그래서 내 서버가 서비스 거부 공격을 받고 있는 것 같습니다.
우리는 pingdom(웹사이트 모니터링)으로부터 새벽 3시쯤부터 웹사이트를 사용할 수 없다는 알림을 받았습니다. 오늘 일찍 우리는 아파치 오류 로그를 확인하기 시작했고 다음과 같은 오류가 많이 발견되었습니다.
AH00485: 점수판이 가득 찼습니다. MaxRequestWorkers가 아닙니다.
또한 우리는 더 많은 서버를 생성하기 위해 PHP-FPM 프로세스 풀이 자주 필요하다는 것을 확인했습니다.
[풀 www] 바쁜 것 같습니다(pm.start_servers 또는 pm.min/max_spare_servers를 늘려야 할 수도 있음). 8명의 하위가 생성됩니다.
우리는 Apache conf 및 기타 해결 방법에서 MaxRequestWorkers를 늘리려고 시도했지만 Apache 오류 로그의 점수판 오류를 제거하지 못했기 때문에 더 나은 판단으로는 다음의 조언을 따랐습니다.이 스레드그리고 설정최소 예비 스레드그리고최대 예비 스레드동일MaxRequestWorkers. 이러한 변경으로 점수판 오류가 제거된 것으로 보입니다.
또한 활용되지 않는 RAM이 많기 때문에 MaxRequestWorkers도 크게 늘렸습니다. 우리 서버에는 8개의 코어가 있으며 이렇게 높은 구성 값에도 불구하고 RAM을 전혀 사용하지 않는 것 같습니다.
$ free -h
total used free shared buff/cache available
Mem: 7.8G 1.8G 2.0G 38M 4.0G 5.8G
Swap: 0B 0B 0B
저는 Apache conf의 MaxRequestWorkers와 php-fpm 구성의 pm.max_children에 대한 이러한 높은 값에 대해 매우 불안합니다.
mpm_event.conf의 기본 구성은 다음과 같습니다.
<IfModule mpm_event_module>
StartServers 2
MinSpareThreads 800
MaxSpareThreads 800
ThreadLimit 64
ThreadsPerChild 25
ServerLimit 800
MaxRequestWorkers 800
MaxConnectionsPerChild 0
</IfModule>
다음은 php-fpm conf 파일의 일부 설정입니다:
pm.max_children = 256
pm.start_servers = 64
pm.min_spare_servers = 64
pm.max_spare_servers = 128
다음은 몇 가지 기본 서버 정보입니다.
Server version: Apache/2.4.18 (Ubuntu)
Server built: 2019-10-08T13:31:25
Server's Module Magic Number: 20120211:52
Server loaded: APR 1.5.2, APR-UTIL 1.5.4
Compiled using: APR 1.5.2, APR-UTIL 1.5.4
Architecture: 64-bit
Server MPM: event
threaded: yes (fixed thread count)
forked: yes (variable process count)
Apache 서버 상태 출력의 일부 데이터는 다음과 같습니다.
Server Version: Apache/2.4.18 (Ubuntu) OpenSSL/1.0.2g
Server MPM: event
Server Built: 2019-10-08T13:31:25
Current Time: Friday, 10-Jan-2020 22:58:55 CST
Restart Time: Friday, 10-Jan-2020 22:26:32 CST
Parent Server Config. Generation: 1
Parent Server MPM Generation: 0
Server uptime: 32 minutes 22 seconds
Server load: 4.69 5.06 5.12
Total accesses: 78434 - Total Traffic: 1.5 GB
CPU Usage: u2970.53 s5037.34 cu0 cs0 - 412% CPU load
40.4 requests/sec - 0.8 MB/second - 19.7 kB/request
797 requests currently being processed, 3 idle workers
PID Connections Threads Async connections
total accepting busy idle writing keep-alive closing
6124 28 yes 25 0 0 0 3
6125 27 yes 25 0 0 0 2
6182 30 yes 25 0 0 1 4
6210 28 yes 25 0 0 0 3
6211 29 yes 25 0 0 0 5
6266 28 yes 25 0 0 2 1
6267 25 yes 25 0 0 0 1
6269 28 no 24 1 0 1 3
6276 28 yes 25 0 0 0 3
6378 28 yes 25 0 0 0 3
6379 31 no 24 1 0 4 3
6380 27 yes 25 0 0 0 3
6384 26 yes 25 0 0 0 2
6397 28 yes 25 0 0 2 1
6405 27 yes 25 0 0 0 2
6414 26 yes 25 0 0 1 0
6423 27 no 24 1 0 1 1
6602 27 yes 25 0 0 0 3
6603 28 yes 25 0 0 0 4
6604 26 yes 25 0 0 0 1
6617 30 yes 25 0 0 0 5
6646 26 yes 25 0 0 0 2
6676 27 yes 25 0 0 0 2
6694 30 yes 25 0 0 0 5
6705 28 yes 25 0 0 0 3
6730 29 yes 25 0 0 0 4
6765 29 yes 25 0 0 0 4
6781 27 yes 25 0 0 0 2
6805 28 yes 25 0 0 0 4
6836 28 yes 25 0 0 0 3
6858 27 yes 25 0 0 0 3
6859 27 no 25 0 0 1 1
Sum 888 797 3 0 13 86
작업자 모드 부분이 가장 당황스럽습니다. 거의 모든 것이 읽기 모드에 있습니다.
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRR_RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
_RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRWRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR_RRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
그리고 마지막에는 이런 내용이 있습니다.
SSL/TLS Session Cache Status:
cache type: SHMCB, shared memory: 512000 bytes, current entries: 2176
subcaches: 32, indexes per subcache: 88
time left on oldest entries' objects: avg: 220 seconds, (range: 197...243)
index usage: 77%, cache usage: 99%
total entries stored since starting: 60122
total entries replaced since starting: 0
total entries expired since starting: 0
total (pre-expiry) entries scrolled out of the cache: 57946
total retrieves since starting: 3405 hit, 59594 miss
total removes since starting: 0 hit, 0 miss
그리고 netstat에서는 포트 80과 포트 443에 대한 약 3000개 이상의 연결을 보여줍니다.
$ netstat -n | egrep ":80|443" | wc -l
3715
도대체 무슨 일이 일어나고 있는 걸까요? 서버는 몇 달 동안 잘 작동하고 있습니다.훨씬 더 겸손한 구성 설정.어젯밤 새벽 3시쯤 뭔가 갑자기 변한 것 같습니다.
어떤 지침이라도 대단히 감사하겠습니다. 여기를 먼저 검색해서 알아냈어요이 다른 스레드하지만 그것은 나와 같은 이벤트 대신 프리포크 모드에서 실행되는 다른 버전의 아파치입니다. 또한 해당 스레드의 약간의 정보가 어떻게 SlowLoris 진단으로 이어졌는지 이해하지 못합니다.
편집 내 질문을 더 정확하게 표현해야 할 것 같습니다.
1) 서버의 응답성을 어떻게 복원할 수 있습니까? 분명히 아파치 작업자가 갇히고 있습니다.아르 자형모드는 어떤 문제의 증상입니다.
2) 실제 문제를 보다 구체적으로 식별하기 위해 취할 수 있는 신뢰할 수 있는 일련의 단계가 있습니까?
3) 해당 기기가 DoS 공격을 받고 있는지 확인할 수 있는 방법이 있나요?
답변1
단순히 점수판의 연결 수를 세는 것만으로는 고객이 무례하고 연결에 대한 후속 조치를 취하지 않는다는 것을 알 수 있는 충분한 증거가 아닙니다. 이는 급격한 증가이므로 웹 앱이 큰 인기를 얻었거나 누군가 어리석은 요청을 하고 있는 것입니다.
초당 완료된 요청 비율을 살펴보세요. 웹 앱이 적절하게 작동한다고 가정할 때 작업자 수가 많으면 꽤 높아야 합니다. 사용자가 사용할 수 있는 대역폭, 서버 로드, 데이터베이스와 같은 관련 구성 요소의 성능을 포함하여 웹 서버 성능의 모든 측면을 확인하세요. 리소스 부족으로 인한 성능 문제를 해결합니다.
웹 포트에 연결된 IP 주소 분포를 분석합니다. 하나의 IP가 수백 개의 연결을 모두 수행하는 것은 드문 일이지만 IPv4 NAT는 이를 복잡하게 만듭니다. 소스 주소의 ISP를 결정합니다. IP 주소의 보안 평판 점수를 확인하고 엄청난 NAT일 수 있는지 확인하세요.
모니터링을 수행하는 동시에 들어오는 요청에 대해 패킷 캡처를 수행합니다. 정상적으로 작동하는 클라이언트로부터 최소한 일부 HTTP 요청이 표시되어야 합니다. 클라이언트가 연결하고 거기에 앉아 있으면 SlowLoris 스타일의 리소스 소진과 비슷해 보입니다.
연결된 답변의 튜닝 권장 사항을 고려하십시오. Linux에서는 sysctl 등을 사용하여 시간 초과를 약간 줄이는 net.ipv4.tcp_fin_timeout = 10것이 좋습니다.
이 웹 서버를 보안 지향 및 로드 밸런싱 프록시 뒤에 두는 것을 고려해보세요. 웹 애플리케이션 방화벽 기능을 사용하면 요청을 필터링하는 영리한 작업을 수행할 수 있습니다. 수평으로 확장하면 더 많은 요청을 처리할 수 있습니다.
답변2
시스템이 DoS 공격을 받고 있는지 확인할 수 있는 방법이 있습니까?
DoS서비스 거부입니다.
공격해를 끼치기 위해 수행되는 적대적인 행동이다.
(수동적 공격성그것을 이해하지 못하는 사람들이 사용하는 모순어법이다수동적인조치가 없음을 의미합니다. 즉, 정의에 따라 아무런 조치도 취하지 않음을 의미합니다.침략(정의에 따르면) 적대적인 행동을 의미합니다. 그러나 그것은 물론 또 다른 이야기입니다.)
둘 사이에는 DoS라는 간격이 있지만 적대적인 행동 측면에서는 공격이 아닙니다. 예를 들어, 사용자 키보드에 F5가 붙어 있으면 대응 조치를 취하지 않으면 DoS가 발생할 수 있지만 해를 끼칠 의도로 수행되는 적대적인 행동으로서의 공격은 아닙니다. OTOH, 사용자가 이것이 DoS를 유발할 것이라는 것을 알고 의도적으로 해당 키를 누르고 있으면 공격입니다.
따라서 귀하의 질문에 대답하는 것은 의도가 있음을 증명할 수 없다면 확실하게 말하기는 불가능합니다. 리소스 부족, 즉 과부하로 인해 서비스 중단이 발생한 경우 DoS인지 알 수 있습니다.