TCP SYN Flooding 공격의 원인과 해결책2편 : SYN Flooding 공격의 파악방법
작성자 정보
- 관리자 작성
- 작성일
컨텐츠 정보
- 2,127 조회
- 0 추천
- 목록
본문
SYN Flooding 공격의 파악 방법
그렇다면 SYN Flooding 공격을 당하고 있는지 여부는 어떻게 확인 할 수 있을까?
공격여부를 확인하기 위해서는 앞에서 잠깐 언급한 바와 같이 시스템에 로그인 한 후 "netstat" 이라는 명령으로 확인할 수 있는데, netstat은 시스템의 각종 네트워크 정보를 알려주는 명령어로서 네트워크 연결, 라우팅 현황, 인터페이스 통계 등의 정보를 확인할 수 있는 매우 유용한 네트워크 명령어이다.
netstat의 결과 중 중요한 부분이 바로 State에 보이는 연결 상태 부분인데 이 상태에 대해 알아보도록 하자. 참고로 이는 해당 호스트가 클라이언트의 역할을 하는지 또는 서버 역할을 하는지에 따라 다르게 보이게 된다.
이를테면 데이터베이스 서버와 연동된 웹 서버인 경우 웹으로 향하는 클라이언트의 접속에 대해서는 서버로 작동하지만 이후 웹에서 데이터베이스 서버를 호출하는 프로세스에 대해서는 클라이언트로 작동하게 되는 것이다.
netstat -na로 확인해 보면 Local Address, Foreign Address, State 등의 정보가 출력되는데, 이 중 State 부분에 보이는 메시지를 주목하면 된다.
각 상태에 대한 자세한 내용은 다음 그림을 참고하기 바라며 앞의 세 단계는 세션을 형성하기 위한 3 way handshake를 나타낸 것이고 아래의 네 단계 그림은 세션을 끊기 위한 4 way handshake를 나타낸 것이다.
[그림] 각 상태별 구성도
LISTEN : 서버의 데몬이 떠서 접속 요청을 대기 또는 기다리는 상태
SYN_SENT : 로컬의 클라이언트 응용프로그램이 원격 또는 로컬 호스트에 SYN 패킷을 보내어 연결을 요청한 상태
SYN_RECEIVED : 서버가 클라이언트로부터 접속 요구(SYN)를 받아 클라이언트에게 SYN/ACK로 응답하였지만 아직 클라이언트에게 ACK 확인 메시지는 받지 않은 상태
ESTABLISHED : 3 way handshake가 완료된 후 서로 연결되어 실제 데이터 교환이 이 루어지고 있는 상태
FIN_WAIT1, CLOSE_WAIT, FIN_WAIT2 : 서버에서 연결을 종료하기 위해 클라이언트에게 또는 클라이언트가 서버에게 종결을 요청하고 회신을 받아 종료하는 과정의 상태
CLOSING : 흔하지 않지만 주로 확인 메시지가 전송도중 분실된 상태
TIME_WAIT : 연결은 종료되었지만 분실되었을지 모를 느린 세그먼트를 위해 당분간 소켓을 열어놓은 상태
CLOSED : 완전히 종료
접속이 많은 서버에서 netstat을 실행하면 아래와 같이 “warning, got duplicate tcp line”라는 메시지가 보이는 경우가 있다.
tcp 0 0 X.X.X.X:80 X.X.X.X:1035 TIME_WAIT tcp 0 0 X.X.X.X:80 X.X.X.X:2028 TIME_WAIT warning, got BOGUS tcp line warning, got BOGUS tcp line
이는 주로 KeepAlive가 Off 로 설정된 웹서버에서 일부 보여 지는데, 동일한 IP:PORT로 연결 후 빠르게 끊겼다가 그 정보가 다시 그대로 재사용될 때 발생하는 메시지로 이론상으로는 발생하지 말아야 하지만 그 자체로는 보안상의 이슈나 성능상의 이슈는 아니므로 걱정하지 않아도 된다.
만약 이 메지시를 보이지 않도록 하려면 아래의 두 커널 파라미터를 disable하는 0으로 설정하면 된다.
net.ipv4.tcp_tw_reuse = 0 net.ipv4.tcp_tw_recycle = 0
|
각각의 연결 상태는 통신 상황에 따라 순간적으로 매우 복잡하게 변화하는데, 이 중 주로 주목하여야 할 상태는 바로 SYN_RECEIVED(Windows에서는 SYN_RECEIVED로 보이지만 리눅스에서는 SYN_RCVD로 보인다.)이다.
앞에서 잠시 언급한 대로 이 상태는 클라이언트의 확인 메시지를 기다리는 상태이지만 정상적인 상태에서 이 과정은 순간적으로 일어나므로 실제 netstat으로 보이는 경우는 거의 없다. 따라서 "netstat -na|grep SYN_RECV"로 확인해 보아서 “SYN_RECV"라는 메시지가 많이 보인다면 SYN Flooding 공격 여부를 의심해 볼 수 있다.
하지만 공격을 받지 않고 있는 정상적인 상황인데도 SYN_RECV가 보이는 경우도 있으므로 주의하여야 한다.
이는 주로 다음과 같은 경우이다.
① 동시 접속자수가 많을 경우 -이를테면 아파치 웹 서버에서 기본적으로 MaxClient가 150으로 설정되었는데, 접속이 많아 http 프로세스의 개수가 최대치인 150개에 도달하였을 경우 초과 이후의 접속에 대해서는 요청(SYN)이 들어와서 서버에서 응답(SYN/ACK)해도 이미 MaxClient에 도달하여 이후의 ACK응답을 서버가 처리할 수 없으므로 SYN_RECV 상태가 된다.
② 네트워크 장애인 경우 - 서비스 중인 시스템이나 네트워크에 순간적으로 네트워크 장애가 발생할 경우 응답 패킷을 받지 못하면 마치 공격을 당하는 것처럼 보이게 된다.
③ 네트워크가 느린 경우 - SYN 요청에 대해 SYN/ACK로 응답하였지만 네트워크가 느려 ACK 응답이 빨리 오지 않는 경우가 있다.
이러한 경우에는 해당 IP로 ping을 해 보아 네트워크가 연결되어 있는지 여부를 확인하면 된다.
만약 ping은 잘 나가는데, SYN_RECV로 보이면 공격이 아니므로 무시하면 되고 ping등 네트워크가 반응하지 않는다면 공격일 가능성이 높다.(뒤에서 다시 살펴보겠지만 반드시 그런 것만은 아니다.) |
다음은 실제 시스템에서 공격 코드를 이용하여 “netstat -na|grep SYN”으로 SYN_RECV 상태를 확인한 부분이다.
[그림] SYN Flooding 공격 시 netstat으로 확인한 결과
분명히 localhost에서 공격을 시도했음에도 위 그림에서처럼 80번 포트로 SYN 패킷을 요청한 IP 주소는 랜덤하게 보이고 있어 도무지 어떤 IP에서 공격하고 있는 것인지 알 수 없다. 이 때문에 SYN Flooding 공격에 대해 알지 못하던 당시, 처음에는 ‘아! 이런 것이 말로만 듣던 분산서비스거부 공격이구나!’라고 생각했던 적이 있었다.
어쨌든 실제로 netstat으로 보이는 공격지 IP 를 확인해 보면 모두 아예 존재하지 않거나 현재 인터넷에 연결되어 있지 않은 IP들이다.
즉 소스 IP는 모두 위조된 것이라고 판단할 수 있다.
실제 공격 소스 코드 중 소스 IP를 생성하는 부분을 보면 아래와 같이 0부터 255까지 임의의 값을 뽑아 IP 주소로 설정하는 것을 확인할 수 있다.
{ a = getrandom(0, 255); b = getrandom(0, 255); c = getrandom(0, 255); d = getrandom(0, 255); sprintf(junk, "%i.%i.%i.%i", a, b, c, d); me_fake = getaddr(junk); } |
SYN Flooding 공격을 받아 서비스가 중단되었을 경우 해당 포트로 telnet 접속을 해 보면 아래와 같이 마치 방화벽에서 DROP으로 차단된 것처럼 보이게 된다.
이는 SYN 패킷 요청에 대해 SYN/ACK 응답이 오지 않기 때문에 결국 timeout이 될 때까지 수십여 초를 기다린 것을 나타낸다.
# telnet web.server.com 80 Trying 192.168.1.3... telnet: Unable to connect to remote host: Connection timed out |
만약 포트 자체가 시스템에서 리슨하지 않고 있다면 아래와 같이 수초 내에 바로 응답이 올 것이다.
이는 해당 포트에 대한 SYN 패킷에 대해 포트에서 리슨하는 데몬이 없기 때문에 시스템에서 reset 패킷으로 응답했기 때문이다.
# telnet web.server.com 80 Trying 192.168.1.3... telnet: Unable to connect to remote host: Connection refused |
위 두 상황의 차이점과 timeout과 refused 메시지의 차이를 분명히 이해하기 바란다. 그리고 여기에서는 웹 서비스(80번 포트)를 예로 들어 설명했지만 SYN Flooding 공격이 반드시 웹 서비스에 대해서만 일어나는 것은 아니다. 일반적으로 웹 서비스가 가장 대중적이고 치명적이기 때문에 예로든 것뿐이며 메일 서버인 경우에는 25번이, FTP 서버인 경우 21번등 모든 포트가 공격 대상이 될 수 있다.
관련자료
-
이전
-
다음
