대규모 사이트 * * 방어 보고서

[51CTO 전문 원고] 필자 가 있 는 사 이 트 는 어느 날 밤 에 넓 은 범위 의 * * * 가 나 타 났 습 니 다. 사후 통계 에 따 르 면 이번 에는 * * 측 이 약 50 만 위안 을 사용 하여 지속 * * 사 이 트 를 사 용 했 습 니 다. 사이트 응용 서버 의 부하 가 매우 높 아서 어쩐지 느 리 더 라 고요.다음은 문 제 를 분석 하고 해결 하기 시작한다.
1. * * 설명
연초 부터 사이트 응용 서버 의 네트워크 카드 트 래 픽 은 보편적으로 100 M 이상으로 증 가 했 는데 그 중에서 몇 대의 서버 네트워크 카드 트 래 픽 은 204 Mbps 에 달 했다.이에 따라 접근 속도 가 점점 느 려 지고 네트워크 대역 폭 이 수 차례 소 진 되 는 것 이다.
2. * * 분석
1. 네트워크 카드 가 100 M 이상 유출 된 이상 비정상적인 요청 주소 가 있어 야 서버 가 응답 하고 클 라 이언 트 에 보 낼 수 있 습 니 다.요청 한 주소 에 이상 이 있 는 것 으로 판단 된다.
응용 서버 가 * * * 를 받 았 을 때의 네트워크 카드 트 래 픽 맵
사이트 응용 서버 가 * * 를 받 았 을 때의 부하 현상
2. 웹 로 그 를 분석 하면 많은 IP 가 동시에 1 초 에 여러 주소 로 GET 요청 을 보 내 고 돌아 오 는 주소 의 데 이 터 는 200 k - 300 k 사이 에 있 음 을 발견 할 수 있 습 니 다.php 주 소 를 되 돌려 주면 어떻게 200 여 k 의 데이터 가 있 을 수 있 는 지 생각해 보 세 요. 그러면 악의 적 인 요청 일 겁 니 다.아래 url 중의 232347 을 보면 이 232347 은 클 라 이언 트 에 게 돌아 가 는 데이터 입 니 다.

123.232.102.228 - - [07/Mar/2012:14:24:23 +0800] "GET /forum-116-20.html HTTP/1.0" "200" 232347 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)" "-"
123.232.102.228 - - [07/Mar/2012:14:24:23 +0800] "GET /forum-1402-1.html HTTP/1.0" "200" 253872 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)" "-"
123.232.102.228 - - [07/Mar/2012:14:24:23 +0800] "GET /forum-63-1.html HTTP/1.0" "200" 118163 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)" "-"
123.232.102.228 - - [07/Mar/2012:14:24:23 +0800] "GET /forum-1342-1.html HTTP/1.0" "200" 235327 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)" "-"
123.232.102.228 - - [07/Mar/2012:14:24:23 +0800] "GET /forum.php?mod=forumdisplay&fid=58 HTTP/1.0" "200" 283377 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)" "-"

3. * * * 는 주로 phop 응용 을 대상 으로 phop 병발 은 nginx 와 여러 개의 수량 급 이 다르다.이번 * * *, 평균 한 대의 phop 은 초당 최대 200 개의 병발 을 견 뎌 내 고 대부분 목록 페이지 를 대상 으로 데이터 베이스 에 직접적인 영향 을 줍 니 다.
4. 해결 방안
1. 방화벽 에 IP 차단 (추천 하지 않 음)
IP 를 차단 하 는 방식 으로 * * * 소스 IP 를 막 는 방법 입 니 다. 처음에 저 는 이런 방법 을 사 용 했 지만 이렇게 IP 를 차단 하려 면 로그 에서 검색 해 야 합 니 다.비교적 번 거 롭 고 효과 가 뚜렷 하지 않다.
2 、 Nginx 패 시 브 방어 (추천)
로그 에 같은 user - agent 가 없 었 던 것 을 기억 합 니 다. nginx 는 이번에 user - agent 를 이용 하여 방어 하 였 습 니 다 * * *.
nginx 설정 문서 에 추가 되 었 습 니 다.

if ( $http_user_agent ~* "Mozilla/4.0\ \(compatible;\ MSIE\ 6.0;\ Windows\ NT\ 5.0\;\ .NET\ CLR\ 1.1.4322\)" )
 {
     return 444;
 }

nginx 를 다시 시작 하면 nginx 는 로그 에서 이러한 user - agent 를 감지 하면 444 http 상태 코드 를 되 돌려 줍 니 다. 요청 이 실 패 했 습 니 다.이렇게 설정 하면 각 응용 서버 의 부하 가 정상 으로 회복 되 고 네트워크 카드 의 트 래 픽 이 정상 입 니 다.

218.5.73.245 - - [07/Mar/2012:10:53:12 +0800] "GET /forum-222-1.html HTTP/1.0" 444 0 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)"
218.5.73.245 - - [07/Mar/2012:10:53:12 +0800] "GET /forum-222-1.html HTTP/1.0" 444 0 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)"
218.5.73.245 - - [07/Mar/2012:10:53:12 +0800] "GET /forum-222-1.html HTTP/1.0" 444 0 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)"

Nginx 처리 * * ip 결과
총화
1. 이번 nginx 는 소형 ddos 나 cc 를 방지 하 는 데 자신 만 의 특색 이 있 습 니 다. 처리 요구 가 효율 적 이 고 자원 소모 가 매우 낮 습 니 다.
단점: 로 그 를 분석 하고 규칙 을 찾 아야 한다. 예 를 들 어 user - agent 등 이다.
2. 의문?
Q: 어떤 학생 들 은 이런 user - agent 를 차단 하면 오 살 률 이 얼마나 됩 니까?
A: cc * * 자 * * * 시, 자신 만 의 특별한 user - agent 가 있 습 니 다. 이러한 user - agent 를 차단 하면 추가 적 인 오 살 이 발생 하지 않 습 니 다.차단 로 그 를 관찰 해 얻 은 결론 이다. 서버 가 이런 전략 을 사용 한 후 한 네티즌 이 이 일 로 찾 아 본 적 이 있다.
Q: cc * * 소프트웨어 가 정상 적 인 user - agent 로 위장 하면 이런 오 살 은 얼마나 됩 니까?
A: 1): 모든 * * * 자 는 user - agent 를 수정 할 수 있 는 것 이 아 닙 니 다. 상당 부분의 * * 자 는 모두 구 매 한 * * 소프트웨어 를 사용 합 니 다. 수정 하려 면 돈의 대 가 를 치 러 야 합 니 다.이것 은 * * 자가 원 하 는 결과 가 아니다.2): 정상 적 인 user - agent 로 위장 하 더 라 도 자신의 특징 이 있 을 수 있 습 니 다. 그 공 통 된 특징 으로 분석 할 수 있 습 니 다. 예 를 들 어 소스 주소 가 같 는 지 등 공통점 으로 전략 을 설정 할 수 있 습 니 다.정책 을 만 들 때 nginx 차단 로그 에서 다른 정상 적 인 요청 도 차단 되 었 는 지 주의해 야 합 니 다.

124.133.235.202 - - [08/Mar/2012:10:33:37 +0800] "GET / HTTP/1.1" 302 163 "/zhuanti/nzpp/zonghegr.jsp?group=2" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727)" -
124.133.235.202 - - [08/Mar/2012:10:33:37 +0800] "GET / HTTP/1.1" 302 163 "/zhuanti/nzpp/zonghegr.jsp?group=2" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727)" -
124.133.235.202 - - [08/Mar/2012:10:33:37 +0800] "GET / HTTP/1.1" 302 163 "/zhuanti/nzpp/zonghegr.jsp?group=2" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727)" -
124.133.235.202 - - [08/Mar/2012:10:33:37 +0800] "GET / HTTP/1.1" 302 163 "/zhuanti/nzpp/zonghegr.jsp?group=2" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727)" -
124.133.235.202 - - [08/Mar/2012:10:33:37 +0800] "GET / HTTP/1.1" 302 163 "/zhuanti/nzpp/zonghegr.jsp?group=2" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727)" -
124.133.235.202 - - [08/Mar/2012:10:33:37 +0800] "GET / HTTP/1.1" 302 163 "/zhuanti/nzpp/zonghegr.jsp?group=2" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727)" -
124.133.235.202 - - [08/Mar/2012:10:33:37 +0800] "GET / HTTP/1.1" 302 163 "/zhuanti/nzpp/zonghegr.jsp?group=2" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727)" -
124.133.235.202 - - [08/Mar/2012:10:33:37 +0800] "GET / HTTP/1.1" 302 163 "/zhuanti/nzpp/zonghegr.jsp?group=2" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727)" -

예 를 들 어 위의 로그, 이번 * * 자 는 user - agent 를 정상 으로 위장 하고 user - agent 를 키워드 로 하면 일부 오 살 될 수 있 습 니 다.그래서 이런 * * * 에 대해 소스 주 소 를 키워드 로 할 수 있 고 nginx 보호 전략 은 이렇게 할 수 있 습 니 다.

if （$http__referer ~ * "/zhuanti/nzpp/zonghegr.jsp?group=2"）
{
  return 444;
}

이렇게 하면 오 살 이 없 을 것 이다.
3. 경험 교훈
교훈: 작년 의 CC * * *, 이번 * * 와 다른 점 이 있 습 니 다. 모두 phop 을 쳤 습 니 다.그때 우 리 는 블랙홀 방 호 벽 을 사용 한 후에 효과 가 뚜렷 하지 않 았 다.
경험: 그날 밤, 나 는 웹 로 그 를 자세히 분석 한 결과, user - agent 는 모두 같은 것 을 발견 했다. 예 를 들 어 windows 5.0 은 정상 적 인 windows NT 5.0 과 본질 적 인 차이 가 있다. 그러면 이 위 에서 글 을 쓸 수 있 을 까?이 문 제 를 가지 고 인터넷 에서 nginx 방 cc 방면 의 자 료 를 검색 한 결과 인터넷 의 고수 들 의 생각 이 저 와 같다 는 것 을 알 게 되 었 습 니 다. 모두 같은 점 user - agent 에 착안 하여 nginx 로 이러한 user - agent 와 일치 한 다음 에 503 http 상태 코드 를 되 돌려 주 었 습 니 다. 물론 여기 서 제 가 수정 을 해서 444 상태 코드 를 되 돌려 주 었 습 니 다.그래서 지난번 의 교훈 을 받 아들 인 후에 올해 사이트 에서 * * * 를 당 했 을 때 저 는 과감하게 이 전략 을 사 용 했 는데 그 결과 효과 가 매우 뚜렷 하 다 는 것 을 증명 하 였 습 니 다.cc * * * 는 계속 되 고 있 지만 사이트 방문 은 여전히 원활 합 니 다.