IPTABLES block Paket auf Port 80/443

[lukesky333]

Hallo liebe Community,

ich habe ein recht mysteriöses Problem mit IPTABLES und hoffe, das mir hier jemand weiterhelfen kann.

Ich nutze Firewall-Builder zur Erstellung aller Regeln für unseren Webserver. Das funktioniert soweit auch recht gut und es gab bis dato kaum Probleme. Seit neuestem ist mir aufgefallen, dass trotz expliziter Freigabe des Ports 80 & 443 immer wieder (aber nicht immer) Pakete gedropt werden.

Code: Alles auswählen

Nov 17 14:09:18 web01 kernel: [544377.078958] Global DenyIN=eth0 OUT= MAC=ab:cd:ef:be:cf:78:ab:cd:ef:20:8e:08:ab SRC=XXX.XXX.XXX.XXX DST=YYY.YYY.YYY.YYY LEN=52 TOS=0x00 PREC=0x00 TTL=53 ID=51967 DF PROTO=TCP SPT=54776 DPT=80 WINDOW=33120 RES=0x00 ACK FIN URGP=0 OPT (0101080A2D6FCD2D081B4A55)

Hier mal die Regel, die den Verkehr eigentlich durchlassen solte:

Code: Alles auswählen

ACCEPT     tcp  --  anywhere             web.example.com  tcp multiport dports http,https state NEW

Kann mir jemand erklären, wie es dazu kommt?

[tuxedo]

Hallo

Wie sehen die restlichen Regeln aus?
Grüsse

[lukesky333]

Also generell sperre ich mal alles und lasse dann die Sachen durch, die auch durchkommen sollen. Hier mal der Output von iptables -L:

Code: Alles auswählen

Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
ACCEPT     tcp  --  gw.example.com   anywhere             tcp dpt:ssh state NEW,ESTABLISHED
In_RULE_0  tcp  --  web.example.com  anywhere             tcp
In_RULE_0  all  --  web.example.com  anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     tcp  --  anywhere             web.example.com  tcp multiport dports http,https state NEW
Cid31234X24993.0  all  --  anywhere             web.example.com  state NEW
Cid10717X4644.0  all  --  anywhere             web.example.com  state NEW
Cid28510X4972.0  tcp  --  anywhere             web.example.com  tcp dpt:ftp state NEW
REJECT     tcp  --  anywhere             web.example.com  tcp dpt:auth reject-with icmp-port-unreachable
In_RULE_8  all  --  anywhere             anywhere            

Chain FORWARD (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED

Chain OUTPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
ACCEPT     tcp  --  anywhere             gw.example.com   tcp spt:ssh state RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  web.example.com  anywhere             state NEW
Out_RULE_8  all  --  anywhere             web.example.com 

Chain Cid10717X4644.0 (1 references)
target     prot opt source               destination         
ACCEPT     all  --  aaa.vie.surfer.at  anywhere            
ACCEPT     all  --  bbb.vie.surfer.at  anywhere            
ACCEPT     all  --  ccc.vie.surfer.at  anywhere            
ACCEPT     all  --  ddd.inode.at  anywhere            
ACCEPT     all  --  eee.inode.at  anywhere            
ACCEPT     all  --  fff.vie.surfer.at  anywhere            
ACCEPT     all  --  ggg.vie.surfer.at  anywhere            
ACCEPT     all  --  hhh.vie.surfer.at  anywhere            
ACCEPT     all  --  gw.example.com   anywhere            
ACCEPT     all  --  gw.example.com   anywhere            
ACCEPT     all  --  iii.inode.at  anywhere            
ACCEPT     all  --  jjj.inode.at  anywhere            

Chain Cid28510X4972.0 (1 references)
target     prot opt source         destination         
RULE_6     all  --  88.88.88.88    anywhere            
RULE_6     all  --  99.99.99.99    anywhere    

Chain Cid31234X24993.0 (1 references)
target     prot opt source               destination         
ACCEPT     icmp --  anywhere             anywhere             icmptype 8 code 0
ACCEPT     icmp --  anywhere             anywhere             icmptype 30 code 0
ACCEPT     udp  --  anywhere             anywhere             udp dpts:33434:33524

Chain In_RULE_0 (2 references)
target     prot opt source               destination         
LOG        all  --  anywhere             anywhere             LOG level info tcp-options ip-options prefix "spoofing"
REJECT     tcp  --  anywhere             anywhere             tcp reject-with tcp-reset
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable

Chain In_RULE_8 (1 references)
target     prot opt source               destination         
LOG        all  --  anywhere             anywhere             LOG level info tcp-options ip-options prefix "Global Deny"
DROP       all  --  anywhere             anywhere            

Chain Out_RULE_8 (1 references)
target     prot opt source               destination         
LOG        all  --  anywhere             anywhere             LOG level info tcp-options ip-options prefix "Global Deny"
DROP       all  --  anywhere             anywhere            

Chain RULE_6 (2 references)
target     prot opt source               destination         
LOG        all  --  anywhere             anywhere             LOG level info tcp-options ip-options prefix "RULE 6 -- ACCEPT "
ACCEPT     all  --  anywhere             anywhere 

[MSfree]

Code: Alles auswählen

Nov 17 14:09:18 web01 kernel: [544377.078958] Global DenyIN=eth0 OUT= MAC=ab:cd:ef:be:cf:78:ab:cd:ef:20:8e:08:ab SRC=XXX.XXX.XXX.XXX DST=YYY.YYY.YYY.YYY LEN=52 TOS=0x00 PREC=0x00 TTL=53 ID=51967 DF PROTO=TCP SPT=54776 DPT=80 WINDOW=33120 RES=0x00 ACK FIN URGP=0 OPT (0101080A2D6FCD2D081B4A55)

Das ist ein ACK FIN Paket, das zu keiner aktiven (establisched, related) Verbindung gehört. So etwas kann z.B. dann passieren, wenn ein Client aus dem Mobilfunknetz sich zum Stromsparen vom Netz trennt und nach einem erneuten Verbindungaufbau mit einer neuen IP-Adresse noch den ACK-FIN hinterher schickt, den es eigentlich vor dem Verbindungsabbau hätte schicken sollen. Gelegentlich sind auch "normale" Verbindungabbrüche daran schuld.

Man kann ACK-FIN auch nutzen, um DOS-Angriffe gegen Server zu fahren,, in dem man den Server mit zusammenhangslosen ACK-FIN flutet.

Ich würde mir da erst anfangen, Gedanken zu machen, wenn es wirklich sehr viele dieser Pakete werden.

[lukesky333]

Vielen Dank für die Info, damit hätte ich erstmal eine Erklärung dafür.

Eigentlich bin ich nur darauf gestossen, weil ich nach dem Grund suche, warum der Server öfter (meist Nachts) garnicht erreichbar ist. D.h. ich komme mit dem Browser nicht auf die Webseiten, Ping dagegen geht durch.

In diesem Zeitraum habe ich dann auch diese Meldungen im Syslog gefunden, was mir komisch vorkam. Im Log finde ich solche Meldungen aber generell ist der Server via Port 80 bzw. 443 nicht erreichbar?!?

Dann wird es wohl ein Problem mit dem Server sein, oder hat da noch jemand eine Idee dazu?

[MSfree]

Eigentlich bin ich nur darauf gestossen, weil ich nach dem Grund suche, warum der Server öfter (meist Nachts) garnicht erreichbar ist. D.h. ich komme mit dem Browser nicht auf die Webseiten, Ping dagegen geht durch.

Kannst du dich per SSH zu so einem Zeitpunkt auf dem Sever einlogen?

Dann könntest du nämlich die Logs nach deiner IP-Adresse durchsuchen, um festzustellen, ob wirklich iptables schuld ist. Du könntest auch das betreffende Logfile per tail -f LogDatei mitverfolgen, während du einen Verbindungsversuch via HTTP oder HTTPS unternimmst.

Auch ein mitlaufendes tcpdump oder iptraf könnten Hinweise liefern, ob der Verbindungsversuch deinen Server überhaupt erreicht.

Ist das ein vServer, der eventuell ein wenig überbucht ist und nachts riesige Backups die IO-Kanäle des Hostsystems verstopfen?

[lukesky333]

Per SSH bin ich letzte Nacht nicht reingekommen, weil mein Provider wieder mal (ungefragt) meine IP geändert hat und die nicht in der Firewall freigeschalten war.
Ich hab aber heute vom Büro aus auf dem Server im Log-File nachgesehen und dort ähnlich "Deny-Meldungen" für meine IP gefunden. Also zum Server scheinen die Requests zu kommen nur werden die zur Gänze abgelehnt oder aber auch nur aus dem von MSfree genannten Grund, was dann wohl eher ein Problem beim Apache bedeuten würde.

Bin echt ratlos... Wollte nun Cacti installieren, das gestaltet sich unter Ubuntu 12.04 LTS mit aktuellem PHP auch nicht so einfach... Ich steh mal wieder an!