실패한 로그인 시도를 차단할 가치가 있습니까?

fail2ban , sshdfilter 또는 이와 유사한 도구를 실행하는 것이 가치가 있습니까?

나는 이것이 "적절하게 보안 된"서버의 보안관이라고 주장 하는 것을 보았다 . 그러나 아마도 스크립트 키디가 목록의 다음 서버로 넘어갈 수 있다고 생각합니다.

내 서버가 "적절하게 보안"되어 있고 무차별 대입 공격이 실제로 성공 할까 걱정하지 않습니다. 이러한 도구가 단순히 내 로그 파일을 깨끗하게 유지합니까, 아니면 무차별 대입 공격 시도를 차단하는 데 가치있는 이점이 있습니까?

업데이트 : 암호의 무차별 추측에 대한 많은 의견-나는 이것에 대해 걱정하지 않는다고 언급했습니다. 아마도 더 구체적이고 fail2ban이 키 기반 ssh 로그인 만 허용하는 서버에 어떤 이점이 있는지 물었을 것입니다.

로그인 제한 속도 시도는 일부 고속 암호 추측 공격을 방지하는 쉬운 방법입니다. 그러나 분산 공격을 제한하기는 어렵고 많은 주 또는 몇 달에 걸쳐 낮은 속도로 실행됩니다. 저는 개인적으로 fail2ban과 같은 자동 응답 도구를 사용하지 않는 것을 선호합니다. 그리고 이것은 두 가지 이유 때문입니다.

1. 합법적 인 사용자는 때때로 자신의 암호를 잊어 버립니다. 서버에서 합법적 인 사용자를 금지하고 싶지 않으므로 수동으로 계정을 다시 활성화해야합니다 (또는 더 나쁜 경우 100/1000의 금지 된 IP 주소 중 자신의 IP 주소를 파악하려고 시도).
2. IP 주소는 사용자에게 좋은 식별자가 아닙니다. 단일 IP 뒤에 여러 명의 사용자가있는 경우 (예 : 500 대의 학생 컴퓨터에서 NAT를 실행하는 학교) 약간의 추측 만해도 한 명의 사용자가 고통의 세계에 빠질 수 있습니다. 동시에 내가 본 암호 추측 시도의 대부분은 배포됩니다.

따라서 fail2ban (및 유사한 자동 응답 도구)을 무차별 대입 공격으로부터 서버를 보호하는 데 매우 적합한 방법이라고 생각하지 않습니다. 로그 스팸을 줄이기 위해 설정 한 간단한 IPTables 규칙 (대부분의 Linux 서버에 있음)은 다음과 같습니다.

iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP

60 초 동안 단일 IP에서 ssh 로의 4 회 이상의 연결 시도를 방지합니다. 나머지는 암호가 합리적으로 강화되어 처리 할 수 ​​있습니다. 보안 수준이 높은 서버에서는 사용자가 공개 키 인증을 사용하도록하는 것이 추측을 멈추는 또 다른 방법입니다.

fail2ban과 같은 도구는 불필요한 네트워크 트래픽을 줄이고 로그 파일을 조금 작고 깨끗하게 유지하는 데 도움이됩니다. 그것은 큰 보안 치료는 아니지만 sysadmin 생활을 조금 더 쉽게 만듭니다. 그래서 여유가있는 시스템에서 fail2ban을 사용하는 것이 좋습니다.

소음을 줄이는 것만이 아닙니다. 대부분의 ssh 공격은 암호에 대한 추측을 무차별하게 시도합니다. 따라서 실패한 ssh 시도가 많이 있지만 2034 번째 시도가 이루어질 때 유효한 사용자 이름 / 암호를 얻을 수 있습니다.

다른 접근법과 비교하여 fail2ban의 좋은 점은 유효한 연결 시도에 최소한의 영향을 미친다는 것입니다.

네트워크를 거부 공격으로부터 어느 정도 저장하고 장애 처리 오버 헤드를 절약합니다.

스크립트 키즈 목록에서 가장 약한 서버가 아닌 것은 항상 좋은 것입니다.

죄송하지만, sshd가 비밀번호 인증 시도를 거부하면 서버가 올바르게 보호되었다고 말하고 싶습니다.

PasswordAuthentication no