IPTABLES - ssh für bestimmte dynamische IP zulassen

[wckl]

Hallo,
die Situation:
- Mein Rechner liegt hinter einem Router, auf meinem Rechner läuft eine firewall mit IPTABLES;
- SSH-Verbindungen will ich nur für bestimmte externe IP zulassen, diese sind leider dynamisch.

Für die Kontrolle habe ich diesen Code vorgesehen

Code: Alles auswählen

$IPT4 -A INPUT  -s $ssh_extern  -d $ssh_obelix -p TCP --dport ssh \
        -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
$IPT4 -A OUTPUT -d $ssh_extern -s $ssh_obelix -p TCP --dport ssh \
        -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

Wie kann ich

Code: Alles auswählen

ssh_extern=

bestimmen, wenn die IP-Adresse des zugelassenen Teilnehmers ständig wechselt?
Am Ende will ich einen SSH-Tunnel einrichten, über den mit TightVNC der fremde Rechner betreut werden soll.

Hat jemand dafür eine Lösung?

Vielen Dank für Hilfe.
wckl

[heinzelrumpel]

Ich sehe da nur einen Umweg als Lösung. Die IP des externen Rechners muss auf den Rechner gelangen, damit die iptables Regel erstellt werden kann. Ich würde mir da per OpenVPN ein Verbindung einrichten. Was genau soll denn der Sinn und Zweck dieser Übung sein? Wenn sich die IP des entfernten Rechners doch ständig ändert kann man ja nicht erkennen, dass hie rein Sicherheitsgewinn durch iptables erreicht wird. Erkläre doch bitte etwas genauer, was Du damit erreichen möchtest.

[thoerb]

Das einzig Sinnvolle ist meiner Meinung nach eine Authentifizierung über Public-Keys.

[MSfree]

Ich sehe da nur einen Umweg als Lösung. Die IP des externen Rechners muss auf den Rechner gelangen, damit die iptables Regel erstellt werden kann. Ich würde mir da per OpenVPN ein Verbindung einrichten.

Es ist nicht besonders sinnvoll, eine VPN-Verbindung aufzubauen, um die IP des entfernten Rechners auf den Server zu übertragen, damit dann IP-Tables-Regeln erstellt werden können, die genau diese eine IP für SSH zuläßt. Das Problem ist nämlich dann, daß die VPN nur für bestimmte dynamische IPs zulassen willst, die du dann.....

Was genau soll denn der Sinn und Zweck dieser Übung sein?

Die Begrenzung des SSH-Zugangs auf einen eingeschränkten Nutzerkreis.

Das einzig Sinnvolle ist meiner Meinung nach eine Authentifizierung über Public-Keys.

Und genau die wurde bei mir schonmal ausgehebelt durch einen Fehler im SSH-Daemon, der zwar später geflickt wurde, aber da war es schon zu spät. Seither mache ich genau das, was der OP oben gefordert hat.

Hat jemand dafür eine Lösung?

Ja, ich habe dafür eine Lösung.

Die sieht so aus:

- Client und Server müssen ihre aktuelle IP-Adresse bei einem DynDNS-Hoster ständig aktuell halten, z.B. bei afraid.org. Beim Server ist das nur nötig, wenn der ebenfalls eine dynamisch wechselnde IP-Adresse hat, sonst findet der Client den nicht.

- mit iptables wir eine Regel erstellt, so daß eingehenden SSH-Pakete, die einen Verbindungsaufbau initiieren sollen, gequeued werden:

Code: Alles auswählen

iptables -A INPUT -i ppp0 -p tcp -m tcp --dport 22 -m state --state NEW -j QUEUE

- ich habe mir einen eigenen Daemon geschrieben, der die gequeueten Pakete abfängt, die IP-Adresse des Clients extrahiert, und dann einen Nameserverlookup auf den Hostnamen des erlaubten Clients durchführt, als z.B. ein nslookup beispiel.homenet.org. Die IP-Adresse, die dieser nslookup liefert, wird dann mit dem eingehenden Paket verglichen und bei Übereinstimmung durchgelassen, sonst verworfen.

Es gibt leider keine Debianpaket, nur Sourcecode, den man selbst kompilieren muß.

[wckl]

Aber existiert denn -i ppp0 hinter einem Router?
Gibt es die Schnittstelle pppX nicht nur bei einem direkten Anschluß über ein Modem?

Wie anfangs beschrieben liege ich hinter einem Router.

[MSfree]

Aber existiert denn -i ppp0 hinter einem Router?

Das war eigentlich nur als Beispiel gedacht, um das QUEUE-Target von iptables zu illustrieren. In deinem Fall dürfte das eher eth0 als Inputdevice sein.

Aber, wie gesagt, es ist mit dieser Regel alleine nicht getan. Man braucht auf jeden Fall ein Programm (Daemon), das im Userspace läuft und sich um die gequeueten Pakete kümmert. Wenn sich keiner um die Pakete kümmert, werden sie verworfen und nicht durchgelassen. Das hat immerhin den Vorteil, daß ein so geschützter Rechner nicht erreichbar und auch nicht kompromitierbar ist, wenn der Daemon mal abstürzen sollte.

[heisenberg]

Eine zusätzliche Sicherung wäre noch portknocking. Es werden in einer vordefinierten Reihe Anfragen an eine exakt definierte Reihenfolge von Ports gesendet. Der Portknocking-Daemon lauscht und führt nach der korrekten Sequenz ein Kommando aus.

Bei mir mache ich das z. B. so, dass ich als Erfolgsaktion dann einen zweiten SSH-Server auf einem anderen Port temporär freischalte, der dann nur einen bestimmten Benutzer aber mit Kennwort zulässt. Somit kann ich von einem fremden Rechner, auf dem mein Key nicht gespeichert ist eine Notadministration durchführen. (In Kombination mit shellinabox, damit ich ein komfortables Terminal im Browser habe).

Hier ist mal meine Konfig vom portknocking-daemon dazu:

Code: Alles auswählen

[options]
        UseSyslog

[openSSH]
        sequence    = 23854,23123,12334,9444,1234,8712,23664,55231,21345,32445
        seq_timeout = 5
        command     = /usr/local/bin/temp_unblock_port tcp 64118 120
        tcpflags    = syn

Die zusätzliche sshd Konfiguration:

Code: Alles auswählen

...
Port 64118
...
PasswordAuthentication no
PubkeyAuthentication no
Match User superspecialadminaccount
  PasswordAuthentication yes
...

Hier noch das Script: temp_unpblock_port

Code: Alles auswählen

#!/bin/bash

function usage_exit {
        echo
        echo "Error: wrong invocation"
        echo
        echo "$(basename $0) : temporary unblock a port"
        echo
        echo "Usage: $(basename $0) <tcp|udp> <port_nr(1-65535)> <duration_minutes(1-1440)>"
        echo
        exit 1
}

function iptables_add_first_rule {

        UNIQUE_ID="$(tr -cd '[:alnum:]' < /dev/urandom | fold -w30 | head -n1)"
        CHAIN=$1
        PROTO=$2
        PORT=$3
        DURATION=$4

        /sbin/iptables -I $CHAIN 1 -p $PROTO --dport $PORT -m comment --comment="Unblocked $DURATION minutes $UNIQUE_ID" -j ACCEPT
        echo $UNIQUE_ID

}

function unblock_port {

        PROTO=$1
        PORT=$2
        DURATION=$3

        iptables_add_first_rule INPUT $PROTO $PORT $DURATION
}

  [ $# -lt 3 ]                                                  && usage_exit
! [[ $1 =~ ^(tcp|udp)$ ]]                                       && usage_exit
! [[ $2 =~ ^[0-9]+$ ]] || [ $2 -lt 1 ] || [ $2 -gt 65535 ]      && usage_exit
! [[ $3 =~ ^[0-9]+$ ]] || [ $3 -lt 1 ] || [ $3 -gt 1440  ]      && usage_exit

PROTO=$1
PORT=$2
DURATION=$3

UNIQUE_ID=$(unblock_port $PROTO $PORT $DURATION)
echo "/usr/local/bin/iptables_regex_delete $UNIQUE_ID" | /usr/bin/at "now + $DURATION minutes"

und das iptables_regex_delete

Code: Alles auswählen

#!/bin/bash

# Delete an iptables rule specified by a unique pattern. Ideally put a unique id set into the rules comment

for ID in $* ;do
        # only continue if the pattern is at least 10 chars long
        [ -z $ID ] || [ ${#ID} -lt 10 ] && continue

        /sbin/iptables-save | grep -v $ID | /sbin/iptables-restore
done

[MSfree]

Eine zusätzliche Sicherung wäre noch portknocking.

Im Prinzip ja. Portknocking hat aber den Nachteil, daß es oft nicht funktioniert, wenn man hinter eine Firewall sitzt, die ausgehenden Verkehr filtert und nicht jeden beliebigen Port durchläßt.

Die Alternative wäre Pingknocking, bei dem man dem Ping-Paket eine Datenlast in Form eines verschlüsselten Zugangscodes mitgibt, die vom Knocking-Daemon ausgewertet werden kann. Das Problem dabei ist aber, daß Plastikrouter kein Paketforwarding für Pingpakete können und der Knocking-Daemon nicht auf dem Plastikrouter selbst laufen kann.

Anklopfen wäre fein, ist aber oft nicht möglich, wie ich aus leideiger Erfahrung selbst mitbekommen mußte. Daher ja die Geschichte mit der IP-Adresse, die mir als einzige Möglichkeit, den Kreis der Angreifer effektiv zu beschränken, erscheint. Unmöglich wird ein Angriff dadurch natürlich trotzdem nicht, aber extrem erschwert..

[heisenberg]

Ich habe meinen PortKnocking-Client auf dem Handy. Dort schalte ich es frei und nutze von anderer Stelle. Ist natürlich temporäres Sicherheitsrisiko den SSH für alle zu öffnen. Ich halte das für mich für akzeptabel.

Das Szenario des Themenstarters scheint auf die (spontane) Fernwartung bei Heimbenutzern abzuzielen. Dort ist üblicherweise keine Firewall oder nur eine sehr wenig restriktive Firewall im Einsatz. Im Firmenumfeld sieht das natürlich anders aus.

Bei einer spontanen Fernwartung würde die Einrichtung von dyndns einen zusätzlichen Aufwand bedeuten.

Sich aber bei so einer Sache mal grundsätzlich auf http(s) zu beschränken wäre gut weil robust.

[MSfree]

Ich habe meinen PortKnocking-Client auf dem Handy. Dort schalte ich es frei und nutze von anderer Stelle. Ist natürlich temporäres Sicherheitsrisiko den SSH für alle zu öffnen. Ich halte das für mich für akzeptabel.

Das ist eine Idee, die mir so noch gar nicht gekommen ist. OK, SSH muß wohl oder übel für 1-2 Minuten für jeden geöffnet werden, aber das Risiko, ausgerechnet während dieses Zeitfensters gehackt zu werden, ist überschaubar.

[mat6937]

Eine andere Möglichkeit ist hosts.allow (libwrap) in Kombination mit dyndns und zusätzlich, um den "Angreifer zu verwirren", auf das gesetzte ecn-Bit (Server/Client) beim Server zu filtern:

Code: Alles auswählen

iptables -I INPUT 1 -i eth0 -p tcp --tcp-flags SYN SYN --dport 22 -m ecn ! --ecn-tcp-cwr -m state --state NEW -j DROP

[MSfree]

Eine andere Möglichkeit ist hosts.allow (libwrap) in Kombination mit dyndns

Meines Wissens nach funkioniert das nur, wenn der anfragende Client per DNS-Reverse-Lookup aufgelöst werden kann, also ein nslookup 11.22.33.44 funktioniert.

Bei einerm Reverse-Lookup einer T-Online IP-Adresse bekommst du etwas in der Art xyz123456.dip0.t-ipconnect.de zurück, und das ist eben nicht dein beispiel.dyndns.org, der in deiner hosts.allow steht.

[mat6937]

Ja, aber die IP-Adresse von "beispiel.dyndns.org" (Client) lasse ich auf dem Server von einem cronjob in eine Textdatei schreiben und diese Textdatei trage ich in der hosts.allow (zusätzlich mit ".t-ipconnect.de") für allow ein.

[MSfree]

Ja, aber die IP-Adresse von "beispiel.dyndns.org" (Client) lasse ich auf dem Server von einem cronjob in eine Textdatei schreiben und diese Textdatei trage ich in der hosts.allow (zusätzlich mit ".t-ipconnect.de") für allow ein.

Dann kann man auch gleich einen Cronjob laufen lassen, der eine iptables-Regel für die gerade gültige IP-Adresse erstellt und die alte Regel entfernt. hosts.allow braucht man dann nicht mehr.

[scientific]

Was hältst du von Zertifikat + pam-googleauthenticator?

[heisenberg]

Ich habe meinen PortKnocking-Client auf dem Handy. Dort schalte ich es frei und nutze von anderer Stelle. Ist natürlich temporäres Sicherheitsrisiko den SSH für alle zu öffnen. Ich halte das für mich für akzeptabel.

Das ist eine Idee, die mir so noch gar nicht gekommen ist. OK, SSH muß wohl oder übel für 1-2 Minuten für jeden geöffnet werden, aber das Risiko, ausgerechnet während dieses Zeitfensters gehackt zu werden, ist überschaubar.

Ok. Die Idee ist sogar noch besser. Im Moment mach' ich den Port für 2 Stunden auf. Aber nach erfolgreichem Login kann man natürlich für den betreffenden Client länger erlauben und die Regel für den für alle geöffneten SSH sofort wieder entfernen.

[MSfree]

Ok. Die Idee ist sogar noch besser. Im Moment mach' ich den Port für 2 Stunden auf. Aber nach erfolgreichem Login kann man natürlich für den betreffenden Client länger erlauben und die Regel für den für alle geöffneten SSH sofort wieder entfernen.

Mit iptables wäre das eigentlich ganz einfach mit folgender permanenten Regel:

Code: Alles auswählen

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

erlaubt grundsätzlich bestehende Verbindungen. Du müßtest Port 22 also gar nicht länger aufhalten, wenn die Verbindung steht, darum kümmert sich die ESTABLISHED,RELATED-Regel.

Die folgende Regel, die sich nur um den Neuaufbau von SSH-Verbindungen kümmert, mußt du dann nach 1-2 Minuten wieder löschen:

Code: Alles auswählen

IPTABLES -A INPUT --dport 22 -m state --state NEW -j ACCEPT

[heisenberg]

War/Bin mir nicht sicher ob die gleiche SSH-Sitzung unter allen Umständen auch die gleiche TCP-Sitzung ist. Ist das wirlich so?

[MSfree]

War/Bin mir nicht sicher ob die gleiche SSH-Sitzung unter allen Umständen auch die gleiche TCP-Sitzung ist. Ist das wirlich so?

Ja, das ist garantiert.

Allerdings habe ich mir über dieses dynamische IP-Problem auch meine Gedanken gemacht und einen Daemon geschrieben, der Clients mit Hostnamen, die per DynDNS auflösbar sind, Zugang gewährt. Mittlerweise ist dieser Daemon noch um Pingknocking erweitert worden, was aber einen speziellen Pingclient voraussetzt, der die Payload in die Pingpakete schreibt.

[heisenberg]

Allerdings habe ich mir über dieses dynamische IP-Problem auch meine Gedanken gemacht und einen Daemon geschrieben, der Clients mit Hostnamen, die per DynDNS auflösbar sind, Zugang gewährt. Mittlerweise ist dieser Daemon noch um Pingknocking erweitert worden, was aber einen speziellen Pingclient voraussetzt, der die Payload in die Pingpakete schreibt.

Das wäre dann also ein sehr komplexes Passwort, dass im Klartext über die Leitung geschickt wird?

[MSfree]

Das wäre dann also ein sehr komplexes Passwort, dass im Klartext über die Leitung geschickt wird?

Nein, das Paßwort wird durch einen Zeitfaktor verlängert und mit SHA256 gehasht und dann der Hash übertragen. Das ganze ist im Endeffekt so etwas ähnliches wie ein One-Time-Paßwort. Der Knockingdaemon nimmt das hinterlegte Paßwort und hasht es ebenfalls mit diesem Zeitfaktor und vergleicht die Hashes.

Durch den Zeitfaktor ist so ein Hash dann nur eine gewisse zeit gültig, und selbst, wenn ein Angreifer den mitliest, hätte er nicht lange Freude daran. Die Uhren in Client und Server müssen dazu allerdings halbwegs synchron laufen, was dank NTP ja eigentlich kein großes Problem ist. Dennoch erlaube ich hier noch 100s Tolleranz.

- ein Angreifer müßte also zunächst den Hash mitlesen
- dann müßte er das Pingpaket selbst von seinem Angriffsrechner abschicken
- dann müßte er wissen, was der Knockingdaemon mit dem Hash macht, er öffnet ja nicht unbedingt den SSH-Port, das funktioniert mit einem OpenVPN-Port auch.
- Sollte er herausbekommen haben, daß der verschickte Hash den SSH-Port für 2 Minuten öffnet, kann er in dieser Zeit versuchen, den SSH-Server zu kapern
Ich denke, das dürfte hinreichend abgesichert sein

[suleiman]

Wenn schon mit Passwort dann würde ich auch sshguard installieren, funktioniert wie fail2ban.