fail2ban 비표준 SSH 포트 차단 실패: 22022 포트가 안 막히던 이유

어느 날, 제가 운영하는 DB 서버에 SSH 무차별 대입 공격(brute-force attack) 시도가 계속 감지되기 시작했습니다. 보안 강화를 위해 SSH 기본 포트인 22번 대신 22022번으로 변경하여 사용하고 있었고, fail2ban도 당연히 설치해 sshd jail을 활성화해둔 상태였습니다. '설마 fail2ban이 막아주겠지' 하는 마음으로 지켜봤지만, 공격은 멈추지 않았습니다. fail2ban-client status sshd 명령어를 실행해 보니, 'Banned' 목록이 텅 비어 있는 것을 확인했습니다. 분명히 활성화되어 잘 돌고 있다고 생각했는데, 왜 공격 IP들이 차단되지 않는 걸까요? 이 글은 제가 직접 겪었던 이 의아한 상황의 원인을 파악하고 해결했던 과정을 담고 있습니다.

이 글에서 다루는 것

fail2ban이 비표준 SSH 포트에서 동작하지 않는 이유
sshd jail의 port 설정이 차단에 미치는 영향
jail.local을 활용한 fail2ban 설정 변경 방법
fail2ban이 실제로 IP를 차단하는지 확인하는 방법

대상: SSH 포트를 기본 22가 아닌 다른 번호로 바꿔 운영하는 1인 개발자 및 서버 관리자
난이도: 초급

fail2ban 활성화에도 불구하고 SSH 무차별 대입 공격이 계속되던 상황

제가 운영하는 DB 서버는 보안을 위해 SSH 접속 포트를 기본 22번이 아닌 22022번으로 변경해 사용하고 있었습니다. 그런데 어느 시점부터 특정 IP에서 SSH 무차별 대입 공격 시도가 지속적으로 들어오는 것을 로그를 통해 확인할 수 있었습니다. fail2ban이 설치되어 있고 sshd jail이 enabled 상태였기에, 당연히 공격 IP가 자동으로 차단될 것이라고 예상했습니다. 그러나 시간이 지나도 공격은 멈추지 않았습니다. fail2ban-client status sshd 명령으로 fail2ban의 상태를 확인해 보아도, Banned IP 목록은 0건으로 계속 비어 있더군요. fail2ban 서비스는 정상적으로 실행 중이었지만, 실제로 공격자들을 막아내고 있지는 못하는 상황이었습니다. 로그에는 로그인 실패 기록이 분명히 쌓이고 있었는데, 왜 fail2ban은 이를 차단으로 연결하지 못하는지 의문이 들었습니다. 서비스가 '돌고 있다'는 것과 '제 역할을 하고 있다'는 것은 완전히 다른 문제라는 것을 깨닫게 된 순간이었습니다.

sshd jail 기본 설정 'port = ssh'와 실제 포트 불일치가 만든 차단 공백

문제가 발생한 원인을 깊이 파고들어 보니, fail2ban의 sshd jail 기본 설정에 문제가 있었습니다. fail2ban의 기본 설정 파일인 jail.conf를 살펴보면, sshd jail 항목에 port = ssh 라고 명시되어 있는 것을 발견할 수 있습니다. 여기서 'ssh'는 /etc/services 파일에 정의된 대로 기본 22번 포트를 의미합니다. 즉, fail2ban의 sshd jail은 기본적으로 22번 포트로 들어오는 SSH 공격 시도를 감지하고 차단 규칙을 적용하도록 설정되어 있었던 것입니다. 하지만 제 서버의 실제 SSH 서비스는 22022번 포트에서 동작하고 있었고, 로그인 실패 로그 또한 22022번 포트를 기준으로 기록되고 있었습니다. fail2ban 필터는 로그를 분석하여 공격 IP를 성공적으로 찾아냈을 것입니다. 하지만 jail의 port 설정이 22번으로 고정되어 있다 보니, fail2ban이 iptables를 통해 차단 규칙을 생성하더라도 그 규칙은 22번 포트에만 적용되었던 것이죠. 결과적으로 실제 공격 트래픽이 들어오는 22022번 포트는 아무런 차단 조치 없이 그대로 열려 있었던 것입니다. 비표준 포트 사용이라는 보안 강화 조치가 fail2ban의 기본 설정과 충돌하며 오히려 차단 기능을 무력화시키는 역설적인 상황이 발생한 것이 근본적인 원인이었습니다.

jail.local에서 SSHD jail 포트 명확히 지정하기

문제의 원인을 파악했으니, 해결책은 명확했습니다. fail2ban의 sshd jail이 실제 SSH 서비스 포트를 인지하도록 설정을 변경해야 했습니다. 이때 fail2ban의 기본 설정 파일인 jail.conf를 직접 수정하는 것보다는, jail.local 파일을 생성하여 원하는 설정을 오버라이드(override)하는 것이 패키지 업데이트 등으로 인해 설정이 초기화되는 것을 방지하는 좋은 방법입니다. 저는 /etc/fail2ban/jail.local 파일을 열어 다음과 같이 sshd jail 설정을 추가하거나 수정했습니다. 여기서는 port를 실제 SSH 포트인 22022로 명확히 지정하고, 필요에 따라 maxretry, findtime, bantime 등의 값도 운영 환경에 맞게 조정했습니다.maxretry는 재시도 허용 횟수, findtime은 해당 횟수를 찾는 시간 범위, bantime은 차단 지속 시간을 의미합니다. 설정을 완료한 후에는 systemctl restart fail2ban 명령으로 fail2ban 서비스를 재시작하여 변경된 설정이 적용되도록 했습니다.이제 fail2ban은 22022 포트로 들어오는 SSH 로그인 시도를 감지하고, 해당 포트에 대한 차단 규칙을 적용할 수 있게 된 것입니다. /etc/fail2ban/jail.local [sshd] enabled = true port = 22022 filter = sshd maxretry = 3 findtime = 600 bantime = 86400

설정 변경 후 즉시 확인된 차단과 재발 방지

fail2ban 서비스를 재시작하자마자 그 효과를 바로 확인할 수 있었습니다. sudo fail2ban-client status sshd 명령을 다시 실행해 보니, Banned IP 목록에 이전까지 로그에 쌓여 있던 공격 IP 주소들이 임계치를 넘어선 순서대로 13개가 즉시 등록되어 있는 것을 확인할 수 있었습니다. 그동안 수없이 시도되던 공격이 드디어 fail2ban에 의해 차단된 것이죠. 추가적으로 sudo iptables -L -n | grep 22022 명령을 통해 실제 iptables 규칙을 확인해 보니, 22022 포트에 대한 DROP 규칙들이 정확히 생성되어 있는 것을 볼 수 있었습니다. 이는 fail2ban이 22022 포트로 들어오는 트래픽을 제대로 차단하고 있다는 명확한 증거였습니다. 이후 같은 공격 IP에서 재시도가 있었지만, 서버로의 연결 자체가 차단되어 더 이상 로그인 시도 로그가 발생하지 않았습니다. fail2ban이 단순히 '돌고 있다'는 것만으로는 안심할 수 없으며, 정확한 설정으로 '제대로 막고 있는지' 확인하는 과정이 얼마나 중요한지 다시 한번 깨달았던 경험입니다. 적용 후 상태 확인 sudo systemctl restart fail2ban sudo fail2ban-client status sshd 실제 차단 규칙 확인 sudo iptables -L -n | grep 22022

마무리

fail2ban이 정상적으로 활성화되어 있다고 해서 모든 공격을 막아주고 있다고 단정해서는 안 됩니다. 특히 SSH 포트를 기본값인 22번이 아닌 다른 포트로 변경하여 사용하는 환경에서는, fail2ban의 sshd jail 설정(특히 port 항목)이 실제 서비스 포트와 일치하는지 반드시 확인해야 합니다. '돌고 있다'와 '실제로 막고 있다'는 전혀 다른 문제라는 점을 기억하시고, fail2ban-client status 명령 등으로 주기적인 상태 점검을 통해 보안 체계를 견고하게 유지하시기를 권합니다. 이 경험이 비표준 포트 사용으로 fail2ban이 제 역할을 하지 못하는 상황에 처한 분들께 도움이 되기를 바랍니다.