iptables und ssh

[hennes]

Hallo,

ich habe ein kleines Problemchen meine Firewall mit iptables so einzurichten, dass man von außerhalb per SSH darauf zugreifen kann.

Hinter dem Rechner selbst hängen noch weitere Rechner, die per Masquerading ins Netz kommen. Das funktioniert sehr schön.

Die INPUT-Queue steht per Default auf DROP, die FORWARD und die OUTPUT Queue auf ACCEPT.

Desweiteren braucht man ja ein

iptables -A INPUT -p udp --destination-port:domain -j ACCEPT

damit DNS Auflösungen stattfinden können. Auch das klappt.

iptables -A INPUT -i ! ppp0 -j ACCEPT

wodurch alles, was nicht von außen kommt, akzeptiert wird. Als Gutmensch gehe ich mal davon aus, dass alle innerhalb der Firma keinen Mist verzapfen.

Dann braucht man noch ein

iptables -A INPUT -f -j ACCEPT
und ein
iptables -A INPUT ! --syn -j ACCEPT

damit Folgepakete richtig durchgelassen werden.

So, nun zum interessanten Teil: Bis hierher funktioniert alles wie erwartet, von außen ist alles dicht, von innen darf man schalten und walten, wie man mag.

Nun muss ich in diese Firewall aber ein Loch popeln, damit ich von außen an den SSH Port komme.

Also probiere ich mal ein

iptables -A INPUT --destination-port ssh -j ACCEPT

und dann von außen ein SSH mit Protokoll 2 und DSA-Key:

-bash-2.05b$ ssh -vvv -l hennes derrechner.derda.ist
OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to derrechner.derda.ist [217.234.189.6] port 22.
debug1: Connection established.
debug1: identity file /server/Entwickler/Jonas/.ssh/identity type -1
debug1: identity file /server/Entwickler/Jonas/.ssh/id_rsa type -1
debug3: Not a RSA1 key file /server/Entwickler/Jonas/.ssh/id_dsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: no key found
debug2: key_type_from_name: unknown key type 'Proc-Type:'
debug3: key_read: no key found
debug2: key_type_from_name: unknown key type 'DEK-Info:'
debug3: key_read: no key found
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: no key found
debug1: identity file /server/Entwickler/Jonas/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.1p1
debug1: match: OpenSSH_3.1p1 pat OpenSSH_2.*,OpenSSH_3.0*,OpenSSH_3.1*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.5p1
debug1: SSH2_MSG_KEXINIT sent
Read from socket failed: Connection reset by peer
debug1: Calling cleanup 0x80674e0(0x0)
-bash-2.05b$

Und hier weiß ich nicht mehr weiter.
Wo habe ich den Denkfehler? Was habe ich falsch eingestellt?

Ach ja: Vom internen Netz heraus funktioniert SSH natürlich. Und wenn man die Firewall komplett deaktiviert (Default Regel auf ACCEPT), dann klappt es auch von außerhalb.

Vielen Dank im Voraus
Hennes

[mistersixt]

Probier mal ff. Zeile hinzuzufügen:

Code: Alles auswählen

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

Geht es dann?

Gruss, mistersixt.

PS: Willkommen im Debian Forum !

[thorben]

moin,
mit sicherer konfiguration hat dein iptables zwar nix zu tun, aber naja

das von mistersixt geschriebene könnte evtl helfen, wobei ich das eher nicht glaube das das alleine hilft

das ist für ssh (das von mistersixt auch einfügen):

Code: Alles auswählen

iptables -A INPUT -i ppp0 -p tcp --dport 22 -j ACCEPT

das solltest du löschen:

iptables -A INPUT -p udp --destination-port:domain -j ACCEPT

das erlaubt von außen deinen dns abzufragen...

such mal im forum nach iptables scripten oder verwenden einen iptables generator, da sollte es einige gute bespiele geben

gruß
thorben

PS: vom internen droht die meiste gefahr (tauschbörsen, mailwürmer usw.) in einem netzwerk, gerade da sollte man als guter admin aufpassen und nicht mit allow all regeln arbeiten...

[hennes]

Hallo,

leider war es das nicht ganz. Das Resultat ist genau dasselbe.
Schade. Das war es noch nicht..

Gruß
Hennes

[mistersixt]

Starte doch mal den sshd per Hand mit "sshd -v -v", vielleicht siehst Du dann mehr auf der Server-Seite.

gruss, mistersixt,

[hennes]

Hallo Thorben,

> das ist für ssh (das von mistersixt auch einfügen):
> Code:
> iptables -A INPUT -i ppp0 -p tcp --dport 22 -j ACCEPT

Hmm, und meines geht nicht?
iptables -A INPUT --destination-port ssh -j ACCEPT
Wo ist der Unterschied, außer in der kryptischeren Schreibweise in deinem Code?

> das solltest du löschen:
> iptables -A INPUT -p udp --destination-port:domain -j ACCEPT
> das erlaubt von außen deinen dns abzufragen...

Wer sagt denn, dass ich einen habe??
Starte keine Dienste, die du nicht auch wirklich brauchst.

> PS: vom internen droht die meiste gefahr (tauschbörsen,
> mailwürmer usw.) in einem netzwerk, gerade da sollte man
> als guter admin aufpassen und nicht mit allow all regeln
> arbeiten...

Was mein Chef und meine Chefin auf ihren Notebooks für Schäden anrichten ist deren Problem. Die Server-Farm für Samba und Oracle läuft unter Linux.

Gruß
Hennes

[hennes]

Sodele,

nachdem ich erst über das sshd -v -v gestolpert bin (es muss sshd -d -d) heißen, kommt da nun folgende Meldung auf dem Server:

debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug2: Network child is on pid 23424
debug3: preauth child monitor started
debug3: mm_request_receive entering
Read from socket failed: Connection reset by peer
debug1: do_cleanup
debug1: PAM: cleanup
debug3: PAM: sshpam_thread_cleanup entering
debug1: do_cleanup
debug1: PAM: cleanup
debug3: PAM: sshpam_thread_cleanup entering
hennes:~#

Also auf beiden Seiten die Meldung "Connection reset by peer". Ich glaube, ich muss mal die gedropten Pakete der Firewall untersuchen, was hier abgeht.

Vielen Dank trotzdem für die schnelle Hilfe
Hennes

[mistersixt]

Mach einfach mal als allerletzte Regel ein allgemeines -j LOG, um zu sehen, was anschliessend durch die Drop-Policy gedropt wird.

Gruss, mistersixt.
*

[hennes]

Hallo,

der Versuch mit aktiviertem Logging zeigte mir zwar eine Menge Angriffe auf die Ports 135, 137, 4666, usw., nur leider keine verworfenen Pakete von der Adresse vom ssh-client :-((

Und dennoch funktioniert es ohne die Firewall. Jetzt blick ich nicht mehr ganz durch.

Seltsam ist auch, dass ich das Verhalten in einem lokalen Netzwerk nicht reproduzieren kann. Zwei Rechner in einem Netz, Firewall auf eth0, nur Folgepakete und ssh dürfen passieren: SSH funktioniert.

Einzelne, verteilte Rechner im Internet, sshd Server mit derselben Firewall auf ppp0: SSH ist nicht möglich. *kopfschüttelnd*

Ich mach jetzt erst einmal Feierabend, erst einmal drüber schlafen.

Viele Grüße
Hennes

[oli_f]

Dieser teil deines skripts:

Code: Alles auswählen

iptables -A INPUT -f -j ACCEPT
und ein
iptables -A INPUT ! --syn -j ACCEPT 

lass das mal schön ersetze es lieber durch:

Code: Alles auswählen

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

ausserdem muss du das

Code: Alles auswählen

iptables -A INPUT -p udp --destination-port:domain -j ACCEPT 

noch um ein

Code: Alles auswählen

 -i <Namen der lokalen Netzwerkkarte>

ergänzen damit man nicht von aussen zugreifen kann.


danach erlaubst du den ssh zugriff folgendermassen:

Code: Alles auswählen

iptables -A INPUT -i $IFACE_EXT -p tcp --dport 22 --syn -m limit --limit 5/s -j ACCEPT
iptables -A INPUT -i $IFACE_EXT -p tcp --dport 22 --syn -j DROP 

wobei du wiederum $iface_ext durch den Namen der Netzwerkkarte worüber die gewünschte verbindung aufgebaut wird ersetzst.


Ansonsten solltest du mit

Code: Alles auswählen

iptables -A input --dport 22 -m state --state NEW -j LOG

alle verbindungsversuche auf port 22 logen können!

[hennes]

Hallo Oli,

meinst du wirklich, dass man ein Nichtzustandekommen einer Verbindung durch eine zu restriktive Einstellung dadurch ermöglicht, dass man die Firewall noch weiter einschränkt?

*grübel*

Gruß
Hennes

[oli_f]

nun ja es ist sicher auch keine lösung des problems einfach alle türen zu öffen.

ausserdem ist meine version nicht restriktiver ausser vielleicht die 5s limite für verbindungsversuche. ausserdem weiss ich von meinem skript das es funktioniert, wenn es mit dem bei dir immer noch nicht funktioniert musst du wohl einmal das ganze skript irgendwo hochladen und den link posten.