bad_packets problem?

bad_packets problem?

[Bill Tangren]

Hello all,

I'm new to this list.

I have a Linux (2.6.9-22.EL) box, running iptables version 
1.2.11-3.1.RHEL4. My server is sitting behind a firewall (that I don't 
control), but I have iptables running anyway, as occasionally other 
boxes behind the firewall are compromised.

I think I have a problem with iptables. Part of the script that I use to 
set up iptables is as follows:

IPT="/sbin/iptables"
$IPT -N bad_packets
# bad_packets chain
#

# Drop INVALID packets immediately
$IPT -A bad_packets -p ALL -m state --state INVALID -j LOG \
     --log-prefix "Invalid packet: "
$IPT -A bad_packets -p ALL -m state --state INVALID -j DROP
# Then check the tcp packets for additional problems
$IPT -A bad_packets -p tcp -j bad_tcp_packets
# All good, so return
$IPT -A bad_packets -p ALL -j RETURN


When implemented, this shows up in /etc/sysconfig/iptables as:

-A bad_packets -m state --state INVALID -j LOG --log-prefix "Invalid
  packet: "
-A bad_packets -m state --state INVALID -j DROP
-A bad_packets -p tcp -j bad_tcp_packets
-A bad_packets -j RETURN


So far, so good.

A program called LogWatch summarizes the logs for me. When I use up2date 
to update my RedHat software, I get entries in the log that show up in 
the LogWatch email. The thing is, the "Invalid packet" rule catches a 
few hundred packets a day, and logs them. A number of those packets come 
from 209.132.177.100 (xmlrpc.rhn.redhat.com), the rhn up2date server. 
The LogWatch output can look like this:

 From 209.132.177.100 - 24 packets
   To 10.1.5.154 - 24 packets
      Service: 33353 (tcp/33353) (Invalid packet:,eth0,none) - 4 packets
      Service: 33935 (tcp/33935) (Invalid packet:,eth0,none) - 10 packets
      Service: 33951 (tcp/33951) (Invalid packet:,eth0,none) - 10 packets

The updates take place eventually, but almost never on the first go.
I get LogWatch entries like this every time I run up2date. I am assuming 
that there is some problem with the iptables rules I have set up, but I 
don't know what they might be.

Does anyone have any thoughts on this? [I posted this question on the 
redhat-list, but got no replies, so I thought I might try here.]

Bill Tangren

Re: bad_packets problem?

[/dev/rob0]

On Thursday 2005-October-20 09:52, Bill Tangren wrote:
> I have a Linux (2.6.9-22.EL) box, running iptables version
> 1.2.11-3.1.RHEL4. My server is sitting behind a firewall (that I
> don't control), but I have iptables running anyway, as occasionally
> other boxes behind the firewall are compromised.

Consider your threat model. I don't think a Windows zombie poses any 
threat to a Linux machine. The main "threat" to Linux machines these 
days would be the ssh attack bots, which I bet run from compromised 
Unix-like machines. Good sense in securing your sshd and strong 
passwords (if you even allow password authentication) protects you 
quite well.

A good firewall won't hurt, but it might not matter much.

> $IPT -A bad_packets -p ALL -j RETURN

"-p ALL" is always superfluous, as is a "-j RETURN" rule at the end of
a chain.

> up2date to update my RedHat software, I get entries in the log that
> show up in the LogWatch email. The thing is, the "Invalid packet"
> rule catches a few hundred packets a day, and logs them. A number of
> those packets come from 209.132.177.100 (xmlrpc.rhn.redhat.com), the
> rhn up2date server. The LogWatch output can look like this:
>
>  From 209.132.177.100 - 24 packets
>    To 10.1.5.154 - 24 packets
>       Service: 33353 (tcp/33353) (Invalid packet:,eth0,none) - 4
snip
> The updates take place eventually, but almost never on the first go.
> I get LogWatch entries like this every time I run up2date. I am
> assuming that there is some problem with the iptables rules I have
> set up, but I don't know what they might be.

Not likely. From "man iptables", MATCH EXTENSIONS, state:
    "... Possible states [include] INVALID meaning that  the  packet
    could  not  be identified for some reason which includes running
    out of memory and ICMP errors  which  don't  correspond  to  any
    known connection ..."

For some reason connection tracking is not identifying this connection. 
It is possible that you have some rule in mangle or nat tables which is 
interfering with conntrack, but the rules you showed us would not cause 
those packets to be in state INVALID.

A probable workaround is to put an exception rule for your up2date 
server or ports prior to your INVALID rules.

> Does anyone have any thoughts on this? [I posted this question on the
> redhat-list, but got no replies, so I thought I might try here.]

Is that a general-purpose list? You might want to go to the up2date 
developers.
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

Re: bad_packets problem?

[Henrik Nordstrom]

On Thu, 20 Oct 2005, Bill Tangren wrote:

> From 209.132.177.100 - 24 packets
>  To 10.1.5.154 - 24 packets
>     Service: 33353 (tcp/33353) (Invalid packet:,eth0,none) - 4 packets
>     Service: 33935 (tcp/33935) (Invalid packet:,eth0,none) - 10 packets
>     Service: 33951 (tcp/33951) (Invalid packet:,eth0,none) - 10 packets

What does the actual log entries look like?

> The updates take place eventually, but almost never on the first go.
> I get LogWatch entries like this every time I run up2date. I am assuming that 
> there is some problem with the iptables rules I have set up, but I don't know 
> what they might be.

Not neccesarily. Could just be poor connectivity to the RHN up2date 
servers, or a bad choice of mirrors..

Regards
Henrik