Re: iptables & ipsec - Schwääre Kost...?
Am Samstag, 30. Oktober 2004 20:53 schrieb Björn Schmidt:
> Matthias Houdek wrote:
> >>iptables -A INPUT -m state --state INVALID -j LOG --log-prefix
> >> "INVALID State INPUT "
> >>iptables -A INPUT -m state --state INVALID -j DROP
> >>iptables -A OUTPUT -m state --state INVALID -j LOG --log-prefix
> >>"INVALID State OUTPUT "
> >>iptables -A OUTPUT -m state --state INVALID -j DROP
> >>iptables -A FORWARD -m state --state INVALID -j LOG --log-prefix
> >>"INVALID State FORWARD "
> >>iptables -A FORWARD -m state --state INVALID -j DROP
> >
> > Ja, gut, das ist doch aber nicht alles. Wer darf denn neue
> > Verbindungen aufbauen? So kann nix gehen.
>
> Das ist mir klar. Die paar Zeilen dienen auch nur dazu um zu zeigen
> dass der Status der Verbindung INVALID ist. Ich könnte die
> defaultpolicy genauso auf ACCEPT setzen, es würde nichts bringen da die
> Verbindung immer INVALID ist (nicht NEW oder ESTABLISHED) und somit
> gedroppt wird. Wenn dieses kleine Beispielscript nicht funktioniert,
> dann kann mein richtiges erst recht nicht gehen. Um das zu zeigen habe
> ich das Skript oben erweitert um ... --state NEW -j ACCEPT
>
> iptables -vL zeigt dann (etwas menschenfreundlicher als ein Skript):
>
> Chain INPUT (policy DROP 0 packets, 0 bytes)
> pkts bytes target prot opt in out source
> destination
> 0 0 ACCEPT all -- lo any anywhere
> anywhere
>
> 7 1979 ACCEPT all -- any any anywhere
> anywhere state RELATED,ESTABLISHED
> 0 0 LOG all -- any any anywhere
> anywhere state INVALID LOG level warning prefix `INVALID State INPUT '
> 0 0 DROP all -- any any anywhere
> anywhere state INVALID
> 2 192 ACCEPT all -- any any anywhere
> anywhere state NEW
>
> Chain FORWARD (policy DROP 0 packets, 0 bytes)
> pkts bytes target prot opt in out source
> destination
> 0 0 ACCEPT all -- any any anywhere
> anywhere state RELATED,ESTABLISHED
> 0 0 LOG all -- any any anywhere
> anywhere state INVALID LOG level warning prefix `INVALID State FORWARD
> ' 0 0 DROP all -- any any anywhere
> anywhere state INVALID
> 0 0 ACCEPT all -- any any anywhere
> anywhere state NEW
>
> Chain OUTPUT (policy DROP 0 packets, 0 bytes)
> pkts bytes target prot opt in out source
> destination
> 0 0 ACCEPT all -- any lo anywhere
> anywhere
>
> 9 4156 ACCEPT all -- any any anywhere
> anywhere state RELATED,ESTABLISHED
> 5 272 LOG all -- any any anywhere
> anywhere state INVALID LOG level warning prefix `INVALID State OUTPUT '
> 5 272 DROP all -- any any anywhere
> anywhere state INVALID
> 3 721 ACCEPT all -- any any anywhere
> anywhere state NEW
>
> 5 Pakete im OUTPUT Chain wurden - da INVALID - gedroppt, alles andere
> akzeptiert.
>
> >>Im log steht dann:
> >>Oct 30 14:40:18 gigabyte kernel: INVALID State OUTPUT IN= OUT=eth0
> >>SRC=192.168.1.2 DST=192.168.1.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64
> >>ID=17523 DF PROTO=TCP SPT=34246 DPT=22 WINDOW=2372 RES=0x00 ACK PSH
> >> FIN URGP=0
> >
> > Jo, da fehlt ja auch die Hälfte.
>
> Mein Fehler, hab nicht alles gepostet. Alle Fehlermeldungen die kommen
> wenn ich eine ssh-Verbindung öffnen will sind diese:
> Oct 30 20:37:16 gigabyte kernel: INVALID State OUTPUT IN= OUT=eth0
> SRC=192.168.1.2 DST=192.168.1.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64
> ID=19104 DF PROTO=TCP SPT=32811 DPT=22 WINDOW=1460 RES=0x00 ACK URGP=0
Das ist keine vollständige TCP-Verbindungs-Anforderung. Es fehlen das
SYN-Flag und eine SEQ-Number, dafür ist das ACK-Flag zu viel. Die anderen
sehen diesbezüglich nicht besser aus.
>
> > Außerdem - wieso FIN?
>
> Das kommt nach einem Timeout oder nach CTRL-C während des
> Verbindungsaufbaus.
Ja, weil ja erst gar keine Verbindung angefordert wird.
> >>Ich bin am Rechner 192.168.1.2 eingeloggt und versuche eine ssh
> >>Verbindung zu 192.168.1.1 aufzubauen. Hoffe das sind jetzt
> >> ausreichend Informationen... ;)
> >
> > Die Firewall läuft auf 192.168.1.2 ?
>
> Ja, richtig. Allerdings lief sie während meiner ersten Mails auf
> 192.168.1.1
> Da dort das gleiche Fehlverhalten auftrat und ich nicht immer zum
> Rechner laufen sollte habe ich sie auf 192.168.1.1 deaktiviert
> und zum testen nach 192.168.1.2 geholt.
> Die ssh-Verbindung soll von 192.168.1.2 zu 192.168.1.1 aufgebaut
> werden.
>
> > Was soll IPSec machen (Tunnel von wo nach wo?)?
>
> Kein Tunnel. Transport Modus, wie hier:
>
> http://www.ipsec-howto.org/x247.html
und diese IPSec-Verbindung soll den gesamten Verkehr zwischen 192.168.1.1
und 192.168.1.2 verschlüsseln?
Dann dürften zwischen diesen beiden Rechnern keine UDP- oder TCP-Pakete
mehr direkt ausgetauscht werden (außer UPD-500 zu Authentifizierung),
sondern nur noch alles über Protokoll 50 bzw. 51 (AH bzw. ESP) geleitet
werden (d.h., alle TCP-Segmente sind in das AH/ESP-Segment gekapselt).
Daraus ziehe ich den Schluss, dass dein IPSec schon mal nicht ordentlich
konfiguriert ist, sonst würden keine TCP-22-Segmente (SSH) mehr an den
Interfaces auftreten.
--
Gruß
MaxX
Hinweis: PMs an diese Adresse werden automatisch vernichtet (Filter
nach /dev/null).
Reply to: