Custom chains in Iptables

colucix · 07-11-2008, 07:23 AM

I have a question related to the general functioning of iptables. I know that when a packet is processed by the firewall/iptables, the rules in a chain are applied in order. If the packet matches the first rule, an action is taken otherwise it is subjected to the next rule.

Some targets - like ACCEPT and DROP - will cause the packet to stop traversing that specific chain, whereas some other targets - like LOG - may take an action on the packet, after which the packet will continue passing through the rest of the rules.

Based on this little knowledge, I don't understand how the following setup (created by firestarter) works. It defines a custom chain called INBOUND, referenced by the INPUT chain:

Code:

Chain INPUT (policy DROP 89 packets, 13385 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     tcp  --  *      *       XXX.XXX.XXX.XX       0.0.0.0/0           tcp flags:!0x17/0x02 
  379 73149 ACCEPT     udp  --  *      *       XXX.XXX.XXX.XX       0.0.0.0/0           
    0     0 ACCEPT     tcp  --  *      *       XXX.XXX.XXX.XX       0.0.0.0/0           tcp flags:!0x17/0x02 
    0     0 ACCEPT     udp  --  *      *       XXX.XXX.XXX.XX       0.0.0.0/0           
  466 33353 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
   31  1891 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 10/sec burst 5 
26762   13M DROP       all  --  eth0   *       0.0.0.0/0            255.255.255.255     
76073 6836K DROP       all  --  *      *       0.0.0.0/0            XXX.XXX.XXX.255     
    0     0 DROP       all  --  *      *       255.255.255.255      0.0.0.0/0           
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0             
   90  9150 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           state INVALID 
    0     0 LSI        all  -f  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 10/min burst 5 
14287 9704K INBOUND    all  --  eth0   *       0.0.0.0/0            0.0.0.0/0           
 7785 4819K INBOUND    all  --  eth1   *       0.0.0.0/0            192.168.0.1         
    0     0 INBOUND    all  --  eth1   *       0.0.0.0/0            XXX.XXX.XXX.XXX     
    0     0 INBOUND    all  --  eth1   *       0.0.0.0/0            192.168.0.255       
   89 13385 LOG_FILTER  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
   89 13385 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 6 prefix `Unknown Input'

Chain INBOUND (4 references)
 pkts bytes target     prot opt in     out     source               destination         
 5822  921K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
 1802  137K ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
    0     0 ACCEPT     tcp  --  *      *       192.168.0.10         0.0.0.0/0           tcp dpt:3551 
    0     0 ACCEPT     udp  --  *      *       192.168.0.10         0.0.0.0/0           udp dpt:3551 
    4   240 ACCEPT     tcp  --  *      *       192.168.0.4          0.0.0.0/0           tcp dpt:22 
    0     0 ACCEPT     udp  --  *      *       192.168.0.4          0.0.0.0/0           udp dpt:22 
 4897 1092K LSI        all  --  *      *       0.0.0.0/0            0.0.0.0/0

As you can see, in the middle of the INPUT chain there is a DROP target (marked in red) which drops all packets from anywhere to anywhere. After that, there are the rules that transfer control to the custom chain INBOUND. I don't understand how can a packet jump to the UNBOUND chain if it has been dropped by a preceeding rule.

Anyway, this setup works, as you can see from the packets and bytes count. Also notice that the count of the above mentioned DROP rule is zero. Maybe I'm missing something. Can you help me to understand?

acid_kewpie · 07-11-2008, 07:43 AM

I'd assume that the actual command itself is more complex than the output provided. dig through the original script and find what's being run.

colucix · 07-11-2008, 08:04 AM

I was just digging through it. Looking at the code that creates the "incriminated" DROP rule:

Code:

# Block Traffic with Stuffed Routing
#  Early versions of PUMP - (the DHCP client application included in RH / Mandrake) require
#  inbound packets to be accepted from a source address of 255.255.255.255.  If you have issues
#  with DHCP clients on your local LAN - either update PUMP, or remove the first rule below)
$IPT -A INPUT -s 255.255.255.255 -j DROP
$IPT -A INPUT -d 0.0.0.0 -j DROP
$IPT -A OUTPUT -s 255.255.255.255 -j DROP
$IPT -A OUTPUT -d 0.0.0.0 -j DROP

make me notice that the destination address is 0.0.0.0 instead of 0.0.0.0/0, as set in other rules. What does this mean? Maybe this is the reason why this rule apparently has not dropped any packet yet.