Warum werden einige Pakete gefiltert, andere nicht?

[SchlaWiener]

Guten Tag,

wir nutzen im Netzwerk David.fx von Tobit als Mail-Lösung.
Als zusätzlichen Dienst haben wir den integrierten Spamfilter am laufen. Dieser baut eine TCP-Verbindung zu *.expurgate.net (Host variiert) auf Port 55555 auf, um die erhaltenen E-Mails auf Spam zu überprüfen.

Jetzt gibt es bei uns eine Regel:

Grp-Mailserver -> Internet: spamfilter, Accept, Log=Long

Wobei die Dienstgruppe spamfilter den Dienst

tcp 1024:65535 -> 55555

enthält.

Wenn ich ins Protokoll schaue, habe ich folgende Einträge:

Code: Alles auswählen

Aug 21	11:15:02	1.1.1.1	Firewall ACCEPT	IN=eth1 OUT=ppp0 SRC=192.168.143.10 DST=195.190.135.41 
LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=31316 DF PROTO=TCP SPT=1238 DPT=55555 WINDOW=64378 RES=0x00 ACK URGP=0

Aug 21	11:15:02	1.1.1.1	Firewall ACCEPT	IN=ppp0 OUT=eth1 SRC=195.190.135.41 DST=192.168.143.10 
LEN=1165 TOS=0x00 PREC=0x00 TTL=54 ID=59133 DF PROTO=TCP SPT=55555 DPT=1238 WINDOW=6432 RES=0x00 ACK PSH URGP=0	

Soweit ja in Ordnung. Ich schicke meine Anfrage und erhalte eine Antwort.

Jetzt habe ich aber auch solche Einträge dazwischen:

Code: Alles auswählen

Aug 21	11:15:04	1.1.1.1	Firewall DROP	IN=eth1 OUT=ppp0 SRC=192.168.143.10 DST=194.145.224.52 
LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=31842 DF PROTO=TCP SPT=4841 DPT=55555 WINDOW=65495 RES=0x00 ACK FIN URGP=0
	
Aug 21	11:15:08	1.1.1.1	Firewall DROP	IN=eth1 OUT=ppp0 SRC=192.168.143.10 DST=194.145.224.52 
LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=32202 DF PROTO=TCP SPT=4841 DPT=55555 WINDOW=65495 RES=0x00 ACK FIN URGP=0	

Aug 21	11:16:04	1.1.1.1	Firewall DROP	IN=eth1 OUT=ppp0 SRC=192.168.143.10 DST=194.145.224.52 
LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=1471 DF PROTO=TCP SPT=4841 DPT=55555 WINDOW=65495 RES=0x00 ACK FIN URGP=0

Ich verstehe nicht warum die Pakete gefiltert werden. Den einzigen Unterschied, den ich sehe ist, dass die Destination IP anders ist. Aber wie ich schon sagte, variiert die IP, da dahinter wohl eine Serverfarm steht und so das Load Balancing geregelt ist.
Und meine Regel greift ja für "any" und ist die erste Regel in der Liste.



Hat irgendjemand eine Idee, warum die Pakete gefiltert wurden? Ich bin echt ratlos.

[Erik]

Guten Tag,
die Pakete (TCP-Flags: FIN+ACK) werden vermutlich geDROPt, weil die Firewall vorher kein FIN in der Gegenrichtung bekommen hat. Sind das die einzigen Pakete, die verworfen werden können Sie das soweit ignorieren, da es sich hierbei nur um den Verbindungsabbau handelt.

[SchlaWiener]

Vielen Dank erstmal für die schnelle Antwort,

zurzeit haben wir das Problem, dass die Identifizierung von E-Mails eben nicht mehr durchgeführt wird..
Leider ist das Log von David nicht sehr aussagekräftig. Im Protokoll steht lediglich: "SpamStatus = Not scanned (0)"

Um die Securepoint Applicance als mögliche Fehlerquelle auszuschließen: Gibt es eine Möglichkeit die Pakete trotz fehlendem FIN der Gegenseite durchzulassen?

[SchlaWiener]

Update:
So wie es aussieht werden diese Pakete auch gesendet, obwohl vorher keine Kommunikation stattgefunden hat (ich hatte gerade einige rote Einträge und keine grünen dazwischen). Evt. entspricht ein solches Paket ja nicht dem Standard, aber es schein wohl so zu sein, dass alle 5 min (wir rufen alle 5 min. E-Mails per POP3 ab) für jede abgerufene E-Mail eine Anfrage auf Port 55555 gesendet wird und dann eine Rückantwort gemeldet wird. Wenn die erste Nachricht also bereits (warum auch immer) ein FIN enthält und geblockt wird, fehlt auch die Rückmeldung.

[Erik]

Gibt es eine Möglichkeit die Pakete trotz fehlendem FIN der Gegenseite durchzulassen?

Die gibt es in der Tat:
Erstellen Sie einen neuen Dienst:
davidspam-stateless
tcp
1024:65535
55555

Damit schalten Sie die Stateful Packet Inspektion für diese Regel aus, sodass auch ein FIN+ACK ohne vorheriges FIN passieren kann.

[SchlaWiener]

Hat geklappt, besten Dank!