Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Guide to OpenBSD Packet Filtering Firewalls

By scubacuda in Internet
Sat Nov 23, 2002 at 10:29:52 PM EST
Tags: Software (all tags)
Software

by Roger E. Rustad, Jr.

In this article, I explain to users with little UNIX knowledge and experience how to create an OpenBSD 3.2 firewall using pf (packet filter).

I open with a brief introduction on Internet history. While BSD paved the way for the Internet as we know it today, many soon found exploits in its decentralized open standards. From the ground up, the OpenBSD dev team created a secure, hardened UNIX-like OS with these exploits in mind.

Next, I get into the mechanics of setting up an OpenBSD firewall:

  • how to boot from a floppy disk and install OpenBSD 3.2 via FTP;
  • how to configure the /etc files using vi (a UNIX text editor);
  • how to edit the pf.conf file and operate it from the command line (using pfctl);
  • what to take into consideration when planning an appropriate firewall policy for a home LAN; and
  • further tweaking your OpenBSD box.

While implementing an OpenBSD in an enterprise environment is beyond the scope of this article, I provide extensive links to security resources, whitepapers, help pages, and FAQs for those who eventually wish to do so.


BSD's Foundations

BSD (Berkeley 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 later chose 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 implementations and abuse.

  • IP, 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.

  • TCP (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).
  • ARP/RARP, 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.
  • ICMP, originally meant to redirect errors to help routers build more efficient tables, is abused by malicious hackers for things like DoS, smurf attacks (relates to IP-directed broadcasts), etc. (Neither ARP/RARP nor ICMP have any sort of built in security, making them especially vulnerable to misuse.). Ping is perhaps the best known implementation of ICMP (not to be confused, of course, with Ping the Duck!).
  • 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. FreeBSD focused 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.

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 and book!)
  • 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 truly paranoid)
  • 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 six years.

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.

  • man : Perhaps the single most important UNIX command. Man, short for "manual", is the UNIX equivalent of a help file. You would type, for example, "man man" from the command line to read the manual for the command "man")
  • pwd : Short for "print working directory". It helps you determine "where" in the directory structure you are located.
  • cd : How you change directories.
  • ls : How you list the contents of each directory

  • afterboot : A checklist of what you need to do after you install the operating system.
  • ifconfig : Short for "interface configuration", it is how configure your ethernet NIC.
  • hostname : The name of your computer system.
  • sysctl.conf : Instructions on what services and variables to start up upon boot
  • pf.conf ver 3.2 has nat.conf built in it, unlike previous versions of OpenBSD
  • dhcp : An automatically way for your computer to assign [or be assigned] and IP address
  • rc Instructions on what your computer does when it boots up
  • vi A horribly complicated UNIX text editor with rewards that take a long time to appreciate
  • Hoang Tran's guide to creating an OpenBSD firewall using pf : The pf.conf information is outdated with version 3.2, but it nevertheless is an excellent guide.
  • OpenBSD's installation guide (this one requires a lot of paper)

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", "partition", "sector", 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 DMZ(s).

If you're a Windows or Mac user, you're probably used to either

  • Using a bootable CD-ROM to install the OS (after you set the BIOS to "boot to CD"), or
  • Getting 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 server)

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 OS).

  • After you log in as root, you'll see a nasty "Don't login as root, use su" 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.
  • You'll see a "terminal type" prompt. Just hit ENTER.
  • 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 characters.
  • Now, 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)
  • Now 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 the cat command: simply type in in "cat" (in lieu of "vi") and then the name of the file you want to check out.

configuring etc/pf.conf

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 version 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 NAT.
  • 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 and Cisco's 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 of:

Reject all inbound TCP connections (in the first line)

And then go on to say something like--

Accept all inbound www (port 80) requests (in the second line)

--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.
  • Dynamic NAT
    • This 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 address.
  • Overloading (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.
  • Overlapping
    • Used 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 other network.

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 -> 24.5.0.5

(/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 words:

Evil Untrusted Internet ==> (fxp0 interface) firewall (internal card) ==>192.168.1.0/24 network

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 inbound computers.)

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.
  • Negate incoming traffic
    • Deny incoming traffic (on specific ports) the ability to redirect to certain addresses (helpful in thwarting applications like AIM)
  • A combination of redirection and negation
    • In 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."
  • Other 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

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 scanning)
  • 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:

  • leave open upper range ports (those greater than 1023) to allow a file transfer session to take place, or
  • shut 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.

Cisco's PIX, Cisco's Firewall Feature set (an optional add-on to Cisco's IOS), CheckPoint's Firewall-1, NetScreen, SonicWALL, 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 the pftcl command.

  • To see the contents of the state table, type pfctl -s state
  • To flush the state table, type in pfctl -F state

Pfctl also lets you load, disable, and enable firewall rulesets.

  • To 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, pf3.conf, etc.)
  • To disable the firewall, type in pfctl -d pf.conf
  • To disable the firewall, type pfctl -e pf.conf
Now What?

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). Now what?

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 it?)

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") or Check 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!

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
Is OpenBSD's pf is better than ipfilter?
o Yes 64%
o No 7%
o Who cares? I've got better things to do! 28%

Votes: 39
Results | Other Polls

Related Links
o Slashdot
o Google
o Berkeley Software Distribution
o UNIX
o Bill Joy
o DARPA
o chose to be the preferred 'universal computing environment' linking together ARPANET research nodes
o Internet
o basic building blocks
o ARPANET
o decentrali zed architecture
o insecure
o implementa tions
o IP
o spoof
o ping of death
o teardrop attacks
o strict and loose routing
o TCP
o TCP/IP stack
o IP address
o port
o UDP
o fraggle
o a type of
o DoS attack
o ARP
o RARP
o physical address
o a logical one
o cache poisoning
o ICMP
o redirect errors to help routers build more efficient tables
o DoS
o smurf attacks
o Ping
o Ping the Duck
o RIP
o OSPF
o FreeBSD
o NetBSD
o OpenBSD
o focused on adapting the BSD framework
o Intel's architecture
o on adapting BSD
o all sorts of non-Intel hardware
o Theo de Raadt
o left the NetBSD project
o his team of developers
o proactivel y secure
o easy
o secure by default
o viable alternative to commercial firewalls
o Documentat ion is excellent
o CheckPoint
o website
o book
o man
o pwd
o cd
o ls
o afterboot
o ifconfig
o hostname
o sysctl.con f
o pf.conf
o nat.conf
o dhcp
o rc
o vi
o Hoang Tran's guide to creating an OpenBSD firewall using pf
o OpenBSD's installation guide
o OpenBSD's website
o FAQ
o installati on guide
o OpenBSD supports your hardware
o mount
o partition
o sector
o computer glossary
o WhatIs.com
o the hardware page to make sure your NICs are on the OK list
o DMZ
o bootable floppy
o BIOS
o FTP
o reboot
o su
o man afterboot
o geno.org
o OpenBSD's FTP servers
o OnLamp's networking guide
o Windows Registry
o the guy who made it
o vi cheat sheet
o buy this book also
o touch
o IPv6
o rc.conf
o inetd.conf
o cat
o licensing dispute
o ipfilter
o Kernel Trap interview
o Design and Performance of the OpenBSD Stateful Packet Filter
o Kernel Trap interview [2]
o these
o articles
o pf.conf man page
o networking pf guide
o Wouter Coene's OpenBSD Packet Filter HOWTO
o /etc/nat.c onf
o /etc/pf.co nf file
o version 3.0 and 3.1's pf
o pf
o NAT and Redirection Rules
o enterprise
o NIC driver of your card
o Check Point
o Cisco's PIX
o SYN/ACK/FI N
o Created in 1994
o (reserved) private IP addresses
o NAT
o Port Address Translation [PAT], or "NAT overloading", by Cisco
o NAT [2]
o subnet
o proxy
o AIM
o hardened router
o ACL
o O'Reilly's Cisco Access Control Lists
o NSA's Cisco Security Recommendations
o network layer
o track each connection traversing all interfaces of the firewall and makes sure they are valid
o port scanning
o evolution of firewalls
o Packet Filtering Firewalls
o TCP state (SYN, ACK, FIN)
o squirrelly protocol: FTP
o PIX
o Cisco's Firewall Feature
o Firewall-1
o NetScreen
o SonicWALL
o netfilter
o pftcl
o ident
o comsat
o time
o rstatd
o rusersd
o SAN
o GeodSoft
o ftp-proxy
o rules you'll need to create to accommodate your FTP traffic
o Daniel Hartmeier's pf page
o /etc/rc.co nf
o /etc/pf.co nf
o /etc/nat.c onf
o pfctl
o pflogd
o pflog
o pf.conf [2]
o pf [2]
o ftp-proxy [2]
o authpf
o commands
o basics
o shells
o directory names
o directory structure/commands
o file commands
o printer commands
o communicat ing with others
o learn the most important 40 commands
o convert DOS commands to UNIX
o vi [2]
o vi clone
o Nano
o vi cheat sheet
o vi shortcuts
o BSD news
o Slashdot [2]
o GreasyDaem on
o BSDtoday
o FreeOS
o Chucktips
o BSD Vault
o BSD HOWTOs
o BSDatWork
o Nomoa.com
o Deadly.org
o Maximum BSD
o OnLamp's BSD Dev Center
o DaemonNews
o BSD FAQ
o OpenBSD security
o OpenBSD administration
o OpenBSD packet filter (pf) mailing list archive
o UNIX security news
o advisory alerts
o pf [3]
o TCP state
o RFC
o DMZ [2]
o IPv6 firewalls
o Rootkits
o chkrootkit
o tools
o nmap
o Intrusion Detection System
o installing
o Snort
o ACID
o advanced logging
o honeypot
o proxy [2]
o VPN
o other misc tools
o typing in "failover"
o Check Point
o Nokia IPSO
o VRRP
o do certain things well
o John Strader
o Also by scubacuda


Display: Sort:
Guide to OpenBSD Packet Filtering Firewalls | 101 comments (75 topical, 26 editorial, 0 hidden)
Don't forget to mention (1.88 / 9) (#22)
by ph317 on Sat Nov 23, 2002 at 06:24:14 PM EST

The shitty attitudes of the OpenBSD dev crew.  Even among open source kernel development teams, they are  the worst.  I love OpenBSD for firewalls (although I find it useless for much else), and I was going to donate some sparc hardware to them to help with pf on sparc development.  But by the time I had the stuff together I had seen enough of the mailing list to decide I didn't want to support them.  They need to get a grip on reality.  I'm more than happy to use their work to firewall my house, I just don't feel like supporting assholes in any direct way.

you're not the first to say that... (5.00 / 1) (#25)
by scubacuda on Sat Nov 23, 2002 at 07:47:24 PM EST

I have no experience with the dev guys. (But I confess to getting a perverse joy out of the wicked jokes everyone else makes!)


There are a thousand forms of subversion, but few can equal the convenience and immediacy of a cream pie. Noel Godin
[ Parent ]

Data point (5.00 / 5) (#31)
by Anonymous 7324 on Sat Nov 23, 2002 at 09:37:53 PM EST

Theo is not nearly as bad as people make him out to be. I remember as a newbie back in the 2.7 days asking several very stupid questions on the mailing lists, and as long as I showed some semblance of having RTFM'ed, everyone was most tolerant of my questions, no matter how banal or even off-topic.

Let's put it this way: I was asking about troubleshooting a P.O.S. on-motherboard soundcard under an OS supposed to be used as a server/firewall, and yet these guys were incredibly helpful... Theo replied personally with mixer commands to help me out, IIRC. They're really a very nice bunch of folks, as long as you're not outright lazy.

[ Parent ]

perverse joys (5.00 / 2) (#59)
by dhartmei on Mon Nov 25, 2002 at 08:28:12 AM EST

It's not easy to live up to that reputation, it takes a lot of wickedness to satisfy everyone ;-)

Let's try nitpicking about your nice article: keywords in rules should be lower-case ("pass", not "Pass", etc.) .


[ Parent ]

thanks... (none / 0) (#63)
by scubacuda on Mon Nov 25, 2002 at 01:08:56 PM EST

I noticed that after I submitted it.

:/
There are a thousand forms of subversion, but few can equal the convenience and immediacy of a cream pie. Noel Godin
[ Parent ]

Weird (4.00 / 1) (#35)
by Spendocrat on Sat Nov 23, 2002 at 11:24:55 PM EST

I hear this all the time, but after sitting on the lists for a couple years, I still don't see what people are complaining about.

If you have some examples, I'd like to see them.

[ Parent ]

like that gerbil story... (4.50 / 2) (#36)
by scubacuda on Sat Nov 23, 2002 at 11:37:23 PM EST

Maybe it's sorta like Richard Gear and the gerbil:  everyone's "heard" about it, but no one can confirm it.
There are a thousand forms of subversion, but few can equal the convenience and immediacy of a cream pie. Noel Godin
[ Parent ]
What did we do to you?!!?? (2.00 / 1) (#43)
by jungleboogie on Sun Nov 24, 2002 at 03:21:39 PM EST

Hey man, it's not like I raped your mom or something...

[ Parent ]
You must not know how to RTFM (none / 0) (#68)
by lb008d on Mon Nov 25, 2002 at 04:14:05 PM EST

If people do their homework, OpenBSD users are helpful. If you post "I can't get FTP working from behind my firewall" to the lists, you will be rightfully flamed.

"Kuro5hin: politics and pretension, from the $3,000 leather recliners on the hill overlooking the trenches."DarkZero
[ Parent ]

Sorry.. that's bullshit. (5.00 / 1) (#69)
by mindstrm on Mon Nov 25, 2002 at 06:13:07 PM EST

I've seen plenty of posts to the OpenBSD lists with rather dumb newbie questions that get answered intelligently and helpfully.. even if the answer is only "Please check the archives about 6 months back, the answer should be there".

Of course, then the next guy would ask a sligthly more intelligent, less obvious question, and get "RTFM you fucking idiot, don't post that shit here"

Sorry, you can justify it however you want, but the OpenBSD core crowd are quite often pure assholes, for god knows what reason. Every other project out there deals with the same stuff, in a much more grown up manner, but to hear the OpenBSD crowd talk about it, you'd think they had the stupidest users on earth.

They are free to do what they want, their product is good, yadda yadda, but they encourage people to use it then lambast them for being morons.

The original poster is 100% correct.

[ Parent ]

Oh? (none / 0) (#75)
by lb008d on Tue Nov 26, 2002 at 09:32:44 AM EST

This thread is a good example.

The initial question "I noticed the list misc@openbsd.org will distribute messages form non-subscribed addresses..is this normal?" could easily have been answered by searching the archives, yet the poster decided that list members should do it for him.

The followup from Todd is perfectly reasonable, as the initial question has been asked many times. His answer should have been the end of the discussion, however here the initial poster had to whine that Todd's answer didn't coddle his feelings well enough:


A simple "yes" or "no" would have been adequate.

Thanks for prematurely assuming I was going to try to convince
everyone that it should be moderated.

Anyone with half a brain can see immediately upon subscribing to this
list that one should never argue anything about how things on OpenBSD
or anything relating to it are done.

I'm sorry I asked.


The core OpenBSD developers have better things to do than read threads like this when they could be helping people who have real questions.

"Kuro5hin: politics and pretension, from the $3,000 leather recliners on the hill overlooking the trenches."DarkZero
[ Parent ]

apparently not much better things (none / 0) (#101)
by Alan Dershowitz on Sat Feb 22, 2003 at 02:19:36 AM EST

The core OpenBSD developers have better things to do than read threads like this when they could be helping people who have real questions.

Some of them seem to have plenty of time to formulate smartass responses.

Lashing out, even as mild the example was (nobody's linked to one of De Raadt's highly professional retorts) is bound to escalate the situation. It's no surprise that the gentleman responded back.

Todd's response was not "perfectly reasonable" if one realizes that just typing "yes" would have been faster and would most likely would have ended the discussion right there instead of the numerous responses it ended up spawning. Writing back a barbed reply will not prevent others from asking the same question again, since they are asking these questions because they didn't search for the answer in the first place. And no, its's not the really the poster's fault, because no one has read everything, and there's an awful lot of people on the internet. Courtesy is a coping mechanism for dealing with this kind of inevitability, and people should use it.

[ Parent ]

agreed... (4.00 / 1) (#73)
by scubacuda on Tue Nov 26, 2002 at 12:05:04 AM EST

A lot of it is asking the right questions in the right forums.

I generally find that if you're respectful of people's time, they are generally pretty helpful.


There are a thousand forms of subversion, but few can equal the convenience and immediacy of a cream pie. Noel Godin
[ Parent ]

Tough Call - Apropos is your friend. (5.00 / 4) (#23)
by HidingMyName on Sat Nov 23, 2002 at 06:51:39 PM EST

I'm a long time Unix User (21+ years!) and I still feel the pain of learning to use man. Here is what I do when stuck:
  • Use Google (first on the web then google groups on usenet).
  • The BSD web sites are generally good, I'd try the OpenBSD faq and the FreeBSD Handbook as useful resources. Linux How-To's tend to be more accessible but not always accurate or detailed. Sometimes finding out how they do something in a different version of Unix gives a hint as to how it is done in the version you are using.
  • apropos is your friend. Try to come up with one or two key words describing the command you want to use and do
    apropos keyword
    where keyword is the service you are looking for.
  • Ask for help (I do this last).
In general the BSD man pages are definitive reference manuals for the commands (they are really good in that respect). However, you need to have a certain background to understand their contents.

And while obviously not BSD oriented (5.00 / 1) (#48)
by Anonymous 7324 on Sun Nov 24, 2002 at 06:19:18 PM EST

The Linux documentation project usually gives a good hint at places to look for stuff, as long as you realize that bits about bootloaders, kernels,  system and network init, etc. will be different.

Of course, it's likely a bootstrap thing: people who grok the difference between BSD vs. SysV style init and the peculiarities of varied bootloaders generally have a good handle on where to look for help in the first place.


[ Parent ]

nice article but -1 (2.70 / 10) (#26)
by ogre on Sat Nov 23, 2002 at 08:13:26 PM EST

In addition to the wordiness pointed out by others, I can't in good conscious uprate an article that might help to spread the evil horror that is vi.

Good grief, man! Vi sucked from the very start (when it first came out I was excited, but after trying it, I went back to ed until emacs arrived). And here it is thirty years later when there are dozens, if not hundreds, of superior and free replacements, and people are still using vi. Do you still use a handcrank to start your car too?

P.S.

I disavow any responsibility for unnecessary harshness on the grounds that I have a cold, I'm feeling miserable, and vi really, really does suck. Thank you.

Everybody relax, I'm here.

that's cool... (5.00 / 3) (#27)
by scubacuda on Sat Nov 23, 2002 at 08:18:30 PM EST

...I completely understand. vi DOES sucks ass! But it A) does the job, and B) will be on any system you'll ever have to use.
There are a thousand forms of subversion, but few can equal the convenience and immediacy of a cream pie. Noel Godin
[ Parent ]
True, however... (4.44 / 9) (#29)
by tacomacide on Sat Nov 23, 2002 at 08:55:32 PM EST

OpenBSD doesn't support filesystems big enough to contain a full emacs install.

*** ANONYMIZED ***
[ Parent ]

Hehe (4.50 / 2) (#30)
by Anonymous 7324 on Sat Nov 23, 2002 at 09:30:29 PM EST

Nice attempt at starting a religious war. Brownie points for the effort, at least!

[ Parent ]
indeed. (none / 0) (#38)
by pb on Sun Nov 24, 2002 at 02:50:35 AM EST

That's why Gentoo comes with nano.

:)
---
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall
[ Parent ]

pfft.... (none / 0) (#53)
by needless on Mon Nov 25, 2002 at 01:18:03 AM EST

vi is a text editor. nano is a text entry tool. ;-)

[ Parent ]
hey... (none / 0) (#66)
by pb on Mon Nov 25, 2002 at 02:50:49 PM EST

nano can load and save files--it even has a search and replace function!

Now, nano might not have a Turing-complete macro system, but it does have an online help system...  :)
---
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall
[ Parent ]

you cretin! (5.00 / 1) (#81)
by Wolf Keeper on Tue Nov 26, 2002 at 02:17:34 PM EST

vi is the ultimate hacker tool!  It enables us to know in the pits of our hearts that we, the unix'ers, the elite, are the pinnacle of our race because we can master arcane tools.  To the common man, watching a guru use his vi editor is like watching a sorceror work his magic.

How could we give up this most prominent indicator of our innate superiority?

Okay, sarcastic elitism aside, I have a very good reason for using vi.  I want to feel like I didn't waste countless hours learning the damn thing on our unix servers at college.  The first time one of my friends showed me NANO (and the equally user-friendly JOE), I just about shot myself.  

At least my epiphany happened before I tried to tackle emacs.  

[ Parent ]

but... (2.23 / 13) (#33)
by turmeric on Sat Nov 23, 2002 at 11:03:52 PM EST

BSD is dying
Netcraft Confirms

Just the opposite is true. (none / 0) (#55)
by mreardon on Mon Nov 25, 2002 at 05:50:39 AM EST

Far from dying, BSD just keeps on going and going. The highest uptimes list by Netcraft is dominated by BSD.

[ Parent ]
Logging firewall violations... (4.00 / 1) (#37)
by dasunt on Sun Nov 24, 2002 at 01:05:05 AM EST

I agree, logging firewall violations is probably a good idea, but on the small box I have, over a 56k dialup, an hour or two on the net will generate a few pages worth of logs.

So, how to manage them?



Log only the strange and unusual (none / 0) (#39)
by CtrlBR on Sun Nov 24, 2002 at 06:43:04 AM EST

Myself I don't log common things like Windows share scans, Netbus scans, open proxies scan... because I'm absolutely not vulnerable to them and could not care less if some kid just downloaded a v3r7 k3wl h4ck3r t00l.

I just keep an eye on what is out of the ordinary.

[ Parent ]

Two Minute Firewalls (5.00 / 1) (#40)
by cam on Sun Nov 24, 2002 at 08:22:18 AM EST

Maybe you'd prefer commercial firewall vendors who aren't completely forthright about their products' shortcomings.

We had a project that had a commercial firewall fail on us shortly before deployment. With a panic as deployment time came near and the commercial vendor unable to solve the failure, it got replaced with an old Dell Linux Firewall. The impromptu solution didnt miss a heartbeat and we had another waiting in the wings in case of a fall over.

Not so long ago that same project got an injection of money and we looked at replacing the Linux Firewall with a commercial solution again. But there was number of connections licenses issues and so forth. Too much licensing hassle. So we spent the money on two Dell 1U Poweredges that come with Linux as well as basic Red Hat support and set them up instead.

There are some other advantages to having a Linux Firewall (and I assume a BSD firewall as well) in that you can keep the firewall rules in CVS and have a versioning history of them. Transferring the rules as rc.firewall also makes it easy to replicate the firewall as well.

After reading the article, I will have to have a go at setting up a test OpenBSD firewall now.

cam
Freedom, Liberty, Equity and an Australian Republic

Nightly /etc diff (none / 0) (#44)
by zenit on Sun Nov 24, 2002 at 03:22:37 PM EST

One of the nice aspects of OpenBSD is that every night, a diff of the /etc directory is mailed to root. This way, you have a nice record of configuration changes. Not quite CVS, but easier to handle and a very sensible default setting.

[ Parent ]
Linux has this too (none / 0) (#46)
by Anonymous 7324 on Sun Nov 24, 2002 at 06:15:52 PM EST

in the form of changetrack, and you can tell it exactly what files and directories to track and not track, and have it selectively mail diffs of only changes in certain directories to you.

Anyways, so it mails changes to you, and keeps older versions in RCS -- very nice: I've actually used it as a recovery tool to get back a file that I'd accidentally clobbered with a rogue '>' instead of '>>'.

[ Parent ]

I'm not a zealot but... (none / 0) (#41)
by faecal on Sun Nov 24, 2002 at 11:56:13 AM EST

I feel the need to defend vi just a little. Primarily, against this: "There's really no easy way to learn vi. It's not very intuitive."

Second sentence: true, but neither is clicking a floppy to save onto a hard disk and a folder to open from the root of a floppy. I don't believe that there is such a thing as intuitive software design beyond the "make it as similar as possible to everything else" philosophy.

First sentence: you're wrong. There is. It's called vimtutor, and it's what I used for 15 minutes or so before deciding the ditch gedit and pico and use vim. vim==vi, insofar as is relevant to editing config files. Yes, vimtutor or something similar probably wasn't available in this precise situation, but coming from that to "There's no easy way to learn vi" is like saying that "There's no easy way to squeee oranges" based on the experience of someone without an orange-squeezing device of some kind.



thanks... (none / 0) (#42)
by scubacuda on Sun Nov 24, 2002 at 01:07:04 PM EST

...I will definitely check that out.


There are a thousand forms of subversion, but few can equal the convenience and immediacy of a cream pie. Noel Godin
[ Parent ]

bah (none / 0) (#49)
by gjetost on Sun Nov 24, 2002 at 07:34:06 PM EST

Bah, real programmers and sysadmins use ed

[ Parent ]
Excellent article (5.00 / 1) (#45)
by strlen on Sun Nov 24, 2002 at 04:28:29 PM EST

But, you didn't mention the fact that OpenBSD is the easiest BSD to keep updated. In fact, the entire system can be updated by:

-Using CVS (or FTP) to retrieve most recent system sources
-Configuring and compiling the kernel, rebooting
-Then issue one or two commands (which are explained in OpenBSD FAQ), to recompile and reinstall all the system sources.

This way OpenBSD a whole can easily be upgraded. In addition, OpenBSD, borrows portability from the project it forked with, NetBSD, thus running on a great deal platform. My personal favorite is OpenBSD on sparc, and in fact the two servers that I am running at my "lab" run that combination.

If you also want more relevant BSD experience before installing OpenBSD (which will help), I highly suggest playing with FreeBSD as well. In fact, FreeBSD makes excellent and powerfull workstations and desktops (as well as laptops). My only problem with FreeBSD and OpenBSD, is lack of support for a journaling FS, but there's also SOFTUPDATES available, which, while it isn't journaling, can provide a bit of the same functionality.

--
[T]he strongest man in the world is he who stands most alone. - Henrik Ibsen.

thanks (none / 0) (#47)
by scubacuda on Sun Nov 24, 2002 at 06:17:26 PM EST

Thanks for the kudos.

I thought about including that...

Perhaps in my second article.


There are a thousand forms of subversion, but few can equal the convenience and immediacy of a cream pie. Noel Godin
[ Parent ]

Updating (none / 0) (#96)
by pinkcress on Thu Nov 28, 2002 at 11:31:29 AM EST

I don't know about NetBSD, but FreeBSD is a doddle to keep updated (cvsup, buildkernel, buildworld..). What are you basing your "easiest BSD to keep updated" statement on?

---
damnit all these 'facts' getting in the way of my writing - turmeric
[ Parent ]
Due to the fact (none / 0) (#97)
by strlen on Thu Nov 28, 2002 at 02:22:11 PM EST

Even less is needed to upgrade OpenBSD. First we use normal CVS rather than cvsup, in addition less steps are required for an update (I've had experiences with both). But I agree, other BSD's are still easy to upgrade.

--
[T]he strongest man in the world is he who stands most alone. - Henrik Ibsen.
[ Parent ]
CVS vs. CVSup (none / 0) (#98)
by pinkcress on Thu Nov 28, 2002 at 05:24:06 PM EST

Both Open and FreeBSD offered FTP, CVS, CVSup and CTM access. So it's really down to which you prefer - not really a case of "we do it better".

I use CVSup because it works faster than CVS..

---
damnit all these 'facts' getting in the way of my writing - turmeric
[ Parent ]

OpenBSD, crashing (none / 0) (#50)
by gjetost on Sun Nov 24, 2002 at 07:38:49 PM EST

I tried installing OpenBSD 3.2 a week or so ago, to use as a web server and NAT / PAT server, on a 200mhz PPro + 40mb box, but had crashing problems so had to use Debian. Anyone else had crashing problems?

no (none / 0) (#51)
by scubacuda on Sun Nov 24, 2002 at 10:18:53 PM EST

I just installed it on a Dell Optiplex (800MHz) right before I wrote the article and had no problems...

I'll dig up an older computer and test it out.


There are a thousand forms of subversion, but few can equal the convenience and immediacy of a cream pie. Noel Godin
[ Parent ]

Crashing problems? (none / 0) (#52)
by strlen on Sun Nov 24, 2002 at 10:47:52 PM EST

Could you be more specific? What said by syslogd dmesg/(/var/log/*)? Kernel panic? Or were specific apps crashing? Seems to be strange, to just "crash" out of the blue, and same problem not have happened in Debian.

--
[T]he strongest man in the world is he who stands most alone. - Henrik Ibsen.
[ Parent ]
Werid HW? (none / 0) (#54)
by miro on Mon Nov 25, 2002 at 02:40:18 AM EST

Check this page to see if your HW is supported: http://www.openbsd.org/i386.html I run OpenBSD on older boxes(P133-200) all the time, no problem if the HW is sane.

[ Parent ]
pass out keep state flags S/SA (none / 0) (#56)
by mreardon on Mon Nov 25, 2002 at 07:52:34 AM EST

Its been a while since I messed around with pf and ipf but if I remember correctly it would be better to put the flags on the keep state for outgoing tcp traffic. This will mean the state tables are a lot leaner and meaner especially if there are lots of tcp connections outbound. Otherwise it will set up a new entry in the state table for each outbound tcp packet.

Pass out on xl0 proto tcp from any to any keep state flags S/SA
Pass out on xl0 proto udp from any to any keep state
Pass out on xl0 proto icmp from any to any keep state


uncapitalized... (5.00 / 1) (#64)
by scubacuda on Mon Nov 25, 2002 at 01:21:53 PM EST

Make sure you uncapitalize

"pass out on xl0...."

That was a mistrake in my article.  :/


There are a thousand forms of subversion, but few can equal the convenience and immediacy of a cream pie. Noel Godin
[ Parent ]

Bridging FW (4.50 / 2) (#57)
by El Volio on Mon Nov 25, 2002 at 08:19:57 AM EST

If you have the IP addresses available for your internal machines, you don't need to do NAT. Many DSL providers give you an 8-address subnet (6 usable, minus 1 more for the router, for 5 available addresses). If this is the case, you might consider a bridging firewall.

A bridge is a network device that separates two segments (typically Ethernet), while the same network exists on both sides. This can be useful in a number of instances, such as an "invisible" firewall -- nothing on your network needs to be reconfigured to use it, and you may not even need to assign it an IP address.

To do so in OpenBSD, it's pretty simple. In /etc, create a file for each interface that will be used as "hostname.IFNAME". I use quad Ethernet cards on Sparc boxes, so for me, it's qe0, qe1, and so on, but you may have xl (as in the text above). Note that you should not replace "hostname" with the actual system name; that word should be used literally. So in each "hostname.qe0", "hostname.qe1", just put the word "up". Then create a file called "bridgename.bridge0" with the commands to create a bridge; you will probably need something like "add qe0 add qe1 up". On reboot, you will have those two interfaces tied together in a bridge. Note that you don't have to reboot and can set this up from the command line with the sequence:

ifconfig qe0 up
ifconfig qe1 up
brconfig bridge0 add qe0 add qe1 up

If you really want to have an IP address on one of the systems, that's OK, just configure it normally. This might be useful for logging or remote administration.

Finally, this will necessitate a few considerations in your pf.conf file. While pf is considerably more flexible than ipf in this regard, it's good practice to pass everything in and out on the internal interface, then do all your rules on the external interface. You also might find it easier if you designate aliases in the pf.conf file for your external and internal interfaces. To do this, put two lines at the top that say external="qe0" and internal="qe1". Then, in each rule, write it as pass in quick on $external proto tcp from any to http or whatever you're trying to do.

There are a lot of security benefits to doing it this way. For one, it's not immediately obvious to an attacker that you have a firewall; if you don't configure it with an IP address, it can't be attacked normally. Well, that's not strictly true, there are some funny things that can be done with attacks against the MAC address, but he'll have to be on your local network first to do it, and most attackers don't have that level of skill. Another is that, depending on your network configuration, it might be easiest and let you add a firewall with a minimum of impact to your network configuration. Plus it's 31337 (oops...)

Highly Recommended but Some Issues (none / 0) (#67)
by 0xA on Mon Nov 25, 2002 at 03:43:35 PM EST

I am whipping one of these up to replace my OpenBSD 2.9 box at work.

Very cool but I am having some little issues. My provider dosen't give out real static IPs, if you want one you register your MAC address with them and they will give you the same IP via DHCP every time. You also can't just grab the address and staticly configure it, they actually build the route for your machine automagically when the lease is given. I know this sounds overly complicated and prone to failure and it is but I am stuck at the moment.

I am using the bridge in between the DSL modem and the switch for my DMZ. I have it working okay but I want a better ruleset for the DHCP traffic. I'm currently allowing all port 68 traffic, I don't like that much.

The bridge mode pf is a great thing but it can cause some interesting little issues on occasion.

[ Parent ]

Good point..... (none / 0) (#72)
by mindstrm on Mon Nov 25, 2002 at 10:28:04 PM EST

It's very common nowadays for anyone to think "Firewall" and immediately think of some kind of NAT (network address translation) or, thanks to Linux, "Masquerading".

NAT was never designed as a security measure. Although any given implementation of masquerade/nat may have certain security features (for instance, only permitting tcp connections to initiate from one side of the firewall), that doens't mean they were designed with security in mind. NAT is for just that.. address translation. Security should be handled separately.

Any security benefits you percieve with NAT can be had without it just as easily.

[ Parent ]

Honeypots (5.00 / 1) (#58)
by El Volio on Mon Nov 25, 2002 at 08:24:19 AM EST

Honeypots are useful and interesting, but something should be noted: never set up your firewall with "honeypot capabilities" as the author suggests. It should be a dedicated machine, preferably firewalled off from the rest of your network. Allowing attackers to have any access to the same machine that enforces your local security policy (which is what a firewall does) is a clear violation of most security best practices.

Also note that honeypots require a great deal of care and feeding; they're not "fire and forget", so don't expect to set one up and magically learn a lot. It'll take work on your part, too.

you're aboslutely right (none / 0) (#61)
by scubacuda on Mon Nov 25, 2002 at 12:56:21 PM EST

I should have made that distinction in my article... Thanks.
There are a thousand forms of subversion, but few can equal the convenience and immediacy of a cream pie. Noel Godin
[ Parent ]
FYI: Article on OpenBSD Journal (none / 0) (#60)
by Platy on Mon Nov 25, 2002 at 09:29:21 AM EST

Congrats, your article got linked at OpenBSD Journal!
Just thought I'd tell :-)
--
Tongue-tied and twisted, just an earthbound misfit, I.
cool, thanks... (none / 0) (#62)
by scubacuda on Mon Nov 25, 2002 at 01:05:48 PM EST

I just e-mailed creining and thanked him for linking me.

:)


There are a thousand forms of subversion, but few can equal the convenience and immediacy of a cream pie. Noel Godin
[ Parent ]

typo (none / 0) (#65)
by scubacuda on Mon Nov 25, 2002 at 01:42:18 PM EST

Should read:

"To enable the firewall, type pfctl -e pf.conf"


There are a thousand forms of subversion, but few can equal the convenience and immediacy of a cream pie. Noel Godin

OpenBSD -vs- the rest. (4.00 / 2) (#70)
by mindstrm on Mon Nov 25, 2002 at 06:19:36 PM EST

I know I'm asking for it here... especially after a rather good article.. however.

It is important for people to realize that, although OpenBSD is known for being "secure".... that security is mostly due to having well audited services running by default, and then, not many of them.

It's ability to provide security for a network is not directly related to this at all.  It's kind of like saying "Safes manufactred by company X are the msot secure in the world, so let's use one to secure the stage area for the next concert". Unrelated. The analogy is not, of course, correct.. as the firewall itself has to be secure, but by turning off unneeded services (which on a firewall is, well, everything, except for maybe SSH if you want remote access) you get the same level of security as you do with openbsd.

OpenBSD may make a neat packet filter, but linux makes a better one. More features, more filtering.. POLICY ROUTING which comes in really handy in some cases... just generally MORE to choose from when building a firewall.

OpenBSD security (5.00 / 1) (#74)
by El Volio on Tue Nov 26, 2002 at 08:46:19 AM EST

The security of OpenBSD is based on considerably more than code auditing, as important as that component is. The heavy use of encryption throughout the OS (e.g. encrypted swap, etc.), the fact that it comes 90% hardened (including things like diffing /etc every night), and similar tasks show that it has an overall focus on security.

I'm not overly familiar with the firewalling features anymore in Linux. I used them some time ago (early in the 2.2 series, IIRC), but soon discovered that, like many things in Linux, its firewalling capabilities didn't match with the way I conceptualized things, as at the time I was a full-time Checkpoint FW-1 admin. As with other aspects of the OS, OpenBSD concentrates on doing whatever it does well, rather than doing a lot of different things. That said, I've yet to see something that Linux can do in this particular arena that OpenBSD can't (that certainly doesn't mean that no such feature exists).

I'm not bashing Linux here; it's a fine OS and one with a well-deserved place in many operations. Sometimes that place might even be firewalling. But let's not suggest that it's universally better-suited as a firewall or that OpenBSD's focus on security is irrelevant in this regard.

[ Parent ]

I'll bite. (none / 0) (#83)
by mindstrm on Tue Nov 26, 2002 at 04:50:10 PM EST


Yes.. it has audited code. Yes it's "hardened". But my point is that things like encrypted swap HAVE NOTHING AT ALL to do with how well it can act as a firewall for a network. As a server, yes, as a multi-user platform, yes.. but as a firewall? Not really relevant.

You don't diff your firewall every night (or you shouldn't). You don't CHANGE a firewall automatically every night... for reasons that should be obvious.

Yes... you haven't used linux firewalling since 2.2. I, on the other hand, have extensively used both. I'm telling you flat out that OpenBSD's firewalling code is not anywhere near as flexible or functional as that available in Linux 2.4. Neither is it's routing, which is also related to firewalling.

Linux firewalling *IS* universally better, from a technical point of view. Of course, that doesn't mean it's better in every case; OpenBSD is easier to configure, and there are less ways you can screw up (because the system is simpler and less flexible overall), and the OS is more or less secure. That makes it a better solution for some people.

I also never said it's focus on security was irrelevant...

I was trying to put some perspective down. People seem to more and more think OpenBSD is the best firewall solution because of it's  "focus on security".. when, in fact, most of the "security" features are not related whatseover to a properly configured firewall.

OpenBSD can't do policy routing... there's a start.

OpenBSD is good, openbsd is great.. but it's not the be-all end-all of firewalling.

[ Parent ]

We're not actually that far apart (none / 0) (#85)
by El Volio on Tue Nov 26, 2002 at 05:35:01 PM EST

You're certainly correct that encrypted swap isn't important to firewalling per se. But it (and the rest of the system hardening that should be done no matter the OS) are important for any bastion host; that goes double for the devices that enforce your security policy. In fact, many of those practices vis-a-vis system hardening need to be put into place on any OS; an extensive hardening policy can really save the day even should you have a compromise. Defense in depth — belts and suspenders.

Routing and firewalling are not necessarily related. In fact, in most true enterprise environments (where most of my experience is), routing and firewalling are separated as much as possible. Dirty-side router, firewall, clean-side router. We're trying to eliminate the last few cases where the firewall does any routing at all — and we are talking about several hundred firewalls here (yes, this is a really large organization). Policy routing is almost a red herring: I'm honestly curious how much it's actually deployed in the field. And I believe that in the environments where Linux and OpenBSD are best suited as firewalls (see below), it's not really appropriate for that network.

Diffing your config files isn't just to know when you've made a change. It's to let you know when a change was made, and in situations where (a) you're concerned about security and (b) you have more than one admin (it's been years since I was the only admin on a system or even seen a system with only one admin). And it has nothing to do with automatic changes; it lets you know when anything changed; in fact, much of what's done in this area could be viewed as a poor man's HIDS.

But I don't actually believe that OpenBSD is the be-all end-all of firewalling. In fact, I would daresay it works best in small to mid-size network environments (under 25 firewalls, no real enterprise rulebase management needed). pf is not well suited to the sort of extensive firewalling environment I describe above, at least not without considerable extra work. At that level, neither is Linux. Something like Checkpoint FW-1 on Solaris, or perhaps even Gauntlet, will do a much better job and be much easier to manage. Again, proper hardening can nearly equalize most of these systems.

In reality, I don't think we're that far apart, really, but are simply where personal preferences and the sorts of environments we commonly make the difference. Choose the tool that works best for your environment (technically and organizationally), whether that be Linux, OpenBSD, Solaris, or something else.

[ Parent ]

Two words (none / 0) (#77)
by lb008d on Tue Nov 26, 2002 at 10:16:24 AM EST

It is important for people to realize that, although OpenBSD is known for being "secure".... that security is mostly due to having well audited services running by default, and then, not many of them.

Code auditing.

"Kuro5hin: politics and pretension, from the $3,000 leather recliners on the hill overlooking the trenches."DarkZero
[ Parent ]

Two words (2.50 / 2) (#79)
by samedi on Tue Nov 26, 2002 at 12:47:19 PM EST

Racist bastard


i am the king... of no pants! - www.penny-arcade.com
[ Parent ]
Yeah (none / 0) (#82)
by mindstrm on Tue Nov 26, 2002 at 04:41:49 PM EST

Didn't I say "well audited"?

The point is, the only code that *matters* in this case is the kernel itself.

[ Parent ]

Except that (none / 0) (#84)
by lb008d on Tue Nov 26, 2002 at 05:09:54 PM EST

the kernel as well as services are audited. Thus your statement

by turning off unneeded services ... you get the same level of security as you do with openbsd.

is incorrect. The Linux kernel has not underwent the same code audit that OpenBSD has. Which is why people who need relaible firewalls/filters praise OpenBSD so highly.

"Kuro5hin: politics and pretension, from the $3,000 leather recliners on the hill overlooking the trenches."DarkZero
[ Parent ]

Linux firewalling *IS* universally better (none / 0) (#91)
by mreardon on Wed Nov 27, 2002 at 07:05:19 AM EST

OK, I am not that up on Linux firewalling so can you help me? When would policy routing come in really handy? I had a browse through policyrouting.org and am none the wiser. Perhaps because some of the links don't work. Espeically the ones with simple and complex real world examples. I just can't (yet) imagine where I would want to do this in my firewall. Is it QoS thing?
It is important for people to realize that, although OpenBSD is known for being "secure".... that security is mostly due to having well audited services running by default, and then, not many of them. It's ability to provide security for a network is not directly related to this at all.
I disagree here. If the local services are not audited and secured, how can openbsd then offer these services to the internal network? I am thinking of points 2.4 and 2.5 here.

More filtering
...What do you mean here? Are you talking about QoS mangling?

Personally, I am attracted to the stealth/bridging and normailizing part of pf. I am not trolling here. I can see that iptables is a great piece of software, just trying to understand where your statement "Linux firewalling *IS* universally better" comes from.

[ Parent ]

Answers (4.00 / 1) (#93)
by mindstrm on Wed Nov 27, 2002 at 06:01:15 PM EST

First.. regarding audited services. My point is that those services do NOT need to run on a firewall. A firewall does not need to run an ftp server or telnet server or even an ssh server, strictly speaking. Therefore the fact that the rpc services, ftpd, httpd, etcetera, are audited doesn't really matter.

Policy routing is when I want to say, for instance.  "If it came FROM box X, route it to gateway 1, but if it came FROM box Y on port Z, route it to gateway 2, and route everything else through gateway 3" or

"If the remote box accessed us via IP1, then use gateway 1 for return traffic. If it accessed us via IP2, use gateway 2.".

In the case of linux, this means multiple routing tables and the ability to select which table you want to process a packet againts based on any arbitrary decision.

More filtering. I mean FW marking, complex rulesets, more stages at which to insert code for doing filtering/nat/routing/mangling. Just plain more flexible.

I'm not trying to say "Linux is better for everyone"... OpenBSD is a nice, tight firewalling package... let me rephrase and say "Linux firewalling is more feature-rich and flexible"

[ Parent ]

I certainly agree (none / 0) (#95)
by mreardon on Thu Nov 28, 2002 at 04:37:29 AM EST

Linux firewalling is feature rich and flexible. Thanks for the info.

[ Parent ]
2.4 & 2.5 (none / 0) (#94)
by mindstrm on Wed Nov 27, 2002 at 06:02:46 PM EST

On points 2.4 & 2.5, you have a point.. those *are* very cool features specific to firewalling. But those don't have much to do with audited services.


[ Parent ]
Text editor nitpicking (5.00 / 1) (#71)
by LodeRunner on Mon Nov 25, 2002 at 06:36:24 PM EST

You say that vi is "radically different than any of the editors you're used to--Word, Notepad, Pico, etc." and then point out the user to "a vi clone, such as Nano".

Nano, as the name and the cool look of their webpage suggest, is a clone of Pico, which is definitely not a vi clone.

In the next relase of our very unorthodox Linux distribution it will be provided as the default text editor (we have a policy of not shipping vi in the default base package ;-) ) since Nano's interface actually makes sense and does not depend on a whole mail client (Pine) or file manager (as mcedit, shipped with mc, does). Obviously, Vim is available in the distro as a separate package.


---
"dude, you can't even spell your own name" -- Lode Runner

Thanks for a great article! (none / 0) (#76)
by SteveTheRed on Tue Nov 26, 2002 at 10:04:17 AM EST

I've been wanting to breathe new life into my old Acer K6-233 by using it as a firewall, but I was daunted by the sheer volume of information that Googling provides.

Thanks for boiling it down into one easy to read article. It still looks complicated, but at one time I thought that I was never going to be able to learn (much less like) Linux ;)

One nit though -- there is now way in hell that I am going to use vi. All copies of vi and ed should be put on a rocket and shot into the sun. I'll use nano, the editor for people who don't want to torture themselves.



Thanks (none / 0) (#78)
by scubacuda on Tue Nov 26, 2002 at 11:04:50 AM EST

I'm very new to the *BSD world (in fact, I installed OpenBSD for the first time a couple of weeks ago).

I tried to write the sort of article I would have liked to read before I started.  :)


There are a thousand forms of subversion, but few can equal the convenience and immediacy of a cream pie. Noel Godin
[ Parent ]

before you consider supporting openbsd... (1.60 / 5) (#80)
by samedi on Tue Nov 26, 2002 at 12:52:27 PM EST

ask yourself... do I really want to encourage this anti-social racist jerk?


i am the king... of no pants! - www.penny-arcade.com
I'd be interested to know... (none / 0) (#92)
by mreardon on Wed Nov 27, 2002 at 07:39:25 AM EST

How long do your laptop batteries last up there on your moral high horse? And what O/S has passed your "strict" criteria and been deemed worthy of your support.

[ Parent ]
'scuse me? (4.00 / 2) (#86)
by mdekkers on Tue Nov 26, 2002 at 11:24:15 PM EST

"Because the Internet's basic building blocks (rooted in ARPANET 's decentralized architecture) are open sourced, they have been incredibly succeptible to insecure implementations and abuse."

WTF? You lost a lot of credibillity in my mind by making this statement. The building blocks in this context are RFC's. Now, whether or not an RFC is open source in the true sense of the word does not matter much. But could you please explain to me how you would make an effective standard while keeping the specifications secret? Unless you are suggesting that Microsoft should have built the Internet.

Taking a wider view of this erroneous statement, you seem to claim that opensource software is inherently insecure - a claim that has been widely refuted, even so by your own logic. If opensource is so insecure, why run a Firewall on OpenBSD?

Insecure implementations (none / 0) (#87)
by El Volio on Tue Nov 26, 2002 at 11:39:35 PM EST

While I can't speak for the author or what he meant, I would say that many implementations of the various standards set forth in the RFCs are insecure — the SNMP problems in Feb 2002 alone are witness to that. Then there's SMTP (Sendmail's old problems), HTTP, FTP... you name it, somebody's done a half-assed job and caused the rest of us a lot of grief at one point.

Not that I can think of a better way; putting the standards out there for everybody to see is about the only way to do it and avoid much worse problems.

[ Parent ]

Insecure Implementations (none / 0) (#88)
by mdekkers on Tue Nov 26, 2002 at 11:50:48 PM EST

Correct, but that is not what he is saying. Literally, he is saying that because the standards are open source, the implementations are insecure. This is, of course, incorrect. Moving past that, he seems to imply that open source is by default insecure, due to the ready availibillity of source code. This is a rather short sighted and silly comment to make - especially in an article that goes on to praise the security of an open source product.

[ Parent ]
point taken--a very careless mistake on my part (none / 0) (#89)
by scubacuda on Wed Nov 27, 2002 at 01:00:07 AM EST

"Open sourced" WAS a very poor choice of words.  (Someone else pointed that out to me also)

"Open to abuse" is a side effect of both "open" and "closed" source.  It was sloppy of me to imply that it was was a result of open source...<

Thanks for the comment.  I have already e-mailed Rusty and asked if I could submit a revised version...


There are a thousand forms of subversion, but few can equal the convenience and immediacy of a cream pie. Noel Godin
[ Parent ]

really is no better way... (none / 0) (#90)
by scubacuda on Wed Nov 27, 2002 at 01:17:35 AM EST

But could you please explain to me how you would make an effective standard while keeping the specifications secret?

There really is no better way to do it.  When you make something open for others to build on, there are always going to be low lifes who use it for mischief.

Personally, my bias is towards open standards.  When these low lifes engage in their mischief, I like to think that the rest of the world bands together to stop them....

Thanks again for your comment.  Point taken.


There are a thousand forms of subversion, but few can equal the convenience and immediacy of a cream pie. Noel Godin
[ Parent ]

Check out the LEAF project (none / 0) (#99)
by GLuft3 on Thu Nov 28, 2002 at 09:12:01 PM EST

Nice article. It just might be the thing I need to get me to give OpenBSD a look. Now all I need is the spare time in which to do it.

If you're looking for a Linux firewall that is easy to set up, is well supported (by a friendly mailing list), and fits on a diskette, then check out the Linux Embedded Appliance Firewall (LEAF) project: leaf.sourceforge.net.

Guide to OpenBSD Packet Filtering Firewalls | 101 comments (75 topical, 26 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!