kde will bei aktiver firewall nicht mehr

Einrichten des lokalen Netzes, Verbindung zu anderen Computern und Diensten.
Antworten
decembersoul
Beiträge: 283
Registriert: 16.10.2003 10:25:15

kde will bei aktiver firewall nicht mehr

Beitrag von decembersoul » 16.01.2007 10:40:37

Hallo
Ich habe letzte Woche mein KDE auf 3.5.5 gebracht.
Seit dem will KDE bei eingeschalteter Firewall nicht mehr arbeiten.
Dabei ist "lo" total freigeschaltet. Ich sehe im logfile auch nicht das irgendwas von lo blockiert wird.
Ich habe ein paar Anfragen auf Port 137 aus unserem Firmennetz aber das hat wohl damit nichts zu tun.
Jemand eine Idee?

Code: Alles auswählen

#!/bin/sh
iptables=`which iptables`
MODPROBE=`which modprobe`


BOX0_ETH="eth1"
LAN_ETH="eth0"

PRIVILIG_PORTS="0:1023"
UNPRIVIL_PORTS="1024:65535"
BROADCAST_SRC="0.0.0.0"
BROADCAST_DEST="255.255.255.255"

BOX0_LAN="192.168.0.0/24"
BOX1_LAN="192.168.0.0/24"
LAN="172.31.0.0/16"

BOX0_IP="192.168.0.2"
LAN_IP="172.31.20.70"

TEST_LOG="1" # Logfile "/var/log/syslog"
FTP=1

case "$1" in
        "start")
        #########      START      #########
        ###################################
                echo -e "\n\033[34m Starting Firewall...\033[0m \$iptables = $iptables\n"
                ### delete
                $iptables -t nat -F
                $iptables -t filter -F
                $iptables -X

                if [ "$TEST_LOG" = "1" ]; then
                        $iptables -N garbage
                        $iptables -I garbage -p tcp  -j LOG --log-prefix="Firewall: TCP "  --log-level debug
                        $iptables -I garbage -p udp  -j LOG --log-prefix="Firewall: UDP "  --log-level debug
                        $iptables -I garbage -p ICMP -j LOG --log-prefix="Firewall: ICMP " --log-level debug
                fi

                ### Default Policy
                $iptables -P INPUT   DROP
                $iptables -P OUTPUT  DROP
                $iptables -P FORWARD DROP
                ### Loopback
                $iptables -I INPUT  -i lo -j ACCEPT
                $iptables -I OUTPUT -o lo -j ACCEPT
                ### MY_PC --->
                $iptables -A OUTPUT -o $LAN_ETH  -s $LAN_IP  -m state --state    NEW,ESTABLISHED,RELATED -j ACCEPT
                $iptables -A OUTPUT -o $BOX0_ETH -s $BOX0_IP -m state --state    NEW,ESTABLISHED,RELATED -j ACCEPT
                #  all         --> MY_PC
                $iptables -A INPUT  -i $LAN_ETH  -d $LAN_IP  -m state --state        ESTABLISHED,RELATED -j ACCEPT
                $iptables -A INPUT  -i $BOX0_ETH -d $BOX0_IP -m state --state        ESTABLISHED,RELATED -j ACCEPT
                #  ssh, scp    --> MY_PC
                $iptables -A INPUT  -i $LAN_ETH  -s $LAN      -d $LAN_IP  -p tcp --sport $UNPRIVIL_PORTS --dport 22 -m state --state NEW -j ACCEPT
                $iptables -A INPUT  -i $BOX0_ETH -s $BOX0_LAN -d $BOX0_IP -p tcp --sport $UNPRIVIL_PORTS --dport 22 -m state --state NEW -j ACCEPT
                #  http        --> MY_PC
                $iptables -A INPUT  -i $LAN_ETH  -s $LAN      -d $LAN_IP  -p tcp --sport $UNPRIVIL_PORTS --dport 80 -m state --state NEW -j ACCEPT
                $iptables -A INPUT  -i $BOX0_ETH -s $BOX0_LAN -d $BOX0_IP -p tcp --sport $UNPRIVIL_PORTS --dport 80 -m state --state NEW -j ACCEPT

                # Loggen in /var/log/syslog
                if [ "$TEST_LOG" = "1" ]; then
                        $iptables -A INPUT   -j garbage
                        $iptables -A OUTPUT  -j garbage
                        $iptables -A FORWARD -j garbage
                fi
                #FTP
                if [ "$FTP" = "1" ]; then
                       $MODPROBE ip_conntrack_ftp   # Aktiviert die Stateful Inspection
                fi
        ;;
        "stop")
        #########      STOP       #########
        ###################################
                echo -e "\033[31m \nStopping Firewall...\n\033[0m"
                $iptables -t nat -F
                $iptables -t filter -F
                $iptables -X
                $iptables -P INPUT   ACCEPT
                $iptables -P OUTPUT  ACCEPT
                $iptables -P FORWARD ACCEPT
        ;;
    "*")
        #########      REST       #########
        ###################################
                echo "Usage: /etc/init.d/firewall (start|stop)"
                exit 1
        ;;
esac

gms
Beiträge: 7798
Registriert: 26.11.2004 20:08:38
Lizenz eigener Beiträge: MIT Lizenz

Re: kde will bei aktiver firewall nicht mehr

Beitrag von gms » 16.01.2007 11:03:40

Diese zwei iptable Kommandos sollten auch einen Fehler liefern und werden daher auch nicht geladen:

Code: Alles auswählen

                $iptables -I INPUT  -i lo -j ACCEPT 
                $iptables -I OUTPUT -o lo -j ACCEPT
bei "-I" brauchst du noch eine Rulenumber (Zeilennummer ) wo diese Rule eingefügt werden soll.
Du kannst aber auch "-A" (append) verwenden

Gruß
gms

decembersoul
Beiträge: 283
Registriert: 16.10.2003 10:25:15

Beitrag von decembersoul » 16.01.2007 11:13:35

danke für den Tip.
Ich dachte das -I immer an den Anfang einfügt.
Leider macht es keinen Unterschied ob ich die Regel anhänge oder -I verwende.
Fehlermeldung gibt es bei beiden nicht.

gms
Beiträge: 7798
Registriert: 26.11.2004 20:08:38
Lizenz eigener Beiträge: MIT Lizenz

Beitrag von gms » 16.01.2007 11:18:01

poste bitte einmal die Ausgabe von

Code: Alles auswählen

iptables -nvL

decembersoul
Beiträge: 283
Registriert: 16.10.2003 10:25:15

Beitrag von decembersoul » 16.01.2007 11:32:40

Hier erstmal die Ausgabe mit einem -I (also so wie mein Skript oben)

Code: Alles auswählen

iptables -nvL
Chain INPUT (policy DROP 3 packets, 732 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     0    --  lo     *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     0    --  eth0   *       0.0.0.0/0            172.31.20.70        state RELATED,ESTABLISHED
    0     0 ACCEPT     0    --  eth1   *       0.0.0.0/0            192.168.0.2         state RELATED,ESTABLISHED
    0     0 ACCEPT     tcp  --  eth0   *       172.31.0.0/16        172.31.20.70        tcp spts:1024:65535 dpt:22 state NEW
    0     0 ACCEPT     tcp  --  eth1   *       192.168.0.0/24       192.168.0.2         tcp spts:1024:65535 dpt:22 state NEW
    0     0 ACCEPT     tcp  --  eth0   *       172.31.0.0/16        172.31.20.70        tcp spts:1024:65535 dpt:80 state NEW
    0     0 ACCEPT     tcp  --  eth1   *       192.168.0.0/24       192.168.0.2         tcp spts:1024:65535 dpt:80 state NEW
    3   732 garbage    0    --  *      *       0.0.0.0/0            0.0.0.0/0

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 garbage    0    --  *      *       0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     0    --  *      lo      0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     0    --  *      eth0    172.31.20.70         0.0.0.0/0           state NEW,RELATED,ESTABLISHED
    0     0 ACCEPT     0    --  *      eth1    192.168.0.2          0.0.0.0/0           state NEW,RELATED,ESTABLISHED
    0     0 garbage    0    --  *      *       0.0.0.0/0            0.0.0.0/0

Chain garbage (3 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 LOG        icmp --  *      *       0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 7 prefix `Firewall: ICMP '
    3   732 LOG        udp  --  *      *       0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 7 prefix `Firewall: UDP '
    0     0 LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 7 prefix `Firewall: TCP '
Dann habe ich das -I gegen -A ausgetauscht.

Code: Alles auswählen

iptables -nvL
Chain INPUT (policy DROP 6 packets, 1592 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     0    --  lo     *       0.0.0.0/0            0.0.0.0/0
    8   716 ACCEPT     0    --  eth0   *       0.0.0.0/0            172.31.20.70        state RELATED,ESTABLISHED
    0     0 ACCEPT     0    --  eth1   *       0.0.0.0/0            192.168.0.2         state RELATED,ESTABLISHED
    0     0 ACCEPT     tcp  --  eth0   *       172.31.0.0/16        172.31.20.70        tcp spts:1024:65535 dpt:22 state NEW
    0     0 ACCEPT     tcp  --  eth1   *       192.168.0.0/24       192.168.0.2         tcp spts:1024:65535 dpt:22 state NEW
    0     0 ACCEPT     tcp  --  eth0   *       172.31.0.0/16        172.31.20.70        tcp spts:1024:65535 dpt:80 state NEW
    0     0 ACCEPT     tcp  --  eth1   *       192.168.0.0/24       192.168.0.2         tcp spts:1024:65535 dpt:80 state NEW
    6  1592 garbage    0    --  *      *       0.0.0.0/0            0.0.0.0/0

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 garbage    0    --  *      *       0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy DROP 5 packets, 1080 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     0    --  *      lo      0.0.0.0/0            0.0.0.0/0
    8   496 ACCEPT     0    --  *      eth0    172.31.20.70         0.0.0.0/0           state NEW,RELATED,ESTABLISHED
    1    48 ACCEPT     0    --  *      eth1    192.168.0.2          0.0.0.0/0           state NEW,RELATED,ESTABLISHED
    5  1080 garbage    0    --  *      *       0.0.0.0/0            0.0.0.0/0

Chain garbage (3 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 LOG        icmp --  *      *       0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 7 prefix `Firewall: ICMP '
    6  1592 LOG        udp  --  *      *       0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 7 prefix `Firewall: UDP '
    5  1080 LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 7 prefix `Firewall: TCP '

gms
Beiträge: 7798
Registriert: 26.11.2004 20:08:38
Lizenz eigener Beiträge: MIT Lizenz

Beitrag von gms » 16.01.2007 11:59:05

mit der "-I" Option hattest du recht, das hatte ich falsch in Erinnerung

Pakete werden ja anscheinend gedroppt, kannst du die geloggten Pakete posten ?
Wie macht sich die Arbeitsverweigerung von KDE bemerkbar ?
Für "lo" wurden hier keine Pakete angezeigt, möglicherweise war der Zeitraum zu kurz, es könnte aber auch sein, daß dein "lo" Interface nicht "up" ist ( kannst du mit "ifconfig lo" überprüfen )

decembersoul
Beiträge: 283
Registriert: 16.10.2003 10:25:15

Beitrag von decembersoul » 16.01.2007 12:12:07

Ich habe nun die Firewall ausgeschaltet und kde gestartet, wenn ich nun die Firewall einschalte, dann passiert das:

-Neue Programme lassen sich nicht mehr starten
-Menü geht nicht mehr auf
-Fenster lasse sich nicht mehr verschieben
..

Ich vermute stark auf dcop bin mir aber nicht sicher.

Das interface lo ist up und hier mal ein auszug aus meinem syslog
SYSLOG per PN

172.31.20.70 ist meine IP

gms
Beiträge: 7798
Registriert: 26.11.2004 20:08:38
Lizenz eigener Beiträge: MIT Lizenz

Beitrag von gms » 16.01.2007 12:31:25

abgesehen von den Netbios und DHCP Paketen wird bei dir auch der folgende ausgehende Traffic gedroppt

Code: Alles auswählen

OUT=eth0 PROTO=TCP SPT=730 DPT=2049 
Die Ports sagen mir jetzt nichts, hast du eine Ahnung ?

P.S. Du hättest das Log auch auf NoPaste ( http://nopaste.debianforum.de/ ) posten können

gms
Beiträge: 7798
Registriert: 26.11.2004 20:08:38
Lizenz eigener Beiträge: MIT Lizenz

Beitrag von gms » 16.01.2007 12:42:14

aja, ist möglicherweise NFS
wenn ja, solltest du dieses auch freischalten

decembersoul
Beiträge: 283
Registriert: 16.10.2003 10:25:15

Beitrag von decembersoul » 16.01.2007 14:37:59

Verbindungen die ICH aufbaue, sollten doch eh immer gehen. Also wenn ich was per nfs mounte, dann ist es auch kein Problem. Nur falls jemand versucht was von mir zu mounten, dann schlägt es fehl.
sehr komisch die ganze Sache.

gms
Beiträge: 7798
Registriert: 26.11.2004 20:08:38
Lizenz eigener Beiträge: MIT Lizenz

Beitrag von gms » 16.01.2007 15:39:34

Die geloggten NFS Pakete müßten ja eigentlich den Status INVALID besitzen, weil NEW, ESTABLISHED und RELATED läßt du explicit durch. Also gehören diese Pakete entweder noch zu einer alten Verbindung ( eine Verbindung die initiiert wurde bevor das conntrack Modul seinen Dienst aufgenommen hat), oder das Connectiontracking für NFS funktioniert ganz einfach überhaupt nicht.
Letzteres würde mich auch ehrlich gesagt gar nicht verwundern, braucht doch das relativ einfache FTP Protokoll ein eigenes Connectiontracking-Modul (conntrack-ftp) dafür. Aber das ist jetzt schon sehr spekulativ, ich hatte noch nie das Problem, einen NFS Traffic durch eine Firewall durchlassen zu müssen.

decembersoul
Beiträge: 283
Registriert: 16.10.2003 10:25:15

Beitrag von decembersoul » 16.01.2007 17:05:44

ja ich glaube nun auch das es ein NFS Problem ist.
Bei uns in der Firma werden die /home über nfs gemountet.
Da ist wohl das Problem. Eigentlich sollte es gehen wenn die Verbindung einmal steht. Dann werden ja ESTABLISHED,RELATED zuschlagen. Ich glaube aber das sich bei nfs was mit sync und async geändert hat.
Fakt ist wenn ich Verbindungen von aussen zulasse, dann geht alles.
Hat also nichts mit lo zu tun.

gms
Beiträge: 7798
Registriert: 26.11.2004 20:08:38
Lizenz eigener Beiträge: MIT Lizenz

Beitrag von gms » 16.01.2007 23:37:54

Firewallregeln für NFS auf Basis von Connectiontracking habe ich leider nirgends gefunden, dafür aber dieses HowTo:
http://www.sns.ias.edu/~jns/wp/2006/01/18/iptables-nfs/
Unter "NFS Client of remote server" findest du dort folgenden Link: http://www.sns.ias.edu/~jns/files/iptab ... nfs_server
Die "outbound" Regeln, die hier verwendet werden, müßten alle von deinen bisherigen Regeln abgedeckt sein.
Es gibt aber ganz unten auch noch "inbound" Regeln:

Code: Alles auswählen

   # status (nfs.statd)
     allow_inbound_tcpservice 32765 $iface $nfs_server "    status-tcp"
     allow_inbound_udpservice 32765 $iface $nfs_server "    status-udp"
    # nlockmgr (nfs.lockd)
     allow_inbound_tcpservice 32766 $iface $nfs_server "    nlockmgr-tcp"
     allow_inbound_udpservice 32766 $iface $nfs_server "    nlockmgr-udp"
Diese Ports müßtest du also für eingehende Verbindungen zulassen, nur müssen dann auch "nfs.statd" und "nfs.lockd" diese Ports auch verwenden:
http://www.sns.ias.edu/~jns/files/iptables_remote_nfs_server hat geschrieben: Add this line to modules.conf to fix the port that rpc.lockd uses:
options lockd nlm_udpport=32766 nlm_tcpport=32766

Also, modify /etc/rc.d/init.d/nfslock in order to fix the port that rpc.statd uses. Here’s the relevant piece of this file after modification:

echo -n $"Starting NFS statd: "
daemon rpc.statd -p 32765
RETVAL=$?


Gruß
gms

Benutzeravatar
Simmel
Beiträge: 698
Registriert: 08.03.2004 14:43:43
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Düsseldorf
Kontaktdaten:

Re: kde will bei aktiver firewall nicht mehr

Beitrag von Simmel » 17.01.2007 10:19:04

decembersoul hat geschrieben:Hallo
Ich habe letzte Woche mein KDE auf 3.5.5 gebracht.
Seit dem will KDE bei eingeschalteter Firewall nicht mehr arbeiten.
Dabei ist "lo" total freigeschaltet. Ich sehe im logfile auch nicht das irgendwas von lo blockiert wird.
Ich habe ein paar Anfragen auf Port 137 aus unserem Firmennetz aber das hat wohl damit nichts zu tun.
Jemand eine Idee?
Kenne mich mit X nicht so gut aus, aber wäre es möglich das der FONT-Server damit zu tun haben könnte? Arbeitet auf Port 7100 meine ich, kann das sein?gib mal anstatt der lo noch die eigene IP mit frei, ich denk das das Problem da irgendwo sitzt.

Irgendein Dienst arbeitet anscheinend nicht über lo sondern übers eigene iface und wird blockiert, das wäre so meine dunkle Vermutung.
you've got to know how far to go in going too far

perl -le'print+(split//,"schaeuble")[6,8,7,3,5,0..2,4]'

http://creativecommons.org/licenses/by-nc-sa/2.0/

Benutzeravatar
DynaBlaster
Beiträge: 958
Registriert: 25.03.2004 18:18:57
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: DF0://dynablaster.adf

Beitrag von DynaBlaster » 17.01.2007 11:26:00

Wäre natürlich eine Möglichkeit. Ich hatte hier letztens ein ähnliche Problem mit meinem Debian, daß als Jukebox dient. Zur Fernsteuerung des MPD nutze ich Ampache - eine PHP-Applikation, die MP3-Streams erzeugt. Habe 2 Tage damit zugebracht, die Konfiguratinsdateien des MPD, Webservers und der Ampache-Scripte zu editieren, Beta- und Alpha-Versionen zu installieren bis es mir dann wie Schuppen von den Augen fiel: zur Fehleranalyse habe ich mittels iptstate die Verbindungen auf der Jukebox beobachtet, wobei ich dann feststellen durfte, das Ampache seinen MP3-Stream grundsätzlich mit der LAN-IP absetze. Naja, und im iptables-Script stand tatsächlich das hier (,das letztlich den Verbundungsaufbau geblockt hat):

Code: Alles auswählen

iptables -A INPUT -i lo -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT
iptables -A OUTPUT -i lo -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT
Als ich das Script geschrieben habe, war mir die Überflüssigkeit der zusätzlichen Angaben durchaus bewusst - allerdings habe ich zu der Zeit rumgetestet und die 127.0.0.1-Einträge dienten zur Identifikation der Regeln bei der Ausgabe mit "iptables -L".
Das Entfernen der -s und -d Parameter löste dann das Problem. Etwas ähnliches habe ich jetzt im geposteten Script nicht gesehen, finde die Idee mit dem Fontserver aber gut.

Antworten