Iptables Tutorial 1.2.2 - Oskar Andreasson

Another error that you may get when running iptables is the following error.

iptables: No chain/target/match by that name

This error tells us that there is no such chain, target or match. This could depend upon a huge set of factors, the most common being that you have misspelled the chain, target or match in question. Also, this could be generated in case you are trying to use a match that is not available, either because you did not load the proper module, it was not compiled into the kernel, or iptables failed to automatically load the module. In general, you should look for all of the above solutions but also look for misspelled targets of some sort or another in your rule.

State NEW packets but no SYN bit set

There is a certain feature in iptables that is not so well documented and may therefore be overlooked by a lot of people (yes, including me). If you use state NEW, packets with the SYN bit unset will get through your firewall. This feature is there because in certain cases we want to consider that a packet may be part of an already ESTABLISHED connection on, for instance, another firewall. This feature makes it possible to have two or more firewalls, and for one of the firewalls to go down without any loss of data. The firewalling of the subnet could then be taken over by our secondary firewall. This does however lead to the fact that state NEW will allow pretty much any kind of TCP connection, regardless if this is the initial 3-way handshake or not. To take care of this problem we add the following rules to our firewalls INPUT, OUTPUT and FORWARD chain:

$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j LOG

--log-prefix "New not syn:"

$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

Caution! The above rules will take care of this problem. This is a badly documented behavior of the Netfilter/iptables project and should definitely be more highlighted. In other words, a huge warning is in its place for this kind of behavior on your firewall

Note that there are some troubles with the above rules and bad Microsoft TCP/IP implementations. The above rules will lead to certain conditions where packets generated by Microsoft product gets labeled as state NEW and hence get logged and dropped. It will however not lead to broken connections to my knowledge. The problem occurs when a connection gets closed, the final FIN/ACK is sent, the state machine of Netfilter closes the connection and it is no longer in the conntrack table. At this point the faulty Microsoft implementation sends another packet which is considered as state NEW but lacks the SYN bit and hence gets matched by the above rules. In other words, don't worry to much about this rule, or if you are worried anyways, set the --log-headers option to the rule and log the headers too and you'll get a better look at what the packet looks like.

There is one more known problem with these rules. If someone is currently connected to the firewall, let's say from the LAN, and you have the script set to be activated when running a PPP connection. In this case, when you start the PPP connection, the person previously connected through the LAN will be more or less killed. This only applies when you are running with the conntrack and nat code bases as modules, and the modules are loaded and unloaded each time you run the script. Another way to get this problem is to run the rc.firewall.txt script from a telnet connection from a host not on the actual firewall. To put it simply, you connect with telnet or some other stream connection. Start the connection tracking modules, then load the NEW not SYN packet rules. Finally, the telnet client or daemon tries to send something. the connection tracking code will not recognize this connection as a legal connection since it has not seen packets in any direction on this connection before, also there will be no SYN bits set since it is not actually the first packet in the connection. Hence, the packet will match to the rules and be logged and after-wards dropped to the ground.

SYN/ACK and NEW packets

Certain TCP spoofing attacks uses a technique called Sequence Number Prediction. In this type of attack, the attacker spoofs some other hosts IP address, while attacking someone, and tries to predict the Sequence number used by that host.

Let's look on typical TCP spoofing by sequence number prediction. Players: "attacker" [A], trying to send packets to a "victim" [V], pretending to be some "other host" [O].

[A] sends SYN to [V] with source IP of [O].

[V] replies to [O] by SYN/ACK.

now [O] should reply to an unknown SYN/ACK by RST and the attack is unsuccesful, but let's assume [O] is down (flooded, turned off or behind firewall that has dropped the packets).

if [O] didn't mess it up, [A] now can talk to [V] pretending to be [O] as long as it predicts correct sequence numbers.

As long as we do not send the RST packet to the unknown SYN/ACK in step 3, we will allow [V] to be attacked, and ourselves to be incriminated. Common courtesy, would hence be to send the RST to [V] in a proper way. If we use the NEW not SYN rules specified in the ruleset, SYN/ACK packets will be dropped. Hence, we have the following rules in the bad_tcp_packets chain, just above the NEW not SYN rules:

iptables -A bad_tcp_packets -p tcp --tcp-flags SYN,ACK SYN,ACK

-m state --state NEW -j REJECT --reject-with tcp-reset

The chance of being [O] in this scenario should be relatively small, but these rules should be safe in almost all cases. Except when you run several redundant firewalls which will often take over packets or streams from each other. In such case, some connections may be blocked, even though they are legit. This rule may actually also allow a few portscans to see our firewall as well, but they should not be able to tell much more than that.

Internet Service Providers who use assigned IP addresses

I have added this since a friend of mine told me something I have totally forgotten. Certain stupid Internet Service Providers use IP addresses assigned by IANA for their local networks on which you connect to. For example, the Swedish Internet Service Provider and phone monopoly Telia uses this approach for example on their DNS servers, which uses the 10.x.x.x IP address range. A common problem that you may run into when writing your scripts, is that you do not allow connections from any IP addresses in the 10.x.x.x range to yourself, because of spoofing possibilities. Well, here is unfortunately an example where you actually might have to lift a bit on those rules. You might just insert an ACCEPT rule above the spoof section to allow traffic from those DNS servers, or you could just comment out that part of the script. This is how it might look:

/usr/local/sbin/iptables -t nat -I PREROUTING -i eth1 -s

10.0.0.1/32 -j ACCEPT

I would like to take my moment to bitch at these Internet Service Providers. These IP address ranges are not assigned for you to use for dumb stuff like this, at least not to my knowledge. For large corporate sites it is more than o.k., or your own home network, but you are not supposed to force us to open up ourselves just because of some whim of yours. You are large Internet providers, and if you can't afford buying some 3-4 IP addresses for your DNS servers, I have a very hard time trusting you.

Letting DHCP requests through iptables

This is a fairly simple task really, once you get to know how DHCP works, however, you must be a little bit cautious with what you do let in and what you do not let in. First of all, we should know that DHCP works over the UDP protocol. Hence, this is the first thing to look for. Second, we should check which interface we get and send the request from. For example, if our eth0 interface is set up with DHCP, we should not allow DHCP requests on eth1. To make the rule a bit more specific, we only allow the actual UDP ports used by DHCP, which should be ports 67 and 68. These are the criteria that we choose to match packets on, and that we allow. The rule would now look like this:

$IPTABLES -I INPUT -i $LAN_IFACE -p udp --dport 67:68 --sport

67:68 -j ACCEPT

Do note that we allow all traffic to and from UDP port 67 and 68 now, however, this should not be such a huge problem since it only allows requests from hosts doing the connection from port 67 or 68 as well. This rule could, of course, be even more restrictive, but it should be enough to actually accept all DHCP requests and updates without opening up too large of holes. If you are concerned, this rule could of course be made even more restrictive.

mIRC DCC problems

mIRC uses a special setting which allows it to connect through a firewall and to make DCC connections work properly without the firewall knowing about it. If this option is used together with iptables and specifically the ip_conntrack_irc and ip_nat_irc modules, it will simply not work. The problem is that mIRC will automatically NAT the inside of the packets for you, and when the packet reaches the firewall, the firewall will simply not know how and what to do with it. mIRC does not expect the firewall to be smart enough to take care of this by itself by simply querying the IRC server for its IP address and sending DCC requests with that address instead.

Turning on the "I am behind a firewall" configuration option and using the ip_conntrack_irc and ip_nat_irc modules will result in Netfilter creating log entries with the following content "Forged DCC send packet".

The simplest possible solution is to just uncheck that configuration option in mIRC and let iptables do the work. This means, that you should tell mIRC specifically that it is not behind a firewall.

Appendix C. ICMP types

This is a complete listing of all ICMP types. Note the reference pointing to the RFC or person who introduced the type and code. For a complete and absolute up to date listing of all ICMP types and codes, look at the icmp-parameters document at Internet Assigned Numbers Authority.

Note Iptables and netfilter uses ICMP type 255 internally since it is not reserved for any real usage, and most likely will never have any real usage. If you set a rule to match iptables -A INPUT -p icmp --icmp-type 255 -j DROP, this will DROP all ICMP packets. It is in other words used to match all ICMP types.

Table C-1. ICMP types

TYPE CODE Description Query Error Reference 0 0 Echo Reply x   RFC792 3 0 Network Unreachable   x RFC792 3 1 Host Unreachable   x RFC792 3 2 Protocol Unreachable   x RFC792 3 3 Port Unreachable   x RFC792 3 4 Fragmentation needed but no frag. bit set   x RFC792 3 5 Source routing failed   x RFC792 3 6 Destination network unknown   x RFC792 3 7 Destination host unknown   x RFC792 3 8 Source host isolated (obsolete)   x RFC792 3 9 Destination network administratively prohibited   x RFC792 3 10 Destination host administratively prohibited   x RFC792 3 11 Network unreachable for TOS   x RFC792 3 12 Host unreachable for TOS   x RFC792 3 13 Communication administratively prohibited by filtering   x RFC1812 3 14 Host precedence violation   x RFC1812 3 15 Precedence cutoff in effect   x RFC1812 4 0 Source quench     RFC792 5 0 Redirect for network     RFC792 5 1 Redirect for host       5 2 Redirect for TOS and network     RFC792 5 3 Redirect for TOS and host     RFC792 8 0 Echo request x   RFC792 9 0 Router advertisement - Normal router advertisement     RFC1256 9 16 Router advertisement - Does not route common traffic     RFC2002 10 0 Route selection     RFC1256 11 0 TTL equals 0 during transit   x RFC792 11 1 TTL equals 0 during reassembly   x RFC792 12 0 IP header bad (catchall error)   x RFC792 12 1 Required options missing   x RFC1108 12 2 IP Header bad length   x RFC792 13 0 Timestamp request (obsolete) x   RFC792 14   Timestamp reply (obsolete) x   RFC792 15 0 Information request (obsolete) x   RFC792 16 0 Information reply (obsolete) x   RFC792 17 0 Address mask request x   RFC950 18 0 Address mask reply x   RFC950 20-29   Reserved for robustness experiment     Zaw-Sing Su 30 0 Traceroute x   RFC1393 31 0 Datagram Conversion Error   x RFC1475 32 0 Mobile Host Redirect     David Johnson 33 0 IPv6 Where-Are-You x   Bill Simpson 34 0 IPv6 I-Am-Here x   Bill Simpson 35 0 Mobile Registration Request x   Bill Simpson 36 0 Mobile Registration Reply x   Bill Simpson 39 0 SKIP     Tom Markson 40 0 Photuris     RFC2521

Appendix D. TCP options