가이드

작성자 Matt Connor 2026-07-15 · 업데이트됨 2026-08-07

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

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

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

Q: Fail2ban이 제 서버에서 아무것도 차단하지 않는 이유는 무엇입니까?

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

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.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 정도만 사용하는 가벼운 도구이므로 별도의 제한 설정이 필요하지 않습니다.

이제 기존의 많은 가이드가 잘못 설명하고 있는 부분을 짚어보겠습니다. 수년간 표준처럼 여겨졌던 조언은 "Fail2ban을 설치한 뒤 backend = systemd를 추가하라"는 것이었습니다. Ubuntu에서 /var/log/auth.log 기록을 중단했기 때문입니다. 이는 실제 변화를 반영한 조언으로, 최신 서버 및 클라우드 이미지는 rsyslog 없이 배포되므로 SSH 로그는 systemd 저널에만 기록되고 해당 텍스트 파일은 존재하지 않습니다. 하지만 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이 저널을 읽는다는 의미이므로, 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 저널을 읽을 수 없는 권한 없는 컨테이너 환경인 경우, 또는 오래된 튜토리얼을 따라 backend = auto 내용을 자신의 jail.local에 붙여넣어 정상적인 기본 설정을 덮어쓴 경우입니다. 실패 유형 섹션에서 각 상황이 어떻게 나타나는지 확인할 수 있습니다.

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.conf가 아닌 jail.local 편집하기

Fail2ban은 상위 설정 기본값을 /etc/fail2ban/jail.conf에 보관합니다. 이 파일을 직접 편집하지 마십시오. 패키지의 apt upgrade이 이 파일을 덮어쓸 수 있으며, 그럴 경우 변경 사항이 경고 없이 사라집니다. Fail2ban은 정해진 순서대로 파일을 읽는데, jail.conf를 먼저 읽고 jail.d/의 모든 파일을 읽은 뒤 마지막으로 jail.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:   10.0.0.66

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

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

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

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

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

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

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

대기 시간 없이 전체 과정을 검증하려면, 본인의 IP가 아닌 문서용 주소를 수동으로 차단하십시오.

sudo fail2ban-client set sshd banip 10.0.0.66

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

sudo nft list table inet f2b-table

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

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

실수로 본인의 IP 주소를 포함하여 차단하지 말아야 할 주소를 차단했다면, 다음 명령어로 차단을 해제하십시오.

sudo fail2ban-client set sshd unbanip 10.0.0.66

성공하면 1이 반환됩니다. 모든 jail에서 모든 차단 항목을 삭제하려면 다음 명령어를 사용하십시오.

sudo fail2ban-client unban --all

이미 열려 있는 SSH 세션이 안전할 것이라고 가정해서는 안 됩니다. nftables 차단은 포트 22로 들어오는 해당 IP의 모든 패킷을 거부하며, 여기에는 이미 확립된 연결도 포함되므로 차단이 적용되는 즉시 기존 세션은 멈추게 됩니다. 본인을 차단했고 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에서는 패키지 기본값을 재정의했거나, 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번 포트에 도달하는 경우입니다. 이는 차단 작업과 방화벽 간의 불일치 문제이며, Ubuntu 24.04에서는 iptables 계층이 없는 환경에서 이전 가이드의 banaction = iptables-multiport를 복사하여 정상 작동하던 banaction = nftables을 재정의했을 때 거의 항상 발생합니다. 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)을 활성화합니다. 또한 backend = systemd을 설정하여 존재하지 않는 /var/log/auth.log 대신 systemd 저널을 읽도록 하며, banaction = nftables를 설정하여 Ubuntu의 실제 방화벽을 통해 차단이 적용되도록 합니다. 별도의 설정 없이도 apt install fail2ban은 첫 부팅부터 SSH를 보호합니다. sudo fail2ban-client status sshd 명령으로 이를 확인하고 Total failed 값이 0이 아닌지 확인하십시오.

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

다음 세 가지 일반적인 원인을 순서대로 확인하십시오. 첫째, 테스트 중인 IP 주소가 ignoreip에 포함되어 있을 수 있습니다. 이 설정은 기본적으로 차단에서 제외됩니다. 둘째, 오래된 가이드에 따라 backend = auto을 jail.local에 붙여넣어 기본 설정을 덮어썼을 수 있습니다. 이 경우 auth.log가 없는 환경에서는 저널 읽기가 중단됩니다. 셋째, 읽을 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.conf은 읽기 전용 참조용으로만 두십시오.

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

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

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