CDN 자체 구축,DDOS방어,아키텍처 설계

1.CDN 아키텍처

CDN 아키텍처는 공격 방지 기능과 유연성의 원칙을 완전히 반영해야합니다. 따라서 CDN 노드를 리버스 프록시 + 캐시 가속 + 공격 방어의 세 가지 기능 구조 수준으로 분해합니다.

• 리버스 프록시 기능 (기능 : 라우트 가속, 숨겨진 마스터 노드,로드 밸런싱)
• 캐시 가속 기능 (기능 : 정적 푸시, 백엔드 마스터 노드의 대역폭 절약)
• 공격 방어 기능 (기능 : 빠른 분석, 악성 공격 일치 및 필터링)

오픈 소스 세계에는 리버스 프록시 및 캐시 역할을 할 수있는 많은 소프트웨어가 있으며 각각 고유의 장단점이 있습니다. 설계자로서 모델을 선택하는 방법을 고려해야하며 성능, 기능 및 구성의 관점에서 비교하고 선택합니다.

2.비교분석

3.평가

우리는 3 층 기능 구조의 테스트 및 최적화와 생산 라인의 실제 검사를 수행했으며 다음과 같은 측면에서 평가했습니다.

• HTTP 방어 성능 : HAProxy는 대량의 CC 공격을 처리 할 때 정기적 인 일치 및 헤더 필터링을 수행 할 때 CPU 소비의 10 % ~ 20 % 만 소비합니다. 다른 소프트웨어는 CPU 리소스의 90 % 이상을 임의로 차지하므로 병목 현상이 발생하여 전체 시스템이 응답하지 않을 수 있습니다.
• 리버스 프록시 성능 : 순수한 캐시 효율성은 메모리 캐시 유형 Varnish와 ATS 및 Nginx로 가장 강력합니다. 대용량 캐시 팩터를 고려할 때 ATS도 좋은 선택이지만 문서가 부족하고 지속적인주의가 필요합니다. Nginx는 C10K를 위해 특별히 설계된 제품으로 성능이 뛰어나며 많은 플러그인에 매우 적합합니다.
• 필터 규칙 구성 가능 : HAProxy, ATS, Squid는 모두 규칙 파일 읽기, ACL 사용자 정의 및 핫로드, 핫 스타트를 지원합니다. Nginx는 외부 파일의 정기적 일치를 지원하지 않으므로 약간 나빠지지만 소성에는 강합니다.

따라서 위의 고려 사항에 따라 마지막으로 채택한 아키텍처는 HAProxy + Varnish / ATS / Nginx, 즉 방어 적 리버스 프록시 캐시 솔루션의 조합입니다. 기능적 역할은 다음과 같습니다.

• HAProxy는 세션 고 정성, 노드 로드밸런싱 및 페일 오버를 달성하기 위해 동적 및 정적 리소스의 분리를 전적으로 책임지고, 위기가 발생하면 Http 프로토콜을 기반으로 CC 유형 공격 방어를 수행합니다.
• 후자는 플러그 가능하고 교체 가능한 리버스 프록시 캐시 엔진입니다. 프로덕션 라인의 실제 응용 프로그램 시나리오와 캐시 객체의 용량에 따라 메모리 유형 광택 또는 디스크 유형 att를 사용하기로 결정됩니다. Nginx + 플러그인과 같은 리버스 프록시.

이 조합의 가장 큰 특징은 다음과 같습니다.

• 외부 필터링 규칙 읽기를 지원합니다. 특히 키 문자열을 이스케이프 할 필요가 없으며 파일에 직접 추가 할 수 있습니다.
• 적용 할 구성 파일의 핫로드 지원, 모든 지원 재로드 및 서비스가 원활하게 적용됩니다.
• 플러그 가능한 캐시 구성 요소는 다양한 비즈니스 요구에 유연하게 대응합니다.
• 배포가 간단하고 노드 장애 / 유효 전환이 편리합니다.

왜 LVS에 대한 언급이 없는가? LVS는 강력하고 효율적이며 안정적인 4 계층 포워딩으로 7 계층 HTTP 프로토콜로 식별 할 수 없지만 7 계층 전에 세울 수 있기 때문이다. 따라서 LVS의 사용은 네트워크 구조에 영향을 미치지 않으며 앞으로도 계속 생각할 수 있지만 LVS의 단일 장애 지점을 고려해야합니다.

4.보호 전략을 만드는 방법

HAProxy의 httplog 기능을 켜서 로그를 기록하십시오.

HAProxy 구성 전략 :

global
    nbproc 24
    pidfile /var/run/haproxy.pid
    daemon
    quiet
    user nobody
    group nobody
    chroot /opt/haproxy
    spread-checks 2

defaults
    log 127.0.0.1   local5
    mode    http
    option  forwardfor
    option  httplog
    option  dontlognull
    option  nolinger # reduce FIN_WAIT1
    option  redispatch
    retries 3
    option  http-pretend-keepalive
    option  http-server-close
    option  accept-invalid-http-request
    timeout client 15s
    timeout connect 15s
    timeout server 15s
    timeout http-keep-alive 15s
    timeout http-request 15s

    stats enable
    stats uri /stats
    stats realm 53KF\ Proxy\ Status
    stats refresh 60s
    stats auth admin:adminxxx

listen Web_FB 0.0.0.0:80
    option httpchk GET /alive.php HTTP/1.0

    acl invalid_referer hdr_sub(referer) -i -f /opt/haproxy/etc/bad_ref.conf
    acl invalid_url url_sub -i -f /opt/haproxy/etc/bad_url.conf
    acl invalid_methods method -i -f /opt/haproxy/etc/bad_method.conf
    block if invalid_referer || invalid_url || invalid_methods

    acl dyn_host hdr(host) -i -f /opt/haproxy/etc/notcache_host.conf
    acl static_req path_end -i -f /opt/haproxy/etc/allow_cache_file.conf
    use_backend img_srv if static_req !dyn_host

# acl shaohy
    acl geek hdr_dom(host) -i 17geek.com
    use_backend geek if geek

# backend shaohy
backend geek
    mode http
    balance source
    cookie SESSION_COOKIE insert indirect nocache
    option tcpka
    server geek_1 127.0.0.1:81 cookie geek_1 maxconn 10000 weight 8

backend img_srv
    mode http
    option tcpka
    server img_srv 127.0.0.1:88 maxconn 30000 weight 8

5.Varnish의 구성 전략 :

backend h_17geek_com_1 {        
    .host="127.0.0.1";      
    .port="81";         
    .connect_timeout=300s;      
    .first_byte_timeout=300s;   
    .between_bytes_timeout=300s;    
 }                  

director geek srv {         
    { .backend=h_17geek_com_1; .weight=3;}
 }                  

sub vcl_recv {
    if (req.http.host~"^(www).?17geek.com$"){
        set req.backend=geek_srv;       
        if (req.request != "GET" && req.request != "HEAD") {
            return (pipe);              
        }                       
        if(req.url ~ "\.(php|jsp)($|\?)") {         
            return (pass);              
        }                       
        else {                      
            return (lookup);            
        }                   
    }                       
 }

CC 유형 DDoS 공격의 경우 비정상 트래픽을 모니터링하는 방법이 여전히 적용 가능하며 다음과 같은 장점이 있습니다.

• 각 노드는 해당 로그 레코드를 보유하고 로그의 시스템 오버 헤드를 분석하며 ACL 요청을 직접 감지하여 haproxy의 프론트 엔드에서 ACL 규칙을 필터링하므로 백엔드 보안을 위해 공격 압력이 백엔드 서버로 전송되지 않습니다.
• 노드가 수신 한 공격 트래픽이 너무 커서 컴퓨터 실이 IP를 차단하거나 트래픽을 전환 할 수 있습니다. 백엔드 지능형 DNS는이 노드를 자동으로 제거하고 후속 요청은이 노드를 통과하지 않습니다.