it-swarm.com.de

Bastion Server: Verwenden Sie TCP Weiterleitung VS Platzieren des privaten Schlüssels auf dem Server

Wir haben Bastion Server B. Wir müssen SSH von A über B nach C mit privatem Schlüssel.

Was ist die bessere Option:

  • Legen Sie den privaten SSH-Schlüssel auf den Server B. Wir haben gelesen, dass es eine schlechte Idee ist, dies in einer Produktionsumgebung zu tun.

    Von hier :

    Platzieren Sie niemals Ihre privaten SSH-Schlüssel auf der Bastion-Instanz. Verwenden Sie stattdessen die SSH-Agentenweiterleitung, um zuerst eine Verbindung zur Bastion und von dort zu anderen Instanzen in privaten Subnetzen herzustellen. Auf diese Weise können Sie Ihren privaten SSH-Schlüssel nur auf Ihrem Computer behalten.

  • Verwenden Sie die Weiterleitung von SSH-Agenten . Zum Einrichten der Agentenweiterleitung muss TCP Weiterleitung zugelassen werden. Beim Einrichten der Agentenweiterleitung wird auf dem Weiterleitungshost eine Socket-Datei erstellt. Dies ist der Mechanismus, mit dem der Schlüssel an das Ziel weitergeleitet werden kann. In den Bastion-Einstellungen bei AWS:

    TCP-Weiterleitung: Wenn Sie diesen Wert auf true setzen, wird die Weiterleitung TCP (SSH-Tunneling) aktiviert. Dies kann sehr nützlich sein, stellt jedoch auch ein Sicherheitsrisiko dar. Wir empfehlen daher, die Standardeinstellung (deaktiviert) beizubehalten, sofern dies nicht erforderlich ist

    Auch von hier :

    SSH Agent Forwarding gilt als schädlich

Was ist besser? Was ist mit der Alternative aus dem zweiten Link: ProxyCommand , ich verstehe, dass es beim Problem mit der Socket-Datei hilft, aber ich denke immer noch, dass ich TCP Weiterleitung, ist es also sicher genug?

10
user2503775

Verwenden Sie ProxyCommand oder ProxyJump

Ich würde empfehlen, ProxyCommand (oder noch besser ProxyJump zu verwenden, da die Syntax einfacher ist, aber meiner Meinung nach auf der Clientseite openssh 7.3+ erfordert), und Sie müssen keinen privaten Schlüssel auf dem bereitstellen Bastion, alles bleibt lokal.

Beispiel mit ProxyJump

Auf Ihrem Client-Computer schreiben Sie eine Datei unter ~/.ssh/config mit einem ähnlichen Inhalt wie unten:

Host bastion
  HostName bastion.example.com
  User bastion-user
  Port 22
  IdentityFile ~/.ssh/id_bastion

Host srvC
  HostName srvC.local
  User server-user
  IdentityFile ~/.ssh/id_protected_lan
  ProxyJump bastion

Dann mache ich ssh srvC verbindet Sie über B (Bastion) mit C, ohne dass der Agent weitergeleitet oder der private Schlüssel für die Bastion bereitgestellt wird.

Im obigen Beispiel ist "Bastion" ein Alias ​​für Ihren Bastion-Host und srvC ein Alias ​​für Ihren Server C. In HostName müssen Sie entweder IPs oder einen echten vollqualifizierten Domainnamen für Ihre Hosts eingeben. Für die Benutzer müssen Sie das User für den korrekten Anmeldenamen auf der Bastion und dem Server C aktualisieren. Schließlich ist das IdentityFile optional, wenn Sie einen lokalen Agenten (z. B. KeeAgent oder ssh-agent) verwenden ), aber wenn es nicht ausgeführt wird, funktioniert es auch und fragt Sie nach den einzelnen Schlüsselpassphrasen.

Bereitstellen der öffentlichen Schlüssel

Natürlich müssen Sie die Schlüssel public sowohl für bastion als auch für srvC bereitstellen. Sie können Folgendes verwenden (das $ -Zeichen dient nur zur Veranschaulichung der Eingabeaufforderung, geben Sie sie nicht ein):

$ ssh-copy-id -i ~/.ssh/id_bastion.pub \
   -o PreferredAuthentications=password \
   -o PubkeyAuthentication=no \
   bastion
$ ssh-copy-id -i ~/.ssh/id_protected_lan.pub \
   -o PreferredAuthentications=password \
   -o PubkeyAuthentication=no \
   srvC

Hinweis: Dies funktioniert nur, wenn die Kennwortauthentifizierung noch zulässig ist. Nach der obigen Bereitstellung und der Überprüfung, ob alles wie beabsichtigt funktioniert, sollten Sie die Kennwortauthentifizierung auf den beiden Servern nicht zulassen.

Beispiel mit ProxyCommand anstelle von ProxyJump

Wenn Sie eine ältere Version von OpenSSH haben, die ProxyJump (auf der Clientseite) nicht unterstützt, ersetzen Sie:

ProxyJump bastion

durch

ProxyCommand ssh -q -W %h:%p bastion

Soweit ich verstanden habe, ist dies ähnlich.

13
Huygens

Ich habe die Antwort zu ProxyJump gesehen. Lassen Sie uns über ProxyCommand sprechen.

Aber warte, warte! Ich kann dir schreiben , wie man den Server hackt , die Agent-Weiterleitung verwendet, wäre der Unterschied viel einfacher zu verstehen!

Lass uns hacken!

Für die grundlegenden Schritte: Sie können meinen Beitrag lesen hier

Grundlegende Schritte sind die folgenden:

  1. Erstellen Sie Bastionbenutzer
  2. Deaktivieren Sie die Root-Anmeldung
  3. Blockieren Sie Hacking-Versuche
  4. Port wechseln
  5. Konfigurieren Sie die Firewall
  6. Konfigurieren Sie SELinux

Verwendung von AgentForwarding

-Erstellen Sie die Konfiguration in ~/.ssh/config

  Host bast
        Hostname BASTION_IP
        ForwardAgent yes
        User bastion

- Fügen Sie Ihren Authentifizierungsschlüssel zu ssh-agent hinzu

ssh-add ~/.ssh/name_rsa

-Verbinden Sie sich mit Bastion Hos

ssh bast

- Verbinden Sie den Anwendungsserver mit der Bastion

 ssh [email protected] -p PORT

Hacken!

Sie können mir die Frage stellen:

  • Ist mein Server sicher? Und die Antwort ist ganz einfach:

    • NEIN!
  • Warum?

    • Weil Sie die SSH Agent-Weiterleitung verwenden!
  • Und wo ist das Problem?

    • Weil die Weiterleitung von Agenten gefährlich ist und als schädlich angesehen wird.
  • Warum?

    • Lassen Sie uns alles von innen nach außen erklären: Wenn Sie Bastion Host verbinden, wird Ihr herrlicher SSH-Agent weitergeleitet. Dies bedeutet, dass der Socket so eingerichtet wird, dass jemand diese Socket-Daten für den Zugriff auf Ihre Server verwenden kann. Stellen Sie sich vor, Ihr Bastion-Server ist kompromittiert. Wenn jemand über ausreichende Berechtigungen für Ihren Linux-Server verfügt, verwendet er nur Ihre Socket-Informationen. Infolgedessen kann auf alle Ihre Server zugegriffen werden. Ich weiß, dass das Kompromissfenster sehr klein ist, da es davon abhängt, wie viel Zeit Sie mit dem Bastion Host verbunden sind. Aber möchten Sie wirklich das Risiko eingehen, wenn Sie andere Optionen wie ProxyCommand haben? Verwenden Sie daher einfach ProxyCommand!

Wie kann man Server hacken, wenn man den Bastion-Host kompromittiert hat?

Ziel verfolgen

Im Verzeichnis/tmp sehen Sie möglicherweise Folgendes:

[[email protected] tmp]# ll
total 12
drwx------  2 bastion bastion 4096 Sep  7 17:35 ssh-mKX88v0Vlo

Öffnen wir die temporäre Datei

[[email protected] tmp]# cd ssh-mKX88v0Vlo/
[[email protected] ssh-mKX88v0Vlo]# ll
total 0
srwxr-xr-x 1 bastion bastion 0 Sep  7 17:35 agent.10507

Sehen wir uns Verbindungen zu dieser Prozess-ID an.

netstat -nxp | grep  10507

ergebnis:

unix  [ ]   STREAM     CONNECTED     501384   10507/sshd: bastion

und wer ist verbunden?

lsof -i -a -p 10507

ergebnis:

COMMAND  PID   USER  FD  TYPE DEVICE SIZE/OFF NODE NAME
sshd    10507 bastion  3u  IPv4 501301  0t0  TCP *IP*:ssh->*IP*:8279 (ESTABLISHED)

Wir können auch Socket-Dateien sehen:

cd /proc/10507/fd/
ls

ergebnis:

lrwx------ 1 root root 64 Sep  7 17:46 0 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 1 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 10 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 14 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 15 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 2 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 3 -> socket:[501994]
lrwx------ 1 root root 64 Sep  7 17:46 4 -> socket:[502069]
lrwx------ 1 root root 64 Sep  7 17:46 5 -> socket:[502072]
l-wx------ 1 root root 64 Sep  7 17:46 6 -> /run/systemd/sessions/1836.ref
lr-x------ 1 root root 64 Sep  7 17:46 7 -> pipe:[502079]
l-wx------ 1 root root 64 Sep  7 17:46 8 -> pipe:[502079]
lrwx------ 1 root root 64 Sep  7 17:46 9 -> socket:[502080]

Und was passiert , wenn der Client mit dem Remote-Server verbunden wird ? wir werden sehen:

lrwx------ 1 root root 64 Sep  7 17:46 0 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 1 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 10 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:48 11 -> socket:[502267]
lrwx------ 1 root root 64 Sep  7 17:46 14 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 15 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 2 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 3 -> socket:[501994]
lrwx------ 1 root root 64 Sep  7 17:46 4 -> socket:[502069]
lrwx------ 1 root root 64 Sep  7 17:46 5 -> socket:[502072]
l-wx------ 1 root root 64 Sep  7 17:46 6 -> /run/systemd/sessions/1836.ref
lr-x------ 1 root root 64 Sep  7 17:46 7 -> pipe:[502079]
l-wx------ 1 root root 64 Sep  7 17:46 8 -> pipe:[502079]
lrwx------ 1 root root 64 Sep  7 17:46 9 -> socket:[502080]

Wir können sogar sehen, ob eine Socket-Datei mit netstat verwendet wird:

unix  3 [ ]  STREAM  CONNECTED  502267  10561/sshd: 
                     bastion  /tmp/ssh-oVoMXC6vb8/agent.10561
unix  3  [ ] STREAM     CONNECTED     502072   10561/sshd:  bastion 

Socket-Informationen und IP-Adresse stehlen

Jetzt müssen wir die Socket-Informationen stehlen, während die Sitzung des Bastion Host geöffnet ist . Oh, wir brauchen auch Zielserver-IP , also benutze einfach netstat:

netstat -tn

Der letzte Schritt zur Verwendung der weitergeleiteten Socket-Datei

eval "$(ssh-agent -s)"
SSH_AUTH_SOCK=/tmp/ssh-EAKxOdL4fl/agent.10507

Überprüfen Sie, ob der Schlüssel geladen ist .

ssh-add -l

ergebnis sollte so etwas sein :

2048 SHA256:2Psdl..B5KQ /home/usr/.ssh/name_rsa (RSA)

Server ist gehackt, wie kann man das Sicherheitsproblem beheben?

Proxy-Befehl

Host app
    Hostname *.*.*.*
    IdentityFile ~/.ssh/your_rsa
    User *******
    Port ****
    ProxyCommand ssh -W %h:%p bast

Host bast
     Hostname *.*.*.*
     ForwardAgent no
     User ******

Für grundlegende Operationen: Wie man Dateien über die Server überträgt (von Client zu Server, Server zu Client), können Sie in meinem Beitrag lesen hier

Fazit

  • Wenn Sie Bastion Host verwenden, verwenden Sie nicht AgentForwarding, sondern ProxyCommand
  • Verwenden Sie zur Authentifizierung immer Benutzer ohne Rootberechtigung
  • Verwenden Sie eine Firewall und blockieren Sie alle unnötigen Verbindungen.
  • Verwenden Sie SELinux (im Allgemeinen)
  • Blockieren Sie die IP-Adresse, die mehrmals versucht, sich mit falschen Anmeldeinformationen anzumelden
  • Wenn dies nicht erforderlich ist, erteilen Sie dem Benutzer keine Sudo-Berechtigung
  • Überwachen Sie Ihren Server
  • Aktualisieren Sie Ihren Server auf Sicherheitspatches

Weitere Informationen finden Sie in meinem Blog . Zusätzlich habe ich einige Screeenshots, so dass es für Sie hilfreich sein kann.

5
grep

Verwenden Sie einfach SSH-Agentenweiterleitung wie die meisten anderen.

  • Die Schlüssel befinden sich im ssh-Agenten auf Ihrem Laptop.
  • Sie melden sich bei Bastion an und werden über den Agenten authentifiziert.
  • Von dort aus melden Sie sich bei Ihrem Zielhost an, wobei die Authentifizierungsanforderung an Ihren Laptop zurückgeleitet wird .

Vorteil: In der Bastion sind keine Schlüssel gespeichert, die missbraucht werden können.

Ich hoffe, das hilft :)

4
MLu