Wednesday, June 14, 2017

라즈베리 파이를 이용한 Stratum 1 NTP 서버 구성 (원제: How to Build a Stratum 1 NTP Server Using A Raspberry Pi )

 라즈베리 파이 모델 B가 2012년 릴리즈 된 이후 수많은 유용한 애플리케이션들이 등장했습니다. 그것들 중 라즈베리파이를 Stratum 1 NTP 서버로 구성해 인터넷과 같은 네트워크에서 시간 동기화에 사용 할 수 있는 기능을 제공하는 것도 있는데 저는 이를 이용해 사무실 전체를 훨씬 효율적으로 만들 수 있었습니다.

Stratum 1 NTP란?

많은 사람들이 이미 NTP에 대해서 잘 알고 있겠지만 이 프로젝트를 시작하기 전, 다시 한 번 짚고 넘어가도록 하겠습니다. 네트워크 타임 프로토콜(NTP - Network Time Protocol)은 네트워크 상의 컴퓨터 시간을 동기화하는데 사용되는 규약이며 협정세계시(UTC - Universal Time Coordinated)를 사용하여 컴퓨터 시계를 밀리 초 혹은 그 이하 단위까지 동기화합니다. 이를 이용하면 네트워크상에 연결된 기본 시간 서버를 통해 전체 네트워크 내의 컴퓨터 시간을 동기화 할 수 있습니다. 이는 일반적으로 번거롭고 비용이 들지 않게 UTC를 이용할 수 있는 방법입니다. 컴퓨터가 UTC 소스에 연결되는 계층은 'strata'로 정의됩니다. Stratum 1 NTP 서버는 특히 위성 항법 시스템 또는 라디오 시계 등 실제 시간을 수신하는 기기와 직접 연결되며 Stratum 2는 Stratum 1 컴퓨터 등에 연결되어 작동합니다.

NTP는 왜 유용한가?

NTP 서버는 UTC 소스의 정확한 시간을 수신해 내부 컴퓨팅 자원의 시간 동기화를 제공하는, 비용 효율적인 솔루션입니다. 시간동기화는 여러 상황에서 중요한 요소가 되는데 예를들어 트러블 슈팅 시 서버 로그를 뒤져볼 때에 시간동기화가 되어 있지 않다면 매우 곤란할 것입니다. 마찬가지로, 분산 프로세스는 정확한 순서를 따르기 때문에 시간의존적이며, 보안플랫폼들 또한 데이터 암호화, 복잡한 인증시스템구현, 사이버 보안 위협 혹은 금융사기로부터 안전한 데이터 입력 및 변환 등을 위해 시간의존적입니다. 또한 수많은 시스템이 상호의존적으로 복잡하게 업데이트가 이루어지는 경우, Kali Linux와 보안매니지먼트를 위한 KrolLDiscovery에서 데이터 암호화 혹은 시스템 복구 등의 과정에서도 시간에 대한 정확성이 요구됩니다. 이러한 정확한 시간 정의를 통해 데이터 침해 가능성을 줄이고 현 시스템의 결함을 파악할 수 있습니다.  $100이 조금 넘는 금액으로 Stratum 1 NTP 서버를 구성함으로써 워크플로를 개선하고 UTC를 사용하는 장점을 모두 취할 수 있습니다.

Stratum 1 NTP Server를 구성하기 위해 필요한 것들:

  • 라즈베리 파이 (512 MB의 메모리를 가진 Model B 이상 권장)
  • PPS 출력을 가진 GPS 모듈 (Adafruit’s Ultimate GPS Breakout 권장)
  • CR1220 대체 배터리
  • 프리미엄 수-수 점퍼 와이어
  • GPS 안테나
  • 기기 보호를 위한 Raspberry Pi 용 케이스
  • SMA - uFL/u.FL/IPX/IPEX RF 어댑터 케이블
  • 하프 사이즈의 Breadboard
  • 선택사항: Chronodot (라즈베리 파이는 하드웨어 시계를 내장하고 있지 않기 때문에 Chronodot는 이 문제를 해결하기에 좋은 대안임)
  • Adafruit Assembled Pi Cobbler Breakout과 Raspberry Pi 케이블

하드웨어 구성하기

제일 먼저, 준비된 모든 퍼즐 조각들을 연결하도록 합시다. 이를위해 GPS / PPS 출력을 Pi의 23번 핀에 연결하고 GPS TXD를 라즈베리파이의 RXD에 연결합니다. VIN에 5V 전력을, GND에 GND을 을 연결합니다. 특정한 트러블슈팅을 찾기 위해서는 GPS RXD에서 Raspberry Pi TXD로 다른 케이블을 연결할 수도 있습니다.
그 다음 접착제를 사용해 브레드 보드를 라즈베리 파이 케이스에 고정하고 브레드 보드 브레이크 아웃 핀을 GPS 브레이크 아웃 보드에 납땜합니다. 그리고 배터리 하우스를 또한 납땜해야합니다. 이 작업이 처음이라면 민감한 하드웨어를 파괴하지 않기 위해 조심스럽게 진행해야 합니다.

운영체제 구성하기

OS 설치의 첫 단계는 Adafruit’s Occidentalis v0.2 이미지를 설치하는 것입니다. 해당 이미지는 Raspberry Pi의 정식 OS인 Raspbian에서는 제공하지 않는 추가 패키지들이 선탑재되어 있습니다. 해당 이미지를 다운로드 받아 다음 명령어를 이용해 SD 카드에 기록합니다.
#dd if=/path/to/occidentalis.img of=/dev/sdz
다음으로 SSH를 활성화하기 위해 SD카드를 마운트 해서 /etc/network/interface 파일을 편집합니다. 이 작업이 완료되면 가상 인터페이스가 보일 것입니다. (이 과정에 대한 설명). 그리고 나서 라즈베리파이를 부팅하고 터미널로 접속합니다.
디폴트 커널은 PPS를 지원하지 않기 때문에 커스텀 커널을 사용해야 합니다. 이를 위해 다른 사람의 3.1 커널 저장소를 사용하겠습니다.

먼저 터미널에서 root 권한으로 Git을 설치하고 다음 저장소를 사용합니다.
#apt-get install git
#git clone https://github.com/davidk/adafruit-raspberrypi-linux-pps.git
다음으로 새 커널과 모듈을 복사합니다.
# cd adafruit-raspberrypi-linux-pps
# cp kernel.img /boot/kernel.img.pps
# cp -a modules/* /lib/modules
변경 사항을 영구적으로 적용하기 위해 "pps-gpio" 모듈이 매 부팅시마다 로드되도록 해야 합니다. 다음 명령어를 사용합니다.
# echo  ‘pps-gpio’  >> /etc/modules
새 커널 적용을 위해 아래 내용을 /boot/config.txt 파일에 덧붙입니다.
kernel=kernel.img.pps
gpu_mem=16
재부팅 하고 나서 다음 명령어로 새 커널로 잘 부팅되었는지 여부와 "pps-gpio"모듈이 로드 되어 있는지 확인합니다.
# uname -a
Linux ntp.example.com 3.1.9adafruit-pps+ #21 PREEMPT Sun Sep 2 10:57:58 PDT 2012 armv6l GNU/Linux
# lsmod | grep pps-gpio
pps_gpio                2314  0 
pps_core                7808  2 pps_gpio,pps_ldisc

NTP 컴파일 하기

하드웨어와 OS가 준비되었으니 이제 NTP를 컴파일할 차례입니다. 오리지널 Raspbian 패키지는 ATOM을 지원하지 않기 때문에 NTP를 직접 컴파일해야합니다. 이를 위해 root권한으로 /etc/apt/sources.list 파일을 열어 다음 내용을 추가합니다.
deb-src http://mirrordirector.raspbian.org/raspbian/ wheezy main contrib non-free rpi
그리고 root 권한으로 다음 명령어를 입력합니다.
# apt-get update
# apt-get build-dep ntp
# apt-get source ntp
# cd ntp-4.2.6.p5+dfsg
Here’s where things get good; 'debian/rules" 파일을 수정해 "- – enable-ATOM" 을 설정에 덧붙입니다. 그리고 "debian/changelog" 파일에 "pps"를 적절한 버전 번호와 함께 덧붙입니다. 그 후, 패키지를 빌드하고 설치합니다.
# dpkg-buildpackage -b
# cd ../
# dpkg -i ntp_4.2.6.p5+dfsg-2pps_armhf.deb ntp-doc_4.2.6.p5+dfsg-2pps_all.deb

NTP 설정하기

Adafruit GPS 모듈은 NMEA GPS 으로 드라이버 20을 사용하기에 "/etc/ntp.conf 파일에 다음 내용을 추가해야합니다.
server 127.127.20.0 mode 17 noselect
fudge 127.127.20.0 flag1 0 time2 0
이 작업이 완료되면 GPS 시계가 "noselect"로 설정되어 "time2"에 대한 정확한 시간을 파악할 수 있습니다. 신호 문제로 NTP가 시간을 받는데에 조금 시간이 걸립니다. NTP를 24시간 동안 실행하고 "/etc/ntp.conf"파일의 "noselect"를 "iburst"로 추가해 PPS 프로세싱을 위한 준비를 마칩니다. 이후 NTP를 재시작합니다.
윤초를 적용하기 위해 다음 셸스크립트를 "/usr/local/bin/leap-seconds.sh"로 추가합니다.
#!/bin/sh
cd /etc/ntp
wget ftp://time.nist.gov/pub/leap-seconds.list &> /dev/null
service ntp restart &> /dev/null
이 작업의 실행을 위해 root 권한의 cron 작업을 스케쥴링합니다.
0 0 31 6,12 * /usr/local/bin/leap-seconds.sh
잊지말고 셸스크립트에 실행권한을 주는 것도 잊지맙시다.
# chmod a+x /usr/local/bin/leap-seconds.sh
마지막으로 "/etc/ntp.conf" 파일을 다시 한 번 열어 다음 내용을 파일 최상단에 추가합니다.
# leap seconds file
leapfile /etc/ntp/leap-seconds.list
이제 마지막으로 다시 한 번 NTP를 재시작합니다. 이제 수많은 컴퓨터를 연결해 동기화할 때에 "/etc/ntp.conf" 파일에 서버를 추가하기 만하면됩니다. 다만, UTC 소스에서 하나의 stratum이 멀어질수록 매 60 마이크로초가 추가된다는 점은 유의할 필요가 있습니다.
Stratum 1 NTP 서버를 구축하는 것은 시간이 많이 걸리고 어려운 작업일 수 있지만, 그 만큼의 가치가 있습니다. 이 NTP 서버를 사용하면 많은 돈을 절약 할 수 있을 뿐 아니라 과거에는 효율적으로 할 수 없었던 작업들이 가능해집니다. 










번역된 컨텐츠입니다.
Red Hat Developers Blog. Samantha Donaldson. https://developers.redhat.com/blog/2017/02/22/how-to-build-a-stratum-1-ntp-server-using-a-raspberry-pi/

Translated article.

Red Hat Developers Blog. Samantha Donaldson. https://developers.redhat.com/blog/2017/02/22/how-to-build-a-stratum-1-ntp-server-using-a-raspberry-pi/

Monday, June 5, 2017

AWS EC2 인스턴스에서 Host 기반 침입탐지시스템(IDS) 모니터링 하기 (원제: How to Monitor Host-Based Intrusion Detection System Alerts on Amazon EC2 Instances)

 AWS 리소스를 보호하기 위해서 저희는 예방 및 탐지 컨트롤을 포함하는 계층화 된 접근 방식을 권하고 있습니다. 예를 들어 Amazon EC2 인스턴스에 대해 호스트 기반 컨트롤을 통합하면 액세스를 제한하고 시스템 동작 및 액세스 패턴에 대한 적절한 수준의 가시성을 제공 할 수 있습니다. 이러한 컨트롤을 위해서는 호스트의 네트워크 트래픽, 로그 파일 및 파일 액세스를 모니터링하고 분석하는 호스트 기반 침입 탐지 시스템 (HIDS)이 필요합니다. HIDS는 일반적으로 경고, 자동 치료 솔루션을 통합하여 사용자 환경의 공격, 허가되지 않은 활동 또는 의심스러운 활동 및 일반적인 오류를 탐지하고 해결합니다.
 이 포스팅에서는 Amazon CloudWatch Logs를 사용하여 OSSEC (Open Source Security) HIDS에서 알림을 수집하고 집계하는 방법을 소개합니다. CloudWatch Logs 구독을 사용하여 Amazon Elasticsearch Service (이하 Amazon ES)에 alert을 전달해 분석하고 이것을 오픈 소스 도구인 Kibana로 시각화 합니다.
이 솔루션의 가시성을 위해 대부분의 배포 과정을 처리할 CloudFormation 템플릿도 제공할 것입니다. 이 솔루션을 통해 사용자는 EC2 인스턴스 플릿 전체에 대해 향상된 가시성과 통찰력을 확보할 수 있으며 보안성 개선에 도움을 받을 수 있습니다. 예를 들어, 특정 호스트가 EC2 인스턴스를 스캐닝해 OSSEC 경고를 트리거하는 경우 VPC 네트워크 접근통제 리스트(Access Control List) 또는 AWS WAF 규칙을 구현하여 해당 소스 개별 IP 주소 또는 전체 CIDR 블록을 차단할 수 있습니다.

솔루션 개요

다음 다이어그램은 지금부터 소개할 솔루션에 대한 개요를 보여줍니다.
솔루션은 다음과 같이 동작합니다:
  1. 대상 EC2 인스턴스에서 OSSEC HIDS는 alert을 생성하고 그것을 CloudWatch 로그 에이전트가 캡처합니다. HIDS는 로그 분석, 무결성 검사, Windows 레지스트리 모니터링, 루트킷 탐지, 실시간 경고 및 능동적 대응을 수행합니다. 자세한 내용은 OSSEC 시작하기를 참조하세요.
  2. CloudWatch 로그 그룹은 alert을 이벤트로써 수신합니다.
  3. CloudWatch 로그 구독은 대상 로그 그룹에 적용되어 AWS Lambda를 통해 Amazon ES로 이벤트를 전달합니다.
  4. Amazon ES는 기록된 alert 데이터를 로드합니다.
  5. Kibana는 alert을 실시간에 가깝게 시각화합니다. Amazon ES는 모든 Amazon ES 도메인에서 기본설정된 Kibana를 제공합니다.

배포 고려사항

 이 포스팅에서는, alert이 각 시스템에서 로컬로 생성되고 수집되는 Linux 머신에서 OSSEC HIDS을 구성합니다. 솔루션은 배포하려는 리전의 Amazon ES 및 Lambda에 영향을 받을 수 있으며 리전별 AWS 서비스에 대한 최신 정보는 리전 목록에서 확인할 수 있습니다. 또한, EC2 인스턴스가 필요한 구성 요소를 올바르게 제공 할 수 있도록 Amazon VPC (Virtual Private Cloud) 서브넷에서 인터넷 액세스 및 DNS 검색이 정상적으로 작동하는지 미리 확인해야합니다.
 배포 프로세스를 간소화하기 위한 테스트환경을 AWS CloudFormation 템플릿으로 만들어 두었습니다. 이 템플릿을 사용하면 테스트 환경 스택을 기존 Amazon VPC 서브넷에 자동으로 프로비저닝 할 수 있습니다. 이 경우, CloudFormation을 사용하여이 솔루션의 핵심 구성 요소를 프로비저닝 한 다음, alert 분석을 위한 Kibana 설정을 하면 됩니다. 이 솔루션의 소스 코드는 GitHub에서 내려받을 수 있습니다.
제공된 CloudFormation 템플릿은 선택된 리전에서 다음과 같은 단계를 수행합니다:
  1. CloudWatch의 로그에 액세스 할 수 있는 IAM(Identity and Access Management) 역할을 부여한 두 개의 Amazon Linux 인스턴스 생성. (참고 : 샘플 HIDS 경고 데이터를 얻기 위해 두 개의 EC2 인스턴스가 시뮬레이션 된 HIDS 경고를 로컬로 생성하도록 구성됩니다.)
  2. OSSEC, CloudWatch 로그 에이전트 및 테스트 환경에 사용되는 추가 패키지를 설치하고 구성합니다.
  3. 대상 HIDS Amazon ES 도메인을 만듭니다.
  4. 대상 HIDS CloudWatch 로그 그룹을 만듭니다.
  5. Amazon ES에 HIDS alert을 보내기 위해 Lambda 함수 및 CloudWatch Logs 구독을 만듭니다.
CloudFormation 스택이 배포되고 나면 Amazon ES 도메인의 Kibana 인스턴스에 액세스하여 아래에서 소개할 테스트 환경 설정을 마무리 할 수 있습니다.
 이 포스팅에서 다루는 범위를 조금 벗어난 이야기입니다만, OSSEC을 기존 EC2 환경에 배포 할 경우에는 모니터링 할 로그 파일, 무결성 검사할 디렉터리 및 활성 응답 등 원하는 구성을 직접 결정해야 하며 이후 시스템 환경을 최적화하고 테스트, 튜닝 등이 뒤따라야 합니다. OSSEC 문서에는 이러한 과정에서 참조할 많은 정보들이 있습니다. 또한 이벤트의 중앙처리 및 CloudWatch에의 전송을 담당할 에이전트 혹은 별도의 OSSEC 매니저를 이용하는 형식의 배포 또한 선택가능하나 이 경우에는 추가적인 서버 구성 요소와 에이전트와 관리자 간의 네트워크 통신이 필요합니다. Windows Server의 경우는 OSSEC이 지원하는 운영체제이지만 에이전트 기반 설치만 가능하므로 OSSEC 매니저를 이용해야 합니다. OSSEC 아키텍처 및 배포 옵션에 대한 추가적인 정보를 확인하기 위해서는 OSSEC 아키텍처 페이지에서 확인할 수 있습니다.

솔루션 배포

솔루션의 배포 단계는 다음과 같습니다:
  1. CloudFormation 스택 실행
  2. Kibana 색인 패턴 구성 및 alert 탐색 시작
  3. Kibana HIDS 대시 보드 구성 및 alert 시각화

1. CloudFormation 스택 실행

 자동 프로비저닝을 위해 CloudFormation 템플릿으로 테스트 환경을 시작합니다. 이를 위해 대상 VPC와 서브넷 (인터넷 액세스 필요)등 몇 가지 매개 변수를 입력해야합니다. 배포대상 서브넷이 인터넷 게이트웨이를 사용하는 경우 AssignPublicIP 매개 변수를 true로 설정하십시오. 대상 서브넷이 NAT 게이트웨이를 사용하는 경우 AssignPublicIP의 기본 설정(false)으로 두면 됩니다.
 먼저, 동일 리전의 S3 버킷에 Lambda 함수 배포 패키지를 준비해야합니다. 이를위해 압축 된 배포 패키지를 다운로드하여 버킷에 업로드하십시오. S3에 개체를 업로드하는 방법에 대한 자세한 내용은 Amazon S3에 개체 업로드를 참조할 수 있습니다.
또한 스택을 만든 후 환경에 액세스하고 인스턴스와 연결할 신뢰할 수있는 IP 주소 또는 CIDR 블록을  설정하고, 인스턴스와 묶일 EC2 키 쌍을 선택해야합니다. EC2 Key Pair 생성에 대한 자세한 내용은 Amazon EC2를 사용하여 Key Pair 만들기를 참조하십시오. 신뢰할 수있는 IP 주소 또는 CIDR 블록은 Kibana 액세스를 위해 자동으로 Amazon ES 엑세스 정책에 반영됩니다. 모든 IPv4 주소로부터 인스턴스에 액세스를 허용하는 0.0.0.0/0을 사용하기보다 특정 IP 주소 또는 CIDR 범위를 사용하는 것이 안전합니다. 인스턴스에 대한 인바운드 트래픽 권한 부여에 대한 자세한 내용은 Linux 인스턴스에 대한 인바운드 트래픽 인증을 참조하십시오.
입력한 매개 변수 (자세한 내용은 다음 스크린 샷과 표 참조)를 확인한 후 CloudFormation 스택을 생성합니다.
파라미터설명
1. HIDSInstanceSize테스트 서버에 사용할 EC2 인스턴스 사이즈
2. ESInstanceSizeAmazon ES 인스턴스 사이즈
3. MyKeyPair인스턴스 접속을 위한 공개/비밀 Key Pair 
4. MyS3Bucket압축 된 배포 패키지가 업로드된 동일 리전 S3 버킷
5. MyS3Key압축 된 배포 패키지가 업로드된 동일 리전 S3버킷의 Key
6. VPCId솔루션을 배포할 Amazon VPC
7. SubnetId
선택한 VPC 내에서 아웃바운드 연결을 사용하는 서브넷 ID
(인터넷 연결 필요)
8. AssignPublicIP서브넷이 인터넷게이트웨이를 통해 인터넷에 연결하도록 설정되어 있을 경우에는 true, NAT 게이트웨이를 통하도록 설정되어 있을 경우에는 false
9. MyTrustedNetworkEC2 인스턴스와 Amazon ES 엔트포인트로의 화이트리스트 엑세스를 허용할 신뢰할 수 있는 IP 혹은 CIDR 블록 
CloudFormation 스택 생성 마무리:
  1. 적절한 파라미터 입력 후 Next
  2. Options 페이지에서 default 설정 선택 후 Next
  3. Review 페이지에서 설정값들이 제대로 입력되었는지 확인 후 I acknowledge that AWS CloudFormation might create IAM resources 체크박스를 선택하고 Create. (스택 생성에 약 10분 소요)
스택이 생성되면 CloudFormation의 Outputs 탭에서 HIDSESKibanaURL을 확인한 후에 다음 섹션에서 설명할 Kibana 구성 넘어가십시오.

2. Kibana 색인 패턴 구성 및 alert 탐색 시작

이 섹션에서는 Kibana의 초기 설정을 수행합니다. CloudFormation의 스Outputs (이전 섹션 참조)에 제공된 HIDSESKibanaURL으로 접속하면 Amazon ES 인스턴스에 프로비저닝 된 Kibana 페이지로 이동합니다. CloudFormation 매개 변수로 입력한 IP는 Amazon ES 액세스 정책에 자동으로 반영이 되어 있습니다. 만약 다음과 같은 오류가 발생한다면 Amazon ES 액세스 정책이 올바른지 확인해야합니다.
{"Message":"User: anonymous is not authorized to perform: es:ESHttpGet on resource: hids-alerts"}
Amazon ES 도메인에 대한 액세스 보안에 대한 추가 정보는 Amazon Elasticsearch 서비스 도메인에 대한 액세스를 제어하는 방법을 참조하십시오.
OSSEC HIDS 경고가 이제 Amazon ES로 넘겨집니다. Kibana를 사용하여 대화식으로 alert 데이터를 분석하기위해서는, Amazon ES에서 분석할 데이터를 식별할 수 있도록 색인 패턴을 구성해야합니다. Kibana 문서에서 색인 패턴에 대한 추가 정보를 찾을 수 있습니다.
Index name or pattern 상자에 cwl-2017. *을 입력합니다. 색인 패턴은 람다 함수 내에서 cwl-YYYY.MM.DD로 생성되므로 와일드 카드 문자를 사용하여 2017의 데이터를 매칭할 수 있습니다. Time-field name 드롭 다운 메뉴에서는 @timestamp를 선택하하고 Create를 클릭합니다.
Kibana에서 이제 Discover 창이 선택가능해지고 alert이 채워지는 것을 볼 수 있습니다. alert 갱신 빈도를 설정하려면 오른쪽 상단에서 원하는 시간 범위 (예 : Last 15 minutes)를 선택하십시오.
 Auto-refresh을 선택하고 5 seconds 등 적절한 인터벌을 선택합니다.
Kibana는 이제 매 5초마다 자동 갱신 되도록 구성되었을 것입니다. 다음 스크린샷과 같이 카운트그래프와 함께 alert이 업데이트됩니다.
EC2 인스턴스는 CloudFormation에 의해 자동으로 구성된 두 다음과 같은 시뮬레이션이 동작하며 여러 alert을 표시합니다:
  • Successful sudo to ROOT executed – Linux의 sudo 명령어가 성공적으로 실행됨.
  • Web server 400 error code – 서버가 클라이언트 에러로 인해 요청을 진행하지 못함 (조작된 요청, 큰 사이즈, 유효하지 않은 요청 메시지 프레임 등)
  • SSH insecure connection attempt (scan) – SSH listener로 유효하지 않은 커넥션 시도
  • Login session opened – 시스템에서 로그인 세션이 열림
  • Login session closed – 시스템에서 로그인 세션이 닫힘
  • New Yum package installed – 시스템에 패키지가 설치됨
  • Yum package deleted – 시스템에서 패키지가 삭제됨
다음 스크린 샷으로 몇 가지 alert 필드들을 자세히 살펴 보겠습니다.
위 스크린 샷의 필드들은 다음과 같은 내용을 담고 있습니다:
  1. @log_group – CloudWatch 로그 그룹
  2. @log_stream – The CloudWatch 로그 스트임 이름 (인스턴스ID)
  3. @message – OSSEC의 원본 alerts.json에서의 JSON 페이로드
  4. @owner – alert이 발생한 AWS 계정 ID
  5. @timestamp – Lambda 함수에 의해 정의된 타임스탬프
  6. full_log – 로그 원본 파일
  7. location – 로그 원본의 경로와 파일이름
  8. rule.comment – OSSEC 룰에 대한 간략한 설명
  9. rule.level – 0~16으로 나뉜 OSSEC 룰 분류 (Rules Classification 페이지 참조)
  10. rule.sidid – OSSEC 룰 ID
  11. srcip – alert을 트리거한 IP 주소. 테스트시뮬레이션이 진행된 이 경우에는 서버의 로컬 IP가 표시됨
Kibana 쿼리 바에 검색 조건을 입력하면 HIDS 경고 데이터를 대화식으로 탐색 할 수 있습니다. 예를 들어, 다음 쿼리를 이용해 소스 IP가 10.10.10.10 이고 ID가 i-0e427a8594852eca2인 EC2인스턴스의 레벨 6 alert을 볼 수 있습니다.
“rule.level: 6 AND @log_stream: "i-0e427a8594852eca2" AND srcip: 10.10.10.10”
간단한 텍스트, Lucene 쿼리 구문 또는 전체 JSON 기반 Elasticsearch Query DSL에 이르기까지 다양한 방법을 사용할 수 있습니다. Elasticsearch 문서는 데이터 검색에 대한 추가 정보를 제공하고 있습니다.

3. Kibana HIDS 대시보드 구성 및 alert 시각화

시간 경과에 따른 alert의 추세 및 패턴 분석에는 차트 및 그래프가 유용할 수 있습니다. Kibana 인스턴스로 바로 import할 수 있는 대시보드 템플릿을 구성해 공유해두었습니다.
인스턴스에 샘플 HIDS 대시보드 템플릿 추가:
  1. 템플릿을 로컬에 저장하고 Kibana 네비게이션 창에서 Management 선택
  2. 차례대로 Saved ObjectsImport, 로컬에 저장한 샘플 HIDS 대시보드 템플릿을 선택합니다..
  3. HIDS Alerts 대시보드 항목의 오른쪽에있는 눈 모양 아이콘을 선택하십시오. 이 버튼을 누르면 추가한 대시보드 템플릿으로 이동할 것입니다.
Kibana 대시보드 템플릿으로 이동하면, 다음 스크린 샷과 같이 HIDS 대시보드가 표시됩니다. 이 HIDS 샘플 대시보드는 시간별 alert, 상위 20 개 alert 유형, 규칙 수준 분석, 상위 10 개 규칙 소스 ID 및 상위 10 개 소스 IP 등을 표시합니다.
다음 두개의 스크린샷과 같이 필터링 할 alert 유형을 선택해 alert 데이터를 더 자세히 탐색할 수 있습니다.
You can see more details about the alerts based on criteria such as source IP address or time range. For more information about using Kibana to visualize alert data, see the Kibana User Guide.
소스 IP 주소 또는 시간 범위와 같은 기준에 따라 자세한 내용들을 출력합니다. Kibana를 사용한 데이터 시각화의 자세한 내용은 Kibana User Guide를 참조하십시오.

요약

이 포스팅에서는 CloudWatch 로그를 이용해 OSSEC HIDS에서 alert을 수집하고 CloudWatch와 Kibana, 그리고 Amazon ES을 사용해 분석 및 시각화하는 방법을 설명했습니다. 이 솔루션은 AWS 환경에서 심층 방어 보안 전략의 일환으로 EC2 플릿의 보안 모니터링 개선에 일조합니다.
이 솔루션을 통해 EC2 플릿에 대한 공격이나 이상 행동 및 오류 추세를 탐지 할 수 있으며 시스템 재조정 작업의 우선 순위 지정이나 VPC 보안 그룹 규칙, VPC 네트워크 ACL 또는 AWS WAF 규칙과 같은 추가 제어 결정에 참고할 수 있을 것입니다.
이 게시물에 대한 의견이 있으시면 아래에 커맨트를 달아주시기 바랍니다. 이 솔루션 구현에 대한 질문 혹은 의견은 CloudWatch 또는 Amazon ES 포럼에서 새 스레드를 시작하십시오. 이 솔루션의 소스 코드는 GitHub에서 내려받을 수 있습니다. OSSEC 특정한 지원이 필요한 경우에는OSSEC Support Options을 참조하십시오.
– Cameron




번역된 컨텐츠입니다.

AWS Security Blog. by Cameron Worrell, How to Monitor Host-Based Intrusion Detection System Alerts on Amazon EC2 Instances. https://aws.amazon.com/blogs/security/how-to-monitor-host-based-intrusion-detection-system-alerts-on-amazon-ec2-instances/


Translated article.

AWS Security Blog. by Cameron Worrell, How to Monitor Host-Based Intrusion Detection System Alerts on Amazon EC2 Instances. https://aws.amazon.com/blogs/security/how-to-monitor-host-based-intrusion-detection-system-alerts-on-amazon-ec2-instances/