30 Aug 2020

[Project] Linux 취약점 진단 및 평가와 로깅

목차

1. 프로젝트 개요

   1.1. 프로젝트 목적

   1.2. 프로젝트 아키텍처

   1.3. 취약점 분석 평가 항목

2. 프로젝트 구현

   2.1. 스크립트 디렉토리 구조

   2.2. 스크립트 실행

   2.3. Kibana 대시보드 커스터마이징

3. 결론


1. 프로젝트 개요


1.1. 프로젝트 목적

본 프로젝트는 KISA에서 작성된 주요정보통신기반시설 기술적 취약점 분석 평가 상세 가이드 문서를 참고하여 기술적인 취약 여부를 검사함으로써 악성코드 유포, 해킹 등 사이버 위협에 대응하기 위해 시작하게 된 프로젝트이다.

가이드의 문서를 숙지하기 어려운 부분이 많기 때문에 보안 담당자들이 취약점 점검을 자동으로 손쉽게 취약점 진단을 진행할 수 있도록 운영체제 취약점 진단 자동화 스크립트를 개발하고 배포한다.

취약점 점검을 손쉽게 진행할 수 있도록 자동화 스크립트를 개발하고 진단 결과를 한 눈에 확인할 수 있도록 가시화된 데이터를 제공하는 것을 목표로 한다.


1.2. 프로젝트 아키텍처

다음 [그림 1]은 진단 스크립트를 실행하는 것부터 Kibana에서 로그를 확인하는 일련의 과정을 테스트하기 위한 환경을 아키텍처로 나타낸 것이다.

project_architecture
[그림 1] 프로젝트 아키텍처


테스트는 Virtualbox에서 진행되었으며, ELK Stack이 설치되어 있는 VM과 진단할 여러 대의 VM을 구성하여 테스트까지 진행했다.

명령어 하나로 [그림 1]의 과정이 모두 진행되며, 스크립트를 실행하는 명령어의 매개변수에 입력되는 노드들까지 모두 취약점 진단이 되어 Kibana에서 진단 결과를 확인할 수 있다.


1.3. 취약점 분석 평가 항목

취약점 분석은 CentOS 7 환경에서 진행되며 항목 중요도가 상인 진단 항목을 몇 가지 선택하여 진단 스크립트를 작성했다.

본 프로젝트에서 선택한 진단 항목은 다음 [그림 2]와 같다.

analysis_list
[그림 2] 진단 항목 리스트


2. 프로젝트 구현


2.1. 스크립트 디렉토리 구조

[son@elk linux_diagnosis]$ tree .
.
├── lib
│   ├── diagnosis_1
│   ├── diagnosis_2
│   └── function
├── log
│   └── diagnosis_script.debug
├── main_diagnosis.sh
└── U-13_filelist

2 directories, 6 files


본 프로젝트에서 취약점을 진단하기 위해 사용되는 스크립트의 디렉토리 구조를 나타낸다. 각 파일들에 대한 설명은 다음과 같다.

  • lib/diagnosis_1 : KISA 가이드 문서의 ‘계정 관리’ 진단 부분을 실행하는 파일
  • lib/diagnosis_2 : KISA 가이드 문서의 ‘파일 및 디렉토리 관리’ 진단 부분을 실행하는 파일
  • lib/function : 스크립트를 실행하면서 남겨지는 로그와 Elasticsearch로 데이터를 전송할 때 필요한 함수들을 정의한 파일
  • log/diagnosis_script.debug : main_diagnosis.sh 스크립트에서 실행되는 명령어와 실행 결과를 기록한 파일
  • main_diagnosis.sh : 취약점 진단을 위한 스크립트 실행 파일
  • U-13_filelist : U-13 항목에서 진단할 파일 리스트를 작성한 파일


2.2. 스크립트 실행

취약점 진단에는 시스템 파일을 확인하는 경우가 많기 때문에 root로 실행하거나 sudo를 앞에 삽입하여 실행하도록 구현했다.

다음 [그림 3]은 일반 유저로 스크립트를 실행했을 때의 결과이다.

failed_execute
[그림 3] 일반 유저의 스크립트 실행 실패


스크립트가 재대로 실행되었을 때의 화면은 다음 [그림 4]와 같이 출력된다.

succeed_execute
[그림 4] 정상적인 스크립트 실행 결과


root 권한과 함께 스크립트를 실행하면 정상적으로 취약점 진단이 실행되며, 항목 코드 별로 진단 결과가 출력된다.

[Good]은 해당 항목에서 진단한 결과가 양호하다는 것이다.

[Weak]는 진단 결과가 취약하게 나왔으므로 [Info]를 통해 취약점을 보완해야 함을 의미한다.

이러한 결과 로그는 스크립트 실행과 동시에 Elasticsearch에 전달되어 Kibana에서 확인할 수 있다.


위의 [그림 4]처럼 main_diagnosis.sh를 실행시킬 때 매개변수로 client.cccr.local의 호스트네임을 매개변수로 넣어서 실행시켰을 때 다음의 [그림 5]와 같이 elk.cccr.local 에서의 진단이 끝나면 곧바로 이어서 매개변수에 기입된 호스트에 대한 진단을 진행하게 된다.

execute_with_ssh
[그림 5] ssh를 이용하여 매개변수에 기입된 호스트 진단


마찬가지로 client.cccr.local 호스트의 진단 결과도 Kibana에서 바로 확인할 수 있다.

아래의 [그림 6]은 진단 스크립트를 실행시키면서 실행되는 명령어들이 재대로 수행되는지 xtrace를 통해 디버깅할 수 있도록 만든 것이다.

debug_sample
[그림 6] diagnosis_script.debug 실행 샘플


진단하면서 실행되는 코드는 xtrace를 통해 디버깅해볼 수 있도록 log/diagnosis_script.debug 파일로 저장되어 진단이 끝난 후에 확인해볼 수 있다.

elk.cccr.local, client.cccr.local에서 실행되는 코드 모두 elk.cccr.local 호스트의 log/diagnosis_script.debug 파일을 통해 확인할 수 있다.

그리고 다음 [그림 7]은 다른 호스트까지 원격 진단할 수 있도록 개발한 코드이다.

remote_execute_code
[그림 7] elk.cccr.local에서 다른 호스트로의 원격 진단 코드


예를 들어 $ sudo ./main_diagnosis.sh client 라고 명령어를 입력하면 호스트의 취약점 진단이 끝난 후에 /etc/hosts에 정의된 client 호스트네임을 가진 노드로 진단에 필요한 코드를 전송하여 ssh 접속을 통해 진단을 수행하도록 했다.

output_log_code
[그림 8] 진단 로그 출력과 Elasticsearch로의 로그 전송 코드


위의 [그림 8]은 진단 결과를 출력해주는 진단 로그를 출력해주는 함수와 Elasticsearch로 로그를 전송하는 함수를 정의한 것이다.

콘솔에서 진단 결과를 출력해주는 함수는 print_good(), print_weak(), print_info() 로 정의되어 있고, 콘솔에 출력하는 동시에 Elasticsearch로 로그를 보내게 된다.


2.3. Kibana 대시보드 커스터마이징

Elasticsearch와 Kibana의 설치가 정상적으로 끝나고나면 스크립트를 실행하여 진단 결과 데이터를 Elasticsearch로 전송시켜주면 Kibana에서 인덱스 패턴을 생성할 수 있게 된다.

create_index_pattern
[그림 9] Kibana에서 인덱스 패턴 생성


Kibana에 접속하여 Management > Stack Management > Kibana > Index Patterns 탭에 들어가서 Create index pattern 버튼을 누르면 위의 [그림 9]과 같이 인덱스 패턴을 생성할 수 있는 화면이 나온다.

인덱스 패턴을 정의할 때 해당 패턴에 일치하는 인덱스가 Elasticsearch 내에 존재해야 한다.

본 프로젝트에서는 인덱스 이름을 diagnosis라고 정의하였고, 진단 스크립트가 실행되면서 diagnosis 인덱스에 정형화된 컬럼 필드 내용들이 Elasticsearch로 전송되어 스크립트로 생성된 diagnosis라는 인덱스에 대한 인덱스 패턴을 생성할 수 있게 된다.

인덱스 패턴 이름을 적는 란에 diagnosis* 이라고 입력하여 인덱스 패턴을 생성해준다.


인덱스 패턴을 생성하고 나면 해당 인덱스 패턴에 대한 로그를 확인할 수 있게 되고, 로그는 Kibana > Discover 탭에서 확인할 수 있다.

해당 탭에 들어가면 아래의 [그림 10]처럼 전송된 진단 로그를 확인할 수 있다.

kibana_discover_log
[그림 10] Kibana Discover 로그 확인


스크립트에서 전송되는 로그에 대한 컬럼은 {“timestamp”, “ip_addr”, “hostname”, “os_version”, “vul_item”, “result_code”, “messages”}의 형태로 되어 있다.

취약점 진단 스크립트를 실행을 통해 생성된 로그를 Discover 탭에서 가시화되어 확인할 수 있고, 왼쪽에 필드 내용을 검색해서 데이터를 필터링해서 확인할 수도 있다.

예를 들어, 취약점으로 나온 로그만 확인하고 싶다면 Add filter를 눌러 result_code: Weak를 입력하면 result_code 값이 Weak라고 되어있는 로그들을 쉽게 필터링하여 확인할 수 있다.


다음으로, Kibana에서 로그를 한눈에 확인할 수 있도록 다양한 모형을 통해 로그를 확인해본다.

다음 [그림 11]는 로그를 Visualization하여 확인한 것이다.

kibana_visualize_custom
[그림 11] Kibana Visualize 탭 커스터마이징


Kibana > Visualize 탭에서 로그를 Visualization 할 수 있다.

로그들에 대한 Visualization할 수 있는 모형들이 다양하게 존재하는데, [그림 11]에서 보여지는 모형은 Pie를 사용했으며, 로그 필드는 hostname, result_code, vul_item을 순서로 드래그 앤 드랍하여 커스터마이징 한 것이다.

Pie 뿐만 아니라 Bar, Line, Area, Data table, Metric, Donut, Treemap 등 다양한 모형을 통해 로그를 Visualization 하여 확인할 수 있다.


3. 결론

KISA의 기술적 취약점 분석 평가 상세 가이드 문서를 참고하여 CentOS 환경에서 Bash 스크립트를 기반으로 취약점 진단을 자동으로 진행한 후에 로그를 Elasticsearch에 저장하였고, Kibana를 통해 가시화된 데이터를 확인하고 테스트를 진행한 방식에 대해 기술했다.

취약점 진단 자동화 스크립트를 실행하여 진단 로그를 생성하고, Elasticsearch에 저장한 후에 Kibana에서 각 노드 별로 진단 결과를 한 눈에 확인하는 [그림 1]의 일련의 과정들이 정상적으로 동작되는 것을 확인했다.

다만 개발 기간이 짧아 KISA의 문서에 기술된 진단 항목을 모두 개발하지 못하고 일부만 구현한 부분이 아쉽고 나머지 진단 항목에 대해서는 추가 개발이 필요하다.

그리고 진단 결과 취약하다고 나온 결과에 대해서는 자동으로 조치할 수 있는 스크립트를 개발하는 것도 향후 과제로 남기며 본 포스트를 마친다.


Tags:
0 comments