대상 OS: Debian 12 (bookworm)
SSH를 인터넷에 열어두면, 성공하든 실패하든 ‘시도’는 끝없이 들어옵니다.
키 인증을 써도, 취약한 계정이 없어도, 공격자는 연결을 열고 닫는 것만으로도 자원을 소모시키고 로그를 오염시킵니다.
Fail2ban처럼 “로그 기반 차단”도 좋지만, 더 앞단에서 ‘연결 속도’를 줄이면 소음 자체가 줄어듭니다.
Debian 12에서는 nftables의 rate limit과 set을 활용해 SSH 시도를 완화하고, 필요 시 단계적으로 차단까지 이어갈 수 있습니다.
이 글은 nftables만으로 SSH 연결/신규 세션을 속도 제한하고, 운영자가 조절 가능한 형태로 튜닝하는 방법을 정리합니다.
(목표는 “완벽 차단”이 아니라 “자원 소모/로그 노이즈/무차별 시도의 비용”을 올리는 것입니다.)
---
1) 이 방식이 잘 먹히는 위협 시나리오
1) 봇넷이 22/tcp에 초당 수십~수백 연결을 던지는 경우
2) 인증 실패가 대량으로 쌓여 디스크/로그 파이프라인이 시끄러운 경우
3) 애플리케이션은 멀쩡한데 SSH 데몬이 과부하로 지연되는 경우
4) Fail2ban을 쓰기 전에 “앞단에서 속도부터 줄이고” 싶은 경우
주의: 분산 공격(수천 IP가 조금씩)에는 rate limit만으로는 한계가 있습니다. 그래도 ‘연결 폭주형’ 공격에는 효과가 큽니다.
---
2) 변경 전 확인: 현재 SSH 포트/방화벽/접속 경로
1) SSH 포트 확인
sudo sshd -T | grep -i '^port '2) nftables 사용 여부와 현재 룰셋 백업
sudo nft list ruleset > /root/nft.ruleset.backup.$(date +%F_%H%M%S).txt
sudo nft list ruleset | sed -n '1,200p'3) 현재 22번 연결 상태(폭주 여부) 확인
sudo ss -tn sport = :22 | head -n 50
sudo ss -s---
3) 설계 원칙: ‘허용’보다 ‘속도 제한’을 먼저 둔다
운영에서 흔한 실수는, 처음부터 공격 IP를 영구 차단하려고 하는 겁니다.
속도 제한은 오탐 리스크가 낮고, 임계치 튜닝이 쉬워서 도입이 안전합니다.
이 글의 정책(예시)
- 관리망/사내 IP는 제한 없이 허용(또는 더 높은 한도)
- 공용망에서 SSH 신규 연결은 초당/분당 제한
- 임계치를 넘으면 일시적으로 “짧게” 드롭(또는 일정 시간 차단 set에 적재)
---
4) nftables 기본 골격(예시: inet filter)
이미 nftables를 운영 중이면, 기존 테이블에 “SSH 전용 체인”만 추가하는 걸 권장합니다.
아래는 이해를 돕기 위한 예시이며, 적용 전 반드시 콘솔 접근(또는 세션 유지) 상태로 진행하세요.
1) /etc/nftables.conf에 SSH 체인 추가 예시
sudo tee /etc/nftables.conf >/dev/null