[목차] 크라켄을 이용한 보안 솔루션 개발 크라켄북

완성할 때까지 블로그 최상단에 위치

1부. 서론

1부에서는 배경지식과 개발환경 설정 방법을 다룬다.

1장. 개요
- 로드맵
- 대상 독자
- 감사의 글

2장. 배경지식
- Maven

- OSGi

- iPOJO
 * iPOJO 핸들러 확장

3장. 개발환경 준비
- m2eclipse 플러그인 설치

2부. 애플리케이션 서버와 기반 모듈

2부에서는 플랫폼을 구성하는 애플리케이션 서버와 인프라 성격의 모듈에 대하여 다룬다.
 
4장. 크라켄 코어
- 로컬 디버깅과 원격 디버깅
- 메모리 덤프 분석
- 크라켄 패키지 시스템
- 작업 스케줄링
- NT 서비스 설치

5장. Hello, OSGi World!
- 헬로월드 프로젝트 생성과 빌드, 설치
- 예제로 이해하는 iPOJO 생명주기: 메타데이터와 어노테이션 기반 설정
- 크라켄 iPOJO를 이용한 컴포넌트 상태 진단
- 크라켄 명령어 확장과 활용
- 크라켄 Cron을 이용한 스케줄링

6장. 크라켄 설정DB
- 파일, RDBMS 저장 방식의 불편함
- 크라켄 설정DB의 특징
- 크라켄 코덱의 구조
- 사용자 정의 타입의 변환 규칙
- 크라켄 설정DB 사용 예제: 커밋, 롤백, 플래시백
- 크라켄 설정DB 명령어
- shrink, export, import

7장. 크라켄 JPA
- 데이터베이스별 JDBC 사용 방법
- 하이버네이트와 OSGi
- 크라켄 JPA 설정과 선언적 트랜잭션
- 크라켄 JPA 명령어
- 크라켄 JPA 활용 예제

8장. 크라켄 도메인 객체 모델 (DOM)
- 개요
- 생명주기 이벤트
- 공통 객체 관리 API
 * 멀티 테넌시 지원
 * 푸시 API
 * 메시지 지역화
 * 사용자 정보 관리
 * 영역 및 호스트 관리

9장. 크라켄 메시지버스
- 개요 및 주요 개념
- 선언적 메시지버스 프로그래밍
- 세션과 인증 처리
- 권한 어노테이션

3부. 네트워크 프로그래밍

3부에서는 보안 솔루션이 통상적으로 타 시스템과 연동할 때 사용하는 각종 프로토콜을 다룬다.

10장. 크라켄 Syslog

11장. 크라켄 SNMP
- snmp 개요
- snmp trap 서버 설정
- snmp trap 서비스

12장. 크라켄 NTP 클라이언트
- NTP 개요
- 자동 시각 동기화 설정

13장. 크라켄 웹서버
- 크라켄 웹서버 명령어 (파일 서버 설정 방법 포함)
- HttpContext 개념
- 서비스 인터페이스

14장. 크라켄 XMLRPC
- XMLRPC 프로토콜 개요
- 선언적 XMLRPC 서비스 프로그래밍
- XMLRPC 프로그래밍 예제

15장. 크라켄 LDAP
- LDAP 인증과 조직도 임포트

16장. 크라켄 RADIUS
- RADIUS 개요
- PAP, CHAP 클라이언트 예제
- PAP, CHAP 서버 예제
- RADIUS 확장 모듈의 구현

17장. 크라켄 메일
- SMTP 서버 설정
- POP3, IMAP 설정
- 자동화된 메일 전송

18장. 크라켄 DHCP
- DHCP 개요
- DHCP 서버 설정

19장. 크라켄 RPC
- 메시지 교환 패턴: request/response, fire-and-forget
- 크라켄 RPC 프로토콜
- 선언적 RPC 서비스 프로그래밍
- 동기적, 비동기적 RPC 호출

3부. 로그 수집과 관리

20장. 크라켄 로그 API
- 개요 및 주요 개념: logger, logger factory, pipe, 네임스페이스 등
- 로그 관리 명령어

21장. 크라켄 로그DB
- 크라켄 로그스토리지의 특징
 * 실시간 압축 및 조회, 비정형 데이터 처리, 읽기 잠금 없음, 비동기 API
- 로그스토리지 명령어
- 로그스토리지 서비스
- 로그 쿼리 문법
- 로그 쿼리 문법의 확장
 * 크라켄 BNF
 * 확장 인터페이스 설명
 * GEOIP 확장 예시
- 로그 쿼리 서비스
- 텍스트 파일 통계 처리 예시
- 표준 출력 (stdout) 처리 예시

22장. 크라켄 센트리/베이스

4부. 저수준 네트워크 프로그래밍

4부에서는 드라이버 수준에서 수집된 패킷을 필터링하거나 해석하고 조작하는 방법을 다룬다.

23장. 크라켄 PCAP
- PCAP 개요 
- PCAP 파일 포맷
- 802.11 무선랜 패킷의 해석
- DHCP 핑거프린팅을 이용한 장치 식별
- HTTP 이미지 파일 추출 예제
- SMTP 첨부파일 추출 예제

24장. 크라켄 Captive Portal (인증 포탈)
- Captive Portal 개요
- ARP 스푸핑
- DNS 포이즈닝
- 설치 및 연동
- 아이폰 패킷 캡처 예시


10.2. 크라켄 Syslog 설치 및 설정 크라켄북

아래 명령어를 이용하여 크라켄 Syslog 패키지를 설치할 수 있다.

kraken> pkg.install kraken-syslog


크라켄 Syslog는 Syslog 서버를 열고 닫는 명령어들과, 실시간으로 서버 상태 및 로그 수신을 추적하는 명령어들이 지원된다.
  • syslog.servers
    현재 열려있는 모든 Syslog 서버의 목록을 표시한다. 바인딩 된 주소, 바이너리 해석에 사용할 문자집합, 로그 버퍼 크기, 현재까지 수신한 로그 수, 큐에 대기 중인 로그 수를 확인할 수 있다.
  • syslog.open
    새 Syslog 서버를 생성한다. 크라켄 코어가 재시작되어도 서버 설정이 유지된다.
  • syslog.close
    Syslog 서버를 닫는다.
  • syslog.trace
    실시간으로 수신되는 Syslog를 출력한다.
아래는 syslog.trace 명령을 이용하여 실시간으로 수신되는 Syslog를 확인하는 화면 예시이다. Ctrl+C를 누르면 실시간 출력을 중단한다.


프로그래밍 방식으로 Syslog 서버를 열거나 로그를 수신하려면, SyslogServerRegistry OSGi 서비스를 이용한다.
  • void open(SyslogProfile profile) throws SocketException;
    Syslog 서버를 연다. 크라켄 코어를 재시작해도 Syslog 서버가 유지된다.
  • void close(String name);
    Syslog 서버를 닫는다.
  • void addSyslogListener(SyslogListener callback);
    SyslogListener 콜백을 추가한다. 모든 서버의 Syslog를 수신할 수 있다.
  • void removeSyslogListener(SyslogListener callback);
    SyslogListener 콜백을 제거한다.
만약, 특정한 Syslog 서버의 Syslog만 수신하고 싶다면, getServer(String name) 혹은 findServer(InetSocketAddress local) 메소드를 이용하여 SyslogServer 개체를 얻어낸 다음, 이 개체에 SyslogListener 콜백을 추가하면 된다.


10.1. 크라켄 Syslog 개요 크라켄북

크라켄 Syslog는 syslog를 수신하여 인코딩을 해석하고 syslog를 필요로 하는 모든 서브시스템들에게 로그를 전달하는 역할을 수행한다. Syslog 프로토콜에 대한 자세한 내용은 RFC 5424를 참조하도록 한다. 

크라켄 Syslog는 가장 흔히 사용되는 PRI 헤더만을 파싱한다. 현실적으로 봤을 때 그 외의 Syslog 헤더들은 RFC를 준수하여 포맷팅 된 경우가 거의 없다. RFC에서는 유니코드를 사용할 것을 주문하고 있으나, 그마저도 각국의 멀티바이트 인코딩(euc-kr 등)으로 날아오는 경우가 비일비재하다.

PRI 헤더는 <숫자> 형태로 구성되는데, Facility와 Severity의 조합으로 숫자가 만들어진다. Facility는 해당 호스트의 어떤 서브시스템이 로그를 보냈는지 식별하는데 사용하는 번호이고, Severity는 중요도를 의미한다. RFC에 정의된 Facility 값은 아래와 같다:
  • 0: 커널 메시지
  • 1: 유저레벨 메시지
  • 2: 메일 시스템
  • 3: 시스템 데몬
  • 4: 보안/권한인가 메시지
  • 5: syslogd 데몬 로그
  • 6: 라인 프린터 서브시스템
  • 7: 네트워크 뉴스 서브시스템
  • 8: UUCP 서브시스템
  • 9: clock 데몬
  • 10: 보안/권한인가 메시지
  • 11: FTP 데몬
  • 12: NTP 서브시스템
  • 13: 감사 로그
  • 14: 경고 로그
  • 15: clock 데몬
  • 16: local0
  • 17: local1
  • 18: local2
  • 19: local3
  • 20: local4
  • 21: local5
  • 22: local6
  • 23: local7
15번까지는 사전 정의된 구성요소들이 쓰는 것이고, 대부분의 네트워크 장비들은 사용자 정의에 해당하는 16번부터 23번까지의 번호 중 하나를 설정하여 사용한다. PRI 헤더 숫자의 하위 3비트는 Severity 값으로 쓰이는데, 각 의미는 다음과 같다:
  • 0: Emergency
  • 1: Alert
  • 2: Critical
  • 3: Error
  • 4: Warning
  • 5: Notice
  • 6: Informational
  • 7: Debug
따라서 만약 PRI 헤더가 <165>라면, 이진수로 10100101 이고, 하위 3비트는 5, 상위 5비트는 20에 해당하므로, local4에서 발생한 Notice 로그에 해당된다.

크라켄 Syslog는 Syslog 객체를 전달하는데, 이 객체는 아래와 같은 메소드들을 지원한다:
  • Date getDate()
    로그 수신 시각
  • InetSocketAddress getLocalAddress()
    로그를 수신한 로컬 주소
  • InetSocketAddress getRemoteAddress()
    로그를 전송한 원격지 주소
  • int getFacility()
    Facility 값. 만약 PRI 헤더가 없었다면 -1
  • int getSeverity()
    Severity 값. 만약 PRI 헤더가 없었다면 -1
  • String getMessage()
    Syslog 본문 문자열
크라켄 Syslog는 여러 포트에서 Syslog를 수신할 수 있고, 각 포트마다 설정된 문자집합으로 바이너리를 해석하여 메시지 문자열을 복원한다. (기본값은 utf-8)

다음 절에서 크라켄 Syslog 패키지의 설치와 관리 방법을 알아본다.

22.4. 센트리 원격 로그 펌핑 크라켄북

센트리의 가장 중요한 기능은 베이스에서 로거를 관리하고, 원격지에서 로그를 가져갈 수 있도록 하는 것이다. 베이스는 센트리가 접속하면 센트리에 존재하는 모든 LoggerFactory와 Logger의 목록을 동기화하고, 마치 로컬 시스템에 실제로 존재하는 것처럼 프록시 개체를 만들어 LoggerRegistry와 LoggerFactoryRegistry에 등록한다. (각각 RemoteLogger, RemoteLoggerFactory에 해당된다.)

아래 명령어들을 이용하여 동작을 먼저 확인해보자:

base> base.remoteLoggers bb4f6e12-b7c6-4554-8780-fb52c316f058
base> base.remoteLoggerFactories bb4f6e12-b7c6-4554-8780-fb52c316f058
base> logapi.loggerFactories


먼저, base.list 명령어로 현재 접속된 센트리를 확인하였고, base.remoteLoggers 명령으로 원격지의 Logger 목록을, 그리고 base.remoteLoggerFactories 명령으로 원격지의 LoggerFactory 목록을 확인하였다. 현재 센트리에서 생성된 Logger가 아무 것도 없기 때문에 빈 목록이 나오고, 원격지의 LoggerFactory 목록은 process-check, textfile, windows-event-logger, cpu-usage, memory-usage, disk-usage, network-usage 가 존재하는 것을 확인할 수 있다.

logapi.loggerFactories 명령으로 확인해보면 로컬에 존재하는 LoggerFactory와 원격지에 존재하는 LoggerFactory가 혼재되어 표시되는 것을 확인할 수 있다. 원격지의 LoggerFactory는 이름공간(namespace) 문자열이 센트리의 GUID으로 표시된다.

이제, 원격에서 CPU 사용률 성능 로그를 받도록 설정해보자.

base> base.createRemoteLogger bb4f6e12-b7c6-4554-8780-fb52c316f058 cpu-usage cpu "my remote cpu usage log"
base> base.startRemoteLogger bb4f6e12-b7c6-4554-8780-fb52c316f058 cpu 5000
base> base.connectRemoteLogger bb4f6e12-b7c6-4554-8780-fb52c316f058 cpu
base> logapi.loggers
base> logapi.trace bb4f6e12-b7c6-4554-8780-fb52c316f058\cpu


base.createRemoteLogger 명령을 사용하면, 해당 GUID를 가진 센트리의 LoggerFactory를 이용하여 원격지에 Logger 개체를 생성한다. 여기서는 "cpu"라는 이름의 Logger를 만들었다. base.startRemoteLogger 명령을 사용하면, 해당 GUID를 가진 센트리의 "cpu"라는 이름을 가진 Logger를 5초 주기로 동작하도록 시작시킨다. 여기까지는 단순히 원격지의 로거를 만들고 시작시킨 것일 뿐 베이스에 로그가 들어오는 것은 아니다.

base.connectRemoteLogger 명령을 사용하게 되면, 원격지의 Logger에 LogPipe를 연결하면서 RPC 접속을 타고 비로소 로그가 원격지에서 전송되기 시작한다. logapi.loggers 명령을 쳐보면, 센트리 GUID로 된 네임스페이스에 cpu 이름의 Logger가 마치 로컬에 존재하는 것처럼 만들어져 있다. logapi.trace 명령을 사용하여 Logger에서 발생하는 로그를 실시간으로 추적할 수 있다. 화면 예시에서 5초마다 CPU 사용률 로그가 화면에 표시되는 것을 볼 수 있다. (실시간 추적을 중지하려면 Ctrl-C)

원격 로그 펌핑을 중단하려면 base.disconnectRemoteLogger 명령을 사용하면 된다.

베이스에서 이를 프로그래밍 방식으로 수행하려면, 앞에서 언급했던 SentryProxy 개체를 이용한다.
  • Logger createRemoteLogger(String factoryName, String name, String description, Properties props) throws RpcException, InterruptedException;
    원격지에 로거를 생성한다.
  • void removeRemoteLogger(String name) throws RpcException, InterruptedException;
    원격지의 로거를 삭제한다.
  • void startRemoteLogger(String name, int interval) throws RpcException, InterruptedException;
    원격지의 로거를 시작시킨다.
  • void stopRemoteLogger(String name, int timeout) throws RpcException, InterruptedException;
    원격지의 로거를 정지시킨다.
  • void connectRemoteLogger(String loggerFullName) throws RpcException, InterruptedException;
    원격지의 로거에 파이프를 연결한다. 이 때부터 실시간으로 원격지의 로그가 수신된다.
  • void disconnectRemoteLogger(String loggerFullName) throws RpcException, InterruptedException;
    원격지의 로거에 연결된 파이프를 끊는다.


1 2 3 4 5 6 7 8 9 10 다음