bad tcp packets?
I'm learning about iptables and am working through the example scripts in Oskar Andreasson's Iptables Tutorial 1.1.19. So I have the following rules:
iptables -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j LOG --log-prefix "New not syn:" iptables -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j DROP
My understanding of this rule is that all NEW tcp packets should by SYN also. So if they are not NEW and SYN, then we should log them and drop them. I guess Andreasson wants to log them because they may indicate a problem of some sort. So in my log file, I get this:
Jan 30 20:09:27 server kernel: New not syn:IN= OUT=lo SRC=10.0.0.100 DST=10.0.0.100 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=7678 DF PROTO=TCP SPT=34928 DPT=143 WINDOW=32767 RES=0x00 ACK PSH FIN URGP=0
So what's the problem with these packets? It looks like some client is contacting the imapd (which is running on my firewall) with some bad tcp packets?
Signature · 1 line
Kevin
Quoted 13 lines · Kevin Van Workum
I'm learning about iptables and am working through the example scripts in Oskar Andreasson's Iptables Tutorial 1.1.19. So I have the following rules:
iptables -A
bad_tcp_packets-p tcp ! --syn -m state --state NEW -j LOG --log-prefix "New not syn:"
iptables -Abad_tcp_packets-p tcp ! --syn -m state --state NEW -j DROPMy understanding of this rule is that all NEW tcp packets should by SYN also. So if they are not NEW and SYN, then we should log them and drop them. I guess Andreasson wants to log them because they may indicate a problem of some sort. So in my log file, I get this:
Quoted 7 lines
Jan 30 20:09:27 server kernel: New not syn:IN= OUT=lo SRC=10.0.0.100DST=10.0.0.100 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=7678 DF PROTO=TCP SPT=34928 DPT=143 WINDOW=32767 RES=0x00 ACK PSH FIN URGP=0
So what's the problem with these packets? It looks like some client is contacting the imapd (which is running on my firewall) with some bad tcp packets?
NEW without SYN packets can occur but they are very uncommon, the rule proposed it's correct in the 99% of the systems, but if you have a program or daemon that doesn't make the SYN/ACK-SYN/ACK correctly then you maybe have to allow this packets.
Another situation when you could have this kind of packets is when you have two firewalls in high availability and one of them have a failover, then the packets are seen as NEW by the conntrack system but they doesn't have the SYN.
Regards.
Signature · 12 lines
Jose Maria Lopez Hernandez Director Tecnico de bgSEC [email protected] bgSEC Seguridad y Consultoria de Sistemas Informaticos http://www.bgsec.com ESPAÑA The only people for me are the mad ones -- the ones who are mad to live, mad to talk, mad to be saved, desirous of everything at the same time, the ones who never yawn or say a commonplace thing, but burn, burn, burn like fabulous yellow Roman candles. -- Jack Kerouac, "On the Road"
Quoted 18 lines · Jose Maria Lopez
El lun, 31 de 01 de 2005 a las 14:29, Kevin Van Workum escribió:
Quoted 17 lines
I'm learning about iptables and am working through the example scripts in Oskar Andreasson's Iptables Tutorial 1.1.19. So I have the following rules:
iptables -A
bad_tcp_packets-p tcp ! --syn -m state --state NEW -j LOG --log-prefix "New not syn:"
iptables -Abad_tcp_packets-p tcp ! --syn -m state --state NEW -j DROPMy understanding of this rule is that all NEW tcp packets should by SYN also. So if they are not NEW and SYN, then we should log them and drop them. I guess Andreasson wants to log them because they may indicate a problem of some sort. So in my log file, I get this:
Jan 30 20:09:27 server kernel: New not syn:IN= OUT=lo SRC=10.0.0.100DST=10.0.0.100 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=7678 DF PROTO=TCP SPT=34928 DPT=143 WINDOW=32767 RES=0x00 ACK PSH FIN URGP=0
Quoted 8 lines
Quoted 3 lines
So what's the problem with these packets? It looks like some client is contacting the imapd (which is running on my firewall) with some bad tcp packets?
NEW without SYN packets can occur but they are very uncommon, the rule proposed it's correct in the 99% of the systems, but if you have a program or daemon that doesn't make the SYN/ACK-SYN/ACK correctly then you maybe have to allow this packets.
Is there a way to determine which program or daemon is producing these packets?
Signature · 1 line
Kevin
Quoted 24 lines · Kevin Van Workum
Quoted 22 lines · Jose Maria Lopez
Quoted 20 lines · Kevin Van Workum
I'm learning about iptables and am working through the example scripts in Oskar Andreasson's Iptables Tutorial 1.1.19. So I have the following rules:
iptables -A
bad_tcp_packets-p tcp ! --syn -m state --state NEW -j LOG --log-prefix "New not syn:"
iptables -Abad_tcp_packets-p tcp ! --syn -m state --state NEW -j DROPMy understanding of this rule is that all NEW tcp packets should by SYN also. So if they are not NEW and SYN, then we should log them and drop them. I guess Andreasson wants to log them because they may indicate a problem of some sort. So in my log file, I get this:
Jan 30 20:09:27 server kernel: New not syn:IN= OUT=lo SRC=10.0.0.100DST=10.0.0.100 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=7678 DF PROTO=TCP SPT=34928 DPT=143 WINDOW=32767 RES=0x00 ACK PSH FIN URGP=0
So what's the problem with these packets? It looks like some client is contacting the imapd (which is running on my firewall) with some bad tcp packets?
Quoted 7 lines
Quoted 4 lines
NEW without SYN packets can occur but they are very uncommon, the rule proposed it's correct in the 99% of the systems, but if you have a program or daemon that doesn't make the SYN/ACK-SYN/ACK correctly then you maybe have to allow this packets.
Is there a way to determine which program or daemon is producing these packets?
The problematic packets are being sent from your own machine through the lo interface, so you can use some -m owner rules to log the packets. Just make a -m owner --pid-owner with the pids of the suspecting daemons or programs you are running and a different log for each of these and then you can see what program it's sending the data.
Regards.
Signature · 12 lines
Jose Maria Lopez Hernandez Director Tecnico de bgSEC [email protected] bgSEC Seguridad y Consultoria de Sistemas Informaticos http://www.bgsec.com ESPAÑA The only people for me are the mad ones -- the ones who are mad to live, mad to talk, mad to be saved, desirous of everything at the same time, the ones who never yawn or say a commonplace thing, but burn, burn, burn like fabulous yellow Roman candles. -- Jack Kerouac, "On the Road"
Quoted 24 lines · Kevin Van Workum
Quoted 22 lines · Jose Maria Lopez
El lun, 31 de 01 de 2005 a las 14:29, Kevin Van Workum escribió:
Quoted 20 lines
I'm learning about iptables and am working through the example scripts in Oskar Andreasson's Iptables Tutorial 1.1.19. So I have the following rules:
iptables -A
bad_tcp_packets-p tcp ! --syn -m state --state NEW -j LOG --log-prefix "New not syn:"
iptables -Abad_tcp_packets-p tcp ! --syn -m state --state NEW -j DROPMy understanding of this rule is that all NEW tcp packets should by SYN also. So if they are not NEW and SYN, then we should log them and drop them. I guess Andreasson wants to log them because they may indicate a problem of some sort. So in my log file, I get this:
Jan 30 20:09:27 server kernel: New not syn:IN= OUT=lo SRC=10.0.0.100DST=10.0.0.100 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=7678 DF PROTO=TCP SPT=34928 DPT=143 WINDOW=32767 RES=0x00 ACK PSH FIN URGP=0
So what's the problem with these packets? It looks like some client is contacting the imapd (which is running on my firewall) with some bad tcp packets?
Quoted 7 lines
Quoted 4 lines
NEW without SYN packets can occur but they are very uncommon, the rule proposed it's correct in the 99% of the systems, but if you have a program or daemon that doesn't make the SYN/ACK-SYN/ACK correctly then you maybe have to allow this packets.
Is there a way to determine which program or daemon is producing these packets?
Any program or daemon may do, considering the following scenario: there are established connections going through your firewall and you remove then load in again the ip_conntrack module.
But the packages above are more probably late FIN packets: the conection was deleted from the conntrack table and then a delayed FIN packet belonging to the deleted connection arrived.
Best regards,
Jozsef
-
E-mail : [email protected], [email protected] PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
H-1525 Budapest 114, POB. 49, Hungary