보안 Dos 공격유형 및 차단
2017.11.03 00:18
UDP/ICMP Flooding : Source IP 변조하거나 실제 IP를 이용하여 패킷을 다량으로 전송하여 네트워크 대역폭을 잠식
Trinoo 등으로 공격
DNS Query Flooding : DNS 쿼리 데이터를 다량으로 서버에 전송
DNS DDoS 공격차단
UDP size 512byte 이상의 패킷을 차단
iptables -A INPUT -p udp --dport 53 -m length --length 512: -j DROP
5초동안 5번 쿼리 발생시 해당패킷 차단
iptables -A INPUT -p udp --dport 53 -m recent --name ddos2 -set
iptables -A INPUT -p udp --dport 53 -m recent --name ddos2 --update --second 5 --hitcount 5 -j DROP
SYN Flooding : SYN 패킷을 서버로 전달하여 서버의 대기큐(Backlog Queue)를 가득채워 새로운 클라이언트 연결 요청을 무시
Half Open 상태로 신규 접속 받지 못하게 됨
방어 : 방화벽의 IP 당 SYN 요청에 대한 PPS(임계치)를 단계적으로 조정하여 차단
First SYN DROP ( Spoofed) 설정에 의한 차단 - 첫번째 SYN Drop후 재요청 패킷이 도착하는지 여부판단
TCP Flag Flooding : TCP의 Flag 값을 임의로 조작하면 SYN,ACK,FIN,RST 과 같이 여러 형태의 패킷을 생성할 수 있으며,
서버는 이러한 패킷을 수신하는 경우 해당 패킷을 검증(과부하)하기 때문에 서버의 자원을 소진시킴
TCP Session Flooding : TCP 3-Way Handshake 과정을 과도하게 유발함으로써 서비스의 과부하를 유발하는 공격
대응 : Connection Timeout/Keep-Alive/Time-Wait 설정을 통한 차단
L7 스위치의 임계치 설정 기능을 이용한 차단( IP당 Connection Limit)
LAND Attack : IP Header Option 을 변조하여 인위적으로 송신지 IP 주소및 포트를 목적지 (대상 웹서버) IP 주소및 포트와
동일하게 설정하여 트래픽을 전송하는 공격
Teardeop (IP Fragment Packet Flooding) : 하나의 IP 패킷을 MTU 만큼 분해 전달후 재조합할때 데이터그램을 조작하여 재조합에 대한 오버해드 발생
구버젼 OS에나 가능한 공격
HTTP Continuation Data Flooding : 서버로 전달하는 패킷에 HTTP Header 없이 데이타만 채워 웹서버가 지속적으로 테이타 수신을 위해
TCP 자원을 사용하도록 하는공격
패킷 크기를 최대한 크게 하여 보내기 때문에 네트워크 자원도 같이 고갈
HTTP Get/POST flooding : 동일한 URL을 반복 요청하여 웹서버가 URL에 해당되는 페이지를 클라이언트에게 회신하기 위해
서버 자원을 사용하도록 하는 공격, 한정된 connection 용량 초과시 서비스 불가
방어 : IP기준의 임계치 설정
콘텐츠 요청 횟수에 대한 임계치 설정에 의한 차단
시간별 웹페이지 URL 접속 임계치 설정에 의한 차단
웹스크래핑(Web-Scraping) 기법을 이용한 차단 -L7 스위치
HTTP Cache Control (CC Attack) : no-store(캐시저장금지), must-revalidate(캐시검증) 옵션을 주서어 캐싱장비가 응답하지 않고 웹서버가 직접 부하줌
Cache-Control 옵션을 제외하면 Get Flooding 과 동일
방어 : HTTP Header의 Cache-Control에 특정 문자열(no-Store, must-revalidate)을 포함하는 경우 해당 IP의 접속을 차단하는 방
Slow HTTP POST Dos : content-Length 를 크게 설정하고, window size = 1,
POST 데이터를 일정한 간격으로 1바이트씩 분할하여 서보로 전송하여 서버가 해당 데이터를 수신하기 위한
연결 상태를 종료하지 못하도록 유지시켜 다른 클라이언트의 연결이 원할하지 못하도록 유도
방어: iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 30 -j DROP # 30개 이상의 concurrent connection에 대한 차단
Connection Timeout과 Keepalivetimeout 설정을 통한 차단
RequestReadTimeout header=5 body=8 - (mod_reqtimeout Module) 설정을 통한 차단
RequestReadTimeout header=10 body=30 # Client의 요청 header 전송완료는 10초 이내 , 요청 body 전송 완료는 30초 이내로 제한
RequestReadTimeout body=10,MinRate=1000 # client의 요청 body 전송완료는 10초 이내로 제한,
단 client가 data를 전송 할 경우 1,000bytes 전송 시점마다 1초씩 증가
아파치 설정
<IfModule reqtimeout_module>
RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500
</IfModule>
Slow HTTP Header Dos(Slowloris) : 웹로그가 기록되지 않음 , 개행문자 " /r/n/r/n "없음, 웹서버는 HTTP헤더 정보가 다 수신하지 않은것으로
판단하여 연결유지시켜 다른 세션이 연결 못하게 유도
'0D0A0D0A" 가 안나옴
HTTP 분할응답, 자바소스에서 replaceAll(/r/n)
Slow HTTP GET Dos :
전송시 아주 느리게 (1byte) 씩 주고 받기 때문에 느린만큼 시스템 대기로 인한 해당 세션의 대기증기로 시스템부하 증가
Slow HTTP Read Dos : TCP window size = 0 으로 바꾸게 되면 서버는 클라이언트의 윈도우 크기가 정사으로 환원될 때까지 Pending 상태에 빠지게 되어 연결유지됨
HTTP Hash DoS : 해시 테이블에서 해시 충돌이 발생되어 이 해시값을 비교하기위해 CPU 자원을 고갈시킴
HashDoS 공격 방어
o 톰캣(Tomcat)에서의 HashDoS 차단 방안
- (방안 1 : 파라미터 개수 제한) TOMCAT_HOME/conf/server.xml의 Connector 부분을 다음과 같이 설정
<Connector port="8009" protocol="AJP/1.3" maxParameterCount="xxx" …./>
※ 적용가능버전: Tomcat 5.5.35, 6.0.35, 7.0.23
- (방안 2 : POST 메시지 크기 제한)
사이즈를 제한하는 것이 서비스에 문제가 없는 경우 적용하며, TOMCAT_HOME/conf/server.xml의 Connector 부분을 다음과 같이 설정
<Connector port="8009" protocol="AJP/1.3" maxPostSize="xxx" …./>
o PHP에서의 HashDoS 차단 방안
- PHP 5.4.0 RC4로 업데이트 한 후 , php.ini 파일에서 ‘max_input_var'에서 최대 HTTP POST Parameter 개수를 설정
HTTP Hulk DoS : HULK(Http Unbearable Load King)
공격대상 웹사이트 주소(URL)를 지속적으로 변경하여 DDoS 차단정책을 우회
HTTP GET Flooding과 동일하나 url 파라미터가 램덤하게 바뀜
차단방안 : iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 30 -j DROP # 30개 이상의 concurrent connection에 대한 차단
HTTP Request의 HOST 필드값에 대한 임계치 설정을 통한 차단
302-Redirect를 이용한 차단
# ndd -set /dev/ip ip_forward_directed_broadcasts 0
다이렉트 브로드캐스트 패킷의 포워딩을 허용하지 않음으로써 (0),
스머프 공격 패킷이 전달되지 않도록 설정한다.
# ndd -set /dev/tcp tcp_conn_req_max_q0 512
TCP 연결 요청 큐의 크기를 512로 설정한다.
TCP 연결 요청 큐의 크기가 작으면 SYN flag 패킷을 지속적으로 받을 경우 오버플로우가 발생할 수 있는데,
TCP 연결 요청 큐의 크기를 크게 하여 TCP SYN Flooding 공격을 방지할 수 있다.
댓글 0
번호 | 제목 | 날짜 | 조회 수 |
---|---|---|---|
25 |
보안관제
![]() | 2017.11.01 | 4850 |
24 | VPN | 2017.11.01 | 5255 |
23 | 개인정보 | 2017.11.01 | 200 |
22 | 암호학 | 2017.11.01 | 900 |
21 | BCP | 2017.11.01 | 675 |
20 | WLAN, VLAN | 2017.11.01 | 283 |
19 | ISMS - 정보보호관리체계 | 2017.11.01 | 258 |
18 | 위험관리 | 2017.11.01 | 293 |
17 | 법규 - 추가작성 | 2017.11.01 | 284 |
16 |
개발보안
![]() | 2017.11.01 | 668 |
15 |
시스템보안
![]() | 2017.11.01 | 1413 |
14 |
블록체인
![]() | 2017.10.31 | 283 |
13 |
route access-list
![]() | 2017.10.30 | 656 |
12 |
전자서명의 원리
![]() | 2017.10.30 | 291 |
11 |
사이버 침해사고 대응 절차
![]() | 2017.10.29 | 369 |
10 |
스니핑용 promisc 모드
![]() | 2017.10.29 | 426 |
9 |
DDoS 공격도구
![]() | 2017.10.18 | 383 |
8 |
UDP 플러드 공격 - NTP, DNS, SSDP Amplification DDoS Attack
![]() | 2017.10.18 | 1455 |
7 |
Smurf Attack / Land Attack / Ping of Death
![]() | 2017.10.17 | 1585 |
6 |
Tear Drop / Tiny Fragment / Fragment Overlap(고전적인방법)
![]() | 2017.10.17 | 10128 |