머신에 대한 공격: 우리가 하는 일과 여러분이 할 수 있는 일

“attack”이라는 단어는 완전히 다른 두 상황에서 똑같이 들립니다. 채널이 쓸모없는 트래픽으로 가득 차는 경우와 초당 수백 건의 요청이 애플리케이션을 다운시키는 경우죠. 이 둘은 다르게 다뤄지므로, 가장 먼저 해야 할 일은 어느 쪽인지 파악하는 것입니다.

둘을 구별하는 방법

/hosting/vds/m/<id>의 “개요”에서 지난 24시간 동안의 프로세서, 메모리, 트래픽 그래프를 확인하세요. 트래픽은 정상인데 프로세서가 한계치에 고정되어 있다면 애플리케이션 부하이므로, 직접 처리해야 합니다.

할 수 있는 일

nginx에서 요청 속도 제한하기:

limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=conn:10m;

server {
    limit_req zone=perip burst=20 nodelay;
    limit_conn conn 20;
    client_body_timeout 10s;
    client_header_timeout 10s;
}

방화벽에서 연결 수 제한하기:

ufw limit 22/tcp

더 유연한 규칙은 nftables 문서에 있습니다. 여기서는 새 연결의 속도를 제한하고, 차단된 주소 목록을 유효 시간과 함께 유지할 수도 있습니다.

로그에서 출처 찾기:

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
ss -tn state established | awk '{print $4}' | cut -d: -f1 | sort | uniq -c | sort -rn | head

주소나 네트워크를 한 번 차단하기:

ufw deny from 203.0.113.0/24

fail2ban은 로그를 기반으로 차단을 자동화할 수 있습니다.

저희가 하는 일

저희 인프라는 노드로 향하는 쓸모없는 트래픽을, 그것이 여러분의 대역폭을 소모하기 전에 걸러냅니다. 이는 채널에 대한 대규모 공격에 효과가 있으며, 여러분 쪽에서는 아무런 설정이 필요하지 않습니다.

노드 수준 보호가 하지 않는 일은, 여러분 애플리케이션의 로직을 분석하지 않는다는 것입니다. 겉보기에는 정상적인 요청이 여러분의 머신에 도달하며, 이에 대해서는 여러분 자신의 설정만이 보호해 줍니다.

여러분의 머신이 공격의 출처가 되는 경우, 예를 들어 머신이 침해되어 다른 사람의 스팸 캠페인에 가담하고 있다면, 허용 가능한 사용 정책에 따라 접근이 제한됩니다. 머신을 침해 징후와 대조해 확인하세요.

캐싱과 정적 파일

요청 폭주에 맞서는 가장 효과적인 방법은 같은 것을 두 번 계산하지 않는 것입니다:

location /static/ {
    expires 30d;
    add_header Cache-Control "public";
}

무거운 페이지는 애플리케이션 쪽에서 캐시하세요. 캐시에서 제공되는 요청은 비용이 수백 배 적게 듭니다.

흔한 실수

• burst 없이 limit_req를 설정하기 — 페이지가 스무 개 남짓의 파일을 불러오는 일반 사용자도 차단됩니다.
• 분산 공격 중에 주소를 하나하나 수동으로 차단하기: 수천 개에 달하므로 따라잡을 수 없습니다.
• ICMP를 전부 차단하기 — 패킷 크기 협상을 깨뜨립니다. MTU를 참고하세요.
• 자신의 버그를 공격으로 착각하기: 코드의 루프, 제외하는 것을 잊은 디렉터리를 크롤링하는 검색 봇, 끝없는 클라이언트 재시도.

한가한 시점에 미리 한도를 설정해 두세요. 요청 폭주 중에는 rate와 burst 값을 조정할 수 없습니다. 설정을 눈먼 채로, 그것도 조금씩 고쳐야 하니까요.