IIII

IBM RAID Card를 이용한 RAID5 기능 활성화 방법입니다.

언제부터인지는 모르겠지만, 요즘 출시되고 있는 ServeRAID의 RAID5 기능을 이용하려면 별도의 업데이트가 필요하게 되었습니다.

구형 장비에서도 별도의 업데이트가 필요하기는 했지만, Hardware Chip과 같은 형태로 제공되었기 때문에 큰 수고없이 장착 후 사용하면 되었습니다.

하지만 요즘 장비는 조금 다르더군요...

필수적으로 IBM DSA(Diagnostic System Analysis)를 사용해야합니다.

DSA를 실행하는 방법은 여러 가지가 있지만, bootable iso를 download(http://www-947.ibm.com/support/entry/portal/docdisplay?lndocid=serv-dsa) 받으신 후 CD로 구워서 booting하는 방법을 추천드립니다.

bootable iso를 활용하지 않으실 경우 Hardware에 OS가 이미 설치되어 있어야합니다.

이번 작업을 수행하기 위해서는 아래와 같은 사전 준비물이 필요합니다.

  1. RAID5 Activation Instruction 문서

  2. IBM DSA

  3. IBM site Log-in ID

Activation Key 발급을 위해 IBM 자료실로 이동합니다.

https://www-304.ibm.com/systems/x/fod/index.wss

URL 클릭 후 Sign in button을 클릭합니다.


IBM ID로 Log-in 하신 후, 'Request activation key'를 click합니다.


'Activation Instruction' 문서에 나와있는 'Authorization code'를 입력합니다.


'Machine Type'과 'Model', 'Serial number'를 입력합니다.


입력된 정보들을 확인한 후 'Confirm'을 선택합니다.


위 작업이 끝나면 Activation Key를 제공받을 수 있습니다.

제공 방법은, e-mail을 통한 방법과 직접 download 방법 총 2가지가 존재합니다.

Key file은 확장자가 '.key' 인 file입니다.

Key를 발급받으셨다면, Key를 USB로 복사를합니다.

이후 이전에 만들어 놓으신 IBM DSA를 통해 부팅을 합니다.

부팅이 완료되시면, 'Manage Activation Key'를 선택합니다.


'Install from Removable Media'를 선택합니다.


Key가 저장되어있는 USB media를 선택합니다.


할당하기를 원하시는 Key를 선택합니다.


Key 입력이 정상적으로 완료될 경우, 아래와 같이 'Installed'라는 상태가 표시됩니다.



모든 Key 입력이 완료되면, 'Status'의 상태가 'valid'로 표시됩니다.


상태가 'Valid'로 표시된다면 RAID5 기능을 사용할 수 있는 상태임을 의미합니다.

이제 RAID Utility를 통해 RAID5를 생성하시면 됩니다.

This post will show you how to configure to collect logs.

syslog configuration have to be configured on each devices.

Most of devices and os have different way to configure syslog forwarding, so If you can't find manual in this post, please find solution manual.

In this post show you collecting operation system syslog like AIX, Linux, HP-UX, Solaris.

I define QRadar's IP address is 192.168.0.16.

1. Configure forwarding IBM AIX syslog 

  1) modify syslog.conf file


Add comment from ## QRadar to IP address in bottom of file.

It means AIX host will forward syslog to 192.168.0.16 ip address(it is QRadar).

'## QRadar' is comment in this file and has no impact.


'*.debug @192.168.0.16' means server forward every logs in all category that have debug level to 192.168.0.16 ip address(QRadar).

  2) restart syslog service


'refresh -s' command is used to restart services.

2. Configure forwarding Linux syslog 

  1) modify syslog.conf file

Add this two line like AIX setting.

  2) restart syslog service


'/etc/init.d' directory has service files.

And If you have RHEL based linux, you can use service command as below box.


3. Configure fording Solaris / HP-UX syslog 

  1) modify syslog.conf File


  2) restart syslog service

Let me tell you about logs that be base on SIEM system.

There are two type Event log and and Flow log in logs.

Event log is known as usually we know, It includes system, application and other logs on our infrastructure.

For example, There are syslog, file or table in event log.

Another log is called as 'Flow', It is network traffic on our network structure.

We can know many information that how many packet was sanded or received packets.

Please read Wikipedia for more information about Flow.

Below table explains detail information of logs.













Table 1) Detail log information

Log Status means how save this log, it might be syslog, file, Database.

These logs are used for each purpose.

Syslog is used to record about every action on severs, network devices, security solutions.

You can think It is one of programs that be used in UNIX system.

Most devices support to use syslog, and simply Linux syslog write all actions on the /var/log/messages.

Syslog of each devices send logs, We can think syslog push logs to QRadar.






Image 1) Push and Poll logs

Pushing is real-time option for sending logs, but If QRadar had been down, syslog couldn't send logs to QRadar, logs are loss.

We can input logs to QRadar manually, it can't be perfect solution.

Syslog method is good to use for real-time and general purpose, It can't keep all logs.

I told you Syslog is usually used for OS / network device / security solution.

So, maybe there are other log types.

Typical log is 'file log'.

IIS / DB / Tomcat / Apache / etc are using file log for recording action.

For collecting file log, We have to use FTP protocol.

But someone don't want to use FTP.

If you don't want, You can use SFTP.

SFTP is enhanced file transfer protocol for security.

So let me say SFTP is better then FTP.

It is similar with now days most company restrict telnet connection.

Unfortunately QRadar don't support for collecting file logs real-time, because QRadar access log file for real-time, It makes performance slow.

So we have to interval time least 15 minute, QRadar collect repeat using schedule.

File log protocol can make sure collecting all logs.

After reboot QRadar, QRadar sync last log collected and original logs, It collect logs that be not collected log.

It have advantage and disadvantage the other way syslog.

File log has some rules.

When QRadar collect file logs, QRadar access log file.

So QRadar needs server's account and authentication.

This protocol can't be used like real-time collecting because QRadar access file, it has interval times.

The minimum time is 15 minute.

We can't set less time.

I said to you syslog is OS log, file log is application logs.
(It is general, Not only used)

So, What situation uses DB logs?

Usually, most of solutions use DB table log for managing historical data.

Simply speaking, If you have internet monitoring solution, this solution write who did use chatting services or messenger services.

Add to this, history of accessing some system will be written on DB, this type is core of log types.

To collect DB logs is needed JDBC(Java Databases Connectivity) for each DBMS.

QRadar basically supports Microsoft SQL Server, Oracle, DB2, Sybase and etc.

And other DBMS also can be collected by QRadar, it can't support all of DBMS.

Please see next posting if you want to know about flow.

Thanks.


Related Links

IBM QRadar 1) 개요
IBM QRadar 2) 주요 기능
IBM QRadar 3) 로그 유형 (2/2)

PostgreSQL은 IP를 기반으로 한 접근 제어를 통해 보안 증대 효과를 보고있습니다.

최초 설치시 localhost에서만 접근만을 허용하기 때문에 어떠한 원격 접속이 불가합니다.

때문에 우리가 사용하고 있는 IP를 허용해주는 설정이 필요합니다.

이 설정을 수행하지 않고 접속을 시도할 경우 아래와 같은 Error가 발생합니다.



1. pg_hba.conf file 수정

■ 하나의 IP / IP 대역 허용




3. postgres.conf 수정

DB Server에 Vormetric Agent를 설치하게 되면, Vormetric Server에서 6하 원칙에 의한 접근 관리를 하게 됩니다.

누가(User), 언제(Time), 어디서(Directory), 무엇을(File), 어떻게(Process)에 따라 권한을 부여합니다.

예를들어, 'root에게 /oracle이라는 Directory의 Data를 Read / Write에 대한 암.복호화 할수 있게하지만 다른 모든 User는 암.복호화를 제외한 Read만 가능하게한다.'와 같은 Rule을 정의할 수 있습니다.

※ Policy Sample

위 Policy Sample을 차례대로 보겠습니다. (위에서 부터 아래로 우선 순위 정책입니다.)

Policy 1 : 매주 월요일 root가 cat 명령어를 사용하는 것에 대해 읽기 및 암.복호화 권한 부여

Policy 2 : 매주 토요일 user1의 모든 행위에 대해 읽기 및 암.복호화 권한 부여

Policy 3 : 나머지 요일의 경우 모든 행위에 대한 읽기 권한만 부여(암.복호화 불가능)

같은 사용자 계정을 사용한다고 하더라도, 명령어(Process)나 시간(When)에 따라 각기 다른 정책을 부여할 수 있습니다.

여러 가지 복잡한 설정들이 가능하겠지만 실제로는 사용자 계정에 따라 읽고 쓰기 / 암.복호화 권한을 주는 등의 설정이 주류를 이루겠지요. ^^

정책을 생성한 후 각 Host 마다 Guard Point를 지정해주어야합니다.

Guard Point란, Host 내에서 실제로 암호화할 구역을 설정하는 것입니다.

Host의 모든 File이 암호화되는 것이 아니기 때문에 Guard Point와 같은 개념이 필요합니다.

※ Guard Point

그림과 같이, 많은 Directory 중 암호화 할 대상(directory1, directory2)을 선정하여 Guard Point로 설정하게 되면 그 내부에 있는 모든 Data가 암호화되게 됩니다.

조금 더 상세하게 말씀드리면, Guard Point로 설정이 되고나면 File 생성, 이동 등의 행위에 의해 Directory 내로 귀속된 Data는 암호화되는 구조를 갖고 있습니다.

모든 OS 및 File System에 대해 위 기능을 지원하는 것이 아니므로, 사전 점검이 중요할 것으로 보입니다.

아래는 지원 가능한 OS 및 File System 범위이므로 참조하시라고 올립니다. ^^

이상 Vormetric에 대해 알아보았습니다.

감사합니다 !

※ Appendix. OS / File System 지원 범위

안녕하세요.

이번에는 DB 암호화 Solution 중 하나인 Vormetric에 대하여 알아보겠습니다.

Vormetric은 개인정보보호법이 시행되면서 큰 각광을 받고 있는 암호화 Solution입니다.

개인정보보호법이 시행되면서 모든 기업은 개인 정보를 보호해야될 의무를 갖게 되었습니다.

개인정보보호법은 기술적 / 정책적 관리 수칙을 준수하도록 권고하는, 2011년 9월 30일에 시행된 법률입니다.

개인정보보호법 기술적 보호조치에서 필수적으로 수행해야 될 항목 중의 하나로, 개인정보를 포함하고 있는 DB를 암호화해야한다고 이야기하고 있습니다.

자, 그럼 Vormetric의 기본적인 개요를 살펴보겠습니다.


Vormetric에서 Data를 암호화하기 위해서는 암호화 대상 Server에 Agent를 설치해야합니다.

각 OS별 Agent가 별개로 존재하며, IBM AIX, HP-UX, Solaris, Linux, Windows를 지원합니다.

Vormetric에서는 이 모든 암호화 대상 System들을 'Host'라고 부르고있습니다.

Agent가 설치된 Host들은 Vormetric Server와 통신하며 암.복호화 Key를 갱신하고, 정책등을 Update하게 됩니다.

Data를 보호하기 위해 암호화할 대상 단위는 User Access, Directory, Volume Manager 등을 다양하게 지정할 수 있다는 장점이 있습니다.

Vormetric Capability를 소개하는 Image를 보시지요.


※ 출처 : 01-Vormetric Data Security v5 - Architectural Overview  - Q3 2012.pdf

DB를 암호화 할 경우, 암호화 Directory 생성 후 DB File을 넣게 되면 통째로 암호화 되기 때문에 Simple한 설정이 가장 큰 강점 중 하나라고 볼 수 있습니다.

DB File을 옮기는 방법 이외에도, Data가 들어있는 Directory 암호화 할 수 있는 DataXform 기능을 지원합니다.

해당 기능은 진행 중 취소하게 될 경우 Data 복호화가 불가능한 상황에 처할 수 있기 때문에 안정성을 위해 잘 사용되어지지는 않는다고 합니다.

암호화를 위해 사용되는 Algorithm으로는 AES128, AES256, ARIA128, ARIA258, 3DES 등이 있습니다.

보안 증대를 위해 더 복잡한 Algorithm을 사용하면 Performance 측면의 문제가 발생한다는 것은 기본적으로 예상할 수 있는 Risk겠지요...

암.복호화는 위 Algorithm에 의해 생성된 Key를 통해 진행됩니다.

다른 암호화 Solution과 마찬가지로, Key가 없을 경우 암.복호화 과정이 불가능해집니다.

때문에 Key 보관 정책을 어떻게 할 것인가를 고민해 보아야합니다.

Vormetric은 Key의 위치를 지정할 수 있는 세 가지 Option을 제공합니다.

  1) Stored on Server
Vormetric Server에서만 Key를 관리도록 설정하는 Option입니다.

※ Stored on Server 

암호화 대상 Host의 RAM에 Key를 저장한 후 암.복호화를 수행하지만, 대상 Host가 재부팅 될 경우 RAM에 저장되어 있던 Key는 소멸됩니다.

재부팅이 완료된 후 Host와 Vormetric Server의 통신을 통해 Key를 다시 부여받지만, 이 때 서로 간에 통신을 하지 못할 경우 Key를 적재하지 못하는 상태가 되며, 암.복호화를 진행할 수 없습니다.

통신 단절시 암.복호화를 할 수 없다는 단점때문에 많이 사용되지는 않습니다.

  2) Cached on Host
Vormetric을 통한 Data I/O가 일어날 때 I/O에 Key를 추가하여 저장을 합니다.

Stored on Server와 다른 점은 Agent DB Host에서 Key를 관리하게 됩니다.

때문에 Agent DB Server 재부팅 이후 Key가 소멸된 상태에서 Vormetric 서버와 Agent DB Host의 통신이 단절되더라도 자체적으로 Key를 복구할 수 있는 vmsecpasswd 기능이 있습니다.

※ Cached on Host

이 설정은 모든 Host가 동일한 키를 갖고 있기 때문에, 서로간의 I/O가 발생할 때 암.복호화를 할 수 있다는 특징이 있습니다.

 ※ 각 Host 간의 암.복호화 가능
때에 따라서 장점이 될수도, 혹 단점이 될 수도 있는 부분입니다.

  3) Cached on Host + Unique to Host
2) Cached on Host 설정과 동일한 역할을 하고있지만, 각 Agent Host가 갖고 있는 Key 값이 다르기 때문에 서로간의 암.복호화를 할 수 없다는 특징을 갖습니다.

 ※ 각 Host 간의 암.복호화 불가능

위 세 가지 설정에서 볼 수 있는 것 처럼, Stored on Server는 장애 상황에 대한 대응을 원활히 할 수 없다는 단점 때문에 잘 쓰여지지 않습니다.

Cached on Host 기능을 활용할 시 Server의 상태와 관련없이 암.복호화를 할 수 있다는 점은 상당한 장점으로 보여지네요.

지금까지 Vormetric의 간단한 설명 및 Key 관리 방식에 대해 알아보았습니다.

다음 Posting에서는 정책에 대해 조금 더 자세하게 언급하도록 하겠습니다.

RHEL 기반 Linux OS에서 NIC를 Bonding하는 방법입니다.

그대로 따라해주시면 됩니다.

1. bond0 설정 File 생성

이상입니다.

Bonding 구성 후 장애 복구 Test는 다음 시간에. ^^