Being bored at the end of the holidays I am foolishly attempting to understand how to setup iptables. I did a "yum install firestarter" and tried it. The GUI it has may be slightly less cryptic that the low level iptables config files, but not much, and just about the time I'm able to think I may have it figured out, it aborts on me :-). Any other less cryptic GUI options (I know about system-config-firewall, but it is way too simplistic to let me setup the rules I want).
On Sun, 2008-11-30 at 11:49 -0500, Tom Horsley wrote:
Any other less cryptic GUI options
I suppose that depends on what you mean by cryptic. Is it the syntax of the commands that you don't understand, or the functions that a rule needs?
I used to set mine using a script, with a pile of iptables commands. That made it easy to repeat (run the script again), easy to undo changes (you can comment out things, and try variations), and much more flexible than anybody's control GUI. I'd run the script to change or apply the settings. It saved them in the place iptables loads its initial settings, so the computer would always boot up with my configuration, without me needing to modify anything.
Something like the following example (which dates back to when I used dialup). I always used the expanded, rather than abbreviated, commands; it's easier to interpret.
#!/bin/bash
## Turn off IP forwarding while altering configuration: ## (Put it back on again, at end, if needed.)
echo 0 > /proc/sys/net/ipv4/ip_forward
## Flush any pre-existing rules:
iptables --flush INPUT iptables --flush OUTPUT iptables --flush FORWARD
iptables --flush iptables --table nat --flush
iptables --delete-chain iptables --table nat --delete-chain
## Set default (policy) rules:
iptables --policy INPUT DROP iptables --policy OUTPUT ACCEPT iptables --policy FORWARD ACCEPT
## Drop non-internet networking addresses on the internet connection:
iptables --append INPUT --jump DROP --in-interface ppp+ --source 192.168.0.0/16 iptables --append INPUT --jump DROP --in-interface ppp+ --source 172.16.0.0/12 iptables --append INPUT --jump DROP --in-interface ppp+ --source 10.0.0.0/8 iptables --append INPUT --jump DROP --in-interface ppp+ --source 127.0.0.0/8 iptables --append INPUT --jump DROP --in-interface ppp+ --source 169.254.0.0/16 iptables --append INPUT --jump DROP --in-interface ppp+ --source 192.0.2.0/24 iptables --append INPUT --jump DROP --in-interface ppp+ --source 204.152.64.0/23 iptables --append INPUT --jump DROP --in-interface ppp+ --source 224.0.0.0/3
## Accept some things:
iptables --append INPUT --jump ACCEPT --protocol tcp --destination-port 80 iptables --append INPUT --jump ACCEPT --protocol tcp --destination-port https
## Allow established and related outside commications to this system, ## and allow outside communications to the firewall, except for ICMP packets: ## (Could be tightened up, adding conditions about specific ports.)
iptables --append INPUT --match state --state ESTABLISHED,RELATED --in-interface ppp+ --protocol ! icmp --jump ACCEPT
## Prevent connections initiated from the outside world: ## (Can interfere with some services which connect back, later on, such as file transfers or webcams on IM programs.)
iptables --append INPUT --match state --state NEW --in-interface ppp+ --jump DROP
## Allow all local communications to and from the firewall on ETH from the local network:
iptables --append INPUT --jump ACCEPT --protocol all --in-interface eth+ --source 192.168.0.0/16
## Internet connection sharing: ## Set up masquerading to allow internal machines access to outside network: #iptables --table nat --append POSTROUTING --out-interface ppp+ --jump MASQUERADE
## Turn on IP forwarding, only needed for above internet connection sharing rule: #echo 1 > /proc/sys/net/ipv4/ip_forward
## Save iptables rules to the default iptables rules file (used at boot-up): ## (Red Hat's own /etc/init.d/iptables script looks here.)
iptables-save > /etc/sysconfig/iptables
Tim wrote:
On Sun, 2008-11-30 at 11:49 -0500, Tom Horsley wrote:
Any other less cryptic GUI options
I suppose that depends on what you mean by cryptic. Is it the syntax of the commands that you don't understand, or the functions that a rule needs?
I used to set mine using a script, with a pile of iptables commands. That made it easy to repeat (run the script again), easy to undo changes (you can comment out things, and try variations), and much more flexible than anybody's control GUI. I'd run the script to change or apply the settings. It saved them in the place iptables loads its initial settings, so the computer would always boot up with my configuration, without me needing to modify anything.
Something like the following example (which dates back to when I used dialup). I always used the expanded, rather than abbreviated, commands; it's easier to interpret.
#!/bin/bash
## Turn off IP forwarding while altering configuration: ## (Put it back on again, at end, if needed.)
echo 0 > /proc/sys/net/ipv4/ip_forward
## Flush any pre-existing rules:
iptables --flush INPUT iptables --flush OUTPUT iptables --flush FORWARD
iptables --flush iptables --table nat --flush
iptables --delete-chain iptables --table nat --delete-chain
## Set default (policy) rules:
iptables --policy INPUT DROP iptables --policy OUTPUT ACCEPT iptables --policy FORWARD ACCEPT
## Drop non-internet networking addresses on the internet connection:
iptables --append INPUT --jump DROP --in-interface ppp+ --source 192.168.0.0/16 iptables --append INPUT --jump DROP --in-interface ppp+ --source 172.16.0.0/12 iptables --append INPUT --jump DROP --in-interface ppp+ --source 10.0.0.0/8 iptables --append INPUT --jump DROP --in-interface ppp+ --source 127.0.0.0/8 iptables --append INPUT --jump DROP --in-interface ppp+ --source 169.254.0.0/16 iptables --append INPUT --jump DROP --in-interface ppp+ --source 192.0.2.0/24 iptables --append INPUT --jump DROP --in-interface ppp+ --source 204.152.64.0/23 iptables --append INPUT --jump DROP --in-interface ppp+ --source 224.0.0.0/3
## Accept some things:
iptables --append INPUT --jump ACCEPT --protocol tcp --destination-port 80 iptables --append INPUT --jump ACCEPT --protocol tcp --destination-port https
## Allow established and related outside commications to this system, ## and allow outside communications to the firewall, except for ICMP packets: ## (Could be tightened up, adding conditions about specific ports.)
iptables --append INPUT --match state --state ESTABLISHED,RELATED --in-interface ppp+ --protocol ! icmp --jump ACCEPT
## Prevent connections initiated from the outside world: ## (Can interfere with some services which connect back, later on, such as file transfers or webcams on IM programs.)
iptables --append INPUT --match state --state NEW --in-interface ppp+ --jump DROP
## Allow all local communications to and from the firewall on ETH from the local network:
iptables --append INPUT --jump ACCEPT --protocol all --in-interface eth+ --source 192.168.0.0/16
I usually just accept all the ESTABLISHED connections, and put that rule 1st or very high in the ruleset, to avoid going through lots of rules when most packets are for running TCP.
Do you have any ESTABLISHED that you wouldn't ACCEPT? I just take them all.
## Internet connection sharing: ## Set up masquerading to allow internal machines access to outside network: #iptables --table nat --append POSTROUTING --out-interface ppp+ --jump MASQUERADE
## Turn on IP forwarding, only needed for above internet connection sharing rule: #echo 1 > /proc/sys/net/ipv4/ip_forward
## Save iptables rules to the default iptables rules file (used at boot-up): ## (Red Hat's own /etc/init.d/iptables script looks here.)
iptables-save > /etc/sysconfig/iptables
Someone posted here that service iptables save was a better way to do that, in case that name ever changes. I mention that just out of completeness, not conviction. ;-)
I suppose that depends on what you mean by cryptic. Is it the syntax of the commands that you don't understand, or the functions that a rule needs?
Actually, the most cryptic thing isn't any individual command (though they can certainly be cryptic too), it is the need to actually understand the obscure inner workings of internet protocols to realize there are rules you need beyond the obvious.
Anyway, I think I came up with something that works by using system-config-firewall to build some rules that do part of what I want, then modifying those rule to add the more obscure packet filtering the gui doesn't really directly support.
On Mon, 2008-12-01 at 19:16 -0500, Tom Horsley wrote:
Actually, the most cryptic thing isn't any individual command (though they can certainly be cryptic too), it is the need to actually understand the obscure inner workings of internet protocols to realize there are rules you need beyond the obvious.
Ah yes, the fun and games you go through the first time you try to do FTP through a firewall, or get file transfers to work with your instant messaging program, none of which plays nicely with firewalls nor NAT.
On Mon, 2008-12-01 at 17:36 -0500, Bill Davidsen wrote:
Do you have any ESTABLISHED that you wouldn't ACCEPT? I just take them all.
Can't think of any at the moment, though there's some RELATED traffic that I might have trepidations about. I don't know what the rules consider to be related, but I'd be annoyed at something like the following (which does happen).
e.g. You browse to a website, and it connects back to you to look at your identd service (if you have one), regardless of whether you're logging on or browsing anonymously.
I want "related" to mean appropriately related traffic to what I'm doing, not anything back from something that I've made some sort of connection to.
And I can well imagine parents might relent and allow IM chat, but block the ports used for webcams and IM file transferring.
Tim wrote:
On Mon, 2008-12-01 at 17:36 -0500, Bill Davidsen wrote:
Do you have any ESTABLISHED that you wouldn't ACCEPT? I just take them all.
Can't think of any at the moment, though there's some RELATED traffic that I might have trepidations about. I don't know what the rules consider to be related, but I'd be annoyed at something like the following (which does happen).
Yes, RELATED is a different issue, and is not made easier by a lack of documentation and configuration tools. I would love to have an easy to use tool to tune that and save configuration.
e.g. You browse to a website, and it connects back to you to look at your identd service (if you have one), regardless of whether you're logging on or browsing anonymously.
I want "related" to mean appropriately related traffic to what I'm doing, not anything back from something that I've made some sort of connection to.
And I can well imagine parents might relent and allow IM chat, but block the ports used for webcams and IM file transferring.
-
Bill Davidsen -
Tim -
Tom Horsley