Showing posts with label cloudwatch. Show all posts
Showing posts with label cloudwatch. Show all posts

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/

Thursday, March 9, 2017

draw.io + AWS CloudWatch로 모니터링 대시보드 만들어보기 (원제: draw.io + Amazon CloudWatchでAWS監視ダッシュボードもどきを作る!)

 AWS CloudWatch의 단조로운 화면에 지쳐 근사한 모니터링 대시보드를 만들어 보고자 draw.io을 이용해 간단하게 인프라 구성도를 그린 뒤 그것을 모니터링 대시보드로 사용하는 아이디어를 구현해 보았습니다.
이름하여 Drawatchio 입니다!

목표


이렇게 CloudWatch의 메트릭을 표시해 주는 동시에, 알람이 울리면 대상 인스턴스가 반짝거리는 등 인프라의 상태를 시각적으로 알려주는 대시보드를 만들고자 합니다.

간단한 구조

draw.io는 mxGraph를 기반으로 만들어져 있는데 그 API를 사용해 Plugin을 만듭니다.
draw.io Online Blog draw.io API
https://support.draw.io/display/DOB/2016/04/28/draw.io+API

Javascript를 사용할 수 있는 것 같고, 그렇다면, Amazon Cognito와 연동해서 Amazon CloudWatch에 간단하게 접근 가능할 것 같았습니다.

즉, 다음과 같이 연동하려 합니다.
draw.io <=> Javascript으로 작성한 Plugin <=> Amazon Cognito에서 인증 <=> Amazon CloudWatch API
제가 Javascript가 익숙치 않기에 실수가 있다면 피드백 부탁드립니다!

사용법

매우 쉽게 사용 가능합니다!

먼저 그림을 그림

당연한 이야기지이만, 우선 draw.io을 이용해 멋진 그림을 그립니다. 이게 제대로 되지 않으면 앞으로의 단계가 의미가 없어요.

Cognito에서 Identity pool을 작성

구글링 하면 많은 정보를 얻을 수 있기에 간단히 설명하겠습니다!
Cognito 화면을 열어 "Manage Federated Identities"를 선택합니다.

적당한 이름을 붙여서 Identity pool을 만듭니다. 간단한 설명을 위해 인증없이 연결하겠습니다. "Enable access to unauthenticated identities"을 선택합니다.
이것은 아래의 Role을 누구에게나 부여하는 것이기 때문에 실제 환경에서는 제대로 인증된 것만 통과시키도록 설정합시다.

그리고 Cognito에서 인증 시(혹은 인증 없는 경우에도)에 부여하는 Role을 지정하는 화면이 나오는데, 기본설정값대로 만들어두도록 하겠습니다.

작성 후에는 Sample Code에서 "Identity Pool ID"에 나온 값을 메모해 둡니다. Cognito를 이용하는데에 이 ID가 사용됩니다.

Cognito에서 만든 IAM  Role에 CloudWatch의 접근을 허용

Role을 작성했습니다만, 아직 아무런 권한도 갖고 있지 않기에 CloudWatch에 읽기권한을 부여합니다.

이 경우에도 동일하게, 인증 없이 CloudWatchReadOnlyAccess를 부여하면 불특정한 모든 사람들에게 CloudWatch가 보여지기에 보안을 생각해 Cognito와 IAM를 설정해 두어야 합니다.

CloudWatch의 Alarm을 만들거나, 매트릭스를 기억

CloudWatch를 사용하여 모니터링을 할 때에 적용해 둘 알람을 작성합니다. CPU 상태를 기준으로 하든, SQS의 Queue 수를 기준으로 하든, ScaleOut 상태를 기준으로 하든 자유롭게 만듭니다. 이 알람의 이름을 조금 뒤에 사용하도록 하겠습니다.

또한, 표시하고 싶은 매트릭스도 봐 둡니다.

작성해두었던 그림에 Cognito와 CloudWatch의 패턴을 포함

이제 여기서부터는
Drawatchio의 독자적 설정입니다.
앞에서 그려둔 그림에 메타데이터로써 Cognito와 CloudWatch의 정보를 포함시킵니다.
구체적인 내용은 깃허브 페이지나 아래의 동영상을 참고해 주세요. 대상 오브젝트를를 우클릭하여 "Edit Data ..."에 속성을 추가합니다.

draw.io에 Plugin 설정

포함시킨 메타테이터를 바탕으로 CloudWatch와 연동되게 Plugin을 설정합니다.
메뉴 - Extras - Plugins...
를 열어 아래 2가지를 추가한 뒤 draw.io 페이지를 리로드 합니다.

모니터링 시작!

드디어 모니터링을 시작합니다!
적당한 오브젝트를 우클릭해서 "Start Monitoring"을 눌러주세요.
설정한 매트릭스가 수집되고 있으면 모니터링이 정상 작동하고 있는 것입니다.

설정 분위기 영상

Cognito와 CloudWatch의 파라미터를 포함한 이후의 작업을 영상으로 만들어 두었으니 참고하세요.
동영상 제작 시에 사용된 Cognito ID는 이미 파기해 두었습니다. :)

마치며

이것으로 모니터링의 효율이 얼마나 오를지는 모르겠지만 조금이라도 즐겁게 업무가 될 수 있었으면 좋겠습니다.

그럼 이쯤에서 글을 마치겠습니다.



번역된 컨텐츠입니다.
Qiita. by Yaggytter. http://qiita.com/Yaggytter/items/6d7ab0384aa3c326e71f

Translated article.
Qiita. by Yaggytter. http://qiita.com/Yaggytter/items/6d7ab0384aa3c326e71f