답변:
다른 솔루션이 있습니다. 가장 좋은 방법은 공개 / 개인 키를 사용하여 사용자를 인증하는 RSA 인증을 사용하는 것입니다.
다양한 접근 방식 (RSA 인증 포함)에 대해서는이 훌륭한 매뉴얼을 확인하십시오. http://www.la-samhna.de/library/brutessh.html
기술적이지 않은 사용자에게는 복잡하게 만들고 싶지 않기 때문에 서버 에서 세 번째 솔루션 을 사용 iptables하고 있습니다.
사용중인 솔루션은 다음과 같습니다.
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force "
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
여기에 언급 된 바와 같이 : 60 초 내에 지정된 IP 주소에서 3 개의 포트 22 연결을 허용하며 연결을 다시 허용하기 전에 후속 연결 시도없이 60 초가 소요됩니다. --rttl 옵션은 또한 패킷 일치시 데이터 그램의 TTL을 고려하여 스푸핑 된 소스 주소를 완화하기 위해 노력합니다.
언급 된 가이드에 명시된대로 화이트리스트를 사용하여 신뢰할 수있는 사용자를 다음 규칙과 분리하는 것이 좋습니다.
iptables -N SSH_WHITELIST
그런 다음 신뢰할 수있는 호스트를 추가하십시오.
iptables -A SSH_WHITELIST -s $TRUSTED_HOST -m recent --remove --name SSH -j ACCEPT
그리고 나서 규칙을 만드십시오.
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_WHITELIST
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j ULOG --ulog-prefix SSH_brute_force
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
서버에 매일 1 ~ 2의 비율로 무차별 공격을받습니다. 내가 설치 한 denyhosts (: denyhosts 우분투 패키지). 매우 간단하지만 효과적인 도구입니다. 기본적으로 정기적으로 로그를 검사하여 무차별 대입 공격을 탐지하고 이러한 공격이 발생한 위치에서 IP를 /etc/hosts.deny 파일로 보냅니다. 다시는 소식을 듣지 못하므로 부하를 상당히 줄여야합니다. 구성 파일 /etc/denyhosts.conf를 통해 구성 할 수있어 공격을 구성하는 잘못된 시도 횟수 등의 문제를 조정할 수 있습니다.
투명하게 작동하기 때문에 진행중인 상황 (이메일 알림 : '아하, 별다른 공격이 막혔습니다!')을 쉽게 확인할 수 있으며 사용자가 암호를 반복적으로 잘못 입력하여 실수를 취소 할 수 있습니다.
물론 이전에 다른 인증 방법으로 전환하는 것에 대해 언급 한 모든 내용이 적용되지만 요구 사항이 사용자의 요구 사항과 일치하지 않는 경우가 있습니다.
또한 iptables의 새로운 연결 속도 제한이 hosts.deny를 통한 액세스를 거부하는 것이 더 좋습니다. 따라서 fail2ban도 살펴보십시오. 그러나 ssh brute-force가 주요 관심사라는 것을 알고 있다면 (수동으로 /var/log/auth.log를 통해 확인)이 매우 쉽고 영향이 적은 도구를 사용하십시오.
Mar 27 10:28:43 smartfood sshd[17017]: Failed password for root from 218.15.136.38 port 33119 ssh2 Mar 27 10:28:47 smartfood sshd[17019]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=218.15.136.38 user=root공격을 나타 냅니까?
knockd을 구현하는 데 사용recent와 hashlimitmatch를 사용 하여 연속적인 SSH 시도를 제한하십시오우선 암호를 사용하지 말고 키를 대신 사용하십시오. 비밀번호를 사용할 필요가 없습니다. 이것이 효과가있는 경우 OpenSSH 서버가 비밀번호 로그인에 반응하지 않도록 구성 할 수 있습니다.
https://help.ubuntu.com/10.04/serverguide/C/openssh-server.html
fail2ban을 사용하면 옵션이 될 수 있습니다.
fail2ban의 대안은 CSF : ConfigServer Security & Firewall 입니다.
LFD : 로그인 실패 데몬 (Login Failure Daemon)은 다양한 서비스에서 여러 번의 로그인 시도 실패를 감지 할 수 있으며 문제의 IP 주소를 일시적 또는 영구적으로 차단합니다.
또한 홍수 공격에 대비하고 침입을 탐지 할 수있는 다른 옵션이 있습니다.
단점 :
전세계에 SSH 서비스를 허용 하시겠습니까? 아니면 특정 장소의 팀원에게만? 나의 대답은 당신의 도전의 심각성에 따라 조금씩 다릅니다.
두 경우 모두 SSH 서버가 루트 사용자의 비밀번호 로그인을 허용하지 않도록해야합니다.
내 시스템에는이 설정이 있습니다
PermitRootLogin without-password
그러나 나는 새로운 우분투에서 그들이 가지고있는 것을 알았습니다.
PermitRootLogin prohibit-password
"man sshd_config"를 읽으면이 최신 "비밀번호"가 동일한 의미를 가지며 의미가 더 분명하다는 것을 의미합니다. 일부 Linux 시스템에서는 기본값이 아니지만 아마도 있어야합니다.
자, 문제에 대해 시스템 서버는 특정 장소의 일부 사용자 만 있습니까? 이 작업을 수행!
/etc/hosts.deny를 편집하고 삽입하십시오
모두 : 모두
그런 다음 /etc/hosts.allow를 편집하고 SSH 사용을 허용하려는 IP 번호 또는 범위를 나열하십시오. 111.222.65.101에서 111.222.65.255와 같은 IP 번호를 가진 모든 시스템을 허용하려면 hosts.allow에 이와 같은 항목을 입력하기 때문에 약간 혼란스러운 표기법이 있습니다.
ALL: 127.0.0.1
sshd: 111.222.65.
sshdfwd-X11: 111.222.65.
그것은 무차별적이고 강력한 솔루션입니다. IP 범위로 사용자를 열거 할 수 있다면 그렇게하십시오!
이 솔루션은 IP 테이블이 생성되기 전에 존재했지만 관리하기가 훨씬 쉽지만 IP 테이블 루틴은 hosts.allow 및 hosts로 구동되는 프로그램보다 빨리 적을 발견하기 때문에 IP 테이블 솔루션만큼 좋지 않습니다. . 거부 그러나 이것은 SSH뿐만 아니라 많은 문제를 해결하는 확실한 방법입니다.
자신이 만든 문제에 유의하십시오. FTP 서버, 웹 서버 등을 열려면 호스트에서 항목을 허용해야합니다.
iptables와 방화벽을 사용하여 동일한 기본 목적을 달성 할 수 있습니다. 어떤 의미에서 이것은 외부 경계에서 적을 차단하기 때문에 선호되는 솔루션입니다. 우분투에는 "ufw"(복잡한 방화벽)가 있고 "man ufw"에는 많은 예가 있습니다. 차라리 멋진 GUI가 필요합니다. 항상 이것을 할 필요는 없습니다. 어쩌면 다른 사람들이 지금 있다면 말해 줄 수 있습니다.
일부 사용자가 다양한 서버에 대해 다른 ssh 키를 누적하면 또 다른 좌절의 원인이 발생합니다. 약 12 개의 다른 프로젝트에 대한 SSH 키가 있으므로 공개 키가 너무 많아서 ssh가 실패합니다 ( "ssh -o PubkeyAuthentication = false"가 필요하거나 .ssh / config 파일에 항목을 작성해야합니다. PITA 임).
Centos Linux 시스템에서 denyhosts 패키지를 삭제하고 fail2ban 만 제공한다는 것을 알았습니다. denyhosts는 귀찮은 사용자 / IP 범위 목록을 작성한 다음 hosts.deny에 있었기 때문에 좋아했습니다. 대신 fail2ban을 설치했는데 괜찮습니다. 내 이해는 서버의 외부 가장자리에서 이러한 나쁜 사용자를 차단하기 때문에 fail2ban과 같은 ip 테이블 기반 차단기가 실제로 더 낫다는 것입니다. Denyhosts는 2 차 레벨에서 작동합니다. 적들이 iptables를 지나면 sshd 데몬에 의해 거부됩니다.
두 프로그램 모두 암호를 잊어 버려 로그인을 몇 번 시도하면 사용자가 감옥에서 나오게하는 것이 약간 지루합니다. 로그인 실수를했을 때 다시 로그인하는 것은 약간 어렵습니다. 포인트 앤 클릭 GUI를 사용하여 사람들을 다시 지정하고 다시 방문 할 수 있다고 생각했을 것입니다. 나는 몇 달마다 이것을해야하고 시간 사이의 방법을 잊어 버려서 웹 페이지 http://pj.freefaculty.org/blog/?p=301 에 나 자신을위한 지침을 작성했습니다 .