bad tcp packets?

bad tcp packets?

[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 -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?

-- 
Kevin

Re: bad tcp packets?

[Jose Maria Lopez]

El lun, 31 de 01 de 2005 a las 14:29, Kevin Van Workum escribió:
> 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?

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.


-- 
Jose Maria Lopez Hernandez
Director Tecnico de bgSEC
jkerouac@bgsec.com
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"

Re: bad tcp packets?

[Kevin Van Workum]

On Mon, 31 Jan 2005, Jose Maria Lopez wrote:

> El lun, 31 de 01 de 2005 a las 14:29, Kevin Van Workum escribió:
> > 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?
>
> 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?

-- 
Kevin

Re: bad tcp packets?

[Jose Maria Lopez]

El mar, 01 de 02 de 2005 a las 13:33, Kevin Van Workum escribió:
> On Mon, 31 Jan 2005, Jose Maria Lopez wrote:
> 
> > El lun, 31 de 01 de 2005 a las 14:29, Kevin Van Workum escribió:
> > > 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?
> >
> > 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.

-- 
Jose Maria Lopez Hernandez
Director Tecnico de bgSEC
jkerouac@bgsec.com
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"

Re: bad tcp packets?

[Jozsef Kadlecsik]

On Tue, 1 Feb 2005, Kevin Van Workum wrote:

> On Mon, 31 Jan 2005, Jose Maria Lopez wrote:
>
> > El lun, 31 de 01 de 2005 a las 14:29, Kevin Van Workum escribió:
> > > 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?
> >
> > 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  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
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