firewalling...

Ian Molton imolton at clara.net
Sun Oct 7 12:06:21 PDT 2001


On stardate Sun, 7 Oct 2001 20:44:49 +0200
Daniel began the full scale invasion of earth with the following words:

> 
> Ian Molton <imolton at clara.net> wrote:
> > so, heres my script... discuss?
> 
> > $IPTABLES -t nat -P PREROUTING ACCEPT
> > $IPTABLES -t nat -P POSTROUTING ACCEPT
> > $IPTABLES -t nat -P OUTPUT ACCEPT
> 
> Those are actually unnecessary. You don't want to drop anything in
> the nat table anyway, and default policy is accept anyway.

Ok. what happens to packets that get natted?

As I understand it, we have something like this:

--->PREROUTING-->[ROUTE]-->FORWARD---->[ROUTE]--->POSTROUTING--->
                    |                     ^
                    |                     |
                  INPUT                 OUTPUT
                    |                     ^
                    |                     |
                    +---->[USERLAND]------+

So I can see what the PREROUTING FORWARD, POSTROUTING, INPUT and OUTPUT
tables are for.

but what and where are the nat and MASQUERADE tables? how do packets end up
in them?

> > $IPTABLES -F
> > $IPTABLES -t nat -F
> > $IPTABLES -X
> > $IPTABLES -t nat -X
> 
> You forget the mangle table. You wanna flush/zero that too :)

This would be what, something like:

$IPTABLES -t mangle -X ?

What does

$IPTABLES -F

do? flush everything? if so, why bother with

$IPTABLES -t nat -F

?
> > /sbin/modprobe ip_conntrack_ftp
> > #/sbin/modprobe ip_conntrack_irc
> 
> If this is a dedicated firewall I recommend compiling this stuff
> into the kernel, as it will be loaded 24/7 anyway. No point in
> modules then, is there.

I like my kernel modular. it makes the image smaller, and easier to
transfer to floppy/other machines etc. and I can turn off things quite
nicely.
 
> > $IPTABLES -t nat -A POSTROUTING -o eth0 -s 192.168.1.0/24 -j MASQUERADE
> > echo "1" > /proc/sys/net/ipv4/ip_forward

The above seems to work, but why can I not do non-passive FTP from behind
the firewall?

> > # A 'logging' /dev/null */
> > $IPTABLES -N log_and_drop
> > $IPTABLES -A log_and_drop -p udp --sport 138 -j DROP
> > $IPTABLES -A log_and_drop -p udp --sport 631 -j DROP
> > $IPTABLES -A log_and_drop -j LOG --log-prefix "Firewall:"
> > $IPTABLES -A log_and_drop -j DROP
> 
> Uh, you almost definately want to rate limit the LOG rule. Add a
> "-m limit" there, and read up on rate limiting and additional
> parameters in the HOWTO. Otherwise port scans will flood your
> logs, and in the worst case completely DoS your box. Ugly.

Ta. any suggestions as to sensible settings?

OOI do we have a 'LFS recommended firewall' sort of thing? if not, the
result of this thread could become that...

> > # Protect us from source routed packets */
> > $IPTABLES -A INPUT -i eth0 -s 192.168.0.0/16 -j log_and_drop
> > $IPTABLES -A INPUT -i eth0 -s 10.0.0.0/8     -j log_and_drop
> > $IPTABLES -A INPUT -i eth0 -s 172.16.0.0/12  -j log_and_drop
> 
> Watch out, you only drop packets with bogus (private range) source
> addresses, not source routed packets in general with that.

Yep. what was I thinking?

> This will make the kernel ignore source routed packets on eth0:
> echo "0" > /proc/sys/net/ipv4/conf/eth0/accept_source_route

Sounds good...

> Then you want to block -all- illegal source address ranges from
> the Internet, which are currently:
> 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 224.0.0.0/4 169.254.0.0/16
> 0.0.0.0/7 2.0.0.0/8 5.0.0.0/189.0.0.0 23.0.0.0/8 27.0.0.0/251.0.0.0
> 36.0.0.0/7 39.0.0.0/8 41.0.0.0/8 42.0.0.0/8 58.0.0.0/7 60.0.0.0/8
> 70.0.0.0/8 72.0.0.0/232.0.0.0 82.0.0.0/7 84.0.0.0/6 96.0.0.0/3
> 197.0.0.0/8 201.0.0.0/8 219.0.0.0/8 220.0.0.0/6 240.0.0.0/4

why? doesnt the above setting of accept_source_route stop this?
OOI what about attacks from /within/ the firewall?

> BTW I never log those, there's no point, the source addresses are
> bogus, you cannot determine who sent it anyway.

Good point.

> Then, you might want to do some more kernel tuning (hope there are
> no typos):
> 
> # turn return path filtering on, which filters out obviously
> # spoofed source addresses (ie. if an answer to a packet would be
> # routed out through a different interface than it came in on,
> # drop it)
> echo "2" > /proc/sys/net/ipv4/conf/eth0/rp_filter

would this foul things up for people with two (or more) uplinks?

> # don't log martians, just drop them (my preference)
> echo "0" > /proc/sys/net/ipv4/conf/eth0/log_martians

What is a martian?

> # ignore smurf ICMP echo requests
> echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

ditto for smurfs?

> # ignore bogus ICMP messages
> echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses

I assume this is a 'stealth' scan technique?

> # ignore ICMP Redirects
> echo "0" > /proc/sys/net/ipv4/conf/eth0/accept_redirects

whats an ICMP redirect?

> # ignore TCP Timestamp option
> echo "0" > /proc/sys/net/ipv4/tcp_timestamps

Is this one of those 'TCP fingerprint' type vunerabilities?

> # use TCP SYN cookies
> echo "1" > /proc/sys/net/ipv4/tcp_syncookies

Whats the downside to these?

> > # Allow all on loopback, and icmp in general */
> > $IPTABLES -A INPUT -i lo -p all -j ACCEPT
> > $IPTABLES -A INPUT -p icmp -j ACCEPT
> 
> You probably don't want to allow ICMP types 6, 9, 10, 15, 16, 18
> and 18 in.

what are these types?

Is it perhaps a better idea to block all ICMP /except/ what we want to
allow?

> > # Enable masquerading
> > $IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

what does this do over simply doing:

$IPTABLES -t nat -A POSTROUTING -o eth0 -s 192.168.1.0/24 -j MASQUERADE

? It doesnt seem to help the FTP problem...

> > # Some select services */
> > $IPTABLES -A INPUT -p tcp --dport 22 -j ACCEPT
> > $IPTABLES -A INPUT -p tcp --dport 6346 -j ACCEPT
> 
> > # Allow DNS replies in
> > $IPTABLES -A INPUT -p udp --sport 53 -j ACCEPT
> > #$IPTABLES -A INPUT -p tcp --sport 20 -j ACCEPT
> 
> > # Dont accept connections from outside */
> > $IPTABLES -A INPUT -p tcp ! --syn -j ACCEPT
> 
> Well, these look like relics from old times, with non-stateful
> firewalls. Have you converted old ipchains rules? With netfilter,
> you could do something like this (watch out for typos, I write
> those out from memory):

No, I've been reading up on the 'net, but the information is scattered,
confusing, and (apparently) largely out of date...

> # let in stuff belonging to already established connections
> $IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> $IPTABLES -A INPUT -m state --state INVALID -j DROP

what is the INVALID state? (is there a list of state values and their
descriptions?

> # TCP, but not SYN (actually, state invalid should catch this too)
> $IPTABLES -A INPUT -p tcp ! --syn -j DROP

what exactly does this rule do?

> This way, you will let in everything that belongs to connections
> initiated from your box, including DNS queries and FTP data
> connections. You will not let in Null/FIN/Xmas scan crap, and only
> selected ports are accessible from the outside.

Nice.

> > # Dump anything that wasnt accepted into the log */
> > $IPTABLES -A INPUT -p icmp -j log_and_drop
> > $IPTABLES -A INPUT -p tcp  -j log_and_drop
> > $IPTABLES -A INPUT -p udp  -j log_and_drop
> 
> This is almost the same as:
> 
> $IPTABLES -A INPUT -j log_and_drop

Almost?

> As there's not just icmp, tcp and udp, there are other protocols
> on top of IP too (igmp, esp, ah, and many many more), and you
> don't generally want them all in, I expect.

Do you mean that your line logs everything and mine doesnt? or that neither
logs everything, and yours doesnt log the things above?
-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe blfs-support' in the subject header of the message



More information about the blfs-support mailing list