답변:
일부 사람들이 주장하는 것만 큼 유용하지는 않지만, 많은 무차별 강제 로그인 시도가 SSH가 다른 곳에서 수신 대기하는지 확인하기 위해 스캔하는 대신 기본 포트만 사용하기 때문에 최소한 로그 파일에 미치는 영향을 줄입니다. 일부 공격은 다른 곳에서 SSH를 검색하므로 은색 총알이 아닙니다.
서버가 단지 프로젝트의 요구를 충족시키는 것이 아니라 일종의 공유 호스트가 될 경우, 기본이 아닌 포트를 사용하는 것은 사용자에게 반복해서 설명해야하기 때문에 힘들 수 있습니다. 잊어 버렸을 때 클라이언트 프로그램이 포트 22에 연결하지 못한 경우
비표준 포트에서 SSH의 또 다른 문제점은 제한적인 발신 필터 세트가있는 클라이언트가 발생하는 경우입니다.이 필터는 예를 들어 포트 22, 53, 80과 같은 필터 만 허용하므로 사용자 정의 포트에 연결할 수 없습니다. 443은 새로운 발신 연결의 대상이됩니다. 이것은 흔하지 않지만 확실히 들어 본 적이 없습니다. 비슷한 문제로, 일부 ISP는 P2P 연결 및 스로틀 (또는 블록)을 숨기려고 시도하는 것으로 일반적으로 예상되는 포트 (포트 443 또는 HTTPS, 22의 경우 등) 이외의 포트에서 암호화 된 트래픽을 볼 수 있습니다. 불편한 연결.
편의상 표준 포트에 SSH를 개인적으로 유지합니다. 일반적인 예방 조치 (강력한 암호 / 키 정책, 루트 로그인 제한 등)를 취하는 한 걱정할 필요가 없으며 무차별 대입 공격에 부딪 칠 때 로그 파일 증가 문제는 다음과 같은 도구를 사용하여 완화 할 수 있습니다. fial2ban으로 지정된 시간 간격에 잘못된 인증 자격 증명을 너무 많이 제공하는 호스트를 일시적으로 차단합니다.
선택한 포트가 무엇이든, 22에서 멀어지면 1024 미만인지 확인하십시오. 기본 구성의 대부분의 유닉스 유사 설정에서는 루트 (또는 루트 그룹의 사용자) 만 1024 이하의 포트에서 청취 할 수 있습니다. 그러나 모든 사용자는 더 높은 포트에서들을 수 있습니다. 더 높은 포트에서 SSH를 실행하면 불량 (또는 해킹 된) 사용자가 SSH 데몬을 중단하고 자체 또는 프록시로 교체 할 가능성이 높아집니다.
모호함을 통한 단순하지만 놀랍도록 효과적인 보안 형식입니다 .
SSH 서버가 포트 22에 없으면 전체 인터넷을 검색하여 기본 계정에서 약한 암호를 찾는 사람들이 찾을 가능성이 훨씬 적습니다. 전체 네트워크를 스캔하는 경우 SSH 서버를 찾기 위해 64k 가능한 모든 포트를 검사 할 여유가 없습니다.
그러나 누군가가 당신을 적극적으로 목표로 삼고 있다면 간단한 일회성 nmap스캔으로 실제로 실행중인 포트가 표시 되므로 이점이 없습니다 .
무차별 공격을 피하려면 항상 몇 가지 단계를 수행해야합니다.
예. 모든 무차별 대입 공격을 피하고 로그를 명확하게 유지하는 데 도움이되므로 유용합니다. :)
당신에게 달려있는 포트 번호에 관해서는, 회사가 1291을 상당히 자주 사용하는 것을 보았습니다. 스크립트 중 일부를 피하기 위해 더 높은 것을 사용합니다.
루트 ssh 로그인을 허용하지 않고 포트 번호 및 fail2ban과 같은 것을 변경하면 황금색이어야합니다. 좋은 측정을 위해 iptables를 추가하고 최신 정보를 유지하면 어떤 종류의 문제도 발생하지 않아야합니다.
비표준 ssh 포트를 사용하려면 자세한 설명과 설명서가 필요하고 "로그인 할 수 없습니다"이메일에 응답해야합니다.
비표준 포트 에서 sshd를 실행 하면 발생하는 문제보다 다음과 같은 이점 이 더 중요합니다.
또한, 정말로 불쾌감을 원한다면 표준 포트 22에서 가짜 sshd ( DenyUsers * 포함 )를 항상 실행할 수 있고 일반 sshd는 포트 54321에서 실행됩니다. 이렇게하면 모든 봇과 침입자 -wannabes가 영원히 지속될 것입니다 아무도 실제 sshd 서비스 를 찾으려고 생각하지 않기 때문에 모든 로그인을 거부하는 서비스에 로그인하십시오 .
내 2 센트
"보안"사유로 이것을하는 것은 허위입니다. 보안이 아닌 모호한 보안의 가장 좋은 예입니다.
로그를 조금 더 가볍고 깨끗하게 유지하려면 포트 노킹 / 스크립트 익히는 무차별 대입 시도가 많지 않으므로 유용합니다.
무차별 암호 추측 공격을 시도하는 스크립트 봇은 일반적으로 포트 22에 중점을 두므로 포트를 변경하면 일반적으로 포트가 제거됩니다. 비표준 포트에 연결하기 위해 ssh 클라이언트를 구성해야하는 어려움과 그 위험을 완화하는 가치의 균형을 맞출 필요가 있습니다 (많은 사용자가 연결되어 있지 않아도 큰 어려움은 아닙니다).
또는 암호 인증을 끄고 대신 RSA 키 인증을 요구하여 무차별 위험을 완화 할 수 있습니다.
나는 일반적으로 SSHD의 포트를 변경하지 않으므로 다른 번호를 제안 할 수는 없지만 일반적으로 사용되는 포트 목록 을 확인 하여 다른 번호 (예 : 다른 것에 의해 사용되지 않아 스캔 될 수있는 번호)를 찾으십시오. .
모호성을 통한 보안은 쓸모없는 것으로 판명되었습니다. 일반적으로 위에서 언급 한 모든 이유 (재구성의 클라이언트 문제, 방화벽 및 프록시 문제 등)에 대해 표준 포트를 사용하여 ssh 액세스를 구성합니다.
그 외에도 항상 루트 로그인 및 비밀번호 인증을 비활성화하고 마지막 단계에서 fail2ban 을 사용 하여 syslog에서 성가신 메시지를 제거합니다. 데비안 / 우분투에서는 입력하는 것만 큼 간단합니다 aptitude install fail2ban. 기본 구성은 꽤 잘 작동하지만 일반적으로 금지 시간이 길고 (최소 1 일) 인증 시도가 2 회 실패하면 금지에 대한 트리거로 일부 매개 변수를 더 제한적으로 조정합니다.
SSH 포트를 변경할 때 가장 많이 보호하는 것은 표준 사용자 이름 / 암호를 사용하여 액세스를 시도하는 자동 스캔입니다. 암호 정책이 빡빡하면 걱정할 필요가 없습니다. 그들.
서버에 대한 비밀번호 로그인을 비활성화하면 (권장) SSH 포트를 변경하는 것은 전혀 쓸모가 없습니다. 암호 로그인을 비활성화하고 키 기반 인증을 요구함으로써 무차별 암호 시도의 가능성을 제거하므로 포트 번호를 불문하고 아무것도 얻지 못합니다.
암호 기반 인증을 계속 허용하는 경우, 무차별 대입 시도 나 내 경험상 시스템 실행시 암호를 입력 할 때 암호가 손상 될 가능성이 있습니다. 키로거.
man ssh-keygen많은 정보를 참조하십시오 .
답은 아니지만 의견이 너무 길어서이 CW를 작성하겠습니다.
나는 이것에 대해 잠시 동안 생각해 왔고 Alnitak의 대답에 대한 언급에서 Juliano가 말한 것에 많은 진실이 있다는 결론에 도달했습니다. 그럼에도 불구하고 포트 22에서 SSH를 실행하면 SSH에 대한 공격을 시작하기가 너무 쉽다는 것을 알았습니다.
이 문제를 해결하기 위해 포트 22에서 내부 SSH 서버를 실행하고 방화벽을 사용하여 대상 컴퓨터에서 22 포트로 포트를 전달합니다. Juliano가 지적한 것처럼 낮은 포트의 보안을 유지하면서 모호함을 통해 보안을 제공합니다.
모호성을 통한 보안은 내가 일반적으로 구독하는 원칙이 아니며 간단한 포트 스캔으로 대상 포트를 표시하여 모호성을 무가치하게 만드는 경우가 종종 있습니다. 이 문제를 해결하려면 직장과 가정에서 방화벽 (Smoothwall Express)을 Snort 경고에 의해 트리거되는 Guardian Active Response라는 스크립트를 사용하십시오. 관찰을 통해 동일한 소스에서 3 개 이상의 다른 포트를 사용하면 사전 설정 재설정 시간까지 패킷이 삭제된다는 것을 알 수 있습니다. 이로 인해 포트 스캔을 실행하기가 다소 어려워지고 시간이 많이 걸리므로 실제로 모호한 부분을 모호하게 만듭니다. 실제로 과거에 여러 번 종료되어 소스 (집 또는 사무실) IP 주소에 대한 제외를 설정했습니다.
당신이 가진 문제는 방화벽이 특정 IP의 연결만을 허용하도록 설정되어 있고, 보스가 외출 할 때 특정 IP를 여는 데 지쳤다는 것입니다. 방화벽에서 특정 IP를 잠그는 경우에는 문제가 될 수 있습니다.
내가 생각하는 두 가지. 포트를 변경하면 자동 공격으로부터 보호됩니다. 그것에 관한 것이지만, 그것은 평균 공격 트래픽의 큰 부분입니다 ... 자동 스크립트는 네트워크를 스캔합니다. 기본 포트를 변경하면 이러한 공격은 아무 것도 없어야합니다. 따라서 그 점에서 의미가 있습니다. 그러나 공격자가 Nessus 또는 NMAP에서 스캔하여 자신을 미워하는 특별한 작은 친구가있는 경우 사용중인 포트를 확인할 수 있기 때문에 직접 공격에 대해서는 아무런 영향을 미치지 않습니다.
둘째, UNIX와 유사한 서버를 사용하는 경우 Denyhosts와 같은 유틸리티를 설치하여 공격을 중지 할 수 있습니다. 거부 호스트를 설치하면 잘못된 로그인 시도를 모니터하고 실패한 시도 (수를 결정한 횟수)는 지정한 기간 동안 IP를 금지합니다. Denyhosts는 다른 Denyhost 호스트와 대화하고 차단 목록을 전달할 수 있으므로 공격자가 Montana의 Fred의 Linux 시스템에서 잠기면 시스템에서 해당 IP를 차단할 수 있습니다. 사용자가 비밀번호를 기억하는 한 매우 유용합니다.
모두 사용 시나리오에 따라 다릅니다. SSH / SCP의 연결 포트를 변경하기위한 "엉덩이에 통증이있는"프로그램은 몇 개입니까 (허용되지 않거나 통증이있는 경우 공급 업체 변경을 개인적으로 고려해야합니다). 그것이 잠재적 인 두려움이라면 그것이 문제가 아니라고 말할 것입니다. 그리고 이것은 당신의 상사입니다. 많은 sysadmins가 SSH 포트를 뒤집기 때문에 완전히 엉망이 아닌 것을 요구합니다. 자동화 된 스캔으로 인한 주변 소음 감소.)
정리-포트를 변경하면 자동화 된 스크립트와 대부분의 나쁜 트래픽이 차단됩니다. 지시 된 공격자를 멈추지 않습니다. 자동 금지 유틸리티도 설치해보십시오. 계층 구조의 보안은 올바르게 수행해도 문제를 일으키지 않으며 포트를 변경하면 대부분의 상황에서 아파하는 것보다 더 많은 도움이됩니다.
5 년 이상 포트> 1024에서 SSH를 실행 해 왔습니다. 그 이후로, 나는 내 자신의 로그 파일에서 포트가 시도 할 수있는 것을 보지 못했습니다. 포트> 1024를 사용하여 관리하는 서버가 있습니다.
1024보다 큰 포트에서 실행되는 많은 SSH 서버에는 자체 웹 사이트가 있으며 매우 유명합니다.
SSH 서버가 내 회사에서 실행되는 경우 서버에 해킹을 시도 할 수 있도록 이미 해당 서버의 IP 주소를 여기에 게시했을 수 있습니다. 불행히도 SSH 서버는 내 것이 아닙니다. ;-)
그러나 보안을 유지하기 위해 설정해야 할 다른 사항이 있습니다. SSH> 1024만으로는 충분하지 않습니다. 포트 번호는 / etc / services에 없어야하며 포트 전달 (예 : 포트 1124-> 22)을 사용해야하며 루트에 대한 직접 액세스는 비활성화되어야합니다.
따라서 논쟁하고 싶다면 몇 년 동안 1024보다 큰 포트에서 SSH를 실행하는 것이 좋습니다.
p / s : 1124는 내 SSH 포트 번호가 아닙니다. 하하.
"모호함을 통한 보안"군중의 호응에 관계없이 훌륭하게 작동합니다.
바보 같은 토끼, 모든 보안은 모호함을 통한 보안입니다. 모호한 암호화 프로토콜 Z [DNA 샘플, 공유 키 및 인간 암호로 실제로 입력 할 수 없음]가 필요하다는 사실이 실제로 안전하지 않다고 생각하기 때문입니다. 진실은 모든 보안 조치가 사용자의 확률과 가정에 의존한다는 것입니다. 그 가정을 악용하는 방법을 알면 너무 나쁘지만 거기에 있습니다.
어쨌든,
우리는 수년 동안 a) 연결 시도 속도 제한 (단, 설정 방법, ssh 구성에서 dunno) 및 b) 사전 공격을 실행하는 모든 호스트를 금지하는 스크립트를 X는 Y 분 안에 틀린 추측입니다. 우리는 호스트가 일정 기간 동안 연결을하지 못하도록하여 변화하는 네트워크의 토폴로지에보다 쉽게 적응할 수 있도록합니다.
암호가 충분히 복잡하고 15 분 안에 3 번만 시도 할 수 있다면 걱정할 것이 없습니다. 분산 공격을 감시하는 것도 어렵지 않습니다. 우리는 일반적으로 서브넷과 IP를 기준으로 이러한 종류의 것을 배제합니다.
마지막으로, 방화벽 규칙을 수정하여 포트에 연결할 수있는 비밀 다람쥐 방법 만 있으면됩니다. smtp, web, magic dns query 등 무엇이든 가능합니다. SecurID 또는 Wikid와 같은 것들이 더 많은 정보를 제 3 자에게 넘겨줍니다. 그리고 제 3자를 통해 안전한 인증서를 시작하지 마십시오.