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

TCP자원고갈(RS-Resources Starvation)공격의 원리와 대응법1편 : TCP의 연결 상태와 공격 유형

작성자 정보

  • 구돌 작성
  • 작성일

컨텐츠 정보

본문

TCP자원고갈(RS-Resources Starvation)공격의 원리와 대응법1: TCP의 연결 상태와 공격 유형

 

 

TCP는 흔히 연결 기반(connection oriented) 프로토콜이라 부른다. 이는 다른 말로 TCP에서는 각각의 연결 상태를 메모리에 기억하고 있다는 의미가 될 것이다.

 

따라서 공격자는 TCP의 근본적인 특성을 악용하여 CPU나 메모리 등 시스템의 자원을 고갈시키도록 할 수 있는데, 이러한 형태의 서비스 거부 공격은 나프타(Naptha)”라는 이름으로 알려져 있으며 이 공격은 특정 시스템에 대한 취약성을 이용한 것이 아니라 TCP 자체에 대한 취약성을 이용한 것이므로 거의 모든 시스템이 이 공격에 취약하다고 할 수 있다.

 

따라서 이번 장에서는 실제 공격소스를 이용하여 이 공격이 어떠한 원리로 작동하는지 그리고 어떻게 대비해야 하는지 확인해 보도록 하자.

시스템에서 netstat을 실행한 후 State 부분을 보면 각 TCP 패킷의 11개 연결 상태(state)에 대한 모니터링이 가능하다. 11개의 상태 중 6개는 접속을 요청한 클라이언트의 패킷에 의존하여, 반드시 클라이언트로부터 특정한 패킷을 전송 받아야만 하는데 공격자는 이러한 특성을 이용하여 시스템의 자원을 고갈하도록 공격할 수 있다.

 

 

 

먼저 클라이언트와 서버 간에 접속을 시작하기 위해 다음과 같이 3 way handshake가 작동하며 netstat으로 이를 확인하면 각각의 상태는 아래와 같다.

 


 8ad405826b1f699df1b54f73cdfd22c7_1655108463_7057.png 

[그림] 3way handshake 작동상태

 

아래에서는 클라이언트에서 서버로 ftp 접속 시 snort IDS에서 캡처한 실제 패킷을 보면서 설명하도록 하겠다.

 

1단계: 클라이언트(192.168.0.2)ftp 접속을 위해 서버(192.168.0.1)21(ftp)번 포트에 접속 요청을 한다.

 

이때 seq번호는 hex346975이고 ack seq hex 번호는 0이다.

 

 

03/11-09:10:20.691235 192.168.0.2:1056 -> 192.168.0.1:21

TCP TTL:32 TOS:0x0 ID:47617 IpLen:20 DgmLen:44 DF

******S* Seq: 0x346975 Ack: 0x0 Win: 0x2000 TcpLen: 24

TCP Options (1) => MSS: 1460

 

2단계: 서버는 접속을 받아들여 클라이언트에게 SYN/ACK로 응답한다.

 

이때 seq 번호는 hex137F4이고 ack seq번호는 초기의 SYN1을 더한 (346976= 346975+1)이다.

 

 

03/11-09:10:20.691490 192.168.0.1:21 -> 192.168.0.2:1056

TCP TTL:128 TOS:0x0 ID:26112 IpLen:20 DgmLen:44 DF

***A**S* Seq: 0x137F4 Ack: 0x346976 Win: 0x2238 TcpLen: 24

TCP Options (1) => MSS: 1460

 

3단계: 클라이언트는 SYN/ACK에 대해 ACK로 응답한다.

 

이때 seq 번호는 같지만 ack seq번호는 SYN/ACKsyn seq 번호에 1 증가한다.

 

이때 TCP connectionESTABLISHED가 된다.

 

 

03/11-09:10:20.701260 192.168.0.2:1056 -> 192.168.0.1:21

TCP TTL:32 TOS:0x0 ID:47873 IpLen:20 DgmLen:40 DF

***A**** Seq: 0x346976 Ack: 0x137F5 Win: 0x2238 TcpLen: 20

 

이후부터는 클라이언트와 서버가 데이터 교환을 하게 된다.

 

 

 

이후 접속을 끊기 위해서는 그림과 같이 4way handshake가 작동하게 된다.

 

 

 

8ad405826b1f699df1b54f73cdfd22c7_1655108484_4989.png

[그림] 4 way handshake 작동 상태

 

같은 방식으로 접속을 끊는 과정의 패킷은 직접 캡처하여 분석해 보기 바라며 각각의 연결 상태에 대해 알아보자.

 

SYN_RCVD 상태

 

이는 SYN Flooding 공격에서 살펴본 것처럼 클라이언트가 SYN 패킷 발송 후 서버에서 SYN/ACK로 응답하였지만 클라이언트에서 응답 패킷인 ACK를 전송하지 않는 상태이다.

 

앞에서 살펴본 것처럼 존재하지 않는 IP를 소스로 하여 계속적으로 SYN 패킷을 발송하는 방법도 있지만 아래와 같이 IP를 위조하지 않고 자신의 IP를 사용하여 SYN 패킷을 발송 후 SYN/ACK를 받은 후에 ACK를 발송하지 않도록 하는 방법도 있다.

 

이는 공격자의 호스트에서 다음과 같이 실행하면 된다.

 

참고로 여기에서 공격자의 IP211.47.65.57이고 공격 대상호스트(victim)211.47.68.2180번 포트(http)라 가정한다.

 

 

# iptables -A INPUT -s 211.47.68.21 -p tcp --sport 80 -j DROP

# synsend 211.47.68.21 80 211.47.65.57 1

 

위의 의미는 각각 다음과 같다. 먼저 두 번째 줄부터 살펴보면 공격자인 211.47.65.57에서 211.47.68.2180번 포트로 SYN 패킷을 매 1밀리 초 단위로 발송한다는 의미이다.

 

(여기에서 synsend는 나프타 공격 소스에 포함된 별도의 실행 프로그램이다.

 

) 그리고 첫 번째 줄의 의미는 공격에 대한 응답패킷(SYN/ACK flag가 설정된 패킷)인 소스가 211.47.68.21이고 소스 포트가 80인 패킷을 DROP한다는 것이다.

 

따라서 공격자인 211.47.65.57SYN/ACK를 수신하지 않으므로 ACK로 응답하지 않게 되고 공격을 당하는 211.47.68.21에서 “netstat -na”를 실행하면 다음과 같이 SYN Flooding을 당할 때와 동일하게 보이게 된다.

 

, SYN Flooding을 당한다고 해서 공격지의 소스 IP가 모두 존재하지 않는 IP는 아니라는 것을 알 수 있으며 만약 이와 같은 현상이 나타난다면 해당 IP에서 직접 공격한다는 것을 의미한다.

 

 

8ad405826b1f699df1b54f73cdfd22c7_1655108513_6838.png
 

[그림] SYN 패킷을 받을 때 netstat 실행 화면

 

 

ESTABLISHED 상태

 

이는 클라이언트로부터 ACK를 받아 3 way handshake가 완료된 상태이며 클라이언트로부터 데이터 전송을 기다리게 된다.

 

이 상태에서 벗어나기 위해서는 클라이언트로부터 FIN 패킷을 전송받거나 timeout이 될 때까지 기다린 후 FIN 패킷을 발송하여 CLOSE 상태로 바뀌는 것이다.

 

그러나 timeout 시간이 길기 때문에 클라이언트로부터 FIN 패킷을 받지 않는 한 공격에서 벗어나기란 쉽지 않다. 이를 위해 공격자는 공격자의 호스트에서 다음과 같이 실행할 수 있다.

 

 

#iptables -A INPUT -p tcp -s 211.47.68.21 --sport 80 -j DROP

#synsend 211.47.68.21 80 211.47.65.57 1

#srvr -ASa 211.47.68.21



위의 두 줄의 의미는 앞에서 설명한 바와 동일하다. 추가적으로 나프타 공격 프로그램인 srvr에서의 옵션 중 대문자는 inbound 되는 패킷의 tcp-flag, 소문자는 이에 대한 outbound 되는 패킷의 tcp-flag을 의미하는데, 위의 경우 SYN/ACK에 대해 ACK로 응답한다는 의미이다.

 

위와 같이 실행 시 공격자의 화면은 다음과 같이 보이게 된다.

 

아래 화면에서는 inbound 되는 SYN/ACK에 대해 ACK로 응답하는 것을 보여주고 있다.

 

 


8ad405826b1f699df1b54f73cdfd22c7_1655108541_5118.png
 

[그림] ACK로 응답할 때의 netstat 화면

 

다음은 공격을 당하고 있는 211.47.68.21에서 netstat을 실행한 예이다.

 

보는 바와 같이 ESTABLISHED 상태가 계속 유지되고 있는 것을 볼 수 있다.

 

 

 

공격이 장시간 지속될 경우 시스템의 자원이 고갈되는 것은 물론이고, 아파치등과 같은 각 서비스 데몬들의 경우 클라이언트의 요청을 처리할 수 있는 프로세스의 개수가 한정되어 있는데, 위와 같이 공격을 당하게 되면 짧은 시간 내에 허용된 프로세스의 개수가 가득 차게되어 더 이상의 웹 접속을 받아들일 수 없는 상태가 될 것이다.

 

따라서 사이버 시위 등에 악용될 경우 매우 치명적인 공격 형태가 될 것이다.

 

단 공격자의 IP는 위조될 수 없으므로 확인 후 차단할 수는 있다.

 

 

 

8ad405826b1f699df1b54f73cdfd22c7_1655108559_8539.png
 

[그림] ESTABLISHED 상태

 

LAST_ACK 상태

 

ESTABLISHED 상태에서 클라이언트로부터 FIN 패킷을 받으면 서버는 ACK로 응답한다.

 

이후 FIN 패킷을 다시 발송한 후 클라이언트로부터 마지막 ACK 패킷인 LAST_ACK를 기다리게 되는데, 공격자는 이를 악용하여 SYN Flooding 공격을 한 후 SYN/ACK에 대해 FIN/ACK로 응답하고, 서버에서 FIN 패킷 이후 ACK로 응답하면 클라이언트에서는 ACK로 응답하여야 하는데, 응답하지 않도록 한다.

 

결국 서버에서는 LAST_ACK가 가득 차게 되어 더 이상 서비스가 불가능하게 된다.

 

이와 같은 원리를 바탕으로 이런 공격을 위하여 공격자는 공격자의 호스트에서 다음과 같이 실행할 수 있다.

 

 

# iptables -A INPUT -p tcp -s 211.47.68.21 --sport 80 -j DROP

# synsend 211.47.68.21 80 211.47.65.57 1

# srvr -SAfa 211.47.68.21

 

처음 두 줄은 앞과 동일하며 세 번째의 의미는 211.47.68.21로부터 전송되는 SYN/ACK에 대해 FIN/ACK로 응답한다는 의미이다.

 

 

8ad405826b1f699df1b54f73cdfd22c7_1655108581_3086.png
 

[그림] LAST_ACK 상태

 

마찬가지 원리를 이용하여 FIN_WAIT_1 FIN_WAIT_2, CLOSING 상태를 이용한 공격도 가능하다

관련자료

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

공지사항


뉴스광장


  • 전체 회원수 59,444 명
  • 전체 게시물 30,916 개
  • 전체 댓글수 11,873 개