I posted a while back notice about a IPTables tutorial series which goes from nothing to EVERYTHING. I had a conversation with old guy back then and as per request I would like to announce the fact that PDF versions of each part and also plain text archives (for easy searching) are available for download and since I plan on writing more of these (I think noone really explains all aspects of IPTables), all further parts will be available as PDF/TXT immediately.
If you want to check the newest part and the others online, I made an index so i don't have to post all the URL's:
formatting link
and if you want to go straight to the PDF/TXT's (this is also where the scripts for PART 4 are located at:
formatting link
I know the txts are far from perfect however I have to mention that English is not my first language, it isn't even my second :)
As usual, comments and constructive criticism are welcome.
Please don't. You already have several really bad mistakes even in your most basic writeup.
| The policies define the default action for the DEFAULT TABLES, INPUT | (traffic COMING TO the machine directly), OUTPUT (traffic COMING FROM | the machine directly) and FORWARD (traffic COMING FROM or GOING TO a | networked machine on the other side of the firewall).
The TABLES in netfilter are "filter", "nat", "mangle", and "raw", and they are specified with the option "-t" (with "filter" being the default table). What you are referring to here are CHAINS. The default chains in the filter table, to be precise.
| The 3 actions you can set in these policies are ACCEPT,DENY and DROP.
netfilter does not have a target DENY (this is something I usually create as a user-defined chain in my iptables scripts to reject traffic rather than silently drop it). Only ACCEPT and DROP are valid targets for policies.
| In case of a web/ftp-server you would make a variable which contains | ports, 20,21,22,80 and 443 and refer to that variable instead of | writing 5 lines.
Whether you put these ports into one rule or five rules doesn't have anything to do with using variables. It just depends on whether you do or don't use the multiport (or mport) module.
Besides, you don't necesserily need SSH for a www/ftp server, and you need to allow port 20/tcp only if you're using active FTP. In which case you need to allow port 21/tcp inbound and port 20/tcp outbound, so you wouldn't put them into a single rule anyway.
| * create the variables first | * set the default policies second | * write your filter tables third | * point your traffic to the tables
WTH do you mean by this? You don't "point" traffic to the tables. If netfilter is compiled into the kernel the traffic is processed through them automatically. You just define rules controlling the flow.
| #/bin/sh | #variables first! | ipt="/sbin/iptables" | std_ports="22,80,443" | lan="10.0.0.0/24,192.168.0.0/24" | any="0.0.0.0/0" | | As you can see in the beginning we start a standard bash script,
This is actually not a bash script, but a (Bourne) shell script. Though /bin/sh is usually a symlink to /bin/bash on current Linux systems, you should *never* assume that this is necessarily so.
| $ipt -F | $ipt -Z | $IPT -x | | This will do 3 things, it will FLUSH (-F) all old IPTable entries, | ZERO (-Z) all standard tables and statistics, and ERASE (-X) all user | created tables.
"iptables -F" will not flush ALL existing rules, but only those in the default table (filter). To flush rules in any other table you need to specify the table with the option "-t". "iptables -Z" will not "zero" any "standard tables", but will reset the counters to zero, and as with "-F" will do this only for the default table unless another table is specified. "iptables -X" will not delete any tables (users cannot create tables in netfilter), but will delete all user-defined chains in the default table.
| you ADD filters to the table with -A.
You APPEND a RULE to a CHAIN with -A. Another way to add a rule would be to INSERT it at some position with -I.
| $ipt -N states | $ipt -A states -m state --state ESTABLISHED,RELATED -j ACCEPT | $ipt -A states -m state --state NEW -s $lan ! -d 192.168.0.250/32 -j ACCEPT | $ipt -A states -j DROP [...] | The third line is just as the second except for a few changes after | the -state. In this case it will accept new (-state NEW ) connection | attempts from (-s) the lans ($lan) that are NOT (!) destined (-d) to | 192.168.0.250 directly.
It is advisable to specify the interface in a rule like that, otherwise an attacker might be able to sneak packets into your LAN by spoofing the source address.
I did not bother reading any further.
The documentation on netfilter.org is rather extensive, and WAY more accurate than your writeup. Please read AT LEAST the iptables man page before writing any more on this subject.
Thank you for your comments, I have the steps taken to correct what was misspelled and wrongly written.
I actually DO appreciate your input since I DO want novices to get the most out of these. Even though I know some things were factualy wrong (such as naming the chains tables) I have been told that tables as an EXPLANATION works very well for a lot of people.
But yes I apologize. The ACCEPT/DENY/DROP issue is fixed as well the DENY slipped in there as I was migrating ipchains around the time I wrote this.
Again sincerest apologies, and (office space quote: I fixed the glitch)
You still haven't all errors fixed. For example, on the first page you're still talking about DENY where you obviously mean DROP. And traffic (actually processing of packets) doesn't necessarily stop when a rule is matched (think e.g. about rules redirecting packets to user- defined chains).
Why are you trying to re-invent the wheel anyway, if I might ask? As I said in my last post: the documentation on netfilter.org is rather extensive, covering a broad range from first steps to very advanced topics. Is there something you are missing?
I don't care how well people think this works for them as an explanation. It's wrong and will only lead to confusion when discussing iptables matters with other people.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.