Containerized Honeypot Managment Framework: Honey-V
본 프로젝트는 2020년 2학기 세종대학교 창의학기제에서 진행하였습니다.
논문에선 말할 수 없었던 허니팟 운영 히스토리에 대해 설명하고자 한다. 기술적인 부분보단 개발기와 운영적인 부분에 대해 주로 초점을 맞춰 설명할 것 같다. (+기술을 살짝 포함한)
Entrypoint
필자가 다니는 학교에는 “창의학기제” 라는 아주 좋은 제도가 있다. 자기주도적인 프로젝트를 하면 학기당 최대 12학점의 전공선택(전선) 학점을 주는 제도인데, 안그래도 초과학기 각이 뜨고 있던 나에겐 아주 감사한 제도였다.
여튼, 동아리원 중에 4명을 모아서 창의학기제 프로젝트를 진행하게 되었다. (최대 인원을 꽉꽉 모았다)
일단 프로젝트가 아니라 사람을 모아서 한 것이라 프로젝트를 정하고 있었고 여러 주제중에 허니팟이 나름 재밌어 보여서 시작하게 되었다.
근데.. 단순히 허니팟만 하면 재미 없어서 어떤 것을 섞어야 시너지 효과를 얻을 수 있을까..? 하던 중에 갑자기 옛날에 친구가 웹 서버가 엄청난 로그 공격을 받았던 (스캔) 기억을 받았다. 그 때 단순히 친구가 샘플 분석하실분 하면서 로그를 공유했는데 이런걸 자동화 시켜서 플랫폼을 만들면 재밌지 않을까 싶어서 시작했다.
결론: 허니팟으로 공격 정보를 수집해서 분석하거나 해독(detoxify) 시키는 학습을 할 수 있는 플랫폼을 만들자.
Honeypot?
허니팟의 정의는 간단하게 하면 “비정상적인 접근을 탐지하기 위해 의도적으로 설치해 둔 시스템” 이다. 이걸 통해서 공격 정보를 수집하고 그 정보를 가지고 차단을 하거나 공격 패턴을 탐지할 수 있었다.
그러나 기존에 공개된 허니팟은 그냥 특정 시스템을 단순히 clone한 시스템에 불과했다. 사실 대부분 일반적인 사람들은 이게 더 필요하긴 했다.
근데 우리가 해야 할 프로젝트에는 특정 시스템이 아니라 우리가 원하는 다양한 시스템을 자동으로 허니팟으로 운영할 수 있도록 해야 했다. 근데.. 없네..?
그럼 뭐다?
만듭시다. 없으면 만들어야지.
Develop
처음부터 애초에 Docker를 사용할 생각을 가졌었다. 여러 허니팟을 한번에 관리하고 일정 시간마다 정상 상태로 되돌릴 수 있는 방법 중에 우리가 현실적으로 선택 가능한 도구는 Docker였다.
다행히도(?) Docker를 매우 사랑해서 오래 사용하고 있던 터라 개발이 크게 어렵지는 않았다. 대신 Go언어로 개발한 것은 처음이라 지금 보면 왜 이렇게 짰을까 싶은 부분이 너무 많다.
나중에 시간이 되면 제대로 리팩토링을 해야 할 것 같다.
Requirements
이 허니팟에서 제공해야 하는 기능은 아래와 같았다.
- 허니팟 네트워크 트래픽 덤프
- 파일 변경 내역
- 이미징 (with 해시값)
- stdout/stderr 값
- 프로세스 정보
- 감염 이전의 값으로 되돌리기 (revert)
생각보다 빡센 것들이 많았다.
Docker API
Docker를 그냥 사용해도 되지만 좀 더 정교한 컨트롤을 위해 Docker Go API를 사용했다. Docker도 Go로 작성된거라 생각보다 쉽게 integrate 할 수 있었다.
근데 제공해야 하는 기능 중에 제일 어려운 부분은 “허니팟 컨테이너 별로 네트워크 트래픽을 어떻게 수집할 것인가?” 였다. 도커 자체 기능을 이용해서 허니팟 컨테이너 별로 가상 네트워크 인터페이스를 할당했지만, 그 이후로 어떻게 패킷을 뜰 수 있는지에 대해서는 생각이 필요했다.
Base Image
허니팟의 기본이 되는 이미지는 2개의 방법 (docker-compose 까지 해서 3개까지 생각했지만 기간 사정상 2개만 가지고 구현했다) 을 통해 제공할 수 있다.
- Official Docker Hub
- Dockerfile
이 정도면 사용자가 customize한 dockerfile을 제공할 수 있으며, 버전별로 기본 이미지를 docker hub에서 받아 사용할 수 있으니 괜찮을 것 같았다.
이 부분은 딱히 문제는 없었지만 그래도 구현에 제일 고생했던 부분이라 한번 써봤다.
Collect the artifacts
아까 “허니팟 컨테이너 별로 네트워크 인터페이스가 있다” 라고 했다. 즉, 해당 네트워크 인터페이스를 모니터링 하면 모든 패킷을 빠짐없이 수집할 수 있다고 생각했다.
근데.. 컨테이너별로 계속 수집기가 돌려면.. 스레드 관리가 되나?
우리에겐 goroutine과 channel이 있사옵니다.
진짜 이거 하나로 모든 걱정이 해결 되었다. (사실 docker의 pcapdump 쪽에서 메모리 이슈가 좀 있긴 했지만 이 문제도 너무 쉽게 해결했다. 나중에 기회가 된다면 패치한 부분을 PR 보내는 것도 괜찮은 것 같다)
너무 쉽게 병렬 프로그래밍이 되었고, 상태 관리나 channel을 통해서 패킷 덤프의 종료 시점과 그 사실을 전달할 수 있었다.
Classification
여튼, 이렇게 수집된 정보들을 가지고 공격이 발생했는지 여부를 확인해야 했다. 그런게 없다면 모든 아티팩트를 저장해야 하는데 이건.. 좀.. 용량 문제가 너무 심각했다.
여러 방법을 생각하다가 아래와 같은 순서로 구분하기로 했다.
- 외부 트래픽이 발생하지 않은 경우 무조건 패스 (공격 시도 조차 없었으므로)
- 허니팟의 base image에서 수집한 정보와 비교하여 다른 점이 있는 경우 추가
- 프로세스의 변경점이 있는 경우 무조건 추가
- 인간의 분류
사실 4번이 제일 현실적인데 3번까지 하면 사실상 허니팟에서 공격 이벤트만 골라서 수집할 수 있었다.
그리고 이 과정에서 추가적인 공격 정보에 대해 태깅 작업도 진행했다.
Compression
이렇게 수집된 아티팩트를 사용자에게 제공하기 위해서는 (비용을 절감하기 위해) 압축은 필수다.
대부분 압축에는 ZIP Compression 을 생각하지만, Go언어에서는 퍼포먼스 이슈가 있다. #20031
처음에 이 이슈를 모르고 그냥 썼는데. 테스트 과정에서 비정상적으로 오래 걸려서 문제가 발생했다.
해결법: tar을 애용하자. 훨씬 빠르다.
Operate
1차 운영은 8월 초부터 9월 말까지 했다. 이 기간동안 운영한 허니팟의 종류는 아래와 같다.
- Nginx
- SSH
- Wordpress
- RDP
- MySQL
- Elasticsearch
- Redis
- Telnet
- Printer Server
위의 허니팟에서 2달동안 총 196건의 공격 이벤트를 수집했다. (중복 제외)
더 많은 공격 이벤트를 수집할 수 있었지만, 기술적 문제보단 서버의 자원이 부족했던 점이 너무 컸다.
그리고 자동화된 봇 친구들의 엄청난 DDoS 공격 덕분에 서버 운영사에서 경고를 먹기도 했다. DDoS에 대한 비용을 더 지불한 덕분에 좋은 샘플을 잘 얻어가게 되었다.
이 기간 이후에도 개선점을 반영하여 2차 운영을 12월 초 까지 했는데 이 기간동안 청구된 비용은 22만원 정도였다. (대부분 트래픽에 대한 비용이다)
Conclusion
이런 프로젝트를 하면서 생각보다 많은 공격이 있는 것을 확인했다.
절대 포트는 함부로 여는 것이 아니다.. 진짜.. 봇들이 너무 많다. 아마 이런 봇들만 없어도 전 세계 트래픽의 상당수는 아낄 수 있을 것 같다. (아마 클라우드 비용도 많이 줄지 않을까 싶다)
나름 해보면서 재밌었고, 무엇보다도 Docker API 사용하면서 이해가 안되는 부분은 Docker 코드를 뜯어보면서 이해하는 과정에서 내부적인 작동 구조에 대해 배운 것이 좋았다.
현재 해당 프로젝트를 특별히 관리는 하고 있진 않다.
아마 수집된 공격 행위 중 좀 괜찮은 애들을 선발해서 동아리 내부 워게임에 공유를 할 것 같다.
끝.
Open Source
필요한 사람이 있을진 잘 모르겠지만 그래도 나름 간단하게 오픈소스를 해봤다.
https://github.com/bunseokbot/Honey-V
Golang을 사용했고, libpcap과 Docker가 설치된 환경에서만 작동한다.
프로젝트의 이름은 Honey-V라고 지었는데 다들 Hyper-V 짝퉁이라고 한다. 지금 보니 그런 것 같다.
Citation
BibTeX
1 | |