많은 관리자가 기본 SSH 포트를 변경한 것으로 나타났습니다. 이렇게 하는 타당한 이유가 있나요?
답변1
가장 가능성이 높은 이유는 사람들이 찾을 수 있는 SSH 로그인을 무작위로 무차별 공격하는 것을 더 어렵게 만들기 위한 것입니다. 내 인터넷 연결 컴퓨터는 기본 SSH 포트를 사용하며 내 로그는 다음과 같은 콘텐츠로 채워지곤 했습니다(실제 로그 파일에서 발췌).
sshd[16359]: Invalid user test from 92.241.180.96
sshd[16428]: Invalid user oracle from 92.241.180.96
sshd[16496]: Invalid user backup from 92.241.180.96
sshd[16556]: Invalid user ftpuser from 92.241.180.96
sshd[16612]: Invalid user nagios from 92.241.180.96
sshd[16649]: Invalid user student from 92.241.180.96
sshd[16689]: Invalid user tomcat from 92.241.180.96
sshd[16713]: Invalid user test1 from 92.241.180.96
sshd[16742]: Invalid user test from 92.241.180.96
sshd[16746]: Invalid user cyrus from 92.241.180.96
sshd[16774]: Invalid user temp from 92.241.180.96
sshd[16790]: Invalid user postgres from 92.241.180.96
sshd[16806]: Invalid user samba from 92.241.180.96
요즘 사용하고 있어요호스트 거부여러 번 검증에 실패한 IP를 차단하지만 실제로 포트를 전환하는 것도 마찬가지로 쉽습니다. 이러한 모든 무차별 대입 공격은 sshd가 다른 포트에서 수신 대기 중인지 확인하는 것을 귀찮게 하지 않으며 단지 사용자가 그렇다고 가정할 것입니다. 특정 포트를 실행하지 않고 계속 진행
답변2
아니요, 이것은모호한 보안전술.
sshd 설정이 포트 22만 시도하는 멍청한 스크립트 키디를 처리할 만큼 강력하지 않다면 어쨌든 문제가 발생할 것입니다.
보다 합리적인 응답은 다음과 같습니다.
- 사용자가 추측/무차별 대입이 어려운 좋은 비밀번호를 사용하는지 확인하세요.
- 비밀번호 인증을 비활성화하고(적어도 중요한 계정의 경우) 공개 키 인증만 사용합니다.
- SSH 보안 문제 및 업그레이드에 주의하세요
어떤 사람들은 sshd가 시스템 로그에 기록하는 소음 때문에 짜증을 낼 수도 있습니다. 예를 들면 다음과 같습니다.
Jan 02 21:24:24 example.org sshd[28396]: Invalid user guest from 212.129.23.128
Jan 02 21:24:24 example.org sshd[28396]: input_userauth_request: invalid user guest [preauth]
Jan 02 21:24:24 example.org sshd[28396]: error: Received disconnect from 212.129.23.128: 3: com.jcraft.jsch.JSchException: Auth fail [preauth]
Jan 02 21:24:24 example.org sshd[28398]: Invalid user ubnt from 212.129.23.128
Jan 02 21:24:24 example.org sshd[28398]: input_userauth_request: invalid user ubnt [preauth]
Jan 02 21:24:24 example.org sshd[28398]: error: Received disconnect from 212.129.23.128: 3: com.jcraft.jsch.JSchException: Auth fail [preauth
그런 다음 sshd 포트를 숨기거나 자동 차단 솔루션(예: DenyHosts, Fail2ban 또는 BlockHosts)을 사용하여신호 대 잡음비다시.
그러나 더 나은 대안이 존재합니다. 예를 들어, sshd 로그에 노이즈만 기록되고 /var/log/sshd-attempts.log
신호(즉, 나머지 sshd 로그 메시지)가 기록 되도록 syslog 데몬을 구성할 수 있습니다 /var/log/messages
.
보안 관련 시스템의 복잡성이 증가하면 보안도 복잡해지기 때문에 자동화된 차단 도구의 배포는 신중하게 고려해야 합니다.위험~의개발하다. 사실 지난 몇 년 동안 여러 가지 일이 있었습니다.서비스 거부 취약점각 보고서마다호스트 거부,실패 2 금지그리고블록 호스트.
답변3
SSH 포트 변경은 주로보안 극장. 뭔가 이루어졌다는 막연한 느낌을 줍니다. 현관 매트 아래에 SSH 포트를 숨겼습니다.
인터넷에서 SSH 서버를 실행하는 경우 어리석게도 취약한 비밀번호를 찾는 봇의 로그인 시도 실패를 로그에서 많이 볼 수 있습니다.약한 결합이전 버전의 서버에서 알려진 취약점. 실패한 시도는 다음과 같습니다.실패노력하다. 이는 귀하의 취약성을 평가하는 것과 전혀 관련이 없습니다. 걱정해야 할 것은 성공적인 침입 시도이지만 로그에는 해당 내용이 표시되지 않습니다.
기본 포트를 변경하면 이러한 봇의 공격 횟수가 줄어들지만, 적절한 보안 조치(정기적인 보안 업데이트 적용, 합리적으로 강력한 비밀번호 또는 비밀번호 인증 비활성화)를 통해 차단될 가장 정교하지 않은 공격자만 좌절시킬 것입니다. 유일한 이점은 로그 볼륨이 줄어든다는 것입니다. 이것이 문제라면 다음과 같은 것을 고려하십시오.호스트 거부또는실패 2 금지대신 연결 속도를 제한하면 대역폭에도 도움이 됩니다.
기본 포트를 변경하면 한 가지 큰 단점이 있습니다. 즉, 방화벽 뒤에서 로그인할 가능성이 낮아집니다. 방화벽은 임의의 다른 포트보다 서비스가 기본 포트를 통과하도록 허용할 가능성이 더 높습니다. HTTPS 서버를 실행하지 않는 경우 SSH가 포트 443에서도 수신하도록 하는 것을 고려하십시오(또는 포트 443에서 들어오는 TCP 요청을 포트 22로 리디렉션). 일부 방화벽은 포트 443에서 트래픽을 허용하므로 디코딩할 수 없습니다. HTTPS.