실패한 로그인 시도를 차단하는 노력이 가치가 있습니까?

실패한 로그인 시도를 차단하는 노력이 가치가 있습니까?

달릴 가치가 있는 걸까실패2금지,SSHD필터 또는 로그인을 시도하고 실패하는 IP 주소를 블랙리스트에 추가하는 유사한 도구는 무엇입니까?

논쟁하는 걸 본 적이 있어요이는 "적절하게 보안된" 서버의 보안 극장입니다. 하지만 스크립트 키디가 목록의 다음 서버로 이동하게 만드는 것 같습니다.

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

업데이트: 비밀번호 무차별 추측에 대한 댓글이 많습니다. 저는 이에 대해 걱정하지 않는다고 언급했습니다. 아마도 좀 더 구체적으로 설명하고 키 기반 SSH 로그인만 허용하는 서버에 대해 fall2ban이 어떤 이점을 갖는지 물어봤어야 했습니다.

답변1

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

  1. 합법적인 사용자는 때때로 자신의 비밀번호를 잊어버립니다. 내 서버에서 합법적인 사용자를 금지하여 해당 사용자의 계정을 수동으로 다시 활성화하도록 강요하고 싶지 않습니다(또는 더 나쁘게는 100/1000개의 금지된 IP 주소 중 어느 것이 해당 사용자의 것인지 알아내려고 시도하는 것입니다).
  2. IP 주소는 사용자에게 좋은 식별자가 아닙니다. 단일 IP 뒤에 여러 사용자가 있는 경우(예: 500대의 학생 컴퓨터에서 NAT를 실행하는 학교) 단일 사용자가 몇 가지 잘못된 추측을 하면 어려움을 겪을 수 있습니다. 동시에 내가 본 비밀번호 추측 시도의 대부분이 분산되었습니다.

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

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회 이상의 연결 시도를 방지합니다. 나머지는 비밀번호가 합리적으로 강력한지 확인하여 처리할 수 있습니다. 보안 수준이 높은 서버에서는 사용자에게 공개 키 인증을 사용하도록 강제하는 것이 추측을 중지하는 또 다른 방법입니다.

답변2

fall2ban과 같은 도구는 불필요한 네트워크 트래픽을 줄이고 로그 파일을 조금 더 작고 깨끗하게 유지하는 데 도움이 됩니다. 큰 보안 문제는 아니지만 시스템 관리자의 삶을 좀 더 쉽게 만들어줍니다. 그렇기 때문에 감당할 수 있는 시스템에서는 Fail2ban을 사용하는 것이 좋습니다.

답변3

소음을 줄이는 것뿐만 아니라 대부분의 SSH 공격은 비밀번호에 대해 무차별 대입 추측을 시도합니다. 따라서 SSH 시도에 실패한 경우가 많이 있지만 2034번째 시도를 할 때쯤에는 유효한 사용자 이름/비밀번호를 얻을 수도 있습니다.

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

답변4

죄송합니다. sshd가 비밀번호 인증 시도를 거부하면 서버가 제대로 보호된 것입니다.

PasswordAuthentication no

관련 정보