Unique Life

출처: http://acc.giro.or.kr/secu_view.asp?seq=7887

 http://elven.kr/archives/361

윈도우 운영체제 기반의 피해시스템에서 공격자의 침투경로를 파악하기 위해서는 어떠한 정보가 필요할까요?
인터넷 기록 및 레지스트리 등을 확인 및 분석하여 악성코드에 어떻게 감염되었는지도 살펴볼 정보 중 하나이나,
가장 중요한 아티팩트는 윈도우 이벤트 로그라고 볼 수 있습니다.

이 이벤트 로그는 외부에서의 시스템  접속과 사용자 계정 설정 변경 등
침투/피해 시점 당시 발생하였던 다양한 정보를 저장하고 있으며 분석가는 이를 통해 보다 효율적인 접근이 가능합니다.

이번 포스트에서 다룰 내용은 분석 시 활용할 수 있는 로그 설명과 이벤트 ID 등 기초적인 내용이며,
실제 이벤트 로그의 내부 구조 및 활용 사례 등에 대한 심화 과정은 다음 포스팅에서 다룰 예정입니다.

그럼 이벤트 로그에 대해 하나씩 살펴보도록 하겠습니다.

 1. 윈도우 이벤트 로그?

이벤트 로그에는 윈도우에서 발생하는 하드웨어, 소프트웨어 및 시스템 문제에 대한 다양한 이벤트들이 기록됩니다.
다만 운영체제가 업그레이드 됨에 따라 버전별로 기록되는 형태와 경로가 조금씩 다른데요,

각 운영체제별 이벤트 로그 특징은 아래와 같습니다.
(운영체제를 그룹핑하여 Type으로 분류하였으며, 앞으로 설명드릴 내용 역시 역시 분류 기준으로 설명드리겠습니다)

바이너리 형태로 저장된 이벤트 로그를 확인하기 위해서는
데이터를 해석하고 알아볼 수 있게 해주는 별도의 프로그램이 필요한데요,
대표적으로 윈도우에서 기본으로 제공하는 ‘이벤트 뷰어’가 있습니다.

이 도구는 [제어판] → [관리도구]에 위치하고 있으며,
[실행] 창에 eventvwr.msc 를 입력하여 바로 실행할 수도 있습니다.

윈도우8에서는 아래와 같은 방법으로 이벤트 뷰어를 실행할 수 있습니다.
먼저 윈도우 화면에서 윈도우키와 w 키를 함께 누르게 되면 검색창이 실행되는데요,
이 검색창에 ev 를 입력 후 실행하시게 되면 이벤트 뷰어 화면이 출력되는 것을 보실수 있습니다.

주요 이벤트별 특징은 다음과 같습니다.

1) 응용프로그램 로그

2) 시스템 로그

3) 보안 로그

이외에도 OS 구성에 따라 디렉토리 서비스, 파일 복제 서비스, DNS 서버 로그 등이 추가될 수 있습니다.

2. 이벤트 로그 설정 확인

이벤트 로그의 설정을 확인하는 방법은 크게 두 가지로
레지스트리를 이용하는 방법, 이벤트 뷰어를 이용하는 방법이 있습니다.

1) 레지스트리를 통한 확인

[실행] → ‘regedit’ 입력 → ‘HKLM\System\CurrentControlSet\Services\EventLog’ 에서 설정 값을 확인 및 수정할 수 있습니다.

2) 이벤트 뷰어를 통한 확인

이벤트뷰어에서 각 이벤트로그에 대한 속성을 변경할 수 있으며,
설정을 변경하고 싶은 이벤트에 우클릭하여 나오는 메뉴에서 ‘속성’을 클릭합니다.

속성에서 이벤트 로그 파일의 최대크기를 지정해 줄 수 있으며, 로그 관리에 필요한 설정을 할 수 있습니다.

3. 이벤트 로그 구성

이벤트 뷰어를 통해 아래와 같이 로그에 저장된 이벤트를 확인할 수 있습니다.

각 이벤트 엔트리의 헤더에는 다음과 같은 이벤트 정보가 포함됩니다.

또한 이벤트 종류는 다음과 같이 5가지로 분류됩니다.

4. 이벤트 로그 감사 정책

윈도우 감사 정책은 곧 로그 정책이라고 볼 수 있습니다.
감사 설정을 구성하지 않으면 보안과 관련하여 어떠한 일이 발생하였는지 확인하기 어려운 문제가 발생합니다.

정책을 통해 개체 액세스, 로그온/로그오프, 감사 정책 설정 변경 등의 보안 로그를 기록하며,
지정한 이벤트 범주의 사용자나 시스템 동작을 기록하도록 정책 설정이 가능합니다.

로컬보안설정을 통해 감사 정책을 확인하기 위해서는
“[시작] → [제어판] → [관리도구] → [로컬 보안 정책] → [로컬 정책] → [감사 정책]” 선택 후,
각 감사를 클릭하여 ‘성공’, ‘실패’에 관한 감사를 설정할 수 있습니다.

레지스트리를 통해서도 감사 정책을 확인할 수가 있는데요,
저장 및 관리 되는 위치는 아래와 같습니다.

아래 내용은 Windows Vista/2008/7 의 감사정책 구성과 기본 값입니다.

출처 : http://www.kazamiya.net/files/PolAdtEv_Structure_en_rev2.pdf

출처 : http://www.kazamiya.net/files/PolAdtEv_Structure_en_rev2.pdf

5.보안감사 이벤트 설명

기존 Evt 형태의 이벤트 로그에서 운영체제의 업그레이드와 함께 새로운 이벤트 로그 Evtx가 등장합니다.
실제 로그 파일의 헤더 및 구성도 다수 변경이 이루어졌는데요,
상세한 내용은 차후에 다시 설명드리기로 하며 이 포스트에서는 이벤트 ID에 대해 다루어 보겠습니다.

이벤트 로그에서는 이벤트 행위에 대해 특정 숫자 값을 지정하여 관리하고 있습니다.
이것이 이벤트 로그에 있어 가장 중요한 이벤트 ID 인데요, 이 값 역시 Vista 이전과 이후로 나뉘어 상이하게 변경됩니다.
가장 손쉽게 매칭할 수 있는 방법은 Evt 사용 이벤트 ID 값에 4096 값을 더하면 Evtx 형태의 이벤트 ID값이 되며,
실제 상당수 이벤트가 이 조건을 만족합니다.

6. 참고

Security Audit Events for Windows 7 and Windows Server 2008 R2
http://www.microsoft.com/en-us/download/details.aspx?id=21561

Description of security events in Windows 7 and in Windows Server 2008 R2
https://support.microsoft.com/ko-kr/kb/977519

윈도우 이벤트 로그 분석가이드 [비공개 자료]

Windows XP에서 이벤트 뷰어의 이벤트 로그를 보고 관리하는 방법
https://support.microsoft.com/ko-kr/kb/308427

EVTX and Windows Event Logging
http://www.sans.org/reading-room/whitepapers/logging/evtx-windows-event-logging-32949

https://www.digitalocean.com/community/tutorials/how-to-install-elasticsearch-logstash-and-kibana-4-on-ubuntu-14-04

There are a few concepts that are core to Elasticsearch. Understanding these concepts from the outset will tremendously help ease the learning process.

아래의 몇가지 개념들을 이해한다면 매우 쉽게 시작할 수 있다.

Near Realtime (NRT)

Elasticsearch is a near real time search platform. What this means is there is a slight latency (normally one second) from the time you index a document until the time it becomes searchable.

Elasticsearch는 거의 실시간 플랫폼이다. 이 말은 검색하는 시간 만큼 늦어지지만 거의 실시간 이라고 할 수 있다.

Cluster

A cluster is a collection of one or more nodes (servers) that together holds your entire data and provides federated indexing and search capabilities across all nodes. A cluster is identified by a unique name which by default is "elasticsearch". This name is important because a node can only be part of a cluster if the node is set up to join the cluster by its name.

Make sure that you don’t reuse the same cluster names in different environments, otherwise you might end up with nodes joining the wrong cluster. For instance you could use logging-dev, logging-stage, and logging-prod for the development, staging, and production clusters.

Note that it is valid and perfectly fine to have a cluster with only a single node in it. Furthermore, you may also have multiple independent clusters each with its own unique cluster name.

Cluster는 하나 , 더 많은 노드들로 부터 오는 데이터를 하나로 묶을 수 있도록 해준다. 그리고 인덱싱을 여러 노드들을 합쳐서 제공하므로 모든 노드들을 검색 할 수 있게 된다.  Cluster 는 default로 "elasticsearch"라고 정의 된다. 이것이 왜 중요하냐면, 노드들은 cluster이름을 통해 조인할 수 있기 때문이다. Cluster는 다른 이름으로 정의 할 수 있다. 

Node

A node is a single server that is part of your cluster, stores your data, and participates in the cluster’s indexing and search capabilities. Just like a cluster, a node is identified by a name which by default is a random Marvel character name that is assigned to the node at startup. You can define any node name you want if you do not want the default. This name is important for administration purposes where you want to identify which servers in your network correspond to which nodes in your Elasticsearch cluster.

A node can be configured to join a specific cluster by the cluster name. By default, each node is set up to join a cluster named elasticsearch which means that if you start up a number of nodes on your network and—assuming they can discover each other—they will all automatically form and join a single cluster named elasticsearch.

In a single cluster, you can have as many nodes as you want. Furthermore, if there are no other Elasticsearch nodes currently running on your network, starting a single node will by default form a new single-node cluster named elasticsearch.

노드는  cluster의 부분이며, 데이터를 저장하고, 클러스터의 인덱싱과 search 기능을 제공하는 서버이다. 클러스터 처럼 노드 역시 이름을 정할 수 있다.

Index

An index is a collection of documents that have somewhat similar characteristics. For example, you can have an index for customer data, another index for a product catalog, and yet another index for order data. An index is identified by a name (that must be all lowercase) and this name is used to refer to the index when performing indexing, search, update, and delete operations against the documents in it.

In a single cluster, you can define as many indexes as you want.

Type

Within an index, you can define one or more types. A type is a logical category/partition of your index whose semantics is completely up to you. In general, a type is defined for documents that have a set of common fields. For example, let’s assume you run a blogging platform and store all your data in a single index. In this index, you may define a type for user data, another type for blog data, and yet another type for comments data.

Document

A document is a basic unit of information that can be indexed. For example, you can have a document for a single customer, another document for a single product, and yet another for a single order. This document is expressed in JSON (JavaScript Object Notation) which is an ubiquitous internet data interchange format.

Within an index/type, you can store as many documents as you want. Note that although a document physically resides in an index, a document actually must be indexed/assigned to a type inside an index.

Shards & Replicas

An index can potentially store a large amount of data that can exceed the hardware limits of a single node. For example, a single index of a billion documents taking up 1TB of disk space may not fit on the disk of a single node or may be too slow to serve search requests from a single node alone.

To solve this problem, Elasticsearch provides the ability to subdivide your index into multiple pieces called shards. When you create an index, you can simply define the number of shards that you want. Each shard is in itself a fully-functional and independent "index" that can be hosted on any node in the cluster.

Sharding is important for two primary reasons:

The mechanics of how a shard is distributed and also how its documents are aggregated back into search requests are completely managed by Elasticsearch and is transparent to you as the user.

In a network/cloud environment where failures can be expected anytime, it is very useful and highly recommended to have a failover mechanism in case a shard/node somehow goes offline or disappears for whatever reason. To this end, Elasticsearch allows you to make one or more copies of your index’s shards into what are called replica shards, or replicas for short.

Replication is important for two primary reasons:

To summarize, each index can be split into multiple shards. An index can also be replicated zero (meaning no replicas) or more times. Once replicated, each index will have primary shards (the original shards that were replicated from) and replica shards (the copies of the primary shards). The number of shards and replicas can be defined per index at the time the index is created. After the index is created, you may change the number of replicas dynamically anytime but you cannot change the number shards after-the-fact.

By default, each index in Elasticsearch is allocated 5 primary shards and 1 replica which means that if you have at least two nodes in your cluster, your index will have 5 primary shards and another 5 replica shards (1 complete replica) for a total of 10 shards per index.

Each Elasticsearch shard is a Lucene index. There is a maximum number of documents you can have in a single Lucene index. As of LUCENE-5843, the limit is 2,147,483,519 (= Integer.MAX_VALUE - 128) documents. You can monitor shard sizes using the _cat/shards api.

출처: http://asuraiv.blogspot.kr/2015/08/elasticsearch-logstash-elasticsearch.html

Elasticsearch output Plugin

Elasticsearch의 output 플러그인은 'node', 'transport', 'http' 의 3가지 프로토콜이 있다.
여기서는 Elasticsearch 클러스터의 9200번포트로 직접 접속하여 데이터를 전송하는 방식인 'http' 프로토콜을 통해서, Logstash와 연동해보도록 한다.


1. 기초

아래와 같은 클러스터 구조가 있다.

일단 간단하게 stdin 으로 json 데이터를 입력받고, Elasticsearch에 색인하는 작업부터 해보겠다.

logstash.conf 파일은 아래와 같이 작성한다.

input {
        stdin {
                codec => json
        }
}

output {
        elasticsearch {
                host => "localhost"
                index => "school"
                index_type => "students"
                protocol => "http"
        }
        stdout {
                codec => rubydebug { }
        }
}

위와 같이 output 설정에 elasticsearch { } 를 작성하고, 중괄호 안에 각종 설정을 세팅한다. protocol은 'http' 로 작성한다. 이 protocol을 생략하게되면 default 설정인 'node'로 세팅되는데, 이 프로토콜은 로그스태쉬를 하나의 node로 실행시켜, 색인작업을 하고자 하는 elasticsearch cluster에 합류시킨다.

일단 지금은 http 프로토콜을 사용한다 host, index, index_type 등의 설정은 localhost의 elasticsearch 서버로, shcool이라는 인덱스의 students 타입에 데이터를 색인 시키는 설정이다.

입력된 값들이 제대로 인식이 되었는지 확인하기 위해서, stdout 설정도 추가하였다.

실행시켜본다.

./logstash -f logstash.test.conf
Logstash startup completed

그리고 { "class" : "A", "name" : "john" } 를 입력해보자

{ "class" : "A", "name" : "john" } ## 입력
{ ## 여기서부터 stdout rubydebug codec에 의해 출력되는 부분.
         "class" => "A",
          "name" => "john",
      "@version" => "1",
    "@timestamp" => "2015-08-07T07:11:41.975Z",
          "host" => "cweb02.ami",
     "@metadata" => {
        "retry_count" => 0
    }
}

출력을 보니 제대로 색인이 된것 같다.
head 플러그인 화면으로 가서 확인해보자.

curl -XPUT 'localhost:9200/_template/school?pretty' -d '{
    "template" : "school",
    "settings" : { "index.refresh_interval" : "5s" },
    "mappings" : {
        "students" : {
            "properties" : {
                "class" : { "type" : "string", "store" : "yes", index : "not_analyzed" },
                "name" : { "type" : "string",  "store" : "yes" },
                "address" : { "type" : "string",  "store" : "yes" }
            }
        }
    }
}'

elasticsearch {
                host => "localhost"
                index => "school"
                index_type => "students"
                protocol => "http"
                template_name => "school" # 바로 여기 설정
        }
}

자, 다시 Logstash를 실행시키고 { "class" : "A", "name" : "iron man", "address" : "newyork" } 와 같은 데이터를 입력한다

{ "class" : "A", "name" : "iron man", "address" : "newyork" }
{
         "class" => "A",
          "name" => "iron man",
       "address" => "newyork",
      "@version" => "1",
    "@timestamp" => "2015-08-07T07:50:33.537Z",
          "host" => "cweb02.ami",
     "@metadata" => {
        "retry_count" => 0
    }
}

템플릿대로 document가 색인되었는지 head플러그인에서 확인해보자.

아래는 템플릿을 사용하지 않았을때와 사용했을때의 인덱스 메타데이터의 차이이다.

1) 템플릿을 미적용한 경우

Elasticsearch의 기본 idea는 realtime 으로 document를 색인하는것이다. 따라서 동적으로 인덱스와 타입이 생성된다. 위의 경우는 정해진 스키마없이 동적으로 인덱스와 타입이 생성된 경우이며 dynamic_templates 라는 기본 템플릿이 적용된다.

2) 템플릿을 적용한 경우

위의 경우는 템플릿을 적용한 경우이다. 위에서 생성한 템플릿의 필드설정대로, 'class' 필드는 index 설정이 'not_analyzed'로 되어있다. 템플릿이 정상적으로 적용되어 데이터가 색인되었다는 증거다.