RFC: firewall-hint_v1.3

jbauman at adsl-63-193-249-142.dsl.snfc21.pacbell.net jbauman at adsl-63-193-249-142.dsl.snfc21.pacbell.net
Sat Aug 11 16:17:34 PDT 2001


On Sat, Aug 11, 2001 at 07:30:24PM +0200, Henning Rohde wrote:
> Hi Jeff, hi everybody else,
> 
> thank you, Jeff, for reviewing my hint!
> 

You're welcome, Henning.

> Hmm, at the very first I would like admit that I deliberately did limit 
> the scope of my firewalling-hint:
> I want to tell our users how to start, who ever may be in the need for severe
> protection, he needs himself to get familiar with this topic!
 
Yes, people definitely need to take it upon themselves to get familiar with 
this topic if they are putting their systems on the Internet.

> My hint, as it is my intention, is supposed to fit at least for
> dial-up-users; those who want to protect their company's network will be paid
> for setting-up the firewall and will know the services, that they need to
> access, and especially those, that their employers want to be blocked!

There are many of us with dsl or cable modems that need to be at least a 
bit more careful than a dial-up user with their firewall, not just those 
doing it for a living.

> > > Before compiling you might want to edit the Makefile to adapt install-dir's.
> <+snip+>
> > As with most packages, you can specify the directories you would like to
> > have it installed in on the command line, for example:
> >         make BINDIR=/usr/bin LIBDIR=/usr/lib MANDIR=/usr/share/man install
> 
> Right you are. 
> But I do only mention where to edit, I do not recommend this edditing.
> Those who know why they want stuff not to be put elsewhere either know your way
> or deliberately pay the effort to edit the Makefile.
 
I guess I was thinking of the LFS books as a model here -- you're always told 
what commands to use to do the install. Is what we're writing to be 
substantially different from LFS? What model should we use?

> > > Now compile and install iptables and the utilities for saving and restoring
> > > via 'make && make install experimental install-experimental'.
> <+snip+>
> > If you're seriously configuring this as a working firewall, I would
> > recommend skipping the "experimental" stuff.
> 
> The only things that are assingned experimental in iptables-1.2.2 are are the
> save- & restore-utilities!
> I consider them to be quite useful, whoever likes to use them will test them to
> be sure they work as he expects them to do: again: i do not recommend but enable
> their use!
 
An alternative would be to recommend that people use a script to set up their 
firewalls. Saving and restoring rulesets is not really necessary, then. 
As the KNOWN-BUGS file in the iptables packages says, 

"4) iptables-restore and -save still have problems. Sorry."

I would not want my firewall security relying on this. 

> <+snip+>
> > > #!/bin/sh
> > > ##/etc/init.d/firewall
> <+snip+>
> > > # allow forwarding
> > > iptables -A FORWARD -m state --state ESTABLISHED,RELATED      -j ACCEPT
> > > iptables -A FORWARD -m state --state NEW      -i ! ppp+       -j ACCEPT
> > > # do masquerading (not needed if intranet is not using private ip-adresses)
> > > iptables -t nat -A POSTROUTING  -o ppp+                       -j MASQUERADE
> > > # Log everything for debugging: must be at the end of all rules
> <+unsnip+>
>     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 "
>     # set a sane policy
>     iptables -P INPUT       DROP
>     iptables -P FORWARD     DROP
>     iptables -P OUTPUT      DROP
> 
> > I'm not sure what you mean here. The LOG rule must come before an ACCEPT
> > or DROP rule that matches the packet, otherwise, the packet will not be
> > logged.
> 
> :-), but you just snipped the wrong lines: 
> those packets, that are not accepted in FORWARD or on loopback but are dropped
> by policy are those that get logged: eg scans, identd-queries, ...
> 

OK, your intent is clear now.

> <+snip+>
> > > Alternativly, if you want to ping your box to enshure it's still alive:
> > > iptables -I INPUT  -p icmp -m icmp --icmp-type echo-request     -j ACCEPT
> > > iptables -I OUTPUT -p icmp -m icmp --icmp-type echo-reply       -j ACCEPT
> > 
> > It would be wise to limit echo-requests to addresses you know you will
> > use, if this is possible, rather than making your box visible to the whole
> > world. For instance:
> > iptables -I INPUT  -p icmp -s 20.20.20.0/24 -m icmp --icmp-type
> > echo-request -j ACCEPT  # only accept pings from the 20.20.20 network.
> 
> Again, you're right.	But, why did you chose 20.20.20.0/24? 

Just a random example. Thought it was a bit more concrete than a 
<your-ip-address-here> sort of thing.

> Any network we would chose here will confuse those who do nothing 
> but copy'n'past the script; 

If the script has to be idiot-proof, then your way is the only way to go. I'm 
making the assumption that anyone who can get through LFS in the first place 
is not an idiot.

> and those who feel themselves in the need to will be
> able to combine the mentioned features of netfilter and find out about the rest.
> And furthermore, what if the user wants to check it via Dial-Up from anywhere?

As I said above, IF this is possible... Clearly for someone needing to ping 
from anywhere, it is not possible.

> At least IMHO, pings do not harm besides preventing an automatik dial-off; 
> and if the user feels they did he would know the need for a much deeper level of
> security than I'd like here to be offered.

Obviously you've never been the subject of a smurf attack. My firewall gets 
hit by dozens of pings per day from unknown hosts. If I drop the packet,
they're going to have to try harder to find me. Bottom line is that it 
takes one line of code (how much deeper is that?) to fix this.  

> 
> <+snip+>
> > It may be prudent to take some other precautions here, for example, here
> > are a couple ways to block spoofed packets. I recommend using both -- if
> > one fails, the other is there to catch the problem:
> > 
> > # Block spoofed packets
> > for f in /proc/sys/net/ipv4/conf/*/rp_filter; do
> >   echo 1 > $f
> > done
> > 
> > # Anything coming from the outside should not have a private address!
> > iptables -t nat -A PREROUTING -i ppp+ -s 10.0.0.0/8 -j LOG  \
> >         --log-prefix "Dropping spoofed packet"
> > iptables -t nat -A PREROUTING -i ppp+ -s 10.0.0.0/8 -j DROP
> > iptables -t nat -A PREROUTING -i ppp+ -s 192.168.0.0/16 -j LOG  \
> >         --log-prefix "Dropping spoofed packet"
> > iptables -t nat -A PREROUTING -i ppp+ -s 192.168.0.0/16 -j DROP
> > iptables -t nat -A PREROUTING -i ppp+ -s 172.16.0.0/12 -j LOG  \
> >         --log-prefix "Dropping spoofed packet"
> > iptables -t nat -A PREROUTING -i ppp+ -s 172.16.0.0/12 -j DROP
> > 
> OK, correct, we could include these lines.
> But I do think that IP-spoofing has become a much lesser danger than it was in
> times of ipchains: 
> wherever possible I do filter by interface, which is IMHO unspoofable.
> If one really needed to filter by IPs, then he could combine filtering by
> ip-adress with filtering by interface.
> 
> There another reason why I doubt we should include them:
> Oskar Andreasson mentioned in his tutorial that there are ISP's who use
> IP-networks that are assigned to private use for internal services, eg
> nameserver at Telia, Sweden.
> Eg our German exMonopolist, the DeutscheTelekom AG, uses 192.168.0.0/24 for it's
> antiquated BTX, a proprietary network for text-terminals, nowadays nearly solely
> used for homebanking, being still quite secure.
> 
> > There are certain types of packets that you will never want coming in from
> > the Internet. Here are some rules that address this:
> > 
> > # Log and drop malformed packets
> > iptables -A INPUT -p tcp -m state --state INVALID -j LOG \
> >         --log-prefix "invalid tcp packet DROP: "
> > iptables -A INPUT -p tcp -m state --state INVALID -j DROP
> > 
> > # The following packets are used for various types of scans, and nothing
> > #       legitimate:
> > 
> > # XMAS packets
> > iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j LOG \
> >         --log-prefix "XMAS packet hit the firewall"
> > iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
> > 
> > # NULL packets
> > iptables -A INPUT -p tcp --tcp-flags ALL NONE -j LOG \
> >         --log-prefix "NULL packet hit the firewall"
> > iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
> > 
> > # Drop FIN packets that don't have ACKs. They are scans.
> > iptables -A INPUT -p tcp --tcp-flags FIN,ACK FIN -j LOG  \
> >         --log-prefix "FIN packet hit the firewall"
> > iptables -A INPUT -p tcp --tcp-flags FIN,ACK FIN -j DROP
> > 
> > These rules should be placed early in the chain, before any ACCEPTs, other
> > than perhaps ESTABLISHED,RELATED connections.
> > 
> Hmm, do you really think that these lines are necessary? 
> I do not doubt that they are helpful for 'the highest security', but Linux is
> IIRC not vulnerable.
> They will, like pinging, prevent a automatik dial-off, but because they are
> caught by stateful-filtering they do not offer any ways to access harmfully any
> services, at least if I understood the topic correctly.
> Even scanning does not harm as long as firewalling is done correctly.
 
What are you saying, that Linux is not vulnerable to scans? Or that there 
will never again be a bug discovered in a Linux package that is remotely 
exploitable? 

If someone is scanning me, I want to know about it, and I want to provide as 
little information to that person as possible. You must be terribly confident 
in your software and your firewalling skills, and I suppose you spend quite 
a bit of time keeping up with all the latest exploits. I'm not nearly so 
confident or diligent, nor do I suppose others would be who just copied a 
script to do their firewalling, as you suggest people will do above. 
 
I'm beginning to wonder if the best approach to this whole thing might not 
be to provide instructions for installing iptables, and then just point 
them to resources and say, "figure out what you need for your own 
situation" rather than trying to provide rulesets. There are plenty 
of resources out there that already do this.

Jeff



More information about the blfs-book mailing list