PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : ssh und firewall



CaTron
30.10.02, 01:15
hi,

ich habe einen dsl-router unter suse 7.0 laufen der mit dem susewall geschützt ist (geht hier noch über ipchains)

Funktioniert alles schön.

Nun würde ich gern von außen über ssh auf den router zugreifen können (die jeweils aktuelle externe ip des routers ist bekannt) und dazu den firewall umkonfigurieren. Die entsprechende Datei (/etc/rc.config.d/firewall.rc.config) hab ich schon angepasst. Nur leider komme ich nicht rein.

Im log (firewall) steht z.B. : [Feb 11 17:01:31 router kernel: Packet log: input DENY ppp0 PROTO=6 <hier die ip des client>:1023 <hier die ip des routers>:513 L=44 S=0x00 I=41347 F=0x4000 T=246 SYN (#52)]

Wenn ich den firewall stoppe geht es problemlos.

mit: [ipchains --list | grep ssh] findet sich u.a.



ACCEPT tcp -y--l- <freigegebener host> pD951F7DC.dip.t-dialin.net any -> ssh
ACCEPT tcp ------ <freigegebener host> pD951F7DC.dip.t-dialin.net any -> ssh
ACCEPT tcp -y--l- <freigegebener host> router.local any -> ssh
ACCEPT tcp ------ <freigegebener host> router.local any -> ssh

ACCEPT tcp -y--l- anywhere pD951F7DC.dip.t-dialin.net any -> ssh
ACCEPT tcp ------ anywhere pD951F7DC.dip.t-dialin.net any -> ssh

ACCEPT tcp -y--l- <freigegebener host> pD951F7DC.dip.t-dialin.net any -> ssh
ACCEPT tcp ------ <freigegebener host> pD951F7DC.dip.t-dialin.net any -> ssh

ACCEPT tcp -y--l- anywhere router.local any -> ssh
ACCEPT tcp ------ anywhere router.local any -> ssh
-------- (reicht das nicht schon ?) ----------

DENY tcp -y--l- anywhere pD951F7DC.dip.t-dialin.net any -> ssh
DENY tcp ------ anywhere pD951F7DC.dip.t-dialin.net any -> ssh
MASQ tcp !y---- lukas <freigegebener host> ssh -> any
ACCEPT tcp ------ anywhere anywhere ssh -> any
ACCEPT tcp ------ anywhere anywhere any -> ssh

( ich habe zum testen einen fernen host freigegeben von dem aus ich zugreife, aber eigentlich müßte es mit jedem gehen)

Was stimmt hier nicht, bzw. weiß jemand die richtigen ipchains-Kommandos um ssh freizugeben ?

Ciao, CaTron

tomes
30.10.02, 17:41
welche die 52. Regel in deinem Firewall Script ist --> (#52) Diese hat "zugeschlagen" und das Paket zurueckgewiesen.
Vielleicht eine hight_port Regel, da ja nur der Verbindungsaufbau ueber Port 22 (ssh) laeuft. Danach geht die Kommunikation ueber Ports > 1024. Bei OpenSSH jedenfalls normalerweise.
Ach so, was mir gerade noch auffaellt:
Das hast definitiv nichts nit den ssh Regeln (die du gegrept hast) zu tun.

[Feb 11 17:01:31 router kernel: Packet log: input DENY ppp0 PROTO=6 <hier die ip des client>:1023 <hier die ip des routers>:513 L=44 S=0x00 I=41347 F=0x4000 T=246 SYN (#52)]
Das heist, dass dein Client sich mit Port 1023 Versucht hat auf dem Rechner (router) Port 513 zuverbinden.
Das sieht mir sehr nach ssh (nicht OpenSSH und wenn dann eine sehr alte Version) aus, da diese die Ports 1000:1023 zum Verbindung benutzen.
Hier muss du ansetzen. In einer "Handgeschriebenen" Firewall wuerde das ungrfaehr so aussehen:


ipchains -A input -i ppp0 -p tcp -s <freigegebener host> pD951F7DC.dip.t-dialin.net/32 1000:1023 -j ACCEPT
ipchains -A output -i ppp0 -p tcp -s <router.local> -d <freigegebener host> pD951F7DC.dip.t-dialin.net/32 1000:1023 ! -y -j ACCEPT

Wie das bei der SuSEFirewall realisiert wird, keine Ahnung. Notfalls die Regel mit z.B. --> ipchains -I INPUT 52 .....
einfuegen.

Und Port 513 ist login, das kann man auch im sshd.config abschalten, ist sowieso unsicher. Am besten als erstes neue Version von OpenSSH auf dem Clienten und dem Server instalieren ;)

T;o)Mes

CaTron
31.10.02, 00:09
ok, danke für den tip mit 513,

#53 ist die Regel, die telnet verhindert (und das ist auch gut so;-), ich hab mir deshalb den Client mal genauer angesehen (-v) und festgestellt dass der nach 3 ssh-Versuchen zu rsh zurückfällt. Daher auch die DENY-Meldung für 513.

Wenn ich den fallback des clients verhindere, steht in den logs nur :
[ACCEPT ppp0 PROTO=6 <ip-client>:1023 [ip-router>:22], keine DENYs

scheint ja alles in Ordnung, trotzdem kommt die Verbindung nicht zustanden, der Client meldet:

client >> ssh -v <router>
SSH Version 1.2.26 [sparc-sun-solaris2.5.1], protocol version 1.5.
Standard version. Does not use RSAREF.
rp-cip02: Reading configuration data /etc/sw/ssh/ssh_config
rp-cip02: ssh_connect: getuid 1069 geteuid 0 anon 0
rp-cip02: Allocated local port 1023.
rp-cip02: Connecting to <router> port 22.
rp-cip02: connect: Connection refused
rp-cip02: Trying again...

aber wie schon gesagt, wenn ich die fw stoppe gehts problemlos, an ssh kanns also nicht liegen...
Und an den falschen (alten) Ports auch, der client benutzt ja 1023) und im log steht ja auch keine Fehler wegen dieser ports.

Versteh ich nicht.

? CaTron

HangLoose
31.10.02, 00:27
hi

gibt es beim firewallscript der suse 7.0 folgende variable FW_SERVICES_EXTERNAL_TCP?
hast du dort mal ssh eingetragen?


Gruß HangLoose

tomes
31.10.02, 17:28
root beim Server anzumelden ?

rp-cip02: ssh_connect: getuid 1069 geteuid 0 anon 0
vielleicht ist es ja dem root nicht erlaubt sich mit dem sshd zu verbinden.

Wuerde es mal mit einem User-Account versuchen. Ist ja auch sicherer.

T;o)Mes

CaTron
03.11.02, 06:54
@ HangLoose:

ja hab ich gemacht, hat auch neue Einträge in der Chains-Liste gemacht, aber nichts gebracht...

@tomes:

Dazu bin ich gar nicht gekommen, ich starte ssh auf dem client mit: ssh -v <router>
der user wird erst nach Verbindungsaufbau abgefragt, bzw der client geht von meinem aktuellen Benutznernamen aus (der ist nicht root). Ich habe auch jeweils versucht mich als normaler user einzuloggen. Ohne Firewall gehts, mit nicht.

Mal ne andere Frage, ich logge mich aus meinem internen Netz (nicht dem Router) auf dem fernen Client per ssh ein und versuche dann von diesem aus auf den router zuzugreifen. Kann der Router mitbekommen das ich diesen Umweg nehme und versuchen die Abkürzung zu nehmen und kann das daran liegen ? Allerdings kann ich mich aus dem internen Netz immer mit ssh einloggen.

Ciao, CaTron

Jinto
03.11.02, 07:47
Wie hast du denn den sshd konfiguriert? Kann es evtl. sein, dass du ihn an die interne Netzwerkkarte gebunden hast?

Wenn du schon die IP des zugreifenden Computers kennst, dann log doch einfach mal alles was von dieser IP kommt.

tomes
03.11.02, 19:34
was sagen den deine logs auf dem Router zum Verbindungsaufbau ? Da muss doch irgendwas von ssh <client> drinne stehen.
Ansonsten einfach mal eine "kleine Firewall" die alles erlaubt und alles loggt. Irgendwas muss ja zu sehen sein.

Zu "mit geht es nicht, ohne geht es" --> wuerd ich ja immer noch auf die Ports 1000:1023 tippen, nicht nur input, auch output. "Hight Ports" z.B. fangen erst 1024 an. Aber da die Firewall nichts loggt ???

T;o)Mes

Harry
03.11.02, 22:59
Hallo,

versuch einfach mal, den ssh-Connect vom Client mit dem Kommando:

ssh -P <login>@<SSH-Server>

durchzuführen.
Dein Log schaut nach einem typischen Client-Privileged-Port-Reject aus und der Client nimmt per Default einen privilegierten Port (513-1023). Mit der Option "-P" weist Du den Client an, einen nicht-privilegierten Port (>1023) zu verwenden.

Harry