Verbessert es die Sicherheit, obskure Portnummern zu verwenden?

Wenn Sie bereits Kennwörter mit hoher Entropie oder Authentifizierung mit öffentlichem Schlüssel verwenden, lautet die Antwort "nicht wirklich". Meistens werden Sie nur den Lärm in Protokollen los.

Ich mache mir Sorgen über die unbeabsichtigten Folgen einer Abweichung von diesen Empfehlungen.

Es hängt davon ab, welcher Port ausgewählt wurde. Unter Linux benötigen standardmäßig alle Ports unter 1024 Root-Zugriff, um sie abzuhören. Wenn Sie einen Port über 1024 verwenden, kann jedes Benutzerkonto ihn abhören, wenn noch kein Prozess abgehört wird.

Warum ist das wichtig? Angenommen, Sie haben ssh so eingestellt, dass es an Port 20.000 bindet. Wenn jemand den SSH-Prozess auf einem Server stoppen könnte (sagen wir, er hat irgendwie einen Weg gefunden, den Prozess zum Absturz zu bringen) und lokalen Zugriff auf diesen Server hätte, könnte er seinen eigenen SSH-Server auf Port 20.000 ausführen bevor der Dienst neu gestartet wurde. Jeder, der sich anmeldet, meldet sich dann beim SSH-Server der bösen Jungs an.

Dies ist keine so große Sache wie früher, da heutzutage nur vertrauenswürdige IT-Mitarbeiter Anmeldezugriff erhalten Server. Dennoch besteht die Möglichkeit einer Eskalation von Berechtigungen und anderer Unangenehmkeit, wenn ein Angreifer auf Ihrem Server Fuß fasst.

Abgesehen davon, dass er unter 1024 liegt, hat die Nummer 22 nichts Besonderes. Sie wurde größtenteils ausgewählt, weil SSH war ein Ersatz für Telnet an Port 23 , und 21 wurde bereits von FTP übernommen. Solange Sie einen Port unter 1024 auswählen, spielt der Port keine Rolle.

Ist dies eine gute Vorgehensweise oder nicht? Sollten wir bekannte Ports verwenden?

Ich würde nicht sagen, dass ich es empfehlen würde. Ich würde auch nicht davon abraten. Wie gesagt, es vermeidet viel Rauschen in Protokolldateien, aber die Vorteile sind weitgehend darauf beschränkt.

Alle, die sich für die Hintergrundgeschichte zu SSH interessieren, finden sie unter: https://www.ssh.com/ssh/port

Ja, das tut es. Die eigentliche Frage ist: Um wie viel?

Warum? Sie haben bereits grundlegende Sicherheit, sodass Sie sich bei den alltäglichen Bot-Angriffen keine Sorgen machen. Aber es könnte morgen einen 0-Tage geben, und die Angreifer wissen, dass es nicht lange dauern wird, bis ein Patch veröffentlicht wird. Sie bemühen sich also, ihn zu verwenden, und kümmern sich nicht um etwas Kompliziertes - sie treffen einfach so viele Maschinen wie möglich der Standardport. Jede Art von theoretischem SSH-Wurm würde diese Strategie ebenfalls verwenden. Sie wären davor geschützt.

Wie viel zusätzliche Sicherheit bringt Ihnen dies? Es schützt vor diesem und möglicherweise 2-3 anderen spezifischen Szenarien. Jeder gezielte Angriff von Personen, die kein totaler Idiot sind, wird bestenfalls um einige Minuten verlängert. Es hat nichts mit den Szenarien zu tun, gegen die Sie bereits angemessen geschützt sind.

Wenn Sie diese Zahlen in Ihre bevorzugte Risikoanalysemethode einfügen, sollten Sie sich etwas relativ Kleines einfallen lassen. Auf der anderen Seite haben Sie den zusätzlichen Aufwand, eine nicht standardmäßige Portnummer festzulegen, zu dokumentieren, sie möglicherweise während einer Fehlerbehebung zu verpassen und einige Zeit zu verschwenden usw.

Ich vermute, dass Sie gerade die Gewinnschwelle erreichen würden mit einer Analyse. Oder mit anderen Worten: Ja, es verbessert zwar die Sicherheit, aber die Mühe lohnt sich nicht, da die Verbesserung sehr gering ist.

Nein, die Sicherheit wird dadurch nicht verbessert. Dies kann die Unordnung im Protokoll verringern, da bei automatisierten Angriffen nur Standardports für z. ssh. Der Port wird jedoch weiterhin als SSH in einem Port-Scan und shodan.io angezeigt.

Diese automatisierten Angriffe zielen normalerweise auf niedrig hängende Früchte mit Standardbenutzernamen wie root, Schmied und so weiter und schwache Passwörter. Wenn sie erfolgreich sind, liegt zunächst ein Problem vor.

Wenn Sie ssh so konfigurieren, dass nur die Schlüsselauthentifizierung zugelassen wird, Root-Anmeldungen nicht zulässig sind und vernünftige Kennwörter verwendet werden, verwenden Sie fail2ban oder einen ähnlichen Mechanismus, um Straftäter zu blockieren Ich bin keine echte Bedrohung.

Ich verwende fail2ban, das so konfiguriert ist, dass es nach drei fehlgeschlagenen Versuchen für fünf Minuten und nach 3 * 5 fehlgeschlagenen Versuchen eine Woche lang vorübergehend blockiert. Dies reduziert die Unordnung im Protokoll und blockiert jeden echten Fortschritt bei einem Brute-Force-Angriff.

Für einen gezielten Angreifer spielt es keine Rolle, welche Port-Inhalte abgehört werden. Es ist nur für automatisierte Angriffe von Bedeutung, die meiner Meinung nach ein vernachlässigbares Risiko darstellen.

Wenn Sie den Standardport ändern, können Sie sich vor Port-Scan- und Skript-Kiddies schützen, aber Sie sind möglicherweise nicht in der Lage, gezielten Angriffen standzuhalten, bei denen der Angreifer die für die Ports irrelevanten laufenden Dienste identifizieren kann.

Wenn Sie möchten Gehen Sie einfach von Script-Kiddies weg. Dies kann hilfreich sein, aber Sie können sich möglicherweise nicht vor den restlichen Vorabangriffen schützen.

Ich empfehle, den Standardport zu verwenden (kann den Verwaltungsaufwand verringern) und mehrseitige Sicherheitsmaßnahmen einzusetzen, um Angriffe abzuwehren.

Wenn beispielsweise der Standardport verwendet wird, ist die Bereitstellung einer zertifikatbasierten Authentifizierung mit SSH nur für bestimmte vertrauenswürdige Quellen zulässig.

Ich würde ja sagen, verwenden Sie nicht normale Portnummern, da dies eine Menge automatischer Bots herausfiltert. Aber verlassen Sie sich nicht darauf, da viele Bots, die mir aufgefallen sind, ein Netzwerk / einen Host nach offenen Ports durchsuchen und diese ausprobieren.

Das Beste ist, eine gute Sicherheit auf Ihrem SSH-Port zu implementieren . Deaktivieren Sie die Root-Anmeldung und führen Sie IP-Adressen auf die Whitelist, wenn Sie können. Verwenden Sie keine Kennwörter für Anmeldungen (verwenden Sie Schlüssel) und aktivieren Sie auch eine Benachrichtigung für Anmeldungen. Und richten Sie eine Firewall ein, das ist wichtig.

Das Verschleiern von Ports mit einer solchen hohen Anzahl stoppt nur einfache Bots, die nach bekannten Ports suchen. Script-Kiddies und entschlossene Hacker können den Rest des Portbereichs einfach per Port scannen, um einen Dienst zu finden, sodass Sie nur ein wenig Protokollrauschen stoppen.

Es spielt keine Rolle, ob Sie den Standard nicht abhören Port für diesen Dienst. Die Entwickler dieses Dienstes geben Ihnen die Möglichkeit, ihn auf einem anderen Port auszuführen, und jedes Programm, das mit ihm interagiert, kann angeben, mit welchem ​​Port Sie sprechen möchten.

Ich stimme anderen zu Hier wird darauf hingewiesen, dass vertrauliche Ports wie SSH im privilegierten Portbereich unter 1024 aufbewahrt werden sollten.

Ein besserer Weg, um SSH zu verschleiern, das tatsächlich funktioniert, besteht darin, einen Portklopf auszuführen. Dies beinhaltet das Schließen des Ports an iptables, bis eine Sequenz von Ports "geklopft" wurde, die dann den gewünschten Port öffnet.

EG Sie können ein Paket an 8000 4545 28882 7878 senden. Sobald Ihre gewünschte Sequenz ist Eingegebene iptables entsperren Ihren gewünschten Port. Dies stoppt wirklich die Mehrheit der Script-Kiddies und Hacker, da kein Port angekündigt wird. Dies hört jedoch nicht bei Wiederholungsangriffen auf, sondern an dem Punkt, an dem Sie sich größere Sorgen machen müssen.

https://en.wikipedia.org/wiki/Port_knocking.

Eigentlich sollten Sie TCPWrapper verwenden und nur bekannten IP- und Netzwerkbereichen Zugriff auf Ports wie SSH gewähren. Müssen Sie IPs aus China auf SSH zugreifen lassen? Oder müssen Entwickler nur über das Office-LAN zugreifen? Wenn sie remote arbeiten, machen Sie sie VPN in das LAN

Wie von anderen erwähnt, ist die Migration auf einen nicht standardmäßigen Port keine Sicherheitslösung, da Sie nur Angriffe auf naiver Ebene herausfiltern.

Gleichzeitig kann die Migration in Kombination mit anderen viel wertvoller sein Vorsichtsmaßnahmen. Zum Beispiel platzieren Sie einen Honeypot am Standardport (eine Umgebung, die physisch vom Rest Ihres Systems isoliert ist, aber für den Angreifer wie ein legitimes Element aussieht). Wenn Sie dann sehen, dass jemand im Honeypot kaputt ist, handelt es sich höchstwahrscheinlich um einen Hacker, sodass Sie ihn automatisch verbieten können.

Und natürlich sollten Sie keine veralteten Versionen von Software mit bekannten Sicherheitslücken verwenden, unabhängig von der Portnummer, an die sie gebunden sind, um zuzuhören.

Nein, das ist nicht der Fall, oder wenn ich genauer sein möchte, ist es der falsche Schutz gegen die Bedrohung .

Machen Sie einen Schritt zurück: Was ist die Bedrohung, die wir wollen? zu schützen vor? Die Bedrohung, vor der wir uns schützen möchten, ist jede Person im öffentlichen Internet, die den normalen Authentifizierungsmechanismus umgehen kann. Das ist es, was diese "Script Kiddies" versuchen: mit SSH auf den Server zugreifen, obwohl sie nicht autorisiert sind. Ihr Vorgesetzter möchte insbesondere verhindern, dass diese Angreifer überhaupt eine SSH-Verbindung herstellen können.

Welche Standardtechnologie verhindert das Herstellen von Netzwerkverbindungen? Eine Firewall. Die Standardantwort auf dieses Problem besteht darin, Port 22 nur für externen Datenverkehr zu blockieren. Das größere Problem hierbei ist, dass SSH überhaupt für das öffentliche Internet verfügbar ist und die Firewall dies vollständig löst, während der dunkle Port es nur geringfügig verbirgt und die Verbindungen nicht wirklich verhindert. Wenn ein externer Zugriff erforderlich ist, ist die Standardantwort auf das Zulassen dieses autorisierten Zugriffs ein VPN in das Netzwerk. Dies würde sowohl Script Kiddies als auch Wissensangreifer blockieren, die herausfinden könnten, wie sie den Port finden, den Sie tatsächlich verwenden.

Wenn Sie gegen 1% der Angreifer verlieren, verlieren Sie immer noch . Sie benötigen Schutzmaßnahmen, die gegen 100% der Angreifer wirken. Wenn Sie stattdessen (bisher) erfolgreich 100% der Angreifer blockieren, müssen Sie über einen robusteren Schutz verfügen. Diese anderen Schutzmaßnahmen machen den undurchsichtigen Port irrelevant. Wenn dies (hoffentlich) der Fall ist, verwirrt die Verwendung des anderen Ports nur Personen, die mit den tatsächlichen Sicherheitspraktiken weniger vertraut sind, wie Sie selbst und höchstwahrscheinlich Verschwenden Sie die Zeit von Personen, die versuchen, einen legitimen Zugriff zu erhalten, wenn sie versuchen, eine Verbindung herzustellen (neues System ist nicht konfiguriert und muss jemanden nach dem richtigen Port fragen. Der Administrator hat vergessen, die Person über den nicht standardmäßigen Port zu informieren, und die Person muss sie erneut belästigen, um das Problem zu diagnostizieren usw.).

Deshalb sprechen wir über "Sicherheit durch Dunkelheit" und Kerckhoffs Prinzip. Wir sollten vermeiden, uns durch Praktiken abzulenken, die uns nicht wirklich schützen. Wir sollten unsere Zeit und Mühe für Schutzmaßnahmen sparen, die tatsächlich funktionieren, und das falsche Gefühl der "Sicherheit" vermeiden, das uns diese Verschleierungsmethoden geben.

Ich möchte hinzufügen, dass Sicherheit letztendlich ein Spiel um Ressourcen auf beiden Seiten ist. Zeit ist eine solche Ressource.

Diese Maßnahme verschwendet die Zeit eines Angreifers, sodass es nicht so schlimm ist. Sie können sich auch über die Ressourcen von Angreifern informieren, wenn diese noch eine Verbindung zu Ihrem benutzerdefinierten Port herstellen. Möglicherweise besteht ein höheres Interesse daran, Sie besonders anzusprechen.

Wenn dies jedoch Ihren Verwaltungsaufgaben einen erheblichen Aufwand hinzufügt, möchten Sie Ihre Zeit möglicherweise woanders investieren. Wenn nicht, dann tun Sie es, aber verlassen Sie sich nicht darauf.

Die Verwendung von nicht standardmäßigen Ports für stark gefährdete Anwendungen ist SEHR GUT. SSH weist viele Sicherheitslücken auf und 22 ist ein gängiger Standardport für Brute Force.

Davon abgesehen hängt es wahrscheinlich ab. Insbesondere in Unternehmensumgebungen kommt es häufig zu Brute-Force-Angriffen auf DMZ-Server gegen Port 22. Viele Unternehmen, beispielsweise im Finanzbereich, verwenden einen anderen Standardport für SSH / SFTP-Verkehr für eine gültige Datenübertragung zwischen Organisationen. P. >

In diesem Fall geht es eher darum, einen Teil des Rauschens herauszufiltern (Port 22 Brute Forcing), damit der andere Verkehr auf einem alternativen Port leichter überwacht werden kann. Jeder, der gut genug ist, kann einen offenen Port auf einem mit dem Internet verbundenen Server finden.

Dies wird als eine Form der Risikominderung oder Risikominderung angesehen.

Bearbeiten: Ich sollte hinzufügen: Wenn ich gut sage Praxis, ich beziehe mich auf bewährte Praktiken auf Ihren Geräten mit Internetanschluss. Alles, was sich hinter Ihren Firewalls befindet, ist im Allgemeinen sicher.