Der wahrscheinlichste Grund ist, es den Leuten schwerer zu machen, nach dem Zufallsprinzip SSH-Anmeldungen zu erzwingen, die sie finden können. Mein mit dem Internet verbundener Computer verwendet den Standard-SSH-Port, und meine Protokolle waren mit solchen Dingen gefüllt (Auszug aus einer tatsächlichen Protokolldatei):
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
In diesen Tagen verwende ich DenyHosts , um IPs zu blockieren, die sich nicht zu oft authentifizieren, aber es ist wahrscheinlich genauso einfach, nur die Ports zu wechseln. Praktisch alle Brute-Force-Angriffe dieser Art werden sich nicht darum kümmern, zu scannen, ob Ihr SSHD an einem anderen Port empfangsbereit ist
Wenn Ihr sshd-Setup nicht für dumme Script-Kiddies geeignet ist, die nur Port 22 ausprobieren, haben Sie trotzdem ein Problem.
Eine rationalere Reaktion wäre:
Stellen Sie sicher, dass Ihre Benutzer gute Passwörter verwenden, die schwer zu erraten sind
Deaktivieren Sie die Kennwortauthentifizierung (zumindest für wichtige Konten) und verwenden Sie einfach die Authentifizierung mit öffentlichem Schlüssel
Achten Sie auf SSH-Sicherheitsprobleme und -Upgrades
Einige Leute können sich auch über das Rauschen ärgern, das sshd in das Systemprotokoll schreibt, z.
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
Es könnte dann verlockend sein, den sshd-Port zu verdecken oder eine automatische Blockierungslösung (wie DenyHosts, Fail2ban oder BlockHosts) zu verwenden, um das Signal-Rausch-Verhältnis wieder zu erhöhen .
Es gibt aber bessere Alternativen. Beispielsweise können Sie Ihren syslog-Daemon so konfigurieren, dass das Rauschen des sshd-Protokolls beispielsweise nur geschrieben wird /var/log/sshd-attempts.logund das Signal (dh die verbleibenden sshd-Protokollnachrichten) /var/log/messageswie zuvor in usw. geschrieben wird .
Ich stimme nicht wirklich zu, dass "es Sicherheit durch Unbekanntheit ist". Ich denke, dass diese Antwort in diesem Fall ein verbreiteter Irrtum ist. @ Michaels Argumentation ist im Allgemeinen ein besserer Grund, es woanders zu haben. Meistens geht es nur darum, alle Angriffe mit Skripten loszuwerden. Bedeutet nicht zwangsläufig, dass Sie Angst vor ihnen haben oder es für wirksam gegen einen entschlossenen Angreifer halten. Ich wusste, dass ich nie befürchtete, dass sie tatsächlich reinkommen würden, aber die ganze Holzkiste war nervig.
Xenoterracide
1
@xenoterracide: Wenn Sie nur über die Lesbarkeit Ihrer Protokolldateien besorgt sind, gibt es andere bessere Alternativen, um das Rauschen auszuschließen, anstatt den Port als obskure Taktik zu ändern, was die Frage war. In Bezug auf die IP-Blockierung, die nicht Teil der Frage war: Bitte beachten Sie, dass das Hinzufügen von mehr Komplexität zu sicherheitsrelevanten Systemen auch das Risiko der Ausnutzung erhöht. Betrachten Sie zum Beispiel seclists.org/fulldisclosure/2007/Jun/121 ossec.net/main/attacking-log-analysis-tools . Ja, DenyHosts war davon betroffen.
Maxschlepzig
1
Es geht um mehr als nur Lesbarkeit. Eine ordnungsgemäß dokumentierte Portänderung bedeutet nicht "Sicherheit durch Unbekanntheit".
Xenoterracid
4
Das Ändern des SSH-Ports ist hauptsächlich ein Sicherheitsrisiko . Es gibt Ihnen ein unscharfes Gefühl, etwas getan zu haben. Sie haben den SSH-Port unter der Fußmatte versteckt.
Wenn Sie einen SSH-Server im Internet betreiben, werden in Ihren Protokollen viele fehlgeschlagene Anmeldeversuche von Bots angezeigt, die in älteren Serverversionen nach dumm schwachen Passwörtern, schwachen Schlüsseln und bekannten Exploits suchen . Die fehlgeschlagenen Versuche sind genau das: fehlgeschlagene Versuche. Ihre Einschätzung, wie verletzlich Sie sind, ist völlig irrelevant. Worüber Sie sich Sorgen machen müssen, sind die erfolgreichen Einbruchsversuche, die in Ihren Protokollen nicht angezeigt werden.
Durch Ändern des Standardports wird die Anzahl der Treffer durch solche Bots verringert, jedoch werden nur die am wenigsten erfahrenen Angreifer vereitelt, die von angemessener Sicherheit gestoppt werden (regelmäßig angewendete Sicherheitsupdates, einigermaßen sichere Kennwörter oder deaktivierte Kennwortauthentifizierung). Der einzige Vorteil ist die Reduzierung des Protokollvolumens. Wenn das ein Problem ist, sollten Sie so etwas wie Denyhosts oder Fail2ban die Verbindungsrate anstatt zu begrenzen, es wird auch Ihre Bandbreite gut tun.
Das Ändern des Standardports hat einen großen Nachteil: Es ist weniger wahrscheinlich, dass Sie sich hinter einer Firewall anmelden können. Firewalls lassen Dienste mit größerer Wahrscheinlichkeit an ihrem Standardport durch als an einem zufälligen anderen Port. Wenn Sie keinen HTTPS-Server ausführen, sollten Sie in Betracht ziehen, dass SSH auch Port 443 überwacht (oder eingehende TCP-Anforderungen von Port 443 an Port 22 umleitet), da einige Firewalls Datenverkehr zulassen, der auf Port 443 nicht decodiert werden kann, da er aussieht wie HTTPS.
Antworten:
Der wahrscheinlichste Grund ist, es den Leuten schwerer zu machen, nach dem Zufallsprinzip SSH-Anmeldungen zu erzwingen, die sie finden können. Mein mit dem Internet verbundener Computer verwendet den Standard-SSH-Port, und meine Protokolle waren mit solchen Dingen gefüllt (Auszug aus einer tatsächlichen Protokolldatei):
In diesen Tagen verwende ich DenyHosts , um IPs zu blockieren, die sich nicht zu oft authentifizieren, aber es ist wahrscheinlich genauso einfach, nur die Ports zu wechseln. Praktisch alle Brute-Force-Angriffe dieser Art werden sich nicht darum kümmern, zu scannen, ob Ihr SSHD an einem anderen Port empfangsbereit ist
quelle
Nein, es ist eine Strategie der Sicherheit durch Unbekanntheit .
Wenn Ihr sshd-Setup nicht für dumme Script-Kiddies geeignet ist, die nur Port 22 ausprobieren, haben Sie trotzdem ein Problem.
Eine rationalere Reaktion wäre:
Einige Leute können sich auch über das Rauschen ärgern, das sshd in das Systemprotokoll schreibt, z.
Es könnte dann verlockend sein, den sshd-Port zu verdecken oder eine automatische Blockierungslösung (wie DenyHosts, Fail2ban oder BlockHosts) zu verwenden, um das Signal-Rausch-Verhältnis wieder zu erhöhen .
Es gibt aber bessere Alternativen. Beispielsweise können Sie Ihren syslog-Daemon so konfigurieren, dass das Rauschen des sshd-Protokolls beispielsweise nur geschrieben wird
/var/log/sshd-attempts.logund das Signal (dh die verbleibenden sshd-Protokollnachrichten)/var/log/messageswie zuvor in usw. geschrieben wird .Der Einsatz von Tools zum automatischen Blockieren sollte sorgfältig erwogen werden, da eine höhere Komplexität sicherheitsrelevanter Systeme auch das Risiko einer Ausnutzung erhöht . Tatsächlich gibt es im Laufe der Jahre mehrere DoS-Schwachstellenberichte für jeden DenyHosts , Fail2ban und BlockHosts .
quelle
Das Ändern des SSH-Ports ist hauptsächlich ein Sicherheitsrisiko . Es gibt Ihnen ein unscharfes Gefühl, etwas getan zu haben. Sie haben den SSH-Port unter der Fußmatte versteckt.
Wenn Sie einen SSH-Server im Internet betreiben, werden in Ihren Protokollen viele fehlgeschlagene Anmeldeversuche von Bots angezeigt, die in älteren Serverversionen nach dumm schwachen Passwörtern, schwachen Schlüsseln und bekannten Exploits suchen . Die fehlgeschlagenen Versuche sind genau das: fehlgeschlagene Versuche. Ihre Einschätzung, wie verletzlich Sie sind, ist völlig irrelevant. Worüber Sie sich Sorgen machen müssen, sind die erfolgreichen Einbruchsversuche, die in Ihren Protokollen nicht angezeigt werden.
Durch Ändern des Standardports wird die Anzahl der Treffer durch solche Bots verringert, jedoch werden nur die am wenigsten erfahrenen Angreifer vereitelt, die von angemessener Sicherheit gestoppt werden (regelmäßig angewendete Sicherheitsupdates, einigermaßen sichere Kennwörter oder deaktivierte Kennwortauthentifizierung). Der einzige Vorteil ist die Reduzierung des Protokollvolumens. Wenn das ein Problem ist, sollten Sie so etwas wie Denyhosts oder Fail2ban die Verbindungsrate anstatt zu begrenzen, es wird auch Ihre Bandbreite gut tun.
Das Ändern des Standardports hat einen großen Nachteil: Es ist weniger wahrscheinlich, dass Sie sich hinter einer Firewall anmelden können. Firewalls lassen Dienste mit größerer Wahrscheinlichkeit an ihrem Standardport durch als an einem zufälligen anderen Port. Wenn Sie keinen HTTPS-Server ausführen, sollten Sie in Betracht ziehen, dass SSH auch Port 443 überwacht (oder eingehende TCP-Anforderungen von Port 443 an Port 22 umleitet), da einige Firewalls Datenverkehr zulassen, der auf Port 443 nicht decodiert werden kann, da er aussieht wie HTTPS.
quelle