이 구성을 사용하면 컨테이너/docker/VM이 로컬에서 fail2ban을 실행하는 동시에 이 정보를 중앙 fail2ban 서버로 전달합니다. 중앙 서버는 수집된 모든 IP를 txt 형식의 banlist로 제공하도록 할 수 있습니다. 예를 들어: https://fail2ban.YourDomain.com/banned.txt
그런 다음 pfsense 방화벽이 이 banlist를 구독하도록 설정할 수 있으며, 다른 pfsense 라우터와도 목록을 공유할 수 있습니다. 이렇게 하면 한 애플리케이션에 침입을 시도하면 모든 곳에서 차단됩니다. 이 방식은 수년간 저에게 잘 작동해 왔습니다.
discourse에 이를 구현하기 위해 제가 필요한 것은 잘못된 로그인 시도가 있을 때 discourse가 로그 파일에 항목을 기록하게 하는 것뿐입니다
NGINX 로그
간혹 NGINX 로그에 유용한 정보가 포함될 수 있습니다. 위치는 다음과 같습니다:
cd /var/discourse
./launcher enter app
cd /var/log/nginx
해당 디렉터리에는 access.log와 error.log 파일 및 회전된 압축 파일들이 있습니다. less access.log.2.gz 명령을 실행하면 자동으로 압축을 해제하여 로그 파일을 표시해 줍니다.
이 디렉터리는 호스트의 /var/discourse/shared/standalone/log/var-log/nginx 경로에서도 접근할 수 있습니다.
불행히도 nginx의 error.log와 access.log 파일에는 잘못된 로그인 시도가 기록되지 않습니다.
정의상 잘못된 로그인은 에러 200입니다. 물론 앱의 내부 에러로 처리되고, 나중에 403 에러나 복구 링크 전송 같은 다른 결과를 생성할 수는 있지만, 즉시 그런 일이 일어나서는 안 되며 그럴 수도 없습니다.
Fail2ban은 좋은 도구이지만 과대평가되고 있습니다. 도커는 모든 것을 더 어렵게 만들므로 잊어버리기로 합시다. 하지만 VPS의 iptables를 우회할 수 있다는 사실 자체가 제게는 정말로 혼란스러운 문제입니다. 하지만 봇들은 보통 3회 시도마다 IP를 변경하는 경향이 있어, 순수한 로그인 브루트포스 공격에 대해 Fail2ban은 무력해집니다.
스크립트 키디는 물론 또 다른 이야기입니다. 그들은 찾은 모든 것을 복사&붙여넣기하고, 살짝 바꿔본 후 IP를 건드리지 않습니다. 그런 경우 Fail2ban은 그들을 막을 수 있지만, 그들은 거의 해를 끼치지 못하고 부하를 증가시킬 뿐입니다. 즉각적인 플러드가 있을 때의 실제 문제는 스크립트 키디의 수입니다.
하지만 VPS가 그런 상황을 처리할 수 있는 한 그것은 중요하지 않습니다. 지금은 2023년이고, 대부분 그 무책임한 녀석들은 디스코스 사이트에서 워드프레스의 오래된 취약점을 노리고 있습니다.
하지만 일상적인 위협이 아니더라도, 끊임없는 로그인을 막을 논리가 있어야 한다고 생각합니다.
