Frage:
Ist das Starten einer AWS-Instanz mit nur ssh an Port 22 erheblich unsicher?
javadba
2020-06-26 01:51:03 UTC
view on stackexchange narkive permalink

Wie kann eine aws-Instanz auf 0.0.0.0 geöffnet bleiben, es sei denn, jemand hat meinen privaten ssh-Schlüssel, aber nur an Port 22 über ssh unsicher?

enter image description here

Der SSH-Schlüssel wird an eine kleine Gruppe von Personen verteilt. Ich möchte die Quell-IP-Adressen nicht im Voraus angeben müssen.

Ich sehe eine ähnliche Frage SSH-Brute-Force-Eintrag in der aws ec2-Instanz.

Wenn Sie die kennwortbasierte Anmeldung über SSH deaktiviert haben, ist es sehr schwierig, eine SSH-Anmeldung mit einem privaten Schlüssel brutal zu erzwingen (

Vielleicht deckt dies dies ab? In der Sicherheitswelt erhalten Sie keine zweite Chance.

"Wenn jemand nicht über meinen privaten SSH-Schlüssel verfügt, wie kann eine aws-Instanz für 0.0.0.0 geöffnet bleiben, jedoch nur an Port 22 über SSH unsicher?"Dies ist nicht der Fall, es sei denn, Ihr SSH-Server weist Fehler auf, die ausgenutzt werden können (nicht unbekannt, denken Sie an die OpenSSH-Hacks von 2003 oder so) oder ist schlecht konfiguriert.Es ist jedoch interessant, es auf Port 22 zu belassen. Sie erhalten sofort Brute-Forcing-Versuche von berüchtigten IP-Adressen.Der AWS-Text ist ein Standard-Anwaltsschutz.
Ich denke, von _ "Wir empfehlen ... nur den Zugriff von bekannten IP-Adressen zuzulassen" _ (amazon) auf _ "trivial unsicher" _ (Fragentitel) ist dort ein kleiner Sprung;)
"_Der SSH-Schlüssel würde verteilt__"?Ähm, nein.Jede Benutzer / Computer-Kombination sollte einen eigenen Schlüssel haben.Es sollte wirklich von jedem Benutzer generiert und sein öffentlicher Schlüssel in seinem Konto auf dem Server eingerichtet werden.
Der obige Kommentar von @jcaron sollte mehr Aufmerksamkeit erhalten.Verteilen Sie nicht "den" (singulären) Schlüssel, den die AWS-Instanz generiert.Lassen Sie jeden Benutzer seinen eigenen öffentlichen Schlüssel zum Host hinzufügen.Das Thema der Frage nicht streng ansprechen, aber wichtig.
Keine Antwort auf Ihre Frage, aber Sie könnten daran interessiert sein, dass Sie mit Systems Manager eine Verbindung über SSH herstellen können, ohne Port 22 für öffentliche IPs zu öffnen und ohne einen SSH-Schlüssel zu verwenden
"Ich möchte ihre Quell-IP-Adressen lieber nicht im Voraus angeben".Sie müssen das nicht im Voraus tun.Fragen Sie nach der IP-Adresse, von der aus sie auf den Server zugreifen, während Sie gleichzeitig ihren öffentlichen Schlüssel erhalten.Wenn Sie dies als Teil der Einrichtung eines Benutzerzugriffs betrachten, kann dies ganz natürlich befolgt werden.
Dreizehn antworten:
Demento
2020-06-26 02:20:29 UTC
view on stackexchange narkive permalink

Die Antwort hängt von Ihrem Risikoappetit ab. Durch die Beschränkung des Zugriffs auf den SSH-Port auf nur bekannte IP-Adressen wird die Angriffsfläche erheblich reduziert. Unabhängig davon, welches Problem auftreten kann (Lecks von privaten Schlüsseln, 0 Tage in SSH usw.), kann es nur von einem Angreifer ausgenutzt werden, der von diesen spezifischen IP-Adressen stammt. Andernfalls kann der Angreifer von überall auf den Port zugreifen. Dies ist besonders schlimm, wenn eine nicht gepatchte SSH-Sicherheitsanfälligkeit mit einem in freier Wildbahn verfügbaren Exploit vorliegt.

Es liegt an Ihnen, zu entscheiden, wie wichtig das System und sein System sind Daten sind für Sie. Wenn dies nicht so kritisch ist, kann der Komfort eines für die Welt offenen SSH-Ports angemessen sein. Ansonsten würde ich empfehlen, den Zugriff für alle Fälle zu beschränken. Schwere 0-Tage in SSH tauchen nicht täglich auf, aber Sie wissen nie, wann der nächste sein wird.

Danke - ich mache einen kleinen Prototyp mit nur zufälligen Testdaten.Dies kann verwendbar sein.
@javadba wiederholt nur, was Demenz gesagt hat, also werden wir.Es gibt kein "sicher" oder "unsicher".Es gibt immer nur "sicher genug für mich".Die Sicherheitsanforderungen für eine anonyme Website zur Abstimmung von niedlichen Katzenbildern oder nicht die gleiche wie für die Website, auf der Sie Atomangriffe starten (was natürlich nicht einmal eine Website sein sollte !!!).Amazon gibt Best Practices, aber nicht alle Sicherheitsmaßnahmen sind die Kosten für alle wert.
@ConorMancone ja fair genug.Ich freue mich über das Feedback, um sicherzustellen, dass dies zumindest keine Situation zum Mitnehmen ist.
+1 für "0-Tage in SSH" und "SSH-Sicherheitslücke mit einem in freier Wildbahn verfügbaren Exploit".
Wie lege ich eine Quell-IP-Adresse fest?Firewalld ist nicht dazu in der Lage, und die Verwendung von iptables parallel zu Firewalld ist ein Chaos, das weitere Sicherheitsbedenken aufwirft.
@Alexis, die im OP enthaltene Warnung, erklärt Ihnen, wie Sie dies tun: indem Sie Ihre Sicherheitsgruppenregeln aktualisieren.Weitere Informationen zur Funktionsweise von IAM in AWS finden Sie in der offiziellen AWS-Dokumentation unter [Identitäts- und Zugriffsverwaltung für Amazon VPC] (https://docs.aws.amazon.com/vpc/latest/userguide/security-iam.html).
Es war eine AWS-spezifische Frage, richtig, sorry.
iBug
2020-06-26 13:12:25 UTC
view on stackexchange narkive permalink

Der SSH-Schlüssel wird an eine kleine Gruppe von Personen verteilt.

Nein, tun Sie das nicht. Teilen Sie niemals private Schlüssel. Lassen Sie Ihre Leute selbst Schlüsselpaare generieren und ihre öffentlichen Schlüssel sammeln. Ergreifen Sie angemessene Maßnahmen, um sicherzustellen, dass die Pubkeys tatsächlich von den richtigen Personen stammen.

Wenn Ihnen der Aufwand nichts ausmacht, können Sie stattdessen ein einheitliches Authentifizierungsschema ausprobieren, z. B. eine SSH-Zertifizierungsstelle, damit Sie unterschreiben können Diese Zertifikate können beide sicher verteilt werden (das Zertifikat ist ohne den privaten Schlüssel unbrauchbar).

LDAP ist noch besser, aber ich würde mich nicht um kleine Server kümmern. Das Einrichten und Verwalten ist einfach zu komplex.


Das Öffnen eines SSH-Ports für das Internet ist per se nicht unsicher. Es hängt davon ab, wie es sich authentifiziert. Das SSH-Scannen erfolgt jede Minute im Internet. Lassen Sie es nur einen Tag lang eingeschaltet und überprüfen Sie /var/log/auth.log auf ungültige Benutzernamen.

Ich würde sagen, solange Sie die Authentifizierung mit öffentlichem Schlüssel und verwenden Wenn Sie den privaten Teil sicher halten, kann niemand in praktischer Zeit Brute-Force auf Ihren Server anwenden, da bei gängigen SSH-Implementierungen wie OpenSSH nicht häufig 0 Tage auftauchen. Die Freigabe eines privaten Schlüssels ist weder sicher noch praktisch. Der Schlüssel kann während der Übertragung durchgesickert sein, wahrscheinlich irgendwann, von dem Sie nicht einmal wissen. Das ist gefährlich.

Warum ein Zertifikat?Lassen Sie sich von Personen ihre öffentlichen Schlüssel senden, und fügen Sie diese öffentlichen Schlüssel zu ".ssh / authorized_keys" hinzu.Achten Sie angemessen darauf, dass der öffentliche Schlüssel tatsächlich von der Person stammt, von der er angeblich stammt.So wurde es ursprünglich entworfen.
Guter Fang, dass das OP keine privaten Schlüssel teilen sollte, aber ich bin mit den meisten anderen, die Sie gesagt haben, nicht einverstanden.Guntrams Vorschlag ist die viel bessere Lösung, und rohe Gewalt ist nicht das einzige Problem.Das Risiko von 0 Tagen ist größer.All dies hängt jedoch vom Risikoappetit des OP ab.
Ich habe noch nie von "SSH CA" gehört (bin aber mit X509-CAs und SSH vertraut). Beziehen Sie sich darauf?https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/sec-using_openssh_certificate_authentication
Ich bin damit einverstanden, dass das Teilen von SSH-Schlüsseln wie das Teilen von Passwörtern eine schlechte Sicherheitspraxis ist.Dieser Typ hat jedoch einen einzigen Server, den er der Welt aussetzen möchte, und er ist nicht bereit, ihn hinter einem privaten Subnetz und einem VPN zu schützen.Es ist unwahrscheinlich, dass er eine SSH-Zertifizierungsstelle einrichten wird, um die gemeinsame Nutzung von Schlüsseln zu vermeiden.
@CaptainMan Ja das war's.Zusammenfassend als "ssh-keygen -s".
Einige Details zum ssh ca-Konzept: https://engineering.fb.com/security/scalable-and-secure-access-with-ssh/
Ich finde es ironisch, dass eine Antwort (und Kommentare) sagt: * Es gibt kein "sicheres" oder "unsicheres".Es gibt immer nur "sicher genug für mich" * und eine andere Antwort lautet * Das Teilen eines privaten Schlüssels ** ist nicht sicher ***;)
@AndrewSavinykh Die Freigabe eines privaten Schlüssels für eine EC2-Instanz sollte für die meisten Menschen nicht sicher genug sein :)
Criggie
2020-06-27 06:35:25 UTC
view on stackexchange narkive permalink

Antwort Nein, nicht trivial unsicher, aber immer noch nicht ideal.

Ich verwalte mehrere AWS-Instanzen, und während die meisten von ihnen Sicherheitsgruppen haben, die den eingehenden SSH-Zugriff einschränken, gibt es eine Aus geschäftlichen Gründen muss einer von ihnen auf Port 22 auf alle Verbindungen warten.

Als solcher wird dieser Host jeden Tag von Tausenden Script-Kid-Verbindungen (Skiddy) getroffen. Dies wird bei der Anmeldung durch MOTD-Nachrichten wie

  angezeigt. Letzte Anmeldung: Fr 19 Jun 23:17:36 UTC 2020 auf pts / 2Letzte fehlgeschlagene Anmeldung: Sa 27 Jun 01:00:44 UTC 2020 ab 120.70.103.239 auf ssh: notty Seit dem letzten erfolgreichen Login gab es 21655 fehlgeschlagene Anmeldeversuche. Host1234 ~ # dateSat Jun 27 01:12:18 UTC 2020  

Das sind also ungefähr 2.500 pro Tag oder a hundert pro Stunde. Sicherlich handelt es sich bei den meisten von ihnen lediglich um automatisierte Tests. Was passiert jedoch, wenn eine Zero-Day-Sicherheitsanfälligkeit gefunden und ausgenutzt wird?
Indem Sie Ihre Exposition begrenzen, reduzieren Sie das Risiko. Stark >

Zu den Lösungen gehören eine / einige / alle:

  • Verwenden Sie AWS-Sicherheitsgruppen, um nur Verbindungen von bestimmten IP-Adressen im Internet zuzulassen.
  • Verwenden Sie ein VPN Lösung und erfordern, dass SSH über das VPN durchgeführt wird. Das VPN kann alle Quellen abhören, über Zertifikate und 2FA verfügen und im Allgemeinen weitere Ebenen hinzufügen. OpenVPN funktioniert gut, oder es gibt mehrere AWS-Angebote, die dieselbe Aufgabe ausführen.
  • SSH an einen anderen Port verschieben - dies ist keine zusätzliche Sicherheit, verringert jedoch die Anzahl der SSH-Verbindungsversuche und damit die Lärm. Jeder, der sein Geld wert ist, scannt ohnehin alle Ports, nicht nur die Standardeinstellungen.
  • Wenn Sie promisku auf SSH warten MÜSSEN, suchen Sie nach einer Lösung wie fail2ban Dadurch werden Quellen zu /etc/hosts.deny hinzugefügt, wenn sie mehr als X Mal in Y Minuten fehlschlagen, und können sie nach etwa einem Tag wieder entfernen.
  • Erkunden Sie IPv6-like Durch Ändern des Überwachungsports erhöht IPv6 die Zeit für das Scannen, sodass Skiddies mehr Platz zum Suchen haben. Das Scannen in Version 6 findet jedoch weiterhin statt.

Für mich handelt es sich bei den sshing-in-Geräten um Hardware, daher verfügen sie über ein gültiges Benutzerzertifikat und werden immer erfolgreich authentifiziert. Wir haben ein Skript geschrieben, das / var / log / secure scannt und nach "Benutzer nicht gefunden" oder ähnlichem sucht und diese Quellen sofort dauerhaft zur Datei hosts.deny hinzufügt.
Wir haben überlegt, dies zu erweitern, um ganze Subnetze basierend auf Lookups zu blockieren, aber das wurde noch nicht benötigt.

Wir blockieren derzeit:

  host1235 ~ # grep -ci all /etc/hosts.*/etc/hosts.allow:79/etc/hosts.deny:24292 

Ich werde keine Liste fehlerhafter Quell-IPs freigeben , da einige Standorte IP-Adressen als personenbezogene Daten (oder personenbezogene Daten) betrachten.

Beachten Sie, dass sich unsere Office-IPs in hosts.allow befinden, die die hosts.deny Datei. Wenn also jemand eine Anmeldung von einem Büro aus fehlschlägt, werden menschliche Benutzer nicht gesperrt.

Bitten Sie um Klarstellung - ich weiß, dass ich viele Details von Hand gewinkt habe.

Ich kann für fail2ban bürgen.Sogar das Hosten eines Raspberry Pi in meinem Heimnetzwerk führte zu Brute-Force-Angriffen!
Zusätzlich zu den vorhandenen Ebenen, die Sie beschrieben haben, ist es möglich, zusätzlich eine Art 2FA-Lösung zu implementieren, die erforderlich wäre, wenn die Anmeldungen von zuvor nicht sichtbaren IPs (oder IPs, die keine Whitelist sind) versucht werden.?Mein Problem ist, dass ich Konnektivität von einem mobilen Hotspot möchte, der jedoch dazu neigt, die IP sehr oft zu ändern.
Eine andere Sache über das Ändern der Ports von 22: Soweit ich weiß, können sie immer noch durch einen gründlichen nmap-Scan entdeckt werden - wenn dies der Fall ist, ist es möglich, sie zu fälschen?Zum Beispiel einige "Honeypot" -Ssh-Ports erzeugen, die nirgendwohin führen (oder zu einem leeren Docker-Container?) Und im Wesentlichen den richtigen Port verbergen, der zur Maschine führt?
Captain Man
2020-06-27 00:52:15 UTC
view on stackexchange narkive permalink

Möglicherweise möchten Sie AWS Session Manager verwenden. Als mein Unternehmen AWS verwendete, schien es kein sehr bekanntes Tool zu sein. Im Wesentlichen können Sie sich einfach über den Browser (oder die Befehlszeile † sup>) über die AWS-Konsole bei der EC2-Instanz anmelden. Sie verwenden IAM-Richtlinien zum Autorisieren anstelle von SSH-Schlüsseln.

Auf die Gefahr hin, wie eine Werbung zu klingen, zitiere ich den relevanten Teil der Dokumentation.

  • Keine offenen eingehenden Ports und keine Notwendigkeit, Bastion-Hosts oder SSH-Schlüssel zu verwalten

    Wenn Sie eingehende SSH-Ports und Remote-PowerShell-Ports auf Ihren Instanzen offen lassen, erhöht sich die Risiko, dass Entitäten nicht autorisierte oder böswillige Befehle auf den Instanzen ausführen. Mit dem Sitzungsmanager können Sie Ihre Sicherheitslage verbessern, indem Sie diese eingehenden Ports schließen und SSH-Schlüssel und -Zertifikate, Bastion-Hosts und Sprungboxen nicht mehr verwalten können.

Wenn Sie also den Verdacht haben, Port 22 offen zu lassen, ist dies ein Problem (und ich denke, Dementos Antwort deckt gut ab, ob Sie sollten oder nicht) Dies ist ein Ansatz, mit dem Sie ihn geschlossen halten können, während Sie weiterhin den SSH-Zugriff zulassen (zumindest unter bestimmten Gesichtspunkten).


†: Es gibt ein Drittanbieter-Tool zur Verwendung des Sitzungsmanagers von der Kommandozeile hier.

Die OP-Frage zur SSH-Sicherheit wird nicht wirklich beantwortet, aber dies ist in der Tat die richtige Lösung.SSM kann auch einfach [über die Befehlszeile verwendet] werden (https://aws.nz/projects/ssm-session/).
+1 hier ist SSM ein großartiges Werkzeug.
@MLu Ich habe das Tool zur Antwort hinzugefügt.Wenn Sie (oder jemand anderes) wissen, wie Sie dies mit Tools von Erstanbietern tun können, werde ich dies ebenfalls bearbeiten.:) :)
Paul Draper
2020-06-27 00:14:09 UTC
view on stackexchange narkive permalink

A. Schlüsselbasiertes SSH ist sehr sicher und weithin vertrauenswürdig. Es besteht natürlich immer die Möglichkeit einer Sicherheitsanfälligkeit (z. B. Heartbleed), und die Begrenzung durch IP erhöht die Sicherheit. Es besteht jedoch die Gefahr, dass Sie auf andere Weise eher kompromittiert werden (z. B. wenn Sie für die AWS-Konsole phishing werden).

B. Erstellen Sie mehrere SSH-Schlüssel, um mögliche Kompromisse bei der Freigabe zu vermeiden. (Obwohl ich verstehe, dass dies unpraktisch sein kann, da AWS beim ersten Start der Instanz nur einen SSH-Schlüssel zulässt.)

Ángel
2020-06-27 06:00:33 UTC
view on stackexchange narkive permalink

Nein. Es ist nicht trivial unsicher, einen OpenSh-Server zu öffnen, um Verbindungen von überall zu empfangen.

OpenSh hat eine wirklich gute Sicherheitsbilanz, und es ist unwahrscheinlich, dass dort fast ein neuer "Killer-Exploit" auftaucht

Beachten Sie jedoch, dass Ihre Instanz viele Bruteforcing-Versuche aus der ganzen Welt erhält. Dies gilt nicht für ein schwaches Kennwort!

  • Deaktivieren Sie die Kennwortauthentifizierung auf SSH-Serverebene. Daher sind SSH-Schlüssel für die Anmeldung erforderlich.
  • Teilen Sie keinen privaten Schlüssel! Jeder, der Zugriff auf den Server benötigt, sollte einen eigenen Schlüssel (lokal generiert, nie gesendet) zum Server hinzufügen lassen. Dies verbessert die Nachverfolgbarkeit und ermöglicht das Entfernen des Zugriffs von einer einzelnen Person. Wenn ein Schlüssel im Verdacht steht, kompromittiert zu werden, kann er leicht ersetzt werden, und die Probleme beim Verteilen privater Schlüssel werden beseitigt.
  • Sie können den Server auf einen verschieben anderer Port. Es ist selbst keine Sicherheitsmaßnahme, aber es gibt Ihnen sauberere Protokolle.
  • Sie können den Zugriff weiter einschränken, indem Sie wissen, von wo aus keine Verbindung hergestellt wird. Möglicherweise ist es Ihnen nicht möglich, eine Whitelist mit den genauen IP-Adressen festzulegen, die verwendet werden sollen, aber Sie wissen möglicherweise, aus welchem ​​Land sie verwendet werden. Oder dass niemand von dort ein Geschäft hat, das sich dort verbindet.

Die Warnung von AWS ist gut, und es ist gut, eingehende Quellen einzuschränken, wenn Sie können, aber dies nicht zu tun, ist nicht unsicher. Beachten Sie, dass AWS nicht weiß, ob Sie SSH-Schlüssel benötigen oder ob Ihre Anmeldeinformationen root / 1234 sind. Leider spiegelt diese Warnung die hohe Anzahl von Instanzen wider, die aufgrund trivial dummer Anmeldeinformationen kompromittiert werden.

Peter Green
2020-06-26 23:51:48 UTC
view on stackexchange narkive permalink

openssh hat einen ziemlich guten Sicherheitsruf. Wenn ich mein Debian-Sicherheitswarnungsarchiv durchsuche (dies ist keine erschöpfende Suche, gab es möglicherweise Probleme in Bibliotheken, die von openssh verwendet wurden und die ich nicht entdeckt habe). Ich sehe ungefähr eine Warnung pro Jahr, aber die meisten davon scheinen relativ geringfügige Probleme zu sein (einige Probleme bei der Aufzählung von Benutzernamen, einige Probleme im Client, Probleme bei der Privilegieneskalation für Benutzer, die bereits auf einem Server mit nicht standardmäßiger Konfiguration authentifiziert sind, einige Umgehungen für Einschränkungen von Umgebungsvariablen

Allerdings fällt ein Fehler auf. Im Jahr 2008 gab es einen wirklich bösen Fehler in Debians openssl, der bedeutete, dass Schlüssel mit openssl oder openssh auf anfälligem Debian generiert wurden Systeme könnten brutal erzwungen werden. Darüber hinaus wurden DSA-Schlüssel, die lediglich auf einem anfälligen System verwendet verwendet wurden, möglicherweise gefährdet, wenn der Angreifer Datenverkehr mit dem anfälligen Schlüssel hatte (entweder durch Sniffing oder im Fall von Hostschlüsseln von) Herstellen einer Verbindung zum Server) Wenn eine solche Sicherheitsanfälligkeit öffentlich wird, haben Sie möglicherweise nur sehr begrenzte Zeit, um sich anzupassen, bevor die Botnets sie verwenden.

Es wird daher empfohlen, die Menge an Dingen zu minimieren, die Sie direkt dem Server aussetzen Internet, damit wann Es kommt ein wirklich böser Fehler, den Sie schnell beheben können. Ein Notfall-Update für eine Handvoll Systeme durchzuführen ist viel besser als für jedes System gleichzeitig.

Dies ist natürlich mit Kosten verbunden, da nur auf einen Server von zugegriffen werden kann Systeme in Ihrem VPN oder die Notwendigkeit, über mehrere Server zu springen, können zu einer wichtigen PITA werden. Letztendlich müssen Sie entscheiden, welches Gleichgewicht für Sie richtig ist.

TrypanosomaBruceii
2020-06-27 05:55:28 UTC
view on stackexchange narkive permalink

Nein, es ist nicht "trivial unsicher", aber AWS hat nie gesagt, dass dies der Fall ist. Stattdessen wird empfohlen, etwas anderes zu tun, da etwas anderes den Standard-Best Practices entspricht. Sie können diese Best Practices vermeiden, wenn Sie der Meinung sind, dass Sie es besser wissen. Da in Ihrem OP jedoch die Idee erörtert wird, einen privaten Schlüssel für mehrere Benutzer freizugeben, würde ich dringend empfehlen, nur jede Sicherheitsbenachrichtigung einzuhalten, die AWS Ihnen sendet. Im schlimmsten Fall verschwenden Sie ein wenig Zeit damit, Dinge zu überarbeiten. Bestenfalls vermeiden Sie schwerwiegende Folgen.

tankmek
2020-06-27 18:18:06 UTC
view on stackexchange narkive permalink

Wenn jemand nicht über meinen privaten SSH-Schlüssel verfügt, wie lässt man eine aws-Instanz auf 0.0.0.0 offen, aber nur auf Port 22 über SSH unsicher?

Sie sind nicht "unsicher" Erhöhen Sie das Risiko einer Verletzung nur, wenn in SSH eine unbekannte oder nicht gepatchte Sicherheitsanfälligkeit vorliegt.

Da Sie AWS verwenden, können Sie mithilfe von IAM den Teammitgliedern die Möglichkeit geben, die Remote-IP-Adressen hinzuzufügen, die sie von sich selbst erhalten .

eckes
2020-06-28 05:00:06 UTC
view on stackexchange narkive permalink

Beachten Sie, dass diese Warnung einige zusätzliche Ebenen enthält. Zunächst möchten Sie den Computern in Ihrem internen Subnetz möglicherweise überhaupt keine öffentliche IP-Adresse zuweisen.

Anstelle von (nur) IP-Filterung in Sicherheitsgruppen- und VPC-ACLs, bei denen das Netzwerk nicht ohne Sprung erreichbar ist Host, Sitzungsmanager oder VPN sind eine zusätzliche Messung.

Dies hilft auch dabei, die Sicherheitsgruppen nicht versehentlich neu zu konfigurieren (und zusätzliche Netzwerkdienste beizubehalten und zuzulassen). Es hilft auch gegen Exploits auf Kernel-IP-Ebene oder DOS-Risiken. Dies alles ist Teil der Sicherheit in tiefgreifenden und vielschichtigen Ansätzen, die sich an dem Prinzip orientieren, keinen vermeidbaren Zugriff zuzulassen - auch wenn Sie dadurch keine unmittelbare Bedrohung finden.

Bevor die Öffentlichkeit Menschen trübt Dies gilt auch für softwaredefinierte Architekturen in der Cloud, bei denen die Mikrosegmentierung eigentlich die Norm sein sollte.

CONvid19
2020-06-28 13:14:22 UTC
view on stackexchange narkive permalink

Kurze Antwort:

  • SSH-Standardport ändern
  • SSH-Standardbanner entfernen
  • Private Schlüssel nicht freigeben
  • Zulässige IPs einschränken
  • Fügen Sie einen täglichen Cronjob hinzu, um Sicherheitsupdates zu installieren
Ich würde hinzufügen, um Root-Login und Passwort-Logins zu deaktivieren.
trognanders
2020-06-29 05:05:50 UTC
view on stackexchange narkive permalink

Die ordnungsgemäße Konfiguration von sshd ermöglicht es zufälligen Personen nicht, sich absichtlich bei Ihrer ec2-Instanz anzumelden. Eine Fehlkonfiguration oder Sicherheitsanfälligkeit ist jedoch möglich.

Die Verwendung von Port 22 ist häufig und ein enorm beliebtes Ziel für das Scannen von Sicherheitslücken. Bei einer offenen Firewall-Konfiguration werden Ihre sshd -Konfiguration und Software getestet.

Die meisten EC2-Benutzer stellen SSH nur für sich selbst bereit und bieten es daher als Öffentlichkeit an Service ist definitiv ein unnötiges Risiko.

Wenn Sie Endbenutzern SSH bereitstellen möchten, handelt es sich um einen öffentlichen Service. Stellen Sie fest, dass Sie diese Verantwortung übernehmen. Einige bewährte Methoden sind (ohne darauf beschränkt zu sein): Bearbeiten Sie die Konfiguration sehr sorgfältig und stellen Sie sicher, dass Updates regelmäßig installiert werden.

Jemand, der oben erwähnt wurde, verwendet Amazon Session Manager .

R.. GitHub STOP HELPING ICE
2020-06-29 08:20:07 UTC
view on stackexchange narkive permalink

Vorausgesetzt, Sie konfigurieren es richtig , ist es nicht nur nicht "wesentlich unsicher". Es ist überhaupt nicht anfällig, abgesehen von weltweiten Vulns auf Katastrophenebene, von denen nicht erwartet wird, dass sie existieren. Im Ernst, die AWS-Verwaltungsinfrastruktur ist ein schwächeres Glied als OpenSSH.

Nun gibt es viele Möglichkeiten, sie falsch zu konfigurieren, einschließlich der in Ihrer Frage erwähnten, Verteilung von a gemeinsamer privater Schlüssel. Tu das auf keinen Fall. Sie sollten niemals mit dem privaten Schlüssel einer anderen Person umgehen. Sie sollten Ihnen ihre öffentlichen Schlüssel geben. Außerdem sollten keine anderen Authentifizierungsoptionen als pubkey aktiviert werden - keine Kennwörter, keine GSSAPI, keine PAM usw.



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 4.0-Lizenz, unter der er vertrieben wird.
Loading...