Antworten:
Es ist nicht so nützlich, wie manche behaupten, aber es wird zumindest die Auswirkung auf Ihre Protokolldateien verringern, da viele Brute-Force-Anmeldeversuche nur den Standardport verwenden und nicht scannen, um festzustellen, ob SSH woanders empfangsbereit ist. Einige Angriffe suchen jedoch an anderer Stelle nach SSH, so dass es keine Wunderwaffe ist.
Wenn Ihr Server eine Art gemeinsam genutzter Host sein soll, anstatt nur die Anforderungen Ihrer Projekte zu erfüllen, kann die Verwendung eines nicht standardmäßigen Ports problematisch sein, da Sie ihn Ihren Benutzern immer wieder und immer wieder erklären müssen vorbei, wenn sie vergessen und ihre Client-Programme keine Verbindung zu Port 22 herstellen!
Ein weiteres mögliches Problem mit SSH auf einem nicht standardmäßigen Port besteht darin, dass Sie auf einen Client mit einem restriktiven ausgehenden Filtersatz stoßen, der keine Verbindung zu Ihrem benutzerdefinierten Port herstellen kann, da sein Filter beispielsweise nur die Ports 22, 53, 80 zulässt und 443, um das Ziel für neue ausgehende Verbindungen zu sein. Dies ist ungewöhnlich, aber sicherlich nicht ungewöhnlich. In ähnlicher Hinsicht sehen einige ISPs möglicherweise verschlüsselten Datenverkehr an einem anderen als dem normalerweise erwarteten Port (Port 443 oder HTTPS, 22 für SSH usw.) als Versuch, eine P2P-Verbindung zu verbergen und zu drosseln (oder zu blockieren). die Verbindung in unbequemer Weise.
Ich persönlich belasse SSH aus Bequemlichkeitsgründen auf dem Standard-Port. Solange die üblichen Vorsichtsmaßnahmen getroffen werden (strenge Kennwort- / Schlüsselrichtlinie, Einschränkung der Root-Anmeldungen, ...), ist dies kein Problem, und das Problem mit dem Anwachsen der Protokolldatei, wenn Sie von einem Brute-Force-Angriff getroffen werden, kann mithilfe von Tools wie z as fial2ban zum vorübergehenden Blockieren von Hosts, die in einem bestimmten Zeitraum zu viele ungültige Authentifizierungsdaten angeben.
Unabhängig vom gewählten Port sollten Sie sicherstellen, dass der Wert unter 1024 liegt, wenn Sie sich von 22 entfernen. Bei den meisten Unix-ähnlichen Setups in der Standardkonfiguration können nur Root-Benutzer (oder Benutzer in der Root-Gruppe) Ports unter 1024 überwachen. Jeder Benutzer kann jedoch die höheren Ports abhören. Das Ausführen von SSH auf einem höheren Port erhöht die Wahrscheinlichkeit, dass ein betrügerischer (oder gehackter) Benutzer Ihren SSH-Dämon zum Absturz bringt und durch einen eigenen oder einen Proxy ersetzt.
Es ist eine einfache (aber überraschend effektive) Form der Sicherheit durch Unbekanntheit .
Wenn Ihr SSH-Server nicht an Port 22 angeschlossen ist, wird er mit weitaus geringerer Wahrscheinlichkeit von Personen gefunden, die im gesamten Internet nach schwachen Passwörtern für Standardkonten suchen. Wenn Sie das gesamte Netz durchsuchen, können Sie es sich nicht leisten, alle 64.000 möglichen Ports zu überprüfen, um den SSH-Server zu finden.
Wenn Sie jedoch gezielt angesprochen werden, hat dies keinen Vorteil, da durch einen einfachen einmaligen nmapScan der Port ermittelt wird, auf dem er tatsächlich ausgeführt wird.
Um Bruteforce-Angriffe wirklich zu vermeiden, ist es immer wichtig, einige Schritte zu befolgen:
Ja, es ist nützlich, da es nur dazu beiträgt, alle Brute-Force-Angriffe zu vermeiden und die Protokolle klar zu halten :)
Was die Portnummer anbelangt, die Ihnen überlassen ist, habe ich gesehen, dass Unternehmen 1291 ziemlich oft verwenden. Ich verwende jedoch etwas Höheres, um einige der Skripte zu vermeiden.
Erlaube keine Root-SSH-Anmeldungen und ändere die Portnummer und vielleicht etwas wie fail2ban und du solltest golden sein. Füge iptables hinzu und halte dich auf dem Laufenden. Du solltest keine Probleme haben.
Die Verwendung eines nicht standardmäßigen SSH-Ports erfordert weitere Erläuterungen und Dokumentation sowie die Beantwortung von E-Mails mit dem Titel "Ich kann mich nicht anmelden".
Ich halte die folgenden Vorteile der Ausführung von sshd auf einem nicht standardmäßigen Port für wichtiger als die damit verbundenen Probleme:
Außerdem können Sie, wenn Sie wirklich böse sein möchten, auf dem Standard-Port 22 immer einen gefälschten SSHD (mit DenyUsers * ) ausführen , während Ihr regulärer SSHD auf Port 54321 ausgeführt wird. Auf diese Weise wird sichergestellt, dass alle Bots und Eindringlinge für immer auf dem Laufenden sind Versuchen Sie, sich bei einem Dienst anzumelden, der alle Anmeldungen verweigert, da niemand daran denkt, Ihren echten SSHD-Dienst zu finden .
Meine 2 Cent.
Dies aus "Sicherheitsgründen" zu tun, ist eine Fälschung. Es ist das beste Beispiel für Sicherheit durch Dunkelheit, bei dem es sich nicht um Sicherheit handelt.
Wenn Sie Ihre Protokolle ein wenig leichter und sauberer halten möchten, dann ist dies nützlich, da Sie nicht so viele Port-Knocking- / Script-Kiddy-Bruteforce-Versuche erhalten.
Ich würde ssh auf dem Standardport ausführen und so etwas wie fail2ban oder denyhosts verwenden , um die Anzahl der Wörterbuchangriffe zu begrenzen.
Eine andere Möglichkeit ist, die Anmeldung mit Passwörtern zu deaktivieren und nur Anmeldungen mit SSH-Schlüsseln zuzulassen.
Weil es eine Menge schlechter Leute gibt, die alle Server-IPs nach offenen Ports durchsuchen, um sie auszunutzen. Früher hatte ich den ganzen Tag Hammerangriffe auf meinen SSH-Port, bis ich ihn auf einen anderen Port und auf eine IP verlegte, die nicht mehr mit einer meiner Websites verknüpft war.
Dies ist nützlich, da sich die Skript-Bots, die Brute-Force-Angriffe zum Erraten von Passwörtern ausführen, in der Regel auf Port 22 konzentrieren. Wenn Sie also die Ports ändern, werden sie normalerweise deaktiviert. Sie müssen den Wert der Minderung dieses Risikos mit dem Aufwand abwägen, der durch die Konfiguration von ssh-Clients für die Verbindung mit dem nicht standardmäßigen Port entsteht (zugegebenermaßen kein großer Aufwand, wenn nicht viele Benutzer eine Verbindung herstellen).
Alternativ können Sie das Brute-Force-Risiko verringern, indem Sie die Kennwortauthentifizierung deaktivieren und stattdessen die RSA-Schlüsselauthentifizierung anfordern.
Normalerweise ändere ich den Port auf der SSHD nicht, sodass ich keine andere Nummer vorschlagen kann. Überprüfen Sie jedoch die Liste der häufig verwendeten Ports , um eine andere Nummer zu finden (dh eine Nummer, die nicht von etwas anderem verwendet wird und daher möglicherweise gescannt wird). .
Ich ändere meine SSHd immer so, dass sie Port 2222 verwendet. Jeder, der auf meine Server zugreifen muss, weiß das und es ist kein Geheimnis. Es gibt absolut keinen Sicherheitsgewinn, wenn Sie dies tun (es sei denn, der potenzielle Hacker ist ein absoluter Schwachkopf).
Der einzige Vorteil, den ich daraus ziehen kann, ist, dass das Authentifizierungsprotokoll nicht über eine Million fehlgeschlagener Anmeldeversuche für "root", "alice", "bob", "sally", "admin" usw. verfügt.
Sicherheit durch Unbekanntheit hat sich als nutzlos erwiesen. Normalerweise konfiguriere ich den SSH-Zugriff mit dem Standard-Port aus den oben genannten Gründen (Client-Probleme bei der Neukonfiguration, Firewall- und Proxy-Probleme usw.).
Außerdem deaktiviere ich immer die root-Anmeldung und die Passwortauthentifizierung und verwende als letzten Schritt fail2ban , um diese lästigen Nachrichten im Syslog loszuwerden. In Debian / Ubuntu ist es so einfach wie das Tippen aptitude install fail2ban. Die Standardkonfiguration funktioniert ziemlich gut, aber ich stimme einige Parameter normalerweise so ein, dass sie restriktiver sind, da sie eine längere Sperrzeit (mindestens einen Tag) und nur zwei fehlgeschlagene Authentifizierungsversuche als Auslöser für die Sperre haben.
Ich würde sagen, dass Sie sich beim Ändern des SSH-Ports am meisten vor automatischen Scans schützen, die versuchen, unter Verwendung von Standardbenutzernamen / -kennwörtern Zugriff zu erhalten. Wenn Ihre Kennwortrichtlinien streng sind, sollten Sie sich keine Sorgen machen müssen Sie.
Wenn Sie die Kennwortanmeldungen auf Ihrem Server deaktivieren (was dringend empfohlen wird), ist das Ändern des SSH-Ports völlig nutzlos. Durch das Deaktivieren der Kennwortanmeldungen (und das Erfordernis einer schlüsselbasierten Authentifizierung) wird die Möglichkeit von Brute-Force-Kennwortversuchen beseitigt, sodass Sie nichts gewinnen, wenn Sie mit Portnummern herumtollen.
Wenn Sie weiterhin die Kennwortbasisauthentifizierung zulassen, können Sie möglicherweise einen erfolgreichen Brute-Force-Versuch starten oder - was meiner Erfahrung nach häufiger vorkommt - Ihr Kennwort kompromittieren, weil Sie es bei laufendem System eingeben ein Keylogger.
man ssh-keygenfür viele Informationen.
Keine Antwort, aber zu lang für einen Kommentar, also mache ich das CW.
Ich habe eine Weile darüber nachgedacht und bin zu dem Schluss gekommen, dass das, was Juliano in seinen Kommentaren zu Alnitaks Antwort sagt, sehr viel Wahres enthält. Trotzdem finde ich, dass es durch das Ausführen von SSH auf Port 22 viel zu einfach ist, Angriffe jeglicher Art dagegen zu starten.
Um dieses Problem zu lösen, führe ich meine internen SSH-Server an Port 22 aus und nutze die Firewall, um den hohen Port an 22 auf den Zielcomputern weiterzuleiten. Dies gibt etwas Sicherheit durch Dunkelheit, während die Sicherheit eines niedrigen Hafens erhalten bleibt, wie Juliano hervorgehoben hat.
Sicherheit durch Unbekanntheit ist kein Prinzip, dem ich mich normalerweise anschließe, und es wird oft darauf hingewiesen, dass ein einfacher Port-Scan den Zielport aufdeckt und die Unbekanntheit wertlos macht. Um dieses Problem zu lösen, verwenden meine Firewalls (Smoothwall Express) sowohl bei der Arbeit als auch zu Hause ein Skript namens Guardian Active Response, das durch Snort-Warnungen ausgelöst wird. Aus der Beobachtung kann ich Ihnen sagen, dass wenn Sie mehr als 3 verschiedene Ports von derselben Quelle ansteuern, Ihre Pakete bis zur voreingestellten Rücksetzzeit fallengelassen werden. Dies macht es ziemlich schwierig und extrem zeitaufwendig, einen Port-Scan durchzuführen, wodurch die Unklarheit tatsächlich etwas wert ist. Dies hat dazu geführt, dass ich in der Vergangenheit so oft gesperrt wurde, dass ich einen Ausschluss für meine Quell-IP-Adresse (zu Hause oder im Büro) festgelegt habe.
Das Problem, das Sie haben, ist, dass die Firewall so eingerichtet ist, dass nur bestimmte IPs eine Verbindung herstellen können, und der Chef es leid ist, bestimmte IPs zu öffnen, wenn er unterwegs ist. Wenn Sie bestimmte IP-Adressen an der Firewall sperren, kann das nerven.
Zwei Dinge, an die ich hier denke. Das Ändern des Ports schützt vor automatisierten Angriffen. Das war's auch schon, aber es ist ein großer Teil des durchschnittlichen Angriffsverkehrs da draußen ... das Scannen von Netzwerken mit automatisierten Skripten. Wenn Sie den Standard-Port ändern, sollten diese Angriffe auf Null sinken. Insofern macht es also Sinn. Gegen gezielte Angriffe ist jedoch nichts einzuwenden, da der Angreifer einfach von Nessus oder NMAP aus scannen kann, um festzustellen, welche Ports Sie verwenden, wenn Sie einen speziellen kleinen Freund haben, der Sie genug hasst.
Zweitens können Sie, wenn Sie UNIX-ähnliche Server verwenden, ein Dienstprogramm wie Denyhosts installieren, um Angriffe zu stoppen. Wenn Sie denyhosts installieren, wird nach falschen Anmeldeversuchen gesucht, und nach (unabhängig von der Anzahl) fehlgeschlagenen Versuchen wird die IP für einen von Ihnen festgelegten Zeitraum gesperrt. Denyhosts können auch mit anderen Denyhost-Hosts sprechen und Bannlisten weiterleiten. Wenn ein Angreifer also in Montana aus Freds Linux-System ausgeschlossen wird, erhält Ihr System diese IP auch zum Bannen. Sehr nützlich, solange sich Ihre Benutzer an ihre Passwörter erinnern.
Es hängt alles von Ihren Nutzungsszenarien ab. Wie viele Programme haben Sie, die einen "Schmerz im Arsch" für das Ändern des Verbindungsports für SSH / SCP darstellen (und wenn sie es nicht zulassen oder zu einem Schmerz machen, müssen Sie wirklich in Betracht ziehen, den Anbieter persönlich zu wechseln). Wenn es nur eine potenzielle Angst ist, würde ich sagen, dass es kein Problem ist. Und das ist Ihr Chef, der nach etwas fragt, das nicht ganz verrückt ist, da viele Sysadmins den SSH-Port umdrehen (mit einigem Flak von Leuten, die alles hassen, was auch nur schwach nach Sicherheit riecht, durch Unbekanntheit ... aber es verringert sich wirklich Hintergrundgeräusche von automatisierten Scans.)
Heruntergekocht - Durch Ändern des Ports werden automatisierte Skripts und der Großteil des schlechten Datenverkehrs blockiert. Hält gerichtete Angreifer nicht auf. Erwägen Sie auch die Installation eines Dienstprogramms zum automatischen Bannen. Die Sicherheit in Schichten schadet Ihnen nicht, wenn sie ordnungsgemäß ausgeführt wird, und das Ändern der Ports tut in den meisten Situationen mehr weh als es tut.
Ich habe seit mehr als 5 Jahren SSH auf Port> 1024 ausgeführt. Seitdem habe ich in meiner Protokolldatei keinen Portscan-Versuch mehr gesehen (außer meinem eigenen). Es gibt meine Server, die ich mit Port> 1024 verwalte.
Viele der SSH-Server, die auf einem Port> 1024 laufen, haben ihre eigenen Websites, was sehr beliebt ist.
Wenn der SSH-Server in meiner eigenen Firma ausgeführt wird, habe ich möglicherweise bereits die IP-Adresse dieses Servers hier veröffentlicht, damit Sie versuchen können, sich in den Server zu hacken. Leider ist der SSH-Server nicht mein eigener. ;-)
Es gibt jedoch noch andere Dinge, die Sie einrichten müssen, um die Sicherheit zu gewährleisten. SSH> 1024 allein würde nicht ausreichen. Die Portnummer darf nicht in der / etc / services stehen, muss Portforwarding verwenden (zB Port 1124-> 22), der direkte Zugriff auf Root muss deaktiviert sein und sonstiges.
Wenn Sie argumentieren möchten, sollten Sie SSH einige Jahre lang auf Port> 1024 ausführen.
p / s: 1124 ist nicht meine SSH Port Nr. Haha.
Das Verschieben von SSH auf einen anderen Port ist zwar sinnvoll, hilft aber bei der Sicherheit nicht enorm. Natürlich müssen Sie dazu die Kontrolle über Ihre Firewalls haben, aber das ist für Sie kein Problem. Was meiner Meinung nach den Vorteil des Verschiebens des Hafens zunichte macht, ist die Öffnung des akzeptierten Bereichs. Ich würde sogar sagen, dass dies den Vorteil mehr als zunichte macht und Sie weiter bloßstellt als heute. Ich bin sicher, Sie können ihn davon überzeugen, den Port zu verschieben UND die Empfangsreichweite erheblich zu verringern, indem Sie eine Liste der wahrscheinlichen Einstiegspunkte zusammenstellen, anstatt sie alle zu öffnen.
Das Ändern Ihres SSH-Ports ist eine sinnlose Übung, die Ihnen nur eingeschränkte Sicherheit bietet. Sie sollten einfach die Kennwortauthentifizierung deaktivieren, um das Risiko von Brute-Force-Kennwortversuchen zu vermeiden, und sich ausschließlich auf die auf SSH-Schlüsseln basierende Authentifizierung verlassen. Wenn Ihre Umgebung eine Kennwortauthentifizierung erfordert, verwenden Sie einen Zwei-Faktor-Mechanismus wie SecurID oder Wikid.
Beides erhöht die Sicherheit erheblich, während das Ändern des SSH-Ports nur die Illusion von Sicherheit erzeugt.
Dies ist ein praktischer POV: Ich habe mehr als vier Jahre lang öffentlich sichtbare private SSH-Server mit geändertem SSH-Port betrieben und keinen einzigen Versuch unternommen, ein Kennwort zu scannen. Aus Gründen dieser Qualitätssicherung habe ich gerade 22 für einen Tag für einen von ihnen aktiviert. Als Ergebnis wurde ich ungefähr alle 10 Minuten mit einer Kennwortversuchsfrequenz von ungefähr 5 pro Sekunde gescannt. Außerdem suchen "Scan Kiddies" nach Servern mit bestimmten OpenSSH-Schwachstellen.
Natürlich ist dies Sicherheit durch Unbekanntheit, was nicht hilft, wenn Sie einen Feind haben.
Es funktioniert großartig, ungeachtet des Jammerns der Menge "Sicherheit durch Dunkelheit".
Dumme Kaninchen, ALLE Sicherheit ist Sicherheit durch Dunkelheit. Nur weil Sie glauben, dass das obskure Kryptoprotokoll Z (das eine Kombination aus DNA-Proben, gemeinsam genutzten Schlüsseln und vom Menschen unmöglich zu tippenden Passwörtern erfordert) tatsächlich sicher ist, ist dies noch lange nicht der Fall. Die Wahrheit ist, dass alle Sicherheitsmaßnahmen auf Wahrscheinlichkeiten und Annahmen der Benutzer beruhen. Schade für dich, wenn ich weiß, wie ich diese Annahme ausnutzen kann, aber da ist sie.
Sowieso,
Wir haben dies jahrelang getan, zusammen mit a) der Beschränkung der Verbindungsversuchsrate (ich weiß jedoch nicht, wie wir das eingerichtet haben, etwas in der ssh-Konfiguration) und b) einem Skript, um jeden Host zu verbieten, auf dem ein Wörterbuchangriff mit mehr als ausgeführt wird X falsche Vermutungen in Y Minuten. Wir verbieten dem Host, die Verbindung für einen bestimmten Zeitraum herzustellen, und dies erleichtert die Anpassung an die Topologie sich ändernder Netzwerke.
Wenn Ihre Passwörter ausreichend komplex sind und nur drei Versuche in 15 Minuten möglich sind, gibt es nicht viel zu befürchten. Es ist auch nicht so schwer, nach verteilten Angriffen Ausschau zu halten - wir sortieren normalerweise nach Subnetz und IP, um solche Angriffe auszuschließen.
Schließlich benötigen Sie nur eine geheime Eichhörnchenmethode, um Verbindungen zu Ihrem Port zuzulassen, indem Sie die F / W-Regeln ändern. Es kann alles sein ... smtp, web, magic dns abfragen. Sachen wie SecurID oder Wikid geben einfach mehr Informationen an Dritte weiter. Und lassen Sie mich nicht durch Dritte mit sicheren Zertifikaten beginnen.