보안 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
번호 | 제목 | 날짜 | 조회 수 |
---|---|---|---|
96 | 전자서명법 - 공인인증서 | 2017.11.09 | 248 |
95 | 국제공통 평가 기준 표준 (CC:Common Criteria) | 2017.11.09 | 377 |
94 | 정보통신망법 | 2017.11.09 | 201 |
93 | IoT 보안 | 2017.11.08 | 193 |
92 | 접근통제 참조모델 | 2017.11.07 | 326 |
91 | 쉘쇼크(Shellshock) | 2017.11.07 | 244 |
90 | 악성코드의 종류 | 2017.11.07 | 643 |
89 | 디지털 포렌직 조사의 일반원칙 | 2017.11.07 | 231 |
88 | ftp 보안 취약점및 대책 | 2017.11.05 | 624 |
» | Dos 공격유형 및 차단 | 2017.11.03 | 796 |
86 |
command
![]() | 2017.11.01 | 1546 |
85 | ICMP | 2017.11.01 | 1262 |
84 |
아파치 웹서버 보안설정
![]() | 2017.11.01 | 3557 |
83 | HTTP Header | 2017.11.01 | 245 |
82 | IPv4, IPv6 | 2017.11.01 | 260 |