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:
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
> > $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 ?
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
> > $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
> > # 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
> 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 220.127.116.11/4 169.254.0.0/16
> 0.0.0.0/7 18.104.22.168/8 22.214.171.124/126.96.36.199 188.8.131.52/8 184.108.40.206/251.0.0.0
> 220.127.116.11/7 18.104.22.168/8 22.214.171.124/8 126.96.36.199/8 188.8.131.52/7 184.108.40.206/8
> 220.127.116.11/8 18.104.22.168/22.214.171.124 126.96.36.199/7 188.8.131.52/6 184.108.40.206/3
> 220.127.116.11/8 18.104.22.168/8 22.214.171.124/8 126.96.36.199/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.
> 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
> > # 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
> # 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.
> > # 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
> 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