* DoS (Denial of Service) : 단일 공격자가 서버 자원을 고갈시켜 가용성을 저해하는 공격
| 서비스 거부 공격 목적 | 설명 |
| 파괴 공격 | - 디스크, 데이터, 시스템 등의 파괴 |
| 시스템 자원 소진 공격 | - CPU, 메모리, 디스크 등의 자원에 과부하를 유발 |
| 네트워크 자원 소진 공격 | - 과도 트래픽으로 네트워크 대역폭(Bandwidth) 소진을 유발 |
* DoS 유형
1) Ping Of Death Attack : ICMP 패킷(Ping)을 정상 크기보다 아주 크게 만들어 전송, MTU에 의해 다수 IP 단편화(Fragment)가 발생, 수신측에서 이를 재조합(reassembling) 하는 과정에서 부하 또는 재조합 버퍼 오버플로우를 유발
- 대응책 : 보통 ICMP 패킷은 분할하지 않으므로, 분할이 일어난 패킷을 공격으로 의심하여 탐지하며, 반복적으로 들어오는 일정 수 이상의 ICMP 패킷을 무시하도록 설정 및 패치
2) Land Attack : (착륙하다 / 나쁜 상태에 빠지게 하다의 의미) 출발지(Source) IP와 목적지(Destination) IP가 같은 패킷을 만들어 보내, 수신자가 자기 자신에게 응답을 보내게 하여 시스템 가용성을 침해하는 공격
- 대응책 : 대부분 OS 및 방화벽에서 출발지와 목적지 IP가 동일한 패킷은 모두 Drop하기 때문에, 현재는 이론상 존재하는 공격 기법
3) Smurf Attack : 출발지 IP를 Target의 IP로 위조(IP Spoofing) 후, 증폭(Amplifier) Network로 ICMP Echo Request를 Boradcast하여, 다수의 ICMP Echo Reply가 Target으로 전달되게 하는 방식
Directed Broadcast : IP 주소의 호스트ID를 모두 1로 설정(255)하여 Broadcast 하는 방식
- 원격지 네트워크에 broadcast 할 시에는 원격지 라우터의 Directed Broadcast 설정이 활성화 되어 있어야 가능
Amplfier(Bounce) Network : ICMP Echo Request Broadcast를 받아, 다수의/증폭된 ICMP Echo Reply를 전송하는 네트워크
- 대응책 : 동일한 ICMP Echo Reply 패킷이 다량으로 발생 시, F/W을 통해 모두 차단(Drop)하며, Router에서 Directed Broadcast 패킷을 허용하지 않도록 설정((config-if)#no ip directed-broadcast)하며 브로드캐스트 주소로 전송된 ICMP Echo Request 메세지를 응답하지 않도록 시스템 설정
4) Teardrop Attack : 공격자가 IP Fragment offset 값을 서로 중첩되도록 조작하여 전송, 수신한 시스템이 재조합하는 과정에서 오류 및 시스템 기능이 마비되는 공격
- Fragment 관련 헤더 값을 조작하는 유사 공격으로 Bonk, Boink가 존재
- Tiny Fragment : IP Header보다 작은 Fragment(단편)을 만들어, F/W을 우회 (DoS가 아닌 우회 공격 기법)
- Fragment Overlap : IP Fragment의 offset값을 조작하여, 서비스 포트 필드를 중첩시켜 재조합이 되고 나면, F/W에서 허용하지 않은 서비스에 접근 가능 (DoS가 아닌 우회 공격 기법)
- 대응책 : OS의 보안 패치를 모두 설치하여 OS의 취약점 해소
5) Hash DoS : 웹서버 특성을 악용하여, HTTP Request를 비 정상적인 파라미터(매개정보)를 가진 POST 방식으로 웹서버로 전달, 웹서버는 해당 파라미터를 조회 할 시, 다수의 해시 충돌(Collision)이 발생하여 많은 CPU 자원을 소모
- 웹서버 특성 : 클라이언트(웹 브라우저) HTTP 요청을 통해 전달되는 파라미터를 효율적으로 저장, 검색하기 위한 자료구조로 해시테이블을 주로 사용
- 보통 Parameter의 Content-Length 헤더필드에 bytes 값을 말도안되는 수준으로 크게 설정, 또는 파라미터명=파라미터값&(파라미터 구분자)로 구성하는 등 비정상 형태로 전송
- 대응책 : POST 파라미터의 개수 제한 및 POST 메세지 크기 제한이 되도록 설정
6) Slow HTTP Header DoS (Slowloris) : HTTP Request Header 정보를 조작하여, 저대역폭으로 서비스 거부 공격을 수행하는 방식
- HTTP 요청 메세지 특성
- [요청 라인 / 요청 헤더 / 빈 라인 / 메세지 바디]는 CRLF(Carriage Return : 행의 맨 앞으로 이동, Line Feed : 다음 행으로 이동)를 통해 개행처리 되어 각 영역을 구분
- HTTP 요청 메세지가 웹서버에 전달 될 시, 먼저 요청 헤더(Request Header)부 까지 모두 수신 후, 헤더필드를 분석하며, 이후 Message Body부에 대한 처리를 결정
- Slowloris의 경우 위 HTTP 요청 메세지 특성을 악용하여, 지속적으로 천천히, 불필요한 요청 헤더 필드 정보를 전달하여, Empty Line을 주지 않으므로 연결 상태를 유지하며 대기 시킴으로써, 웹서버 가용량을 소진 시킴
7) Slow HTTP POST DoS (RUDY) : HTTP Request에서 POST Method 사용 시, Content-Length를 비정상적으로 크게 설정, 매우 소량의 데이터를 지속적으로 천천히 웹서버에 전송하며, 웹서버가 데이터를 모두 수신하기 위해 연결 상태를 유지하게 하여 가용량을 소진시키는 공격
- 웹서버는 Content-Length 헤더 필드를 참고하여, 수신할 데이터의 길이를 파악한 후에 명시된 크기 만큼 데이터를 모두 수신하기 위해 대기하는 특성이 존재하며, 해당 취약점을 이용하여 가용량을 소진
8) Slow HTTP Read DoS : 공격자가 TCP Flow Control(흐름 제어)의 특성을 악용하여, HTTP 요청 시에 Window Size를 0인 'Zero Window Packet'을 지속적으로 서버측에 전달, 서버는 응답 메세지를 전송하지 못하고 Timer에 의해 연결을 지속하도록 유도하는 공격
TCP Flow Control : 연결된 상호간 수신 가능한 양 만큼만 데이터를 전송하는 제어 방식
TCP Header Window 필드 : 수신측에서 수신 가능한 여유 공간의 크기를 담아서, 송신측에 전달하는 헤더 필드
TCP Keep-Alive Packet : 일정 시간(TCP 옵션 설정) IDLE 타임(아무런 데이터 송,수신 없이 지속되는 시간)이 지속 될 경우, TCP 연결 상태를 확인하기 위해 상대방에게 보내는 패킷 (Zero Window Probe Packet과 구조상 완전히 동일하여 TCP Flag ACK로만 회신 가능)
- 수신측이 데이터를 수신할 공간이 0일때 Window=0 (Zero Window Packet)으로 설정하여 송신측이 전달
- 송신측은 일정 시간(Timer) 대기 후, 수신측의 Window 상태를 확인하기 위한 Zero Window Probe Packet 전달
- 수신측에서 여유공간이 있을 시, Window Update Packet 전송 / 없을 시, Zero Window Packet 응답
- Slow DoS 공격(Slowloris, RUDY, Read) 대응책
| 대응 방안 | 설명 |
| 동시 연결 임계치 설정 (Concurrent connection) |
- 동일 출발지 IP에서 동시에 연결할 수 있는 연결 개수 임계치(Threshold) 설정 ex) iptables F/W configuration iptables -A INPUT -p tcp --dport 80 -m conlimit --conlimit-above 30 -j DROP : 30개 초과 동시 연결에 대해 DROP |
| 연결 타임아웃 설정 (Connection Timeout) |
- Client와 Web Server간 아무런 데이터 송수신 없이, 세션 유지 시간에 대해 타임아웃 설정 ex) Apache httpd.conf configuration # Timeout: The number of seconds before receives and sends time out. Timeout 120 : 데이터 전송 주기에 대한 Timeout을 120초(default)로 설정 |
| 읽기 타임아웃 설정 (Read Timeout) |
- Request Header와 Request Body 부분 각각에 대하여 Timeout을 설정하여 지정 시간 내에 read(수신)를 완료하지 못할 시, 클라이언트에게 오류코드를 반환 ex) Apache httpd.conf configuraton <IfModule reqtimeout_module> RequestReadTimeout header=5 body=10 </IfModule> : Request Header 정보는 5초 이내, Request Body 정보는 10초 이내에 모두 수신되지 않을 시, 오류 응답 |
* DDoS : 다수 대상(보통 좀비 PC)에서 무의미한 요청으로 가용성을 저하시키는 공격
- 보통 악성코드에 감염되어 C&C (Command & Control) 서버를 통해 다수 대상에서 공격을 수행
| DDoS 구성 요소 | 설명 |
| 공격자 (Attacker, Bot Master) |
- C&C 서버를 관리 및 공격 명령을 내리는 해커의 컴퓨터 - 공격자는 다양한 악성 코드(웜/바이러스, 백도어, 스파이웨어, 루트킷, 스팸메일 등)을 통해 불특정 다수의 PC에 봇을 배포, 감염을 시도 |
| 명령제어 서버 (C&C - Command & Control, Master) |
- 공격자로 부터 명령을 전달받아 관리 및 다수의 악성 봇에 전달 |
| Zombie PC/Device (Bot, Slave, Agent) |
- C&C 서버로 부터 전달받은 명령을 공격 대상에 실제로 수행하는 장치 - 감염을 통해 C&C 서버에 접속하여 BotNet의 일원으로 추가됨 - 스스로 다른 PC로 봇을 전파 시키기도 함 |
| 공격 대상 (Target) |
- 공격의 대상이 되는 시스템 |
| BotNet 유형 | 제어 방식 | 설명 |
| 중앙 집중형 명령/제어 방식 (Command/Control) |
IRC 봇넷 | - 초기 IRC 프로토콜(ex-Rbot 등)의 특성을 이용한 봇넷이 주 - 탐지 및 대응을 보다 어렵게 하기 위해 HTTP 기반(ex-Rogax 등)으로 진화 - 다수의 도메인을 확보하여 C&C 서버에 등록, 다수의 좀비들이 C&C 서버와 연결되어 명령을 수행하는 구조 - C&C 서버가 탐지 및 차단될 시, 전체 봇넷이 중단될 수 있음 |
| HTTP 봇넷 | ||
| 분산형 명령/제어 방식 | P2P 봇넷 | - 참여 멤버(좀비/봇)들이 모두 C&C 역할을 수행하여 그룹에 명령을 전파하는 분산 제어 방식 - 중앙 관리를 위한 별도 도메인 및 C&C 서버 불필요 - 탐지 및 차단에 의한 봇넷을 보호, 네트워크가 끊기는 것을 방지 - Storm, Peacomm 등의 P2P 봇넷 유형이 존재 |
IRC (Internet Relay Chat) : 웹 상, 채팅을 할 수 있도록 고안된 프로토콜로 IRC 서버간에 연결되어, 한 서버에 연결하면 자동으로 전 세계의 모든 IRC 서버와 연결되는 구조
* DDoS 유형
1) UDP Flooding : 공격자가 다량의 UDP Packet을 Target으로 전송하여 대상이 보유한 네트워크 대역폭을 소진시키는 공격
2) ICMP Flooding : 공격자가 다량의 ICMP Packet을 Target으로 전송하여 대상이 보유한 네트워크 대역폭을 소진시키는 공격
3) TCP SYN Flooding : TCP 연결 과정(3-Way Handshake)의 취약점을 이용, 공격자가 다량의 도달 불가능한(존재하지 않는) 출발지 IP로 위조한 SYN 요청을 Target으로 전송하여, 서버측의 SYN+ACK 요청에 대한 ACK 응답이 발생하지 않도록 만들어 다른 요청을 받을 수 없게 만드는 공격
- TCP SYN Flooding은 위 방식에서, 존재하지 않는 위조 IP들의 SYN 전송으로, 서버에서 SYN+ACK 응답 전송 및 SYN_RECV 상태로 ACK 응답을 기다리는 것을 유도, Backlog Queue를 소진 시켜 새 요청을 받지 못하게 만드는 방식
(위조 IP중, 실제 존재하는 IP의 경우 RST 응답이 발생할 수 있음)
- 대응책
| 대응 방안 | 설명 |
| SYN Cookie 설정 | - 연결 설정 과정에서 서버가 특정값(Cookie)를 생성, SYN+ACK 응답 시 이를 ISN(Initial Sequence Number)으로 설정하여 전달 - 클라이언트가 해당 Cookie에 대한 적절한 ACK 응답을 할 때까지 backlog queue에 연결요청정보를 담지 않음 ex) [Linux]#sysctl -w net.ipv4.tcp_syncookies=1 (1은 True를 의미) |
| Client IP SYN Threshold 설정 | - F/W 또는 Anti DDoS 장비 등을 이용 - 동일 Client IP의 SYN 요청에 대한 임계치 설정 ex) iptables -A INPUT -p TCP --dport 80 -syn -m connlimit --conlimit-above 5 -j DROP (TCP 80포트에 대한 SYN의 경우 동일 출발지 IP로 동시 연결 개수 5개 초과 시 차단) |
| First SYN DROP 설정 | - 대부분 공격툴이 다량 SYN 요청만 생성할 뿐, 패킷 DROP시 재전송을 수행하지 않는 점 이용 - Client의 첫 SYN은 DROP하여 재요청 패킷이 도착하는지 확인 - 출발지 IP의 Spoofing 여부에 대한 판단이 가능 |
| Backlog queue Size 확장 | - 임시적인 조치로, 대규모 공격에 대해서 큰 효과는 없음 ex1) [Linux]#sysctl -w net.ipv4.tcp_max_syn_backlog = 1024 (TCP Backlog Queue의 크기를 1024로 늘림) ex2) [Unix]#ndd -set /dev/tcp tcp_conn_req_max_q0 1024 (TCP Backlog Queue의 크기를 1024로 늘림) |
| SYN+ACK Connection Time out 설정 | - 대기 시간을 너무 줄일 시, 정상요청에 문제가 생길 수 있으니 주의 |
TCP/IP 커널 파라미터 설정
- 리눅스 sysctl : sysctl -w <파라미터 명>=파라미터 값
- 유닉스 ndd : ndd -set /dev/<드라이버> <파라미터 명> <파라미터 값>
4) HTTP GET Flooding : 공격자가 봇넷을 통해 동일한 동적 컨텐츠에 대한 HTTP GET 요청을 다량으로 발생시켜 대상 웹서버의 부하를 유발하는 공격
- Web Server Access Log 분석 : 웹 통신에 대한 통계 추출에 효과적
- access-log 포맷의 경우, 첫번째 컬럼이 '요청 클라이언트 IP'이며 위 같은 명령어들로 통계 추출이 가능
- grep "GET /home/index.php" : access 로그에서 해당 URL을 포함하는 행을 grep
- awk '{print $1}' : grep한 행 중에서 첫 번째 컬럼($1 - 요청 클라이언트 IP)을 출력(print)
- sort : 오름 차순 정렬 / sort -rn : reverse(역순)으로 내림차순 정렬, number로 정렬할 컬럼 값을 숫자형식으로 정렬
- uniq -c : 연속된 중복 행을 제거 (즉, 동일 IP가 연속해서 나올 시, 하나만 출력 후 -c 옵션을 통해 행의 개수를 출력)
5) Hulk DoS : HTTP GET Flooding의 동일 URL에 대한, 다량의 GET 요청의 경우, 임계치 기반의 DDoS 방어에 취약하여, 이를 우회하기 위해 공격대상의 웹사이트 URL을 지속적으로 변경, 다량으로 GET을 발생시키는 공격
(주소 변경 또는 파라미터 변경)
6) TCP Flag Flooding : TCP Flag(Control Bit)를 임의로 조작하여 여러 형태의 패킷을 생성, 이를 Target 서버에 전송 시, 수신한 서버는 해당 TCP 패킷을 검증하며 자원을 소모하게 되는 점을 이용한 공격
7) DNS Query Flooding : UDP 프로토콜 기반의 서비스를 제공하는 DNS에 대해 다량의 DNS 쿼리를 서버에 전송, DNS의 정상적 서비스를 방해하는 공격
8) TCP Session Flooding : TCP 3-Way Handshake 과정을 과도하게 유발하여, 서비스 과부하를 유발하는 공격
9) HTTP Continuation : 서버로 전달되는 패킷에 HTTP Header 없이, Data만 채워 웹 서버가 지속적으로 데이터 수신을 위해 TCP 자원을 사용하도록 하는 공격
10) CC Attack (HTTP GET Flooding with Cache-Control) : 공격자가 HTTP 메세지의 캐시 옵션(Cache-Control:no-store, must-revalidated)을 조작하여, 캐싱 서버가 아닌 웹서버가 직접 처리하도록 유도, 캐싱 서버 기능을 무력화하고 웹 서버의 자원을 소모시키는 공격
* DDoS 인지 방안 (Identification) : 공격받는 시점에 담당자의 공격 확인
| 확인 정보 | 내용 |
| 유입 트래픽 크기 (Incoming Traffic Volume) |
보안 & 네트워크 장비를 통해 유입 트래픽의 크기가 비정상 증가될 때 |
| 웹서버 접속 로그 (Web Server Access Log) |
서버의 접속 로그 확인을 통해 비정상 접속 증가 확인 |
| 동시접속 정보 (Concurrent Connection) |
서버와 클라이언트 간 연결 규모를 확인하여 세션 수를 확인 |
| 유입 트래픽 샘플링 캡처 (Incoming Traffic Sampling Capture) |
유입되는 트래픽을 샘플링, 실제 트래픽 분석 |
* DDoS 대응 방안
1) 사전 준비
- 기업 자체
| 사전 준비 사항 | 내용 |
| 허니팟 (Honey pot) |
- 취약한 형태로 구축해 공격을 유도 |
| 사이버 게놈 분석 (Cyber Genome Analysis) |
- 서열 및 시퀀스를 추출하여 비교 |
| 블랙홀 라우팅 (Blackhole Routing) |
- 비정상 IP를 차단 |
| 씬 프록시 (Syn Proxy) |
- 거짓 Syn 패킷들을 차단 |
| 연결요청 대기 큐 증가 (Backlog Queue) |
- 연결 자체 성능을 늘림 |
| Anti DDoS | - 보안 솔루션 설치 |
- 정부 연계
| 사전 준비 사항 | 내용 |
| KrCert 대응 체계 수립 | - 실시간 대응 체계 수립 |
| 사이버 대피소 | - KISA, 금융보안원 등 트래픽 우회소 지원 |
| DNS 싱크홀 | - KISA에서 국내 주요 ISP 업체 및 가입 기간과의 협력을 통해 운영 * 동작 과정 1. 사전 단계 : KISA에서 배포한 C&C 목록을 ISP 등의 DNS 싱크홀 적용 기관의 DNS 서버에 주기적으로 업데이트 2. 악성 봇에 감염된 Zombie가 싱크홀이 적용된 DNS에 C&C 서버에 대한 질의를 요청 3. DNS는 해당 Zombie에게 싱크홀 서버의 IP 주소를 반환 4. 해당 Zombie는 공격자의 명령으로부터 피해 방지가 가능 |
| C-TAS 연계 | - 각종 정부의 공격 정보를 수신 |
2) 사후 대응
- 기업 자체
| 사후 대응 사항 | 내용 |
| QoS (Quality of Service) |
- 일정량의 트래픽이 넘을 시 나머지를 차단 |
| DR 센터 (Disaster Recovery Center) |
- 공격에 대비한 가용 시설을 준비 |
| 웹서버 증설 | - 요청 수신 용량 확장 |
| CDN (Content Delivery Network) |
- 별도의 컨텐츠를 캐싱 서버에서 제공 |
| 사이버 디셉션 구축 (Cyber Deception) |
- 정적인 허니팟과 다르게 동적 발전성이 있는 덫을 구축 |
- 정부 연계 : 공격자 역추적을 통한 수사 요청, 사이버 탄력성(Cyber Resilience) 등 구성
'Information Security > Hacking' 카테고리의 다른 글
| Honey pot (0) | 2021.01.07 |
|---|---|
| DNS 보안 (0) | 2021.01.07 |
| SQL Injection (0) | 2020.12.27 |
| CSRF (Cross-Site Request Forgery) (0) | 2020.12.27 |
| XSS (Cross-Site Scripting) (0) | 2020.12.27 |
