Nginx 는 CC 공격 을 간단하게 방어 하 는 두 가지 방법
Nginx 는 러시아의 프로그래머 Igor Sysoev 가 개발 한 경량급 웹 서버 로 최초 로 러시아의 대형 입구 사이트 와 검색 인 Rambler 에 사용 되 었 다.메모리 가 적 고 병발 능력 이 강 한 것 이 특징 이다. 사실상 Nginx 의 병발 능력 은 같은 유형의 사이트 서버 에서 비교적 잘 나타난다.
Nginx 는 Apache 보다 더 큰 연결 수 를 처리 할 수 있 지만 HTTP GET FLOOD 는 WEB 서버 뿐만 아니 라 데이터베이스 서버 도 대상 으로 한다.대량의 HTTP 요청 으로 대량의 데이터 베 이 스 를 조회 할 수 있 습 니 다. 몇 초 안에 데이터 베 이 스 를 응답 하지 않 고 시스템 부하 가 높 아 지면 서 서버 가 다운 되 었 습 니 다.
본 고 는 주로 CentOS + Nginx 에서 CC 공격 을 신속 하고 효과적으로 방어 하 는 방법 을 소개 한다.Nginx 를 어떻게 설치 하 는 지 에 대해 서 는 상세 하 게 소개 하지 않 습 니 다. 관심 있 는 독 자 는 Nginx 공식 사이트 에서 (http://www.nginx.org/) 원본 코드 를 다운로드 하여 컴 파일 한다.Centos 5 를 사용한다 면 rpm 패키지 로 설치 할 수도 있 습 니 다 (http://centos.alt.ru/repository/centos/5/i386/nginx-stable-0.7.65-1.el5.i386.rpm)。
1. 능 동적 억제 방법
Nginx 가 더 많은 병렬 연결 수 를 지원 하도록 실제 상황 에 따라 작업 스 레 드 수 와 모든 작업 스 레 드 가 지원 하 는 최대 연결 수 를 조정 합 니 다.예 를 들 어 'worker processes 10' 과 'worker connections 1024' 를 설정 하면 이 서버 가 지원 하 는 최대 연결 수 는 10 입 니 다.×1024=10240。
worker_processes 10;
events {
use epoll;
worker_connections 10240;
}
Nginx 0.7 은 사용자 연결 을 제한 하 는 모듈 2 개 를 제공 하기 시 작 했 습 니 다. NginxHttp LimitZone Module 과 NginxHttp LimitReqModule 입 니 다.NginxHttpLimitZoneModule 은 조건 에 따라 병렬 연결 수 를 제어 할 수 있다.
예 를 들 어 다음 코드 를 정의 할 수 있 습 니 다.
http {
limit_zone my_zone $binary_remote_addr 10m;
server {
location /somedir/ {
limit_conn my_zone 1;
}
}
}
그 중에서 'limit zone my zone $binary remote addr 10m' 는 이름 을 my 로 정의 한 다 는 뜻 입 니 다.zone 의 저장 영역, myzone 의 내용 은 원 격 IP 주소, myzone 의 크기 는 10m 입 니 다."location / somedir /" 는 somedir 디 렉 터 리 에 대한 응용 규칙 을 의미 합 니 다."limit conn my zone 1" 은 위 에서 정의 한 my 를 뜻 합 니 다.zone 기록 구역 에 기 록 된 IP 주 소 는 지정 한 디 렉 터 리 에 하나의 연결 만 만 만 들 수 있 습 니 다.
NginxHttpLimitReqModule 은 조건 에 따라 요청 주파 수 를 제어 할 수 있 습 니 다.예 를 들 어 다음 코드 를 정의 할 수 있 습 니 다.
http {
limit_req_zone $binary_remote_addr zone=my_req_zone:10m rate=1r/s;
...
server {
...
location /somedir/ {
limit_req_zone zone= my_req_zone burst=2;
}
그 중에서 'limit req zone $binary remote addr zone = my req zone: 10 m rate = 1r / s' 는 이름 을 my 로 정의 한 다 는 뜻 이다.req_zone 의 저장 영역, myreq_zone 내용 은 원 격 IP 주소, myreq_zone 크기 는 10M, myreq_zone 의 평균 요청 속 도 는 1 초 에 불과 합 니 다."location / somedir /" 는 somedir 디 렉 터 리 에 대한 응용 규칙 을 의미 합 니 다."limit req zone zone = my req zone burst = 2" 는 위 에 정 의 된 myreq_zone 기록 구역 에 기 록 된 IP 주 소 는 지정 한 디 렉 터 리 의 내용 을 요청 할 때 초당 최대 2 개의 돌발 요청 속도 입 니 다.
연결 이 항소 규칙 을 촉발 하면 Nginx 는 '503 Service Temporarily Unavailable' 오 류 를 보고 하고 사용자 요청 을 중단 합 니 다.503 을 되 돌려 주 는 것 은 서버 에 큰 영향 을 미 치지 않 고 nginx 의 스 레 드 만 차지 할 뿐 상대 적 으로 수지 가 맞는다.
효 과 를 시험 하기 위해 서, 나 는 위의 코드 를 Nginx 프로필 에 넣 고, phpinfo 를 표시 하 는 PHP 파일 을 만 들 었 습 니 다.또한 html 파일 을 하나 썼 는데 그 중 에 여러 개의 iframe 호출 php 파일 이 삽입 되 어 있다.이 html 파일 을 열 었 을 때 하나의 iframe 에 있 는 phop 파일 만 정상적으로 표시 되 고 다른 iframe 은 모두 503 오 류 를 표시 하 는 것 을 볼 수 있 습 니 다.
예 를 들 어 (Discuz!)
Discuz!phop 포럼 프로그램 을 많이 사용 합 니 다.Discuz 로!7.0 예 를 들 어 프로그램 디 렉 터 리 에 직접 접근 할 수 있 는 phop 파일 이 많 지만 그 중에서 가장 공격 을 받 기 쉬 운 것 은 보통 index. php (첫 페이지), forumdisplay. phop (판 넬 표시), viewthread. phop (게시 물 표시) 이다.공격 자 는 일반적으로 이 페이지 에 대량의 요청 을 해서 HTTP 서버 연결 수가 다 소모 되 고 mysql 데이터베이스 가 응답 을 멈 추 며 최종 적 으로 서버 가 붕 괴 됩 니 다.위 페이지 가 공격 당 하 는 것 을 방지 하기 위해 아래 의 규칙 을 설정 하여 방어 할 수 있 습 니 다.
http {
limit_zone myzone_bbs $binary_remote_addr 10m;
limit_req_zone $binary_remote_addr zone=bbs:10m rate=1r/s;
...
server {
...
location ~ ^/bbs/(index|forumdisplay|viewthread).php$ {
limit_conn myzone_bbs 3;
limit_req zone=bbs burst=2 nodelay;
root html;
fastcgi_pass unix:/dev/shm/php-cgi.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /usr/share/nginx/html$fastcgi_script_name;
include fastcgi_params;
}
}
}
이 규칙 을 적용 하면 bbs 디 렉 터 리 에 있 는 index. php, forumdisplay. php 와 viewthread. php 이 페이지 들 은 같은 IP 로 3 개의 연결 만 가능 하 며 1 초 에 1 개의 요청 만 있 을 수 있 습 니 다 (돌발 요청 은 2 개 에 달 할 수 있 습 니 다).이러한 규칙 은 일반적으로 정상 적 인 사용자 에 게 영향 을 주지 않 지만 (1 초 안에 3 개의 페이지 를 여 는 사람 은 극히 적다) 빠 른 사용자 접근 에 영향 을 주지 않도록 nginx 에서 503 페이지 를 사용자 정의 하고 503 페이지 에서 사용자 에 게 알림 을 한 다음 에 자동 으로 새로 고침 할 수 있다.Nginx 에서 사용자 정의 503 페이지:
error_page 503 /errpage/503.html;
503 페이지 의 소스 코드:
<html>
< head>
< title> ....</title>
< meta http-equiv=content-type c>
< META NAME="ROBOTS" C>
< /head>
< body bgcolor="#FFFFFF">
< table cellpadding="0" cellspacing="0" border="0" width="700" align="center" height="85%">
<tr align="center" valign="middle">
<td>
<table cellpadding="10" cellspacing="0" border="0" width="80%" align="center" style="font-family: Verdana, Tahoma; color: #666666; font-size: 11px">
<tr>
<td valign="middle" align="center" bgcolor="#EBEBEB">
<br /><b style="font-size: 16px"> </b>
<br /><br /> 。 , ...
<br /><br />[<a href="javascript:window.location.reload();"><font color=#666666> </font></a>]
<br /><br />
</td>
</tr>
</table>
</td>
</tr>
< /table>
< /body>
< /html>
< SCRIPT language=javascript>
function update()
{
window.location.reload();
}
setTimeout("update()",2000);
< /script>
2. 수 동적 방어 방법
주동 방 어 는 대부분의 HTTP GET FLOOD 공격 을 막 아 냈 지만, 도가 한 자 높 으 면 마 가 한 장 높 아 공격 자 는 약 한 부분 을 찾 아 공격 할 것 이다.그래서 우 리 는 여기 서도 수 동적 인 방어 방법 을 소개 해 야 한다.
IP 주소
방문 자 는 브 라 우 저 를 통 해 정상적으로 웹 사 이 트 를 방문 합 니 다. 서버 와 의 연결 은 보통 20 개 를 넘 지 않 습 니 다. 저 희 는 스 크 립 트 를 통 해 연결 수가 너무 많은 IP 접근 을 금지 할 수 있 습 니 다.다음 스 크 립 트 는 netstat 명령 을 통 해 모든 연결 을 열거 합 니 다. 연결 수가 가장 높 은 IP 를 연결 수가 150 을 넘 으 면 iptables 를 통 해 접근 을 막 습 니 다.
#!/bin/sh
status=`netstat -na|awk '$5 ~ /[0-9]+:[0-9]+/ {print $5}' |awk -F ":" -- '{print $1}' |sort -n|uniq -c |sort -n|tail -n 1`
NUM=`echo $status|awk '{print $1}'`
IP=`echo $status|awk '{print $2}'`
result=`echo "$NUM > 150" | bc`
if [ $result = 1 ]
then
echo IP:$IP is over $NUM, BAN IT!
/sbin/iptables -I INPUT -s $IP -j DROP
fi
crontab - e 를 실행 하고 위 스 크 립 트 를 crontab 에 추가 하면 분당 자동 으로 실 행 됩 니 다.
* * * * * /root/xxxx.sh
apache 자체 ab 도 구 를 통 해 서버 압력 테스트 를 진행 합 니 다:
# ab -n 1000 -c 100 http://www.xxx.com/bbs/index.php
테스트 가 끝 난 후에 우 리 는 시스템 에 IP 가 봉 인 된 알림 을 볼 수 있 습 니 다.
#tail /var/spool/mail/root Content-Type: text/plain; charset=ANSI_X3.4-1968 Auto-Submitted: auto-generated X-Cron-Env:
IP:58.246.xx.xx is over 1047, BAN IT!
이로써 또 한 번 HTTP GET FLOOD 방어 에 성공 했다.
특징 코드 차단 요청 (CC 공격 에 좋 음)
일반적으로 같은 CC 공격 도구 가 발동 하 는 공격 요청 패 키 지 는 항상 같 고 정상 요청 과 차이 가 있 습 니 다.서버 가 CC 공격 을 받 았 을 때 로 그 를 빠르게 보고 사용자 에이전트 와 같은 요청 의 특징 을 분석 할 수 있 습 니 다.다음은 한 번 의 CC 공격 시 User - agent, Mozilla / 4.0 (compatible, MSIE 5.01, Windows NT 5.0, MyIE 3.01) Cache - Control: no - store, must - revalidate 는 정상 적 인 브 라 우 저 없 이 User - agent 에 'must - revalidate' 라 는 키 워드 를 가 져 옵 니 다.따라서 이 를 특징 으로 필터 링 을 할 수 있 습 니 다. User - agent 에 'must - revalidate' 가 있 는 요청 을 모두 거부 할 수 있 습 니 다.
if ($http_user_agent ~ must-revalidate) {
return 403;
}
본 고 는 nginx 의 HTTP GET FLOOD 방 어 를 소개 하 였 으 며, 잘못된 부분 이 있 으 면 저 에 게 말씀 해 주 십시오.또한, 이러한 사 고 를 apache, lighttpd 등 흔히 볼 수 있 는 웹 서버 에 활용 할 수 있 기 를 바 랍 니 다.
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
다양한 언어의 JSONJSON은 Javascript 표기법을 사용하여 데이터 구조를 레이아웃하는 데이터 형식입니다. 그러나 Javascript가 코드에서 이러한 구조를 나타낼 수 있는 유일한 언어는 아닙니다. 저는 일반적으로 '객체'{}...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.