왜 액세스 로그에 갑자기 400 건의 요청이 많습니까?


10

아래는 내 access_log의 일부입니다.

118.186.8.50 - - [19/Dec/2011:22:42:57 +0800] "-" 400 0 "-" "-"
05
118.186.8.50 - - [19/Dec/2011:22:42:57 +0800] "-" 400 0 "-" "-"
06
118.186.8.50 - - [19/Dec/2011:22:42:57 +0800] "-" 400 0 "-" "-"
07
118.186.8.50 - - [19/Dec/2011:22:42:57 +0800] "-" 400 0 "-" "-"
08
118.186.8.50 - - [19/Dec/2011:22:42:57 +0800] "-" 400 0 "-" "-"
09
220.173.136.39 - - [19/Dec/2011:22:43:22 +0800] "-" 400 0 "-" "-"
10
220.173.136.39 - - [19/Dec/2011:22:43:22 +0800] "-" 400 0 "-" "-"
11
220.173.136.39 - - [19/Dec/2011:22:43:22 +0800] "-" 400 0 "-" "-"
12
220.173.136.39 - - [19/Dec/2011:22:43:22 +0800] "-" 400 0 "-" "-"
13
220.173.136.39 - - [19/Dec/2011:22:43:22 +0800] "-" 400 0 "-" "-"
14
220.173.136.39 - - [19/Dec/2011:22:43:22 +0800] "-" 400 0 "-" "-"

그리고이 용량은 초당 400 건 중 10 만 건에 달합니다. 그리고 그 기간 동안 내 사이트에 오류가 없다고 확신합니다 (오류 보고서가 없으며 소스 코드를 변경하지 않았습니다)

답변:


5

누군가 서버를 퍼징하고 있었습니다 . Wikipedia 도 참조하십시오 .

기본적으로 잘못된 데이터의 빠른 블록을 전송하여 문제가 있는지 확인합니다.

Nginx는 요청 데이터가 전송되지 않을 때 400 오류 오류를 반환하도록 설정되어 있습니다.

걱정하지 마십시오. Nginx는 땀을 흘리지 않고 영원히 튀는 것을 계속 할 수 있습니다.


그가 걱정해야 할 것은 디스크 공간을 흡수하는 로그 파일입니다. 적절한 로그 순환이 도움이됩니다.
Justin Pearce

여기에도 같은 문제가 있습니다. 다른 IP 주소의 양이 공격 (퍼지)을 내 생각에 크게 가능하게하지는 않습니다. 더 나은 설명을 찾고 있습니다.
올리버

2

400을 발생시키는 IP 주소가 Chrome을 사용 중인지 확인하십시오. Chrome은 사전 연결을 사용하여 서버와 여러 연결을 설정하고 사용하지 않을 경우 닫습니다.

연결에 요청이 없으므로 nginx는이 오류를 기록합니다.


여기에서 동일한 문제가 발생하고 정확히 동일한 로그 파일 형식을 사용하므로 OP가 기본값을 변경하지 않았다고 가정합니다. 이는 사용자 에이전트 문자열이 기록되고 있음을 의미합니다. 값이 포함되지 않습니다. 따라서 해당 클라이언트가 Chrome을 사용하고 있는지 확인하는 방법을 잘 모르겠습니다. 지금 Chrome 26을 사용하여 로그 에서이 오류를 재현 할 수 없었습니다. 다른 힌트가 있습니까?
올리버

사용자 에이전트는 요청이 이루어질 때까지 요청 헤더로 전송됩니다. nginx는 사용자 에이전트 문자열을 알고 기록 할 수단이 없습니다. 그러나 해당 IP 주소에서 가져온 다른 로그 레코드를 확인하고 실제로 해당 클라이언트가 실제로 요청한 경우 Chrome인지 여부를 알 수 있습니다.
Ivan Anishchuk
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.