Daniel Roethlisberger daniel at
Sun Oct 7 13:15:50 PDT 2001

a great many questions :)

Ian Molton <imolton at> wrote:
> Ok. what happens to packets that get natted?

> As I understand it, we have something like this:
> OUTPUT tables are for.

There are three tables: filter, nat, mangle.
There are multiple built-in chains in each table.

this is a more accurate diagram:

       mangle       |      filter    ^         nat
       nat          |                |
                    |                |
                    v                |
                    IN filter       OUT mangle
                    |                ^  nat
                    |                |  filter
                    v                |

You want to use the mangle table for packet mangling, the nat
table for masquerading, DNAT/SNAT, and the filter table for
allowing/dropping stuff.
> This would be what, something like:
> $IPTABLES -t mangle -X ?


> What does
> do?

if you specify no table, then "-t filter" is assumed. The above
flushes the filter table only.

>> > $IPTABLES -t nat -A POSTROUTING -o eth0 -s -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?

hmm may have several reasons. either you don't let RELATED
connections in, or you haven't got the FTP connection tracking
module loaded of compiled into the kernel.

>> 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?

That really depends on how much logging you want. The problem is
that with your log&drop chain, the limit is respective to -all-
logging as a whole. I don't use a log&drop chain, and then the
rate limits are per-rule. The default settings are probably ok for
you, it really depends on just how many log entries you want when
someone is really flooding you with garbage.

>> Then you want to block -all- illegal source address ranges from
>> the Internet, which are currently:

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

You should read up on source routing. Source routing is an IP
option. It allows to "route" an IP packet through a list of
gateway addresses.

The above list of reserved address ranges has nothing to do with
source routing. It is just the list of all those addresses which
are not routed through the Internet. Which means that anything
coming from them is bogus.

>> echo "2" > /proc/sys/net/ipv4/conf/eth0/rp_filter

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

Exactly, but only with weird setups where packets come in from one
and leave through the other uplink. And there are some issues with
advanced routing if you activate it (iproute2).

>> echo "0" > /proc/sys/net/ipv4/conf/eth0/log_martians

> What is a martian?

A packet with obviously fake source address. What we are blocking
with the return path filter.

> ditto for smurfs?

A ICMP Echo Request (ping) to a broadcast address. This used to be
abused to flood someone with ping responses (just send a bunch of
echo requests with spoofed source address to a broadcast address,
and all the hosts will flood the target with responses). These
days it is not so much of an issue anymore as not too many boxes
answer those anymore.

>> echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses

> I assume this is a 'stealth' scan technique?

It's just telling the kernel to ignore ICMP messages which make no
sense. It could be abused for OS identification, I guess. Well
there's no reason to act on bogus ICMP, is there?

> whats an ICMP redirect?

An ICMP message used in routing. It tells a host to use a
different route to a given host. Obviously, there's potential for
abuse of this feature.

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

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

Sorta. This is where nmap get's a hosts uptime from.

> Whats the downside to these?

None I know of. But they can save your ass when being SYN flooded.

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

Sure, that's what I do :)

I allow 8 and 30 initiating a new connection (that's ping request
and icmp traceroute). And I allow 0, 3, 4, 11, 12 and 31 on
est/rel connections, which are ping response, and all the error
messages concerning a connections (dest. unreachable, source
quench, time exceeded, parameter problem, conversion error).

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

Well, invalid is just as it says, invalid. Should never happen on
legit connections. See the packet filtering HOWTO.

>> # 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?

Drop all TCP packets which are not a SYN packet. A packet
initiating a TCP connection must be a SYN packet, and if it isn't,
then it is junk from a scanner (Xmas, Null, FIN scans etc), so we
drop it.

>> 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?

Yours only catches TCP, UDP and ICMP. Mine catches everything. Net
result is that ESP, AH, IGMP and every other IP based protocol
except TCP, UDP and ICMP gets through yours, but not through mine.


PS: google should know a lot about things like smurf scans, ICMP
    types, etc., so you might wanna check there ;)

   Daniel Roethlisberger <daniel at>
   PGP Key ID 0x8DE543ED with fingerprint
   6C10 83D7 2BB8 D908 10AE  7FA3 0779 0355 8DE5 43ED

Unsubscribe: send email to listar at
and put 'unsubscribe blfs-support' in the subject header of the message

More information about the blfs-support mailing list