Greetings all.

This is a weird problem, which is only occurring on my Redhat 7.3 version of iptables. I think I have everything in the correct order here, but as you’ll see, as soon as I add a CIDR to block, then select “save active’, I check the rules, only to see that iptables has rearranged them all. Somehow, this doesn’t look right.

Overall objectives with this firewall:

- To block all nonessential ports and open only the ones I need
- To block all UDP and TCP traffic not destine for a legit port
- To make sure no spoofing using reserved IP ranges are accepted
- To block Spam Bags and their associated IP ranges


Here’s the "orginal" order I put them in:

# Generated by iptables-save v1.2.8 on Sat Jun 12 20:10:29 2004
*nat
:PREROUTING ACCEPT [138:9258]
:POSTROUTING ACCEPT [12:2346]
:OUTPUT ACCEPT [12:2346]
-A PREROUTING -s 192.168.0.0/255.255.0.0 -i ppp+ -j DROP
-A PREROUTING -s 172.16.0.0/255.240.0.0 -i ppp+ -j DROP
-A PREROUTING -s 10.0.0.0/255.0.0.0 -i ppp+ -j DROP
COMMIT
# Completed on Sat Jun 12 20:10:29 2004
# Generated by iptables-save v1.2.8 on Sat Jun 12 20:10:29 2004
*mangle
:PREROUTING ACCEPT [918:87195]
:INPUT ACCEPT [918:87195]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1041:674862]
:POSTROUTING ACCEPT [1041:674862]
COMMIT
# Completed on Sat Jun 12 20:10:29 2004
# Generated by iptables-save v1.2.8 on Sat Jun 12 20:10:29 2004
*filter
:INPUT DROP [26:3698]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1005:670279]
:LOG_DROP - [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp ! --tcp-option 2 -j REJECT --reject-with tcp-reset
-A INPUT -i eth0 -p tcp -m tcp --dport 25 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 110 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -s 192.168.1.0/255.255.255.0 -p tcp -m tcp --dport 10021 -j ACCEPT
-A INPUT -s 192.168.1.0/255.255.255.0 -p tcp -m tcp --dport 10022 -j ACCEPT
-A INPUT -s 192.168.1.0/255.255.255.0 -p tcp -m tcp --dport 10030 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A LOG_DROP -j LOG --log-prefix "[IPTABLES DROP] : " --log-tcp-options --log-ip-options
-A LOG_DROP -j DROP
COMMIT
# Completed on Sat Jun 12 20:10:29 2004



Here’s what happens "after" I add a IP Range to block Spammy:


# Generated by iptables-save v1.2.8 on Wed Jun 16 20:29:30 2004
*filter
:INPUT DROP [1:242]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [22:3504]
:LOG_DROP - [0:0]
-A INPUT -s 67.82.0.0/255.255.255.0 -j LOG_DROP
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp ! --tcp-option 2 -j REJECT --reject-with tcp-reset
-A INPUT -i eth0 -p tcp -m tcp --dport 25 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 110 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -s 192.168.1.0/255.255.255.0 -p tcp -m tcp --dport 10021 -j ACCEPT
-A INPUT -s 192.168.1.0/255.255.255.0 -p tcp -m tcp --dport 10022 -j ACCEPT
-A INPUT -s 192.168.1.0/255.255.255.0 -p tcp -m tcp --dport 10030 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A LOG_DROP -j LOG --log-prefix "[IPTABLES DROP] : " --log-tcp-options --log-ip-options
-A LOG_DROP -j DROP
COMMIT
# Completed on Wed Jun 16 20:29:30 2004
# Generated by iptables-save v1.2.8 on Wed Jun 16 20:29:30 2004
*mangle
:PREROUTING ACCEPT [33:2140]
:INPUT ACCEPT [33:2140]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [22:3504]
:POSTROUTING ACCEPT [22:3504]
COMMIT
# Completed on Wed Jun 16 20:29:30 2004
# Generated by iptables-save v1.2.8 on Wed Jun 16 20:29:30 2004
*nat
:PREROUTING ACCEPT [2:290]
:POSTROUTING ACCEPT [1:104]
:OUTPUT ACCEPT [1:104]
-A PREROUTING -s 192.168.0.0/255.255.0.0 -i ppp+ -j DROP
-A PREROUTING -s 172.16.0.0/255.240.0.0 -i ppp+ -j DROP
-A PREROUTING -s 10.0.0.0/255.0.0.0 -i ppp+ -j DROP
COMMIT
# Completed on Wed Jun 16 20:29:30 2004

Urr.. What happened here? Everythings been totally rearranged. My -A PREROUTING -s 192.168.0.0/255.255.0.0 -i ppp+ -j DROP is now sitting at the bottom.

Funny, I have two Redhat 9.0 boxes, and this problem does not exist. You can add ip’s to be blocked, and it never changes the order of the rules. It seems to be a 7.3 thing. Anyway… Is this what iptables is supposed to do, and will it still yield the results I want? I don’t want to end up hacked.

Problem 2: -A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT

This must stay "ABOVE" the blocked ip addresses. If not, iptables cannot lookup a CIDR, as the responce is blocked. Why? I suspect because unless -A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT is above the *blocked ip's*, then iptables looks at the responce from Spammy's server as a new *unestablished* inbound request, and blocks it. This creates a HUGE mess of my logs, as it continues to try and get a response *indefinitely*

I can place -A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT at the top, just below LOG_DROP, but as soon as I add another ip to block, it bumps it back down so that it's *under* the blocked IP's again. How do you get it to stay at the *top* of the blocked IP list?

Hey... It all works correctly, but the question is... Is it actually protecting anything?

Appreciate any responses,

Dave H

Greetings all.
Howdy.

Urr.. What happened here? Everythings been totally rearranged. My -A PREROUTING -s 192.168.0.0/255.255.0.0 -i ppp+ -j DROP is now sitting at the bottom.
The only thing that looks different is the rule you added and the fact that the tables themselves are re-ordered. The rules in each table (filter, nat, and mangle tables) appear to be in the same order. As long as the rules in each table are in the same order, it shouldn't affect anything. I have no idea why RH 7.3 rearranges the order of the 3 tables, but it shouldn't matter.

Problem 2: <SNIP> I can place -A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT at the top, just below LOG_DROP, but as soon as I add another ip to block, it bumps it back down so that it's *under* the blocked IP's again. How do you get it to stay at the *top* of the blocked IP list?
Use iptables -I INPUT..... instead. This will Insert the rule at the top of the ruleset, instead of Appending it to the bottom of the chain. Keep in mind that it can still appear anywhere in the ruleset, but as long as you use -I it will be inserted at the top of the actual firewall.

Hey... It all works correctly, but the question is... Is it actually protecting anything?
Once you get your firewall how you "think" it should work, you should always audit your firewall using port scans and vuln. checkers like nessus (from outside the box). When you finish those benchmarks, then you'll have a reasonably good idea of how well it's works in practice.

Thanks, Capt_Caveman.

So essentially, how the rules are ordered at current do not pose any security risks? It’s that -A PREROUTING -s 192.168.0.0/255.255.0.0 -i ppp+ -j DROP now sitting at the bottom that bothers me. If someone spoofed packets in the 192.168.0.0 range, it looks like the above rule: -A INPUT -s 192.168.1.0/255.255.255.0 -p tcp -m tcp --dport 10021 -j ACCEPT would catch it first. Nah... That can't be right

I suppose I’m somewhat confused. The order of the rules matters, but the “order of the tables” does not, correct? In this case, A PREROUTING -s 192.168.0.0/255.255.0.0 -i ppp+ -j DROP ending up at the bottom matters not –it’s processed in the same way it would be at the top. I’d like to trust that iptables re-orders the tables for its own reasons, and that I can trust those reasons

As for the A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT thing, your suggestion does push it back up to the top. The problem however, is that as soon as I add another IP block, it ends up “on top” of this rule. As a result, I have to keep editing the iptables file manually, and placing A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT back on top of the blocked ip’s.

It’s that log_drop thing. I can’t place that snippet; the blocked IP’s, and the -A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT in a section of their own (at the top of the file). -A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT insists on existing with all the other –A input statements as a group. I don’t think you can have two separate groups of these. If you try, iptables will keep placing them back in the same order. Oh well. Not the end of the world, but it would be nice to get it working correctly.


Thanks again,

Dave H

I suppose I’m somewhat confused. The order of the rules matters, but the “order of the tables” does not, correct?
Correct. If you look closely at that file, you'll see that it is actually subdivided into tables like this:
So if we switched around the filter table section and the NAT section, it won't affect how the firewall functions (the filter rules will still get loaded into the filter table and the NAT rules will still go into the NAT table. The three tables are independent of each other (at least in this context). However, if you switch the position of rules within a table it will make a difference. Looking at the output of iptables -L -v and iptables -t nat -L -v is probably a more accurate way of observing the layout of the rules (it shows you how the rules appear in the firewll itself).



As for the A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT thing, your suggestion does push it back up to the top. The problem however, is that as soon as I add another IP block, it ends up “on top” of this rule.
The file you're looking at is actually just a listing of the rules as you've entered them, which is not necessarily the same order as how they are goingto be placed into the firewall. If you read from top to bottom in a table, each rule that uses -A is appended to the bottom of the rules (so in the firewall, they will be in the same order). However, rules that are entered with the -I option are inserted into the top of the chain and will therefore be the very first rules in that chain unless another rule with -I follows. Take a look at iptables -L -v and you'll see what I mean. As an illustration:
It’s that log_drop thing. I can’t place that snippet; the blocked IP’s, and the -A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT in a section of their own (at the top of the file). -A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT insists on existing with all the other –A input statements as a group. I don’t think you can have two separate groups of these. If you try, iptables will keep placing them back in the same order. Oh well. Not the end of the world, but it would be nice to get it working correctly.
Not sure what you mean here.

Capt_Caveman,

Your detailed response was both insightful and appreciated. I now understand the hierarchy and how the list is processed –at least I think.

As for the -A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT thing, the problem is this: In order for iptables to lookup a “blocked” address, it does this by making a call, then waiting for a response. When the “blocked” server responds, here’s the problem….

The response is blocked, as it’s being caught by the CIDR entry first. In this case, iptables continues to attempt a lookup several times over, as thinks it’s not receiving a response. In actuality it “is”, but the response is blocked. Awe heck… Here’s an example:

This is where A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT *MUST* stay:


# Generated by iptables-save v1.2.7a on Thu Jun 17 12:44:08 2004
*mangle
:PREROUTING ACCEPT [6826:629420]
:INPUT ACCEPT [6826:629420]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [5514:2557614]
:POSTROUTING ACCEPT [5514:2557614]
COMMIT
# Completed on Thu Jun 17 12:44:08 2004
# Generated by iptables-save v1.2.7a on Thu Jun 17 12:44:08 2004
*nat
:PREROUTING ACCEPT [2704:324347]
:POSTROUTING ACCEPT [77:5840]
:OUTPUT ACCEPT [76:5800]
[0:0] -A PREROUTING -s 192.168.0.0/255.255.0.0 -i ppp+ -j DROP
[0:0] -A PREROUTING -s 172.16.0.0/255.240.0.0 -i ppp+ -j DROP
[0:0] -A PREROUTING -s 10.0.0.0/255.0.0.0 -i ppp+ -j DROP
COMMIT
# Completed on Thu Jun 17 12:44:08 2004
# Generated by iptables-save v1.2.7a on Thu Jun 17 12:44:08 2004
*filter
:INPUT DROP [1943:286427]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [5324:2533891]
:SPAM_BAG - [0:0]
:badflags - [0:0]
[2016:124695] -A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
[0:0] -A INPUT -s 221.0.0.0/255.255.0.0 -j SPAM_BAG
[0:0] -A INPUT -s 61.0.0.0/255.255.0.0 -j SPAM_BAG
[0:0] -A INPUT -s 61.252.192.0/255.255.224.0 -j SPAM_BAG
[0:0] -A INPUT -s 67.82.0.0/255.255.255.0 -j SPAM_BAG
[0:0] -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j badflags
[0:0] -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j badflags
[0:0] -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,ACK,URG -j badflags
[0:0] -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j badflags
[0:0] -A INPUT -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j badflags
[0:0] -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j badflags
[44:5543] -A INPUT -i lo -j ACCEPT
[0:0] -A INPUT -p tcp -m tcp ! --tcp-option 2 -j REJECT --reject-with tcp-reset
[127:7080] -A INPUT -i eth0 -p tcp -m tcp --dport 25 -j ACCEPT
[0:0] -A INPUT -i eth0 -p tcp -m tcp --dport 110 -j ACCEPT
[317:15216] -A INPUT -i eth0 -p tcp -m tcp --dport 8086 -j ACCEPT
[6:288] -A INPUT -s 192.168.1.0/255.255.255.0 -p tcp -m tcp --dport 21 -j ACCEPT
[18:864] -A INPUT -s 192.168.1.0/255.255.255.0 -p tcp -m tcp --dport 10022 -j ACCEPT
[659:31632] -A INPUT -s 192.168.1.0/255.255.255.0 -p tcp -m tcp --dport 10030 -j ACCEPT
[44:5543] -A OUTPUT -o lo -j ACCEPT
[10:776] -A SPAM_BAG -j LOG --log-prefix "[IPTABLES DROP] : " --log-tcp-options --log-ip-options
[10:776] -A SPAM_BAG -j DROP
[0:0] -A badflags -j LOG --log-prefix "[IPTABLES DROP] : " --log-tcp-options --log-ip-options
[0:0] -A badflags -j DROP
COMMIT
# Completed on Thu Jun 17 12:44:08 2004


The only way to receive the response from a lookup on a Spam block, is to make sure iptables sees this as an “established” connection. If it sees the response from the Spam IP as a new connection, then obviously it’ll block it.

Now, I understand what you’re saying about the –I statement, in that it will remain at the top, and despite the priority listed in the iptables file. The problem is, when I add a new Spam block IP, these rules insist at loading at the top, thus pushing -A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT down a position every time.

Any Spam IP above this statement will hinder iptables ability to look it up, which it insists on doing when running the status command, and a few others. Ok.. I’ve just babbled into oblivion here. Even if you can’t suggest a fix, please tell me you can at least understand the nature of my problem. I’d hate to think I’m still coming across as ambiguous about what I’m trying to fix here.

In short, I must be careful not to block the very lookups that iptables needs to perform for itself. Am I making any sence, or do I have something horribly confused here. I just know that placing the blocked ip's below that statement will cause iptables to choke upon trying to look it up, as well as HUGE server logs of multiple attempts, which say LOG DROPPED! HAHA... At first I thought this was a major attack on my network, but as it turns out, it was me that was causing it Sort of like a mail-loop in procmail where the system keeps feeding back to itself.

Much thanks again,

Dave H

The only way to receive the response from a lookup on a Spam block, is to make sure iptables sees this as an “established” connection.
Ok. So the established,related rule must be at the top of the rule set. If you add the rule like this:

iptables -I INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT

it will always be at the top of the firewall (not the iptables file). So lets walk through this. I'll load real rules into iptables and show you the output of iptables -L each time. Keep in mind that iptables -L shows you the real order of the rules as they are in the firewall, which is not the same thing as the /etc/sysconfig/iptables file you are looking at.

Ok, now we have one measly rule in the firewall, lets add another with -A again:

So, using -A loaded the rule onto the bottom of the table. Not that groundbreaking. Let's add your rule now, but this time use -I:

If you look at where the rule went, you'll see it got added to the top of the table, unlike the last two rules we added which went to the bottom. So now lets add a rule to block some spam IP, but because we don't want to move the ESTABLISHED,RELATED rule we'll use -A from now on:

So our spam blocking rule is placed at the bottom of the firewall and didn't displace our ESTABLISHED,RELATED rule from the top of the table. So any replies from IPs in the Spam block will match the ESTABLISHED,RELATED rule and will be allowed through. Just to make sure, we can add another:

So we're still good. If you were to add another -I rule, it would be added to the top of the table and move the ESTABLISHED,RELATED rule down one. Hopefully that is more clear now. Remember that the /etc/sysconfig/iptables file that you posted before simply lists the rules as you entered them, not how they will be loaded into the actual firewall.

You might find working with an actual shell script to be alot easier (and logical). Just take the rules as you would like them to appear and put them in a text file. For the rules we added above, we could do some thing like this:

With a firewall script like this, the rules will be loaded in the same order as you put them into the script. Then if you need to add a rule somewhere, you can just edit the file and insert the rule. Then just re-run the script and your rules will be in the proper order. You will need to make the script executable (chmod u+x <filename>) and then either make sure it's run at boot or load the rules once and save them with the iptables-save command. It does make manipulating your firewall significantly easier.

Yes indeed, you’re correct. I’ve added a few additional IP blocks since doing that, and of course, when you look at the iptables file, these blocks are appearing ‘above’ the ESTABLISHED,RELATED rule. To test this, I ran the ‘status’ command, which causes a lookup on all CIDR entries. It works! Normally, the blocks above the ESTABLISHED,RELATED rule would cause iptables to choke, but it flew through all of them without a problem

As for the shell script, I’m still a little foggy on where to place it, and how to execute it at start. Funny huh, I’ve looked at almost 70 pre-made firewalls all over the web, yet not one of the makes mention of where to place the script, or how to execute it at bootup. Oh well.

You know what I’d like to do though, is use an “include” file for my HUGE list of blocked ip’s. This would keep from cluttering the main iptables file. I’m not obligating you here, but if you have a simple example of how to add an include to iptables, and how you’d send the IP’s to this include at the shell command, I’d be forever grateful. If not, an extended thanks once again for all the help you’ve provided me.

Dave H

The actual location of the script doesn't really matter, but there are two main ways to get it to run at boot. You can either place it in one of the init scripts, the only caveat being that it should be run before the network interfaces are brought up. That way you aren't sitting around with your networking on with no firewall. In redhat, you can modify the /etc/init.d/iptables file and have it load your firewall script instead. The second method being that you can put:
/sbin/iptables-save > /etc/sysconfig/iptables
at the bottom of the firewall script. Then when the script is run it should save the firewall rules to the iptables file and will be automagically reloaded once you reboot. In other distros it will go elsewhere, often /etc/rc.firewall.

Depending on the size of the block list, I've seen these implemented two ways. If the list is reasonably small, you can put a list of IP addresses in a file and then just introduce a loop structure into your firewall shell script, which just iterates through the list of IPs. Something like this usually will do the trick:
If your blocklist is really big, then you have to do it a little differently. Iptables works by taking an incoming packet and trying to match it to each rule in the firewall chains (INPUT,OUTPUT,FORWARD,etc are all known as "chains"). So with a few rules, the you are only adding a few microseconds per rule which isn't a big deal. Now with several thousand rules, that can really add up and iptables will actually slow down your networking. So to get around that you have to break it up into smaller files organized into IP address blocks. Then create several user-defined chains like ipchains -N IPBLOCK0 and then have it match all IP addresses from the 0.0.0.0 to 10.0.0.0 class A networks. Then add your loop structure and have it load rules to filter bad IPs in that IP range. You then repeat the process for the 11.0.0.0 to 20.0.0.0 ...etc...you get the idea. The key point being that iptables won't have to sort through 10,000 rules for each incoming packet.

/OT NOTE: This is one case where the BSD PF firewall is bad-arsed because it can do smart filtering and ignore rules that can't possibly match the packet. That is cool and Netfilter needs this.

Many thanks.

I’ve been playing around with this, but don’t know where to place the following statement in my iptables file:

BLOCKLIST=/etc/sysconfig/BLOCKLIST
for i in `cat $BLOCKLIST`

Forgive my ignorance, but do you simply place this above statement into your iptables file? I’ve tried several variations, but all I get is a ‘Bad argument `BLOCKLIST=/etc/sysconfig/BLOCKLIST' message. Maybe this example was meant for a shell script type of iptables file? I don’t have one made up yet. Is it possible to use this in the default iptables file?

To add blocked IP’s to this file, you’d use ‘iptables -A INPUT -s $i -j DROP’, which should send them to BLOCKLIST, correct?

As for organizing blocked IP ranges, man… That looks like a brutal task. Thank God all I have is a little over a hundred blocks. Looks like netfilter was never really setup to manage large amounts of blocking, unlike BSD that seems to use a little logic behind its management

Dave

but do you simply place this above statement into your iptables file?
If your going to use the loop to load the block list, the easiest way to do it would be to use a shell script. Putting it into the iptables file will definitely not work, in fact you should never directly edit the iptables file at all.

The loop I posted above will read a line (an IP address) from the blocklist file and add an iptables rule to block that IP. It will continue to do so until it reaches the end of the file.

netfilter was never really setup to manage large amounts of blocking, unlike BSD that seems to use a little logic behind its management
They both have there pros and cons, you just have to go with the one that best suits your individual needs. If you use a bunch of user-defined chains to break the blocklist into sections, it's really just alot of cut-and-paste if you use a script. Once you start getting into more advanced firewall stuff, I'd really recommend creating a script, otherwise it gets to be a bit un-manageable.

Alright, I’ll start building a shell script.

One last question: I have a cgi script, which catches rogue accesses through http, and then dumps them into my iptables file –works VERY well, and is also awesome for snagging robots that ignore the robots.txt file, and parse the site looking for email addresses. As typical, I cannot get the dam script to fire up in init.d.

I’ve tried every variation from init.d templates, yet all it does is start, and then hang –it won’t return a “started OK” message. Actually, I can leave it running in the shell, but that’s sort of lame.

I’ve searched the web extensively, yet cannot fined a whole lot on how to create a simple init.d script that fires up a cgi script at start. Do you know of any other examples/templates that exist? By all means, if you have one handy, feel free to paste it here. If not, don’t worry about it, as you've certainly done enough.

Again, I really appreciate the time you’ve invested into this posting.

Thanks,

Dave H

Actually I either just put a link to the script in /etc/rc.local or if I'm feeling motivated I'll use an existing init script and hack it as per my requirements. You might want to post a new question in the Linux - General forum though.