적은 수의 SYN_RECV 연결에도 불구하고 로그에“가능한 SYN 플러딩”


30

최근에 우리는 SYN 플러딩으로 인해 아파치 서버가 매우 느리게 응답했습니다. 이에 대한 해결 방법은 tcp_syncookies ( net.ipv4.tcp_syncookies=1 in /etc/sysctl.conf) 를 활성화하는 것 입니다.

더 많은 배경을 원한다면 여기 에 대한 질문을 게시했습니다 .

syncookies를 활성화 한 후 약 60 초마다 / var / log / messages에 다음 메시지가 표시되기 시작했습니다.

[84440.731929] possible SYN flooding on port 80. Sending cookies.

Vinko Vrsalovic는 이것이 syn 백 로그가 가득 찼음을 의미한다고 알려주므로 tcp_max_syn_backlog를 4096으로 올렸습니다. 또한 어느 시점에서을 발행하여 tcp_synack_retries를 3 (기본값 5에서 아래로)으로 내 렸습니다 sysctl -w net.ipv4.tcp_synack_retries=3. 이렇게 한 후 메시지 간격이 약 60 초에서 180 초 사이로 바뀌면서 빈도가 줄어드는 것처럼 보였습니다.

다음으로 발행 sysctl -w net.ipv4.tcp_max_syn_backlog=65536했지만 여전히 로그에 메시지가 표시됩니다.

이 모든 과정에서 SYN_RECV 상태 (실행 중 watch --interval=5 'netstat -tuna |grep "SYN_RECV"|wc -l') 의 연결 수를 보았 으며 백 로그 크기보다 훨씬 낮은 약 240 이상 으로 올라가지 않았습니다. 그러나 나는 약 512 정도의 Red Hat 서버를 가지고 있습니다 (이 서버의 한계는 기본값 1024입니다).

백 로그의 크기를 제한하는 다른 TCP 설정이 있습니까? 아니면 잘못된 트리를 짖고 있습니까? SYN_RECV 연결 수가 netstat -tuna백 로그의 크기와 관련 이 있어야합니까 ?


최신 정보

내가 합법적 인 연결을 다루고 있다고 말할 수있는 가장 좋은 netstat -tuna|wc -l것은 5000 명 정도입니다. 나는 오늘 이것을 연구 하고 있으며 last.fm 직원으로부터이 게시물 을 찾았 습니다 .

또한 syncookies가 활성화되어있을 때 tcp_max_syn_backlog가 영향을 미치지 않는다는 것을 발견했습니다 ( 이 링크에 따라 )

다음 단계로 sysctl.conf에서 다음을 설정했습니다.

net.ipv4.tcp_syn_retries = 3
        # default=5
net.ipv4.tcp_synack_retries = 3
        # default=5
net.ipv4.tcp_max_syn_backlog = 65536
        # default=1024
net.core.wmem_max = 8388608
        # default=124928
net.core.rmem_max = 8388608
        # default=131071
net.core.somaxconn = 512
        # default = 128
net.core.optmem_max = 81920
        # default = 20480

그런 다음 응답 시간 테스트를 설정하고 sysctl -pby by syncookies를 실행 및 비활성화했습니다 sysctl -w net.ipv4.tcp_syncookies=0.

이 작업을 수행 한 후 SYN_RECV 상태의 연결 수는 여전히 220-250으로 유지되었지만 연결이 다시 지연되기 시작했습니다. 이러한 지연이 발견되면 syncookies를 다시 활성화하고 지연이 중지되었습니다.

내가보고있는 것은 여전히 ​​초기 상태에서 개선 된 것이라고 생각하지만 일부 요청은 여전히 ​​지연되어 syncookies를 활성화하는 것보다 훨씬 나쁩니다. 따라서 부하에 대처하기 위해 더 많은 서버를 온라인 상태로 만들 수있을 때까지 서버를 사용하도록 설정 한 것 같습니다. 그럼에도 불구하고 서버 버퍼가 가득 찼을 때 (보증 적으로) 전송되기 때문에 다시 비활성화 해야하는 유효한 이유가 확실하지 않습니다.

그러나 syn 백로 그는 SYN_RECV 상태에서 ~ 250 개의 연결만으로 가득 찬 것으로 보이지 않습니다! SYN 플러딩 메시지가 빨간색 청어 일 수 있으며 채워지는 syn_backlog 이외의 것일 수 있습니까?

다른 튜닝 옵션이있는 사람이 아직 시도하지 않은 경우 시도해 보는 것이 행복하지만 syn_backlog 설정이 어떤 이유로 제대로 적용되지 않는지 궁금합니다.


답변:


27

그래서 이것은 깔끔한 질문입니다.

처음에는 SYN 쿠키가 활성화 된 SYN_RECV 상태의 모든 연결 을보고 놀랐습니다 . SYN 쿠키의 장점은 암호화를 사용하여 TCP 3-way 핸드 셰이크에 서버로 상태에 무조건 참여할 수 있다는 것입니다. 따라서 서버는 반 열린 연결을 전혀 나타내지 않을 것으로 예상됩니다. 유지되지 않습니다.

사실, 소스 (tcp_ipv4.c)를 살펴보면 커널이 SYN 쿠키를 구현하는 방법에 대한 흥미로운 정보가 표시됩니다. 기본적으로 커널을 켜더라도 커널은 보류중인 연결 큐가 가득 찰 때까지 정상적으로 작동합니다. SYN_RECV 상태의 기존 연결 목록에 대해 설명합니다.

보류중인 연결 큐가 가득 찼고 다른 SYN 패킷 (연결 시도)이 수신되고 마지막 경고 메시지 이후 1 분 이상 경과 한 경우에만 커널이 사용자가 본 경고 메시지를 보냅니다 ( "쿠키 보내기"). ). SYN 쿠키는 경고 메시지가 나타나지 않더라도 전송됩니다. 경고 메시지는 문제가 사라지지 않았다는 것입니다.

다시 말해 SYN 쿠키를 끄면 메시지가 사라집니다. 더 이상 SYN 홍수가 발생하지 않는 경우에만 해결됩니다.

수행 한 다른 작업을 처리하려면 다음을 수행하십시오.

  • net.ipv4.tcp_synack_retries:
    • 이 값을 늘리면 스푸핑되는 들어오는 연결이나 서버 쪽 상태 대신 SYN 쿠키를받는 연결 (재시도 없음)에 긍정적 인 영향을 미치지 않습니다.
    • 들어오는 스푸핑 된 연결의 경우이 값을 늘리면 가짜 주소로 보내는 패킷 수가 증가하고 스푸핑 된 주소가 연결 테이블에 머무르는 시간이 늘어납니다 (이로 인해 부정적인 영향을 줄 수 있음).
    • 들어오는 연결의 정상적인로드 / 개 수에서이 값이 클수록 패킷을 삭제하는 링크를 통해 연결을 신속하고 성공적으로 완료 할 가능성이 높아집니다. 이를 늘리면 수익이 감소합니다.
  • net.ipv4.tcp_syn_retries: 변경하면 인바운드 연결에 영향을 미치지 않습니다 (아웃 바운드 연결에만 영향을 미침)

내가 언급하지 않은 다른 변수는 조사하지 않았지만 귀하의 질문에 대한 답변이 여기에 거의 있다고 생각합니다.

SYN이 범람하지 않고 시스템이 비 HTTP 연결 (예 : SSH)에 응답하는 경우 네트워크 문제가 있다고 생각되며 네트워크 엔지니어에게 도움을 요청해야합니다. SYN 플러드되지 않은 상태에서도 시스템이 일반적으로 응답하지 않으면 TCP 연결 생성에 영향을주는 심각한로드 문제인 것 같습니다 (꽤 낮은 수준 및 리소스 비 집약적)


감사합니다-이것은 흥미롭고 유익한 답변입니다. SYN_RECV 상태의 연결과 쿠키 전송 간의 관계에 대한 쿼리에 확실히 응답합니다. 머신은 HTTP보다 훨씬 적은 트래픽을 수신하는 SSH 및 HTTPS를 포함하여 비 HTTP에 응답했습니다. 따라서 트래픽을 줄이는 것이 가장 좋은 방법이라고 결정했습니다.
Alex Forbes

네트워크 엔지니어가 좋은 제안을 할 수 있도록하는 것과 관련하여 좋은 제안이지만이 데이터 센터에서 마이그레이션하고 있으므로 다른 서버를 온라인으로 가져 오는 경우 가치가 없습니다. 로드 밸런서 또는 방화벽에 문제가있을 수 있습니다. 통찰력에 다시 한번 감사드립니다!
Alex Forbes

13

무거운로드 된 웹 사이트로 웹 서버 (apache2)를 실행하는 Ubuntu Oneiric 11.10을 새로 설치하는 것과 똑같은 문제에 직면했습니다. Ubuntu Oneiric 11.10에서 syncookies는 기본적으로 활성화되었습니다.

웹 서버 포트에서 가능한 SYN 플러드 공격을 나타내는 동일한 커널 메시지가 있습니다.

커널 : [739408.882650] TCP : 포트 80에서 SYN 플러딩이 발생할 수 있습니다. 쿠키를 보내는 중입니다.

동시에, 나는 어떤 공격도 일어나지 않을 것이라고 확신했다. 이 메시지를 5 분 간격으로 반환했습니다. 공격자가 서버의 요청에 대한 응답을 중지 시키려고 시도하는 동안 공격자가 항상 부하를 높게 유지하기 때문에 이것은로드 픽과 같았습니다.

net.ipv4.tcp_max_syn_backlog매개 변수를 조정 해도 아무런 개선이 이루어지지 않았습니다. 메시지는 같은 속도로 계속되었습니다. SYN_RECV 연결 수가 항상 실제로 (250 이하의 경우) 낮았다는 사실은이 메시지를 담당하는 다른 매개 변수가 있어야한다는 지표입니다.

Red Hat 사이트 에서이 버그 메시지 https://bugzilla.redhat.com/show_bug.cgi?id=734991 을 발견 했습니다. 응용 프로그램 측에서 버그 (또는 구성 오류)로 인해 커널 메시지가 발생할 수 있음을 나타내는 . 물론 로그 메시지는 매우 오도됩니다! 이 경우 책임이있는 커널 매개 변수가 아니라 응용 프로그램의 매개 변수가 커널에 전달되었습니다.

따라서 웹 서버 응용 프로그램의 구성 매개 변수도 살펴 봐야합니다. 아파치 문서를 잡고 http://httpd.apache.org/docs/2.0/mod/mpm_common.html#listenbacklog 로 이동 하십시오.

ListenBacklog매개 변수 의 기본값 은 511입니다. 이는 Red Hat 서버에서 관찰 한 연결 수에 해당합니다. 다른 서버에 더 낮은 수의 구성이있을 수 있습니다.

Apache에는 들어오는 연결을위한 백 로그 큐에 대한 자체 구성 매개 변수가 있습니다. 들어오는 연결이 많고 (임의의 경우와 마찬가지로) 거의 동시에 모든 웹 서버가 도착하면 웹 서버가 적절한 방식으로 충분히 빨리 서비스를 제공 할 수 없습니다. 511 개의 연결로 가득 차면 커널은 SYN 서비스 장애 공격 가능성을 알리는 위의 메시지를 발생시킵니다.

이 문제를 해결하려면 /etc/apache2/ports.conf아파치에 의해로드 될 다른 .conf 파일에 다음 줄을 추가하십시오 (확인 /etc/apache2/apache2.conf해야 함).

ListenBackLog 5000

또한 net.ipv4.tcp_max_syn_backlog적절한 값으로 설정해야 합니다. 내가 이해하기에 커널 최대 값은 값을 제한하여 아파치 구성에서 구성 할 수 있습니다. 그래서 실행하십시오 :

sudo sysctl -w net.ipv4.tcp_max_syn_backlog=5000

설정을 조정 한 후 아파치를 다시 시작하는 것을 잊지 마십시오 :

sudo service apache2 restart ( or sudo /etc/init.d/apache2 restart )

필자의 경우이 구성 변경으로 인해 커널 경고가 즉시 중지되었습니다. 아파치 구성에서 낮은 ListenBackLog 값을 설정하여 메시지를 재생할 수 있습니다.


2
좋은 대답입니다. 당신이 말한 것이 맞다고 가정하면이 답변을 허용 된 답변으로 표시하지만 실제로 테스트 할 수는 없습니다-부하를 줄이면 문제가 해결되었으며 좋은 이유없이 프로덕션 서버를 다루지 않는 정책이 있습니다 :)
Alex Forbes

이것이 기본적으로 커널 안티 -DDOS 기능이라는 것을 알 수 있지만 많은 웹 트래픽을 수신하면 합법적 인 사용자를 차단하게됩니다!
Areeb Soo Yasir

5

커널 3.4.9를 사용한 일부 테스트 후 netstat의 SYN_RECV 연결 수는

  • /proc/sys/net/core/somaxconn 다음 2의 거듭 제곱으로 올림 (예 : 128-> 256)
  • /proc/sys/net/ipv4/tcp_max_syn_backlogif의 75 %가로 /proc/sys/net/ipv4/tcp_syncookies설정되어 0있거나 100 %가로 /proc/sys/net/ipv4/tcp_syncookies설정된 경우1
  • ListenBackLog 아파치 설정에서 2의 다음 거듭 제곱으로 올림 (예 : 128-> 256)

이 매개 변수 각각의 최소값이 사용됩니다. somaxconn 또는 ListenBackLog를 변경 한 후 아파치를 다시 시작해야합니다.

그리고 tcp_max_syn_backlog를 증가시킨 후에도 아파치를 다시 시작해야합니다.

tcp_syncookies가 없으면 아파치가 차단 되므로이 경우 tcp_max_syn_backlog의 75 %만이 한계입니다. 이 매개 변수를 늘리면 아파치를 다시 시작하지 않고 SYN_RECV 연결을 이전 값의 100 %로 증가시킵니다.


또한 전화 /bin/echo m >/proc/sysrq-trigger인해 포트 80에서 SYN 플러딩발생할 수 있습니다 . 쿠키 메시지 보내기 .
usoft
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.