Jan 20

Jetzt weiss ich auch warum netcat das “Schweizer Taschenmesser” der Netzwerktechnik genannt wird. Gewaltig das Ding.

Doch von vorne – Folgende Ausgangssituation:

Man hat eine Maschine (BOB), die irgendwo hinter einer (SOHO-)Firewall steht. Diese SOHO-Speedport-Dingsdas sind meist so konfiguriert das nix reindarf, aber alles raus. Jetzt möchten wir aber gerne von einer anderen Kiste (die irgendwo im Internet hinter einem etwas eleganter konfigurierten Linux-Router steht, und hier mal ALICE heissen soll) per ssh auf BOB zugreifen. Ferner nehmen wir an, wir hätten gerade (temporär) Zugriff auf BOB (lokal, wie auch immer) und könnten auch auf ALICE rumtoben.

Problem: Direkt von einem Client hinter ALICE gehts nicht, weil unserer Client (Nennen wir ihn PLUTO – der der hinter ALICE geNATted sitzt) zwar durch ALICE rauskommt, aber an BOB’s SOHO-Router scheitert. Wäre doch prima wenn wir irgendwie eine Remoteshell von BOB aus aufmachen könnten. Wir trauen BOB aber nicht, und wollen Ihm auch nicht den SSH-Key/Password für ALICE rausrücken. SSH von BOB nach PLUTO/ALICE ist also doof – Was tun ??

Man nehme: Netcat und Named Pipes. Im einzelnen sieht das dann wie folgt aus:

  1. Brücke auf ALICE bauen:
    netcat -v -l -p 4711 -c "/bin/nc -l -p 4712"
    ALICE wartet jetzt also auf Port 4711. Alles was sich dort verbindet, wird dann mit einem neuen Listener, der auf 4712 horcht verbunden.
  2. Auf BOB erzeugen wir ein Device (Pipe) damit wir bidirektional den ssh-Datenstrom ins Netcat rein und auch wieder rausbekommen:
    mknod backpipe p
  3. Nun nehmen wir das ganze von BOB aus in Betrieb:
    netcat -vv ALICE 4711 <backpipe |netcat -v localhost 22 >backpipe
  4. Wenn wir auf PLUTO nun ein ssh root@ALICE -p 4712 ausführen, sind wir auf BOB angekommen. Voila

Sehr elegant, wie ich finde.

User die auf BOB meinetwegen root-rechte haben und Memdumps machen können, kommen nicht weiter, weil die ja keinen Key oder ähnliches von PLUTO oder ALICE haben, das netcat auf ALICE ist schon dicht mit einer Connection – da kann also auch nichts passieren. Und wir können prima von PLUTO aus auf BOB weiterarbeiten/remote unterstützen/whatever bis jemand die Pipe oder den Netcat tötet…

 

Tagged with:
Feb 01

Na premium. Setze mich heute morgen an den Rechner, und was sehe ich: Kein Internet !

Dass man Abstriche machen muss, wenn man knapp 2 Jahre lang Kabelmodem verwöhnt war, (Kein nervtötender Reconnect / NULL Ausfälle / Konstanter Up/Downstream etc.) hatte ich mir ja schon gedacht. Nunja, seit ca. 3 Wochen bin ich wieder PPP over Ethernet User (DSL) mit all seinen “netten” Nebeneffekten (siehe oben). Normalerweise reconnected der pppd auch fein nach jedem Disconnect – nur heute Nacht halt nicht.

Die Analyse (siehe Logauszug) ergibt zwei suspekte Dinge:

  1. “Rausschmiss” durch den Provider nach 574 Minuten (Normalerweise passiert das nach 24h)
  2. Reconnectversuch durch den PPPD, der jedoch mangels Antwort der Gegenstelle ins leere läuft.

Gerade Punkt 2 nervt hier – denn per default gibt der pppd nach 10 Versuchen auf. Nach etwas googlerei habe ich dann doch die richtige Option gefunden, mit der er unendlich “PADI”s schicken soll, um irgendwann dann mal ‘nen Connect hinzubekommen. Einfach ein “maxfail 0” in die /etc/ppp/peers/provider eintragen, und schon versucht es der Router bis zum St.Nimmerleinstag


Feb 1 03:03:04 pppd[530]: LCP terminated by peer
Feb 1 03:03:04 pppd[530]: Connect time 573.9 minutes.
Feb 1 03:03:04 pppd[530]: Sent [ne Menge] bytes, received
[noch viel mehr] bytes.
Feb 1 03:03:07 pppd[530]: Connection terminated.
Feb 1 03:03:07 pppd[530]: Modem hangup
Feb 1 03:04:12 pppd[530]: Timeout waiting for PADO packets
Feb 1 03:04:43 pppd[530]: PPP session is 350
Feb 1 03:04:43 pppd[530]: Using interface ppp0
Feb 1 03:04:43 pppd[530]: Connect: ppp0 <--> eth2
Feb 1 03:04:49 pppd[530]: Connection terminated.
Feb 1 03:04:49 pppd[530]: Modem hangup
Feb 1 03:05:54 pppd[530]: Timeout waiting for PADO packets
Feb 1 03:06:59 pppd[530]: Timeout waiting for PADO packets
Feb 1 03:08:04 pppd[530]: Timeout waiting for PADO packets
Feb 1 03:09:09 pppd[530]: Timeout waiting for PADO packets
Feb 1 03:10:14 pppd[530]: Timeout waiting for PADO packets
Feb 1 03:11:19 pppd[530]: Timeout waiting for PADO packets
Feb 1 03:12:24 pppd[530]: Timeout waiting for PADO packets
Feb 1 03:13:29 pppd[530]: Timeout waiting for PADO packets

Tagged with:
preload preload preload