Software Distribution) started out as a distributed package of software
enhancements for UNIX
. Bill Joy
et al created an improved version of AT&T's UNIX that DARPA
to be the preferred 'universal computing environment' linking together ARPANET
research nodes, thus setting in place an essential piece of infrastructure
for the later growth of the Internet.
Because the Internet's basic
building blocks (rooted in ARPANET
's decentralized architecture)
are open sourced, they have been incredibly succeptible to insecure
one of the main protocols of the Internet, is too easy to spoof;
susceptible to ping
of deaths (fortunately not a real threat anymore) and teardrop
attacks (overlapping IP fragments, resulting in "kernel panic");
and can easily fall victim to strict
and loose routing.
(IP's "control freak" cousin in the TCP/IP stack)
relies on two things to communicate--an IP
address and a port
(collectively known as a "socket address") to communicate. Because
of the trusting way it attempts to regulate information flow between sockets,
it is incredibly susceptible to LAND attacks (aka the Evil Handshake of Death--the
result of spoofed packets), masqueraded/hijacked sessions, and desynchronization.
- Unlike TCP, UDP,
doesn't even worry about the state of Internet communication, making it especially
vulnerable to teardrop attacks and fraggle (a
type of DoS attack).
two fundamental tools that translate your computer's physical
address to a
logical one, easily fall victim to cache poisoning, resulting
in information being routed to a place other than its intended destination.
originally meant to redirect
errors to help routers build more efficient tables, is abused by malicious
hackers for things like DoS,
(relates to IP-directed broadcasts), etc. (Neither ARP/RARP nor ICMP have
any sort of built in security, making them especially vulnerable to
is perhaps the best known implementation of ICMP (not to be confused, of course,
- Routing protocols, such as RIP/OSPF,
also have vulnerabilities similar to those of those protocols previously mentioned.
OpenBSD's role in the *BSD community
As BSD matured, it branched into three distinct projects--FreeBSD,
NetBSD, and OpenBSD.
on adapting the BSD framework specifically to Intel's
architecture; NetBSD, on
adapting BSD to all sorts of non-Intel
hardware. Theo de Raadt left
the NetBSD project and, with his team of developers, audited
NetBSD's code base to create a "proactively secure" UNIX-like OS --
OpenBSD's easy and "secure
by default" installation makes it perfect for beginners and a viable
alternative to commercial firewalls:
- Documentation is excellent.
If you can't find what you need on OpenBSD's site, you will most likely find
it on help sites and listservs dedicated to helping newbies. Quite impressive
when you compare it to the pitiful support and training large commercial firewall
vendors, such as CheckPoint,
provide. (Thank God for Phoneboy's website
- Non-essential services are turned OFF on the default installation,
allowing you to focus more on their rule set rather than patching your system
of vulnerabilities. (There are still a few more you can turn off if you're
- The price is right! FREE!
- It is supported on all sorts of hardware: you will most likely not have
any trouble when you install it on your old PC.
- Because bug, exploits, and problems are under "full disclosure" policy,
the OpenBSD team boasts one remote hole in the default install in nearly
Printing important pages
Before we actually install and configure OpenBSD, load your printer with paper
and print out the following websites. It's ok if you don't know what they are
yet; you'll see why later on in the article.
Installing OpenBSD via FTP
Let's start at the most obvious place: OpenBSD's
website. On the left panel, you'll see the FAQ and installation
guide. Check to see that OpenBSD
supports your hardware (chances are that it does, but it's always good practice
to check). Read over everything quickly. If you get stuck on terms like "mount",
etc., consult a computer
glossary such as WhatIs.com.
Now, make sure that (at least) two network cards are in your computer (double
check the hardware page to make sure
your NICs are on the OK list). One NIC is used interface the Internet; the
other, to your internal network. Additional cards can be used to create your
If you're a Windows or Mac user, you're probably used to
- Using a bootable CD-ROM to install the OS (after you set the BIOS to "boot
to CD"), or
your computer pre-installed with an OS (most likely Windows).
The way we're going to install BSD is a little different:
- You use create a bootable
floppy on, say, a Windows machine
- You boot your soon-to-be BSD computer to that floppy (after properly
setting your BIOS
to boot to the floppy drive)
- You then give instructions on how to partition and mount your drives, how
to network, and where the OS install files are (CDROM or FTP
Be sure to read the OpenBSD install directions carefully. The OpenBSD box
you're configuring will be completely wiped of all previous information.
If you're uncertain about how to partition your hard drive, then just go ahead
and use their example (which most hard drives should be able to handle no problem;
if not, then just try 250 MB for the swap and devote the rest to the / partition)
Once you check off what packages you want (for the hell of it, just select
them all), sit back and watch them download. Compared to many other programs
you're used to using, OpenBSD is incredibly lean and small.
Wow, installing OpenBSD was easy!
Now, reboot your machine and
log in as root (with whatever password you told it to when you installed the
- After you log in as root, you'll see a nasty "Don't login as root, use
message. Don't worry about that now; that's just a security precaution that
you can worry about later once you get it all up and running.
see a "terminal type" prompt. Just
- Type in "pwd"(short
for "print working directory", this command tells you that you're
located in the /root directory.).
- Now type in "man
afterboot" to get a checklist of everything that needs to be done
upon booting up your computer for the first time.
- Double check your Internet connection (type in "telnet geno.org" and see if you get a login prompt.
If you were able to download the OS files from OpenBSD's FTP servers, then you're
already set.) Nevertheless, if you want to check, type in "ifconfig
-a" to see the addressing information on your network cards. If it scrolls
by too fast, type in "ifconfig -a|more".("|more" at the end of a command
is roughly equivalent to the "/p" switch in DOS.) If you need detailed networking
help, check out OnLamp's
networking guide on OpenBSD.
- Pull out that "man
afterboot" printout you made earlier and circle these important parts
for later--hostname, dhcp, pf.conf, sysctl.conf,
rc, and inetd.conf. (Don't bother with resolv.conf, diskmounts,
printers, adding new users, etc. until you've finished this tutorial.)
- Let's go into the /etc directory (where your configuration files and scripts
are located--the equivalent of, say, Windows
Registry). Type in "cd /etc". If you're unsure whether you're really there,
type in "pwd".
- Now, pull out that printout on vi.
How I learned to stop worrying and love vi
There's really no easy way to learn vi. It's not very intuitive, and chances
are that the first several times you use it, you will curse it and the
guy who made it. It's radically different than any of the editors you're
used to--Word, Notepad, Pico, etc.
That said, the ONLY way to learn it is to jump right in. If the vi man page
you printed out doesn't make sense, try printing out this vi cheat sheet (you
might want to buy
this book also).
- Type "touch
test" to create a dummy file. Now, type"vi test" to edit that dummy file.
(You could have skipped "touch test", it creates the file automatically; but
look on the bright side--you learned another command!)
- You'll notice that you can't edit the file like you're probably used to.You
must first position the cursor where you want and then hit "i" (to put it
in insert mode) to insert characters. Type what you want, then type "esc"
to go back into view mode. To delete a character, go into "view mode",
position the cursor before the character what you want to delete, and then
hit "del". If you want to whack an entire line, then hit "dd" while in view
mode. If you want to save at any point, hit (in this order): esc then
: then w. If you want to quit, then type (in this order): esc
then : then q. (You can combine commands: ":wq", for example,
saves then quits--but don't worry about doing that quite yet).
- Type in "vi /etc/sysctl.conf" and hit the down arrow until you come to the
line "#net.inet.ip.forwarding=1". Now, uncomment that line. (that is, delete
the beginning # mark in front. # is the equivalent of REM in DOS).This
turns ON IP forwarding. You'll notice the line below it (net.inet6.ip6.forwarding=1)
pertains to IPv6;
don't worry about that. Hit esc a few times, then type ":wq" to save
and quit. If you goof, consult your cheat sheet on how to delete or insert
type in "vi rc.conf". Here you will see a list of instructions that your computer
follows every time it boots up. Hit the down arrow until you come to the line "pf=NO". Change "NO" to "YES". (Hit the right arrow a few times until
you come to the space after the equal sign, then hit "i" [for insert] and
type in "YES", then hit esc and then hit del to remove
YES). Now exit (esc a few
times [until it beeps] then ":wq" to save and quit)
type in "vi inetd.conf". Don't change anything, just make a note to yourself that
this is where you would disable potentially vulnerable services (or
enable services that OpenBSD had disabled by default) by inserting a #
sign (aka "commenting out a service") before the service on the left. (Services like ident, comsat, daytime,
time, rstatd, and rusersd really should be commented out; they have no
useful purpose on a firewall. But we won't worry about them now.)
If you ever want to quickly view files without bothering with vi, try using
command: simply type in in "cat" (in lieu of "vi") and then the name of the
file you want to check out.
Due to a licensing
dispute, ipfilter is no longer
packaged with OpenBSD (it came standard on pre-3.0 versions; but, at present, it
comes preinstalled in FreeBSD and NetBSD and can be installed separately on
OpenBSD). Theo de Raadt, in a Kernel
Trap interview, talks about some of the differences between pf and ipfilter,
as has Daniel Hartmeier (author of pf) in his paper, Design
and Performance of the OpenBSD Stateful Packet Filter, and his Kernel
Trap interview. If you're used to working with ipfilter, you might want
to check out these articles
on converting ipfilter rules to pf. )
Print OpenBSD's pf.conf
man page and networking pf guide. Though
slightly outdated, Wouter Coene's OpenBSD
Packet Filter HOWTO is also excellent. Before you create your firewall policy,
note that starting with version 3.2, OpenBSD's /etc/nat.conf is now part
of /etc/pf.conf file (unlike
3.0 and 3.1's pf, as well as previous versions of OpenBSD). While these
distinctions may seem trivial, they are important to note when you look at others'
sample firewall policies you may find on the web.
The new pf.conf file has four parts, according to the OpenBSD's pf.
- Options: Various options to control how PF works.
- Scrub: Reprocessing packets to normalize and defragment them.
- NAT and Redirection Rules:
NAT allows many machines to access the Internet through one IP address. Redirection
allows incoming requests to be forwarded to a particular machine behind the
- Filter Rules: Allows the selective filtering or blocking of packets as
they pass through any of the interfaces
Your firewall has (at least) two network cards: one interfacing the untrusted
Internet; the other, your trusted LAN (if you're in an enterprise
environment, this would probably be "quasi-trusted") This pf.conf file dictates
what traffic flows (and doesn't flow!) in and out of these two NIC interfaces.
These next several steps will detail how you create a firewall policy according
to the interface, source/destination IP, traffic direction, service, port, and/or
TCP state. Remember, your computer (being nothing more than a high speed idiot)
only allows/denies what you specify in the pf.conf file.
The outside interface (let's assume you have a 3com card), xl0, plugs into
the outside world and is considered untrusted). Xl1, on the other hand,
plugs into your internal network and is considered (for our example here) trusted.
The number after xl stands for the PCI slot number. For the sake of simplicity,
we'll assume that you only have two interfaces. (If your network card doesn't
have xl0 as a file extension, that's ok: you'll see a different extension based
on the NIC driver of your card ).
Those who have some firewall experience before may find the pf.conf logic confusing.
While all firewalls compare incoming packets to a rule set (going from top to
bottom), they execute them at different types. Check Point
PIX, for example, execute an action as soon as a packet matches a
rule. In contrast, pf.conf only executes the last matching rule.
That means (on other firewalls) if you say something to the effect
Reject all inbound TCP connections (in the first
And then go on to say something like--
Accept all inbound www (port 80) requests (in the
--all inbound traffic (including port 80 requests) will be
REJECTED. Packets come in, see line
one, and are immediately thrown out!
Pf, on the other hand, gives you more flexibility in
creating your firewall policy (some may argue that this is a bad thing). When a
packet comes in, the last rule applying to that packet is acted on (unless
expressly specified with the quick command).
When you "vi pf.conf" from the command line, you
will notice that the default ruleset is:
Pass in all
Pass out all
The first rule of firewall policy is DENY everything except
that which is expressly permitted. Whack those two lines (position the cursor
at the beginning of the line, then execute the "dd" command) and then type (be
sure to hit "i" first to enter insert mode):
Block in all
Block out all
Now, every packet that enters the network will be first
compared to these two lines. Unless a subsequent rule in the pf.conf file
allows that packet, it will be rejected.
Next, we'll add a "scrub rule" to run the packet run through normalization/defragmentation.
Scrub rules are not considered last matching rules. (IPv6 packets are not defragmented.)
Scrub in all
Scrub out all
Now we'll write our ruleset (saying what type of traffic
you're going to allow in and out) underneath the last "scrub out all" line.
Let's make first make a rule that allows free flow on your internal NIC. Let's
assume that you want to be able to telnet, ping, etc. to your firewall from
your internal computers--no matter what.
Pass in quick on xl1 all
Pass out quick on xl1 all
Wait a minute. What's this "quick" command all about? Well, this is an exception
to the "the last matching rule is executed" rule. Let's assume you have something
really important that you want executed immediately (in this case, you want
any and all traffic directed towards the inside interface--ftp, telnet, ping,
etc.--to be allowed immediately without being matched to the other rules). When
packets on the xl1 interface see this "quick" command, they will stop being
sequentially compared to the other rules in the list.
Let's allow any traffic back in your network on the
condition that it originated from inside. Below the two lines above, type these three lines:
Pass out on xl0 proto tcp from any to any keep state
Pass out on xl0 proto udp from any to any keep state
Pass out on xl0 proto icmp from any to any keep state
The "keep state" rule refers to the state table. In other words, if the traffic
originated from within your network, then you're going to let it back in (the
"state"--SYN/ACK/FIN of the connection--is
saved on a on a separate table and compared against when traffic tries to come
back in). A blanket rule like this is NOT recommended in all environments. There
are all sorts of ports that you'd want to deny coming in and out, not matter
what direction they're coming from.
Now that we've got a basic idea of how pf.conf works, we can work on the NAT
portion (near the bottom). NAT can be incredibly confusing for those who haven't
seen it before, as different technologies/vendors often have different names
for the same thing. Created in
1994 to fix the "two most compelling problems facing the Internet" ("IP
address depletion and scaling in routing") it hides (reserved)
private IP addresses behind legit public IP addresses (of which there is
a finite number of).
There are many ways to NAT:
- Static NAT:
- Often called "one to one" NAT. This means that for everyone public IP,
there is one private IP statically mapped to it. An organization
that has exactly one public IP addresses for everyone computer could use
this sort of scheme. By statically NATting computers on a firewall, a network
administrator could filter out certain types of inbound traffic.
is also known as "many to many" NAT. A range of IP address is shared
between lots of private IP addresses. If someone is just surfing the web,
there's absolutely NO need for them to have their own dedicated IP
(aka Port Address Translation [PAT], or "NAT
overloading", by Cisco)
- Used when there is only one IP address to share with many people (also
known as "many to one"). The unique source port determines which
internal (private) IP address gets the return traffic.
when your public IP addresses "overlap" with the public IP addresses of
another network. The router
translates the address in order to avoid a potential conflict with the
Looking at OpenBSD's manual on NAT,
we see that pf can do all of these cool things.
The manual gives the following example:
nat on fxp0 from 192.168.1.0/24 to any -> 188.8.131.52
(/24 is another way to denote the network subnet
[or, "segment"] 255.255.255.0)
This basically says that (pubic) IP address on the fxp0
interface NATs your internal
192.168.1.0/24 network. Or, in other
Evil Untrusted Internet ==> (fxp0 interface) firewall (internal card)
While this may at first seem complex, it actually gives you incredible control
over the traffic that passes through your firewall! Computers that want to access
the Internet don't have to go through a proxy
(although they could if you wanted to monitor Internet traffic, content, etc.)
and the private addresses of inside computers are kept relatively hidden from
outsiders (making it a little more difficult for outsiders to directly access
Now that we've mapped those internal private addresses to
that particular public interface, we can do all sorts of things:
- Redirect incoming traffic to a particular computer
- Incoming port 80 traffic could be redirected to separate webserver.
incoming traffic (on specific ports) the ability to redirect to certain
addresses (helpful in thwarting applications like AIM)
combination of redirection and negation
other words, causing "initial packet from the client to be translated
again when it's forwarded back through the internal interface, replacing
the client's source address with the firewall's internal address."
cool stuff (like split horizon DNS and TCP proxying) that are beyond the
scope of this article
Putting NAT rules in the pf.conf file makes sense because now you can manage
all your rules in ONE place. If you have questions on where exactly to write
your NAT rules, look closely at the sample rules that are commented out. If
you find one that is helpful, uncomment it and tweak it to your particular need.
Even for those who've had experience with firewalls, configuring the pf.conf
file for the first time can be incredibly confusing. The important thing is
that A) you've installed OpenBSD from scratch, B) edited the important files
in VI, and, perhaps most importantly, C) know where to go when you have questions.
(While firewalls can be very configurable and flexible, they can NEVER
take the place of a hardened
router: always use 'enable secret' command in lieu of an 'enable password';
log ACL violations, avoid using
HTTP or SNMPv1 to manage your routers (use SNMPv2 with digest authentication);
turn on IOS's anti-spoofing; disable IP Source Routing; block incoming ICMP
redirects; and disable TCP and UDP 'small services' (such as ECHO and CHARGEN).
Check out O'Reilly's
Cisco Access Control Lists or the NSA's Cisco Security Recommendations
for more information on this topic.)
Stateful inspection acts on the network
layer to "track each connection
traversing all interfaces of the firewall and makes sure they are valid."
Bottom line, it means:
- Better security (particularly against port
- Decreased processing power devoted to processing packets
To really understand its benefits, let's look at the evolution of firewalls:
- Packet Filtering Firewalls: Today
this technology is dirt cheap. Routers (such as Cisco) have access control list (ACL), which allow
you to filter by
- Source IP
- Destination IP
- TCP/UDP source port
- TCP/UDP destination port
While this may seem like everything that you need for a firewall, consider
how many applications depend on the TCP
state (SYN, ACK, FIN) and send traffic to "random" ports. Packet
filtering, for lack of a better word, is not "application aware"; it only cares
about the port, destination, and source of traffic. It doesn't care about the
contents of that packet.
Let's look at a very squirrelly
protocol: FTP. Packet filtering leaves system administrators with two choices:
open upper range ports (those greater than 1023) to allow a file transfer
session to take place, or
down that entire range (and disallow FTP).
Stateful firewalls, on the other hand, are a little bit more intelligent. If
inbound traffic is greater than 1023, it will let it in IF it originated
inside the network. This is possible because stateful firewalls keep "state
tables"--records of client IPs, server IPs, and port numbers on a separate FTP
"data pending" list. Any incoming inbound FTP traffic is matched against this
dynamic list. If there is a match, the firewall is opened temporarily, then
closed back down.
Feature set (an optional add-on to Cisco's IOS), CheckPoint's Firewall-1,
Linux's netfilter, and, of course, OpenBSD's
pf are all stateful firewall solutions.
Now, what does this have to do with OpenBSD's pf? Well, pf allows you to also keep track of
what connections originated from your network.
If you put in your pf.conf file something like:
Pass out on xl0 proto tcp from any to any keep state
Then you're telling your computer, keep track of TCP traffic
in the state table so it can return, then close up that hole once it returns.
OpenBSD allows you to see see and erase the contents of this state table via
see the contents of the state table, type pfctl -s state
flush the state table, type in pfctl -F state
Pfctl also lets you load, disable, and enable firewall rulesets.
load a pf.conf file, simply type pftcl -f pf.conf. (If you want to
create various practice rulesets, can could create files like pf2.conf,
- To disable the firewall, type in pfctl -d pf.conf
- To disable the firewall, type pfctl -e pf.conf
Your pf.conf file is by no means perfect (your current ruleset allows traffic
in your network only on the condition it originated from you network).
- Let's harden your box further by disabling unnecessary starting services.
are relatively secure, there is probably no real reason for them to run in
/etc/rc.conf. While the perfect hardening strategy is beyond the scope of
this article, check out what SAN's
and GeodSoft's OpenBSD's
- If you're planning on FTPing, then you'll definitely want to read up on
and the rules you'll need
to create to accommodate your FTP traffic.
- Read Daniel Hartmeier's pf page
to double check the pf-related files and commands: /etc/rc.conf
(pf is disabled by default, use pf=YES to enable it); /etc/pf.conf
(default filter rules); /etc/nat.conf
(default NAT rules--N/A on OpenBSD 3.2); pfctl (tool
to configure the packet filter); pflogd (logging
daemon); pflog (logging
interface); pf.conf (filter
rule syntax); pf (description
of the ioctl interface to the kernel); ftp-proxy
(proxies active FTP connections for NATed clients); authpf (authenticating
gateway user shell).
- Sharpen up your UNIX commands
(particular BSD-specific ones). Start with the basics
and learn how to access the man pages, then focus on shells,
with others. If you have absolutely no idea where to start, learn
the most important 40 commands. Or, at the very least, learn to convert
DOS commands to UNIX.
- Become proficient with vi
(or a vi clone, such as Nano).
It's tough; but it's available on almost all Unix machines, is customizable,
and it's pretty much here to stay. At the very least, print out a vi
cheat sheet or browse through other pages devoted to vi
news sites like Slashdot, GreasyDaemon,
HOWTOs, BSDatWork, Nomoa.com,
BSD, OnLamp's BSD Dev Center,
DaemonNews, and BSD
FAQs are a great place for beginners, as are Google's categories on OpenBSD
security and OpenBSD
administration. Once you have a good grasp of the basics, hit the OpenBSD packet filter (pf)
mailing list archive , UNIX
security news , and advisory
- Read the nuts and bolts of how pf
and TCP state
works. Any questions on TCP, consult the RFC
- Put in more network cards and simulate a complicated enterprise environment:
NAT; IPv6 firewalls,
etc. Once you have a complex environment, work on creating more efficient
are evil. If you ever suspect one, download and install chkrootkit.
- Once you have a good feel of OpenBSD, hammer your box with various auditing
tools. Take a look at the various auditing tools,
particular nmap. Read all about
the various types of port scanning hackers use: Vanilla TCP connect scanning;
TCP SYN (half open) scanning; FIN, Xmas, or NULL (stealth)scanning; TCP ftp
proxy (bounce attack) scanning; SYN/FIN scanning using IP fragments; (bypasses
packet filters); UDP raw ICMP port unreachable scanning; ICMP scanning (ping-sweep);
TCP Ping scanning; Remote OS Identification by TCP/IP Fingerprinting; and
- Read how others configure OpenBSD firewalls--how they partition drives, which
services they remove, how they write their pf.conf file, etc. Many of their
instructions will seem odd (they may be using version of OpenBSD that use
ipfilter and nat.conf); but they will give you an idea of how others use OpenBSD
in various environments.
- Consider adding extra functionality your OpenBSD box: Intrusion
Detection System (by installing something like
Snort or ACID);
logging ; honeypot
capabilities; proxy; VPN; or other misc tools.
OpenBSD may not be for you
Maybe you'd prefer commercial firewall vendors who aren't completely forthright
about their products' shortcomings. Or perhaps you LIKE the idea of blowing
several thousand dollars on a solution you could build for free. (Microsoft
Academy doesn't exactly offer you a classes in intelligent purchasing, does
Sarcasm aside, there are plenty of reasons you may not need an OpenBSD firewall.
If you want an easy fail-over solution (that is, a secondary firewall that actively
takes over when the primary firewall dies), you might be better off with Cisco's
PIX (it doesn't get any easier than simply typing in "failover")
Point on a Nokia
IPSO firewall (running VRRP).
And while OpenBSD is a no frills UNIX-like OS compared to Linux or Sun, you
may actually NEED some of those frills in your application development. OpenBSD
is a tool, and like all tools, it's built to do certain things well
(and certain things not so well).
Give it a whirl. If nothing else, you've turned an otherwise useless PC into
a formidable piece of hardware.
If you have any questions about your setup, feel free to e-mail me: scubacuda
$ iname ) com
Many thanks to John Strader for
introducing me to OpenBSD!