nginx 제한 흐름 방지 솔 방안

머리말
    인터넷 의 발전 은 이미 재고 기간 에 접어 들 었 다. 처음에 저렴 한 고객 유치 비용 은 더 이상 존재 하지 않 았 다. 인터넷 회 사 는 매력 적 이 고 높 은 보조금 을 지불 함으로써 새로운 방식 으로 대량의 흑 산, 회 산 을 탄생 시 켰 다. 그리고 점점 더 많은 회사 들 이 데이터 유출 을 폭로 했다.암 인터넷 사용자 의 비밀번호 와 프라이버시 정 보 는 이미 포장 하여 가격 을 표시 하여 판매 되 었 습 니 다. 몇 년 전에 우리 회 사 는 라 이브 러 리 에 부 딪 히 는 공격 을 받 았 고 일부 사용자 의 로그 인 증명서 와 비밀 번 호 를 도 둑 맞 았 습 니 다. 해커 가 다른 경 로 를 통 해 얻 은 핸드폰 번호 와 비밀번호 사전 으로 우리 의 로그 인 인 인 터 페 이 스 를 요청 한 것 을 기억 합 니 다. 마지막 으로 발생 한 손실 은 유한 하지만 많은 서비스 구조 와 업무 안전성 에 문제 가 드 러 났 습 니 다.
* 8195: 우선, 서명 알고리즘 노출 과 약 한 암호 문제 입 니 다. 서명 알고리즘 은 현재 컴 파일 해제 가 이렇게 성숙 한 상황 에 노출 되 어 방지 하기 어렵 습 니 다. 현재 생각 나 는 방안 은 서명 을 제어 하 는 salt 배포 입 니 다. 약 한 비밀 번 호 는 업무 층 에서 개조 해 야 하고 원가 가 비교적 높 습 니 다. 또는 계 정 비밀번호 로 로그 인하 여 제3자 권한 수여 로 전환 해 야 합 니 다.
그 다음 에 이번 공격 은 매우 일찍 발생 했 지만 몇 시간 후에 야 인터페이스 트 래 픽 감 측 을 통 해 요 구 량 이상 을 발견 했다. 발견 할 때 이미 대량의 사용자 비밀 번 호 를 받 아 뒤의 수 동적 인 국면 을 초래 했다. 어떻게 해 야 이런 이상 한 요 구 를 발견 할 수 있 습 니까?
마지막 으로 로 그 를 분석 함으로써 해커 가 요청 한 ip 수량 은 모두 제 한 된 ip 에 집중 되 고 규칙 을 통 해 이러한 불법 요 구 를 거절 할 수 있 습 니 다.
    상술 한 두 가지 문 제 는 모두 오늘 토론 하고 자 하 는 방안 을 통 해 해결 할 수 있다.
누가 늑대인 간이 야?
    서버 는 매일 수 억 번 의 요청 을 받 고 있 습 니 다. 어떤 요청 이 무고 한 평민 인지, 어떤 요청 이 당신 의 목숨 을 요구 하 는 늑대인 간 인지 어떻게 판별 합 니까?
* 8195 ° 8195 ° 분석 요청 log 를 통 해 불법 요청 에 몇 가지 특징 이 있 음 을 발견 할 수 있 습 니 다.

1.         :         ,             .                .
2.         :            ,            .
3. ip   :               DDOS,  ip            ,  ip         

* 8195: 8195: 따라서 {uri} + {ip} 을 key 로 하여 특정한 시간 위도 에서 요 구 량 을 통계 하여 불법 요 구 를 감별 하 는 방법 으로 사례 의 공격 을 효과적으로 막 을 수 있 습 니 다.
누가 사냥꾼 이 야?
그럼 문제 가 생 겼 습 니 다. 누가 사냥꾼 이 되 어 늑대인 간 의 공격 을 막 습 니까?
    서비스 구조 상 몇 군데, lb, nginx, server. 개인 적 으로 어느 층 에 두 느 냐 에 따라 차이 가 크 지 않다 고 생각 합 니 다. 불법 요청 을 빨리 버 리 는 원칙 과 개 조 를 고려 하 는 어려움 에 따라 저 는 nginx 층 을 선 택 했 습 니 다.
nginx 마법
    은 nginx 의 요리 닭 선수 로 서 nginx 버 전이 비교적 낮 기 때문에 그 당시 설정 규칙 에 많은 문제 가 발생 했 습 니 다. 다행히 마지막 으로 실행 가능 한 방식 을 찾 았 습 니 다. 주로 nginx 의 geo, map, limit 을 사 용 했 습 니 다.req
규칙 설정

        ##IP   
        geo $whiteiplist {
            default 1;
            127.0.0.1 0;
            10.0.0.0/8 0;
  
        }
        map $whiteiplist $limit {
            1 $limit_key;
            0 "";
        }
                ##      
       	map $uri $limit2{
                        default $limit;
                        /api/sample "";

                }
        limit_req_status 406;

                ###     
        limit_req_zone $limit2 zone=freq_controll:100m rate=10r/s;
        limit_req_zone $limit2 zone=freq_controll_2:100m rate=500r/m;

    이 규칙 은 비교적 번 거 롭 게 쓰 였 는데 주로 nginx 버 전이 비교적 낮은 limit 에 제한 을 받 았 다.req_zone 은 두 개의 변 수 를 지원 하지 않 으 며 인터페이스 화이트 리스트 와 ip 화이트 리스트 를 지원 합 니 다.

    location / {
	limit_req zone=freq_controll burst=5 nodelay;
	limit_req zone=freq_controll_2 burst=10 nodelay;
	error_page 406 =406  @f406;
	location @f406 {
		access_log syslog:server=127.0.0.1:12301;
		return 406;
		}
	}

『 8195 』 limitreq 에서 두 개의 이상 한 매개 변수 burst, nodelay 가 시작 되 었 을 때 나 도 의 심 스 러 웠 고 뒤의 논리 와 알고리즘 을 알 고 나 서 야 그 중의 오 의 를 이해 했다.
유량 제어
    유량 제어 알고리즘 에서 흔히 볼 수 있 는 깔때기 알고리즘 은 두 가지 사고방식 이 있다. 1: 물의 양 이 통 의 상한 선 에 도 달 했 을 때 먼저 수신 을 잠시 멈 추고 통 의 물이 일부 새 면 계속 수신 한다. 2. 통 을 초과 한 유량 은 직접 버린다. 전체적으로 보면 두 가지 사고방식 은 기다 림 과 버 림 이다.
    이 limitreq 모듈 의 알고리즘 은 깔때기 알고리즘 과 약간 다 르 고 토 큰 통 알고리즘 에 속 합 니 다. 이들 의 가장 큰 차이 점 은 깔때기 알고리즘 은 유량 의 크기 만 강제 적 으로 제한 할 수 있 고 갑 작 스 러 운 부하 에 대응 할 방법 이 없습니다. 토 큰 통 은 바로 이 부족 을 보완 합 니 다.
영 패 통 의 핵심 은 몇 가지 가 있 습 니 다.

1.             ,            . 

2.    n   ,   n   .          . 

* 8195 ° 8195 ° 이때 burst 매개 변 수 는 역할 을 발휘 합 니 다. 1 초 안에 120 개의 요청 이 서버 에 동시에 전송 된다 고 가정 합 니 다. 전통 적 인 깔때기 알고리즘 에 따라더 나 온 이 20 개의 요청 은 직접 거부 되 거나 대기 열 에 놓 여 있 습 니 다. 토 큰 통 알고리즘 에 서 는 또 다른 모습 입 니 다. 토 큰 통 에는 실제로 100 개의 토 큰 이 있 습 니 다. 하지만 10 개의 요청 을 동시에 할 수 있 습 니 다. 10 개의 요청 이 더 나 오 면 거부 당 합 니 다.
    nodelay 를 설정 하지 않 은 상태 에서 이 10 개의 요청 은 대기 열 에 놓 입 니 다. 0.001 초의 속도 로 꺼 내 면 총 0.1 초가 소 모 됩 니 다. 110 개의 요청 을 처리 하 는 데 1. 1 초가 걸 렸 습 니 다. 실제로 이 기다 림 은 필요 없습니다.
    에 nodelay 가 설정 되 어 있 습 니 다. 이 10 개의 요청 은 정상적으로 처 리 됩 니 다. 다만 burst 의 수량 은 비 워 집 니 다. 토 큰 이 다시 보충 되 기 를 기 다 려 야 요청 을 다시 받 을 수 있 습 니 다. 110 개의 요청 을 처리 하 는 데 1 초 가 걸 렸 습 니 다. 그러나 위의 상황 과 마찬가지 로 토 큰 이 보충 되 어야 요청 을 받 을 수 있 습 니 다.