네트워크 기본학습 19~24

서비스 거부DoS:Denai of Service 공격
개요
- 시스템이 정상적인 서비스를 할 수 없도록 서비스를 마비시키는 형태의 공격
- 대상 시스템의 가용성을 떨어트리는 것이 공격의 목적
- 파괴 공격, 시스템 자원 소진 공격, 네트워크 자원 소진 공격
- 서비스 거부DoS : 공격자가 단일 컴퓨터를 이용하여 공격하는 형태
- 분산 서비스 거부DDos : 공격자가 분산된 다수의 컴퓨터 또는 장치들을 이용해 공격하는 형태

1) Ping of Death Attack
- ping 명령을 통해 ICMP 패킷을 정상적인 크기보다 크게 만들어 MTU에 의해 다수의 IP 단편화가 발생하게 한다
- 수신측에서 단편화된 패킷을 재조합하는 과정에서 많은 부하가 발생하거나, 재조합 버퍼의 오버플로우 발생

(+ 이더넷 MTU 1500)

대응책
- 보통의 ICMP 패킷은 분할하지 않으므로 분할된 패킷을 공격으로 의심하여 탐지
- 반복적으로 들어오는 일정 수 이상의 ICMP 패킷을 무시하게 설정

 

실습
: 65000byte 이상의 ICMP 패킷을 전송해보기

hping3 --icmp 192.168.0.1 -d 65000

 

Fragmented IP Protocol (proto=ICMP 0x01, off=26640, ~
Fragmented IP Protocol (proto=ICMP 0x01, off=28120, ~
Fragmented IP Protocol (proto=ICMP 0x01, off=29600, ~

이런식으로 단편화된 ICMP 패킷 결과가 보이면 Ping of Death Attack 공격을 의심

 

 

2) Land Attack
- 출발지와 목적지가 동일한 패킷을 공격대상에 보내, 수신자가 자기 자신에게 응답을 보내 무한루프 상태에 빠지도록 함

대응책
- 대부분의 운영체제는 보안패치가 적용되어 있다.
- 출발지와 목적지 ip 주소가 동일한 패킷의 경우 모두 폐기
- 침입차단시스템(방화벽), 라우터 등 패킷 필터링 장비를 통해 출발지 IP와 목적지 IP가 같으면 차단하도록 설정

 

 

** 3) Smurf Attack 스머프 공격
개요
- 출발지 IP를 희생자 IP로 위조한 후, 증폭 네트워크로 ICMP Echo Request를 브로드캐스트한다
- 다수의 ICMP Echo Reply가 희생자에게 전달되어 서비스 거부를 유발시킨다
- Directed Broadcast (원격 브로드캐스트) : IP 주소 호스트 ID 비트를 모두 1로 설정하여 브로드캐스트 하는 방식
- Amplifier(Bounce) Network : 증폭 네트워크

대응책
- 동일한 ICMP Echo Reply 패킷이 다량 발생하면 침입차단시스템을 통해 차단시킨다
- 증폭 네트워크로 사용되는 것을 막기 위해, Directed Broadcast 패킷을 허용하지 않도록 라우터 설정을 한다 ( no ip directed-broadcast )
- 브로드캐스트 주소로 전송된 ICMP Echo Request 메시지에 응답하지 않도록 설정

(ex 192.168.55.0/24 대역의 브로드캐스트 주소 : 192.168.55.255 (255 = 비트를 모두 1로 설정(11111111))

 

실습
희생자A 공격자B 증폭자C 필요
ping -b 192.168.C.255 로 원격 브로드캐스트가 되는지 확인
hping3 --icmp --spoof 192.168.A.01 192.168.C.255
A의 ip로 위조한 후, 증폭역할을 하는 C에게 브로드캐스트

Destination의 IP주소가 끝부분이 255로 되어있다 = 스머프 공격 의심

 

 

4) Teardrop Attack 티어드랍
개요
- IP패킷 재조합 과정에서 조작된 단편의 오프셋offset 정보로 인해 수신 시스템의 오류나 부하가 발생
- 공격자는 IP패킷의 offset값을 서로 중첩되거나 멀리 떨어지게 조작해 전송한다
- 유사한 공격으로 Bonk, Boink가 있음

대응책
- 운영체제의 보안패치를 적용

 

 

5) IP 단편화의 취약점을 이용한 패킷 필터링 장비(방화벽 등)우회 공격
- Tiny Fragment 작은 단편 공격
- Fragment Overlap 단편 중첩 공격
- DoS공격이 아닌 침입차단시스템(방화벽)을 우회하여, 허용하지 않는 공격 대상 시스템의 서비스에 접근하기 위한 공격

Tiny Fragment 작은 단편 공격
- 최초 IP 단편을 매우 작게 만들어(목적지 포트가 포함되지 않음) 전송한다 (목적지 포트가 없어서 필터할 기준정보가 없으므로, 통과됨)
- 두 번째 IP 단편에 목적지 포트를 포함한다
- 목적지 서버에서 단편들이 재조합 되어 원하는 목적지 포트로 연결된다

Fragment Overlap 단편 중첩 공격
- 오프셋을 조작하여, 첫 번째 단편의 일부분을 두 번째 단편이 덮어쓰도록 하여 우회한다
- 첫 번째 ip단편에는 허용된 목적지 포트를 설정하고, 두 번째 ip단편에는 허용되지 않은 포트를 설정한다
- 재조합 될 때 TCP 헤더가 중첩되어 덮어쓰면서, 허용되지 않은 포트로 접근

 

대응책
- 단편화된 패킷들을 재조합하여 IP 단편화를 이용한 우회 공격의 탐지가 가능한 패킷필터링 장비를 적용

 

 

-19 END-

 

 

 

분산 서비스 거부 DDoS:Distributed Denial of Service 공격
개요
- 분산된 다수의 좀비 PC/바이러스에 의해 공격대상 시스템의 서비스를 마비시키는 공격 형태
- 공격자Attacker : 봇 마스터Bot Master. 공격 명령을 전달하는 해커의 컴퓨터
- C&C 서버 : (=C2서버) 공격자로부터 직접 공격 명령을 전달받는 시스템.
- 좀비PC(Device) : C&C서버로부터 명령받아 실제 공격을 수행하는 pc/device. (=Bot, Slave, Agent)
- Target : 공격대상 시스템
- 공격 절차
1. 공격자는 C&C서버를 구축
2. 불특정 다수의 PC에 봇을 배포
3. 불특정 다수의 사용자가 봇에 감염
4. 봇이 C&C서버에 접속(도메인 주소)해, 감염PC는 봇넷의 일원이 됨
5. 공격자가 C&C서버에 명령하고, C&C서버가 봇에 명령을 전달한다
6. 봇은 명령에 따라 다양한 공격을 수행하고 다른 PC로 봇을 전파

봇, 봇넷Botnet
개요
- 봇Bot은 보안상 결함을 이용해 원격에서 해당 시스템을 제어할 수 있는 프로그램을 의미함
- 봇은 다양한 악성코드들의 특성을 복합적으로 가지고, 정보유출, 디도스, 스팸발송 등 다양한 형태로 공격
- 봇에 감염된 다수의 좀비Device로 구성된 네트워크를 봇넷Botnet이라고 함
- 봇넷은 중앙집중형인 IRC 봇넷, HTTP 봇넷, 분산형인 P2P봇넷으로 분류

가) 봇넷 명령 제어 방식
1. 중앙집중형 명령/제어
- IRC 봇넷이 주를 이루다가 대응을 어렵게 하기 위해 웹 프로토콜인 HTTP를 기반으로 진화
- 다수의 좀비를 C&C서버에 등록하고, 다수의 좀비들이 C&C서버와 연결되어 명령을 수행
- 명령/제어 구조가 비교적 간단하지만 C&C서버가 차단되면 전체 봇넷이 중단될 수 있다
- IRC봇넷(=Rbot), HTTP 봇넷(=Robax) 

 

2. 분산형 명령/제어 방식
- 참여 멤버들이 모두 C&C 역할을 수행하여, 그룹에 명령을 전파하는 분산제어방식
- 봇넷을 보호하고 네트워크가 끊어지는 것을 방지하기 위한 방식
- 모두가 C&C역할을 하므로 탐지나 차단이 어렵다
- P2P 봇넷(=Storm, Peacomm 등)

 

나) DNS 싱크홀SinkHole 서비스
- 악성 봇에 감염된 PC가 C&C서버로 연결을 시도할 때, C&C서버 대신 싱크홀 서버로 우회시켜 해커의 명령을 받지 않게 해주는 시스템/서비스
- 악성 봇을 미리 파놓은 구덩이(싱크홀 서버)로 유도하는 방식
- 한국인터넷진흥원KISA에서 국내 ISP업체 등과의 협력을 통해 서비스 제공

 - 동작 방식 (꼭 이해할 것)
1. C&C서버 목록을 ISP 등 DNS 싱크홀 적용 기관의 DNS 서버에 주기적으로 업데이트
2. 악성 봇에 감염됨 PC가 싱크홀이 적용된 DNS에 C&C서버에 대한 질의 요청
3. DNS는 C&C서버가 아닌 싱크홀 서버 IP를 반환
4. 악성 봇 PC는 C&C서버가 아닌 싱크홀 서버로 접속하여, 공격자의 명령을 회피할 수 있다

 

 

 

봇넷의 보안장비 우회 기법
개요
- 봇넷을 구성하는 좀비PC나 랜섬웨어 등의 악성코드는 C&C서버에 접속하는 과정에서 C&C서버 도메인에 대해 질의한다
(보안장비는 C&C서버 도메인이나 IP를 블랙리스트(차단목록)로 등록하여 탐지/차단   *화이트리스트: 허용할 목록)
- 공격자는 보안장비에 의해 탐지되지 않도록 다양한 보안장비 우회 기법을 적용

가) Fast Flux 패스트 플럭스 기법
- C&C서버의 IP를 지속적으로 변화시킴
- 하나의 C&C서버 도메인에 다수의 IP를 등록하는 방식

- 미리 확보해 둔 다수의 IP주소를 DNS 레코드에 추가하고, TTL 값을 매우 작게 주어 라운드 로빈 방식으로 응답되도록 함

- 7계층 보안장비가 없는 상황일 때, IP일부만 차단해서는 접속을 완전차단 할 수 없다

나) DGA 기법 Domain Generation Algorithm
- C&C서버 도메인을 지속적으로 동적 생성(임시 도메인 생성)

- 도메인을 새롭게 계속 등록함

다) Domain Shadowing 도메인 쉐도잉 기법
- 정상 도메인 관리자 정보 탈취 및 불법적으로 서브 도메인을 만들어 탐지하기 어렵게 함

- 드라이브 바이 다운로드(DBD: Drive by Download) 공격 도구인 앵글러 익스플로잇 도구에서 탐지 회피를 위한 기술

- 주로 악성코드 유포지로 흘러가는 경유지 도메인으로 사용됨

 

 

DDoS 공격유형

대역폭 소진공격	서비스 마비공격
UDP/ICMP Flooding SYN Flooding	HTTP GET Flooding
증상 : 회선 대역폭 고갈, 동일 네트워크를 사용하는 모든 서비스에 접속장애	증상 : HTTP 서버 과다 접속으로 인한 접속장애, 공격대상 시스템만 피해
* UDP/ICMP Flooding (다량의 UDP/ICMP 패킷) ** TCP SYN Flooding (다량의 SYN 패킷) DNS Query Flooding TCP Flag Flooding TCP Session Flooding HTTP Continuation	* HTTP GET Flooding (동일한 URL 반복 요청) HTTP GET Flooding with Cache-Controll(CC Attack) * Slow HTTP POST DoS (POST 메소드) * Slow HTTP Header DoS (헤더부분만 먼저 수신) * Slow HTTP Read DoS (Window크기, 처리율 감소시킨 뒤 송신) 해시도스(HashDoS) 헐크도스(HulkDoS)

 

 

20 END  --

 

 

네트워크 대역폭 소진 공격 실습
가) UDP Flooding
- 다량의 UDP 패킷을 서버로 전송하여 네트워크 대역폭을 소진시킨다

예시
Time   Source             Destination    DSP Port  Protocol
12.49  116.11.22.33   192.168.0.14   53              DNS
12.55  128.66.12.11   192.168.0.14   53              DNS
...
12.59  55.112.63.01   192.168.0.14   53              DNS
13.01  215.0.22.100   192.168.0.14   53              DNS

Port 53은 UDP를 뜻한다
Time을 보면 짧은시간동안 다량의 패킷 전송
Source는 다양한 IP로 위조


나) ICMP Flooding
- 다량의 ICMP 패킷을 서버로 전송하여 네트워크 대역폭을 소진시킨다

예시
Time   Source             Destination    DSP Port  Protocol
12.49  116.11.22.33   192.168.0.14                    ICMP
12.55  128.66.12.11   192.168.0.14                    ICMP
...
12.59  55.112.63.01   192.168.0.14                    ICMP
13.01  215.0.22.100   192.168.0.14                    ICMP

Port 표기 없음, Protocol에 ICMP 표기

 

 

 

서버/서비스 자원 소진 공격 실습
가) *TCP SYN/Flooding 공격
개요
- TCP 연결 설정 과정(3 way handshake)의 취약점을 이용
- TCP 연결 자원(backlog queue)을 소진시켜 외부로부터 TCP 연결 요청을 받을 수 없게 만드는 서비스 거부 공격 기법

공격원리
- Client가 SYN 요청을 보내면 Server는 SYN+ACK 응답을 보내고 그 정보를 backlog queue(SYN RECV 상태 - 연결대기 incomplete connection queue)에 저장한다

- Client가 ACK 응답을 주면 Completed Connection queue(요청완료,  ESTABLISHED 상태)에 저장되었다가, accept() 시스템 콜을 통해 Connected Socket에 전달되면서 queue가 비워짐

- Client가 ACK 응답을 주지 않고 계속 대기하면서 요청이 쌓이면서 백로그큐backlog queue가 꽉 차버리면, 더 이상 연결요청을 받을 수 없게 된다

 

netstat -antp | grep SYN RECV
(a 모든상태 소켓들, n 숫자형식, t tcp만, p 프로세스명/pid명)

출력예시
tcp        0    0      192.168.11.133:80      252.15.11.16:2020      SYN_RECV
tcp        0    0      192.168.11.133:80      11.251.223.12:115      SYN_RECV
tcp        0    0      192.168.11.133:80      116.224.101.25:80      SYN_RECV
tcp        0    0      192.168.11.133:80      12.252.123.21:100      SYN_RECV
tcp        0    0      192.168.11.133:80      117.10.111.144:90       SYN_RECV

 

=> 요청 IP는 위조되어 일관성이 없음. SYN_RECV 상태

 

패킷캡쳐

SYN, SYN+ACK, RST 만 보일경우(=ACK 응답이 오지 않음)

SYN Flooding 공격을 의심

 

tcpdump 캡쳐

tcpdump -nn "tcp port 80"
=> tcp이고 port가 80인 데이터 덤프뜨는 명령어

IP 192.168.11.133:80 > 143.128.111.122.2202: S 4069142400: 4069142400(0) ack 2040874700 win 5840 <mss 1460>
IP 143.128.111.122.2202 > 192.168.11.133:80: R 2040874700: 2040874700(0) win 32767
IP 192.168.11.133:80 > 111.12.123.45:10: S 4069142477: 4069142477(0) win 5840 <mss 1460>
IP 192.168.11.133:80 > 214.0.22.11:9080: S 7069142411: 7069142411(0) ack 1020441155 win 5840 <mss 1460>
IP 111.12.123.45:10 > 192.168.11.133:80: R 4069142478: 4069142478(0) win 32767

=> SYN, SYN+ACK, RST 만 보일경우(=ACK 응답이 오지 않음)

 

실습
공격당할 pc에서
sysctl -a | grep backlog로 현재 크기 확인 후
sysctl -w net.ipv4.tcp_max_syn_backlog=10 으로 크기를 확 줄여놓는다
tcpdump를 켜놓고, netstat도 1초 간격으로 찍도록 함
( tcpdump -nn "tcp port 80"
while true; do netstat -antp | grep : 80; sleep 1; echo "..."; done )
service testSite restart            <- 미리 만들어놓은 실습용 사이트 필요

공격할 pc에서
hping3 -S --rand-source 192.168.공격할ip.주소 -p 80 --fast
(SYN 플래그 설정, 랜덤 IP로 공격, 빠르게)

=> 공격당하면 tcpdump와 netstat의 로그가 엄청나게 쌓이고, 사이트도 열리지 않고 멈춘다

 

대응책
- 완전한 3-way-handshake가 이루어지지 않으면, backlog queue가 소진되지 않도록 설정 (= Syn Cookie)
- Syn Cookie 설정 : sysctl -w net.ipv4.tcp_syncookies = 1

- 방화벽 또는 DDoS 대응 장비를 이용하여 동일 Client의 연결SYN 요청에 대한 임계치 설정을 통해 과도한 연결요청 차단

- First SYN Drop 설정 : SYN 패킷을 보내는 Client가 실제로 존재하는지 파악하는 방법. 첫 번째 SYN 패킷을 Drop하여, 재요청 패킷이 도착하는지 확인하여 출발지 IP가 위조되었는지 판단한다
- backlog queue의 크기를 늘려준다 (임시적 조치, sysctl -w net.ipv4.tcp_max_syn_backlog = SIZE)
- STN+ACK에 대한 대기시간(time out)을 줄인다

Syn Cookie 설정 (TCP 표준에 명신된 방식)
- SYN 요청에 대한 응답으로 syn/ack를 전송할 때, ISN(초기 Seq.Num)에 cookie값을 넣어 전송하는 방식
- 상대방 ack 응답의 Ack.num 값을 cookie값과 비교해 연결의 유효성을 확인하고 TCP 연결을 설정한다
(Client가 A를 보내면, Server는 backlog queue를 사용하지 않고, Cookie를 만들어 Seq.num에 넣어 전송한다.
Client는 Cookie+1하여 Acknowledgment Number를 전송, 서버에서 유효한 값으로 검증되면 backlog queue를 이용함)

- 단점은 Syn Cookie를 사용하는데 오버헤드가 발생하므로 성능이 좋지 않은 서버는 문제가 될 수 있다(스스로 DoS 상태가 되는). 연결을 담당하는 별도의 Proxy 서버를 두는 것이 좋음

(요새는 그냥 DDoS 장비를 쓰긴 함)

 

 

- 21 END -

 

 

*** HTTP GET Flooding 공격
- 동일한 동적 컨텐츠(jsp, asp, php 등 요청할때마다 서버에서 처리됨)에 대한 HTTP GET 요청을 다량으로 발생시켜, 웹서버가 해당 요청을 처리하기 위해 서버 자원을 과도하게 사용(부하 유발)하도록 하여 정상적인 요청을 처리하지 못하도록 하는 서비스 거부 공격 (정적 컨텐츠 : html)

 

(짤막지식
HTTP 요청 분류
1. GET : 해당 자원 요청
2. POST : 데이터 전송후 처리결과 요청

 

Request Line요청라인정보 (구성: 요청메서드  /URI  HTTP버전     -> ex GET /test.php HTTP/1.1) )

 

access_log 필드 구성
요청IP - - 응답시간 "요청라인" 응답코드 총바이트수 "referer" "user agent"

(포맷 종류

CLF (Commo Log Format)
ELF (Extended Log Format) => CLF보다 referer, user ugent 정보가 더 추가됨

 

referer
- 참조링크 (A링크 요청 전에, B링크에 위치해있었던 정보. 유입경로.) )

 

 

웹서버 access 로그 분석
ex cat log-20240321 | awk -F " " '{print $1}' | sort | uniq -c | sort -rn

=> 첫번째 필드인 요청 IP를 sort하고, 중복행을 삭제하고 카운트 넣어서, 카운트를 숫자기준으로 역순(큰것부터) 정렬

필터 명령어
ex cut -d ":" -f 1                  => :를 기준으로 첫번째 필드정보
ex awk -F ":" '{print $1}'      => :를 기준으로 print 첫번째 필드
ex sort                                => 오름차순 정렬 (문자기준)
ex sort -r                            => 내림차순 정렬 (문자기준)
ex sort -n                            => 오름차순, 숫자기준 정렬
ex uniq                                => 연속된 중복된 행 제거
ex sort | uniq                      => sort 후 중복된 행 제거
ex sort | uniq -c                  => sort 후 중복된 행 제거하되 카운트해줌
ex sort | uniq -c | sort -r    => sort 후 중복된 행 제거하되 카운트해주고 역순정렬

문자기준 정렬이란? 3과 21중에 3이 더 크다고 판단하는 것(문자순으로 2보다 3이 더 뒤이므로)

 

 

와이어샤크 툴로 본 패킷
Protocol     Info
HTTP         GET /home/index.php HTTP/1.1
HTTP         HTTP/1.1 200 OK (text/html)
HTTP         GET /home/index.php HTTP/1.1
...
HTTP         HTTP/1.1 200 OK (text/html)
HTTP         GET /home/index.php HTTP/1.1
HTTP         HTTP/1.1 200 OK (text/html)
HTTP         GET /home/index.php HTTP/1.1

=> 짧은 시간에 GET 요청이 많이 쌓인 상태 = HTTP GET Flooding 공격 의심

 

 

ngrep으로 확인하는 패킷 (네트워크 스니퍼 도구. 시험에 출제된 적 있음)

ngrep -qtW byline
(ngrep 네트워크 트래픽 grep, q#표시생략quiet 모드, t타임스탬프, W포맷, byline개행처리(안하면 .. 으로 표기됨))
=> 주고받는 내용이 출력됨 (html 전체 출력 등)

ngrep -qtW byline | grep "GET /index.php"

=> 요런 내용이 나오면, 동일한 동적컨텐츠 호출로 인한 HTTP GET Flooding 공격

 

 

 

Hulk DoS 공격
- 공격대상 웹사이트 주소
- 정보요청라인 :

GET /index.php?AC=1 HTTP/1.1

GET /index.php?AG=2 HTTP/1.1

GET /index.php?AA=3 HTTP/1.1        ←Query String 파라미터가 계속 달라짐 = 각각 다른 요청으로 인지됨

- 공격대상 웹사이트 주소를 지속적으로 변경하면서 다량으로 GET 요청을 발생시킨다
- 임계치 기반의 디도스 대응 장비를 우회하기 위함

- HTTP GET Flooding 공격은 같은 주소를 요청하고, Hulk DoS는 다 다른 주소로 요청한다

 

 

 

 

22 END --

 

 

(짤막 선수지식
Hash
- Key&Value 쌍의 데이터를 저장하고 검색하기 위한 자료구조이자 알고리즘
- 다양한 크기의 입력값에 대하여 고정크기 출력값(=해시값, MD값)을 계산해낸다
- MD5 : 128bit 해시값, SHA-1 : 160bit 해시값, SHA-2: SHA-256(256bit), SHA-512(512bit)
- 이론적으로 상수타임의 복잡도(성능)를 가지지만, 충돌 발생시 많은 자원을 소모하게된다

해시의 특징: 비둘기집(하나의 주소에 여러 개)의 원리
ex (1, B) 일때 1의 해시값이 3으로 나오면, 해시테이블의 3번 버킷Bucket에 (1, B)를 저장한다
(3, C) 일때 3의 해시값이 3으로 나오면, 3번 버킷Bucket에 (3, C)를 저장해야하는데, 이미 (1, B)이 있다 (= 충돌Collision)
그렇다면? (1, B) - (3, C) 이런식으로 링크드리스트(선형자료구조)로 연결해서 저장함)


Hash Dos 공격
- HTTP 요청을 통해 전달되는 파라미터를 효율적으로 저장하고 검색하기 위해 해시테이블을 이용한다
- 공격자는 조작된 쓰레기값 파라미터를 POST 방식으로 전송하고, 웹서버는 다수의 해시충돌이 발생.
- 웹서버는 파라미터 조회시 많은 CPU 자원을 소모하게 되는 서비스 거부 공격

 

스트림정보
Content-Length: 194190
&sdfsdf=a&dfklsd=b&dsfklsd=a&dfsdf=b&sdfsdf=a&dfklsd=b&dsfklsd=a&dfsdf=b&sdfsdf=a&dfklsd=b&dsfklsd=a&dfsdf=b ... 

=> Content-Length가 매우크고, 매우 많은 조작된 쓰레기값이 확인됨

 

 

Slow 계열 공격 유형
1. Slow HTTP Header DoS(Sllowloris 슬로우리스)

2. Slow HTTP Post Dos

3. Slow HTTP Read Dos

- HTTP 트래픽을 이용함 (Application 레벨의 공격, 저대역폭 공격(트래픽이 적다))
- 웹서버의 연결자원/가용량 (웹서버가 동시에 클라이언트를 연결할 수 있는 최대갯수) 을 소진시키는 공격
- 공격자는 웹서버에 세션을 유지한 채 요청의 끝을 주지 않고, 웹서버는 요청의 끝을 계속 대기한다

 

 

 

-- 23 END

 

 

가) Slow HTTP Header Dos(Slowloris) 공격
HTTP 요청 메시지 구조
요청라인 ( GET /home/index.php HTTP/1.1 )   개행(0x0d0a) = CRLF 개행으로 필드 구분
요청헤더 ( Host : http://www.test.com               개행(0x0d0a)
                 User-Agent: Mozilla/4.0                    개행(0x0d0a)
                                ...
                 마지막 헤더 필드                           )  개행(0x0d0a)
빈 라인                                                               개행(0x0d0a)             <- 요청헤더의 끝을 의미하는 개행
메시지 바디 - 요청 데이터

 

- 공격자는 요청 헤더의 끝, 빈 라인(개행)을 전달하지 않고 지속적으로 천천히 불필요한 헤더 필드 정보를 전달한다.
- 웹서버는 요청 헤더부를 모두 수신해야 처리가 가능하므로 수신할 때까지 연결상태를 유지하며 대기한다.
- 이런 식으로 다수의 연결을 지속하면 웹서버의 연결자원이 소진되어 정상적인 서비스가 불가능해진다

 

패킷 예시
39 34 37 0d 0a
=> 쓰레기값과 개행 1번 (개행이 2번이어야 헤더의 끝임)

 

 

나) Slow HTTP POST DoS(RUDY) 공격

요청라인 ( POST /upload.php HTTP/1.1 )                                    개행(0x0d0a)
요청헤더 ( Host : http://www.test.com 개행(0x0d0a)                    개행(0x0d0a) 
                Content-Type: application/x-www-form-unlencoded     개행(0x0d0a)
                          . . .
                Content-Length: 10000000                                      )  개행(0x0d0a)

빈 라인   개행(0x0d0a)

메시지 바디 - 데이터                           <- 메시지 바디의 데이터를 아주 조금씩 전송

 

- Content-Length를 비정상적으로 크게 설정하고 매우 소량의 데이터를 지속적으로 천천히 웹서버에 전송
- 웹서버는 Content-Length만큼 모두 수신하기 위해 연결상태를 유지하며 대기한다
- POST 방식으로 데이터를 전송하면서, Content-Length 헤더 필드와 전송 데이터를 조작해 서비스 거부 공격을 수행

 

 

 

다) Slow HTTP Read Dos 공격
- TCP의 흐름제어(수신 가능한 양만큼만 데이터를 전송)를 이용한 공격방식
- 공격자는 Zero Window Packet을 서버에 보내 대기하게 만든다 (window size: 0)
- TCP는 Timer(Zero Window Probe Timer)만큼 대기 후 여유공간이 생겼는지 확인하고, 여유 공간이 생길 때까지 대기한다
- 서버측은 요청에 대한 응답 메시지를 전송하지 못하고 연결을 지속적으로 유지하게 된다

 

 

키워드 요약
- Slow HTTP Header Dos (Slowloris) : 빈라인(개행 0x0d0a CRLF ), 헤더의끝이없음
- Slow HTTP POST Dos (RUDY) : Content Length, POST
- Slow HTTP Read Dos : Zero Window(window size:0), TCP흐름제어

 

 

 

대응책
1. 동일 출발지 IP의 동시 연결에 대한 임계치Threshold 설정을 통한 차단
ex iptable -A INPUT -p tcp --dport 80 -m connlimit --conlimit-above 30 -j DROP
- 30개 초과 동시 연결에 대해 차단

2. 연결 타임아웃 설정을 통판 차단
ex Apache의 httpd.conf 설정 : Timeout 120                   <- (초단위)
- 데이터 송수신 없이 세션을 유지하는 시간에 대한 타임아웃 설정. 권장 5초.
- 너무 작은 Timeout을 설정하면 정상적인 서비스에 영향을 줄 수 있다

3. 읽기 타임아웃 설정을 통한 차단
ex Apache의 httpd.conf 설정 : RequestReadTimeout header=5 body=10
- Apache 2.2.1.5 버전 이상에서 설정가능, 지정한 시간내에 read를 완료하지 못하면 Client에게 오류코드 반환
- Header DoS와 POST DoS에 대한 대응

 

 

짤막지식
TCP Keep-Alive Packet : 일정시간 데이터 송수신 없이 지속될 경우 tcp 연결 상태를 확인하기 위해 상대방에게 보내는 패킷
(Zero Window Probe Packet과 구조가 동일함)

 

 

-- 24 END