플러딩은 DDoS 공격을 수행하는 가장 간단하고 일반적인 방법입니다. SYN 플러드로부터 Linux 서버 보호: 기본 사항 및 방법 다른 모든 방법이 실패하는 경우

syn-flood 공격 - 연습

알렉산더 안티포프

일부 공급자(시간이 지남에 따라 더 많은 공급자가 나타남)는 보낸 사람 주소가 위조되지 않도록 클라이언트의 트래픽을 필터링합니다. 스푸핑 가능성이 클래스 C 서브넷으로 제한될 가능성이 높으며, 또한 연결 요청에 주소가 지정된 호스트는 서버 응답에 응답하지 않아야 합니다. 가장 쉬운 방법은 연결 요청이 없는 주소를 선택하는 것입니다. 기계. 실제 구현에서, 특히 협력 공격을 위한 범용 도구를 생성할 때 이 두 가지 기능을 고려하고 서브넷과 응답하지 않는 주소에서만 공격을 수행해야 합니다. 또 다른 문제는 공격을 수행하려면 관리자 권한이 있어야 한다는 것입니다.

공격자가 통제할 수 없는 문제.

소프트웨어 구현.

표준 원시 소켓 외에도 Nerf의 D0minat0r은 Linux에서 SYN 플러드를 구현하는 매우 아름다운 방법을 찾았지만 다른 Unix 계열 소켓에서는 테스트되지 않았으며 Win에서는 작동하지 않습니다. Linux에서는 루트가 로컬 호스트에 속하지 않은 주소를 포함하여 모든 주소에 소켓을 바인딩할 수 있도록 허용합니다. 그런 다음 이 소켓에 대해 connect()를 호출하면 로컬 호스트는 소켓이 있는 주소에서 SYN 패킷을 보냅니다. 소켓이 비차단 모드에 있었다면 connect() 직후에 close()를 호출하고 작업을 반복할 수 있습니다.

Windows용 구현은 이 OS에서 원시 패키지를 생성할 수 없다는 일반적인 통념으로 인해 덜 일반적입니다. 실제로 win98은 IP 헤더까지 원시 수준 소켓을 지원하고, win2k와 XP는 헤더도 지원합니다(옵션 IP_HDRINCL). win2k 및 XP에서의 공격 구현은 단 몇 줄의 Unix 공격과 다릅니다. win2k에서 테스트한 완성된 구현은 한때 www.nerf.ru에 있었지만 호스팅을 변경한 후 이 그룹과 formattsev를 떠나서 손실되었습니다. 아직 갖고 계신 분이 계시다면 연락주시면 포스팅해드리겠습니다.

SYN 폭주에 대한 OS 보호 메커니즘.

a) 표준 타우아웃. 반쯤 열린 연결은 일정 시간이 지나면 버퍼에서 삭제됩니다. 버퍼가 고갈되면 클라이언트 연결 요청은 확률 C1/C2로 통과됩니다. 여기서 C1은 클라이언트의 SYN 패킷 수이고 C2는 공격자를 포함한 다른 모든 사람의 SYN 패킷 수입니다. 공격자의 채널에 초당 6개의 패킷 부하가 있어도 C1/C2는 약 1/100입니다. 서비스가 99% 다운되었습니다.

b) 반개방 연결의 무제한 버퍼. 공격자 채널의 로드가 100Mb/초이고 시간 초과가 약 1분인 경우 절반만 열린 연결 대기열은 약 1Gb의 메모리를 차지하게 되며 이는 대규모 서버에 치명적이지 않습니다. 부작용: 공격받은 서버는 공격자의 트래픽보다 3배 더 많은 트래픽(4배 DDoS라고 함)으로 응답하여 채널 대역폭을 소모할 수 있습니다. 그러나 채널 폭을 모두 소모하는 것이 불가능할 경우 공격에 대한 보호는 절대적이며 단일 클라이언트 연결이 거부되지 않습니다.

c) 가장 오래된 반개방 연결을 청소합니다. 버퍼가 오버플로되면 가장 오래된 반개방 연결이 제거됩니다. 부작용: 공격 중에 버퍼가 시간 t에 채워지면 클라이언트는 공격 중에 연결할 수 없습니다. 연결 확인 시간이 t보다 크면 해당 요청도 취소됩니다. 예를 들어, 공격자의 채널 로드가 4Mbit/초이고 버퍼 길이가 512(Win2K의 경우 권장 값)인 경우 시간 t는 약 50msec입니다. 이는 전화 접속에서 서버에 연결하려는 모든 시도를 거부하고 임대 회선에서 많은 것. 버퍼 크기를 늘리면 보호 수준이 이전 옵션으로 축소될 수 있습니다.

d) 싱크 쿠키. 버퍼가 소진된 후에는 버퍼에 맞지 않는 정보가 이를 요청한 클라이언트로 전송됩니다. 클라이언트가 진짜라면 정보를 다시 반환하고, 가짜라면 정보를 잃게 되며 메커니즘은 TCP를 통한 RFC 프레임워크 내에서 구현됩니다. 이 기술에 익숙하지 않은 고객도 지원됩니다. SYN COOKIE가 있는 운영 체제는 반개방 연결의 버퍼 크기에 관계없이 SYN 플러드 공격에 전혀 영향을 받지 않습니다. 부작용: "큰 창" 금지.

요약: SYN 플러드 공격은 더 이상 사용되지 않으며 현재는 기껏해야 채널 용량을 초과하는 일반적인 플러드 공격으로 사용될 수 있습니다.

DoS(약어: Denial of Service)는 시스템의 선의의 사용자가 제공된 시스템 리소스(서버)에 액세스할 수 없는 조건을 만드는 것을 목표로 컴퓨터 시스템에 대한 해커 공격입니다. 접근이 어렵습니다.

DoS/DDoS 공격에는 두 가지 유형이 있으며, 그 중 가장 일반적인 것은 플러딩(Flooding), 즉 엄청난 수의 패킷으로 피해자를 압도한다는 개념에 기반을 두고 있습니다. ICMP 플러드, SYN 플러드, UDP 플러드, HTTP 플러드 등 다양한 플러드가 있습니다. 최신 DoS 봇은 이러한 모든 유형의 공격을 동시에 사용할 수 있으므로 각 공격에 대해 사전에 적절한 보호 조치를 취해야 합니다.

DoS 공격 탐지

SYN 홍수

SYN 플러드의 존재 여부는 "반개방" TCP 연결 수를 세어 쉽게 확인할 수 있습니다. 정상적인 상황에서는 전혀 없어야 합니다(또는 매우 적은 양: 최대 1~3개).

DoS 공격으로부터 보호

패킷 조각을 차단합니다. 프로토콜의 기능적 목적으로 인해 ICMP 패킷은 매우 작아야 하며 일반적으로 MTU에 맞아야 하기 때문에 해당 조각의 존재는 일반적으로 오류 또는 공격 시도를 나타냅니다. iptables -A 입력 -p icmp -f -j DROP

귀하를 대신하여 스푸핑을 금지하십시오. iptables -A INPUT -m conntrack --ctstate NEW,INVALID -p tcp --tcp-flags SYN,ACK SYN,ACK -j LOG --log-level info --log-prefix "DROP SYN,ACK: " iptables - A 입력 -m conntrack --ctstate NEW,INVALID -p tcp --tcp-flags SYN,ACK SYN,ACK -j REJECT --reject-with tcp-reset

결국 아직 열려 있지 않은 연결을 통해 SYN 및 ACK 플래그가 설정된 패킷(SYN 패킷에 대한 응답에만 이 플래그 조합이 있음)을 수신하면 이는 누군가가 우리를 대신하여 다른 호스트에 SYN 패킷을 보냈다는 의미입니다. , 그리고 우리에게 응답이 왔습니다. 물론 공격자는 여전히 시퀀스 번호를 추측해야 하지만 공격자에게 그런 기회를 주지 않는 것이 좋습니다. 위의 규칙에 따라 호스트는 RST 패킷으로 응답하고, 이를 수신한 후 공격받은 호스트는 연결을 닫습니다. 방화벽 구성에 이러한 규칙을 추가하는 것이 좋습니다. 공격자가 사용자를 대신하여 스푸핑 공격을 수행하면 조사가 사용자에게로 이어질 수 있기 때문입니다.

SYN 홍수

통신 채널을 막을 뿐만 아니라 운영 체제의 네트워크 스택을 더 이상 새로운 연결 요청을 받아들일 수 없는 상태로 만드는 일반적인 방법 중 하나입니다. 존재하지 않는 반환 주소로 SYN 패킷을 전송하여 다수의 동시 TCP 연결을 초기화하려는 시도를 기반으로 합니다. 연결할 수 없는 주소로 응답 ACK 패킷을 보내려고 여러 번 시도한 후에 대부분의 운영 체제는 설정되지 않은 연결을 대기열에 넣습니다. 그리고 n번째 시도 후에만 연결이 닫힙니다. ACK 패킷의 흐름이 매우 크기 때문에 큐는 곧 가득 차고 커널은 새 연결을 열려는 시도를 거부합니다. 가장 똑똑한 DoS 봇은 또한 공격을 시작하기 전에 시스템을 분석하여 열려 있는 중요한 포트에만 요청을 보냅니다. 이러한 공격을 식별하는 것은 쉽습니다. 서비스 중 하나에 연결해 보세요. 방어 조치에는 일반적으로 다음이 포함됩니다.

"반개방" TCP 연결 대기열 늘리기:

"반개방" 연결 유지 시간 단축:

TCP syncookies 메커니즘 활성화:

UDP 플러드

대역폭 범람 방법. 이는 다양한 UDP 서비스의 포트로 UDP 패킷을 끝없이 보내는 것을 기반으로 합니다. 이러한 서비스를 외부 세계로부터 차단하고 단위 시간당 연결 수에 제한을 설정하면 쉽게 제거할 수 있습니다.

#포트 80에서는 연결 제한을 5개로 설정했습니다. iptables -A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 5 -j REJECT # 한 IP에서 smtp로의 동시 연결은 하나만 허용합니다 iptables -A FORWARD -p tcp --syn --dport smtp -m connlimit --connlimit-above 1 -j DROP # 포트 1720에서 연결 수 제한을 200개로 설정합니다. iptables -A INPUT -p tcp --syn --dport 1720 -m connlimit --connlimit-above 200 -j REJECT # udp 5060 $IPT -A INPUT -p udp --dport 5060 -m connlimit --connlimit-above 60 -j LOG --log-level info --log-prefix "REJECT 5060: " $IPT -A INPUT -p udp --dport 5060 -m connlimit --connlimit-above 60 -j REJECT # tcp 1720 $IPT -A 입력 -p tcp --syn --dport 1720 -m connlimit --connlimit-above 60 -j LOG --log-level info --log-prefix "REJECT 1720: " $IPT -A INPUT -p tcp --syn --dport 1720 -m connlimit --connlimit-above 60 -j 거부

ICMP 홍수

ICMP ECHO 네트워크 정체 진단 프로토콜(ping) 요청의 단조로운 전송을 통해 대역폭을 막고 네트워크 스택에 부하를 생성하는 매우 원시적인 방법입니다. 양방향 트래픽 흐름을 분석하여 쉽게 감지할 수 있습니다. ICMP 플러드 공격 중에 트래픽 흐름은 거의 동일합니다. 거의 고통스럽지 않은 절대적인 보호 방법은 ICMP ECHO 요청에 대한 응답을 비활성화하는 것을 기반으로 합니다.

Sysctl net.ipv4.icmp_echo_ignore_all=1

또는 방화벽을 사용하여:

Iptables -A INPUT -p icmp -j DROP --icmp-type 8

HTTP 플러드

ps aux 프로세스 수 | 그렙 아파치 | 화장실 -l

포트 80의 연결 수 netstat -na | grep ":80\ " | 화장실 -l

연결 요청이 들어오는 IP 주소 목록을 봅니다. netstat -na | grep ":80\ " | 정렬 | 유니크 -c | 정렬 -nr

sysctl

스푸핑 방지 net.ipv4.conf.default.rp_filter = 1

매분마다 TCP 연결을 확인하십시오. 반대편에 합법적인 차량이 있으면 즉시 대응합니다. 기본값은 2시간입니다. net.ipv4.tcp_keepalive_time = 60

10초 후에 다시 시도하십시오. net.ipv4.tcp_keepalive_intvl = 10

연결을 닫기 전 확인 횟수 net.ipv4.tcp_keepalive_probes = 5

데비안: DDoS에 맞서기

기본적으로 Debian 및 기타 운영 체제는 봇넷에 의해 생성된 엄청난 수의 연결을 지원할 수 없습니다. TCP/IP 스택을 강화하려면 커널 설정을 변경해야 합니다. 이 구성의 예:

Net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.eth0.accept_redirects = 0 net.ipv4.conf.default.accept_redirects = 0 net.core.rmem_max = 996777216 net.core.wmem_max = 996777216 net.ipv4 .tcp_rmem = 4096 87380 4194304 net.ipv4.tcp_mem= 786432 1048576 996777216 net.ipv4.tcp_wmem = 4096 87380 4194304 net.ipv4.tcp_max_orphans = 225536 0 net. core.netdev_max_backlog = 10000 net.ipv4.tcp_fin_timeout = 10 net.ipv4. tcp_keepalive_intvl = 15 net.ipv4.tcp_max_syn_backlog = 2048 net.ipv4.tcp_synack_retries = 1 kernel.msgmnb = 65536 kernel.msgmax = 65536 kernel.shmmax = 494967295 kernel.shmall = 268435456 net.core.somaxconn = 16096

커널 구성을 조심스럽게 변경하고 서버를 재부팅하십시오 ...

FreeBSD: DDoS에 맞서기

SYN-ACK 요청에 대한 응답 패킷의 대기 시간을 줄입니다(SYN 플러드 방지).

서버를 블랙홀로 만들었습니다. 이렇게 하면 비어 있는 포트에 연결하려고 할 때 커널이 응답 패킷을 보내지 않습니다(임의의 포트에서 DDoS를 수행하는 동안 시스템의 로드가 줄어듭니다).

ICMP 메시지에 대한 응답 수는 초당 50개로 제한됩니다(ICMP 플러드 방지).

서버에 대한 최대 연결 수를 늘립니다(모든 유형의 DDoS에 대한 보호).

DEVICE_POLLING을 활성화합니다 - 높은 부하에서 커널에 의한 네트워크 드라이버의 독립적인 폴링(DDoS 동안 시스템의 부하를 크게 줄입니다):

“options DEVICE_POLLING” 옵션을 사용하여 커널을 다시 빌드합니다. 폴링 메커니즘을 활성화합니다: "sysctl kern.polling.enable=1"; /etc/sysctl.conf에 "kern.polling.enable=1" 항목을 추가합니다.

DDoS 폭풍이 시스템을 강타할 때 절망적인 상황에 빠지지 않으려면 이러한 상황에 대해 신중하게 준비해야 합니다.

외부 네트워크에 직접 액세스할 수 있는 모든 서버는 간단하고 빠른 원격 재부팅을 위해 준비되어야 합니다(sshd는 러시아 민주주의의 아버지를 구할 것입니다). 큰 장점은 메인 채널이 막힌 경우 서버에 액세스할 수 있는 두 번째 관리 네트워크 인터페이스가 있다는 것입니다.

서버에서 사용되는 소프트웨어는 항상 최신 상태여야 합니다. 모든 구멍이 패치되었고 업데이트가 설치되었습니다(부팅만큼 간단하며 많은 사람들이 따르지 않는 조언). 이렇게 하면 서비스의 버그를 악용하는 DoS 공격으로부터 사용자를 보호할 수 있습니다.

관리용으로 의도된 모든 수신 네트워크 서비스는 해당 서비스에 액세스할 수 없는 모든 사람이 방화벽 뒤에 숨겨야 합니다. 그러면 공격자는 이를 사용하여 DoS 공격이나 무차별 공격을 수행할 수 없습니다.

서버(가장 가까운 라우터)에 접근할 때 트래픽 분석 시스템(NetFlow to the Rescue)을 설치해야 초기 공격에 대해 신속하게 파악하고 적시에 이를 방지할 수 있는 조치를 취할 수 있습니다.

실제로 SYN 플러드 공격에 대한 보호에 대해 이야기하겠습니다.

매우 널리 사용되는 DoS 공격에는 서버에 많은 수의 SYN 패킷을 보내는 것이 포함됩니다. 이 경우 TCP 통신 설치가 완료되지 않습니다. 반개방 연결 요청 대기열이 빠르게 채워져 정상적인 연결이 설정되지 않습니다. 이러한 공격은 연결을 종료할 필요가 없기 때문에 공격하는 머신에서 큰 자원을 요구하지 않으므로 구현 및 제어가 쉽습니다.

SYN 공격을 탐지하는 것은 쉽습니다. netstat 명령은 반쯤 열린 연결의 거대한 목록을 생성합니다.

Netstat -n --tcp | grep SYN_RECV tcp 0 0 xxx.xxx.xxx.xxx:80 yyy.yyy.yyy.yyy:1084 SYN_RECV tcp 0 0 xxx.xxx.xxx.xxx:80 yyy.yyy.yyy.yyy:1228 SYN_RECV tcp 0 0 xxx .xxx.xxx.xxx:80 yyy.yyy.yyy.yyy:2652 SYN_RECV TCP 0 0 xxx.xxx.xxx.xxx:80 yyy.yyy.yyy.yyy:3446 SYN_RECV

Netstat -n --tcp | grep SYN_RECV | 화장실 -l 238

먼저 매개변수를 확인해 보겠습니다. tcp_syncookies- 1과 같아야 합니다.

고양이 /proc/sys/net/ipv4/tcp_syncookies 1

그대로 두자. 기본적으로 이 옵션은 새 배포에서 항상 활성화됩니다.

tcp_syncookies 옵션이 설정된 경우(커널이 CONFIG_SYNCOOKIES로 빌드된 경우에만 사용 가능) 커널은 대기열이 가득 찰 때까지 TCP SYN 패킷을 정상적으로 처리합니다. 대기열이 가득 차면 SYN 쿠키 메커니즘이 활성화됩니다.

SYN 쿠키는 SYN 대기열을 전혀 사용하지 않습니다. 대신 커널은 각 SYN 패킷에 일반 SYN|ACK로 응답하지만 소스 및 대상 IP 주소와 포트는 물론 패킷이 전송된 시간을 기반으로 특별히 생성된 번호를 포함합니다. 공격자는 이러한 패킷을 절대 수신하지 않으므로 이에 응답하지 않습니다. 정상적인 연결 중에는 숫자가 포함된 세 번째 패킷이 전송되고, 서버는 그것이 SYN 쿠키에 대한 응답인지 확인하고, 그렇다면 SYN 큐에 해당 항목이 없더라도 연결을 허용합니다. .

SYN 쿠키 메커니즘을 활성화하는 것은 SYN 플러드 공격에 대처하는 매우 간단한 방법입니다. 쿠키를 생성하고 조정해야 하기 때문에 CPU 사용량이 조금 더 필요합니다. 대체 솔루션은 모든 연결 요청을 거부하는 것이므로 SYN 쿠키가 좋은 선택입니다.

또한 반쯤 열린 연결의 대기열을 늘려야 합니다. tcp_max_syn_backlog(Debian Lenny에는 기본적으로 1024개의 연결이 있습니다):

고양이 /proc/sys/net/ipv4/tcp_max_syn_backlog 1024

증가하다:

에코 "20000" > /proc/sys/net/ipv4/tcp_max_syn_backlog

또, 접속 대기 시간을 줄일 수 있다 tcp_synack_retries:

1바이트 정수 값 tcp_synack_retries는 수동 TCP 연결에 대해 SYNACK 패킷을 재시도하는 횟수를 지정합니다. 시도 횟수는 255회를 초과할 수 없습니다. 기본값 5는 연결 시도에 대한 약 180초에 해당합니다.

1로 줄입니다(약 9초).

에코 "1" > /proc/sys/net/ipv4/tcp_synack_retries

tcp_fin_timeout

tcp_fin_timeout 파일의 정수는 로컬 측에서 소켓을 닫은 후 소켓이 FIN-WAIT-2 상태로 유지되는 기간을 결정합니다. 피어는 이 연결을 절대로 닫을 수 없으므로 제한 시간이 만료된 후 자체적으로 닫아야 합니다. 기본 시간 제한은 60초입니다. 2.2 시리즈 커널은 일반적으로 180초 값을 사용했으며 이 값을 저장할 수 있지만 사용량이 많은 웹 서버에서는 절반 끊어진 연결이 끊어진 상태를 유지하는 데 많은 메모리를 낭비할 위험이 있다는 점을 기억하세요. FIN-WAIT-2 상태의 소켓은 1.5KB 이하의 메모리를 소비하므로 FIN-WAIT-1보다 덜 위험하지만 더 오래 지속될 수 있습니다.

30으로 변경:

에코 "30" > /proc/sys/net/ipv4/tcp_fin_timeout

tcp_keepalive_probes

tcp_keepalive_probes 정수 변수는 연결이 닫힌 것으로 간주되기 전에 전송된 Keepalive 프로브 수를 지정합니다. 기본적으로 9개의 샘플이 전송됩니다.

에코 "5" > /proc/sys/net/ipv4/tcp_keepalive_probes

tcp_keepalive_intvl

정수 변수 tcp_keepalive_intvl은 샘플링 간격을 지정합니다. tcp_keepalive_probes * tcp_keepalive_intvl 제품은 응답이 없을 경우 연결이 닫히는 시간을 결정합니다. 기본 간격은 75초입니다. 즉, 응답이 없을 경우 연결을 끊는 데 걸리는 시간은 약 11분입니다.

15로 설정해 보겠습니다.

에코 "15" > /proc/sys/net/ipv4/tcp_keepalive_intvl

netdev_max_backlog

이는 인터페이스가 커널이 처리할 수 있는 것보다 더 빠르게 패킷을 수신하는 경우 처리를 위해 대기열에 들어갈 최대 패킷 수를 지정합니다.

고양이 /proc/sys/net/core/netdev_max_backlog 1000

증가하다:

에코 "20000" > /proc/sys/net/core/netdev_max_backlog

소맥스콘

연결을 기다리는 최대 열린 소켓 수입니다.

고양이 1024

증가하다:

에코 "20000" > /proc/sys/net/core/somaxconn

커널 매개변수에 대한 이러한 변경 사항은 재부팅 후에 저장되지 않으므로 /etc/rc.local:

에코 "20000" > /proc/sys/net/ipv4/tcp_max_syn_backlog 에코 "1" > /proc/sys/net/ipv4/tcp_synack_retries 에코 "30" > /proc/sys/net/ipv4/tcp_fin_timeout 에코 "5" > /proc/sys/net/ipv4/tcp_keepalive_probes echo "15" > /proc/sys/net/ipv4/tcp_keepalive_intvl echo "20000" > /proc/sys/net/core/netdev_max_backlog echo "20000" > /proc/sys/ 넷/코어/somaxconn

또한 iptables에서 단위 시간당 SYN 패킷 수에 대한 제한을 추가할 수 있습니다.

Iptables -N syn_flood iptables -A INPUT -p tcp --syn -j syn_flood iptables -A syn_flood -m 제한 --limit 500/s --limit-burst 1500 -j 반환 iptables -A syn_flood -j DROP

새 SYN 패킷 수는 초당 최대 500개이며, 임계값 1500을 초과하면 새 패킷이 차단됩니다.

더 명확하게 말하면, 이 기준은 단위 시간당 특정 수의 패키지가 통과하는 배출구가 있는 특정 컨테이너(즉, "유출" 속도)로 상상할 수 있습니다. "누출" 비율은 --limit 값에 의해 정확하게 결정됩니다. --limit-burst 값은 총 "용량 볼륨"을 지정합니다. 이제 --limit 3/min --limit-burst 5라는 규칙을 가정해 보겠습니다. 그런 다음 5개의 패킷이 도착하면(매우 짧은 시간 내에) 용량이 "채워지고" 각 후속 패킷으로 인해 용량이 " 오버플로” 즉, 기준의 "트리거링". 20초 후에 탱크의 "레벨"이 낮아져(--limit 값에 따라) 탱크가 "오버플로"되지 않도록 다른 패킷을 수용할 준비가 됩니다. 기준을 발동시킵니다.

스푸핑된 SYN은 임의 또는 존재하지 않는 IP 주소가 실제 보낸 사람을 대신하는 방식으로 패킷 헤더를 위조하는 공격입니다.

면책조항

면책조항 #1

면책조항 #2

면책조항 #3

약간의 역학과 Wikipedia

첫째, TCP는 가장 많이 사용되는 전송 프로토콜 중 하나이며, 그 위에 대부분의 응용 프로그램 프로토콜이 있습니다. 둘째, 구현을 상대적으로 복잡하고 리소스 집약적으로 만드는 여러 가지 특수 기능(연결의 시작과 끝을 명시적으로 확인, 흐름 제어 등)이 있습니다.

이 기사의 맥락에서 TCP 연결을 설정하는 메커니즘, 즉 3방향 핸드셰이크를 고려하는 것은 흥미롭습니다. 첫 번째 근사치로 클라이언트-서버 수준에서는 다음과 같습니다: 클라이언트가 서버에 SYN 패킷을 보내고 SYN+ACK가 응답합니다. 클라이언트는 서버의 SYN에 대한 ACK로 응답하고 연결은 설정된 경로로 들어갑니다. 상태.

SYN 공격 – 어떤 이유로든 실제 연결이 설정되지 않는 개방형 서버 포트에 대량의 SYN 패킷을 보내는 것입니다. 이는 연결 대기열을 오버플로하는 "반개방 연결"을 생성하여 강제로 후속 클라이언트에 대한 서비스를 거부하는 서버입니다. 또한 TCP RFC는 서버가 들어오는 모든 SYN에 응답하도록 의무화하며 이는 서버 리소스와 데이터 전송 채널 모두에 추가로 영향을 미칩니다. 그러나 실제로 DDoS 공격을 이미 경험하셨다면 저 없이 위에서 설명한 내용을 아실 것입니다. 구체적인 권장 사항으로 넘어 갑시다.

들판에 혼자

첫 번째– 서버에 대한 액세스 권한을 얻어야 합니다(예, 이 또한 어려울 수 있습니다. 특히 공격이 대규모이거나 오래 지속되는 경우 - 서버가 단순히 모든 버퍼를 소진했거나 CPU 로드가 100%인 경우). 일반적으로 이렇게 하려면 공격받은 서비스를 방화벽으로 닫거나 서비스를 끄는 것으로 충분합니다(그러나 공격이 감지되면 어떤 경우에도 이 작업을 수행해야 합니다. 서버에서 다른 작업을 수행하세요).

두번째– 공격에 대한 첫 번째 정보를 얻습니다. 들어오는 트래픽을 이미 모니터링했다면(좋지 않다면) 방화벽을 열고 서비스를 높이고 오래된 tcpdump 및 netstat를 사용하여 정확히 공격 대상이 무엇인지, 공격 크기(초당 패킷 수)가 얼마인지 알아보세요. 그 과정에서 대량 요청이 들어오는 네트워크를 신속하게 볼 수 있습니다. 해당 네트워크가 귀하의 서비스에 대한 일반적인 대상 그룹에 포함되어 있는지 여부도 알 수 있습니다. 이 모든 것이 미래에 유용할 것입니다.

제삼– 공격받은 IP 주소가 있는 인터페이스에는 하나만 남아 있어야 합니다. 각 별칭은 시스템 성능을 저하시킵니다. 이는 시스템마다 다른 숫자로 표시되지만 이 숫자는 심각합니다. 각 별칭에는 초당 2~3,000개의 패킷이 추가로 필요할 수 있습니다.

네번째– 공격받은 주소로 들어오는 트래픽에 대해 방화벽을 사용하는 경우 차단을 제외한 모든 규칙을 비활성화해야 합니다. 예를 들어 스푸핑된 SYN 공격의 경우 PF의 SYN 프록시가 도움이 될 가능성이 0이 되고 CPU는 이 매우 심각하게 받아들일 것입니다.

다섯– 시스템을 설정합니다. 여기에는 기적이 없으며 준비된 드라이버와 특별히 구매한 네트워크 카드 형태로 덤불에 피아노가 필요하며 SYN 공격을 수신하는 능력에 심각한 영향을 미치는 유일한 두 가지 일반적인 권장 사항은 오랫동안 모든 사람에게 알려져 왔습니다.
- 서버 프로세서 전반에 걸쳐 인터럽트 처리를 분산시킵니다.
- 싱크 쿠키를 활성화하고 싱크 캐시를 비활성화합니다.

시스템 조정의 나머지 부분은 추가로 5~10,000개의 패킷을 짜내는 데 도움이 되지만 공격 상황에서는 결정적이지 않을 것입니다. 누구에게나 유용할 경우를 대비해 가장 일반적인 구성은 다음과 같습니다(커널이나 특수 드라이버를 다시 빌드해야 하는 옵션을 활성화하지 않음).

Net.isr.direct=1 kern.ipc.nmbclusters=400000 net.inet.tcp.nolocaltimewait=1 net.inet.tcp.recvspace=16384 net.inet.tcp.sendspace=32768 net.inet.tcp.msl=5000 net.inet.tcp.blackhole=1 net.inet.ip.intr_queue_maxlen=3000 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.inet.icmp.log_redirect=1 net.inet.ip .redirect=0 net.inet.icmp.maskrepl=1 net.inet.tcp.syncookies_only=1 net.route.netisr_maxqlen=4096 kern.ipc.maxsockbuf=83886080 net.inet.ip.intr_queue_maxlen=10240
다음 지침에 따라 구성된 데스크탑 수준 시스템:

First# netstat -w1 -h -d 입력(총계) 출력 패킷 errs idrops bytes packets errs bytes collsdrops 260K 0 0 15M 230K 0 13M 0 0
다음 권장사항에 따라 구성된 IBM System x3630 M3 레벨 시스템:

두 번째# netstat -w1 -h -d 입력(총계) 출력 패킷 오류 idrops 바이트 패킷 오류 바이트 colls 삭제 477K 0 0 36M 457K 0 25M 0 0
다음 주제에서는 OS와 머신의 세부 구성과 실제로 이에 도달한 방법에 대해 설명하겠습니다.

한 가지만 하자

여기서 약간의 여담을 만들 가치가 있습니다. 대부분의 호스팅 회사는 공격에 맞서 싸우는 데 도움을 주기를 극도로 꺼릴 것이며 이에 대해 비난하기는 어렵습니다. 그러나 최소한 그들은 공격에 대한 데이터를 제공할 것입니다. 보호 공급자와 협력해야 하는 경우 공격 중에 수집한 정보와 결합되어 생활이 훨씬 쉬워질 것입니다.

이해하는 호스팅 업체를 만난다면(정말 매우 드물다) – 그런 다음 다음 알고리즘에 따라 작업합니다. 병렬과 블록, 블록과 병렬:
네트워크 카드가 여러 개인 경우(그렇지 않은 경우 설치하십시오) - LACP 모드로 켭니다(이를 위해서는 호스터 스위치에서 유사한 옵션을 활성화해야 합니다). 이렇게 하면 실제로 성능이 1.5배 증가합니다. (나중에 프로세스의 미묘함 중 일부를 살펴보겠습니다. 주제가 제대로 작동하지 않는다는 사실을 이해하기 위해) 우리는 다음과 같은 성능에 도달했습니다.

두 번째# netstat -w1 -h -d 입력(총계) 출력 패킷 errs idrops 바이트 패킷 errs 바이트 colls 삭제 1.2M 16K 0 65M 1.1M 0 59M 0 0
사용하지 않는 모든 포트와 프로토콜을 차단하십시오. SYN 공격은 UDP 공격으로 쉽게 대체될 수 있습니다.
거의 모든 호스팅 회사가 이러한 작업을 수행할 수 있습니다. 그러나 운이 좋게도 진지한 회사와 일할 수 있다면 프로젝트의 청중 대부분이 거주하지 않는 지역(예: 중국)의 트래픽을 차단하도록 요청하십시오. 이는 일반적으로 백본 공급자에게 네트워크의 블랙홀을 알리는 것을 의미합니다. 특정 지역에서. 일반적으로 SYN 공격은 가격이 저렴하고 대량 배포되기 때문에 아시아에서 수행되므로 이러한 발표는 공격에 맞서 싸우는 데 심각하게 도움이 되거나 공격 가능성을 완전히 제거할 수 있습니다.

위에서 설명한 조치 외에도 특정 조건(예: 도메인에서 공격이 수행됨)에서 GeoDNS와 유사한 서비스를 사용하는 것이 좋습니다. 이는 특정 네트워크에 대한 블랙홀을 알리는 것과 유사하게 작동합니다.

마지막으로

UPD. 계속되는 내용은 작성 중이며 곧 여기에 게시될 예정입니다. 우리와 함께 있어주세요!

SYN 플러드 공격은 공격자가 TCP 프로토콜을 사용하는 대상 시스템의 서비스에 대량의 SYN 요청을 보내는 서비스 거부 공격의 한 형태입니다. 이로 인해 서버 리소스가 소모되어 시스템이 합법적인 트래픽에도 응답하지 않게 됩니다. 이 공격은 TCP 프로토콜을 사용하는 모든 서비스에서 발생할 수 있지만 주로 웹 서비스에서 발생합니다. 이 튜토리얼에서는 SYN 플러드 공격의 기본 사항과 완화 단계를 자세히 살펴보겠습니다.

SYN Flood 공격은 3방향 핸드셰이크라고 하는 TCP(전송 제어 프로토콜)의 구현 특성을 이용합니다. 다음은 일반적인 3방향 핸드셰이크에서 발생하는 단계입니다.

1. 클라이언트는 서버에 SYN(동기화) 메시지를 보내 연결을 요청합니다.
2. 서버는 SYN-ACK를 클라이언트에 다시 보냄으로써 이 요청을 승인합니다.
3. 클라이언트는 ACK로 응답하고 연결이 설정됩니다.

SYN 플러드 공격은 예상되는 ACK 코드로 서버에 응답하지 않음으로써 작동합니다. 이러한 반개방 연결로 인해 대상 시스템의 TCP 백로그가 채워지고 따라서 모든 새 연결이 무시될 수 있습니다. 이로 인해 합법적인 사용자도 무시됩니다.

이 공격은 두 가지 방법으로 발생할 수 있습니다.

1. 직접 공격

이러한 종류의 공격에서 공격자는 IP 소스 주소를 스푸핑하지 않고 SYN 세그먼트를 빠르게 보냅니다. 이러한 유형의 공격이 감지되면 방어하기가 매우 쉽습니다. 공격할 공격자의 소스 IP 주소로 패킷을 차단하는 간단한 방화벽 규칙을 추가할 수 있기 때문입니다.

2.IP 주소 스푸핑 사용

이는 직접 공격보다 더 복잡한 형태의 공격입니다. 이 방법에서는 악의적인 시스템이 스푸핑된 IP 주소에서 대상 시스템으로 SYN 요청 플러드를 보내 서버가 위조된 IP 주소로 SYN-ACK를 보내게 합니다. 이는 ACK가 결코 전송되지 않는다는 것을 "알기" 때문에 전송하지 않습니다. SYN을 보냈습니다.

SYN 플러드 공격 감지

웹 사이트 방문자에 대한 SYN Flood 공격의 일반적인 증상은 사이트를 로드하는 데 오랜 시간이 걸리거나 페이지의 일부 요소는 로드되지만 다른 요소는 로드되지 않는다는 것입니다. 웹 서버에 대한 SYN Flood 공격이 의심되는 경우 "SYN_RECEIVED" 상태에 있는 웹 서버 연결 요청을 확인하는 데 사용할 수 있습니다.

netstat -tuna | grep:80 | grep SYN_RECV

이 상태의 연결이 많이 표시되면 서버가 SYN Flood 공격을 받고 있을 수 있습니다. 단일 IP 주소에서 다수의 SYN_RECV 패킷이 직접 공격되는 경우 방화벽에 해당 IP 주소를 추가하여 이 공격을 중지할 수 있습니다. 서버에 APF 또는 방화벽이 설치되어 있는 경우 다음 명령을 실행하여 이를 수행할 수 있습니다.

apf –d IP 주소
csf –d IP 주소

SYN Flood 공격 방어

SYN 쿠키 사용

이는 SYN Flood 공격을 방어하는 가장 효과적인 방법입니다. SYN 쿠키를 사용하면 SYN 대기열이 가득 찼을 때 서버에서 연결이 끊어지는 것을 방지할 수 있습니다. 대신 서버는 SYN 대기열이 확대된 것처럼 동작합니다. 서버는 적절한 SYN+ACK 응답을 클라이언트에 다시 보내지만 SYN 대기열 항목을 삭제합니다. 서버가 클라이언트로부터 후속 ACK 응답을 받으면 TCP 시퀀스 번호에 인코딩된 정보를 사용하여 SYN 대기열 항목을 재구성할 수 있습니다.

SYN 쿠키는 /etc/sysctl.conf에 다음을 추가하여 활성화할 수 있습니다.

net.ipv4.tcp_syncookies = 1

sysctl 구성 파일을 수정한 후 다음 명령을 실행하여 /etc/sysctl.conf 파일에서 sysctl 설정을 로드해야 합니다.

SYN 백로그 대기열 늘리기

선택적 방어 기술은 SYS 백로그 대기열 크기를 늘리는 것입니다. 기본 크기는 1024입니다. 이는 /etc/sysctl.conf에 다음을 추가하여 수행할 수 있습니다.

net.ipv4.tcp_max_syn_backlog = 2048

SYN_ACK 재시도 줄이기

커널 매개변수 tcp_synack_retries를 조정하면 커널이 SYN_RECV 상태 연결을 더 일찍 닫게 됩니다. 기본값은 5입니다.

net.ipv4.tcp_synack_retries = 3

SYN_RECV 시간 초과 설정

SYN_RECV의 시간 초과 값을 낮추면 SYN 플러드 공격을 줄이는 데 도움이 됩니다. 기본값은 60이며 40 또는 45로 줄일 수 있습니다. 이는 sysctl.conf에 다음 행을 추가하여 수행할 수 있습니다.

net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv=45

IP 스푸핑 방지

다음 sysctl 매개변수는 SYN 플러드 공격에 사용되는 IP 스푸핑으로부터 보호하는 데 도움이 됩니다.

net.ipv4.conf.all.rp_filter = 1

많은 호스팅 회사에서는 Netscreen 또는 Appsafe와 같은 SYN 플러드 방어를 사용하는 방화벽을 배포하여 SYN 공격으로부터 보호합니다.