BSD DevCenter
oreilly.comSafari Books Online.Conferences.

advertisement


Securing Small Networks with OpenBSD, Part 1
Pages: 1, 2, 3

We also want to allow all traffic from legal addresses in the DMZ to the Internet; all we have to do is copy the rules for the internal private network and replace the network address (192.168.2.0/24 instead of 192.168.1.0/24 -- the /24 is the netmask):



pass out quick on tun0 proto tcp from 192.168.2.0/24 to any keep state
pass out quick on tun0 proto udp from 192.168.2.0/24 to any keep state
pass out quick on tun0 proto icmp from 192.168.2.0/24 to any keep state

All other traffic that tries to reach the Internet through tun0 is blocked as a safety precaution:

block out quick on tun0 all

We now have a set of rules that define which packets can leave our network and try to reach other hosts on the Internet. In the next step, we will add rules that block unwanted packets sent from other hosts on the Internet to our network.

As before, we need to drop all packets sent from illegal addresses, as they will almost always be sent by people with bad intentions. This is done with the following set of rules:

block in     quick on tun0 from 192.168.0.0/16 to any
block in     quick on tun0 from 172.16.0.0/12 to any
block in     quick on tun0 from 10.0.0.0/8 to any
block in     quick on tun0 from 127.0.0.0/8 to any
block in     quick on tun0 from 0.0.0.0/8 to any
block in     quick on tun0 from 169.254.0.0/16 to any
block in     quick on tun0 from 192.0.2.0/24 to any
block in     quick on tun0 from 204.152.64.0/23 to any
block in     quick on tun0 from 224.0.0.0/3 to any
block in log quick on tun0 from x.x.x.x/32 to any
block in log quick on tun0 from any to x.x.x.0/32
block in log quick on tun0 from any to x.x.x.255/32

The log keyword tells ipfilter to log packets that match a particular rule.

When all illegal packets have been dropped, we can check if there are any packets destined at ports that we made open to the public and let them through. The following rule checks for packets sent to port 80, the place where we can usually find some sort of HTTP server listening for requests from HTTP clients.

pass in quick on tun0 proto tcp/udp from any to x.x.x.x/32 port = 80 keep state
pass in quick on tun0 proto tcp/udp from any to 192.168.2.254/32 port = 8080 keep state

Note that the address/port pairs used in ipf.rules must match address/port pairs used in ipnat.rules. A set of rules that allows connection to the SMTP server in the DMZ is shown below:

pass in quick on tun0 proto tcp/udp from any to x.x.x.x/32 port = 25 keep state
pass in quick on tun0 proto tcp/udp from any to 192.168.2.253/32 port = 25 keep state

All other packets sent to the external interface from the Internet will be discarded.

block in quick on tun0 all

Our external interface is protected quite well now, and we can focus our efforts on the interface to the internal private network and the DMZ. Assuming that the private internal network is connected to the interface ne1, we can write the following rule that blocks all packets trying to reach hosts on the internal private network:

block out quick on ne1 all

This rule cuts off access to the DNS nameserver for the internal private network listed in the /etc/resolv.conf file mentioned earlier in this article. You can enable acess to the nameserver with

pass out quick on ne1 proto tcp from 192.168.1.1 to 192.168.1.2/32 port = 53 keep state
pass out quick on ne1 proto udp from 192.168.1.1 to 192.168.1.2/32 port = 53 keep state

Better still, instead of using internal nameservers, use external nameservers, in which case the /etc/resolv.conf would look like this ("y.y.y.y" and "z.z.z.z" are IP addresses of external nameservers, which you should be given by your ISP):

lookup file bind
nameserver y.y.y.y
nameserver z.z.z.z

It is worth remembering, that "out" rules define filtering policy for packets leaving the firewall and entering some network (in this case, the internal private network), and "in" rules define filtering policy for packets sent from networks to the firewall. This has been known to cause a few problems to novices.

The rules that defines which packets sent from the internal private network can enter the firewall are similar, though not identical, to the "in" rules for tun0:

block in     quick on ne1 from 172.16.0.0/12 to any
block in     quick on ne1 from 10.0.0.0/8 to any
block in     quick on ne1 from 127.0.0.0/8 to any
block in     quick on ne1 from 0.0.0.0/8 to any
block in     quick on ne1 from 169.254.0.0/16 to any
block in     quick on ne1 from 192.0.2.0/24 to any
block in     quick on ne1 from 204.152.64.0/23 to any
block in     quick on ne1 from 224.0.0.0/3 to any
block in log quick on ne1 from x.x.x.x/32 to any
block in log quick on ne1 from any to x.x.x.0/32
block in log quick on ne1 from any to x.x.x.255/32
pass in quick on ne1 proto tcp from 192.168.1.0/24 to any keep state
pass in quick on ne1 proto udp from 192.168.1.0/24 to any keep state
pass in quick on ne1 proto icmp from 192.168.1.0/24 to any keep state
block in quick on ne1 all

Unlike the internal private network, the DMZ is partially open to the outside world. Therefore, before we drop all packets trying to reach it, we will need to let some through. The first set of rules will let all traffic from the internal private network through without any restrictions:

pass out quick on ne2 proto tcp from 192.168.1.0/24 to 192.168.2.0/24 keep state
pass out quick on ne2 proto udp from 192.168.1.0/24 to 192.168.2.0/24 keep state
pass out quick on ne2 proto icmp from 192.168.1.0/24 to 192.168.2.0/24 keep state

Next, we'll block packets sent to illegal addresses:

block out quick on ne2 from any to 192.168.0.0/16
block out quick on ne2 from any to 172.16.0.0/12
block out quick on ne2 from any to 127.0.0.0/8
block out quick on ne2 from any to 10.0.0.0/8
block out quick on ne2 from any to 0.0.0.0/8
block out quick on ne2 from any to 169.254.0.0/16
block out quick on ne2 from any to 192.0.2.0/24
block out quick on ne2 from any to 204.152.64.0/23
block out quick on ne2 from any to 224.0.0.0/3

And finally, we'll let packets through that arrive from the outside and are destined for publicly-open addresses:

pass out quick on ne2 proto tcp from any to 192.168.2.254/32 port = 8080 keep state
pass out quick on ne2 proto udp from any to 192.168.2.254/32 port = 8080 keep state
pass out quick on ne2 proto tcp from any to 192.168.2.253/32 port = 25 keep state
pass out quick on ne2 proto udp from any to 192.168.2.253/32 port = 25 keep state

All other packets are blocked for safety reasons.

block out quick on ne2 all

As for packets sent from the DMZ to the Internet, we let all packets sent from illegal addresses through:

block in     quick on ne2 from 172.16.0.0/12 to any
block in     quick on ne2 from 10.0.0.0/8 to any
block in     quick on ne2 from 127.0.0.0/8 to any
block in     quick on ne2 from 0.0.0.0/8 to any
block in     quick on ne2 from 169.254.0.0/16 to any
block in     quick on ne2 from 192.0.2.0/24 to any
block in     quick on ne2 from 204.152.64.0/23 to any
block in     quick on ne2 from 224.0.0.0/3 to any
block in log quick on ne2 from x.x.x.x/32 to any
block in log quick on ne2 from any to x.x.x.0/32
block in log quick on ne2 from any to x.x.x.255/32
pass in quick on ne2 proto tcp from 192.168.2.0/24 to any keep state
pass in quick on ne2 proto udp from 192.168.2.0/24 to any keep state
pass in quick on ne2 proto icmp from 192.168.2.0/24 to any keep state
block in quick on ne2 all

The rules we have now are quite restrictive and but also quite secure. You can enable them with the following commands:

ipf -A -Fa -f /etc/ipf.rules -E
ipnat -FC -f /etc/ipnat.rules

Our network will be quite immune to attacks from the outside, at the price of some inconvenience:

  • We cannot use traceroute -- the solution is to relax our rules. Read the ipfilter HOW-TO file for more information on how you can accomplish that feat. It will be a good exercise in configuring firewalls.
  • pings and connection attempts from the outside to our network report 100% packet loss -- this is a problem when you want to monitor the firewall from the outside by sending pings at regular time intervals, to see if the machine is running. You can replace pings with connections to public ports.

Should you want to open additional services to the outside world, remember to add appropriate entries in the /etc/ipnat.rules and /etc/ipf.rules.

Final Thoughts

What services you make available to the public is up to you. The most obvious candidate for running in the DMZ is the HTTP server. Another popular option is to have an email server and the DNS server for virtual domain hosting.

There are many solutions available on the market, but I suggest that you stick with what you know best, or, if you do not know how to manage a particular piece of software, my advice would be to start with simple things. For example, if you do not know how to configure and manage DNS, you can use the /etc/hosts files until you learn more about DNS. If you do need DNS for virtual domain hosting, use external DNS servers. You can rent a DNS server for as low as $5 per month per domain, or maybe you can ask your ISP to host these domains on their nameserver for you.

If you want to run a mail server, consider postfix, a free sendmail replacement that is much easier to configure and manage and enjoys a reputation of being much more secure than sendmail.

As for the HTTP server software, if you have never tried running a Web server, consider thttpd instead of the Apache Web server. thttpd is smaller, easier to learn and manage, and teaches some good administration habits. And if you really want to run a publicly-accessible namesever, try djbdns. Learn various configuration options for the servers you want to make publicly available and find out how to run them in the chroot jail, which greatly increases security of the system.

And finally, learn as much about network security, firewalls, TCP/IP management as you can. The design I presented in this article strikes a nice balance between security and inconvenience, but you should not assume it is without flaws, nor that it is the most secure design ever devised. It is only a beginning: you are supposed to improve it and adapt to your own needs. Read all available manuals, HOW-TOs, and tutorials. When in doubt, ask older/more experienced administrators and learn from them.

Read Part 2 of "Securing Small Networks with OpenBSD."

Jacek Artymiak started his adventure with computers in 1986 with Sinclair ZX Spectrum. He's been using various commercial and Open Source Unix systems since 1991. Today, Jacek runs devGuide.net, writes and teaches about Open Source software and security, and tries to make things happen.


Return to the BSD DevCenter.





Sponsored by: