Building Firewalls With OpenBSD And PF, 2nd Edition (2003)
.pdfSection 4.3: ConŒguring Networking |
87 |
|
|
Then, restart inetd(8):
# kill -HUP `cat /var/run/inetd.pid`
and reload pf rules:
#pfctl -F all
#pfctl -f /etc/pf.conf
The conŒguration of ftp-proxy(8) is described in its manual, so there is not much point rewriting it here. Default settings are good and can be safely used in most cases. When you run into problems with Network Address Translation (NAT), have a closer look at the description of the -n option. Another handy option is -A, which allows users to log on remote FTP servers as anonymous users, which usually means that they only get limited download privileges. This is enough for most non-technical users.
There is a way to connect to some servers without using ftp-proxy(8). Some FTP clients and servers can work in passive mode, which only needs one connection for data and control. A lot of FTP servers can detect problems with Œrewalls and switch to passive mode automatically. When automatic passive mode negotiation is not available, you can often do it by hand. Modern FTP clients and servers allow you to switch to passive mode with the passive command.
Such solution, while usable, and better than nothing, is not perfect. You will still not be able to connect to many FTP servers, which is particularly noticeable when you try to browse FTP sites with a web browserŠit will hang for a long time before returning an error message.
Another problem with FTP are FTP servers sitting behind a Œrewall. They will most likely be located in a DMZ segment and will have a private IP. So, how does one reach an FTP server hidden so well? With reverse ftpproxy(8) of course. You run it on the Œrewall host and make it wait for connections to port 21. When they arrive, they will be redirected to the FTP server in the DMZ and everything will work as if the server was directly accessible on the Internet.
88 |
Chapter 4: ConŒguring OpenBSD |
|
|
Unfortunately, ftp-proxy(8) does not support it out of the box. You need to build your own version of ftp-proxy(8). Don't worry it is not as scary as it sounds. You'll have to download OpenBSD sources (to another machine), update them to the latest version of OpenBSD (-rOPENBSD_3_4), apply the ftp-proxy-reverse.diff patch, and build a new ftp-proxy(8) binary. Scary? Only at the Œrst sight. To begin, download src.tar.gz from /pub/OpenBSD/3.4 (you'll Œnd the list of mirror servers in Chapter 3, Installing OpenBSD). Once you have it, download the ftp-proxy-reverse.diff patch from:
http://www.benzedrine.cx/ftp-proxy-reverse.diff |
(reverse ftp-proxy patch) |
Then, issue these commands:
$ su
#cd /usr
#tar -zxvf /home/joe/src.tar.gz
#setenv CVS_RSH ssh
#setenv CVSROOT the string that you put here is one of CVSROOT values
found on http://www.openbsd.org/anoncvs.html
#cvs -q get -rOPENBSD_3_4
#cd /usr/src/libexec/ftp-proxy
#patch < /home/joe/ftp-proxy-reverse.diff
#make
#cp /usr/libexec/ftp-proxy /usr/libexec/ftp-proxy.old
#cp /usr/obj/libexec/ftp-proxy/ftp-proxy
+ /usr/libexec/ftp-proxy
What you will get is a new binary that can redirect FTP clients to FTP servers using private IP addresses hidden behind a Œrewall.
To enable ftp-proxy(8), add the following line to /etc/inetd.conf:
a.b.c.d:21 stream tcp nowait root
+ /usr/libexec/ftp-proxy ftp-proxy -R 10.1.1.4:21
Let's explain a few things: a.b.c.d is the address of the external interface at which connection attempt from FTP clients will arrive; 21 is the standard FTP port number; 10.1.1.4 is the address of the internal host running the FTP server on port 21. When you want to run the FTP server on a
Section 4.3: ConŒguring Networking |
89 |
|
|
higher port (> 1024), change the port number for the internal server, e.g.:
a.b.c.d:21 stream tcp nowait root
+ /usr/libexec/ftp-proxy ftp-proxy -R 10.1.1.4:8021
If you want to learn more about FTP, consult [RFC 959] and [Stevens 1994].
4.3.6 Taking Control of ARP
Contrary to popular belief IP addresses are not enough for TCP/IP packets to reach their destinations. Another piece of information required to make it happen is the destination's Ethernet Media Access Control (MAC) address, sometimes called the Ethernet address or the hardware address. They are used by hosts, routers, and bridges to pass IP packets from one point on the network to another. Unlike IP addresses, which are assigned by the administrator, Ethernet addresses are assigned by the network interface card manufacturers. Every Ethernet network interface card in the world has a unique 6-byte number burned into its PROM chip and that number is its' Ethernet address. You can can Œnd out what it is on your machine with ifconŒg(8):
# ifconfig rl0
rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> + mtu 1500
address: 00:00:1c:d7:4d:06
...
The Ethernet address is displayed as a string of six hex numbers separated with a colon(:).
Because Ethernet addresses cannot be used on the Internet (routing would be a nightmare), there must be a way to translate between the IP address space and the Ethernet address space. That is the job of the Address Resolution Protocol (ARP) [RFC 826]. The way it works is quite simple. Suppose that the gateway your internal network is connected to receives a packet whose destination address is 10.1.1.32. If requests for the same address have been received in the last few minutes, there is a chance that the IP/Ethernet address pair is still stored inside the ARP cache; when this is not a case, ARP will broadcast a message asking who has this address.
90 |
Chapter 4: ConŒguring OpenBSD |
|
|
A `broadcast' is a message sent to all machines on the same network segment.
Such messages are being listened to by all machine on the same network segment and the one that has an interface to which you assign the IP address of 10.1.1.32 will send its IP/Ethernet address information to the gateway who will store it in its cache. The machine answering the gateway's call will store the gateway's IP/Ethernet information and both will communicate with each other without sending ARP requests unless there's been a long period of inactivity between them and one of them removes the IP/Ethernet information from its cache. You can watch ARP in action with tcpdump(8):
# tcpdump -n -e arp tcpdump: listening on rl0
16:55:11.548546 0:40:25:e3:40:af ff:ff:ff:ff:ff:ff 0806 60: arp + who-has 10.1.1.32 tell 10.1.1.1
16:55:11.549173 0:41:26:e4:41:af 0:40:25:e3:40:af 0806 60: arp + reply 10.1.1.32 is-at 0:41:26:e4:41:af
There might be a long time before you see anything, but eventually you should start seeing output similar to the one shown above.
ARP essentially run on autopilot, which is why many young administrators often do not know that it exists. Which is a pity, because there are a few tricks that can make network management easier as well as making your network more secure.
The Œrst feature of ARP that can come handy in everyday network administration routine is the ability to change the MAC address of the interface. Why would you want to do it? There are two popular cases: failover solutions (when one machine is taking over the responsibilities of another and must have the other machine's IP and MAC addresses to cause the least havoc on the network) and dealing with ISPs who Œlter MAC addresses and are slow or unwilling to change their Œlter rules when you change the network interface card that connects your network to their routers. The solution is to assign the old MAC to the new interface. Contrary to what you'd expect, you cannot do it with ifconŒg(8), but must download and build a separate tool called sea. Fortunately, it is quite easy to do. Download the sea.c source code:
Section 4.3: ConŒguring Networking |
91 |
|
|
$ lynx -dump
+ http://www.devguide.net/books/openbsdfw-02-ed/sea.c > sea.c
build sea:
# gcc -Wall -o sea sea.c -lkvm
boot OpenBSD into single-user mode:
# reboot boot> boot -s
run sea:
# ./sea rl0 00:00:00:00:00:01
Do not use the 00:00:00:00:00:01 address on your network. It is just an example. Use the old card's MAC address instead and do not use the old card on another host on the same network segment, unless you change it's
MAC address as well. Two interfaces with the same MAC address is asking for trouble.
Check that the interface is reconŒgured properly:
# ifconfig rl0 | grep address
If all is working Œne, add the sea command to /etc/netstart to make sure that the new MAC address is assigned automatically on every system reboot. Next, restart the system:
# reboot
Not all cards allow you to change their MAC address, but they are in minority.
What if you wanted to do as your ISP does and also Œlter packets based on their MAC addresses? It is not possible with pf, but you can do it, if you conŒgure your host as a bridge (see earlier sections in this chapter), because the MAC address Œltering code is a part of the bridge code base, instead of
92 |
Chapter 4: ConŒguring OpenBSD |
|
|
being a part of the pf code (this is no accident, there are good reasons for this).
There two kinds of rules for MAC address Œltering: block or pass. Their syntax is simple: every rule starts with the rule keyword followed by:
ƒaction keyword: block or pass
ƒdirection keyword: in or out
ƒinterface name: the on keyword followed by the name of the interface the rule will apply to.
ƒsource MAC address: the src keyword followed by the MAC address of the interface the rule will apply to. This part is optional.
ƒdestination MAC address: the dst keyword followed by the MAC address of the interface the rule will apply to. This part is optional.
The rules can be added with brconŒg(8) or the can be listed in the appropriate /etc/bridgename.* Œle.
For example, the following rule blocks all inbound trafŒc on rl0:
rule block in on rl0
This rule will pass all outbound trafŒc on ne1:
rule pass out on ne1
What if you wanted to block outbound trafŒc from just a few interfaces? Use the following rules (ne1 is the external interface in this example):
rule block out on ne1
rule pass out on ne1 src 00:00:00:00:00:01 rule pass out on ne1 src 00:00:00:00:00:02 rule pass out on ne1 src 00:00:00:00:00:03
Please note that the last matching rule wins, hence the global block or pass rule should be listed before more speciŒc rules. Also worth remembering is the fact that
Section 4.3: ConŒguring Networking |
93 |
|
|
src and dst sections are optional and independent of each other; you can have either, or both, of them in your rules, if that's what you need.
Another layer of defense is based on ARP is static ARP. As you might suspect, static ARP does not allow automatic ARP cache updates. How could it be useful? Suppose that someone takes over one of the hosts on your internal network, or plugs his laptop into a free connector on a hub or switch, to hijack the communications of another host on the same network segment. All he has to do is assign an IP number used by the target host to the host he is in control of (it is useful if the target other host is crashed or powered down, that can be arranged) and ping a few addresses on the same segment. Since all other hosts do not have the rouge machine's MAC address in their ARP caches, the hacker will ping a series of hosts, which will cause them to update their ARP caches. In a matter of seconds, the rouge machine is being recognized as the old host and can talk to other hosts as if nothing has happened. The attacker uses the very mechanism that makes ARP so usefulŠthe automated discovery and learning of the Ethernet addresses. What can you do to prevent it?
First of all, you should be using a switch and not a hub. This makes network snifŒng a lot more difŒcult. It isn't fool-proof (there are tools that turn switches into hubs by •ooding them with requests that the switch cannot handle). Next, you supply the gateway machine with the static IP/Ethernet address information for all machines on the network segment in question and turn ARP off (the interface should have the NOARP •ag turned on):
#ifconfig rl0 -arp
#ifconfig rl0
rl0: flags=88c3<UP,BROADCAST,RUNNING,NOARP,SIMPLEX,MULTICAST> mtu 1500
#arp -d -a
#arp -s 10.1.1.32 0:41:26:e4:41:af permanent
#arp -s 10.1.1.33 0:41:26:e4:41:b0 permanent
#arp -s 10.1.1.34 0:41:26:e4:41:b1 permanent
#arp -s 10.1.1.35 0:41:26:e4:41:b2 permanent
Be careful! Disabling ARP and clearing the ARP cache is the best way to loose network connection. Do it from a
94 |
Chapter 4: ConŒguring OpenBSD |
|
|
script or from the console, where you have full control over the system.
You can use static ARP on every host on the same network segment as well. Their ARP caches only need to store the IP/Ethernet information for the gateway.
If you want the static ARP conŒguration to happen automatically at every system restart, place the arp commands in /etc/netstart and add the -arp command to the appropriate /etc/hostname.* Œle.
The gateway will now only send and accept packets to/from the MAC addresses it has in its ARP cache, the cache will not be altered dynamically. It is a double-edged sword; when you change the network interface on one of the hosts, you will have to update the ARP caches entry for that host on the gateway, or the gateway will not be able to communicate with that host. You could also change the MAC address of the interface on that host to the address of the old interface.
On a related subject, when you are using OpenBSD conŒgured as a bridge, you can prevent bridge table poisoning with the -learn and discover commands placed in the /etc/bridgename.* Œle for every interface that belongs to the bridge.
For example, to set up static entries in the bridge table for hosts connected to the bridge via ne1, ne2, and ne3, use:
flush
-learn ne1 static ne1 01:23:45:67:89:ab -discover ne1
-learn ne2 static ne2 01:23:45:67:89:ac -discover ne2
-learn ne3 static ne3 01:23:45:67:89:ad -discover ne3
Is such protection strong? Not really, attackers can change their hosts' MAC addresses as easily as you can but, it does prevent stupid mistakes and makes it a little more difŒcult to break through your defenses. The best
Section 4.4: Automated System Reboot |
95 |
|
|
level of protection can be achieved when you combine pf, MAC address Œltering, authentication, encryption, and some kind of NIDS.
4.4 Automated System Reboot
A system `panic' is a an unforeseen event that causes system halt. The system drops to the debugger and waits for the operator to take care of the problem and reboot the machine, which is not always the desired behavior for a Œrewall, especially when the Œrewall is managed remotely. A better solution would be for the system to reboot itself. This can be done if you change ddb.panic to 0:
# systcl -w ddb.panic=0
Then, make this change permanents in /etc/sysctl.conf and change:
#ddb.panic=0
to
ddb.panic=0
4.5 Swap Encryption
Another level of security, desired on workstation and servers, is swap encryption. This is less necessary on a Œrewall, but if you have some CPU cycles to spare, set vm.swapencrypt.enable to 1:
# systcl -w vm.swapencrypt.enable=1
Then, make this change permanents in /etc/sysctl.conf and change:
#vm.swapencrypt.enable=1
to
vm.swapencrypt.enable=1
96 |
Chapter 4: ConŒguring OpenBSD |
|
|
4.6 Working with Securelevels
Securelevels deŒne different kernel security levels at which certain actions are permitted or not. There are four securelevels identiŒed with numbers -1, 0, 1, and 2. The higher the securelevel of the kernel, the lower the privileges granted by the kernel.
To change a secure level, use sysctl(8), e.g.:
# sysctl -w kern.securelevel=2
Permanent changes to that value should be recorded in /etc/rc.securelevel:
securelevel=2
While you might be tempted to raise the default securelevel to 2 (the default value is 1) it is not always a good idea. Although you gain greater security, you also loose •exibility of administration, as some changes can only be undone if you put the operating system in single-user mode and you need to reboot the machine with:
boot> boot -s
Then, you can undo the changes that are forbidden under lower securelevels or in multi-user mode.
On a Œrewall, the most important securelevels are 1 and 2 and they:
ƒSecurelevel 1. It is impossible to remove schg and sappnd •ags (see ch•ags(1)) without booting into single-user mode. Imagine that you set schg on /etc/rc.conf, /etc/pf.conf, or /etc/rc.securelevelŠevery change would require booting into single-user mode. Secure? Yes, but not convenient.
ƒSecurelevel 2. It is not possible to make changes to NAT or Œltering rules with pfctl(8).
This is only a part of the things that change under different securelevels, but they are most often of concern to Œrewall administrators. For more information about securelevels, read securelevel(7).