다양한 요구 조건에 딱 맞는 오픈소스 보안 솔루션 활용 가이드
ⓒ 공개SW역량프라자 / 2016-12-16
어떠한 회사 또는 조직에서든 운영하고 있는 시스템이나 네트워크에 대한 "보안"은 이제 빠질수 없는 핵심 고려요소가 되고 있다. 따라서, 보안의 조건을 만족하기 위해 적합한 보안 솔루션을 검토하여 도입하는 것은 매우 중요한데, 이때 비용뿐만 아니라 융통성이나 활용성 등의 이유로 오픈소스 솔루션이 대안으로 떠오르고 있다. 본 고에서는 각각의 복잡하고 다양한 각 조직의 요구사항에 대해 오픈소스 보안 솔루션을 어떻게 활용할 수 있는지 살펴보도록 하겠다.
[목차]
- 왜 오픈소스 보안 솔루션을 활용해야 하는가
- 요구 조건에 맞는 툴 활용하기
- 열린 서비스(포트) 및 취약성 빠르게 스캔하기
- 1-1. nmap
- 1-2. 취약성 스캐너 OpenVAS, Nessus
- 보안 이벤트, 효율적으로 모니터링하기
- 2-1. Host 기반의 IDS/IPS, OSSEC
- OTP로 철용성 보안 구축하기
- 3-1. 구글 OTP 구현하기
- L7 DDoS 공격 차단 솔루션, testcookie
- 4-1. testcookie
- (1) 30x와 set-Cookie를 이용한 대응
- (2) Javascript 삽입 및 set-Cookie를 이용한 대응
- 맺음말
- 왜 오픈소스 보안 솔루션을 활용해야 하는가
- 제품에 환경을 맞출 것인가? 환경에 제품을 맞출 것인가?
- 일년만 쓰고 버릴 것인가? 재활용할 것인가?
- 메뉴를 이해할 것인가? 작동원리를 이해할 것인가?
- 횟수에 제한 없이 사용 가능
- 요구 조건에 맞는 툴 활용하기
- 열린 서비스(포트) 및 취약성 빠르게 스캔하기
- 1.1 nmap
- auth : 인증과 관련된 스크립트, anonymous ftp 스캔 등
- discovery : 대상에 대한 깊이 있는 정보를 찾는 스크립트들
- external : 외부의 자원(resources)을 활용한 스크립트들
- intrusive : 대상에 대한 공격 시도를 하는 스크립트들
- malware : 백도어나 악성코드(malware) 점검과 관련된 스크립트들
- Vuln : 알려진 취약성을 점검하는 스크립트들
- 1.2 취약성 스캐너 OpenVAS, Nessus
- 보안 이벤트, 효율적으로 모니터링하기
- 2.1 Host 기반의 IDS/IPS, OSSEC
- OTP로 철옹성 보안 구축하기
- 3.1 구글OTP 구현하기
- L7 DDoS 공격 차단 솔루션, testcookie
- 4.1 testcookie
- (1) 30x와 set-Cookie를 이용한 대응
- (2) Javascript 삽입 및 set-Cookie를 이용한 대응
- 맺음말
활용방안에 대해 본격적으로 살펴보기에 앞서, 왜 오픈소스 보안 솔루션을 활용해야 하는지 체크해 보도록 하자.
아무래도 상용솔루션은 고가이고, 제품의 특성상 유연하게 설정을 변경하는 것이 불가능하다 보니 상용솔루션을 도입하게 되면 솔루션에 맞추어 환경을 변경하여야 하는 일이 발생하기도 한다. 반면에 오픈소스는 약간의 분석만 하고 문서를 살펴보면 각자의 환경에 맞도록 커스터마이징이나 변경이 수월하다. 따라서 각자의 환경에 맞는 설정이 가능해진다.
보안의 환경은 빠르게 변화하다 보니 2-3년만 지나면 기존 기능을 포함하면서 더 다양하고 좋은 성능을 내는 솔루션이 나오게 되고, 또 다른 솔루션을 도입해야 할 경우도 생기게 된다. 그러다 보니, 일부 기능은 중복될 수 밖에 없고, 아직 감가상각도 지나지 않은 보안 장비를 처분하기도 쉽지 않은 것이 사실이다. 그러나 오픈소스를 활용하면 기존 서버나 장비를 다른 용도로 전환할 수도 있고, 또는 업그레이드된 소프트웨어만 다시 설치하여 사용하면 되기 때문에 이런 우려에서 자유로울 수 있다.
상용솔루션의 경우 편리하게 GUI는 제공하지만 이 메뉴를 클릭하거나 선택했을 때 어떠한 원리로 어떻게 작동하는지는 알기 어렵다. 이는 솔루션 개발사의 노하우이기도 하고 영업 기밀일 수도 있기 때문이다. 그러다 보니 유저입장에서는 사용방법에만 익숙해 지기 마련인데, 원리를 이해하고자 하는 현업 운영자나 엔지니어에게는 답답한 것이 사실이다. 그러나, 오픈소스의 경우 편리한 GUI는 다소 부족하지만 커뮤니티를 통해 공유되는 정보나 공개된 소스를 분석해 보면 작동원리를 쉽게 이해할 수 있고, 여러 가지 제공되는 다양한 옵션으로 시도해 보면서 어떻게 다른지 이해할 수 있게 된다. 결국 작동원리를 이해하게 되면 다양한 응용이 가능해 지게 된다.
상용 솔루션 또는 Cloud 서비스의 경우 라이선스 정책에 따라 사용 횟수나 설치할 agent의 수에 제한이 있는 경우가 대부분이다. 따라서 솔루션 도입 이후 환경의 변화나 인원의 증가시에는 추가 비용을 지불해야 하는 경우가 발생하게 된다. 그러나 오픈소스의 경우 이러한 변화에 관계없이 자유롭게 활용할 수 있다는 장점이 있다.
다음은, 실제 메일등으로 발생한 이벤트에 대한 로그를 살펴보도록 하자.
그럼, 이제 본격적으로 각각의 조건에 맞는 툴 사용방법을 살펴보도록 하자.
일정 규모의 시스템이나 네트워크를 운영할 경우 또는 사무실이나 전산실의 PC가 불필요하게 열려져 있는 포트나 서비스 혹은 해당 포트를 통해 취약성이 있는지 여부를 알고자 할 때가 있다. 이러한 경우 흔히 스캐너(scanner)를 이용하여 점검을 할 수 있는데, 용도에 따라 다양한 종류의 프로그램이나 서비스가 존재하고 있다. 이 중에서 가장 대표적인 툴이라면 위의 그림에서와 같이 nmap이나 OpenVAS 또는 Nessus를 생각할 수 있다.
먼저 nmap(https://nmap.org/)은 가장 대표적인 포트 스캐너로서 Matrix등 13편의 영화에 출연(?)할만큼 잘 알려져 있는 툴이다.
[그림] 영화 Matirx의 nmap 실행장면
사용방법도 쉽지만 nmap은 정말 많은 옵션을 제공하고 있는데, 그 중에서도 실무에 꼭 필요하지만 잘 알려져 있지 않은 몇가지 활용방안에 대해 살펴보도록 하자.
* 대규모의 네트워크에 특정 포트 오픈 여부 확인 방법
먼저 아래의 명령어는 여러 IP 또는 IP대역에서 특정 포트가 오픈된 IP를 찾고자 할 때 유용하게 활용할 수 있는 방법이다. 복잡해 보이지만, 하나씩 살펴보면 의외로 간단한데, 먼저 -p 다음에 스캔하고자 하는 포트번호를 ,(콤머)를 기준으로 나열하면 된다. 여기에서는 22,3389,445를 지정하였고 -iL 다음에는 스캔하고자 하는 IP나 IP 대역을 정의한 파일이름을 지정하면 되는데, 아래 예의 경우 현재 디렉토리 내에 있는 ip_list.txt 파일이다. 그리고, -oG는 output의 형식을 Grep할 수 있는 형태로 하되 (-oG :: output with Grepable format) 결과물은 open_result 라는 파일에 저장된다.
$ cat ip_list.txt
10.1.2.3
10.2.3.4
10.0.0.0/16
10.1.93.0/24
......
스캔하고자 하는 대역은 각 IP나 대역을 각각의 라인에 하나씩 입력하면 된다.
스캔이 종료되면 최종적으로 open_result 파일에 결과가 저장되고 아래와 같이 grep으로 찾고자 하는 정보를 필터링하면 되는데, 아래는 telnet이 열린 IP에 대한 정보가 보여지게 되고 아울러 해당 telnet daemon이 어떠한 종류인지에 대한 정보도 같이 출력해 준다.
$ cat open_result | grep telnet
Host: 10.0.82.74 () Ports: 23/open/tcp//telnet//BSD-derived telnetd
Host: 10.0.85.139 () Ports: 23/open/tcp//telnet//Netscreen ScreenOS telnetd
Host: 10.0.90.66 () Ports: 23/open/tcp//telnet//Cisco router telnetd/
Host: 10.1.93.245 () Ports: 23/open/tcp//telnet//telnet (generic)/
아래는 위의 포트를 사용하는 것 중 SSH에 대한 정보도 확인할 수 있는 예를 보여준다. 주로 외부에서 오픈된 SSH에 대한 정보를 찾고자 할 때 활용하는데, Banner 정보를 보고 버전이나 프로토콜 정보도 판단할 수 있다.
$ cat open_result | grep SSH
Host: 10.19.150.195 Ports: 22/open/tcp//ssh//OpenSSH 4.3 (protocol 2.0)
Host: 10.19.89.10 Ports: 22/open/tcp//ssh//OpenSSH 3.9p1 (protocol 1.99)
* NSE를 활용한 취약성 점검
nmap에는 NSE(Nmap Scripting Engine)이라는 기능도 제공한다. 이는 nmap의 확장된 script 기능을 활용해서 필요로 하는 특정 취약성에 대한 스캔을 빠르게 할 수 있는 기능으로 /usr/local/share/nmap/scripts 에 500여개의 스크립트가 있어서 필요로 하는 기능은 대부분 활용할 수 있다. 이들은 다음과 같은 종류로 나눌 수 있다.
많은 기능들 중에서 몇 가지 대표적인 예만 확인해 보도록 하자.
192.168.1.0/24 대역에서 recursion이 허용된 IP를 검색할 수 있다.
192.168.1.0.24 대역에서 anonymous ftp가 허용된 IP를 검색할 수 있다.
192.168.1.0 대역에서 ftp에 대한 brute force 공격을 시도하여 추측하기 쉬운 ftp 계정이 있는지 스캔한다.
index.bak 나 index.html~ 등과 같은 백업 파일이 있는지 검색한다.
PORT STATE SERVICE
80/tcp open http
http-google-malware.nse: Host is known for distributing malware.
구글의 safe browsing을 활용하여 해당 홈페이지에 악성코드(malware)가 삽입되었는지 여부를 점검할 수 있다.
이는 쉽게 추측할 수 있듯이 해당사이트에 sql injection 취약성이 있는지 여부를 스캔한다.
Post-scan script results:
reverse-index:
22/tcp: 192.168.0.60
23/tcp: 192.168.0.100
80/tcp: 192.168.0.70
445/tcp: 192.168.0.1
53/udp: 192.168.0.105, 192.168.0.70, 192.168.0.60, 192.168.0.1
5353/udp: 192.168.0.105, 192.168.0.70, 192.168.0.60, 192.168.0.1
이는 쉽게 추측할 수 있듯이 해당사이트에 sql injection 취약성이 있는지 여부를 스캔한다.
앞에서 살펴본 nmap이 포트나 개별 취약성에 대한 스캔기능을 제공한다면 특정 IP나 IP 대역에 대한 전반적인 취약성을 점검하고자 할 때는 별도의 전용 스캐너를 이용할 수 있다. 이의 대표적인 프로그램으로는 Nessus(http://nessus.org/)와 OpenVAS(http://openvas.org/) 가 있는데, 먼저 Nessus는 처음에 오픈소스 프로젝트로 시작되었다가 현재는 Tenable 이라는 회사에 프로젝트가 인수되어 상용 버전으로 제공되고 있다. 비록 현재, 오픈소스는 아니지만 Home 버전 라이선스로는 동시에 스캔할 수 있는 IP제한이 있는 것 외에 상용 버전과 유사한 기능을 무료로 활용할 수 있도록 제공하고 있다. Nessus를 설치한 후에는 스캔하고자 하는 IP나 IP대역 또는 도메인만 입력하면 되는데, 특히 Nessus는 스캔할 수 있는 취약성의 수와 스캔 시 서비스에 영향을 주지 않는 안정성 그리고 아래와 같이 깔끔한 보고서로서의 장점을 가지고 있다.
[그림] Nessus의 host별 취약성 점검 결과
Nessus의 IP별 세부 취약성 정보
Nessus가 상용 프로젝트로 넘어가면서 이의 뒤를 잇는 오픈소스 프로젝트로는 OpenVAS가 있다. Nessus와 유사한 기능과 쉬운 GUI를 제공하지만 설치하는 방법이 매우 어렵고 복잡한 문제점이 있는 것이 사실이다. 이러한 문제점을 해결할 수 있는 방법으로는 Kali 라는 리눅스 배포판을 이용하는 방법이 있는데, Kali 리눅스(https://www.kali.org/)에는 OpenVAS를 포함하여 정보수집, 취약성점검, 웹 어플리케이션 분석, 패스워드 크랙, 무선 해킹, 리버스엔지니어링, 스니핑 및 spoofing 툴, 포렌식, 리포팅 툴 등 다양한 분야별로 가장 대표적인 300여종의 각종 오픈소스가 이미 설치되어 있기 때문에 별도로 설치할 필요없이 메뉴로 선택하기만 하면 바로 사용할 수 있는 편리함을 제공한다.
[그림] [그림] Kali 리눅스 실행화면
아래 그림은 Kali 리눅스에서 OpenVAS를 재가동하고, 웹GUI에 접근할 ID/PW를 생성하는 절차를 보여주고 있는데, 간단히 실행이 가능한 것을 알 수 있다.
[그림] OpenVAS 설정 화면
이후 https://127.0.0.1:9392/ 로 접속하여 앞에서 생성한 ID/PW로 로그인을 한 후 스캔하고자 하는 대상을 입력하여 스캔을 하면 된다.
[그림] 로그인 화면
[그림] 스캔 결과 화면
상용 솔루션에 비해 기능이나 GUI는 다소 부족하지만 취약성 점검의 기능으로서는 손색이 없을 정도로 유용하다 할 수 있다.
상용이든 오픈소스이든 보안 솔루션을 설치하고 나면 넘쳐나는 보안이벤트 때문에 골머리를 앓거나 튜닝을 하다가도 결국에는 끝이 보이지 않는 작업에 아예 포기를 하는 경우도 있다. 따라서, 보안을 위해 꼭 필요로 하는 최소한의 이벤트만 발생하도록 하고, 또한 넘쳐나는 이벤트들을 통합하여 효율적으로 모니터링 하고자 할 때 활용할 수 있는 솔루션에 대해 살펴보도록 하자.
IDS(침입탐지시스템)나 IPS(침입방지시스템) 솔루션으로는 snort와 같은 네트워크 기반의 솔루션이 많이 알려져 있고, 반면에 각 Host에 agent 형식으로 설치하는 호스트 기반의 IDS/IPS는 각 Host마다 설치해야 한다는 번거로움 때문에 잘 알려져 있지 않은 것이 사실이다. 그러나 Host기반의 IDS/IPS는 직접 시스템 로그나 프로세스를 모니터링 할 수 있기 때문에, 네트워크 기반 솔루션에 비해 좀 더 정확하고 의미 있는 정보를 얻어낼 수 있다는 장점을 가지고 있다. 이를 위해 가장 대표적인 오픈소스 솔루션으로는 OSSEC(https://ossec.github.io/) 이라는 솔루션이 있는데, 현재는 보안회사인 Trendmicr의 지원 하에 지속적으로 오픈소스로 제공하고 있다.
ossec은 Log 분석, 파일무결성모니터링(FIM)뿐 아니라 루트킷 탐지 기능도 제공하고 있으며 상세한 모니터링이 가능하기 때문에, System(kernel, daemon등)내부에서 어떠한 일이 발생하는지 상세하게 인지할 수 있어 전반적인 visibility(가시성)를 제공한다고 할 수 있다.
아래는 ossec의 작동 방식에 대한 조감인데, 각 host에 설치되어 있는 agent에서는 로그나 프로세스 등 모니터링 하고자 하는 항목에 대해 수집만해서 로그서버에 전달해 주면 별도의 ossec 서버에서 지정한 조건이나 룰에 따라 분석을 하고 매칭이 될 경우 전용 로그 시스템에 전송하거나 메일 알람 등의 action을 취하기 때문에 각 Host에서는 부하 발생 등에 대한 부담을 최소화할 수 있다.
[그림] ossec의 작동방식
ossec은 기본적으로 /var/ossec 디렉토리에 설치되고, 주 설정파일은 /var/ossec/etc/ossec.conf 이며 /var/ossec/rules/*.xml 에 룰 파일이 있는데, 실제 발생한 로그를 기반으로 탐지하기 때문에 오탐은 거의 없으며 따라서 의미 있는 알람을 기대할 수 있다. 실제 몇 가지 룰을 보고 어떻게 활용할 수 있는지 살펴보도록 하자.
<directories check_all="yes">/etc,/usr/bin,/usr/sbin</directories>
<ignore>/etc/passwd</ignore>
</syscheck>
이 설정은, 변경되지 말아야 할 파일이나 디렉토리의 속성이 변경 시 알람하고자 할 때 활용할 수 있는 룰로서, /etc/passwd 를 제외하고(ignore) /etc, /usr/bin, /usr/sbin 디렉토리에서 md5나, owner, permission등이 변경시에 알람을 하게 된다.
다음은, 실제 메일등으로 발생한 이벤트에 대한 로그를 살펴보도록 하자.
Rule: 5551 fired (level 10) -> "Multiple failed logins in a small period of time."
Src Location: CN,Guangdong,Guangzhou
Portion of the log(s):
www vsftpd: pam_unix(vsftpd:auth): authentication failure; logname= uid=0 euid=0 tty=ftp ruser=zhaolg rhost=61.144.79.245
이는 짧은 시간에 특정 IP에서 지속적인 ftp brute force 시도가 있을 때 알람하는 것을 알 수 있다.
Rule: 592 fired (level 8) -> "Log file size reduced."
Portion of the log(s):
ossec: File size reduced (inode remained): '/var/log/messages'.
이는 파일을 삭제하거나 로그의 특정 부분이 삭제 되었을 때 발생하는 알람으로, 공격자가 시스템에 침입 후 자신의 흔적을 교묘하게 지우고자 할 때 유용하게 모니터링 할 수 있을 것이다.
다음은, 단순 탐지에 그치지 않고 특정 조건에 매칭될 경우 tcpwrapper나 iptables를 이용하여 특정 IP를 차단하고자 할 때 활용할 수 있는 예를 보여주고 있다. 아래의 룰은 source ip를 기준으로 level 3 이상의 이벤트가 발생하였을 때 해당 IP에 대해 600초(10분)동안 해당 Host에서 차단하기 위해 host-deny.sh를 실행한다는 의미가 된다.
<name>host-deny</name>
<executable>host-deny.sh</executable>
<expect>srcip</expect>
<timeout_allowed>yes</timeout_allowed>
</command>
<active-response>
<command>host-deny</command>
<location>local</location>
<level>3</level>
<timeout>600</timeout>
</active-response>
이는 www.server2.com이라는 Host에서 192.168.0.2로부터 level3의 이벤트가 발생하였을 때 보여지는 이벤트 정보를 보여주고 있다.
2015 Jul 12 23:27:24 (www.server2.com) any->/var/ossec/logs/active-responses.log
Rule: 603 (level 3) -> 'Host Blocked by host-deny.sh Active Response'
Src IP: 192.168.0.2
Sun Jul 12 23:27:21 KST 2015 /var/ossec/active-response/bin/host-deny.sh add - 192.168.0.2 1436711242.71719 5720
이처럼 OSSEC은 다양한 조건에 따라 발생하는 이벤트를 메일이나 로그 등으로 남기도록 할 수 있지만 이벤트들을 통합하여 웹기반의 GUI로도 볼 수 있는 기능을 제공하고 있는데, 아래 그림은 AnaLogi라는 오픈소스 툴을 연동하여 ossec의 다양한 이벤트를 좀 더 이해하기 쉽게 모니터링 할 수 있는 것을 보여주고 있다. 설치 후 DB ID,PW만 설정해 주면 제한 없이 바로 사용할 수 있기 때문에 매우 유용하다.
[그림] AnaLogi를 활용한 ossec dashboard 화면
아울러, 단순히 GUI dashboard 만 볼 수 있는 것이 아니라 이벤트 level이나 기간, 이벤트 종류 등 다양한 조건에 맞는 이벤트만을 필터링하여 볼 수 있는 기능도 제공하고 있다.
[그림] ossec GUI의 조건 필터링 화면
또한, 전용 SIEM(Security Information and Event Management) 솔루션을 활용할 수도 있다. 특히 오픈소스로 제공하는 Elastic(https://www.elastic.co/)의 경우 splunk와 같은 상용 수준의 다양한 기능과 유려함, 그리고 최근에는 커뮤니티를 통해 한번에 설치할 수 있는 스크립트를 제공하는 등 활발하게 활용되고 있는데, 앞에서 예를 든 ossec뿐만 아니라 웹로그나 시스템 로그 등 다양한 소스로부터 다양한 로그를 받아서 처리할 수 있기 때문에 최근 사용자수가 급증하고 있다.
elastic dashboard 예
elastic 뿐 아니라 유사한 상용 솔루션인 splunk의 경우 홈페이지에서 다운로드 할 수 있고 일정 용량의 로그처리까지는 기능 제한없이 무상(Free)으로 사용할 수 있는데, 설치방법이 쉽고, 다양한 종류의 App 설정도 웹 GUI를 통해 제공되기 때문에 SIEM을 경험하는데 도움이 될 것이다.
[그림] splunk의 ossec dashboard 예
사실 아무리 암호를 자주 변경하고 어렵게 설정한다 하더라도 공격자들은 APT등의 방법을 통해 내부 시스템에 접근하는 경우가 빈번하게 발생하고 있다. 이렇듯 ID/PW 만으로는 부족한 인증체계를 극복하기 위한 추가인증(Multi Factor) 수단으로서 OTP(One Time Password) 를 도입하는 경우가 증가하고 있다.
OTP는 말 그대로 시간(time)이나 이벤트 발생을 기준으로 random하게 생성되는 일회용 암호로서 흔히 ID/PW만으로는 부족한 인증 체계에 추가 인증을 하고자 할 때 주로 사용되는데, 초기에는 OTP 인증을 위한 별도의 서버가 있어야 하고, 솔루션 자체가 매우 고가여서 대기업 외에는 도입하기가 어려웠지만 최근에는 스마트폰의 보급과 Free로 사용할 수 있는 훌륭한 오픈소스 OTP솔루션이 제공되면서 점차 대중화되어 가고 있다.
[그림] OTP의 개념
여러 오픈소스 OTP 솔루션 중에서 가장 대표적인 것으로는 구글OTP가 있다. 먼저 OTP를 사용하려면 각 유저들은 자신의 스마트폰에 전용앱(App)을 설치하여야 하는데, 구글OTP는 iphone, 안드로이드, 윈도우폰 등 거의 모든 디바이스(device)를 지원하기 때문에 별도의 장치가 필요하지 않다. 또한 이벤트 또는 시간(time) 기반 OTP의 경우 OTP가 적용된 서버와 접속 단말의 시간만 서로 큰 차이가 많이 나지 않으면 유효하기 때문에 별도의 인증 서버도 필요 없다. 따라서 T(Time based)OTP의 경우 WIFI/LTE등의 연결이 되지 않아도 사용이 가능하다. 통상적으로 OTP 코드는 30초마다 random하게 변경되기 때문에 30초만 유효하며, 자체적으로 rate-limit 기능이 있기 때문에 Brute force 공격에 안전하다는 장점도 있다.
여기에서는 리눅스 서버의 SSH인증시 구글OTP를 연동하여 보도록 하자.
먼저, 홈페이지(https://github.com/google/google-authenticator/wiki)를 참고하여git 또는 # yum install google-authenticator로 설치를 하도록 한다. 이후 QR code를 시스템에서 볼 수 있도록 “# yum install qrencode”로 설치하도록 한다. 이제 각 유저들은 각자 아래 명령어를 실행하여 OTP 코드에 대한 개인 설정을 셋업 또는 초기화할 수 있다.
위 명령어를 실행하면 잠시 후 각 유저 및 시간대별로 유일한 QR 코드가 생성되는데, App을 이용하여 스캔을 하면 아래 그림과 같이 자동으로 항목이 추가되고 30초마다 변경되는 6자리 숫자를 확인할 수 있다.
[그림] OTP 셋업 초기화 단계
다음으로, SSH 서버에 OTP 모듈을 연동하여 설정하는 방법을 살펴보자.
먼저 /etc/pam.d/sshd 파일에 아래 설정을 추가하여 적용한다.
그리고, SSH 설정 파일인 /etc/ssh/sshd_config 에 아래의 관련 설정을 추가한다.
ChallengeResponseAuthentication yes
PasswordAuthentication yes
이후, SSHD를 재가동하여 적용 후 원격에서 SSH 접속을 시도하면 아래와 같이 Verification code(OTP)를 묻는 창이 뜨는 것을 알 수 있다. App을 실행하여 30초안에 OTP 코드를 입력하면 되는데, Verification code(OTP) 뿐 아니라 ID에 해당하는 암호도 정확히 입력해야 로그인이 된다.
Verification code: xxxxxx <== OTP코드
Password: <== 기존에 사용중인 password
구글OTP외에 유사한 오픈소스 프로젝트로서 Redhat의 FreeOTP(https://fedorahosted.org/freeotp/)도 있다.
공격자의 입장에서 DDoS 공격은 가장 쉬우면서도 위력적인 방법이기 때문에 언제든 악용될 수 있는 공격 중 하나이다. 특히 DDoS 공격 중 GET Flooding등과 같은 L7 DDoS공격은 자주 발생하지만 정상적인 접속과 구분하기 어려워 사실상 차단하기 어려운 방법 중 하나인데, 대부분의 DDoS 공격은 브라우저가 아니라 봇(bot)을 통해 이루어진다는 점에 착안, 브라우저와 봇을 구분하여 방어할 수 있는 오픈소스 모듈이 있다.
testcookie(https://github.com/kyprizel/testcookie-nginx-module)는 nginx 웹서버와 호환되는 보안 모듈로서 nginx 웹서버라면 바로 module을 올려서 사용할 수 있고 Apache등 nginx가 아니라면 nginx를 proxy 형태로 사용할 수도 있다. 기존의 다른 ddos 대응 모듈들은 단순히 비율제한(rate-limit) 기능을 사용했기 때문에 오탐이 있거나 대응이 효과적이지 않았는데, testcookie는 봇의 특성을 이용하여 접속을 원천적으로 차단하기 때문에 좀 더 효율적이라고 할 수 있다.
먼저 nginx 및 testcookie 설치는 아래와 같이 간단히 가능하다.
# wget https://github.com/kyprizel/testcookie-nginx-module/tarball/master
# tar xzvf nginx-x.x.x.tar.gz;
# tar xzvf kyprizel-testcookie-nginx-module-xxxx.tar.gz
# mv kyprizel-testcookie-nginx-module /usr/share/testcookie-nginx-module
# cd nginx-x.x.x/
# ./configure --add-module=/usr/share/testcookie-nginx-module
# make; make install
testcookie가 Bot으로 탐지하는 원리는 크게 두가지인데, 각각의 원리와 프로세스에 대해 살펴보도록 하자.
모든 일반적인 웹브라우저는 30x 및 set-cookie를 인지하여 따라가지만 일반적인 봇은 따라가지 않는다는 원리를 이용하는 방법으로 중간에서 요청을 가로채어 30x 및 set-cookie로 응답 후 이에 대해 클라이언트가 어떻게 반응하는지를 보고 판단하는 방법이다.
[그림] 30x와 set-Cookie를 이용한 대응
① 처음에 클라이언트로가 GET 접속요청을 한다.
② nginx + testcookie에서 307 Redirect와 함께 Set-Cookie를 달고 응답한다.
이때 cookie는 Source IP를 MD5한 값(S#)으로 한다.
③ 정상적인 브라우저라면 Redirect 및 setcookie를 인지하므로, cookie=S#를 달고 Redirect한 URL로 재접속 요청을 한다.
④ 정상적인 요청이므로 원래의 웹서버(origin)로 요청을 전달한다.
만약 cookie=S#를 달고 들어오지 않은 요청이라면 ② 과정을 되풀이한다.
즉, 봇(bot)이라면 ①,②과정만을 되풀이하게 되며 ③,④를 진행하지 못할 것이다.
설정 방법은 홈페이지에 자세히 나와있지만 핵심적인 부분은 아래와 같다.
testcookie on;
testcookie_name LINUX;
testcookie_session $remote_addr;
}
즉, testcookie 기능을 활성화하고 LINUX 라는 이름의 cookie를 만들고 이 변수에 들어가는 값은 클라이언트 IP를 md5로 hash한 값으로 생성하여 클라이언트에게 Set-Cookie로 전달하게 된다.
첫 번째 방법과 유사하지만, set-cookie를 Header 수준에서 삽입하지 않고 200 OK 응답과 함께 응답 데이터에 Javascript로 삽입함으로써 cookie를 인지하는 일부 고수준의 봇을 탐지할 수 있는 방법이다.
[그림] Javascript 삽입 및 set-Cookie를 이용한 대응
① 처음에 클라이언트로가 GET 접속요청을 한다.
② nginx + testcookie에서 200 OK로 응답하면서 Javascript에서 cookie를 달고 재접속 요청을 하도록 한다. 이때 cookie는 Source IP를 AES로 암호화한 값(S#)으로 한다.
③ 정상적인 브라우저라면 Javascript 및 cookie를 인지하므로 document.location.href에 의해 재 접속을 하게 되고 이때 cookie=S#를 달고 들어오게 된다.
④ 정상적인 요청이므로 원래의 웹서버(origin)로 요청을 전달한다.
만약 cookie=S#를 달고 들어오지 않은 요청이라면 ② 과정을 되풀이한다.
즉, 봇(bot)이라면 ①,②과정만을 되풀이하게 되며 ③,④를 진행하지 못할 것이다. 일부 진보된 봇의 경우 30x와 set-cookie를 인지하는 경우가 있지만 Javascript까지 인지하는 경우는 거의 드물기 때문에 두 번째 방법을 활용하면 좀 더 확실하게 대응할 수 있을 것이다.
이처럼, testcookie 솔루션을 활용하면 다양한 봇으로부터의 접속을 차단할 수 있다는 장점이 있지만 봇 중에서는 모니터링 툴이나 검색엔진 등과 같은 굿봇(good bot)도 일부 차단될 수 있으므로 공격시에만 적용하거나 굿봇에 대해서는 사전에 허용 처리하는 것이 권장된다.
지금까지 대표적인 오픈소스 보안 툴 중 일부를 살펴보았다. 그러나, 앞에서 잠시 언급한 바 있는 Kali 리눅스를 보면 300여개가 넘는 오픈소스 보안 툴들이 있기 때문에 지금 소개한 것들은 극히 일부에 불과하다는 것을 알 수 있으며, 새로운 오픈소스 프로젝트는 계속해서 생겨나고 또 진보하고 있다. 분명한 것은 최근의 오픈소스 솔루션들은 기존의 전통적인 오픈소스의 특징인 사용하기 어렵고, 불편하고 UI가 좋지 않다는 부분을 과감히 개선하여 상용 솔루션 수준의 기능과 성능을 제공하는 경우가 많아지고 있다는 것이다. 아울러, 상용 솔루션은 상용 솔루션대로, 오픈소스 역시 오픈소스 나름대로의 장단점을 가지고 있으므로 어느 하나에만 의존하기 보다는 상황에 맞게 적당히 혼용하여 사용하는 방안도 생각해 볼 수 있을 것이다.
/필/자/소/개/
홍석범 이사
- CDNetworks 이사, 미래창조과학부 사이버보안전문단
- 저서 : IT백두대간 리눅스 완벽가이드, 리눅스 서버 보안과리 실무, 리눅스 보안과 최적화 완벽 솔루션(번역)
공개SW역량프라자에 의해 작성된 이 저작물은 크리에이티브 커먼즈 저작자표시-변경금지 4.0 국제 라이선스에 따라 이용할 수 있습니다. |
번호 | 제목 | 작성자 | 조회수 | 작성 |
---|---|---|---|---|
공지 | [2024년] 오픈소스SW 라이선스 가이드 개정판 발간 file | support | 12553 | 2024-01-03 |
공지 | [2024년] 기업 오픈소스SW 거버넌스 가이드 개정판 발간 file | support | 10071 | 2024-01-03 |
공지 | [2024년] 공공 오픈소스SW 거버넌스 가이드 개정판 발간 file | support | 9964 | 2024-01-03 |
공지 | 공개 소프트웨어 연구개발(R&D) 실무 가이드라인 배포 file | support | 22461 | 2022-07-28 |
공지 | 공개소프트웨어 연구개발 수행 가이드라인 file | OSS | 20809 | 2018-04-26 |
248 | [1월 공개SW 월간브리핑] CES 2017 공개SW 전략과 기술 외 | OSS | 2040 | 2017-02-06 |
247 | IoT 보안 동향과 기술 | OSS | 4373 | 2016-12-21 |
246 | 다양한 요구 조건에 딱 맞는 오픈소스 보안 솔루션 활용 가이드 | OSS | 3888 | 2016-12-16 |
245 | [논문] 경제학이 오픈소스 소프트웨어에 대해 알고 있는 것 | OSS | 2376 | 2016-12-09 |
244 | 워드 파일을 PDF로 변환하기 1 | OSS | 9696 | 2016-12-06 |
243 | 오픈소스 SW의 글로벌 동향과 우리 기업의 해외 진출 방안 | OSS | 1956 | 2016-11-28 |
242 | 컴퓨터의 발달과 사물인터넷의 등장 | OSS | 4145 | 2016-07-12 |
241 | 오픈소스 소프트웨어 관점 기반 SDI 발전 고찰 | OSS | 1991 | 2016-07-05 |
240 | [2015년 12월 기준] 임베디드분야 공개SW 솔루션 리스트 file | OSS | 1682 | 2016-04-07 |
239 | [2015년 12월 기준] SW 품질검증분야 공개SW 솔루션 리스트 file | OSS | 1643 | 2016-04-07 |
0개 댓글