self study

- Live Response

 ● 활성화된 시스템에서 휘발성 정보를 수집하는 것을 말함.

 ● 시스템이 꺼지게 되면 휘발성 정보는 날아가기 때문에 OOV(Order Of Volatility)를 고려하여 정보를 수집한다.

- OOV(Order Of Volatility) [RFC 3227](http://www.ietf.org/rfc/rfc3227.txt)

 ● 레지스터, 캐시

 ● 네트워크 연결 정보

 ● 프로세스 목록, 커널 통계정보, 메모리

 ● 임시 파일, 열린 파일 목록

 ● 로그, 사용자 정보

 ※ 꼭 정해진 순서는 없다. 상황에 따라 정보를 수집해야 한다.

- Live Response 조사시 유의할 점

 ● 로카르트의 교환법칙

   ◇ 두 객체가 접촉하면 반드시 무언가가 교환된다.

   ◇ 이 법칙은 Live Response 시 정보를 수집하기 위해 프로그램을 실행한다던지 로그인을 한다던지 등의 행위들에 따라 시스템에 영        향을 줄 수 있다. 이러한 행위 때문에 중요한 정보들을 잃을 수 있으므로 시스템에 영향을 최소화 하는 방식으로 Live Response를        수행해야 한다.

   ◇ 메모리, 네트워크, 프로패치 파일, 시스템의 레지스트리(접근시간 변경), 시스템의 DLL(접근시간 변경), 로그파일 등 영향을 미칠         수 있다.

 ※ 관리자 권한을 얻기 위해 다시 시스템에 로그인 하는 것은 잘못된 방법이다. 이유는 로그오프하고 다시 로그인을 하게 되면 해당 세션의 휘발성 정보를 잃게 된기 때문이다. 오 놀라워라.... 따라서 이 분은 윈도우에서 runas와 같이 리눅스에 sudo?나 su?처럼 일시적으로 관리자 권한을 얻어 프로그램을 실행시킬 수 있는 명령어를 추천했다.

- Live Response 휘발성 정보 수집

 ● 시스템 시간

   ◇ 해당 시스템의 시간 정보를 수집하고 윈도우 명령어를 통해 레지스트리에 기록이 남지 않도록 할 수 있다.

 윈도우 명령어 : date /t & time /t

 출력 : 2013-10-19

    오후 8:56

 ● 네트워크 연결 정보

   ◇ 방화벽이 있다면 방화벽 로그를 수집해야 한다. 방화벽엔 휘발성인 세션로그와 커스터마이징 할 수 있는 로그가 따로 있다. 세션로

 그는 방화벽에 붙은 세션정보를 일시적으로 볼 수 있기 때문에 먼저 수집하는 것이 좋다. 그리고 커스터마이징 할 수 있는 로그 차  단로그를 많이 쓴다고 알고 있다.(예전 일할 때 차단로그를 주로 사용) 방화벽에 의해 허용 및 차단 로그를 모두 저장하게 된다면 방  화벽 부하가 크기 때문에 서비스의 문제가 생길 수 있어서 차단된 로그만 저장한다고 알고 있다. 룰에 의해 차단된 로그를 확인하여  의심할 만한 정보를 수집할 수 있을 것이다. 또한 해당 시스템의 네트워크 정보를 알아보기 위해 netstat 윈도우 명령을 이용하여 네  트워크 정보를 수집한다. 옵션이 너무 많아 스스로 보는것이 중요하다 생각한다.

 ● 프로세스 목록

   ◇ 프로세스 목록을 수집하여 해당 시스템에서 어떠한 행위가 일어났는지 확인해 봐야한다. tasklist 명령이나 SysInternalSuite에서 제공하는 Pslist를 많이 사용한다. PID, PPID를 통해 의심이 될만한 정보를 찾는 경우도 있고, 숨겨진 프로세스를 찾아내야 하는 경우도 있다.

 ● 핸들 정보

   ◇ 핸들에 경우 개인적으로 공부를 해보았다. 핸들이 무엇이고 이 핸들을 통해서 무엇을 알아야 하는지가 중요하다 생각했다.

 핸들은 응용프로그램이 시스템 자원(커널 오브젝트)에 접근할 수 있도록 하게 하는 것을 말한다. 응용프로그램은 시스템 자원에 직  접 접근이 불가능하기 때문이다. 윈도우에서 내부적으로 오브젝트를 직접 접근할 수 있도록 테이블을 만들어 이 테이블의 인덱스  값을 이용하도록 했다. 그리고 이를 확인하기 위해서는 커널 디버깅을 통해서 확인할 수 있는데 밑에 슬라이드에서 자세한 내용이  나와있다.

 (http://www.slideshare.net/JoosaengKim/windows-handle-2-24604055)

 그리고 핸들이 실제로 가리키고 있는 오브젝트는 레지스트리에 기록이 되어 있어서 SysInternalSuite에서 만든 Handle.exe를 통해  레지스트리 정보 수집을 할 수 있다.

[그림 1] 응용프로그램과 커널오브젝트 관계도 

(http://www.hauri.co.kr/customer/security/colum_view.html?intSeq=107&page=1)

   ◇ 커널 오브젝트는 다른 프로세스와 공유가 가능하기 때문에 이를 악용하면 다른 정상적인 프로세스를 제어하는 악성코드가 발생할        수 있다. 이것 뿐만아니라 다른 측면에서도 필요한 정보일 수도 있는데 이 부분은 점차 공부하면서 알아보도록 하겠다.

 ● DLL 목록

   ◇ http://blog.naver.com/PostView.nhn?blogId=process3&logNo=20017834792

   ◇ http://blog.naver.com/PostView.nhn?blogId=bolin1479&logNo=80154007392

   ◇ http://mayu.tistory.com/9

   ◇ http://www.reversecore.com/40

   ◇ DLL이 무엇이고 DLL Injection 관련한 내용이 있는 사이트를 링크시켜 놓았다. DLL Injection이나 7.7 DDoS와 같이 서비스로 등록하여 실제 구동되는 DLL파일 등 DLL 관련하여 침해사고가 발생되곤 한다. DLL과 관련된 침해사고라면 프로세스에서 사용되는 DLL 목록을 수집해야 한다. DLL 목록을 수집하기 위해 SysInternalSuite에서 만든 ListDlls.exe 도구가 있다.

 ● 로그온 사용자 정보

   ◇ 원격에서 로그온 한 사용자, 로컬 로그온 사용자 정보를 확인해야 한다.

 명령어 : net session(원격 로그온 사용자)

 SysInternalSuite : psloggedon(원격&로컬 사용자), Logonsession(원격&로컬 사용자, 해당 사용자가 실행한 프로세스 목록 출력)

 ● 파일 핸들

   ◇ 보류...공유폴더까지....

 ● 히스토리

   ◇ 명령 프롬프트에서 사용된 명령어들을 수집하는 것이다. 참고로 명령 프롬프트가 닫히면 그 전 정보들은 사라진다.

 ● 윈도우의 서비스 정보

   ◇ 악의적인 서비스가 등록 되었는지 확인해야 한다. 서비스 목록을 얻기 위해 SysInternalSuite의 Psservice.exe를 사용한다.

 ● 시작 프로그램 목록 정보

   ◇ 시스템이 부팅할 때 자동적으로 시작되는 프로그램이 있는데 악성코드 경우 이를 많이 활용한다. 레지스트리에 등록되어 있는데 이를 출력하기 위해 사용되는 툴은 SysInternalSuite의 autorunsc.exe가 있다.

 ● NetBios 정보

   ◇ NetBios는 근거리 데이터 통신을 위한 것으로 TCP/IP 기반으로 통신이 이루어진다. 상대방과 데이터를 교환할 경우 600초 동안 테이블 형태로 생성이 되고 이를 Cached NetBios Name Table이라고 한다. 또한 NetBios에서 세션모드, 데이터그램 모드가 있으며 세션모드는 연결성립, 메시지 처리를 하고 데이터그램 모드는 응용 프로그램이 통신 에러의 발견 및 회복을 수행, 브로드캐스트 지원을 한다.

침해사고 시 근거리 네트워크 정보를 수집할 수 있다.

 명령어 : nbtstat [옵션]

 ● 프로세스 메모리

   ◇ 프로세스의 가상 메모리를 뜻하며 해당 프로세스가 어떤일을 하는지 분석할 수 있도록 덤프를 떠야한다. MS사에서 제공하는              userdump.exe가 있고, 단 해당 프로세스가 정지하고 있어야 정확한 덤프가 가능하다는 점이 단점이다.

- 마지막으로

 ● 이 뿐만아니라 여러가지 방법으로 여러가지 정보를 더 얻을 수 있다고 생각한다. 아직 부족한 실력이라 책을 중점적으로 다루면서 공부를 했지만 다소 아쉬운 점이 많다. 현재 배치스크립트를 아주 간단하게나마 작성했는데 집에가서 문제를 한 번 풀어보면서 실습을 해봐야겠다...

디지털 포렌식의 세계라는 책을 가이드로 시작해보려 합니다. 간단하게 정리해보려 합니다.

- 디지털 포렌식 증거처리 절차

 ● 사전준비 -> 증거수집 -> 증거이송 -> 증거분석 -> 정밀검토 -> 문서화

- CoC(Chain of Custody)

 ● 사건의 증거가 수집한 상태에서 법정에서까지 변경이 되지 않았음을 보이기 위한 절차적인 방법

(A chain of custody is the accurate documentation of the movement and possession of a piece of evidence, from the time it is taken into custody until it is delivered to the court)

- E-Discovery

 ● 전자 포맷의 문서를 재판에서 사용될 증거로 수집하여 제출하는 것을 말함

- EDRM(Electronic Discovery Reference Model)

 ● E-Discovery의 참조모델이다. 점진적으로 각 단계를 수행하고 필요시 다시 전 단계로 돌아가 수행하기도 함.

[그림 1] EDRM (www.edrm.net)

  1. 정보관리(Information Management) : 증거개시가 요청되기 전 미리 필요한 정보를 준비하는 단계

  2. 식별(Identification) : 사건과 관계된 가능성이 있는 증거들을 식별하는 단계

  3. 보존(Preservation) : 증거들의 훼손 및 변조되지 않도록 보증하는 단계

  4. 수집(Collection) : E-Discovery 절차에 따라 무결성을 유지된 채 증거를 수집하는 단계

  5. 처리(Processing) : 수집된 증거들에 대해 필요시 결합하고, 더욱 적합한 검토와 분석을 할 수 있도록 데이터를 처리하는 단계 

  6. 검토(Review) : ESI의 타당성과 권한을 평가하는 단계(일반적으로 법률 관계자가 수행함)

  7. 분석(Analysis) : 증거들에 대해 컨텐츠, 문맥 등을 추출하여 평가하는 단계

  8. 제작(Production) : 증거들을 적합한 전달 과정을 이용하여 소송 당사자들에게 제작&제출하는 단계

  9. Presentation : 소송 당사자들에게 증거에 따른 사건 전황에 대해 보여주는 단계

- 디지털 포렌식 준비도(Digital Forensic Readiness)

 ● 신뢰할 수 있는 증거 수집 환경의 능력을 최대화하고 사고 대응 비용을 최소화하기 위한 제도

Shuffle job log 분석

- FIle Output Format Counters

Bytes Written - output의 데이터 크기

- Map-Reduce FrameWork

Reduce input groups - 리듀스에 도착한 그룹들을 말하며, 하나의 그룹은 하나의 키로 이루어진 그룹을 말함

Reduce input records - 리듀스에 도착한 그룹으로 볼 수 있으나, 키는 같아도 value값에 따라 나누어진 record이기 때문에 input group보다 수가 많거나 같을 수 있다.

ex)  a    4                                

b    5                        -> 각 스플릿 결과에 따라 나온 결과들이기 때문에 키가 같을 수 있다. Reduce input records는 4가 되고, 이를 키들로 

c    6                            묶게 되면 Reduce input groups가 된다.

a    2

Spilled Records - shuffle&sort  후 버퍼에 남아있거나 버퍼 임계값이 넘쳐 local disk에 쓰여진 temporary output으로 각 map task들이 스플릿을 처리한 output의 record들의 수를 말함.(어찌보면 Reduce input records와 수가 같다.)

Physical Memory (bytes) snapshot - ?

Virtual Memory (bytes) snapshot - ?

매우 단순할 것 같다 ? 답은...하지만 왜이리 찾기가 힘드노...

우연히 여기 방문하셔서 보신다면 댓글 부탁점....

1. 맵리듀스가 무엇인가?

 - 분산된 수많은 노드에 대용량 데이터 처리를 수행함으로써 배치 작업, 관리하는 프레임워크이다. 

2. 맵리듀스 이전 데이터 처리 방식의 한계

 - 데이터를 분석하는데 병렬로 수행한다고 가정한다면 이러한 문제점이 있다.(맵리듀스 사용하지 않을 경우)

  1) 파일크기에 따라서 몇몇 프로세스 처리가 빠른 경우가 있고 느린 경우가 있을 것이다. 빠른 경우엔 추가로 다른 일을 할 순 있겠지만 결국엔 가장 큰 파일에 의해 처리 수행속도가 판가름 날 것이다.

  2) 결과를 조합하는데 있어서 더 많은 처리가 필요할 수 있다. 예를들면 연도별로 데이터를 나누는데 이를 정렬시키고 조합시키는데 처리가 더 필요하다는 것이다.

  3) 단일 서버의 처리 능력은 한계가 있다.

3. 맵리듀스 이해

 1) 간략한 맵리듀스 동작

그림 1) 맵리듀스 동작

(http://withfriendship.com/user/mithunss/mapreduce.php)

 - 위 그림은 맵리듀스를 이해하는데 있어 좋은 예제인 것 같아 퍼오게 되었다. 먼저 맵함수에 들어가기전에 각각 다른 모양과 색깔을 가진 도형들이 있다. 맵함수에서는 같은 도형의 수와 서로다른 도형들을 분류 및 정렬한다. 그리고 맵함수에 출력물을 가지고 리듀스함수에 입력에 사용하여 결과를 나타낸다. 

 헷갈리신다면 도형들을 한 문장으로 생각해도 좋다. 예를 들어 '나의 성격은 나의 행위의 결과이다.'의 문장을 도형의 묶음으로 보고 나의, 성격은, 나의, 행위의, 결과이다 각각 단어를 하나의 도형으로 보면 된다. 구글에서는 이를 이용해서 엄청난 양의 데이터를 처리하여 서비스 한다. 그만큼 맵리듀스는 분산환경 및 대용량 데이터를 처리하는데 효과적인 프레임워크라고 생각한다.

깊은 내용은 각자 서치로^^

 2) 데이터 흐름

 - 두가지 유형 노드

   (1) 잡 트래커 : 태스크트래커들이 수행할 태스크들을 스케줄링하여 시스템 전체에 모든 잡들이 수행되도록 조절함

   (2) 태스크트래커 : 태스크들을 수행하고 각 잡의 전체 경과를 하나의 레코드로 유지하는 경과 보고서를 잡트래커에 보낸다.

그림 2) 다중 리듀스 태스크의 맵리듀스 데이터 흐름

(http://ypshin.com/2690309)

 - 하둡은 맵리듀스의 잡의 입력을 스플릿이라 불리는 고정 크기 조각들로 나눈다. 하둡은 각 스플릿마다 하나의 맵 태스크를 생성하고, 그 스플릿에 있는 각 레코드를 사용자 정의 맵 함수로 처리한다.

 - 맵 태스크의 결과는 HDFS가 아닌 로컬 디스크에 저장된다. 이유는 맵의 결과는 중간결과물일 뿐 잡이 완료되면 맵의 결과는 필요가 없어지기 때문이다. 그리고 만약 맵 태스크를 실행하는 노드가 리듀스에 의해 맵의 결과를 사용하다 실패하면 하둡은 다시 맵 태스크를 또 다른 노드로 전달하여 맵의 출력을 재생성한다.

 - 리듀스 태스크는 맵함수의 출력으로 입력을 받는다. 리듀스의 출력에 대한 각 HDFS 블록은 첫 복제본이 로컬 노드에 저장되고, 그 이외의 복제복은 자신이 속해있지 않은 곳에 저장된다.(이래서 지워야할 해당 데이터들을 찾기가 어렵다는 뜻인가...)

1. 분산 코디네이터

1) 분산 락이나 동기화 문제

• 접근방법
  (1) NFS 같은 파일 공유 서비스 이용 : 모든 서버에 특정 디렉토리를 마운트 시키고 파일 락을 이용
  (2) DB 이용 : 레코드 락을 이용하여 락을 획득한 서버만 자원에 접근하게 함
  

• 단점
  둘 다 락 요청이 많아지면 서버에 부하가 집중되어 SPOF(Single Point Of Failure)가 될 수 있다.

2) 이중화

 - 고가용성을 위해 서버를 이중화 구성을 많이 한다. Active-Active, Active-Standby로 구성된다. 영어 단어처럼 활동하는 서버, 대기 서버라고 보면 된다.

3) 주키퍼(야후의 분산 코디네이터)

 - 분산 환경에서 코디네이터 서비스를 제공하는 아파치 오픈소스이다.

 - 네임 서비스, 환경설정, 그룹 멤버십, Double Barriers, 우선순위 큐, 공유 락 제어, 두 단계 커밋, 리더 선출 

 - 위와 같은 기능을 제공하는 것이 아니라 이런 기능을 쉽게 만들 수 있도록 메카니즘을 제공

 - 하둡과는 연관이 없음

 - 구글의 처비를 많이 참고했다고 알려짐

그림 1) 주키퍼 시스템 구성

(http://creatorw.tistory.com/tag/%EC%A3%BC%ED%82%A4%ED%8D%BC)

 - 주키퍼 서버는 데이터를 파일 트리노드와 같이 계층적으로 저장하고, 저장된 데이터는 주키퍼 서버들 사이에 복제되어 일부 서버가 장애를 발생해도 서비스를 계속해서 할 수 있음(데이터는 서버상태, 락 정보, 환경설정 정보 등과 같은 크기가 작은 메타데이터를 주로 저장)

 - 클러스터는 항상 3대 이상의 서버로 구성되야 함(분산시스템 시간에 배웠는데 까먹었다....) 아마 장애 발생 관련 이유일 것이다...

그림 2) 주키퍼 데이터 모델

(http://creatorw.tistory.com/53)

 - 파일 시스템은 로컬에 저장되어 있거나 마운트 되어 있는 파일과 디렉토리에 대한 접근을 수행하지만, 주키퍼는 클라이언트 라이브러리를 이용하여 네임스페이스에 대한 조회, 노드에 저장된 데이터를 원격 클라이언트에서도 접근할 수 있는 분산 시스템이다. 또한 데이터는 메모리에 존재하나 로그와 스냅샷 파일은 로컬 디스크에 저장된다. zoo.cfg에서 로그와 스냅샷을 로컬 어디에 저장할지 설정할 수 있다.

4) 주키퍼 예제

- zookeeper라이브러리 하나만 추가를 했는데 에러가 났다. 그래서 thrift때 사용하던 라이브러리 몇개를 추가시키니 실행이 되었다. log4j, slf4j-api, slf-log4j......

5) 정합성(Consistency)

 - DB는 정합성을 만족해야 한다.

  정합성이란? 모든 클라이언트는 항상 동일한 데이터를 보장받는 것을 의미한다.

  하지만 분산 서버에 데이터가 저장된 후 처리결과를 보내는 강한 정합성(빠르게 처리결과를 보여줌)이 아닌 이벤추얼(Eventual) 정합성을 갖고 있다. 이벤추얼 정합성은 수밀리 초내로 처리결과를 보여주는 것이 아니라 시간은 조금 늦으나 결과는 같아져 동일한 데이터를 보장할 수 있도록 하는 개념이다.

6) 크롤링이란? 최신 상태의 페이지를 유지하기 위해 웹을 탐색하는 것을 말한다.

http://v.daum.net/link/16695860