A NATural Progression

David continues his series on the Netfilter framework with a look at NAT and how to avoid common errors when constructin iptales rules.
Protecting Your Data

It's very difficult to make sure someone on the inside isn't passing data through your firewall that shouldn't go out. And maybe some folks have a legitimate reason for passing company data out through the firewall. But let's assume for now that that's not the case. You want to stop certain data from leaving (or at least attempt to do so).

We can try to prevent certain data from leaving by marking that data, then looking for that mark using the string match. Here I suggest a policy of putting a string, such as “Copyright, foo.corp, not for publication” at the top of those files you don't want sent through the firewall. Then, on the inner firewall, or as a rule on eth2 (where eth0 is the Internet, eth1 is the untrusted LAN and eth2 is the trusted LAN) on your outer firewall, you might want something like this:

iptables -t filter -I FORWARD -i eth2 -m string
--string="Copyright, foo.corp, not for publication"

A few words about this particular solution. First, ensure you have the ipconntrack module loaded. This will defragment packets and result in a much higher likelihood of seeing the string. Second, don't expect this to catch everything. Particularly, if a file has been compressed, the phrase will not be recognizable as such. So this does have limitations.

It will work very nicely, however, if you are running an IIS server and want to drop packets with the string root.exe, for example. The rule might look like this:

iptables -t filter -I FORWARD -m string
--string=root.exe -j DROP

While it might be amusing to use the MIRROR target and turn the attack back on the attacker, this would be an ethically questionable thing to do.

You also have the PSD (port-scan detection) match if you're still subject to this kind of activity. I don't see so much port scanning anymore as I see script kiddies that have a particular tool; they aim it at my systems and fire. Usually it's an FTP attack designed to compromise an IIS server running FrontPage extensions. I see an FTP in, then lots of activity trying to create _vti_private files and the like. We can stop this with:

iptables -t filter -I FORWARD -i eth0 -p tcp
--dport 21 -m string
--string="_vti_private" -j REJECT

Obviously, if you're running a FrontPage server and folks aren't “publishing” to it (which uses port 80) but moving their sites via FTP, the above won't work.

Targets and Matches and More, Oh My!

This article has not touched on a large number of extensions and targets. Some of you with very specific routing requirements might want to look at the MARK target, with or without the realm match, to do some really funky routing tricks. This will require use of iproute2 in conjunction with iptables. This is a very powerful combination for ISPs or others with very specific routing and bandwidth-limiting requirements.

Others of you probably wanted to see some ULOG target examples or iplimit or mport examples. But these are very similar to other matches or targets and are handled in the same way. Often the help in the kernel configuration will show you enough of an iptables rule fragment to make use of these extensions.

Just remember, only ACCEPT, DROP or REJECT are final targets for a packet and stop iptables processing of a packet. The RETURN target only terminates a chain, but not iptables processing.

I also haven't touched on the MANGLE table. But this table works in the same manner as the mangle target in ipchains. Try it out if you're so inclined. You may find you won't be able to use the numeric (hex) targets but have to use the descriptive values. If you can't remember what they are, try:

iptables -j TOS -h

This trick also works if you need a list of the ICMP types because you want to handle a particular ICMP type with iptables (such as permitting pings, which will be dropped by a firewall with -m state --state ESTABLISHED,RELATED):

iptables -p icmp -h
Armed with the correct ICMP name, echo-request, you can permit pings:
iptables -t filter -I INPUT -i eth0 -p icmp
--icmp-type echo-request -j ACCEPT
You also can rate-limit this using either iplimit or limit if you're concerned about this. But note that limiting pings doesn't limit the amount of traffic on your link, just the rate at which you'll respond to this traffic. Anyway, standard ping packets are so small and normally sent only once a second by any given host that they're barely noticeable as traffic.


Some common errors I've seen with iptables scripts include choosing an inappropriate interface for packets. This includes not selecting all interfaces that might be affected. Often lo, the localhost interface, is forgotten about on systems used as both firewall and host (usually a system used in a home). I've also seen outgoing packets using the MANGLE table, the OUTPUT chain or the SNAT target that have -i <interface> rather than -o <interface>.

Sometimes rules get so specific nothing matches them. Try the most general rule you can get away with, adding match extensions only as required. Just be careful where these rules are located in relation to other rules, so they're not picking up packets you don't want them to.

Ensure you're using the right case: ipchains uses lowercase for its built-in chains, but iptables uses uppercase. Targets are also uppercase. Almost everything else is lowercase. If you're using the short options (as I did in this article), the chain action (Insert, Append, Delete, etc.) uses uppercase.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Re: Kernel Korner: A NATural Progression

Anonymous's picture

My copy of Linux Journal had page 21 missing. It had two (2) identical page 20's followed by page 22. Is this a known error in this month's print? [Page 20 - 24 is this Kernel Korner: A NATural Progression article]

Re: Kernel Korner: A NATural Progression

Anonymous's picture

No - it was an error.

Read the next issue's first page of letters/comments/whatever - in the lower-right corner it mentions the double-printing as a mistake...

(too lazy to find the actual page right now... :-P )

Re: Kernel Korner: A NATural Progression

Anonymous's picture

same here. is this an advertising campaign? :) And could I just print a page 21 and add it back to the printed copy?

Re: Kernel Korner: A NATural Progression - MASQUERADE

htmlspinnr's picture

One rule you did not mention which many home users may be interested in is the MASQUERADE rule. This rule comes in handy when you're riding on a dynamic IP connection, but still want to use NAT. MASQUERADE uses the interface IP vs. having to hard code within your tables script (or your iptables-save list).

An example may be:

iptables -t nat -A POSTROUTING -s -o eth0 -j MASQUERADE

Which would masquerade the block as whatever address is assigned to eth0 - be it static or dynamic (though static should stick with SNAT for best results).

I've seen some firewalls use this in static situations as well (Astaro Security Linux 2.x - based on iptables) due to it's simplicity.

Hope this helps.


Re: Kernel Korner: A NATural Progression - MASQUERADE

Anonymous's picture

David's previous NetFilter article covered MASQUERADE, IIRC

Re: Kernel Korner: A NATural Progression - MASQUERADE

Anonymous's picture

This article, a two-part article (of which this month was the second part), was a continuation of a more basic article I wrote and was published in last September's LJ. The basic article (referred back to in this article) discussed MASQUERADE and provided examples and scripts. Please check out September's LJ article on Netfilter/iptables.

David A. Bandel