가이드

작성자 Matt Connor 2026-10-12

Ubuntu 24.04 Fail2ban 설치 및 SSH 차단 설정 방법

Q: Ubuntu 24.04에 기본 설치된 Fail2ban이 실제로 SSH 공격을 차단합니까?

네, 그렇습니다. 해당 패키지는 /etc/fail2ban/jail.d/defaults-debian.conf을 포함하고 있어 sshd 감옥(jail)을 활성화합니다. 또한 /var/log/auth.log 파일의 생성 여부와 관계없이 systemd 저널을 읽도록 backend = systemd를 설정하며, Ubuntu의 기본 방화벽을 통해 차단이 적용되도록 banaction = nftables를 설정합니다. 별도의 설정 없이도 apt install fail2ban가 첫 부팅부터 SSH를 보호합니다. sudo fail2ban-client status sshd 명령으로 상태를 확인하여 Total failed 값이 0이 아닌지 확인하십시오.

Q: 제 IP 주소의 차단을 해제하려면 어떻게 해야 합니까?

sudo fail2ban-client set sshd unbanip YOUR.IP.HERE을 실행하십시오. 성공하면 1이 반환됩니다. 모든 차단을 해제하려면 sudo fail2ban-client unban --all을 실행합니다. SSH 접속이 차단된 경우, 제공업체의 웹 콘솔이나 VNC 콘솔을 통해 동일한 명령을 실행하십시오. 차단이 적용되면 해당 주소에서 포트 22로 들어오는 모든 패킷이 거부되므로, 이미 열려 있던 세션도 작동을 멈춥니다. 이후 차단이 재발하지 않도록 ignoreip에 본인의 주소를 추가하십시오.

Q: jail.conf와 jail.local의 차이점은 무엇입니까?

jail.conf에는 Fail2ban의 상위 기본 설정이 포함되어 있으며 패키지 업그레이드 시 교체될 수 있으므로, 이곳을 직접 수정하는 것은 위험합니다. Debian/Ubuntu 패키지는 jail.d/defaults-debian.conf을 통해 자체 설정을 덧씌웁니다. 사용자의 변경 사항은 jail.local에 작성해야 합니다. 이 파일은 앞선 두 파일보다 나중에 읽혀 우선순위를 가지며, 업그레이드 시에도 변경되지 않습니다. jail.d/ 내부의 *.local 파일은 가장 마지막에 읽히므로, 불필요한 파일을 남겨두지 마십시오. jail.conf는 읽기 전용 참조용으로만 두어야 합니다.

Ubuntu 24.04에서 apt install로 Fail2ban을 설치하고 SSH 무차별 대입 공격을 차단하는 방법을 설명합니다. fail2ban-client status sshd 명령으로 작동 상태를 확인하고 Total failed가 0으로 유지되는지 점검하는 법을 안내합니다.

Fail2ban의 실제 역할

Fail2ban은 로그를 읽는 데몬입니다. 이 도구는 SSH 인증 메시지를 모니터링하다가, 짧은 시간 내에 특정 주소에서 여러 번의 인증 실패가 발생하면 방화벽 명령을 실행하여 해당 주소를 일정 시간 동안 차단합니다. 이것이 작동 원리의 전부입니다. 설정 파일 하나에 약 30줄 정도의 설정만 포함되며, Ubuntu 24.04에서는 apt 명령 한 번으로 설치가 완료되어 별도의 수정 없이도 즉시 보호를 시작할 수 있습니다.

이 도구의 역할과 한계를 명확히 이해해야 합니다. Fail2ban은 사용자를 인증하거나 데이터를 암호화하지 않으며, 단 한 번의 치밀한 로그인 시도를 막아내지도 못합니다. 오직 동일한 소스에서 반복되는 시도만을 차단합니다. 이는 보안 잠금장치가 아니라 소음 필터이자 속도 제한 도구입니다. Fail2ban의 목적은 포트 22를 대상으로 하는 지속적인 배경 스캔이 CPU, 대역폭, 로그 공간을 낭비하지 않도록 방지하고, 한 번에 하나의 주소에서만 접근할 수 있는 공격자의 속도를 늦추는 것입니다.

Fail2ban이 대체하지 못하는 것

Fail2ban은 첫 번째 방어선이 아니라 세 번째 방어선입니다. 서버가 여전히 SSH 비밀번호 인증을 허용한다면, 수천 개의 주소로 분산된 봇넷은 차단 임계값 미만으로 시도를 유지하며 계속해서 비밀번호를 추측할 수 있습니다. 이에 대한 실질적인 방어책은 키 기반 인증(key-only authentication)을 사용하는 것입니다. 키 기반 인증을 사용하면 아무리 많은 시도를 하더라도 비밀번호 추측 자체가 불가능해집니다. 키 기반 인증 환경에서 Fail2ban을 추가로 사용하면 두 가지 유용한 효과가 있습니다. 첫째, 로그에서 무차별 대입 공격(brute-force) 관련 노이즈를 제거합니다. 둘째, 스캐너를 조기에 차단하여 포트에 대한 지속적인 공격을 방지합니다. Fail2ban은 심층 방어(defence in depth)의 일부로 취급해야 합니다. Fail2ban은 키 인증과 방화벽 뒤에 위치해야 하며, 결코 그 앞단에 배치해서는 안 됩니다.

사전 요구 사항 및 Ubuntu 24.04의 현실

root 또는 sudo 권한이 있고 SSH 접속이 가능한 Ubuntu 24.04 VPS가 필요합니다. 가급적 키 기반 인증을 사용하는 것이 좋습니다. Fail2ban은 수십 MB의 RAM만 사용하는 가벼운 도구이며, 별도의 제한 설정 최적화는 필요하지 않습니다.

이제 구형 가이드들이 잘못 설명하는 부분을 짚어보겠습니다. 수년간 "Fail2ban을 설치한 뒤 backend = systemd를 추가하십시오. Ubuntu는 더 이상 /var/log/auth.log을 기록하지 않기 때문입니다"라는 조언이 표준처럼 통용되었습니다. 하지만 이 조언은 일부 이미지에서만 유효합니다. 표준 Ubuntu 24.04 서버 또는 클라우드 이미지는 여전히 rsyslog을 설치하며, 기본 규칙에 따라 auth,authpriv.*을 /var/log/auth.log에 기록합니다. 따라서 대부분의 VPS에서 SSH 실패 기록은 systemd journal뿐만 아니라 해당 파일에도 남습니다. 최소 설치 이미지(Ubuntu 24.04 minimal cloud image는 rsyslog 없이 배포됨)와 대부분의 컨테이너는 SSH 로그를 journal에만 기록하므로 텍스트 파일이 실제로 존재하지 않습니다. 어느 경우든 Ubuntu 24.04의 Fail2ban 패키지는 이를 이미 고려하고 있습니다. 패키지 설치 시 /etc/fail2ban/jail.d/defaults-debian.conf이 생성되며, 서버는 업스트림 기본값이 아닌 이 파일을 실제로 실행합니다.

[DEFAULT]
banaction = nftables
banaction_allports = nftables[type=allports]
backend = systemd

[sshd]
enabled = true

이 내용을 주의 깊게 읽어보십시오. 설정을 변경하기 전에 두 가지 의문이 해결됩니다. backend = systemd는 SSH jail이 journal을 읽는다는 의미이므로, 이미지에서 auth.log을 기록하는지 여부는 중요하지 않습니다. banaction = nftables는 차단이 레거시 iptables가 아닌 Ubuntu 24.04의 실제 방화벽인 nftables를 통해 수행됨을 의미합니다. 그리고 [sshd] enabled = true는 jail이 첫 부팅부터 활성화되어 있음을 의미합니다. 결론적으로, Ubuntu 24.04의 표준 apt install fail2ban은 설치 즉시 SSH 무차별 대입 공격을 차단합니다. 사용자가 할 일은 이를 확인하고, 정책을 조정하며, 스스로 접속이 차단되지 않도록 주의하는 것뿐입니다.

오래된 auth.log 함정은 다음 세 가지 상황에서 여전히 문제가 되므로 인지할 필요가 있습니다. 첫째, apt 대신 pip로 Fail2ban을 설치하여 defaults-debian.conf이 없는 경우, 둘째, 읽을 systemd journal이 없는 비권한 컨테이너 내부인 경우, 셋째, 오래된 튜토리얼을 따라 backend = auto을 자신의 jail.local에 붙여넣어 정상 작동하는 기본값을 덮어쓴 경우입니다. 첫 번째와 세 번째 상황은 rsyslog이 없는 이미지(예: 최소 설치 이미지)에서만 SSH 차단 기능을 고장 냅니다. rsyslog가 실행되는 환경에서는 파일 백엔드가 /var/log/auth.log를 찾아 정상 작동하기 때문입니다. 실패 유형 섹션에서 각 상황이 어떻게 나타나는지 정확히 확인할 수 있습니다.

1단계: 설치 및 차단 동작 확인

sudo apt update
sudo apt install -y fail2ban

Ubuntu 24.04는 Fail2ban 1.0.2 버전을 제공하며, 패키지 설치 시 python3-systemd을 필수 의존성으로 함께 설치하므로 저널 백엔드 구동에 필요한 모든 요소를 갖추게 됩니다. 서비스는 설치 직후 자동으로 활성화되고 시작됩니다.

sudo systemctl status fail2ban

active (running)을 실행합니다. 그런 다음 이미 동작 중인 jail을 확인합니다.

sudo fail2ban-client status sshd

인터넷에 노출된 VPS라면 몇 분만 지나도 포트 22를 향한 지속적인 스캔 시도로 인해 실패 횟수가 기록되고 IP 주소가 차단된 것을 확인할 수 있습니다. 이는 기본 설정이 정상적으로 작동하고 있다는 증거입니다. 이제부터는 밑바닥부터 구축하는 것이 아니라, 기존 설정을 다듬어 나가는 작업을 진행합니다.

2단계: jail.local 편집하기 (jail.conf는 절대 편집 금지)

Fail2ban은 상위 설정 기본값을 /etc/fail2ban/jail.conf에 보관합니다. 이 파일을 직접 편집하지 마십시오. 파일 헤더에 경고된 바와 같이, 패키지 업그레이드 시 파일이 교체될 수 있으며 이때 편집한 내용이 모두 사라집니다. Fail2ban은 정해진 순서대로 파일을 읽습니다. 먼저 jail.conf을 읽고, 다음으로 jail.d/*.conf을 알파벳순으로 읽으며, 그 뒤에 jail.local를, 마지막으로 jail.d/*.local을 알파벳순으로 읽습니다. 나중에 읽힌 값이 우선합니다. 따라서 jail.local은 패키지로 제공된 defaults-debian.conf를 덮어쓰지만, jail.d/에 생성한 모든 *.local 파일은 그 이후에 읽혀 다시 한번 덮어씁니다. 어떤 값이 적용 중인지 파악할 수 있도록 재정의 설정은 한곳에 모아두어야 합니다. .local 파일은 사용자의 영역이며, 패키지 업그레이드 시 절대 변경되지 않습니다. 필터에도 동일한 규칙이 적용되며, *.local 파일이 기본 제공되는 filter.d/*.conf을 덮어씁니다.

따라서 필요한 설정 몇 가지만 재정의하는 작은 jail.local 파일을 작성하고, jail.conf와 패키지로 제공된 jail.d/defaults-debian.conf은 참조용으로 그대로 두어야 합니다.

3단계: /etc/fail2ban/jail.local 작성

sudo nano /etc/fail2ban/jail.local

다음 내용을 입력하십시오. ignoreip 줄의 주소는 본인의 공인 IP로 변경해야 합니다.

[DEFAULT]
# Ubuntu 24.04 already sets these two in jail.d/defaults-debian.conf.
# Pinning them here documents the dependency and survives if that
# file is ever removed or changed by an upgrade.
backend   = systemd
banaction = nftables

# Ban for one hour ...
bantime  = 1h
# ... if an address fails ...
maxretry = 5
# ... 5 times within 10 minutes.
findtime = 10m

# Never ban these. PUT YOUR OWN IP HERE.
ignoreip = 127.0.0.1/8 ::1 10.0.0.24

# Longer bans for repeat offenders: 1h, 2h, 4h ... up to a week.
bantime.increment = true
bantime.maxtime   = 1w

[sshd]
enabled = true

각 설정 줄은 다음과 같은 역할을 합니다.

bantime, findtime, maxretry은 정책을 정의합니다. 기본값인 bantime은 10분에 불과하므로, 1시간 정도로 설정하는 것이 더 합리적입니다. 10분 동안 동일 주소에서 5회 실패하면 차단됩니다. 일반 사용자는 비밀번호를 한두 번 틀릴 수 있지만, 10분 내 5회 실패는 스크립트 공격으로 간주합니다.
ignoreip은 안전장치입니다. 본인이 접속하는 공인 IP 주소를 여기에 입력하여 Fail2ban이 서버에서 스스로를 차단하는 일을 방지하십시오. 가정용 인터넷의 IP가 유동적이라면 이 줄을 생략하기보다 문서 끝부분에 설명된 VPN 방식을 사용하는 것이 좋습니다.
bantime.increment = true는 반복 차단 시 차단 시간을 점진적으로 늘립니다. 1시간, 2시간, 4시간 순으로 증가하며 최대 bantime.maxtime까지 늘어납니다. 계속해서 접속을 시도하는 주소는 점점 더 길게 차단됩니다.

SSH 접속을 수행하는 로컬 컴퓨터에서 화이트리스트에 추가할 주소를 확인하십시오(서버에서 확인하는 것이 아닙니다).

curl -s ifconfig.me

사용 중인 포트와 차단 정책에 맞춰 최적화된 jail.local을 생성한 뒤, 해당 내용을 파일에 붙여넣을 수 있습니다.

ToolFail2ban jail generator

단계 4: 재시작 및 저널 읽기 확인

sudo fail2ban-client -t
sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

-t은 먼저 설정 테스트를 수행하므로, jail.local에 오타가 있으면 서비스가 중단된 상태로 남지 않고 즉시 실패를 알립니다. 정상적인 jail 상태는 다음과 같습니다.

Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     14
|  `- Journal matches:  _SYSTEMD_UNIT=sshd.service + _COMM=sshd
`- Actions
   |- Currently banned: 1
   |- Total banned:     3
   `- Banned IP list:   203.0.113.66

Fail2ban이 로그인 기록을 정상적으로 읽고 있음을 증명하는 숫자는 Total failed입니다. 이 값이 0보다 크거나 다른 기기에서 의도적으로 로그인을 실패했을 때 증가한다면, 저널을 정상적으로 읽고 있는 것이며 작업이 완료된 것입니다. 만약 로그인을 여러 번 실패해도 값이 0로 유지되고, ignoreip에 명시된 주소에서 테스트하는 것이 확실하다면 아래의 실패 유형 항목으로 이동하십시오.

Journal matches 줄에서 여전히 sshd.service을 가리키고 있다는 점에 유의하십시오. Ubuntu에서 SSH 유닛은 실제로는 ssh.service이지만, 기본 제공 필터는 _COMM=sshd와도 일치하며, 24.04의 OpenSSH는 sshd이라는 프로세스 이름으로 실패 로그를 기록하므로 매칭이 정상적으로 작동합니다. 이 세부 사항은 최신 OpenSSH(연결별 워커가 sshd-session인 9.8 버전 이상)를 사용하는 경우에만 중요하며, 해당 사례는 실패 유형 항목에서 다룹니다.

5단계: 실제 차단 확인 또는 강제 테스트

공개된 VPS라면 몇 분 안에 자동으로 차단이 발생합니다. 차단 과정을 확인하려면 로그를 실시간으로 추적하십시오:

sudo tail -f /var/log/fail2ban.log

차단 로그는 다음과 같은 형식으로 나타납니다:

2026-07-15 10:31:40,502 fail2ban.filter  [812]: INFO    [sshd] Found 203.0.113.66 - 2026-07-15 10:31:40
2026-07-15 10:31:44,118 fail2ban.actions [812]: NOTICE  [sshd] Ban 203.0.113.66

기다리지 않고 전체 과정을 검증하려면, 본인의 IP가 아닌 문서용 주소를 수동으로 차단하십시오. 203.0.113.66는 문서화를 위해 예약된 TEST-NET-3 대역에 속하므로, 실제 호스트나 공급자의 내부 네트워크 주소와 충돌하지 않습니다:

sudo fail2ban-client set sshd banip 203.0.113.66

명령을 실행하면 1이 출력되며, 해당 주소가 fail2ban-client status sshd의 Banned IP list 항목에 나타납니다. 이제 방화벽에 차단 규칙이 실제로 존재하는지 확인하십시오. Ubuntu 24.04는 iptables가 아닌 nftables를 사용합니다:

sudo nft list table inet f2b-table

203.0.113.66을 포함하는 addr-set-sshd이라는 이름의 set과, 해당 set에 포함된 소스를 거부하는 f2b-chain 체인을 확인할 수 있습니다. 만약 fail2ban-client에서는 주소가 차단되었다고 나오는데 nft list에는 아무것도 나타나지 않는다면, 차단 동작이 방화벽 설정과 일치하지 않는 것입니다. 실패 유형 항목의 nftables/iptables 관련 참고 사항을 확인하십시오.

6단계: 차단 해제 및 잠김 상태 복구

실수로 본인의 IP 주소를 차단했다면 다음 명령어로 차단을 해제하십시오.

sudo fail2ban-client set sshd unbanip 203.0.113.66

성공하면 1이 반환됩니다. 모든 jail에서 모든 차단 항목을 삭제하려면 다음을 실행하십시오.

sudo fail2ban-client unban --all

이미 열려 있는 SSH 세션이 안전할 것이라고 기대하지 마십시오. nftables 차단은 차단된 주소에서 포트 22로 들어오는 모든 패킷을 거부하며, 여기에는 이미 확립된 연결도 포함됩니다. 따라서 차단이 적용되는 즉시 기존 세션은 멈춥니다. 만약 본인을 차단했고 ignoreip 항목이 없다면, 차단이 만료될 때까지 시스템에 접근할 수 없습니다. 이 경우 SSH를 거치지 않는 제공업체의 웹 콘솔(VNC 또는 시리얼)을 통해 복구하십시오. 그곳에서 bantime 시간이 지날 때까지 기다리거나 차단 해제 명령을 실행하십시오.

7단계: 차단 유지 및 강화

Fail2ban은 활성 차단 목록을 /var/lib/fail2ban/fail2ban.sqlite3의 소규모 SQLite 데이터베이스에 보관하므로, 서비스가 재시작되거나 시스템이 재부팅되어도 차단 상태가 유지됩니다. 이미 추가한 bantime.increment 설정 줄은 반복적인 공격자의 차단 시간을 1시간에서 약 1주일까지 점진적으로 늘려 나갑니다.

이와 더불어 시스템 전체에 "삼진 아웃" 정책을 적용하려면, Fail2ban에서 제공하는 recidive 감옥(jail)을 사용하십시오. 이 감옥은 자체 /var/log/fail2ban.log를 감시하며, 모든 감옥에서 반복적으로 차단된 주소에 대해 장기 차단을 적용합니다. 현재 [DEFAULT] 설정이 systemd 백엔드를 사용하고 있으므로, 이 감옥이 읽도록 설계된 로그 파일로 다시 지정해야 합니다.

[recidive]
enabled  = true
backend  = auto
logpath  = /var/log/fail2ban.log
bantime  = 1w
findtime = 1d
maxretry = 5

backend = auto에 명시적인 logpath를 설정하면 recidive가 일반 fail2ban.log 파일을 계속 읽게 됩니다. 이 파일에는 실제로 Ban 설정 줄이 기록되는데, 전역으로 설정한 systemd 기본값을 그대로 두면 journal을 참조하게 되어 해당 기록을 찾을 수 없게 됩니다.

8단계: 키 기반 SSH 인증과 VPN을 함께 사용하기

Fail2ban은 키 기반 인증과 함께 사용할 때 비로소 제 역할을 합니다. /etc/ssh/sshd_config.d/ 아래의 드롭인 파일(예: /etc/ssh/sshd_config.d/00-hardening.conf)에 다음 내용을 설정하십시오.

PasswordAuthentication no
KbdInteractiveAuthentication no

그런 다음 sudo systemctl restart ssh를 실행합니다. 비밀번호 인증을 비활성화하면 무차별 대입 공격은 원천적으로 불가능해집니다. 이때 Fail2ban은 로그 기록을 줄이고 스캐너를 조기에 차단하는 역할을 수행합니다. 더 강력한 방법은 SSH를 공용 인터넷에서 완전히 격리하는 것입니다. SSH를 자체 호스팅 WireGuard VPN 내부로 옮기고 방화벽에서 22번 포트를 터널 인터페이스에서만 응답하도록 설정하십시오. 접근할 수 없는 포트는 무차별 대입 공격이 불가능하며, Fail2ban은 최전선이 아닌 최후의 방어선이 됩니다.

Fail2ban은 SSH만을 위한 도구가 아닙니다. 로그인 실패 로그를 남기는 모든 서비스(메일 서버, nginx 사이트, 혹은 자체 호스팅 Vaultwarden 비밀번호 관리자)에 감옥(jail)을 설정할 수 있습니다. 특히 웹 로그인 페이지를 크리덴셜 스터핑 공격에 노출하고 싶지 않을 때 유용합니다. 웹 애플리케이션이 Let's Encrypt 인증서가 적용된 nginx 사이트 뒤에 있다면, SSH 감옥이 저널을 참조하는 것과 같은 방식으로 Fail2ban 필터를 해당 액세스 로그에 연결하십시오.

실패 유형 및 확인 가능한 정확한 메시지

"Have not found any log file for sshd jail" 메시지와 함께 Fail2ban이 시작되지 않음. 이는 오래된 auth.log 문제입니다. Ubuntu 24.04에서는 /var/log/auth.log가 존재하지 않는 환경(최소 이미지나 컨테이너 등 rsyslog이 없는 이미지)에서 저널을 읽지 못할 때 발생합니다. 즉, defaults-debian.conf이 없는 pip 설치, 저널이 없는 컨테이너, 또는 jail.local에 잘못 붙여넣은 backend = auto가 원인입니다. /var/log/auth.log이 없는 파일 백엔드 환경에서는 sshd jail이 로그 파일을 찾지 못해 데몬 전체가 중단됩니다. fail2ban.log는 다음을 보여줍니다.

ERROR   Failed during configuration: Have not found any log file for sshd jail

이 오류는 치명적이므로 서비스가 시작되지 않으며, fail2ban-client status은 하위 증상을 다음과 같이 보고합니다.

ERROR  Failed to access socket path: /var/run/fail2ban/fail2ban.sock. Is fail2ban running?

"socket path" 행은 Fail2ban이 고장 났다는 뜻이 아니라, 특정 jail이 로그를 찾지 못해 시작조차 하지 못했다는 의미입니다. Ubuntu 패키지에서 이미 설정되어 있는 [DEFAULT]의 backend = systemd를 설정하면 두 메시지가 동시에 해결됩니다.

Jail은 활성화되어 있으나 Total failed이 전혀 증가하지 않음. 데몬은 실행 중이고 저널도 읽고 있지만, 실제 실패 사례가 journalctl -u ssh에 쌓여도 카운터는 0에 머물러 있는 경우입니다. 먼저 명백한 원인을 배제하십시오. ignoreip에 나열된 주소에서 테스트 중이라면 설계상 본인의 실패는 제외됩니다. 그렇지 않다면, 연결별 워커가 sshd-session(9.8 버전 이상)인 OpenSSH 빌드를 사용 중일 수 있습니다. 이 경우 저널 _COMM은 sshd이 아닌 sshd-session이므로, 기본 제공되는 매치 규칙이 이를 놓치게 됩니다. [sshd] 블록에서 매치 범위를 넓히십시오.

[sshd]
enabled      = true
backend      = systemd
journalmatch = _SYSTEMD_UNIT=ssh.service + _COMM=sshd + _COMM=sshd-session

재시작 후 ignoreip에 포함되지 않은 주소에서 의도적으로 로그인을 실패해 보고, Total failed이 정상적으로 올라가는지 확인하십시오.

본인 차단: Connection refused. ignoreip에서 본인의 주소를 제외한 채 잘못된 로그인을 몇 번 시도하면 다음과 같은 상황이 발생합니다.

ssh: connect to host 10.0.0.10 port 22: Connection refused

응답이 없는 타임아웃이 아니라 연결 거부(refusal)가 발생하는 것은 nftables 액션의 기본 reject 판정이 정상 작동하고 있다는 뜻입니다. 6단계의 설명대로 해결하십시오. 차단되지 않은 다른 주소의 세션이나 제공업체 콘솔을 통해 차단을 해제하십시오. 차단된 주소에서 이미 열려 있던 세션은 그대로 멈추게 됩니다. 그 후 다시는 이런 일이 발생하지 않도록 ignoreip에 본인의 주소를 추가하십시오.

Fail2ban은 주소가 차단되었다고 하지만 여전히 연결됨. status sshd의 카운터는 올라가지만 해당 주소가 여전히 22번 포트에 도달하는 경우입니다. 이는 ban-action과 방화벽 간의 불일치 때문입니다. Ubuntu 24.04에서는 iptables 계층이 없는 환경에서 오래된 가이드를 보고 작동하는 banaction = nftables를 banaction = iptables-multiport으로 덮어썼을 때 주로 발생합니다. fail2ban.log는 다음을 보여줍니다.

fail2ban.actions [812]: ERROR  Failed to execute ban jail 'sshd' action 'iptables-multiport'

해당 오버라이드를 삭제하고 패키지에 포함된 기본 nftables 액션을 사용하십시오. 만약 ufw를 통해 방화벽을 관리하고 차단 내역을 그곳에서 확인하고 싶다면, [DEFAULT]에서 banaction = ufw을 설정하십시오. 재시작 후 sudo nft list ruleset | grep f2b을 통해 규칙이 나타나는지 확인하십시오.

jail.local 수정 후 Fail2ban이 시작되지 않음. 오타, 잘못된 헤딩, 또는 잘못된 시간 값으로 인해 서비스가 시작을 거부하는 경우입니다. 실행 전 Fail2ban에 설정을 검사하도록 요청하십시오.

sudo fail2ban-client -t

이 명령은 문제가 있는 파일과 jail을 명시합니다(예: Errors in jail 'sshd'. Skipping...). 따라서 추측할 필요 없이 원인을 직접 수정할 수 있습니다.

FAQ

Ubuntu 24.04에 기본 설치된 Fail2ban이 실제로 SSH 공격을 차단합니까?

네, 그렇습니다. 해당 패키지는 /etc/fail2ban/jail.d/defaults-debian.conf을 포함하고 있어 sshd 감옥(jail)을 활성화합니다. 또한 /var/log/auth.log 파일의 생성 여부와 관계없이 systemd 저널을 읽도록 backend = systemd를 설정하며, Ubuntu의 기본 방화벽을 통해 차단이 적용되도록 banaction = nftables를 설정합니다. 별도의 설정 없이도 apt install fail2ban가 첫 부팅부터 SSH를 보호합니다. sudo fail2ban-client status sshd 명령으로 상태를 확인하여 Total failed 값이 0이 아닌지 확인하십시오.

Fail2ban이 아무것도 차단하지 않는 이유는 무엇입니까?

다음 세 가지 일반적인 원인을 순서대로 확인하십시오. 첫째, 테스트 중인 IP 주소가 설계상 차단에서 제외되는 ignoreip에 포함되어 있을 수 있습니다. 둘째, 오래된 가이드의 backend = auto 내용을 jail.local에 붙여넣어 기본 설정을 덮어썼을 수 있습니다. 이 경우 rsyslog 파일이 없는 환경에서는 auth.log가 작동하지 않아 SSH 차단이 실패합니다. 셋째, systemd 저널을 읽을 수 없는 컨테이너 환경일 수 있습니다. fail2ban-client status sshd에서 Total failed 값을 확인하십시오. journalctl -u ssh에는 실제 실패 기록이 나타나는데도 이 값이 전혀 증가하지 않는다면, 감옥이 잘못된 위치를 참조하고 있는 것입니다.

제 IP 주소의 차단을 해제하려면 어떻게 해야 합니까?

sudo fail2ban-client set sshd unbanip YOUR.IP.HERE을 실행하십시오. 성공하면 1이 반환됩니다. 모든 차단을 해제하려면 sudo fail2ban-client unban --all을 실행합니다. SSH 접속이 차단된 경우, 제공업체의 웹 콘솔이나 VNC 콘솔을 통해 동일한 명령을 실행하십시오. 차단이 적용되면 해당 주소에서 포트 22로 들어오는 모든 패킷이 거부되므로, 이미 열려 있던 세션도 작동을 멈춥니다. 이후 차단이 재발하지 않도록 ignoreip에 본인의 주소를 추가하십시오.

jail.conf와 jail.local의 차이점은 무엇입니까?

jail.conf에는 Fail2ban의 상위 기본 설정이 포함되어 있으며 패키지 업그레이드 시 교체될 수 있으므로, 이곳을 직접 수정하는 것은 위험합니다. Debian/Ubuntu 패키지는 jail.d/defaults-debian.conf을 통해 자체 설정을 덧씌웁니다. 사용자의 변경 사항은 jail.local에 작성해야 합니다. 이 파일은 앞선 두 파일보다 나중에 읽혀 우선순위를 가지며, 업그레이드 시에도 변경되지 않습니다. jail.d/ 내부의 *.local 파일은 가장 마지막에 읽히므로, 불필요한 파일을 남겨두지 마십시오. jail.conf는 읽기 전용 참조용으로만 두어야 합니다.

Fail2ban이 키 기반 SSH 인증을 대체합니까?

아니요, 그렇지 않습니다. Fail2ban은 동일한 주소에서 반복되는 실패를 제한할 뿐, 각 주소가 임계값 미만으로 시도하는 느리고 분산된 공격에는 대응하지 못합니다. 키 전용 인증(PasswordAuthentication no)은 비밀번호 추측 공격을 원천적으로 차단하며, Fail2ban은 로그의 노이즈를 줄이고 스캐너를 조기에 퇴출하는 역할을 합니다. 두 가지를 모두 사용하고, 가급적이면 SSH를 공용 인터넷에 직접 노출하지 않는 것이 좋습니다.

#fail2ban#ssh #ubuntu-24-04 #nftables #systemd #security