강좌
클라우드/리눅스에 관한 강좌입니다.
해킹&보안 분류

네트워크취약성과대책 #1 : 스니핑(sniffing)공격과 대책 1편

작성자 정보

  • 관리자 작성
  • 작성일

컨텐츠 정보

본문

스니핑(Sniffing) 공격



우리가 일상생활 속에서 늘 사용하고 있는 인터넷(INTERNET) 자체가 TCP/IP라고 할 수 있을 만큼 인터넷의 표준 프로토콜인 TCP/IP는 시스템이나 네트워크 분야에서 너무나 익숙하게 사용하고 있다.

 

하지만 그 내부를 조금만 들여다보면 자체적으로 많은 취약성을 가지고 있다는 것을 알 수 있는데, 그러하기에 이러한 TCP/IP 프로토콜을 기반으로 한 OS나 여러 응용 프로그램 역시 최신의 패치작업을 하였다 하더라도 TCP/IP 프로토콜과 관련된 치명적인 취약성에서 결코 예외일 수는 없다.

 

따라서 이러한 네트워크 자체의 취약성을 악용한 공격은 비정상적인 행위이므로 실제로 보이는 현상이나 증상도 매우 비정상적이어서 이로 인한 장애가 발생했을 때 시스템이나 네트워크 관리자는 처음 접한 상황에 매우 당황하게 된다.

 

장애시간이 길어지면서 고객들의 항의 전화는 불이 나게 되고 관리자는 마음이 바빠지게 된다.

 

그래서 최후의 수단으로 시스템이나 네트워크 장비를 재부팅 해 보기도 하지만 장비의 오작동이 아니므로 비정상적인 현상은 계속 나타나게 될 것이다.

 

결국 자신의 능력으로 정상적인 복구가 안 된다면 지인이나 유료 기술지원을 통해 해결하여야 하겠지만 다른 이에게 지원을 요청하는 것이 관리자 입장에서는 자존심이 허락되지 않는 일이기도 하거니와 문제가 해결될 때까지 서비스 장애도 큰 문제꺼리가 아닐 수 없다.

 

이러한 공격 중 치명적이면서도 자주 악용되는, 그래서 필자도 이로 인하여 고생한 적이 있는 대표적인 몇 가지 공격의 원리와 대처 방법에 대해 알아보도록 하겠다. 물론 이외에도 다른 형태의 공격도 있을 수 있지만 이에 대해서는 보안 메일링 리스트 등을 통해 꾸준히 새로운 보안정보를 접하도록 하는 것이 좋고, 또한 이전에 접해보지 못한 공격 형태라 하더라도 원리는 크게 벗어나지 않으므로 기존의 지식을 충분히 활용하여 대처할 수 있을 것이다.

 

가끔 서버를 운영하다 보면 시스템의 모든 취약성을 패치하여 보안적으로 안정한 상태이고, 암호를 특수문자까지 섞어 어렵게 설정하였음에도 불구하고 누군가 시스템에 침입한 흔적을 발견하는 경우가 가끔씩 있다.

 

아마도 서버관리자라면 이러한 경험을 한 두 번씩은 해 보았을 텐데, 어떻게 침입하였을까 라는 의구심이 드는 경우가 있다.

 

필자 역시 특정 시스템의 취약성이 발표될 때마다 꾸준히 패치를 하여 보안설정을 완벽하게 하고 있었던 관리서버에 침입당한 흔적을 발견한 적이 있는데, 도대체 이 시스템의 어떤 취약성을 이용하여 침입 하였을까 라고 고민했던 적이 꽤 있었다.

 

그런데, 아무리 찾아봐도 취약성을 발견할 수 없어 혹시나 내부에 침입자가 있었던 것이 아닐까라고 생각했던 적도 있었다.

 

 

이럴 경우 가장 먼저 의심해 보아야 할 것은 바로 스니핑을 통해 아이디/암호나 명령어가 유출된 것은 아닌지 확인해 보아야 한다.

 

우리가 사용하는 PC와 서버환경이 모두 네트워크에 연결된 이상 자신의 시스템 하나만 보안을 강화하는 것으로 완벽한 시스템/네트워크 보안을 구현하였다고 할 수 없으며 주위의 시스템도 반드시 함께 고려를 하여야 한다.

 

왜냐하면 주위의 다른 시스템에서 해킹을 당해 공격자가 스니핑을 실행한다면 시스템 내부에 침입하지 않고도 같은 네트워크에 있는 시스템의 아이디/암호 등의 유용한 정보를 손쉽게 획득할 수 있기 때문이다.

 

만약 스니핑에 의해 아이디/암호가 유출되었을 경우, last 명령어로 확인해 보면 몇 가지 공통적인 현상이 있다.

 

첫 째, 같은 IP에서 짧은 시간에 하나가 아닌 여러 계정에 접근한 흔적이 있는데 이는 스니핑을 통해 획득한 로그인 정보를 통해 실제 로그인이 되는지, 로그인시 쉘을 사용할 수 있는지 등을 확인해 보기 위해서이다.

 

두 번째는 여러 IP에서 한 계정에 접근한 흔적이 보이는데, 이는 스니핑을 통해 여러 시스템의 로그인 정보를 획득하여, 접속 시 마다 다른 서버를 경유하기 때문(일종의 경유지 세탁)이다.

 

기본적으로 last 명령어는 한 달을 기준으로 현재 속한 달()의 정보만 보여주므로 이전 달()의 정보를 확인하려면 “last -f /var/log/wtmp.1”와 같이 실행하면 된다.

 

 

10.1.1 스니핑 개요

 

스니핑이라는 용어 자체는 자주 들어보았겠지만 간단히 정의하자면, 네트워크를 통과하는 패킷을 도청하여 아이디/암호나 입력한 명령어 등 각종 정보를 비정상적인 방법으로 엿보는 행위, 즉 전기적 도청을 의미한다.

 

현실 세계에서도 마음만 먹는다면 여러 가지 방법을 이용하여 전화나 휴대폰의 통화 정보를 도청할 수 있는 것처럼 네트워크에서도 역시 간단한 원리와 툴 사용법만 알면 어렵지 않게 네트워크 트래픽을 도청할 수 있는 것이 사실이다.

 

이 때문에 대부분의 공격자들은 시스템의 관리자 권한을 획득한 후 시스템에 스니핑 프로그램을 설치하여 실행하면 해당 로컬 서버는 물론이고 동일네트워크를 사용하는 다른 서버에 접근하는 아이디나 패스워드 정보를 얻을 수 있다.

 

참고로 동일 네트워크의 의미를 좀 더 정확히 표현한다면 같은 VLAN 공간을 의미한다.

 

, 동일한 VLAN 공간에 있는 정보에 대해서만 스니핑이 가능하며 다른 VLAN이나 원격지 시스템에 대해서는 스니핑이 불가능하다. 물론 동일한 VLAN내 시스템에서 외부로 접속하는 정보는 스니핑이 가능하다.

 

하지만 스위칭 환경이라 하더라도 IDC와 같이 대량의 시스템이 모여 있는 환경에서는 한 서버만 해킹 한 후 스니핑 프로그램을 실행해도 최소 10여개 이상의 시스템 접근정보를 파악할 수 있게 된다.

 

따라서 시스템의 취약성을 모두 패치 하였다 하더라도 다른 시스템에서 스니핑을 실행하여 아이디/암호등 접속정보가 보여 지게 된다면 쉽게 침입할 수 있는 허점이 존재하게 되는 것이다.

 

이처럼 스니핑은 공격자의 입장에서 매우 간단하면서 큰 수확을 얻을 수 있지만 반면 서버나 네트워크 관리자의 입장에서는 매우 치명적이고 대비하기가 어려운 형태의 공격이라 할 수 있다.

 

 

네트워크에서의 스니핑은 크게 두 가지 이유로 가능한데, 이것이 바로 스니핑의 원리가 될 수 있다.

 

 

 

첫 번째로, 단순한 구조에서 주로 사용하는 더미(dummy) 허브(흔히 가정이나 사무용으로 사용되는 저가형 허브, 흔히 허브라 하면 더미허브를 뜻한다.

 

) 환경에서는 모든 패킷을 모든 포트에 전달(broadcast)함으로써 직접적인 통신과 관계없는 다른 포트에 연결되어 있는 PC나 서버에서도 다른 시스템의 패킷을 캡처할 수 있게 된다.

 

두 번째는 인터넷의 표준 프로토콜인 TCP/IP의 전송 방식이 암호화하지 않은 평문(plain text)을 사용한다는 점이다.

 

 

 

스니핑은 더미(dummy)환경에서 뿐만 아니라 스위치 환경에서도 문제가 되는데, 이는 뒤에서 설명하겠지만 TCP/IP 자체가 이더넷 구간에서는 ARP라는 취약한 프로토콜에 의존하기 때문이다.

 

 

그러나 TCP/IP 프로토콜이 평문 방식으로 전송된다고 해서 바로 모든 패킷을 스니핑 할 수 있는 것은 아니다. 왜냐하면 기본적으로 패킷의 목적지가 자신의 MAC주소가 아닌 패킷은 이더넷 카드에서 드롭(drop)하는 특성이 있기 때문이다.

 

따라서 어떤 시스템에서 스니핑을 하려면 시스템의 인터페이스에서 패킷의 목적지 MAC이 자기 자신이 아닌 패킷도 받아들여야 하는데, 이를 위해서는 인터페이스가 promiscuous(또는 promisc)모드로 작동하도록 설정하여야 한다.

 

promisc 모드를 번역하면 보이는 패킷은 모두 다 받아들인다는 의미에서 무차별 모드라고도 하는데, promisc 모드로 설정되면 자신을 목적지로 하지 않은 패킷도 이더넷 카드에서 패킷을 드롭하지 않고 무차별적으로 모든 패킷을 다 받아들여 스니핑 프로그램까지 전달되어 스니핑이 가능하게 된다.

 

리눅스에서 인터페이스가 promisc 모드인지 여부를 확인하기 위해서 아래와 같이 인터페이스의 상태를 확인할 수 있는 ifconfig 명령어를 입력하면 된다.

 

 

 

????[유용한 팁]

일반적으로 ifconfig를 이용하여 인터페이스의 상태를 알 수 있다고 알고 있으나 인터페이스에 연결되어 있는 속도정보와 Full인지 Half인지 등의 Duplex 모드정보는 알 수 없다. 이러한 상태에 대한 조회 및 변경을 위해서는 ethtool이라는 것을 이용할 수 있다.

 

 

홈페이지 : http://sourceforge.net/projects/gkernel/

 

홈페이지에서 다운로드 및 압축 해제 후 ./configure; make로 설치하면 된다.

 

이후 아래와 같이 실행하면 현재 인터페이스 상태를 보여주게 된다.

 

 

# ethtool eth1

Settings for eth1:

Supported ports: [ TP MII ]

Supported link modes: 10baseT/Half 10baseT/Full

100baseT/Half 100baseT/Full

Supports auto-negotiation: Yes

Advertised link modes: 10baseT/Half 10baseT/Full

100baseT/Half 100baseT/Full

Advertised auto-negotiation: Yes

Speed: 100Mb/s

Duplex: Full

Port: MII

PHYAD: 32

Transceiver: internal

Auto-negotiation: on

Supports Wake-on: pumbg

Wake-on: d

Current message level: 0x00000007 (7)

Link detected: yes

위의 예에서 보면 현재 eth1이라는 인터페이스의 속도는 100Mb/s이며 Duplex모드는 Full이라는 것을 확인할 수 있다.

 

(진하게 표시된 부분 참조) 물론 이외에도 ethtool을 이용하면 위의 결과에서 확인할 수 있듯이 다양한 인터페이스 정보를 얻을 수 있다.

 

 

만약 현재의 연결 상태를 임의로 변경하려면 다음과 같이 하면 된다.

 

 

속도를100M로 강제설정

ethtool -s eth1 speed 100

Duplex모드를 Full로 강제설정

ethtool -s eth1 duplex full

 

이때 아래와 같이 PROMISC라는 문자열이 보이면 인터페이스는 promisc 모드로 되어 있는 것인데, 참고로 promisc 모드를 수동으로 설정하려면

“ ifconfig eth0 promisc”와 같이 실행하고, 해제하려면

“ ifconfig eth0 -promisc”로 실행하면 된다.

 

 

8fbf1bfe7faf246d2e517e6d05a2ca70_1654674862_3558.png
 

[그림] PROMISC가 설정된 예

 

특별한 이유가 없다면 일반적으로 promisc 모드로 설정되어 있을 필요가 없으므로 만약 자신의 시스템이 promisc 모드로 설정되어 있다면 스니핑 여부를 주의 깊게 검토해 보아야 할 것이다.

 

그런데 일부 보안문서에서는 promisc 모드로 설정되어 있다면 시스템이 해킹을 당한 후 스니핑이 실행되고 있는 것이라고 말하고 있지만 반드시 그런 것은 아니다. 왜냐하면 시스템에 따라 부팅할 때 자동으로 promisc로 설정되는 경우도 있기 때문이다.

 

????[유용한 팁]

스니핑을 통해서 도청이 가능한 프로토콜은 흔히 알고 있는 tcp뿐만 아니라 ip, udp, icmp, arp, rarp등이다.

 

그리고 누군가가 시스템에서 스니핑을 작동시킨다면 이미 root(시스템관리자) 권한을 획득하였다는 것을 의미한다.

 

왜냐하면 스니핑은 오직 root 권한으로만 실행할 수 있기 때문이다.

 

 

 

또한 대부분의 공격자가 스니핑을 돌리기 전에 ifconfig 파일 자체를 변조하여 스니핑이 작동하더라도 PROMISC로 보이지 않도록 하는 경우가 많으므로 의심이 갈 때에는 ifconfig 파일이 변조되지 않았는지를 먼저 확인해 보아야 한다.

 

변조 여부를 확인하는 방법은 여러 가지가 있지만 간단하게 같은 버전의 시스템에 있는 파일의 사이즈나 "strings /sbin/ifconfig"의 결과를 비교해 보아도 된다.

 

 

 

그리고 리눅스에서 ifconfig가 변조된 것이 아닌데, 오작동을 하는 것처럼 보이는 경우가 있다.

 

이를테면 tcpdumpsnort를 실행 한 후 dmesg를 실행하면 아래와 같이 promisc 모드로 들어갔다는 메시지가 보이지만, 실제 ifconfig를 실행해 보면 PROMISC라는 부분이 보이지 않는다.

 

[root@file root]# dmesg | grep promiscuous

device eth0 entered promiscuous mode

device eth1 entered promiscuous mode

[root@file root]#

 

이는 커널과 관련된 ifconfig 자체의 문제로 보이며 이러한 경우 대신 iproute2에 포함되어 있는 다음의 명령어로 확인하면 된다.

 

# ip link show

 

아래 그림에서는 3번째의 eth1PROMISC 모드인 것을 알 수 있다.

 

, ifconfig에만 의존하지 말고, “ip link show” 명령어와 함께 확인하기 바란다.

 

8fbf1bfe7faf246d2e517e6d05a2ca70_1654674880_6204.png
 

[그림] ip link show 실행화면

 

또한 dmesg를 실행하였을 때 “device eth0 entered promiscuous mode” 메시지가 보였다는 것만으로 해킹여부를 묻는 경우가 많은데, 이는 tcpdumpsnort등의 패킷캡처 프로그램이 실행시 기본적으로 promisc 모드로 작동하여 보이는 것이므로 걱정하지 않아도 된다.

 

만약 promisc 모드로의 작동을 원하지 않을 경우에는 tcpdumpsnort 모두 -p 옵션을 주어 실행하면 된다.

 

 

스니핑이 반드시 나쁜 것만은 아니다. 왜냐하면 스니핑을 이용하여 다음과 같은 목적으로 유용하게 사용될 수 있기 때문이다.

 

- 네트워크 트래픽을 분석해서 병목(bottleneck)부분을 찾아내거나 문제해결에 활용된다.

 

 

- 공격자를 모니터링하고 분석하기 위해 NIDS로 활용된다.

 

 

 

10.1.2 스니핑에 대한 대책

 

지금까지 설명한 내용으로 보면 스니핑에 대한 위험성이 매우 크다는 것을 알 수 있을 것이다.

 

그렇다면 스니핑에 대한 대책은 무엇인가? 필자는 스니핑에 대한 대책으로 다음 3가지 정도의 방법을 제시하고자 한다.

 

 

첫 번째 대책으로는 가장 확실한 방법으로서 평문으로 전송되는 TCP/IP 대신 암호화 전송 프로토콜을 사용하는 것이다.

 

이의 대표적인 경우가 telnet 대신 ssh, http 대신 https(SSL 웹서버)등을 사용하는 것이 그 예이다.

 

물론 최근 들어 많이 사용되고 있는 VPN(Virtual Private Network)을 사용하면 모든 프로토콜이 VPN 터널을 통해 암호화되므로 더 없이 좋은 솔루션이 될 것이다.

 

이 책의 9장에서는 리눅스를 활용한 VPN 환경 구축에 대하여 자세히 설명하고 있으므로 참고하기 바란다.

 

참고로 SSL에 대하여 첨언하자면 대부분의 서버관리자들이 https와 같이 SSL을 설치하면 마치 방화벽이나 IPS등의 보안 장비처럼 모든 웹 보안에 완벽해 지는 것으로 오해하는 경우가 있는데, SSL80번 포트를 사용하는 http 프로토콜 역시 TCP/IP와 관련해 언급한 것처럼 평문으로 전송되어 스니핑 될 수 있기 때문에 기존의 http를 암호화한 프로토콜인 https을 사용하는 것일 뿐이며 다른 특별한 보안 모듈이 포함된 것은 아니다. 물론 SSL이 암호화를 통해 세션의 무결성을 보장하기 위한 목적도 있지만 궁극적인 이유는 스니핑에 대비하기 위하여 http의 트래픽을 암호화 한 것 이라는 뜻이다.

 

아마도 “SSL 보안 웹 서버"라는 명칭 때문에 다소 혼동하는 것이 아닌가 한다.

 

 

두 번째 대책으로는 접근제어를 엄격하게 하는 것이다.

 

이를테면 평문으로 전송되는 ftp 프로토콜을 이용하다가 스니핑으로 인하여 아이디/암호가 유출되었다 하더라도 방화벽이나 ftp 데몬에서 접근 가능한 IP 주소가 제한되었을 경우 아이디/암호를 알더라도 접속할 수 없게 된다.

 

물론 IP 주소를 위조하여 접속시도를 할 수도 있겠지만 IP를 위조하여 tcp 접속을 하는 것은 사실상 매우 어렵다.

 

세 번째 대책으로는 기본적으로 모든 포트에 패킷을 포워딩(broadcasting)하는 더미 허브 대신 해당하는 목적지 포트에만 패킷을 전송하는 스위치(switch)를 사용하는 것이다.

 

따라서 스위치를 사용할 경우 promisc 모드로 설정해도 자기 자신을 목적지로 한 패킷 이외의 다른 패킷을 볼 수는 없는데, 이 때문에 스위치는 스니핑에 안전하다고 생각하는 것 같다.

 

참고로 더미 허브와 스위치의 가장 중요한 차이는 한 마디로 MAC(Media Access Control) 이라 할 수 있는데, 스위치의 경우 자체 메모리에 각 포트별 IP:MAC 주소 쌍을 기억하고 있으므로 더미허브와 같이 모든 포트에 패킷을 포워딩 할 필요 없이 특정한 IP를 목적지로 하는 패킷을 메모리에 저장된 특정한 포트에만 패킷을 전송하면 되기 때문이다.

 

반면, 더미 허브는 패킷이 들어와도 어떤 포트로 보내 주어야 할 지 모르기 때문에 모든 포트로 패킷을 보내게 되고 결국 이것이 브로드캐스팅 하는 것처럼 보이게 되어 모든 포트에서 트래픽을 볼 수 있게 되고, collision이 생겨 속도가 느려지는 것이다.

 

 

 

????[유용한 팁]

스위치 환경에서 tcpdump를 실행했을 때 이론대로라면 자기 자신을 목적지로 하는 IP만 보여야 하는데 다른 IP를 목적지로 한 패킷이 보이는 경우가 있다.

 

이것은 다음과 같은 경우에 보여 지게 된다.

 

 

 

미러링(span) 포트인 경우

해당 포트가 미러링 포트인 경우 미러링을 설정한 포트의 트래픽이 복사되므로 다른 포트의 트래픽이 보이게 된다.

 

스위치가 어떤 포트로 패킷을 포워딩 해 주어야 할 지 모르는 경우

특정한 경우에 어떤 포트로 패킷을 포워딩 하여야 할지 모르는 경우에 다른 포트의 트래픽이 보이게 된다.

 

스위치의 각 포트별 IP:MAC 정보 메모리가 가득 찰 경우

스위치에는 포트별 IP:MAC 정보만을 기억하고 있을 적은 메모리만 있으면 되는데, 스위치 내에서 위조된 대량의 IP:MAC 정보가 뿌려질 경우 메모리가 가득 차게 되면 MAC정보를 기억하고 있는 것이 의미가 없어지므로 더미허브와 동일하게 작동하게 된다.

 

기본적으로 모든 스위치는 완전히 모든 패킷을 정확히 필터링 하지 않는데, 특히 이러한 현상은 순간적으로 많은 트래픽이나 패킷을 전송할 경우 발생한다.

 

 

 

여기에서 세 번째 방법으로 제시한 더미 허브 대신 스위치 사용에 대해 잠깐 알아보도록 하자. 스위치를 사용할 경우 통신하고자 하는 목적지의 MAC 정보를 알기 위해 arp 요청 시에만 모든 포트에 브로드캐스트하고 이후에는 모두 유니캐스트(unicast)로 직접 1:1 통신을 하므로 상대적으로 스니핑에 안전하다고 할 수 있을 것이다.

 

하지만 과연 스위치를 사용한다면 스니핑에 안전할까? 답은 이론적으로는 그런 것 같지만 실제로는 결코 그렇지 않다.”이다.

 

왜냐하면 쉽지는 않지만 스위치 환경에서도 스니핑을 할 수 있는 방법이 있기 때문이다.

 

바로 arp 프로토콜의 특성을 이용하여 다음과 같은 몇 가지 방법이 가능하다.

관련자료

댓글 0
등록된 댓글이 없습니다.

공지사항


뉴스광장


  • 현재 회원수 :  60,043 명
  • 현재 강좌수 :  35,855 개
  • 현재 접속자 :  142 명