The reader is not expected to be a Unix expert (why would a Unix expert need this how-to?) — if you don’t understand something, or something looks intimidating, read on and come back to it. If something still doesn’t make sense, let me know.

I don’t cover what I consider “advanced” usage such as tracking -CURRENT or CVS snapshots. If you want to do that, I assume you know which FAQs to read!

This document may be freely reproduced and redistributed under the terms of the GNU Free Documentation License Version 1.1; with the invariant section being this entire document, with no Front-Cover Texts and no Back-Cover Texts.

In other words, if you want to copy this document in its entirety, feel free to do so; if you wish to modify it (as in providing a translation, or taking sections to include in other documents) please send me email. Needless to say, documents that this document links to will have their own copyrights.

New!
I have a shell script that sets up everything mentioned here. This is still experimental but if you try it, please let me know how it goes. Save this file to disk and run it by typing “sh config31-fw.sh”. (Doesn’t handle PPPoE [the beast].)

There is a new section called Tips and Stuff where I put things I’ve found or written that are useful sysadmin tools.

Introduction
Why OpenBSD? It’s simple and secure. Your firewall machine should not have lots of things installed on it; therefore no exotic hardware, graphical desktops, X11 servers etc. — put those on your desktop machine. A simpler system is more robust and more secure; this machine only offers SMTP (email), ssh, ping/traceroute and optionally HTTP (web) to the outside world. And since it’s running Unix, you can log in to it — securely — using ssh from anywhere on the Internet and make any changes you need to. (N.B.: never use telnet to connect to a machine over the Internet! Anyone can eavesdrop and grab important information like passwords. Only use ssh, which encrypts all communication so that eavesdroppers don’t get any information. And verify those key fingerprints or you leave yourself open to a man-in-the-middle attack. For information do a web search for public key cryptosystems; a good place to start is OpenSSH.)

The utility and security of having this kind of machine: a firewall protects your data and systems from the Big, Bad Internet. When the bad guys are out to vandalise machines on the Internet, MS-Windows machines of various kinds are prime targets because they suck. Er, I mean, Windows is really hard to secure. (Not that an incompetently run Unix machine is any better, of course.) When you dialled in on the phone, your machine was on the ‘net for brief periods; with DSL or cable it’s vulnerable all the time.

This document also describes how to set up an OpenBSD system as a Unix workstation. We will go over setting up X11 (the window system) etc. I assume that you will be using a different machine as your workstation. Important: Unix systems can be set up in various ways; I do things a certain way and that’s what this document will cover. Other people (wizards and newbies alike) may do things differently. In case it matters, I’ve been using Unix since 1982, have been a sysadmin on-and-off since 1986 (VAX/BSD, SunOS 4.x, Solaris 2.x, HP/UX, AT&T 3B5 SVR6 etc.) I’ve been a C programmer since the early 80s. Today I design and implement back-end network servers on Solaris.

This tutorial assumes that you have some familiarity with using Unix: what filenames look like, how to copy and edit files etc. There’s a decent Unix tutorial on the web. The most important command to remember is man (short for “manual”) — if I say something like “read the documentation for foobar it means you should type man foobar. One other piece of Unix argot: if you hear someone write select(2) it indicates that the manual for select is in section 2, i.e. you would read the manpage by typing man 2 select. You should also read the OpenBSD documentation: particularly the OpenBSD FAQ. Bookmark that link right now.

NAT (Network Address Translation) allows you to connect lots of PCs up to one network connection. When any of the machines inside the firewall wants to make a connection to some server out there on the internet, the firewall/NAT box intercepts that request, and sends the request off as though it came from the firewall/NAT machine. When the reply arrives, it is sent off to the machine that made the connection. Neither the server nor the machines on the inside know that all this is going on.

Aside: NAT is also called PAT, for “Port Address Translation.” Also, read this interesting article by HRH Prince Philip, Duke of Edinburgh, on setting up PAT and DHCP on Cisco routers. The whole routergod.com site features many celebrities offering helpful tips on various network issues.

Even if you don’t want plan on having more than one PC at home, NAT is useful, because it allows the machine running your firewall to be different from your main workstation. You probably want to install fancy hardware and software on your machine; but every additional package installed on a firewall makes it more vulnerable.

Network Address Translation (NAT)

Note: if you only have one machine on the “inside”, you don’t need an ethernet hub; use a crossover cable to connect the two machines directly. This also has the advantage that you can get a full-duplex connection between the machines (a hub only allows a half-duplex connection).

Note: you can buy little NAT/DHCP boxes from various manufacturers for about $150, but where’s the fun in that? Besides, who knows how strong the security is on those things. With OpenBSD you know you’re getting the best.

Building the machine
The machine itself: I prefer to build these machines up from individual components rather than buying a pre-made box. That way I can get name-brand supported components, and it works out slightly cheaper since I don’t have to get exotic video cards, sound cards, CD-ROM drives etc. (Not to mention a Fisher-Price operating system that you will be required to pay for.)

Can you build a PC? Well, no one showed me how, but I’ve managed to put together about 10 or so systems, so it can’t be that hard. If you’ve assembed anything with screwdrivers etc. you’ll be fine. There are numerous sites on the web that walk you through building a PC. Go do a Google search and read those. I especially like the one at Acme Labs by Jef Poskanzer. There’s also an excellent motherboard finder at Acme.

Caveat: specific recommendations will be outdated as soon as I write them! I like to use AMD CPUs because I believe Intel is evil and as far as possible I’d like to not buy their products. I’d get the current not-top-of-the-line CPU i.e. the one that costs about $50 and a compatible motherboard that costs in the range of $70. I stay away from integrated components because they’re usually garbage. (For a server that I don’t use directly I might get integrated video.) Spend about $30-50 on RAM, $30 on ethernet, $60 on an IDE disk, $30 for a case (with power supply). I usually find the best prices on components at Directron and CompuVest (warning: uses Java). These have both been non-sleazy (everything was as described in their catalog and shipping was prompt) in all my dealings with them — but let me know if you find any evidence of sleaziness.

All these components add up to around $300 — and that’s brand-new stuff. If you have any old components lying around, they will be fine. You don’t need a keyboard, mouse or monitor when the system is up and running — all maintenance on it can be done over the network. (While you’re installing the OS on the machine you will need to hook up a keyboard, monitor and CD-ROM drive to it, of course.)

While installing the system, I plug in a spare CD-ROM drive, keyboard and monitor. Change the BIOS settings so that the machine will boot without a keyboard etc. Boot off the OpenBSD 3.1 CD and install the system. All the hardware should be recognised without any problems. (The installation guide booklet that comes with the CDs is excellent.)

The easiest way to install OpenBSD is to buy the distribution on CDs. Although you can install it via the network, buying the CD will help make sure that the OpenBSD project will continue to improve and better the system. If you can afford an outlay of US$40, please buy the CDs from the OpenBSD ordering site.

When you’re installing OpenBSD, the installer program will ask you for disklabel information (partitions). On a Unix system, a group of files organised together is called a filesystem. The disk is partitioned into various pieces each of which will hold one filesystem. This is the filesystem breakup and partition sizes I’d use for a 12GB disk (if your disk is bigger, you can just increase the size of /var (for web files) or /home (for your personal files) — the system will be more than happy with these sizes for /, /tmp and /usr):

/dev/wd0a 100M /
/dev/wd0d 400M /tmp
/dev/wd0e 4GB /var
/dev/wd0g 2GB /usr
/dev/wd0h 5GB /home
(The convention is that a is always /, b is swap and c is the whole disk.) Your web files will live in /var, and your other files in /home.

This is all overkill; /usr only needs about 600M or so. Say pad it to 1GB. A 2GB disk would be plenty for the system, but if the cheapest disk you can get is 13GB….

Note for Unix newcomers: the disk is named /dev/wd0, and in this case it has 5 partitions with names /dev/wd0a, /dev/wd0d, /dev/wd0e, /dev/wd0g and /dev/wd0h. And the different partitions don’t get different “drive letters” as in some primitive operating systems; once the system is installed, it looks to the user that there is just one bunch of files; Unix will figure out the right thing to do. After the system has been installed and you’ve booted off the hard disk, log in and (this is important!) type man afterboot; it will remind of some things that you need to do to complete the installation — pick passwords, create user accounts, check network settings etc. Also, man hier will introduce you to the way the system is organised — which files live where. In fact, let me say that again:

After the first normal boot of the system, be sure to read these manpages:
$ man afterboot
$ man hier
Also run dmesg(8) to learn more about your hardware and the driver names that OpenBSD uses for them.

Which packages to install? A good starting point would be to accept the defaults. For a desktop system (workstation), you will want all the X11 packages also. I install everything.

There! And make sure you keep reading the manpages — OpenBSD manpages are a thing of beauty, complete, up-to-date and informative. And also read the OpenBSD FAQ on the web — much of this information is also found there.

Configuring the network
For my outside connection I have DSL and a static IP number (from Speakeasy — I recommend them over PacBell etc. — I’m so happy I switched). Other DSL options are PPPoE that PacBell likes to set people up with, or DHCP which is what you usually get over cable. A completely bogus DSL installation is the USB device they try to foist on customers with Windows. Danger, Will Robinson! They stink; they’re unsupported on any free O/S, and even on Windows they work about half the time.

In *BSD the network cards are named according to the driver used. For the Lite-On (DEC Tulip) cards, the driver is called dc, and the Intel EtherExpress Pro is fxp; so my two ethernet cards are dc0 and fxp0. (If you had two cards that both used the dc driver, they would be dc0 and dc1.) For the inside network I use the “private” (non-routable) IP numbers 192.168.1.* which will make the inward-facing network card 192.168.1.1. The OpenBSD initialization asks you for IP numbers for the two cards. Enter the appropriate ones – the IP number your ISP gave you for dc0, and 192.168.1.1 for fxp0. For PPPoE, the outside interface is tun0 and it will figure out its own IP address. If you’re supposed use DHCP on your DSL or cable connection, type in dhcp.

It is important to remember which network will be the outside and which the inside. If the two cards are identical, the easiest way is to look at the MAC number. Every ethernet card ever made has a unique ID called its MAC number. This will be printed on the card, usually as a sticker. When the kernel boots up, it will print the MAC numbers of each card it finds:

fxp0 at pci0 dev 9 function 0 “Intel 82557″ rev 0x0c: irq 11, address 00:02:b3:a0:3a:50
dc0 at pci0 dev 10 function 0 “Lite-On PNIC” rev 0×20: irq 10 address 00:a0:cc:55:ab:1c
So the card that has a MAC number ending ab1c is dc0; the other is fxp0. (If the two network cards you have are different types, as in this case, there’s no problem, of course. The kernel bootup messages is still be useful to tell you what names the system is using for them.)

(There’s some rule about where the cards are plugged in so which one gets number 0 and which no. 1, but I can never remember that.)

PPPoE
The beast! PPPoE is a pain in the ass but ISPs like it because it makes things simpler for them — they don’t have to maintain lists of IP numbers. Also, they can run a crappy service and keep dropping the connection and that’s ok, you’re expected to reconnect. It’s the Micros**t philosophy of “make something really crappy and expect people to just re-start the whole system a couple of times a day.” It’s a pain in the ass for us because its MTU is 1492 instead of 1500 which used to require changes on every machine inside the network — but now thanks to the “mssfixup” flag we don’t have to any more.

The files you will need to change for PPPoE all live in /etc/ppp/.

Configure system files
To set up the system, the files you will be editing are:/etc/rc.conf, /etc/myname, /etc/mygate, /etc/pf.conf, /etc/nat.conf, /etc/*.conf, /etc/hostname.interface, /var/named/*.

Edit /etc/rc.conf. On my servers I run SMTP, Apache, and ssh. In other words, from the outside it handles email, web acess and secure shell for remote logins. For convenience, on the inside I have a private name server (DNS) and NTP server for accurate time. To get sendmail, NTP, httpd, and NAT to work, these are the lines to change:

sendmail_flags=”-bd -q30m” # for normal use: “-bd -q30m”
named_flags=”" # for normal use: “”
ntpdate_flags=”put.server.here” # for normal use: NTP server; run before ntpd starts
httpd_flags=”" # for normal use: “” (or “-DSSL” after reading ssl(8))
dhcpd_flags=-q # for normal use: “-q”
pf=YES # Packet filter / NAT
ntpd=YES # run ntpd if it exists
pf_rules=/etc/pf.conf # Packet filter rules file
nat_rules=/etc/nat.conf # NAT rules file
Make sure that /etc/sysctl.conf has this line in it:

net.inet.ip.forwarding=1 # 1=Permit forwarding (routing) of packets
Get the names of NTP servers close to where you are and put that name in the ntpdate value. Here’s a list of public NTP servers.

Update ssh
Warning: ssh in OpenBSD 3.1 has a bug!
Upgrading openssh to 3.4 is strongly recommended. See the OpenSSH for OpenBSD page for details. In brief, you will download ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/openssh-3.4.tgz and execute the following steps (as root):

# cd /usr/src/usr.bin
# tar xvfz …/openssh-3.4.tgz
# cd ssh
# make obj
# make cleandir
# make depend
# make
# make install
# cp ssh_config sshd_config /etc/ssh
# mkdir /var/empty
Using vipw(8) you will add this line to your password file:

sshd:*:27:27::0:0:sshd privsep:/var/empty:/sbin/nologin
Then add this line to /etc/group:

sshd:*:27:
NAT and firewall rules
OpenBSD 3.1 has a new packet filter — 2.9 used ipf but 3.x has a re-written from scratch one called pf. The details are not important; pf config files are much simpler. I decided that my outside interface would be dc0, and the inside one fxp0. (If you’re using PPPoE, the outside interface will be tun0.) Firewall rules (they tell the gateway what kind of network traffic should be allowed into the internal network) live in /etc/pf.conf; NAT configuration is in /etc/nat.conf.

Here’s a sample /etc/pf.conf — very little is accessible from the outside, but machines on the inside can go out with no restrictions. In your files you’d replace dc0 and fxp0 with the names of your outward- and inward-facing ethernet cards, respectively.

#####################################################################
#
# IP packet filtering rules (firewall)
# Shamim Mohamed 3/2002

# See pf.conf(5) for syntax and examples

# If you change this file, run
# pfctl -R /etc/pf.conf
# to update kernel tables (also run “pfctl -e” if pf was not running)

# Network interfaces
internal = “fxp0″
external = “dc0″

# Services visible from the outside — remove any you’re not using
services = “{ ssh, http, https, smtp }”

# You shouldn’t need to change anything below this line
#####################################################################

# Non-routable IP numbers
nonroutable = “{ 192.168.0.0/16, 127.0.0.0/8, 172.16.0.0/12, 10.0.0.0/8,
0.0.0.0/8, 169.254.0.0/16, 192.0.2.0/24, 204.152.64.0/23, 224.0.0.0/3,
255.255.255.255/32 }”

# All rules are “quick” so go strictly top to bottom

# Fix fragmented packets
scrub in all

# Don’t bug loopback
#
pass out quick on lo0 from any to any
pass in quick on lo0 from any to any

# Don’t bother the inside interface either
#
pass out quick on $internal from any to any
pass in quick on $internal from any to any

#####################################################################
#
# First, we deal with bogus packets.
#

# Block any inherently bad packets coming in from the outside world.
# These include ICMP redirect packets and IP fragments so short the
# filtering rules won’t be able to examine the whole UDP/TCP header.
#
block in log quick on $external inet proto icmp from any to any icmp-type redir

# Block any IP spoofing atempts. (Packets “from” non-routable
# addresses shouldn’t be coming in from the outside).
#
block in quick on $external from $nonroutable to any

# Don’t allow non-routable packets to leave our network
#
block out quick on $external from any to $nonroutable

#
#####################################################################

#####################################################################
#
# Now the normal filtering rules
#

# ICMP: allow incoming ping and traceroute only
#
pass in quick on $external inet proto icmp from any to any icmp-type { \
echorep, echoreq, timex, unreach }
block in log quick on $external inet proto icmp from any to any

# TCP: Allow ssh, smtp, http and https incoming. Only match
# SYN packets, and allow the state table to handle the rest of the
# connection.
#
pass in quick on $external inet proto tcp from any to any port $services flags S/SA keep state

# Of course we need to allow packets coming in as replies to our
# connections so we keep state. Strictly speaking, with packets
# coming from our network we don’t have to only match SYN, but
# what the hell.
#
pass out quick on $external inet proto tcp from any to any flags S/SA keep state
pass out quick on $external inet proto udp all keep state
pass out quick on $external inet proto icmp from any to any keep state

# End of rules. Block everything to all ports, all protocols and return
# RST (TCP) or ICMP/port-unreachable (UDP).
#
block return-rst in log quick on $external inet proto tcp from any to any
block return-icmp in log quick on $external inet proto udp from any to any
block in quick on $external all

#
# End of file
#
#####################################################################
Read the pf documentation and understand these rules.

This is the NAT config /etc/nat.conf — this allows machines on the inside network to transparently make connections to the outside world:

#####################################################################
#
# NAT rules
# Shamim Mohamed 3/2002

# See nat.conf(5) for syntax and examples

# replace dc0 with external interface name, 192.168.1.0/24 with internal
# network (if different)

# nat: packets going out through dc0 with source address 192.168.1.0/24 will
# get translated as coming from 12.34.56.78 (or whatever the external IP no.
# is). State is created for such packets, and incoming packets will be
# redirected to the internal address.

nat on dc0 from 192.168.1.0/24 to any -> dc0

# End of file
#####################################################################
The system should already have setup /etc/hostname.dc0 and /etc/hostname.fxp0 (or whatever your network device names are) for you. Each file will have the IP number and netmask. This is what these files would look like:

$ cat /etc/hostname.fxp0
inet 192.168.1.1 255.255.255.0 NONE
$ cat /etc/hostname.dc0
inet 123.45.67.89 255.255.255.0 NONE
(The $ is the prompt; cat types a file out to the output.) If you’re using DHCP, the outside interface’s hostname file will say dhcp.

Other important files are /etc/myname — your hostname — and /etc/mygate — your default gateway to the outside world (your ISP told you what this should be — it’s usually the same as your IP number except that the last number is replaced with a 1 or 254.)

PPPoe
If you have PPPoE (you unfortunate soul!) things are different. You shouldn’t have /etc/mygate; and the file describing the outside interface, /etc/hostname.dc0 in my example, will only have one word in it: up. This tells the system to bring up the interface at boot time, but to do nothing else — pppoe will do the rest.

The main file is /etc/ppp/ppp.conf and this is what it should look like:

default:
set log Phase Chat LCP IPCP CCP tun command
set redial 15 0
set reconnect 15 10000

pppoe:
set device “!/usr/sbin/pppoe -i dc0″
disable acfcomp protocomp
deny acfcomp
set mtu 1492
set speed sync
enable lqr
set lqrperiod 5
set cd 5
set dial
set login
set timeout 0
set authname login
set authkey password
enable dns
enable mssfixup
Use your login name and password where indicated. The “set device” line tells ppp which physical device to use to talk to the outside world. You also have to tell the system to start PPPoE at boot time. That can be done with this little snippet of shell script:

echo -n “Trying to establish PPPoE DSL”; ppp -ddial pppoe
for i in 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0; do
sleep 5
echo -n.$i”
if /usr/local/sbin/adsl-status>/dev/null; then
break
fi
done
echo
/usr/local/sbin/adsl-status
Where adsl-status is a little shell-script that tests to see whether the PPP link has come up properly:

#!/bin/sh

IP=$(/sbin/ifconfig tun0 | awk ‘/netmask/{print $2}’)

if [ -z "$IP" ]; then
echo “ADSL link is down.”
exit 1
else
echo “ADSL is up, IP address $IP”
exit 0
fi
Now the question is: where should we put the little loop that tries to get ppp going? The right place to put all these is in /etc/rc.local. However this has the drawback that the outside network hasn’t been initialised while the rest of the system is coming up, which causes some scary-looking error messages from NAT to be printed at boot time. So I do something a little un-kosher: I put the ppp initialisation in /etc/netstart right at the end:

…
echo -n ‘ ADSL… ‘; ; ppp -ddial pppoe
for i in 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0; do
sleep 5
echo -n.$i”
if /usr/local/sbin/adsl-status>/dev/null; then
break
fi
done
echo
/usr/local/sbin/adsl-status
Now remember that each time the PPP link goes up or down, the IPF and NAT rules must be re-done. The files /etc/ppp/ppp.linkup and /etc/ppp/linkdown are scripts that get run by ppp. Here’s /etc/ppp/ppp.linkup:

MYADDR:
! sh -c “/sbin/route del default”
! sh -c “/sbin/route add default HISADDR -mtu 1492″
! sh -c “/sbin/pfctl -F all -R /etc/pf.conf -N /etc/nat.conf -e”
! sh -c “/usr/local/sbin/ntpd -p /var/run/ntpd.pid”
And this is /etc/ppp/linkdown:

MYADDR:
! sh -c “/sbin/pfctl -F all -d”
Configuring email
Sendmail should have been setup automatically since you edited /etc/rc.conf but I’ve occasionally had to make one change in /etc/mail/sendmail.cf:

Djmy-domain-name.com
(If you don’t own a domain, or plan on having it point to your DSL machine, you don’t need sendmail.)

You should have a normal user account that you’re going to use (never log in as root! Always use su or sudo). Administrative email should be forwarded to you; if your normal username is zippy edit /etc/mail/aliases and make sure you make the appropriate lines look like this:

# Well-known aliases — these should be filled in!
root: zippy
manager: zippy
dumper: zippy
One thing you should consider is being an email handler for friends. My DSL service goes down too often — every few months. This is too unreliable for my tastes. What I do is collaborate with friends to accept and queue email for them, and they do the same for me. Example: for my domain foo.com the primary mail exchanger is gateway.foo.com, the OpenBSD firewall/gateway. A friend of mine has bar.com, and his email gateway is gateway.bar.com. I set up a secondary mail exchanger in my domain records as gateway.bar.com. If my DSL line gateway.foo.com goes down and someone out there wants to send email to me at foo.com, her machine will use gateway.bar.com instead and email will wait on that machine until my machine is back on the network. I want to perform the same service for my friend — if gateway.bar.com is down, I want people to be able to send my machine the email destined for bar.com and fubar.org (another friend’s domain). This goes in the file /etc/mail/relay-domains on my gateway box:

bar.com
fubar.org
Now the machine will accept email for my friends’ domains bar.com and fubar.org as well as for itself and forward their messages on. If the machine it’s trying to forward to is down, it will put them in the queue and keep re-trying for a while. (My friend at bar.com does similar things to his /etc/mail/relay-domains.)

Setting up DNS
You probably shouldn’t be running the primary DNS server for your domain on your DSL box; DSL may not be reliable enough for that. Get someone else to do it for you for free, like http://www.zoneedit.com/.

However, it is nice to have a local private DNS because lots of daemons (services that run in the background, like the web server) like to do reverse lookups of IP numbers, so we should have a DNS server for the private network. Also, this installation will give you a caching nameserver which should improve your browsing speed.

The files live in /var/named. Assuming your domain is called fake-domain.org, edit named.boot and add these lines:

primary fake-domain.org fake-domain.db
primary 1.168.192.in-addr.arpa fake-domain.rev

; your static IP number, reversed
primary 89.67.45.123.in-addr.arpa dsl.rev

; remember to add your ISP’s nameservers here!
forwarders 1.2.3.4 5.4.3.2
(Anything starting with a semicolon is a comment.) Here fakedomain.org can be a real domain you have or a fake; and instead of 89.67.45.123 use your static IP but reversed i.e. you would use that line if your IP number were 123.45.67.89. And change the IP numbers on the forwarders line to the nameservers your ISP told you to use.

There are three files you need to create. The first is /var/named/namedb/fake-domain.db:

@ IN SOA gateway.fake-domain.org. root.fake-domain.org.
(
14 ; Serial
10800 ; Refresh
3600 ; Retry
604800 ; Expire
86400 ) ; Minimum

IN NS gateway.fake-domain.org.

gateway IN A 192.168.1.1
libelle IN A 192.168.1.2
discus IN A 192.168.1.4
ventus IN A 192.168.1.3
wander IN A 192.168.1.5
brad IN A 192.168.1.12
jack IN A 192.168.1.13

; your static IP number
dsl IN A 123.45.67.89

www IN CNAME dsl
mail IN CNAME dsl
In this network, there are six machines on the inside and those are their names and IP Number assignments. The OpenBSD gateway machine is named “gateway”. Change these entries to names of the machines on your private network. You can give them any IP number that starts with 192.168.1. Of course if you have three machines on your network, there will only by three entries.)

This is the second file you need to create, /var/named/fake-domain.rev:

@ IN SOA gateway.fake-domain.org. root.fake-domain.org.
(
14 ; Serial
10800 ; Refresh
3600 ; Retry
604800 ; Expire
86400 ) ; Minimum

IN NS gateway.fake-domain.org.

1 IN PTR gateway.fake-domain.org.
2 IN PTR libelle.fake-domain.org
3 IN PTR ventus.fake-domain.org
4 IN PTR discus.fake-domain.org.
5 IN PTR wander.fake-domain.org.
12 IN PTR brad.fake-domain.org.
13 IN PTR jack.fake-domain.org.
(Those trailing dots are important.) And here’s the third, /var/named/namedb/dsl.rev:

@ IN SOA gateway.fake-domain.org. root.fake-domain.org.
(
14 ; Serial
10800 ; Refresh
3600 ; Retry
604800 ; Expire
86400 ) ; Minimum

IN NS gateway.fake-domain.org.

IN PTR dsl.fake-domain.org.
PPPoE
Yes, again more stupid special cases for PPPoE. For one thing, your IP address from the outside keeps changing so all the stuff about dsl.rev doesn’t apply. However, more important: you don’t know what your ISP’s DNS servers are! And they could change which machines you’re supposed to use each time you connect! What you have to do is: connect “by hand” one time, and see which DNS servers you got. After ppp.conf has been written, you can run ppp -ddial pppoe and pray. If all goes well, ifconfig tun0 should show you two lines:

$ /sbin/ifconfig tun0
tun0: flags=11 mtu 1492
inet 63.201.32.40 –> 63.201.39.254 netmask 0xff000000
That means everything worked. Now look at /etc/resolv.conf — there should be one or more lines in there that say which nameservers should be used. Put these IP numbers in the forwarders line in /var/named/named.boot.

One other wrinkle: the /etc/resolv.conf that ppp makes for you doesn’t know about your domain, or that you’re running a nameserver on your machine. To get around these problems, I created another file /etc/resolv.conf-working:

nameserver 192.168.1.1
lookup file bind
search fake-domain.org
In /etc/ppp/ppp.linkup I tell it to overwrite the created resolv.conf with this one:

! sh -c “cp /etc/resolv.conf-working /etc/resolv.conf”
(Add that to the end of the file that you’ve already created.) This allows all programs running on the machine to be able to use all the good things about a local caching nameserver — things like being able to refer to internal hosts by short name etc.

Other machines on the internal network
Go to the other machines on your network (the ones inside your firewall) and set them up with the static IP numbers you assigned above, e.g. the machine wander gets an IP number of 192.168.1.5. All the machines should use 192.168.1.1 for the gateway and use 192.168.1.1 for the DNS server. For more details on DNS, read the excellent O’Reilly book “DNS and BIND”; for more on setting up slightly more complex DNS servers than the one described here, go to the OpenBSD — DNS site maintained by Samiuela LV Taufa.

Setting up DHCP
Above in the DNS setup all internal machines are assigned their own IP numbers. Running DHCP allows guest machines to hook up to the network without fuss. Depending on your comfort level with setting up your other machines, you might also prefer to use DHCP over assigning static IPs.This is what /etc/dhcpd.conf should look like:

# $OpenBSD: dhcpd.conf,v 1.1 1998/08/19 04:25:45 form Exp $
#
# DHCP server options.
# See dhcpd.conf(5) and dhcpd(8) for more information.
#

# Network: 192.168.1.0/255.255.255.0
# Domain name: my.domain
# Name servers: 192.168.1.3 and 192.168.1.5
# Default router: 192.168.1.1
# Addresses: 192.168.1.32 — 192.168.1.127
#
shared-network LOCAL-NET {
option domain-name “fake-domain.org”;
option domain-name-servers 192.168.1.1;

subnet 192.168.1.0 netmask 255.255.255.0 {
option routers 192.168.1.1;

range 192.168.1.32 192.168.1.127;
}
}
This will allow up to 96 machines on your internal network, which should be more than sufficient. Create an empty temporary file for dhcpd to use:
# touch /var/db/dhcpd.leases
If you make any changes to this file, run dhcpd fxp0 (or whatever your inside network is). (Or you can reboot the machine — but that’s the Windows way, in the Unix world we prefer to never reboot any machines.)
Install “ports”
“Ports” is a *BSD term for a tree of Makefiles for all the software out there that’s not part of the standard install. I recommend this highly. It is on CD No. 3 of the OpenBSD 3.1 CD-ROM set as ports.tar.gz. Please read the Ports and Packages page on the OpenBSD web site. You install it by typing (as root)

# mount /dev/cd0a /mnt
# cd /usr
# tar xzf /mnt/ports.tar.gz
Once you’ve done this, if you want to install a package, you cd to the appropriate directory and simply type make all install — it will ftp the source from the appopriate site, handle all dependencies, apply any required patches, configure, build and install the tool.

How do you find the appropriate directory to go to? You can guess at where it might be (look around in /usr/ports to get an idea for the layout etc.). But remember: locate(1) is your friend.

If you have the disk space (about 500 MB), I strongly recommend that you install the source code to the system also. (The source is also on CD No. 3.)

# mount /dev/cd0a /mnt
# cd /usr/src
# tar xzf /mnt/src.tar.gz
Getting time from the Internet
Set up NTP so that your machine will always have accurate time. Pick two servers from the public NTP server list and make sure /etc/ntp.conf looks like this:

server ntp.server.first
server ntp.server.second
Since xntpd is not part of the standard install, you have to compile xntpd from source.

# cd /usr/ports/sysutils/xntpd
# make all install
The tools will be installed into /usr/local/sbin/ntpd.

Run ntpdate -b server where you pick a server from the list — this will perform a coarse adjustment of the system clock. The next time the machine reboots, it will sync your clock and record how much your clock drifts.

Setting up other hosts with NTP
On Unix hosts, use the appropriate NTP client; on Linux, it’s xntpd. Set them up to use 192.168.1.1 as the NTP server. On Windows, use AboutTime — a free NTP client. In its configuration make sure it uses only SNTP as the protocol, with 192.168.1.1 as the server. Put AboutTime in the Startup folder so it’s started automatically.

For more details, go to Robert Mooney’s OpenBSD NTP site.

Tips and Stuff
I have a useful shell script called pkg_install that’s a front-end to pkg_add — here’s an example of it being used:
# pkg_install tex
These files match:
gettext-0.10.40.tgz
jadetex-3.11.tgz
latex2html-97.1.tgz
php4-4.0.6p1-gettext-imap-mhash-no_x11-mcrypt-mysql.tgz
php4-4.0.6p1-gettext-imap-mhash-no_x11-mcrypt-postgresql.tgz
php4-4.0.6p1-gettext.tgz
teTeX_texmf-1.0.2.tgz
texi2html-1.64.tgz
textutils-2.0.tgz
# pkg_install -n 4 texi
Using ftp5.usa.openbsd.org/pub/OpenBSD
+ pkg_add -v ftp://ftp5.usa.openbsd.org/pub/OpenBSD/3.1/packages/i386//texi2html-1.64.tgz
Trying to fetch ftp://ftp5.usa.openbsd.org/pub/OpenBSD/3.1/packages/i386//texi2html-1.64.tgz.
Extracting from FTP connection into /var/tmp/instmp.BVMJM29414
>>> ftp -o — ftp://ftp5.usa.openbsd.org/pub/OpenBSD/3.1/packages/i386//texi2html-1.64.tgz
…
It has a list of all the pre-compiled packages that are available. You type in a string and it installs the package. If more than one name matches, it shows you their names. (It uses egrep(1) so you can use regular expressions.) Save it to /usr/local/bin. It handles dependencies by recursively installing them also.

New in this version is in -n flag. The script has a list of mirrors, and this option picks one of the mirrors. (Currently in progress: it needs bash, and it needs some error checking but it works.) Don’t forget to edit the file — read http://www.openbsd.org/ftp.html and choosea list of mirrors closest to you.

Setting up a CVS server
(This section is probably not of interest to most people; you only need this if you want to set up a cvs server so you can put files you’re working on under source control. So it’s a little terse too.)

The changes I made: added a user and group named cvs. All users of CVS should be in the cvs group. Create a directory for the repository: I put it in /var/cvsroot, you might put it in /home or wherever. This directory should be group writable (group cvs). Add a line to /etc/services:

cvspserver 2401/tcp # CVS pserver
Add this line to /etc/inetd.conf:
cvspserver stream tcp nowait root /usr/bin/cvs cvs -f –allow-root=/var/cvsroot -T /var/tmp pserver
The server uses /var/tmp as its temp directory instead of /tmp since my root partitions are small, but I always make /var large. Now run cvs init in the cvs repository and restart inetd. Voila! Import your directory of files from a client machine, using a pserver CVSROOT and cvs import.

When importing a large set of files, you might want to put a .cvswrappers file in the directory you’re importing so CVS won’t try to put RCS ID strings inside your JPEG files etc. The syntax is:

*.jpg -k ‘b’
*.png -k ‘b’
*.tgz -k ‘b’
Coming soon: using ssh for CVS_RSH.
Setting up X11
You did select the packages xbase, xshare, xfont, and xserv when you installed OpenBSD, I hope? If not, never fear; you can install them directly off the CD:

# mount /dev/cd0a /mnt
# cd /
# tar xzvpf /mnt/3.1/i386/xbase31.tgz
# tar xzvpf /mnt/3.1/i386/xserv31.tgz
# tar xzvpf /mnt/3.1/i386/xshare31.tgz
# tar xzvpf /mnt/3.1/i386/xfont31.tgz
etc. The X11 package for ix86 systems is called XFree86; visit their website for more information. Now run xf86cfg. (If the command is not found, you probably don’t have /usr/X11R6/bin in your PATH environment variable.) Of course this is not something you can do over a network login; you have to be sitting at the machine, with a monitor, keyboard and mouse actually plugged in. You should have your video card and monitor specs available. Follow the instructions to setup XFree86. More information is on the Configuring XFree86 page on the Xfree86 site.
Installing a Desktop
Many people also install a desktop suite such as KDE or Gnome. I prefer KDE of the two. There is nothing special about KDE (or Gnome); it’s just a set of packages to be installed. There are two versions of KDE available, KDE 2.2 and KDE 3.0. Decide which one you want to run, and install those packages. (KDE2 and KDE3 cannot co-exist on the same system.)

These are the KDE2 packages:

$ pkg_info -a | egrep kde
kdelibs-2.2.2 X11 toolkit, libraries
kdeartwork-2.2.2 X11 toolkit, additional artwork
kdegraphics-2.2.2 X11 toolkit, graphics applications
kdelibs-doc-2.2.2 X11 toolkit, libraries documentation
kdebase-2.2.2 X11 toolkit, basic applications
kdenetwork-2.2.2 X11 toolkit, network applications
kdetoys-2.2.2 some useless kde applications
And for KDE3, the corresponding packages are:
kdeaddons-3.0.tgz
kdeartwork-3.0.tgz
kdebase-3.0.tgz
kdeedu-3.0.tgz
kdegames-3.0.tgz
kdegraphics-3.0.tgz
kdelibs-3.0.tgz
kdenetwork-3.0.tgz
kdetoys-3.0.tgz
kdeutils-3.0.tgz
koffice-1.1.1-kde3.tgz
There are lots of I18N packages also, kde-i18n-*-3.0.tgz.
Display managers xdm and kdm
You may want to run a display manager like xdm or kdm. (A display manager is the program that gives you a graphical login display instead of a plain text message.) The config file for kdm is /usr/local/share/config/kdm/kdmrc; the xdm config file lives in /etc/X11/xdm/xdm-config. Edit /etc/rc.conf and set xdm_flags to an empty string (in quotes) to make xdm run on startup. (If you installed KDE, it will be kdm that’s started.) If you installed KDE3, add it to the list of available logins in kdmrc: in the [X-*-Greeter] section, look for the SessionTypes line and add “KDE3″ to the list.

Setting up XDMCP
If you have an X-Terminal (like the Sun Ray, or the ones NCD used to make) or run eXceed on Windows platforms, you may want to allow X11 logins to your OpenBSD machine from eXceed or the X-Terminal. The protocol that allows this is called XDMCP; to enable it: if using xdm, edit /etc/X11/xdm/Xaccess and remove the ‘#’ from the first column of this line:

#* #any host can get a login window
Note: we don’t allow any X11 or XDMCP messages to go across our firewall. Only hosts inside the firewall can get a login screen.
Also edit xdm-config and comment out this line by putting a ‘!’ character in the first column:

DisplayManager.requestPort: 0
If using kdm, edit /usr/local/share/config/kdm/kdmrc and look for the [Xdmcp] section. Uncomment lines so it looks like this:
[Xdmcp]
# Whether KDM should listen to XDMCP requests. Default is true.
Enable=true
# The UDP port KDM should listen on for XDMCP requests. Don’t change the 177.
Port=177
(followed by other stuff.)
Amusements
People like to do things like rip CDs to Ogg Vorbis or MP3 and listen to those files. I use grip as a front-end to rip music to Ogg Vorbis files, and xmms (package name xmms-vorbis) to listen to them. I use Gnu LilyPond and TeX/LaTeX (package teTeX_texmf) to typeset documents and music. The LaTeX files can be converted to HTML with latex2html. You can run Linux programs if you install the redhat_base, redhat_motif, and rpm packages. (The Linux version of Opera, the web browser, runs fine.)

PPPoE Gateway
PPPoE is a curious beast forced down our throats by some DSL providers. On one side, it does not really break anything, has low overhead and allows you to change IP adresses very easily & quickly. On the other side, it sucks big time because it does add overhead to the IP packets, is proprietary, non-standard, forces you to change IP adresses unpredictably, and is unsupported in most operating systems. A good PPPoE gateway simply hides PPPoE from the machines on your internal network. It makes life much easier because you don’t have to install any special “access manager” software on your windoze boxen. They will just work (provided you set their IP address correctly).

Firewall
A firewall is quite mandatory for any machine directly connected to the Big Bad Internet. We want an industrial-strength stateful inspection firewall and this is what we’ll get.

NAT (Network Adress Translation)
The name seems complex, but it is really quite simple: this allows the gateway machine to act on the internet on behalf of all the machines located on the intranet (your internal home network). Even though you might have two, three or even ten computers on your local network, a NAT equipped gateway will hide them to outside observers. They will only see a single very busy machine, with a single IP address.

DNS (Domain Name Service) cache
Having your own DNS server will lower the latency of getting DNS translations for all the machines on your intranet. This will not really decrease the traffic on your DSL modem by a large percentage, but it will improve the quality of the “internet experience” on your local network.

Dynamic DNS tracker
Free dynamic DNS services are extremely useful to xDSL customers. They allow you to have your very own domain name, free of charge, which will follow in real-time your IP address changes. The catch is that the top-level part of your domain must be one of their supplied choices. They are not that bad, really… Personally, I use DYNDNS but any of the multiple free dynamic DNS providers out there will do just fine. Simply make sure they have a client “updater” which can compile and run under OpenBSD.

WEB server
Most ISP’s only allow a few megabytes of disk for web service. Moreover, they never give you direct access to the web logs. Having your own web server allows you the luxury of using all the disk space you want, plus the added advantage of complete control over the web service (cgi-bin) and its logs. Moreover, OpenBSD comes with a crypto-enabled version of Apache and all the tools you need to create RSA-keyed certificates.

Mail server
Have you ever wanted to create a temporary email address just to receive some password? Or simply wanted addresses tailored for specific domains of interest? These are only a few of the many advantages of having your own mail server.

NTP server
The Network Time Protocol allow you to synchronize the gateway’s clock to one of the numerous atomic time references available on the internet. Moreover, the same program is also used as a local time server, so that all your intranet machines can themselves synchronize their clocks to the gateway’s clock. NTP synchronizations are made in tiers, like this, in order to lower the burden on the public time servers.

This page is for all those of you who have are lucky enough to enjoy a dedicated xDSL connection and would like to have a small firewall installation. In my search for the holy grail, i found the answer to most of my wishes in the OpenBSD package. This step-by-step guide is a collection of notes taken while I was installing the thing. They are intended to help my friends do their own setups very quickly and easily, without having to bug me too much They should help you too.

Constructive comments can be sent there … Have fun and GOOD LUCK!

Getting some hardware
The first thing to think about when one embarks on the firewalling adventure is to establish on what hardware you are going to install the thing. This seems unimportant at first, but don’t forget that this box will be turned on 24/7, so the components you use must be reliable.

What are the minimum requirements? My system uses about 50% of its CPU to support Sympatico’s ADSL rate (around 900 kbps). It is built with the following components:

An ancient 486 motherboard (with an ISA bus) given to me by a friend (thanks Christian!). It runs at 66 MHz.
32 MB of brand new RAM i bought for it.
A 200 MB hard disk, which was dying after about 1 year of faithful use (it came with the motherboard). This disk was recently replaced with the cheapest brand new drive i could find. I didn’t know they still made those slow 3600 RPM drives Anyway, the old drive is kept as a kind of extreme emergency backup.
Two ISA-bus ethernet cards. I’ll talk more about this later.
A CD-ROM drive. Very optional, but can make life easier.
A “home” grade hub & cat5 cabling. This is not strictly necessary if you’ll have only one machine connected to your firewall: you can make do with a special “crossover” cat5 cable instead. The cable that comes with xDSL modems is usually (always?) a crossover cable. Anyway, for two or more machines, the hub is mandatory. Small hubs can be bought for a very reasonable price (~40$ cdn).
or
Alternatively, many older ethernet cards come with a BNC female connector. This can be used to connect the machines on your network with coax cables, without any hub. However, be warned that a 10base-2 network must follow certain rules if you want it to work flawlessly. Follow them.
This gives a good approximation of what you need. The MOST important part is the RAM. Make absolutely sure that whatever RAM you use is reliable. Old boxen were usually setup to run Windoze, and it was not a big deal if the machine had flaky RAM because of the way Windoze works…

OpenBSD (like any real OS out there) is much less tolerant of flaky RAM, because it actually uses all of it. It will crash quite quickly if your RAM is marginal, probably within 5-10 minutes. You have been warned.

Finally, the OpenBSD hardware list is there. Try to make sure that whatever hardware you use in your gateway box figures on that list. It’s a long list

The ethernet cards
There is a boring thing of which we must talk about here. You see, there are many kinds of ethernet cards, and you must make sure you have the right ones for your machine. If you have a PCI-based machine, then all is well. Whatever ethernet card you put in there will probably be supported by OpenBSD. However, you must be a bit more careful if you have an ISA-based machine.

It is most likely that your box will not have any ethernet cards to start with since most people did not have networks at home in the pre-historic era of 4 years ago. You need two cards. One will be connected to the DSL modem (the big, bad outerworld), while the other is connected to your internal network hub (your intranet). The gateway’s job will be to pass (or block) packets between those two network cards. For security, its very important that the outside world packets cannot reach directly any of the intranet machines. This is the reason why we use two ethernet cards: complete logical and electrical isolation. Why so much isolation? For example, if someone(s) were launching a full (distributed or not) denial of service attack on your gateway box, its internet-connected ethernet card would be extremely busy, but your intranet would see nothing of this. While any communication with the outside world would probably fail, at least your intranet machines would still be able to talk to each other.

ISA cards use dedicated I/O ports and IRQ’s in your machine. Those must be setup either with jumpers directly on the card, or with a special DOS program if the card is of the more recent “Plug & Play” type. This DOS program is always supplied with the card, when purchased brand new.

If your card is Plug&Play, you must disable the Plug&Play, and program specific I/O port and IRQ values with the setup software that comes with the card. Make sure that you program both cards with different sets of I/O ports and IRQs! Otherwise they will battle each other for cycles on the bus and the result will not be pretty. Once you have set the parameters on the card it will remember them and you don’t have to reprogram anything later on, even if the computer is turned off.

It is good at this point to know a few magic numbers:

Card Type I/O #1 IRQ #1 Mem #1 I/O #2 IRQ #2 Mem #2
NE2000 (ne) 0×240 9 — 0×300 10 —
SMC WD-8003 (we) 0×280 9 0xd0000 0×300 10 0xcc000

For example, i use two cards made by AOpen: the model ALN-101. They are Plug&Play and use the NE2000 chip. The first one is setup at I/O port 0×240, IRQ 9. It is known as “ne0″ in the GENERIC openBSD kernel. The second one is set at I/O port 0×300, IRQ 10. It is known as “ne1″. If the cards were programmed differently, the GENERIC kernel would not recognize them “out of the box” and you would have to re-configure the kernel. It can be done, but its much easier to setup the hardware once than re-configure the kernel every time it gets upgraded.

Some of you might have problems setting the card to an arbitrary combination of IO port and IRQ number. This is allright, just let the card decide what it wants and simply reconfigure your kernel to accomodate that. What is important is that both ethernet cards are not set to conflicting values. Otherwise, any combination that the cards like will be programmable in the kernel.

Last but not least: some cards can be used in the so-called “full-duplex” mode. Be aware that if you want to use an ethernet card in full-duplex, your hub must also be full-duplex, as well as the other ethernet cards in the system. A full-duplex hub is much more expensive and not necessary at all. Unless you know what you are doing, program your ethernet cards to use the half-duplex mode, otherwise it won’t play nice with the other components in your local network, including the xDSL modem
(注，这里需要说NE2000等旧款的基于486机的网卡也可以用，但现在这些网卡，其本难找，所以至少要用8139系列芯片的10-100M自适应的网卡来做应用）

The hard disk
The most secure storage medium is one which can’t be erased. Some firewalls actually use setups like this (with CD-ROMS) but we’ll build our firewall with a classic, writeable hard drive because:

We don’t need “Absolute Security”, do we? We can’t have it anyway
We want to use an “out-of-the-box” OpenBSD distro. This will make maintenance (security, patches, etc…) much easier.
Almost any hard disk out there will work OK, since 200 MB is a safe minimum size. The only thing you must remember is that this disk will run 24/7, so if you use an old drive, it will likely die relatively soon. The venerable drive my friend gave me lasted 6 months before i had to change it, YMMV.

No keyboard?
Of course you’ll need a keyboard… and a monitor too, but just for the installation. After the firewall is successfully installed, you will be able to talk to it through encrypted ssh connections over your internal network, so a keyboard & monitor will not be really useful at that point.

——————————————————————————–

Getting the software
We will be using OpenBSD. Why? Because it is the most secure freely available operating system out there. All the source code included in the mainstream distribution CD’s has been audited for years by the OpenBSD team, which is why sometimes an exploit published on BugTraq is found not to work on OpenBSD simply because the faulty code was already fixed months ago.

I strongly suggest you buy their CD-ROM kit as it comes with a set of very cool stickers… You can also download their stuff for free, of course, but you won’t have the stickers then

This Guide is written for OpenBSD 3.0.

The easiest way to install the software is to use a CD-ROM drive on your firewall box. If you don’t have that, you can do a network install with the “ftp” protocol, either directly to an outside OpenBSD mirror, or to one of your own internal machines equipped with an ftp server. Be aware that if your DSL provider forces you to use PPPoE (boooo!), then of course your link to the outside world will not be functional yet at installation time, which is one more reason to use the CD-ROM. If your machine can boot a CD-ROM, great! It will gladly boot the OpenBSD disc. Otherwise, simply create a boot diskette according to the README and boot that. This diskette is also your rescue disk, so don’t lose it.
——————————————————————————–

Installing OpenBSD
The installation of OpenBSD is very easy, once you have the right hardware, and the right answers to some of the questions. In the following steps, i’ll assume you can follow the instructions of the install program and focus only on the tricky little things you should know to make your life easier.

fdisk & disklabel
After you boot the installer, one of the very first things you’ll have to do is partition your disk. This is done with the “fdisk” and “disklabel” programs. The installer will ask you if you want to use the entire hard disk for OpenBSD. Answer No, even if it is not entirely true. If you say yes, the whole fdisk step will be bypassed, and you will not be able to change the default cylinder/head/sector configuration in order to boot off the hard disk without resorting to the silly “FDISK /MBR” DOS command which is a stupid solution to a stupid problem.
The default OpenBSD fdisk partition setup choice is in slot #3. If you want, you can move your OpenBSD partition in slot #0 with no ill effect.

Important: On some systems, to make sure your system boots off the hard disk, you must set the starting CHS (cylinder/head/sector) to C=0, H=0, S=1, because fdisk suggested an incorrect value for H in OpenBSD 2.7, and still does in 2.8 … If you use “1″, as it suggests, your system will not be able to boot from the hard disk.

After the disk is partitioned with fdisk, you use disklabel to further organize the partition. A label behaves like a traditional partition (as used in Linux, for example), except that you can put as many labels as you want in the single OpenBSD partition. This is useful.

On a fully partitioned system, the disk labels might look like this:

a: 2097648 0 4.2BSD 1024 8192 16 # / 1 GB
b: 262080 2097648 swap # SWAP 128 MB
c: 20015856 0 unused 0 0 # (whole disk) 10 GB
d: 2097648 2359728 4.2BSD 1024 8192 16 # /usr 1 GB
e: 2097648 4457376 4.2BSD 1024 8192 16 # /tmp 1 GB
f: 2097648 6555024 4.2BSD 1024 8192 16 # /var 1 GB
g: 4194288 8652672 4.2BSD 1024 8192 16 # /usr/local 2 GB
h: 7168896 12846960 4.2BSD 1024 8192 16 # /home 3 GB
On my firewall, i like to keep things simpler, so it goes like this:

# size offset fstype [fsize bsize cpg]
a: 18874800 0 4.2BSD 1024 8192 16 # (Cyl. 0 – 18724)
b: 1141056 18874800 swap # (Cyl. 18725 – 19856)
c: 20015856 0 unused 0 0 # (Cyl. 0 – 19856)As you see, the ‘c’ label is a placeholder for the whole disk, in all cases. Don’t delete or otherwise change this, or you’ll be in trouble.

One of the main disadvantages of having a single partition is that one could do bad things in such quantity that the log files would simply fill up the whole drive. OpenBSD doesn’t like it when all its disk space is full. You can guess the rest of the story. In practice, this is not an issue, since i monitor my log files daily, but it could be an issue for someone out there.

On a fully partitioned system, the “df” command says this, after the OS is installed, with its complete source trees:

Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/wd0a 1015269 25985 938521 3% /
/dev/wd0d 1015269 480284 484222 50% /usr
/dev/wd0e 1015269 1 964505 0% /tmp
/dev/wd0f 1015269 5141 959365 1% /var
/dev/wd0g 2030307 8698 1920094 0% /usr/local
/dev/wd0h 3470505 27 3296953 0% /home

On my system i have this:

Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/wd0a 9137589 503054 8177656 6% /

In this example, the full OpenBSD source tree is installed, which explains why the thing uses up about 500 MB. Without the source tree, you only need about 120 MB in there, but having the source tree allows you to make security patches as they are published. This is important and i’ll talk about it more later.

Active FTP
If you do an FTP install to a private FTP server, it might be necessary to use active FTP.

Crypto, SSL, etc…
The crytographic packages are included in the CD’s since release 2.9 of OpenBSD. They will be automatically installed.

UTC time zone
Keep your server in the UTC time zone. This way, your firewall logs will be timestamped in UTC time and it will be simpler to have them interpreted by the abuse@… services of ISP’s. Also, it is important to make sure the gateway is time-synchronized to one of the numerous public NTP servers out there, because having only an IP address is not enough to pin down internet abusers. In this age of dynamic IP allocations you need both IP address and exact time in order to positively identify the origin of an IP packet. Keep your gateway synchronized.
Why not GMT instead? Read all about it there.

Normally, the installer will ask you for a time zone at install time. If you want to change it later, simply make /etc/localtime point to /usr/share/zoneinfo/UTC with a soft link:

ln -s /usr/share/zoneinfo/UTC /etc/localtime

First Boot
reboot … did your machine boot correctly? If not, please consult the numerous FAQ’s available at the OpenBSD site. Are you sure you set H=0 in fdisk? By the way, if it doesn’t boot from hard disk, you can probably still force it by first booting the install diskette, and entering “boot wd0a:/bsd” at the initial prompt. You have about 5 seconds to make your mind, when you see this prompt, act swiftly.
On first boot, you will probably get a message like “ssh-keygen: generating new DSA host key…”, followed with an equivalent message for the RSA host key. They might take quite a long time on a 486 (5-10 minutes), so Don’t Panic! ™ , the machine is not crashed, and the boot process will eventually follow its course, given time. This will happen only on the first boot.

Kernel extra configuration
If, at this point, the kernel sees all you devices (including both ethernet cards), congratulations. If not, you can reconfigure the kernel without having to recompile it by simply using the config utility. Typically, you would copy your current kernel (the “/bsd” file) to an appropriate backup name (e.g. “/bsd.ORIGINAL”), and issue this command:

config -e -f /bsd
and make whatever changes you need. You should know what you’re doing in order to use this command without blowing your system up into tiny bits & pieces. Don’t forget to save your changes. If this modified kernel doesn’t work OK, just boot the “/bsd.ORIGINAL” kernel instead, and you will have another chance.

Sys control files
The services allowed by OpenBSD are configured by a couple of files in the /etc directory. Actually, this directory contains all the configuration files of OpenBSD, for your convenience, but this is something you’ll only appreciate later, when you become an experienced BSD maintainer… We’ll come back to that /etc directory quite often.
For now, just make sure that the following are enabled:

In the file /etc/sysctl.conf:
net.inet.ip.forwarding=1

and in /etc/rc.conf:
sendmail_flags=”-L sm-mta -bd -q30m”
named_flags=”"
httpd_flags=”-DSSL”

Important: If you plan to use PPPoE, don’t enable pf here because you want to start it in a controlled manner, after PPPoE is started. Enabling “pf” here would make it start at the very beginning of the boot process and this would not work.

PPP & PPPoE
Ahhhh… the Evil Beast. Installing a good, working PPP and PPPoE can be quite a tricky task. In OpenBSD 3.0, it is included and works well, once properly configured. This version of PPP supports the “mssfixup” instruction which magically allows you to avoid setting MTU’s at 1492 or less on all of your intranet’s machines. This is very recommended as it avoids a whole bunch of problems with Windows machines, internet appliances, etc…
Notice that there is an excellent Network FAQ available from the OpenBSD site. It contains a lot of information on what to do with those ethernet adapters.

The configuration file for ppp is in /etc/ppp/ppp.conf. Mine contains exactly this:

default:
set log Phase Chat IPCP CCP tun command
set redial 15 0
set reconnect 15 10000

pppoe:
set device “!/usr/sbin/pppoe -i ne0″
disable acfcomp protocomp
deny acfcomp
set mtu max 1492
set speed sync
enable lqr
set lqrperiod 5
set cd 5
set dial
set login
set timeout 0
set authname xxxxxxx
set authkey xxxxxx
add! default HISADDR
enable dns
enable mssfixupNotice how we specify the real network interface ne0 to pppoe (with double quotes), and that i use “max 1492″ for the MTU value, as suggested by many people. Also, no value is specified for the MRU, the PPP network address translation is not enabled, the magic “mssfixup” is enabled and i use the “add!” command instead of plain “add” (suggested by Chris Pockele).

Also notice that the authname and authkey fields don’t contain double-quote characters. You should put in there your own ISP identification and password. Some ISPs require authname to have a full identification (e.g. “username@sympatico.ca”), while other ISPs will want to have only “username” in the authname field. Experiment.

Robert Jameson (thanks Robert!) reports that some ISPs require you to specify the pppoe service you want. This is done on the “set device” line. For example:

set device “!/usr/sbin/pppoe -n Shasta_1 -i ne0″

VERY IMPORTANT!

For some reason, the routes setup automatically by ppp at linkup time were not correctly defined prior to OpenBSD version 3.0. The MTU’s were wrong, leading to all sorts of subtle problems. This is now fixed, and we can safely use the “add default HISADDR” command in the ppp config file, with no special route commands at all in the ppp.linkup file. The MTUs will be properly set to 1492 on all the routes which go through the external interface.

The command “netstat -rn” confirms this:

pcreal# netstat -rn
Routing tables

Internet:
Destination Gateway Flags Refs Use Mtu Interface
default 65.92.185.1 UGS 3 13423 1492 tun0
65.92.185.1 65.92.185.97 UH 1 0 1492 tun0
127.0.0.1 127.0.0.1 UH 1 1045 33224 lo0
192.168.1/24 link#2 UC 0 0 1500 ne1
192.168.1.1 0:e0:18:90:a7:c7 UHL 3 10475 1500 ne1
…

A friend from Australia (thanks Doug!) suggested i clarify the following points:

(1) The 64.229.x.x adresses will NOT be the same in your setup! Those are the adress blocks of my PPPoE service provider (Sympatico). Your own setup will use, most likely, different address blocks.

(2) The ppp daemon creates a virtual network interface (“tun0″) out of thin air. This virtual network interface is internally linked to the actual physical interface (“ne0″ in my system), but you will never have to deal directly with “ne0″ in your configuration files. For example, the firewall rules are written with the virtual “tun0″ interface, not the physical “ne0″ interface. In my setup, the internal interface is “ne1″, and the external interface is “tun0″. Here is Doug’s analogy with the Windows world:

“… think of the PPPoE adaptor like the dialup adaptor in a Windows
control panel. it doesn’t really exist but you gotta have it…”(3) The ppp daemon takes care of automatically assigning the name servers and the routes. Consequently, make sure there is no file “/etc/mygate”, and bear in mind that “/etc/resolv.conf” will be automatically generated as well, at connection time. This has the advantage that you don’t need to know anything about the details of your connection (name server adresses, etc…) to your ISP. Your user ID and password are sufficient, as the ppp daemon will negociate with the server and obtain the information it needs to open the connection.

(4) Since the ppp daemon will take are of the external network interface, you don’t need a “/etc/hostname.ne0″ file. However, you do need a file to describe your internal network interface (in my case, “ne1″):

pcreal# cat /etc/hostname.ne1
inet 192.168.1.2 255.255.255.0 NONENormally, this file should have been built by the setup program of OpenBSD, but if not, you must manually put it there and replace the “192.168.1.2″ with whatever address you want your gateway to have as seen from your internal network.

Another friend, from France (thanks Xavier!), sent me this ascii picture of the network connections:

| |
internet| ====> |DSL Modem| ====>|server|=====>|LAN (HUB)
| tun0 ne1 |
| =ne0 |

Note: I consider this PPP/PPPoE setup to be a work in progress. I continually discover new things about it… so, please bear with me and do send me your feedback about your own experience regarding PPP/PPPoE. It really is a pain, but apparently we will be stuck with it for a long long time, so we might as well learn how to tame the thing!

Second Boot
reboot … your machine should boot correctly. You won’t have internet access yet because the ppp program is not activated. If you want to try it out, just issue

ifconfig ne0 up
ppp -ddial pppoeand ping/telnet away. Don’t worry if you get “carrier settings ignored”, or “change route failed” messages. Be careful because at this point you have no firewall rules set, so you are very vulnerable. Also, make sure your xDSL modem is plugged in the correct ethernet card…

If all works well, then you should kill the “ppp” process. Only restart it when the firewall rules are in place.

The afterboot phase
Follow the instructions obtained by issuing the “man afterboot” command. Actually, quoting FAQ section 2.3, here is a list of the most useful man pages for new users:

* [15]afterboot(8) – things to check after the first complete boot
* [16]boot(8) – system boot strapping procedures
* [17]passwd.conf(5) – format of the password configuration file
* [18]adduser_proc(8) – procedure for adding new users
* [19]adduser(8) – command for adding new users
* [20]vipw(8) – edit the pass word file
* [21]man(1) – display the on-line manual pages
* [22]sendbug(1) – send a problem report (PR) about OpenBSD to a
central support site.
* [23]disklabel(8) – Read and write disk pack label.
* [24]ifconfig(8) – configure network interface parameters.
* [25]route(8) – manually manipulate the routing tables.
* [26]netstat(1) – show network status.
* [27]reboot, halt(8) – Stopping and restarting the system.
* [28]shutdown(8) – close down the system at a given time.
* [29]boot_config(8) – how to change kernel configuration at boot

One of the first things you should do at this point is to add an unprivileged user and make him member of the wheel group. This is because, for security reasons, it is never a good idea to log in directly as root. The preferred way to gain root privileges is to login as a wheel member, and then use the “su -” command to gain root privileges.

OpenBSD will not prevent you from logging in directly as root, but will warn you every time against doing it.

Have fun!

Firewall and NAT rule sets
This is a tricky one. Many people earn a good living just by knowing how to write firewall rule sets! Moreover, the whole packet filter and NAT code was completely rewritten from scratch in OpenBSD 3.0. It is now called “pf”, and is completely free of any external licensing strings so we will always have the latest, fully audited versions in future OpenBSD releases.
Here are my own pf rules, in all their glory. They were heavily influenced by the various man pages and HOW-TO’s pertaining to “pf”. Be aware that they might be either too restrictive, or not enough, depending on your context. My philosophy about this is to disallow everything by default, and only open whatever is known to be useful. This restrictive ruleset will prevent ftp from working correctly, from the firewall itself. However, the ftp proxy currently available will work correctly for client machines located on the intranet.

Don’t forget to send me your tips for better rules… Thanks!

/etc/nat.conf
nat on tun0 from 192.168.1.0/24 to any -> tun0
rdr on ne1 proto tcp from any to any port 21 -> 127.0.0.1 port 8081

/etc/pf.conf
#————————————————————————–
# PF ruleset, 11 dec. 2001
#
# Liberally adapted from the pf man page, the OpenBSD “Network How-To”,
# and my own rulesets.
#————————————————————————–

#————————————————————————–
# Definitions
Ext = “tun0″ # External interface
Int = “ne1″ # Internal interface
Loop = “lo0″ # Loopback interface
IntNet=”192.168.1.0/24″ # Internal network

NoRoute = “{ 127.0.0.1/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8, 255.255.255.255/32 }”

InServicesTCP = “{ ssh, smtp, auth, http, https, pop3 }”
#InServicesUDP = “{ domain }”
OutServicesTCP = “{ http, https, smtp, pop3, whois, domain, ssh, telnet, ftp, ftp-data, nntp, auth, ntp }”
OutServicesUDP = “{ ntp, domain }”

XMMS = “{ 6000, 7500, 8000, 8004, 8044, 8034, 8052, 8038, 8010, 8400, 8014, 8026, 8048, \
8002, 8024, 8028, 8080 }”
RealAudio = “{ 554, 7070, 8080 }”

#————————————————————————–
#————————————————————————–
# Clean up fragmented and abnormal packets
# By default in pf, packets which contain IP options are blocked. Good.
scrub in on { $Ext, $Int } all
#————————————————————————–

#————————————————————————-
# Defaults
# block and log everything
block out log on $Ext all
block in log on $Ext all
block return-rst out log on $Ext proto tcp all
block return-rst in log on $Ext proto tcp all
block return-icmp out log on $Ext proto udp all
block return-icmp in log on $Ext proto udp all

block in quick inet6 all
block out quick inet6 all
#————————————————————————-

#————————————————————————–
# loopback packets left unmolested
pass in quick on $Loop all
pass out quick on $Loop all
#————————————————————————–

#————————————————————————-
# Immediate blocks
# fuzz any ‘nmap’ attempt
block in log quick on $Ext inet proto tcp from any to any flags FUP/FUP
block in log quick on $Ext inet proto tcp from any to any flags SF/SFRA
block in log quick on $Ext inet proto tcp from any to any flags /SFRA

# don’t allow anyone to spoof non-routeable addresses
block in log quick on $Ext from $NoRoute to any
block out log quick on $Ext from any to $NoRoute

# silently drop broadcasts (cable modem noise)
block in quick on $Ext from any to 255.255.255.255
#————————————————————————-

#————————————————————————-
# PASS rules

# ALL — we don’t normally do that. For debugging only.
#pass out quick on $Ext all keep state

# pass in data mode connections for ftp-proxy running on this host.
pass in quick on $Ext inet proto tcp from any to any port > 49151 flags S/SA keep state

# ICMP
pass out quick on $Ext inet proto icmp all icmp-type 8 code 0 keep state
pass in log quick on $Ext inet proto icmp all icmp-type 8 code 0 keep state

# Services we provide to the outside world
#pass in quick on $Ext inet proto udp from any to any port $InServicesUDP keep state
pass in quick on $Ext inet proto tcp from any to any port $InServicesTCP flags S/SA keep state

# Standard services we want to access in the world
pass out quick on $Ext inet proto udp from any to any port $OutServicesUDP keep state
pass out quick on $Ext inet proto tcp from any to any port $OutServicesTCP flags S/SA modulate state

# Special services
pass out quick on $Ext inet proto tcp from any to any port $XMMS flags S/SA modulate state
pass out quick on $Ext inet proto tcp from any to any port $RealAudio flags S/SA modulate state
IMPORTANT: Note that the “rdr” rule in the NAT file refers to the INTERNAL network interface. Its purpose is to redirect all ftp-data requests from the intranet to be redirected to the ftp-proxy on the firewall. Then the ftp-proxy channels those into ports 49152-65535, and outputs them on the internet. This is why we have this hole in the firewall starting at port 49152. I know, it is in the IN direction, but that is how passive ftp works… It is quite a broken protocol.
That’s it! Nothing too painful, as you see. Since pf is a stateful inspection firewall, we can keep our ingress rules to a strict minimum. Notice the sheer elegance of the ruleset, with all services defined at once in a single IN or OUT rule.

One last thing: in order to automagically enable your firewall when the link comes up, you can put the following lines in the /etc/ppp/ppp.linkup file. Notice the extra space in front of each “!” character:

MYADDR:
! sh -c “/sbin/ifconfig pflog0 up”
! sh -c “/sbin/pfctl -e -l tun0 -F all -O aggressive -R /etc/pf.conf -N /etc/nat.conf”

The FTP proxy
If you want tight security, and no FTP available on your intranet, simply remove the hole at 49152, and the “rdr” command in the file “nat.conf”. However, if you want to be able to use FTP from the intranet, then you must keep those, as well as enable the “ftp-proxy” service in inetd. Simply add this line to inetd.conf :

8081 stream tcp nowait root /usr/libexec/ftp-proxy ftp-proxyDon’t forget that you still won’t be able to do FTP’ing from the firewall itself, when the packet filtering is enabled. Hopefully, it is very easy to temporarily disable pf with the command “pfctl -d”, and later re-enable it with the command “pfctl -e”. This comes in handy when we install packages from ftp.openbsd.org with the command “pkg_add”.

We are confident that ftp-proxy will improve with time and eventually dynamically manipulate the state tables of the firewall in order to open/close needed connections on-the-fly.

Addinc stuff to /etc/rc.local
This is where our custom startup instructions go. Those things are started while the kernel is in secure level 1. If you need anything started in a lower security level, modify /etc/rc.securelevel instead. In order to start up PPPoE correctly, I added this at the end of my /etc/rc.local :

ifconfig ne0 up
route flush
ppp -ddial pppoe

This starts PPP, PPPoE, the firewall and the NAT translator (because the firewall and the NAT are started automatically in the ppp.linkup file). If you’re curious, you can reboot at this point, and confirm that you have a fully firewalled internet access:

pcreal# ifconfig -a
lo0: flags=8009 mtu 33224
inet6 fe80::1%lo0 prefixlen 64 scopeid 0×5
inet6 ::1 prefixlen 128
inet 127.0.0.1 netmask 0xff000000
lo1: flags=8008 mtu 33224
ne0: flags=8863 mtu 1500
media: Ethernet autoselect (10baseT)
inet6 fe80::240:f4ff:fe2b:190d%ne0 prefixlen 64 scopeid 0×1
ne1: flags=8863 mtu 1500
media: Ethernet autoselect (10baseT)
inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255
inet6 fe80::240:f4ff:fe2b:16b1%ne1 prefixlen 64 scopeid 0×2
pflog0: flags=141 mtu 33224
sl0: flags=c010 mtu 296
sl1: flags=c010 mtu 296
ppp0: flags=8010 mtu 1500
ppp1: flags=8010 mtu 1500
tun0: flags=8011 mtu 1492
inet 65.92.185.97 –> 65.92.185.1 netmask 0xffffffff
tun1: flags=10 mtu 3000
enc0: flags=0<> mtu 1536
bridge0: flags=0<> mtu 1500
bridge1: flags=0<> mtu 1500
vlan0: flags=0<> mtu 1500
vlan1: flags=0<> mtu 1500
gre0: flags=8010 mtu 1450
gif0: flags=8010 mtu 1280
gif1: flags=8010 mtu 1280
gif2: flags=8010 mtu 1280
gif3: flags=8010 mtu 1280

pcreal# pfctl -sr
@0 scrub in on ne1 all
@1 scrub in on tun0 all
@2 block out log on tun0 all
@3 block in log on tun0 all
@4 block return-rst out log on tun0 proto tcp all
@5 block return-rst in log on tun0 proto tcp all
@6 block return-icmp out log on tun0 proto udp all
@7 block return-icmp in log on tun0 proto udp all
@8 block in quick inet6 all
@9 block out quick inet6 all
@10 pass in quick on lo0 all
@11 pass out quick on lo0 all
@12 block in log quick on tun0 inet proto tcp all flags FPU/FPU
@13 block in log quick on tun0 inet proto tcp all flags FS/FSRA
@14 block in log quick on tun0 inet proto tcp all flags /FSRA
@15 block in log quick on tun0 inet from 255.255.255.255/32 to any
@16 block in log quick on tun0 inet from 10.0.0.0/8 to any
@17 block in log quick on tun0 inet from 172.16.0.0/12 to any
@18 block in log quick on tun0 inet from 192.168.0.0/16 to any
@19 block in log quick on tun0 inet from 127.0.0.1/8 to any
@20 block out log quick on tun0 inet from any to 255.255.255.255/32
@21 block out log quick on tun0 inet from any to 10.0.0.0/8
@22 block out log quick on tun0 inet from any to 172.16.0.0/12
@23 block out log quick on tun0 inet from any to 192.168.0.0/16
@24 block out log quick on tun0 inet from any to 127.0.0.1/8
@25 block in quick on tun0 inet from any to 255.255.255.255/32
@26 pass in quick on tun0 inet proto tcp from any to any port > 49151 flags S/SA keep state
@27 pass out quick on tun0 inet proto icmp all icmp-type echoreq code 0 keep state
@28 pass in log quick on tun0 inet proto icmp all icmp-type echoreq code 0 keep state
@29 pass in quick on tun0 inet proto tcp from any to any port = pop3 flags S/SA keep state
@30 pass in quick on tun0 inet proto tcp from any to any port = https flags S/SA keep state
@31 pass in quick on tun0 inet proto tcp from any to any port = www flags S/SA keep state
@32 pass in quick on tun0 inet proto tcp from any to any port = auth flags S/SA keep state
@33 pass in quick on tun0 inet proto tcp from any to any port = smtp flags S/SA keep state
@34 pass in quick on tun0 inet proto tcp from any to any port = ssh flags S/SA keep state
@35 pass out quick on tun0 inet proto udp from any to any port = domain keep state
@36 pass out quick on tun0 inet proto udp from any to any port = ntp keep state
@37 pass out quick on tun0 inet proto tcp from any to any port = ntp flags S/SA modulate state
@38 pass out quick on tun0 inet proto tcp from any to any port = auth flags S/SA modulate state
@39 pass out quick on tun0 inet proto tcp from any to any port = nntp flags S/SA modulate state
@40 pass out quick on tun0 inet proto tcp from any to any port = ftp-data flags S/SA modulate state
@41 pass out quick on tun0 inet proto tcp from any to any port = ftp flags S/SA modulate state
@42 pass out quick on tun0 inet proto tcp from any to any port = telnet flags S/SA modulate state
@43 pass out quick on tun0 inet proto tcp from any to any port = ssh flags S/SA modulate state
@44 pass out quick on tun0 inet proto tcp from any to any port = domain flags S/SA modulate state
@45 pass out quick on tun0 inet proto tcp from any to any port = whois flags S/SA modulate state
@46 pass out quick on tun0 inet proto tcp from any to any port = pop3 flags S/SA modulate state
@47 pass out quick on tun0 inet proto tcp from any to any port = smtp flags S/SA modulate state
@48 pass out quick on tun0 inet proto tcp from any to any port = https flags S/SA modulate state
@49 pass out quick on tun0 inet proto tcp from any to any port = www flags S/SA modulate state
…
@72 pass out quick on tun0 inet proto tcp from any to any port = 6000 flags S/SA modulate state
@73 pass out quick on tun0 inet proto tcp from any to any port = 8080 flags S/SA modulate state
@74 pass out quick on tun0 inet proto tcp from any to any port = 7070 flags S/SA modulate state
@75 pass out quick on tun0 inet proto tcp from any to any port = 554 flags S/SA modulate state

pflogd and tcpdump
With the new pf firewall code comes a new way to log firewalled packets and look at them. The log is actually taken care of by a separate daemon ( pflogd ) which should be started in “ppp.linkup” and killed in “ppp.linkdown”. This daemon puts its data in a special log file ( /var/log/pflog ) which is not directly human readable, for performance reasons. To get a dump of the file, simply issue the command “tcpdump -n -e -ttt -r /var/log/pflog”, or , if you want a real-time display of the logs, simply issue “tcpdump -n -e -ttt -i pflog0″.

The Dynamic DNS
Dynamic DNS is a wonderful thing. Basically, you just go to a dyndns provider like those nice people and 10 minutes later you have your very own domain, for free. In order to make that domain dynamically follow your IP address changes, you must use a special client program which must be called whenever your IP changes.

Until recently I liked ddup, but now i use ipcheck. The latter is truly compliant with all of dyndns’s client specification, and maintains its state automatically in system files. You will have to install the python package if you use “ipcheck”. Also, you’ll need your user ID and password from the dyndns provider.

One more advice: it is perfectly acceptable to have more than one domain pointing at the same IP address. Remember this when choosing one or more domain names…

Keeping your xDSL link alive 24/7
xDSL connections are very reliable, but ISP’s are not For many reasons unfathomable, you will sometimes lose your connection. There are many methods of re-establishing that connection automatically, and i’ll describe here the one i use.

The Method
Make sure you initialise ppp with the “-ddial” command, and NOT the “-background” command…

The automatic restart of the ppp link is handled by ppp itself (using the “-ddial” command), which is quite handy. This leaves us with the dyndns updates, which are performed intelligently by ipcheck.py . An easy way of doing it is to create an executable file named “do_ipcheck” which contains this:

#!/bin/sh
/usr/local/sbin/ipcheck.py -q -d /etc/ipcheck -i tun0 -w Username Password DomainName1,DomainName2with your own Username, Password and Domain names, of course. Then, all you have to do is to add the following line to crontab:

*/5 * * * * /usr/local/sbin/do_ipcheckAlso, don’t forget to create the directory /etc/ipcheck and make sure your /etc/ppp/ppp.linkup file looks like this:

MYADDR:
! sh -c “/sbin/ifconfig pflog0 up”
! sh -c “/sbin/pfctl -e -l tun0 -F all -O aggressive -R /etc/pf.conf -N /etc/nat.conf”
! sh -c “/usr/local/sbin/ResetNTP.sh”
!bg sh -c “/usr/local/sbin/do_ipcheck”
You can call “do_ipcheck” from “ppp.linkup” … however, you must use the special “!bg” construct, in order to instruct ppp to fork it in the background. Nasty stuff happens if you don’t use “!bg” here. Big thanks to Dan for this update!

This setup should garantee the proper restart of the firewall & ipnat each time the ppp link is brought up again.

Apache
Now would be a good time to install your htdocs directory. The way i like to do this is to mount a read-only NFS file system over the current htdocs. This is easily accomplished by adding a line like this to your /etc/fstab :

192.168.1.1:/usr/local/Apache/htdocs /var/www/htdocs nfs ro Moreover, the web logs are kept in /var/www/logs. Interesting stuff.

We are in full virus season and i’m sure your log files will fill up as fast as mine with useless garbage, once your Apache is up. In order to remove some clutter, you can filter out the virus attacks and channel them to a specialized attack_log file. Simply insert the following lines into your /var/www/conf/httpd.conf file:

SetEnvIf Request_URI “^/default.ida” attacks # For Code Red
SetEnvIf Request_URI “^/scripts” attacks # For nimda
SetEnvIf Request_URI “^/c/winnt” attacks # … ditto all the way down
SetEnvIf Request_URI “^/_mem_bin” attacks
SetEnvIf Request_URI “^/_vti_bin” attacks
SetEnvIf Request_URI “^/MSADC” attacks
SetEnvIf Request_URI “^/msadc” attacks
SetEnvIf Request_URI “^/d/winnt” attacks

CustomLog /var/www/logs/access_log combined env=!attacks
CustomLog /var/www/logs/attack_log combined env=attacks
This will send all virus-related requests to “attack_log”, while still logging other activities normally in access_log.

Named
Someone (Chavous P. Camp, thanks!) sent me advice on optimizing “named” for faster throughput. He recommends to add two lines to the “/var/named/named.boot” file:

options forward-only
forwarders ip.addresses.of.ISPs.nameservers.separated.by.spacesThis forces named to always use the same servers for dns. If your ISP’s servers are always on fixed IP adresses, then it works well. However, ISP’s who force you to use PPPoE will also sometimes change dynamically the DNS servers allocated to you (in “/etc/resolv.conf”, automatically created by ppp at startup). In that case, there is no garantee that the name servers you hardwire as forwarders will always be available.

Removing IPv6 related errors
The GENERIC OpenBSD kernel comes precompiled with IP v6 support. This is the reason why you might see many “/bsd: tun0: not multicast capable, IPv6 not enabled” error messages in your logs. Those messages are completely harmless and do not alter the performance of your system. However, should you want to get rid of them, you can simply remove IPv6 support from your kernel by modifying “/usr/src/sys/conf/GENERIC” and removing the “option INET6″ line. Then recompile your kernel in the usual way. Thanks Chavous for this info!

Setting permissions of scripts & config files
Another excellent suggestion from Chavous. Scripts and config files with passwords should have their permissions changed to 500 (for scripts) or 400 (for config files), for greater security. This includes “ppp.conf”, “do_ipcheck”, etc…

The NTP daemon
The ntpd daemon is not installed by default. However, you can download it as a package, and install it with the pkg_add command. Since you have internet connectivity by now, you can download & install it in a single command:

pkg_add ftp://ftp.openbsd.org/pub/OpenBSD/3.0/packages/i386/ntp-4.1.71.tgz Moreover, you will need a valid /etc/ntp.conf file:

pcreal# cat /etc/ntp.conf
server 128.100.102.201
driftfile /etc/ntp.driftFeel free to use any other atomic time server if you want. Also, the drift file will be created & maintained automagically.

Important tip from Chavous:
=========================================
I found my ntp server would refuse to synchronize after a reboot because it
had no route to the time server. This was, of course, because PPPoE is
loaded AFTER ntp, and sometimes the PPPoE negotiation after a reboot takes a
few seconds.

Anyway, here is something you might want to add as a suggestion:

Turn ntpd OFF in the rc.conf file
add this line to your ppp.linkup file – AFTER the firewall initialization

! sh -c “/etc/ppp/ResetNTP.sh”

That script should then contain:

#!/bin/sh
if [ -f /var/run/ntpd.pid ]; then
kill `cat /var/run/ntpd.pid`
rm -f /var/run/ntpd.pid
fi
/usr/local/sbin/ntpd -p /var/run/ntpd.pid

(as I have said before, remind your readers that this script is executed as
root and should therefore be chmod 444 or less)

This kills the NTP daemon (if it exists) and restarts it. On boot, it would
not be restarted, but what if the link went down for a while? The ntp daemon
would give up and stop sending queries because it couldn’t get a route to
host.

REALLY, the ntp daemon SHOULD NOT stop querying the server just because it
can’t get a route to the host, but it seems to be written as such now
anyway. I haven’t tested the ntp daemon over a long period of time (more
than about a day) so I don’t know if it just gives up for some arbitrarily
long period (MORE than a day) and then tries again. I seriously doubt it
does, because a day is a LONG time. This workaround isn’t ideal, because
for time consistency, one would want the time server to stay running at all
times. According to the ntpd documentation, ntpd tends to become more
accurate the longer it runs.

Chavous
=========================================

Sendmail
If you have followed all the steps of the recipe so far, your sendmail should be configured & ready to receive mail from the internet, however you should know a few more things about this. First, if you want your gateway to receive mail for more than one domain, you must make sure the all fully qualified domains are setup as aliases for your host in the file /etc/hosts.

The mail popper
All ingress mail is received & kept on the gateway untill some POP client on the intranet gets it. I use the “popa3d” server package because it is written with security in mind. It is now part of the main OpenBSD 3.0 distribution, so you don’t have to download it as a separate package. Simply enable it in the file /etc/inetd.conf and you should be up & running.

The installed packages
Just to do a quick check, here are the packages i have installed on my system:

pcreal# pkg_info
gmp-3.1.1 library for arbitrary precision arithmetic
python-2.1.1 interpreted object-oriented programming language
ntp-4.1.71 network time protocol implementation
libiconv-1.7 character set conversion library
gettext-0.10.40 GNU gettext
mhash-0.8.9 strong hash library
libtool-1.3.5p3 generic shared library support script
postgresql-7.1.3 PostgreSQL RDBMS
libmcrypt-2.4.15 interface to access block/stream encryption algorithms
c-client-4.40p1 University of Washington’s c-client mail access routines
php4-4.0.6p1-gettext-imap-mhash-no_x11-mcrypt-postgresql server-side HTML-embedded scripting language

The Secure Shell
The secure shell looks & feels exactly like telnet, except that all communication between the client and the server is encrypted. It is the only possible way to access your gateway, because the telnet daemon is disabled by default. Usage is very simple: just like telnet!

[real@pcreal Projects]$ ssh 192.168.1.2
real@192.168.1.2′s password:
Warning: Remote host denied X11 forwarding.
Last login: Sun Nov 5 12:58:08 2000 from 192.168.1.1
OpenBSD 2.7 (GENERIC) #1: Thu Nov 2 16:05:11 GMT 2000

pcreal:real {39}

Once you are logged in as an unprivileged user, member of the wheel group, you can use su to gain superuser privileges:

pcreal:real {39} su -
Password:
Terminal type? [nxterm]
pcreal#

The log files
There are many log files of high interest maintained automatically by your gateway. It is usually convenient to look at them with the “tail -f” command. The files i look at often are:

/var/log/messages
/var/log/maillog
/var/log/secure
/var/www/logs/access_log

Moreover, you can grab interesting info about the blocked packets on your firewall with the “ipmon” utility.

There are many other log files available for all kinds of things. Dig around to find more about them.

Installing IPSEC
Dave Cook has kindly provided us with a good description of how to install IPSEC on your OpenBSD boxen: file:///H:/OPENBSD/ipsec.pdf, in PDF (Acrobat) format. Be aware that it is a largish file (440K), and it might take some time for your Acrobat reader to load afterwards, so don’t hit the link repeatedly, it won’t make things load faster…

Apply the security patches!
Security patches are published there. APPLY THEM RELIGIOUSLY!
It is not really difficult, but you will need a copy of the complete, original source tree of the distribution. The compressed source archives are to be found with the distribution files. These are the 3.0 source files:

src.tar.gz 64447 Kb Tue May 1 16:18:00 2001 Unix Tape Archive
srcsys.tar.gz 13837 Kb Tue May 1 16:18:00 2001 Unix Tape ArchiveThey total about 80 MB. Once you have them, simply unpack them to ‘/usr/src’ and ‘/usr/src/sys’. The latter is the kernel proper.

Once you have your source tree, you can start downloading the patches, and apply them. Usually, all the currently published patches are availble in a single file. For 3.0, it is there. After that, simply watch the patch page from time to time, to keep updated.

Patches are either applied to an application (in ‘/usr/src’), or to the kernel ( in ‘/usr/src/sys’). Since all kernel patches should be installed, the thing i do is to apply all the kernel patches in one session, then i recompile my kernel once.

The applications you don’t use (e.g. ‘X11′, for example) don’t have to be patched & recompiled.

Reboot and enjoy!
You should be able to ssh into your new gateway from any machine on the intranet.

# Those wonderful scrubbing bubbles
scrub in all

# Filtering begins
block log all

# Local machine stuff
pass quick on lo0 all
pass in on $int_if from $int_if:network to any
pass out on $int_if from any to $int_if:network
block in quick on $ext_if from $priv_nets to any
block out quick on $ext_if from any to $priv_nets
antispoof log for { $int_if, $ext_if }

# Out to the internet
pass out on $ext_if proto tcp all modulate state flags S/SA
pass out on $ext_if proto { udp, icmp, esp } all keep state
设置拨号时启动PF: vi /etc/ppp/ppp.linkup:
MYADDR:
! sh -c “/sbin/ifconfig pflog0 up”
! sh -c “/sbin/pflogd”
! sh -c “/sbin/pfctl -e -F all -f /etc/pf.conf”
vi /etc/ppp/ppp.linkdown:
MYADDR:
! sh -c “/sbin/pfctl -d -F all”
! sh -c “kill $(cat /var/run/pflogd.pid)”
! sh -c “/sbin/ifconfig pflog0 down”
! sh -c “/sbin/route delete default”

table persist
table persist
block quick from
block quick from
pass quick inet proto tcp from any to any port 22 keep state (max-src-conn 5, max-src-conn-rate 3/20,overload flush global)
pass quick inet proto tcp from any to any port ftp keep state (max-src-conn 5, max-src-conn-rate 10/40,overload flush global)

2.再寫個script去紀錄每天的狀況

1
2
3
4
5
6
7
8
9

#!/bin/sh
log_file="/var/log/bad_guy.log"
date >> $log_file
 
echo " FTP:" >> $log_file
/sbin/pfctl -t SSHbruteforce -T show >> $log_file
 
echo " SSH:" >> $log_file
/sbin/pfctl -t FTPbruteforce -T show >> $log_file

3.阻擋一日後,即清除IP紀錄,先裝套件/usr/ports/security/expiretable

# /usr/local/sbin/expiretable -v -d -t 24h SSHbruteforce
# /usr/local/sbin/expiretable -v -d -t 24h FTPbruteforce

並把設定加入rc.local