IP Tables

[mcvickj]

I work for a library system that offers free wireless access to our patrons. The first time they make a http request we transparently proxy them to a page that has some information about the rules and policies. When the patron clicks accept we poke a hole in our firewall and they continue to the requested page.

#!/usr/bin/perl

my $rule = @ARGV[0];
my $ip = @ARGV[1];

if ($ip) {
open (RULE,"|-") or exec '/sbin/iptables', '-I', 'FORWARD', $rule, '-s', $ip, '-d', '0/0', '-j', 'ACCEPT';
close RULE;
open (RULE,"|-") or exec '/sbin/iptables', '-I', 'FORWARD', $rule, '-s', '0/0', '-d', $ip, '-j', 'ACCEPT';
close RULE;
}else{
open (RULE,"|-") or exec '/sbin/iptables', '-D', 'FORWARD', $rule;
close RULE;
}

I am working on converting our firewall rules from ipfw to iptables. What we do is grab the last octet of the IP address for $rule and the users IP address for $ip. My problem is that when I try run this I see "iptables: Index of insertion too big" in my Apache error log.

From what I have found so far iptables likes to insert the rules in order. Is it possible to get around this?

 

[Fallen Kell]

The order of the rules is important as the order inserted is the order of priority of the rules. In other words rule number 1 happens first before rule number 2 occurs. So if your rule 1 does something like forward all incoming TCP packets to a specific IP address, and rule 2 is to forward all incoming TCP packets from port 4000 to different specific IP address, well, rule 2 will never happen, because rule one trumps it. You need to specify the rule number when you add the rule:

iptables -I FORWARD 3 -p tcp --dport 36745 --tcp-flags RST RST -j DROP;

For instance, the above will place this as the 3rd FORWARD rule, and will drop incoming RST packets on port 36745.

What you need to do is find out where you first need to have new rules added to a base/clean firewall, and then add that number into your script so that all the new rules will be inserted at the same place. The reason you are getting the "iptables: Index of insertion too big" is because the "-l" option expects to see a rule number, which you are not giving it, and it is instead using "$rule" which is a number that is the last octet of the IP address, which is a number much larger than the number of rules in the existing chain, hence, the "index (rule number) is too big (because I only have 3-5 rules already and you are trying to insert rule as rule number 253...)"

Now I can understand why you want to number the rule based on the octet, but that just will not work in iptables. You will need to do a little more work in your perl script to delete rules for a particular host by querying the current rule-set, and do pattern matching to find the particular rule number that you want to delete.

 

[QuixoticOne]

I've written systems like this a few times.
It's about dinner time, so I won't dig around for my old scripts or go into a ton of detail at the moment.
The previous response contained some helpful information.
Also you can 'cheat' to an extent and load / restore the whole table rule set efficiently from a text file at once with
iptables-save
iptables-restore
...hack the text file and away you go.

Also look at things like ipset to help manage your address lists:
http://ipset.netfilter.org/

One other way to do it is to SET A MARK for packets that match some filtering criteria and then later in a different part of the filtering process check the marked packets and treat them differently. There are some cases where you have to do it this way because the mark is the best / only information you can use to communicate classification information between two layers in the filtering process.

This should basically tell you everything you really need to know.

IMHO it is a misguided system to try to 'capture' web traffic, though. There are plenty of things that use HTTP or other internet protocols that will break badly if you intercept them and start blocking or spewing unexpected data at them. e.g. an anti-virus program that issues a HTTP GET command to retrieve an updated virus definition file and all of a sudden it gets some unrecognizable garbage (your EULA) from supposedly the site that it was trying to reach... not good.

If anyone has a brain they'll also be trying to use a VPN or HTTPS or something like that to connect through a public / wireless network away from their secure home / office network. You can't intercept that and they'll be annoyed / confused when they can't connect.

Just post a sign at the door "USE OF OUR COMPUTER NETWORKS IS ONLY BE AUTHORIZED IF YOU AGREE TO OUR T&Cs; ALL OTHER USE IS UNAUTHORIZED for more information see: http://....." and leave it at that. It is good enough for such a disclaimer in plenty of other circumstances like the release of liability when you park at a public parking lot or whatever..... The silly EULA thing is really purposeless -- if someone is hacking / using your networks in an illegal / unauthorized manner, there are laws against that that you can rely upon if needed or you can just blacklist the MACs / IPs / users as you would do with any internet hacker or customer that does something you dislike. If they behave then there is no problem....

I recall being UNABLE to access a few "public" wireless hotspots due to their bad configuration not working with my own PC's security / browser configuration. PITA.