Firewalling revisited...

Björn Lindberg d95-bli at nada.kth.se
Tue Oct 16 10:46:59 PDT 2001


Henning Rohde wrote:
> 
> Hi Björn,
> 
> hey, your scripts look quite nicely, did you write them on a basis of
> some document or manual, or did you write them completely from scratch?

I wrote them from scratch, but using information from other sources,
like Rusty's guides and your firewall hint. The idea with dividing it in
routing and filtering is to make the logic a bit more obvious. The route
script looks puny now, but with more boxes inside and maybe some port
forwarding it would be longer.

> > # set default policy
> > $IPTABLES -P INPUT DROP
> > $IPTABLES -P FORWARD DROP
> 
> OK, these are sane policies, but why not on don't you use one on OUTPUT?

Because I didn't see a need to drop anything originating from the
router. Is there?

> > # INPUT section
> > # allow only packets from internal network
> > $IPTABLES -A INPUT -i $INTDEV -j ACCEPT
> > $IPTABLES -A INPUT -i lo -j ACCEPT
> 
> Hmm, what services does your router need to access itself?
> Does it log, for instance, onto another machine?

It works like this: the router masquerades the internal box so that it
look like the packets from the internal box comes from the external IP.
All incoming traffic is directly routed to the internal box, but passing
through a restrictive filter.

The only daemon on the router is ssh, but it is only open for
connections from the internal box, not from the outside. I was thinking
about allowing sshing to it on port 22 and maybe port forward port 222
to port 22 on the internal box, then I would be able to ssh into both
boxes from the outside.

Which would be best?

> > # allow SSH connections
> > $IPTABLES -A FORWARD -p tcp --dport 22 -j ACCEPT
> >
> > # allow ping requests
> > $IPTABLES -A FORWARD -p icmp --icmp-type echo-request -m limit --limit
> > 1/s -j ACCEPT
> 
> Hmm, why do you allow ping and ssh explicitely?
> If you want to ssh some machine anywhere on the 'net this would already
> be allowed by the general-clauses you've written above.
> 
> To state them explicitely makes only sense if you wanted to ssh your
> _internal_ machine or your router from somewhere on the internet, but
> IMHO this would be impossible with these two lines.

The first line makes it possible to ssh into the internal box from the
outside.

The second line makes it possible to ping the internal machine. Would it
be better if the ping request went to the router? Hmm... maybe that
makes more sense...

> If you wanted to ssh and ping your router from anywhere on the internet, you must place these rules into the INPUT-chain, and enable the corresponding traffic on OUTPUT.

I know, now I can ssh and ping the internal machine instead. I should
probably change the ping to go to the router instead though.

> > # do reversed path validation
> > echo 1 > /proc/sys/net/ipv4/conf/$EXTDEV/rp_filter
> >
> 
> Why do you enable rp_filter only on the external interface? As long as
> you don't play with having external IP-adresses on the internal network
> it would not harm if you enabled reversed path validation
> on any interface.

I thought that since I control what comes in from the internal
interface, it wouldn't be necessary. I have only this small, 2
box-network. I'm going to hook up another box eventually, but it's still
small... but as you say, it couldn't hurt.

> You may activate tcp_syncoocies, in the same directory as ip_forward,
> although they would not affect the security of any router because they
> were designed to prevent synflood-attacks against a server.

What does it do?

> Besides syncookies I'd like to recommend you to disable Explicit
> Congestion Notification in case you enabled it at kernel-compilation by
> error. IMHO there are still too many routers that block it because they
> are ignorant of this senseful feature.

Ok, I'll block ECN, I'll just have to find out how.

> > # give all packets coming from the internal LAN the router source
> > address
> > $IPTABLES -t nat -A POSTROUTING -o $EXTDEV -j SNAT --to $IPADDR
> >
> > # route incoming packets to nex
> > $IPTABLES -t nat -A PREROUTING -i $EXTDEV -j DNAT --to 192.168.1.1
> 
> Am I correct if I assume that you setup masquerading with these two lines?

Yes!

> If I'm correct, why don't you keep it as simple as this:
> $IPTABLES -t nat -A POSTROUTING  -o $EXTDEV -j MASQUERADE

Well... because I was under the impression that the MASQUERADE target
does something else specific to dynamic addresses, and I have, well at
least a semi-static IP. :-) I have a really fast connection, 10Mbit/s,
it's just that they use DHCP for IPs, but I _always_ get the same IP
anyway.

> PS: yes I know, you happy folks won't get affected too soon with the
> damn Euro!      ;-)

Well, I live in Sweden, so maybe sooner than you think! :-)

> PPS: Further additions: KISS -> Keep it stupid 'n' simple!
>         Rejecting identd-queries could be sensefull, see my hint.

Thanks for the tip.

> PPPS:
> Log everything for debugging, must be the last of all rules, just before
> you DROP/REJECT the unwanted packets:
> iptables -A INPUT   -j LOG --log-prefix "FIREWALL:INPUT  "
> iptables -A FORWARD -j LOG --log-prefix "FIREWALL:FORWARD"
> iptables -A OUTPUT  -j LOG --log-prefix "FIREWALL:OUTPUT "

I really wonder about this actually. I'm kind of a network newbie, so I
have _no_ clue as to what would be sensible to log, and how much etc.
Wouldn't the above lines result in very much log info?

Also, what happens after the LOG target? Will the packets continue
traversal of the chain or...?


Björn
-- 
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