Re: Linux IPTables tutorial pdfs and plain text available.
- From: Ansgar -59cobalt- Wiechers <usenet-2007@xxxxxxxxxxxxxxxx>
- Date: 9 Jan 2007 18:06:10 GMT
Flosse <flosse@xxxxxxxxxxxxxxx> wrote:
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
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.
(I think noone really explains all aspects of IPTables),
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.
cu
59cobalt
--
"If a software developer ever believes a rootkit is a necessary part of
their architecture they should go back and re-architect their solution."
--Mark Russinovich
.
- References:
- Prev by Date: Linux IPTables tutorial pdfs and plain text available.
- Next by Date: Re: Problems in multiplayer games
- Previous by thread: Linux IPTables tutorial pdfs and plain text available.
- Next by thread: RE: Re: Linux IPTables tutorial pdfs and plain text available.
- Index(es):
Relevant Pages
|
|
