Skip to content

조회 수 13008 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄
1. 백로그 큐를 늘려준다.
직관적으로 보았을 때 서비스 거부에 돌입하게 되는 것은 백로그큐(Backlog Queue)가 가득
차서 다른 접속 요구를 받아들이지 못하기 때문이므로 백로그 큐의 크기를 늘려주면 될 것이다. 실제로 리눅스를 포함해서 많은 운영체제들의 백로그큐값을 조사해 보면 이 값이 필요 이상으로 작게 설정되어 있어 적절히 늘려주는 것이 좋다.
현재 시스템에 설정된 백로그큐의 크기는
[root@net /root]# sysctl -a|grep syn_backlog
net.ipv4.tcp_max_syn_backlog = 128
또는
[root@net /root]# cat /proc/sys/net/ipv4/tcp_max_syn_backlog
128
로 확인가능하며 128kb 인 것을 확인할 수 있다.
일반적으로 시스템의 RAM 이 128M 일 경우에는 128 을 설정하고 그 이상일 경우에는 1024 정도로 설정해 주는 것이 좋다. 이 때 주의할 점은 이 값을 무작정 크게 설정한다고 좋은 것은 아니며 1024 이상으로 설정할 경우는 /usr/src/linux/include/net/tcp.h 소스에서 TCP_SYNQ_SIZE 변수를 수정 후 커널을 재컴파일하여야 한다. 이 변수를 설정시 TCP_SYNQ_HSIZE에 16을 곱한 값이 tcp_max_syn_backlog 보다는 작거나 같아야 하는데, 그렇지 않을 경우에는 시스템에 문제가 발생할 수 있으니 1024 보다 높은 값으로 설정하지 말기 바란다. 그리고 이 값을 너무 크게 설정하였을 경우에는 경험적으로 아래 설명할 syncookies 기능이 잘 적용되지 않는 현상이 가끔 확인되었다.
이와는 별개로 시스템의 부하가 많이 걸릴 경우에도 백로그큐를 늘려주면 일정 정도의 효과를 볼 수 있는 것으로 알려져 있다.
백로그큐의 값을 설정하는 방법은 다음과 같다.
[root@net /root]# sysctl -w net.ipv4.tcp_max_syn_backlog=1024
또는
[root@net /root]# echo 1024 > /proc/sys/net/ipv4/tcp_max_syn_backlog
로 해도 된다.
그러나 이 방법은 임시적인 대책일 뿐, 지속적으로 많은 TCP SYN Flooding 공격을 당할 때는 결국 백로크큐가 가득 차게 되므로 근본적인 해결 방안은 아니다.
2. syncookies 기능을 켠다.
Syncookies(“신쿠키” 라고 발음한다.) 는 "Three-way handshake" 진행 과정을 다소 변경하는 것으로 Alex Yuriev 와 Avi Freedman 에 의해 제안되었는데, TCP header 의 특정한 부분을 뽑아내어 암호화 알고리즘을 이용하는 방식으로 Three-way Handshake 가 성공적으로 이루어지지 않으면 더 이상 소스 경로를 거슬러 올라가지 않는다. 따라서 적절한 연결 요청에 대해서만 연결을 맺기 위해 리소스를 소비하게 되는 것이다.
syncookies 기능은 TCP_Syn_Flooding 공격을 차단하기 위한 가장 확실한 방법으로 이 기능을 이용하려면 일단 커널 컴파일 옵션에서 CONFIG_SYN_COOKIES이 Y 로 선택되어 있어야 한다.
자신의 커널 옵션에 이 기능이 설정되어 있는지 확인하려면
/usr/src/linux 디렉토리로 이동후 make menuconfig 후
Networking options --->
[*] IP: TCP syncookie support (disabled per default)
와 같이 확인하면 된다.
만약 설정이 되어 있지 않다면 선택 후 커널 컴파일을 다시 하여야 하지만 대부분 배포판은 기본적으로 이 옵션이 선택되어 있으므로 걱정할 필요는 없다.
그러나 위와 같이 커널 옵션에 설정되어 있다 하더라도 실제 syncookies 적용은 꺼져 있으므로 이 값을 다음과 같은 방법으로 활성화해야 한다.
[root@control src]# sysctl -a|grep syncookie
net.ipv4.tcp_syncookies = 0
0 으로 설정되어 있으므로 현재 syncookies는 적용되지 않는다.
따라서 아래와 같이 1을 설정하여 syncookies 기능을 활성화하도록 한다.
[root@control src]# sysctl -w net.ipv4.tcp_syncookies=1 or echo 1 > /proc/sys/net/ipv4/tcp_syncookies

syncookies는 백로그큐가 가득 찼을 경우에도 정상적인 접속 요구를 계속 받아들일 수 있도록 해 주므로 SYN_Flooding 공격에 대비한 가장 효과적인 방법중 하나이다.
만약 공격을 당해 syncookies 가 작동할 때에는 /var/log/messages 파일에 아래와 같이 SynFlooding 공격이 진행중이라는 메시지가 출력된다.
Jun 11 18:54:08 net kernel: possible SYN flooding on port 80. Sending cookies.
SYN_Flooding 공격이 지속적으로 매우 심하게 진행중일 때에는 syncookies 기능이 작동한다 하더라도 네트워크가 다운되는 현상이 가끔 확인되었다. 따라서 syncookies 기능 외에 몇 가지 설정도 함께 적용하는 것이 시스템의 안정성을 위해 권장하는 방법이다. 아울러 네트워크가 다운되었을 경우에는 /etc/rc.d/init.d/network restart 로 network 를 재설정해 보거나 reboot 를 하여야 한다.

SYN Flooding조치법
http://cafe.naver.com/dnspro.cafe?iframe_url=/ArticleRead.nhn%3Farticleid=9651
connlimit모듈 설치 후 iptables에 설정
iptables -A INPUT -p tcp --dport 80 --syn -m connlimit --connlimit-above 10 -j DROP

1초동안 80포트에 똑같은 IP가 10번 이상의 SYN패킷이 들어오면 드랍시킨다. 즉 정상적인 요청이 아닌 웹서비스 공격으로 간주하여 요청패킷을 폐기시켜 응답하지 않도록 한다.
iptables -A INPUT -p tcp --dport 80 -m recent --update --seconds 1 --hitcount 10 --name HTTP -j DROP

DDOS공격에 대비하기 위한 캐시구성
다수의 위조된 source ip에서 syn flooding 공격이 발생할 때 아래와 같은 메세지가 나오면서 시스템이 정지되는 경우가 있음

#dmesg
kernel : dst cache overflow
kernel : dst cache overflow
kernel : dst cache overflow

리눅스에서는 각각의 소스의ip에 대해 라우팅캐시로 저장해두는데, syn flooding 공격시에는 이 갯수가 미리 지정된 값을 초과하여 접속이 되지 않는 것으로 현재 수치가 높여져 있지만 더 수치를 조정할 필요가 있습니다.

#route -Cn <-- 현재 라우팅 캐시정보

/proc/sys/net/ipv4/route/max_size = 2097152 => 인식 가능한 라우팅 개수
/proc/sys/net/ipv4/route/secret_interval = 600 => 라우팅을 캐시하는 시간 (600초 10분)
2097152/600=3495   => 초당 신규 라우팅 캐시를 3495개까지 인식 가능
따라서, 위의 경우 초당 4000개 이상의 소스ip에서 접속이 들어오면 시스템이 멈추게 됩니다.
따라서, 공격에 대비하여 아래와같이 설정하는것을 권장합니다.

##대응방법
(1) net.ipv4.route.max_size의 값을 최대한 늘리고 (예:8000000)
(2) net.ipv4.route.secret_interval의 값을 줄인다 (예10)
(3) 또는 ip route flush cache로 캐쉬를 즉시 clear시킨다.

get flooding확인
tcpdump -nn -A | grep GET

List of Articles
번호 제목 글쓴이 날짜 조회 수
48 리눅스서버에서 ping(ICMP) 열기/닫기 ADMINPLAY 2009.08.18 14876
47 시스템 로그를 메일로 - logcheck file ADMINPLAY 2009.09.08 8827
46 스위칭 허브 상에서의 sniffing 툴 file ADMINPLAY 2009.09.08 9637
45 apache 웹방화벽 modsecurity용 웹설정 툴, Remo file ADMINPLAY 2009.09.09 9498
44 rootkit 검색 프로그램 rkhunter-1.2.9.tar.gz file ADMINPLAY 2009.09.22 9236
43 rootkit 검색 프로그램 rkhunter-1.3.4.tar.gz file ADMINPLAY 2009.09.22 9483
» SYN Flooding공격에 대한 대비 ADMINPLAY 2009.09.24 13008
41 SQL Injection tools 15종 ADMINPLAY 2009.09.25 12327
40 iframe 이용한 악성코드 삽입, 홈페이지 변조 사고 대비 ... ADMINPLAY 2009.10.15 10869
39 홈페이지 변조 대처법 (FTP 계정을 이용한 아이프레임 코... ADMINPLAY 2009.10.15 9091
38 SSH(Security SHell) 보안쉘 ADMINPLAY 2009.10.20 8444
37 ossec 로그 분석 툴 설치 ADMINPLAY 2009.10.20 11576
36 iptables 옵션 및 상태 추적 테이블 및 rule ADMINPLAY 2009.11.30 8917
35 해외에서 접근하는 IP 차단하기 ADMINPLAY 2009.11.30 9311
34 실전 테스트!! 스니퍼 공격 ADMINPLAY 2009.11.30 9824
33 lsof 활용 가이드 ADMINPLAY 2009.11.30 8357
32 Kernel 2.4.23 버전 이하에 나온 ptrace 버그에 관한 사항 ADMINPLAY 2009.12.13 8842
31 홈페이지 보안 강화 도구(CASTLE) 보급 안내 1 file ADMINPLAY 2010.01.22 8971
30 Tcpdump 용어 정리 ADMINPLAY 2010.01.30 8549
29 SSH 공격막아내기 방법 l2zeo 2010.03.08 8449
Board Pagination Prev 1 2 3 4 5 Next
/ 5

Copyright ADMINPLAY corp. All rights reserved.

abcXYZ, 세종대왕,1234

abcXYZ, 세종대왕,1234