Free Firewalls Configuration guide

The important thing to keep in mind is that this only gives you basic "secure your network" type information. You should also actively seek out, and stay current in, security issues for your specific platform.

Page sections

• Know your networking
• Conceptual Firewall Types
• Securing the machine
• Ruleset Guidelines
• Real live rulesets
• Paranoia

Know your networking

Information comes across the network in "packets". These packets can be of very different types. You may choose to allow a certain group of types through, or just a select few, or even just one type of packet. So it is imperative to understand networking at a fundamental level first.

You need to understand the basic packet layers before continuing

Conceptual Firewall Types

There are still multiple types of "single-box" firewalls:

1. proxy firewall
2. NAT firewall
3. transparent firewall

Proxy firewall

Advantages:

• The proxy is usually highly aware of the data format it handles, and can look for many "naughty" things, and protect you from them.
• You are guaranteed of only allowing specific protocols that you wish to support.

Disadvantages:

• For any new protocol that you want to allow, you need a proxy that is specifically aware of that protocol.
• If an existing protocol is extended, you will probably need updated proxy software.

NAT firewall, AKA "Masquerading"

A NAT firewall may have filters to only allow outbound packets on certain ports, or it may simply choose to allow all outbound connections.

Advantages:

• Requires no special configuration on the client side, except for normal routing configuration. Clients just have to know their default gateway, and that's about it.

1. There is no additional security beyond "allow this type of traffic". Once an internal client connects via an allowed protocol, anything can happen within the bounds of that protocol
2. There is no way to allow for special protocols that require a return connection to be made.
3. If you wish to restrict certain types of protocols, you can only limit access to certain ports. On the one hand, this is too restrictive, because internal folks may not be able to accesss webservers on non-standard ports. And at the same time, this is too permissive, because there may be a disallowed service running on a non-standard port on the outside, and your internal folks will be able to access it in this case.

Transparent firewall

Advantages:

• No special configuration on the client side, just like a NAT firewall.
• Allows for finer control and protection for well-known services

Disadvantages:

• Shares most of the disadvantages of a NAT firewall. If a particular application protocol is being used on a non-standard port, you will lose all "special" protections. Depending on your allow rules, it may not even happen at all.

Securing the machine

One way is to get an operating system that is explicitly designed for this. For example, one of the "firewall on a floppy" distributions, like http://www.zelow.no/floppyfw (Linux 2.2.X based. I like the description of "More than one floppy is bloatware" !)

But in case you like to roll your own, here's some guidelines.

Ideally, you should turn off ALL services. A "netstat -an | grep LISTEN" should show NO listening ports.

Sometimes, it is neccessary to enable particular services, like ssh. If so, you should configure those services to only accept connections from specific hosts whenever possible. Ideally, you would only run those services on the "internal" side of the firewall.

Additionally, you should remove all unneccesary software from the machine. If you are running a package-based OS, like Solaris or Debian Linux, you should look through the list of installed packages. If you dont know what a package does, either learn it, or remove it. If you know a package is not neccessary for firewall operation, remove it.
You should also remove the setuid permissions of any setuid-root programs. If you need root access to do something, use root to do it!

The ultra-paranoid should at this point also make a point of taking checksums of every single file on the machine, and putting them somewhere safe. You should then periodically take another set of checksums to compare, to verify that your machine has not been tampered with. To improve the tamper-proof rating, put the original checksums and program on read-only media like a floppy or CD-R, and only run the program from this read-only media.

Ruleset guidelines

If you are wondering whether or not you should allow a new type of service, consider that the more complex a service is, the more likely there are to be security holes somewhere waiting to get you.

The simplest firewall ruleset nowadays will probably look something like the following:

Source IP	Dest IP	Protocol	Action
INTERNAL	Any	http(tcp)	ALLOW
INTERNAL	Any	ftp(tcp)	ALLOW
DNS-server	Any	DNS(udp)	ALLOW
[Any]	[Any]	[Any]	[IMPLIED REJECT]

You would additionally want some way of rejecting packets that are supposedly from one interface, but coming in on another. This is protecting yourself from "IP Spoofing"

Note that the "protocol" field is actually misleading. Firewalls arent smart enough to look at a packet and tell "This has HTTP data in it". And even if they were, doing that kind of analysis would slow things down too much.They can only tell "This has TCP data in it with a destination of port 80". So "http" in this case is really just an alias for "TCP, port 80".

Also, the http line implicitly has TWO rules. One rule allows packets to go outbound. The other one says, "If there is an established TCP connection for this protocol, allow packets for that connection to flow inside"

On the other hand, ftp IS sometimes treated specially. Some firewalls have special logic to help ftp connections along, because FTP is a special case. FTP transfers involve TWO connections: a control connection, and a data connection. Originally, the control connection was established as an outbound connection, and the data connection was initiated by the server connecting back to the client. But these days, allowing any kind of inbound connection is a bad idea, so "passive", aka "PASV" FTP, is used. This forces both control and data connections to be outbound.

DNS is also a special case. It is different for a variety of reasons:

1. A lot of client machines dont do full DNS queries. They rely on a common server to handle caching. This turns out to be a good idea anyway, to minimize potential DNS attacks.

2. DNS is based on top of udp. Therefore, there is no "connection" to automatically allow DNS packets inbound. The outbound part is still simple, but the firewall may have to be somewhat smart to figure out when to let DNS packets back inside. Some firewalls do try to be "intelligent" about it, but this is not completely adequate.

3. Some old DNS name servers send queries out on the same port they answer queries on: UDP port 53. So at a high level, it would be difficult to look at a packet and say "This packet is a reply by a normal machine, to a query we sent out".

4. Since there is no "connection", if a packet for a particular UDP port on the inside is let through, the odds are it will get accepted by whatever is listening on your private, internal client machine. There still is the issue of matching port number(s), but it is much much easier for a malicious person to fake UDP packets than it is to fake TCP packets (primarily due to TCP sequence numbers)

ipfilter is a well-written STREAMS-based driver that runs on most UNIX variants like Solaris, and BSD... except Linux, because Linux doesnt have proper STREAMS-based networking.

ipchains is the Linux-specific filtering driver that comes with the standard Linux kernel these days.

ipfilter (Solaris, BSD, ....)

We assume that your internal network is a private class A, on the reserved 10.0.0.0 network, on interface dnet0. Additionally, you have a caching DNS server at address 10.1.1.53

IP Filter ruleset (ipf.conf)

pass in quick on dnet0 proto tcp from 10.0.0.0/8 to any port = 80 keep state

pass in quick on dnet0 proto tcp from 10.0.0.0/8 to any port = ftp keep state

pass in quick on dnet0 proto tcp from 10.0.0.0/8 to any port = ftp-data keep state

pass in quick on dnet0 proto udp from 10.1.1.53 to any port = 53 keep state

#[Yes, DNS *sometimes* uses tcp also] pass in quick on dnet0 proto tcp from 10.1.1.53 to any port = 53 keep state

#(Manually block IP Spoofing ) block in quick on dnet1 from 10.0.0.0/8 to any

#(Block attempts to reach PRIVATE net directly) block in quick on dnet1 from any to 10.0.0.0/8

#(block fragmented packets ) block in quick on dnet1 from any to any with short

# Allow tcp-out from FIREWALL pass out quick on dnet1 proto tcp from any to any keep state

# Allow udp-out from FIREWALL pass out quick on dnet1 proto udp from any to any keep state

Do not forget the "quick" directive!. If you forget it, it will fall through to the next rule.

To enable NAT, you have to separately configure "ipnat.conf". A trivial one-line ipnat.conf might be

map dnet1 10.0.0.0/8 ->0.0.0.0/32 portmap tcp/udp auto
# If you want to enable ICMP (and all other non-tcp/udp protocols), add:
# map dnet1 10.0.0.0/8 ->0.0.0.0/32 

You now have to turn on "IP Forwarding".

On Solaris, if you have multiple interfaces, ip forwarding should be on by default, due to /etc/init.d/networking. But just in case you want to do it by hand, you can use

ndd -set /dev/ip ip_forwarding 1

case $1 in
   start)
        ndd -set /dev/ip ip_strict_dst_multihoming 1
        ndd -set /dev/ip ip_forward_src_routed 0
	ndd -set /dev/ip ip_forward_directed_broadcasts 0
   ;;
esac

Unfortunately, the best I can do for FreeBSD is offer you this third-party patch for rc.firewall. There's other good stuff at http://www.obfuscation.org/ipf/ But note that BSD comes with its own "natd" which would presumably be used instead of ipfilter's own ipnat driver.

ipchains

This next one assumes your INTERNAL interface is eth0, and your EXTERNAL interface is eth1

IPChains ruleset

ipchains -A forward -p tcp -i eth0 --dport www -j ACCEPT

ipchains -A forward-p tcp -i eth0 --dport ftp -j ACCEPT

ipchains -A forward -i eth0 -s 10.1.1.53 --dport 53 -j ACCEPT

If you want to automatically do NAT/Masquerading, replace "-j ACCEPT", with "-j MASQ"

The "hard way" to turn on ip forwarding in linux, is to do

echo 1 > /proc/sys/net/ipv4/ip_forward

# (And then to protect from IP Spoofing)

for f in /proc/sys/net/ipv4/conf/*/rp_filter; do

           echo 1 > $f

       done

ip_forward=yes
spoofprotect=yes

There is a lot more to be said about how IP Chains works. It has a concept of named rulesets, aka "chains".

The default "chains", are "input", "output", and "forward", but you can name your own, and chain them in to one or more of the standard ones. To learn more, please follow the link to the ipchains web pages, at the top of the Real live rulesets" section

Quick-n-dirty ipchains "secure this box" rule

ipchains -A input -i eth1 -p tcp -y -j DENY

The line is interpreted as follows:

For inbound packets	-A input
On interface eth1	-i eth1
Protocol TCP, wanting a new connection	-p tcp -y
DENY THEM	-j DENY

This won't stop everything. After all, it doesnt even touch UDP at all! But it will stop all attempted TCP connections from "outside", assuming "eth1" is your external interface.

Quick-n-dirty ipfilter rule

pass out quick on dnet1 proto tcp from any to any keep state
block in quick on dnet1 all
#Note that this doesnt pass DNS, or ANY KIND of UDP!!

Then run " ipf -Fa -f ipf.conf", and the new rules should be in place.

Or if you're running Solaris, just run "sh /etc/init.d/ipfboot reload" to activate your new config.

Paranoia

To sum it up: Trust no one. Trust nothing to work, unless you personally have seen it work.

The most immediately relevant part of this philosophy is that, once you have implemented some variant of filtering from above: VERIFY IT FROM OUTSIDE

(Is that clear enough, or do I need to emphasize it a little more?)

I apologise if there are any errors in the rulesets listed. Please email me if you find any problems with the rulesets here.

Additionally, if you are interested in SunScreen for solaris, sun has a "blueprint" on how to set it up. Or, you can read my much shorter SunScreen command-line guide

Or, if you want to get sneaky, and want a firewall without having a firewall... use ipsec to give you package filtering on a simple workstation that has IPsec on it (solaris 8 or later has it), without having to install a "firewall package".

Try dropping this ipsec.conf file into /etc/inet/ipsecinit.conf, and rebooting, if all you want is to allow ssh in/out, and DNS traffic.

Author: Philip Brown Site: http://www.bolthole.com/solaris/