• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[LÖSUNG ist da]FW_ALLOW_CLASS_ROUTING?

Frankie777

Frankie777

Advanced Hacker
Der Befehl muß auch an der richtigen Stelle stehen, wenn die Pakete erst gedropt werden und am Schluß kommt erst der ACCEPT Befehl geht es nicht.

iptables -L FORWARD
zeigt Dir die Befehle der Chain FOWARD.

Die Kette wird von oben nach unten abgearbeitet.

Ebenfalls muß IP Forwarding eingeschaltet sein.
 
OP
L

luxman

Newbie
Problematik ist folgendes

es gibt z.B. 2 oder mehrere Subnetze die einen Linux-Firewall als Router nutzen, als folge werden pakete blokiert die aus einer ins andere subnetz gerutet werden. In log datei kommen dann folgende Fehlermeldungen
Jan 11 20:15:20 homelinux kernel: --blokiert-- IN=eth0 OUT=eth0 SRC=192.168.2.1 DST=192.168.1.10 LEN=69 TOS=0x00 P
REC=0x00 TTL=117 ID=14611 PROTO=UDP SPT=65534 DPT=137 LEN=49

also alles was über gleichen interface kommt wird blokiert "IN=eth0 OUT=eth0" meine Frage: gibt es eine kernel parameter oder irgend welche einstellungen um das zu lösen?

Ich hab schon einiges ausprobiert wie z.B.

-A FORWARD -i etho -o eth0 -j ACCEPT auch mit IP Adressen.

Forher hatte ich Suse 8 und da hat das gleiche iptables Script problemlos funktioniert, nach dem update (SuSe9.3) geht nicht mehr. ich vermute mal das die neu version von iptables irgend wie das ganze irgend wie kritisher bearbeitet, aber es muss doch möglichkeit sein oder.

to Frankie777

Ist mir klar dass die Kette von oben nach unten abgearbeitet wird und der ip_forward ist =1 (eingeshaltet)

Danke
 
Frankie777

Frankie777

Advanced Hacker
Das Paket wird blockiert, weil es eine Regel gibt, die dieses Paket aussortiert. Wenn Du die Chain durchsuchst wirst Du die Regel finden. Wenn Du vor dieser Drop Regel eine eigene Regel mit ACCEPT setzt kommt dieses Paket durch. Das Problem ist also lösbar, vorausgesetzt die Regel steht an der richtigen Stelle.

Ist das Beispiel Zufall oder gewählt, es handelt sich um Samba NetBios über SubNetgrenzen hinweg.

Aus anderen Beiträgen habe ich den Eindruck das Yast-Firewall generell Probleme mit Rechnern hat, die über EINE Schnitstelle zwei Subnets ansprechen.

Weiterhin, Warum willst Du Samba NetBios Pakete über die SubNetgrenze transportieren. Windowsen mit XP in default Einstellungen nehmen UDP137, UDP138, TCP 139 und TCP 445 Pakete nur aus ihrem eigenen Subnet an. Eine Windose würde dieses Paket also gar nicht bekommen, sondern wegwerfen.
Wahrscheinlich haben die Suse Firewall Programmierer diesem Fakt Rechnung getragen und dropen solche Pakete.
 
OP
L

luxman

Newbie
Das ist das Problem: es gibt keine regeln die das verbiten

Drop kette kommt als alle letzte.

Das ist nur Beispiel, es wird geblokt für alle ports nicht nur NetBios.

Wie gesagt das ist kein SuseFirewall das ist eigenes iptables script.

Danke dir.

Es muss doch irgend wie gehen?
 
OP
L

luxman

Newbie
Hier ist der script

Code: 
## Allgemeine Variablen setzen

IPTABLES=/usr/sbin/iptables                     ## Verzeichnis unter dem das Programm iptables liegt

PLOW=0:1023                                     ## privilegierte Ports

PHIGH=1024:65535                                ## unprivilegierte Ports

ETH0=129.223.1.1                                ## innere Netzwerkkarte / zur Kommune / immer anpassen

ETH1=129.93.223.2                               ## aeussere Netzwerkkarte / immer anpassen

KOMMUNE=129.223.0.0/16                          ## IP Adressenbereich der Kommune / immer anpassen

##--------------------------------------------------------------------------------------------------------------

## Policy in allen Ketten auf "am Ende alles Droppen" einstellen

$IPTABLES -P INPUT DROP

$IPTABLES -P FORWARD DROP

$IPTABLES -P OUTPUT DROP

##--------------------------------------------------------------------------------------------------------------

## dynamische Kernelparameter setzen

## ip forward einschalten
echo "1" > /proc/sys/net/ipv4/ip_forward

## AbwehrmaÃnamhme gegen SYN flooding / DoS Attacken
echo "1" > /proc/sys/net/ipv4/tcp_syncookies

## echo-reply-messages verbieten
echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

## SYN - food Schutz / DoS Attacken
$IPTABLES -A INPUT -p tcp --syn -m limit --limit 1/s -j ACCEPT

## Ping of Death Schutz
$IPTABLES -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT

##--------------------------------------------------------------------------------------------------------------

## neue Kette DROP und LOG Regel

$IPTABLES -N LOG_DROP

$IPTABLES -A LOG_DROP -j LOG --log-prefix "--rest-muell-- "

$IPTABLES -A LOG_DROP -j DROP

##--------------------------------------------------------------------------------------------------------------
## Loopback Freigabe / Proxy

$IPTABLES -A INPUT -i lo -j ACCEPT

$IPTABLES -A OUTPUT -o lo -j ACCEPT
##--------------------------------------------------------------------------------------------------------------

## Verbindungsfreigabe fuer die Subnetze

$IPTABLES -A FORWARD -p all -s $KOMMUNE -d 192.168.223.0/24 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

$IPTABLES -A FORWARD -p all -s 192.168.223.0/24 -d $KOMMUNE -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

$IPTABLES -A FORWARD -p all -s $KOMMUNE -d 192.169.223.0/24 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

$IPTABLES -A FORWARD -p all -s 192.169.223.0/24 -d $KOMMUNE -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

$IPTABLES -A FORWARD -p all -s $KOMMUNE -d 192.170.223.0/24 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

$IPTABLES -A FORWARD -p all -s 192.170.223.0/24 -d $KOMMUNE -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

##--------------------------------------------------------------------------------------------------------------

## den rest loggen und droppen

$IPTABLES -A INPUT -j LOG_DROP

$IPTABLES -A FORWARD -j LOG_DROP

$IPTABLES -A OUTPUT -j LOG_DROP


und logauszug
Code: 
Jan 17 08:27:50 fw223 kernel: --rest-muell-- IN=eth0 OUT=eth0 SRC=129.223.0.2 DST=192.169.223.15 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=25767 DF PROTO=TCP SPT=3322 DPT=445 WINDOW=65535 RES=0x00 ACK URGP=0
Jan 17 08:27:50 fw223 kernel: --rest-muell-- IN=eth0 OUT=eth0 SRC=129.223.0.2 DST=192.169.223.15 LEN=177 TOS=0x00 PREC=0x00 TTL=127 ID=25768 DF PROTO=TCP SPT=3322 DPT=445 WINDOW=65535 RES=0x00 ACK PSH URGP=0
Jan 17 08:27:51 fw223 kernel: --rest-muell-- IN=eth0 OUT=eth0 SRC=129.223.0.7 DST=192.169.223.19 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=30207 DF PROTO=TCP SPT=445 DPT=1032 WINDOW=17520 RES=0x00 ACK SYN URGP=0
Jan 17 08:27:51 fw223 kernel: --rest-muell-- IN=eth0 OUT=eth0 SRC=129.223.0.7 DST=192.169.223.19 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=30208 PROTO=ICMP TYPE=0 CODE=0 ID=512 SEQ=768
Jan 17 08:27:53 fw223 kernel: --rest-muell-- IN=eth0 OUT=eth0 SRC=129.223.0.7 DST=192.169.223.19 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=30251 DF PROTO=TCP SPT=3128 DPT=1036 WINDOW=17520 RES=0x00 ACK SYN URGP=0
Jan 17 08:27:53 fw223 kernel: --rest-muell-- IN=eth0 OUT=eth0 SRC=129.223.0.7 DST=192.169.223.19 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=30257 DF PROTO=TCP SPT=3128 DPT=1037 WINDOW=17520 RES=0x00 ACK SYN URGP=0
Jan 17 08:27:53 fw223 kernel: --rest-muell-- IN=eth0 OUT=eth0 SRC=129.223.0.2 DST=192.169.223.15 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=25836 DF PROTO=TCP SPT=3322 DPT=445 WINDOW=65535 RES=0x00 ACK URGP=0
Jan 17 08:27:54 fw223 kernel: --rest-muell-- IN=eth0 OUT=eth0 SRC=129.223.0.7 DST=192.169.223.19 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=30392 PROTO=ICMP TYPE=0 CODE=0 ID=512 SEQ=1024

ifconfig

eth0 Link encap:Ethernet HWaddr 00:02:B3:B4:7C:99
inet addr:129.223.1.1 Bcast:129.223.255.255 Mask:255.255.0.0
inet6 addr: fe80::202:b3ff:feb4:7c99/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:55017228 errors:0 dropped:0 overruns:0 frame:0
TX packets:54647362 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3873919532 (3694.4 Mb) TX bytes:668548470 (637.5 Mb)

eth1 Link encap:Ethernet HWaddr 00:02:B3:B4:7B:E8
inet addr:129.93.223.2 Bcast:129.93.223.3 Mask:255.255.255.252
inet6 addr: fe80::202:b3ff:feb4:7be8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:34425952 errors:0 dropped:0 overruns:0 frame:0
TX packets:33423697 errors:34 dropped:0 overruns:0 carrier:34
collisions:196915 txqueuelen:1000
RX bytes:2589026891 (2469.0 Mb) TX bytes:1740708484 (1660.0 Mb)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:8144122 errors:0 dropped:0 overruns:0 frame:0
TX packets:8144122 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3762782491 (3588.4 Mb) TX bytes:3762782491 (3588.4 Mb)

und

netstat -nr

129.93.223.0 0.0.0.0 255.255.255.252 U 0 0 0 eth1
192.169.223.0 129.223.1.3 255.255.255.0 UG 0 0 0 eth0
192.170.223.0 129.223.1.4 255.255.255.0 UG 0 0 0 eth0
192.168.223.0 129.223.1.2 255.255.255.0 UG 0 0 0 eth0
129.223.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 129.93.223.1 0.0.0.0 UG 0 0 0 eth1


installierte IPTables version v1.3.1, dazu muss ich sagen, dassmit der version 1.2.5 trat dieses Problem nicht.
 
OP
L

luxman

Newbie
Leute habt ihr keine Ideen, ich bin schon seit Woche dabei, und hab auch schon keine Ideen mehr.

Es kann aber nicht sein das ich allei das Problem habe.
 
OP
L

luxman

Newbie
Ok Leute das hab ich gelöst.

Folgendes: die geblockte pakete wurden als INVALID markiert deswegen.

Um das festzustellen habe ich zuzatlich noch Log regel für invalid pakete hinzugefügt, danach war alles einfach

zu -m --state NEW,RELATET, ESTABLISHED,INVALID

Alles leuft.

P.S. Das ganze Problem wurde von schlechte LAN Infrastruktur (ROUTING) veruresacht, da ich keinen Einfluss auf Infrastruktur habe musste ich auch INVALID Pakete weiterleiten.
 
Frankie777

Frankie777

Advanced Hacker
Dann kannst Du das statefull filtern auch gleich ausschalten, wenn der Linux Rechner nicht die Verbindungen kontrollieren soll oder kann.

Du bist sicher das Du kein Masquarding brauchst...
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben