iptable-restore commands tutorial
 

Where can I find a fully detailed tutorial on all the commands and what they do for the iptable-restore command?

Rather then use iptables directly and blindly inject all sorts of rules into memory, I rather be editing an actual file so I can lay it out with comments etc, then just apply it which clears the rules and adds the new file. The commands unfortunatly are different, so all the iptables tutorials I find don't help me much.

Right now what I'm trying to do is a IP/Port forward but having trouble finding resources on how to do it.

Learning how to write iptables scripts can be really easy if you start with the method you know works best for you. It sounds like you want to get started with a pre-written script. If that's the case, there's tons of iptables scripts right here on LQ and all over the Web. The most respected tutorial AFAICT is Oskar Andreasson's. BTW, I'm moving this to Networking, as it's not a security issue (at least not directly).

The post above details the best tutorial/manual for iptables, but you have asked for info on iptable-restore command. I don't know of a manual, per se, on this command, but all the info you could want on this particular command is contained in the man page (but, be aware that this is not an iptables or firewalling tutorial; it just concerns this one command).

You would also want to read the same info on iptables-save.

...which makes it difficult to know why you are asking iptables-restore, but that's up to you. The conventional way of doing what you are asking (not "blindly inject all sorts of rules into memory", by which I take it that you mean that you don't want to be dynamically adding rules once the firewalling system is running with, eg -A) is to write something in a scripting language (eg, BASH) that will build your desired set of rules. Look at http://www.linuxhomenetworking.com/w...Using_iptables or http://www.chinalinuxpub.com/doc/www...bles-intro.htm for an idea of how to build the shards of a script into the full system. (I think that these are both derived from the 'Linux Quick Fix notebook' by Harrison; in any case that is as clear a general exposition of how to assemble things as I have seen; the Andreasson/Frozentux 'tutorial' is excellent on describing the commands but really doesn't do much in telling you anything about how the general networking infrastructure and you firewall should mesh together, of the best way of building from the commands.)

You could do something other than build up your rules from a bash-shell script, but I don't see why you would; bash gives you all that ability to do math on network addresses that you might need and the selection or deselection of options.

You could argue for a different scripting language (say, python) but it would be an odd situation in which there is any real, definable, advantage except perhaps in readability. And, if you comment the bash script adequately, it is hard to see this advantage as decisive (but do bear in mind that this is a classic example of a situation in which you can't have over-adequate coments; it is difficult to underestimate the degree to which stuff that was to the front of your mind when writing the ruleset can have 'evaporated' by the time that you modify them six months later to make a trivial change...and bear in mind the old saw 'a trivial change is one than needs no testing before bringing down the entire system').

And if you are using a scripting language to build your ruleset, the only advantages that I see for the use of iptables-save and iptables-restore are if you want to preserve packet counts across reboots (I'm not saying that this is irrelevant in your situation, just that you haven't said anything to make it seem that this is something that you are thinking about doing...although the logic of this situation is then that you wouldn't be using iptables-restore, unless you need the packet counts).

Sorry, that didn't help me much to understand what you meant (the commands are all different from what? From each other? From some other language? Between the different examples that you have seen?).

Have a look at the example scripts, which won't be exactly what you want, but try to understand the principles. Then ask 'do I need to do this'? So, if, for you NTP isn't an issue, you can ignore that part, assuming that the policy blocks off the appropriate port as a default. Etc, etc, through the services that you may or may not be allowing through or blocking in your situation (dns, http/caching, https, nfs, samba come immediately to mind, but you may have other particular requirements and always remember that the detail is dependant on the physical network set up, so to just 'cut and paste without thought' is not appropriate).

I decided to just switch my method and use a bash script instead. Will probably be easier to do in the long run especially if I want to call up external scripts/programs. I've been doing some testing now to ensure it works properly. the flush command just scares me as if I'm doing that remotely over SSH and for some reason the script does not fully execute it could lock me out. Guess I just have to be careful.

One big potential problem with doing a flush (while working remotely) is that you forget you had your policy set to DROP, thereby locking you out. The simplest way I've found to deal with that is to use a "catch all" DROP rule at the end of the chain and leave the policy set to ACCEPT. IIRC this is (or at least used to be) the default approach used by Red Hat-based distros. You could also do stuff like issue a timed shutdown command whenever you are working with dangerous iptables commands, so as that if you lock yourself out the machine will reboot after X amount of time (and load with the default ruleset). Or you could make it so that the default ruleset is loaded, instead of the reboot. The point being, there's several things you can do which will help reduce the possibility of a lock out scenario.

OK, that would scare me too, particularly if the machine I was doing it to was located in a different time zone.

A thoughtful/scared/paranoid person could put some hooks into the generating script that relied on, say, you being able to ssh back in within, say, ten minutes to set a flag file after a change and if that didn't occur put back a known-safe, lowest common denominator, set of rules.

Whether you are that person I cannot say. Of course, you could get equally scared testing out such a system, unless you could test it locally...

This makes the whole system more complex and complexity isn't exactly the friend of security, so if you do it that way I would have to advise you to be careful.

Been playing around and it seems good, as long as I make sure that my ssh port rule is ok. If one rule fails the script still runs as it's just a bash script.

Also I wish I had thought of this before, but all I really need to do is make a bash script like this:

sleep 30; service iptables stop

And call it up with &, then apply my changes. In fact I should just add that to my rules file and have a --production flag that makes it not call that up. That way it's set and forget.

Reason I thought of that is because I just recently locked myself out while checking something, and had to get the data center to open up the firewall. :p

I should be doing this on a test box anyway lol.

Yeah, lock outs are a pain. Been there, done that. :)

I recommend you have it fall back to a known good set of rules instead of stopping the firewall, though.