Fail2ban: 실패 로그에서 방화벽 차단까지

01개념과 구성 요소

• 탐지 입력파일 또는 systemd journal에서 서비스의 실패 기록을 읽는다.
• JailBackend·filter·임계값·action을 묶어 어떤 기록을 어떤 대응으로 연결할지 정한다.
• 차단의 실체Fail2ban의 Ban 상태와 방화벽의 실제 패킷 경로를 함께 확인해야 차단 효과를 알 수 있다.

02실패 로그가 일시 차단으로 이어지는 순서

1. 로그 수신Backend가 파일 위치 또는 journalmatch에 맞는 기록을 읽는다.
2. 패턴·주소 추출Filter가 신뢰할 수 있는 실패 패턴에서 대응할 주소를 추출한다. 사용자 문자열을 주소로 오인하면 오차단이 된다.
3. 시간창 집계같은 대상의 일치 기록을 findtime 안에서 세어 maxretry 조건을 평가한다. 기록 수는 사람의 시도 횟수와 같지 않을 수 있다.
4. Ban Action설정된 action이 방화벽 등에 규칙을 반영한다. 논리적 Ban만으로 IPv4·IPv6와 모든 통신 경로가 막히는 것은 아니다.
5. 만료·해제bantime 또는 관리자의 해제에 따라 규칙을 제거하고 예외·오탐·재발 상태를 확인한다.

03탐지와 차단을 연결하는 구성 요소

• 로그 기반 탐지Fail2ban은 인증 서버 앞에서 모든 패킷의 비밀번호를 검사하는 장비가 아니다. 서비스가 남긴 실패 로그를 backend가 읽고 filter가 정해진 패턴으로 사건과 주소를 추출한다.
• Jailjail은 어떤 서비스·입력·필터·시간 조건·action을 묶을지 정하며, 조건에 도달하면 action이 방화벽 등의 조치를 수행한다.
• Backend·Action로그가 남지 않거나 backend가 해당 로그를 읽지 못하면 차단 조건을 평가할 근거가 없다. 필터가 사건을 찾았더라도 action이 실패하면 실제 패킷이 막히지 않는다.
• 차단 범위설치, 서비스 실행, jail 활성화, 실패 탐지, ban 상태, 실제 방화벽 적용을 서로 다른 확인 지점으로 둔다.
• 실습 구성원본 실습은 Rocky Linux 9에서 SSH 실패를 systemd journal로 읽고 firewalld와 연계하는 구성이었다. 배포판의 기본 action과 서비스 이름은 패키지에 따라 달라지므로 실제 적용 설정과 실행 결과를 함께 읽는다.

04systemd backend와 파일 backend의 차이

• Journal 입력systemd backend는 journal의 필드와 journalmatch 조건으로 대상 이벤트를 읽는다. 파일 경로를 tail하는 방식이 아니므로 같은 jail에 logpath를 넣어 그것이 journal 입력을 지정한다고 생각하면 안 된다.
• Filter 문맥필터가 기대하는 journal 필드와 실제 sshd 기록이 일치하는지 확인한다.
• 파일 입력파일 backend는 지정한 로그 경로를 읽고 파일 회전·권한·날짜 형식의 영향을 받는다. rsyslog 설정에 따라 /var/log/secure 또는 다른 위치에 기록될 수 있으므로 배포판 이름만 보고 경로를 확정하지 않는다.
• 중계 환경별도 컨테이너나 중앙 로그 수집기를 사용하는 환경은 주소와 시간 필드 변형도 고려한다.
• 시간 파싱로그 시각을 잘못 해석하면 오래된 실패가 최근 것으로 잡히거나 현재 실패가 시간 창 밖으로 빠질 수 있다. 서버의 시간대·시계 동기화, parser가 해석한 시각을 확인한다.
• 입력 경계재시작 뒤 journal 커서나 저장 상태의 영향도 로그에서 검증한다.

05maxretry·findtime·bantime을 시간 축으로 읽기

• Findtime·Maxretrymaxretry는 findtime 구간 안에서 해당 주소에 대해 필터가 집계한 실패 사건의 임계값이다. maxretry=5, findtime=10m이면 10분 안에 매칭되는 실패 기록이 5개 쌓일 때 차단 조건이 된다.
• 시도와 기록실제 사용자가 입력한 비밀번호 횟수와 로그 매칭 수가 항상 같지는 않다. 한 시도에서 여러 실패 행이 생기거나 필터가 일부만 세는 경우가 있다.
• Bantimebantime=10m은 차단 후 유지할 기간이다. findtime과 목적이 다르다.
• 시간창 예설명용으로 같은 IP의 실패가 09:00, 09:02, 09:04, 09:06, 09:08에 들어오면 다섯 번째에서 조건에 도달한다. 09:00의 실패 한 건만 있고 다음 실패가 09:20이라면 이전 건은 그 10분 창 밖이다.
• 미탐·오탐많은 사용자가 NAT 뒤에서 같은 출발지 IP를 공유하면 한 사람의 반복 실패가 다른 사용자에게도 영향을 줄 수 있다. 반대로 여러 IP가 느리게 시도하면 주소별 임계값을 넘지 않을 수 있다.
• 정책 목적차단 정책은 MFA·키 기반 인증·접근 범위 제한을 보완하며 전체 계정 보안을 대신하지 않는다.

[sshd]
enabled = true
backend = systemd
port = ssh
maxretry = 5
findtime = 10m
bantime = 10m

수업의 핵심 jail 설정을 재구성한 예제. action과 journalmatch는 설치된 기본값을 포함해 실제 적용 결과를 확인해야 한다.

09filter: 신뢰할 주소를 정확히 추출하기

• 주소 추출filter는 로그에서 실패 사건과 호스트 주소를 찾아야 한다. 사용자가 임의로 입력할 수 있는 사용자명이나 URL을 주소처럼 추출하면 공격자가 다른 사람의 주소를 문자열에 넣어 오차단을 유도할 수 있다.
• 신뢰 필드서비스가 보증하는 로그 접두부와 실제 출발지 필드에 패턴을 고정한다.
• Filter 검증정상 로그인, 잘못된 사용자명, IPv4·IPv6, 다른 메시지 형식이 섞인 표본으로 매칭과 비매칭을 함께 확인한다. 정규식이 몇 줄을 찾았다는 결과만으로 정상 사용자를 차단하지 않는다고 단정할 수 없다.
• 로그 형식 변경버전 변경 뒤 로그 문구가 바뀌면 기존 필터가 조용히 탐지를 놓칠 수 있다.
• Proxy 주소reverse proxy나 중계 서버를 거치면 로그에 중계 주소가 남을 수 있다. 실제 클라이언트 주소는 신뢰한 프록시가 검증해서 전달한 필드에서 얻어야 한다.
• 헤더 신뢰클라이언트가 임의로 보낸 X-Forwarded-For 전체를 신뢰해 방화벽 차단 주소로 쓰지 않는다.

10action: 논리적 Ban과 실제 패킷 경로

• 방화벽 연결action은 Ban/Unban 시점에 방화벽 규칙 등을 적용한다. Fail2ban status에 IP가 있다는 사실과 패킷이 실제 차단 체인을 통과한다는 사실은 다르다.
• Action 문맥선택한 action이 firewalld·nftables·iptables 중 무엇을 사용하는지, SSH 포트와 IPv6를 포함하는지 확인한다.
• 프로토콜 범위서비스 포트가 22가 아닌데 action이 기본 ssh만 막으면 원하는 접속은 계속 통과할 수 있다. 컨테이너·포워딩 경로·다른 네트워크 namespace는 호스트 INPUT 규칙과 다른 경로를 지날 수 있다.
• 기존 연결이미 성립된 연결의 처리는 conntrack과 규칙 순서에 따라 달라 신규 차단과 구분한다.
• Ban 검증firewalld reload나 다른 자동화가 runtime 규칙을 바꾸면 차단 상태와 실제 방화벽이 어긋날 수 있다. Fail2ban 전용 규칙을 확인하고 문제를 고칠 때 시스템의 모든 방화벽 규칙을 초기화하지 않는다.
• 허용 경로전체 방화벽의 상시 접근 제어와 일시적 ban 규칙을 분리해 운영한다.

11Ban 상태와 오류 메시지 해석

• 원본 관찰실습에서는 Server ready, sshd jail 활성화, 시험 클라이언트의 차단 상태와 f2b-sshd 관련 규칙을 확인했다. 이 관찰만으로 모든 재부팅·reload 이후의 정책 지속성을 입증한 것은 아니다.
• 255/EXCEPTION255/EXCEPTION 표기만으로 오류 원인을 하나로 확정할 수 없다. 잘못된 설정 경로, action 의존성, 문법과 로그 입력 문제를 실제 앞뒤 오류 메시지로 좁혀야 한다.
• 정상화 판단정상화 여부는 수정 후 실제 상태와 로그로 판단한다.
• 시험 범위교육용 반복 로그인 시험은 본인의 격리된 SSH 서버와 회복용 콘솔에서 수행해야 한다. 문서의 숫자는 정책 작동을 설명하기 위한 예제이며 현재 사용자의 서버에 차단을 실행한 결과가 아니다.

12상태·탐지·규칙을 각각 검증하기

• Jail 상태fail2ban-client status는 활성 jail 목록을, status sshd는 해당 jail의 탐지·차단 집계를 보여 준다. journal에서 Found와 Ban을 구분하고 action 실행 오류를 함께 읽는다.
• Found·BanFound는 필터가 사건을 찾았다는 뜻이며 그 한 줄만으로 차단이 이루어졌다고 결론 내리지 않는다.
• 실제 규칙실제 규칙을 읽어 출발지 주소·프로토콜·목적지 포트·체인 연결을 확인한다. action 종류에 맞는 관리 도구를 사용하고 nft 규칙이 보인다는 이유만으로 iptables 호환 계층의 관계를 무시하지 않는다.
• 시험 위치허가된 시험 클라이언트에서 신규 접속 결과를 대조하면 정책 적용 여부를 더 확실히 확인할 수 있다.

fail2ban-client status
fail2ban-client status sshd
fail2ban-client get sshd maxretry
fail2ban-client get sshd findtime
fail2ban-client get sshd bantime
fail2ban-client get sshd actions
journalctl -u fail2ban --since "10 minutes ago"
nft list ruleset

상태와 규칙을 읽는 예제. 해당 시스템의 권한과 실제 action을 전제로 하며 이 사이트에서 실행하지 않는다.

13오탐 해제와 설정을 재현 가능하게 유지하기

• Local 설정공급자 기본 jail.conf를 직접 고치기보다 jail.d의 별도 파일이나 적절한 local override로 변경 이유와 적용 범위를 남긴다. 변경 전 파일을 보관하고 설정 검증 후 해당 서비스 상태를 확인한다.
• 버전 관리자동화는 입력값 검증·원자적 파일 교체·실패 시 해당 변경만 복구하는 절차를 갖춘다.
• 복구·IgnoreIP관리자 회복용 경로와 필요한 ignoreip는 최소 범위로 정한다. 광범위한 사설 대역 전체를 예외 처리하면 내부에서 발생한 공격을 놓칠 수 있다.
• 개별 해제개별 주소의 오탐을 해제한 뒤에도 필터 오인식·공유 NAT·시각 오류라는 원인을 고치지 않으면 다시 차단된다.
• 재현 조건배포 완료 기준은 설치 성공 메시지가 아니라 올바른 로그 입력, 기대한 사건 집계, 정확한 포트·주소 차단, 기간 뒤 해제, 서비스 재시작과 방화벽 reload 뒤의 일관성이다. 이 결과를 사건 시각과 함께 남겨야 다음 운영자가 같은 정책을 검증할 수 있다.