hr at our-home.net
Wed Oct 17 13:06:43 PDT 2001
On Tue, 16 Oct 2001, Björn Lindberg wrote:
> Henning Rohde wrote:
> > > # 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
> Because I didn't see a need to drop anything originating from the
> router. Is there?
Hmm, I hope I'm allowed to assume nobody to be perfect, the least one I
claim to be perfect happens to be I myself.
So I like to have some 'insurance', some fallback-level-security, and
this can be accomplished by restricting OUTPUT:
If you only allowed '--sport 22' on OUTPUT, there's quite a lesser
chance that some cracker, who discovered an account with no password on
your router, is able to utilize your box for a DOS-attack.
I hope you'll see this point, IIRC I've explained it furtherly in my
hint, at the beginning of chapter (C).
> > > # 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.
Hmm, I know the principle called network-address-translation or, in
> 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?
For maximal secureness I'd like to propose that you neither allow to
FORWARD any new connection nor to DNAT or REDIRECT any ports from your
external interface to your internal client.
IMHO forwarding wont work properly here because your client have got
'private IP's', IIRC at least as long as you do not play with
source-routed packages, which is IMHO currently impossible because
you've activated rp_filter on your external interface.
Without any DNAT or REDIRECTions it would not mean that you're going to
lose any data If your router got compromised, because, I hope to assume
so correctly, there is no private data on it besides some passwords for
If you REDIRECTEDed a port to your internal client, you'll ease the
chances that any cracker is able to hack your internal box, with all
your private documents on it.
I'd like to propose the following:
Have only openSSH listen on port 22 on the router and forward only
established / related connections to your clients.
If you'd like to have access to your internal client, ssh from your
router to it, but use diffent passwords.
This way it is a bit less convenient and a bit slower, but the cracker
needs to crack twice to access any of your documents.
> > > # 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
> > > 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
> 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.
Hmm, tell me, have you verified this concept, does it really work?
IMHO, as I've written in my first response and here above, accessing
your internal client from the internet is nearly impossible the way
you'd like to do it, at least as long as your clients are having
IP-addresses that are assigned for _private_ use.
'Private use' means, that if you wanted to call home by 'ssh
192.168.1.1' from any machine directly connected to the internet, its
routing-algorythm won't know how to deal with it: at last the first
router should discard it to /dev/null!
There must be some RFC about this topic, if you still don't get the
point I'll look it up.
> > 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?
Forgive me, but I can't resist:
If you'd like to read a document that was written by someone who
designed this feature:
> > 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.
The same way you've activated ip_forward!
> > > # 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
> > 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
OK, I've looked it up in Rusty's guide, but it's still wrong.
He spoke of dynamic IPs, but he meant dial-up.
Because you mentioned DHCP in your script I assumed that you're having a
The special feature of MASQUERADE is, that it deals properly in case
that the connection is temporarilöy unavailiable.
If your uplink is a real ethernet-connection, you could keep it as it
is, although IMHO you need only the first line.
Did you try to ssh your router? If I've understood your scripts, you
wouldn't be able to access your router, you are directed to your client.
It's a quite interesting concept you've invented, as I've said I've
never seen some concept like yours before.
Anyway, I doubt using MASQUERADE would harm.
> > 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! :-)
Yes, I've realized that, but I thought that Sweden wouldn't lose it's
crown as soon as we German get robbed off our former rock-solid Deutsche
> > PPPS:
> > Log everything for debugging, must be the last of all rules, just
> > 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?
Yes it would, but only if you suffer long portscans or hard attacks.
To prevent any fill-up of your disk, you might add this feature:
'-m limit --limit 1/m'
Have a look into iptable's manpage.
> Also, what happens after the LOG target? Will the packets continue
> traversal of the chain or...?
Yes, if you want to LOG only the discarded packets you must either put
these lines as the last before discarding them by policy or put some
'-j DENY' immediately after '-j LOG'.
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