So, you think you're a bigshot now? OR How to build an OpenBSD-based
firewall.

What you'll need:

     An OpenBSD supported machine-- I've been using P5/166's lately
     with Bay Networks DIGITAL 21140-basd OEM cards and 1 Gig of
     diskspace with 32M of RAM. I've seen everything used from cheap
     Alphas and Sparcs. You'll need either two NICs or one NIC and a
     modem or ISDN card that looks like a modem. Chances are, if you're
     building a firewall, you know what hardware you'll need.

Where to start:

     This HOWTO assumes you are pretty familiar with the OpenBSD
     operating system and how to install it and do some basic
     configuration of the system. If you don't have these skills,
     please read my OpenBSD Newuser FAQ (www.openbsd.org/faq) as well
     as afterboot(8) and the related install documentation for your
     hardware platform.

What to do:

  1. Compile a new custom kernel
  2. Turn off any extra services
  3. Hack out ipf.rules and nat.rules configuration
  4. Hack out sendmail.cf configuration
  5. reboot and test, reboot and test, fix, reboot, and test.
  6. Go offsite and test
  7. Hire someone (me?) and have them test
  8. "Rest Secure with OpenBSD" (Hey, I designed that lame logo!)
  9. Custom things.... daemons, piping input

1. Compiling a custom kernel

This is covered in the Newuser-FAQ, but there are a few options that need to
be turned on, as well as some things to keep in mind:

  1. Streamline the hell out of the kernel-- axe all excess drivers and
     devices that you don't need.
  2. add "option GATEWAY" so that internal folks can get out
  3. You can take out extra FS support if you think that is advisable... you
     may even want to take out floppy support if you are completely
     paranoid. Actually, my systems don't HAVE floppy drives after I do the
     install....

2. Turn off any extra services

  1. Edit /etc/rc.conf to make sure you have nfs turned OFF
  2. Edit out as many services as you can from /etc/inetd.conf

3. Hacking ipf.rules and nat.rules configuration files

  1. Take a look at /usr/share/ipf/ and find an ipf.rules that looks like
     something you'd like to use. Edit it for your site. Stick your creation
     in /etc/ipf.rules
  2. See #1 and do the same thing for nat.rules. Stick your creation in
     /etc/nat.rules
  3. Edit /etc/rc.conf so that ipf and ipnat are turned ON.

4. Hacking sendmail.cf

You'll want to turn sendmail OFF if you aren't using it as a relay or proxy
for incoming mail.

There are 600 page books written on this subject. There are 26-year-old
females who sell firewalls for V-1, Inc. who have sendmail.cf memorized (too
much LDS in the 60's).

     Macros to take a look at:
   * Dj$w.
   * DR
   * DH
   * comment out CE
   * DZ (if you want to confuse people...)
   * MaxMessageSize (if you want to limit message sizes) You may want to
     change sendmail.hf to be less helpful or have witty retorts for "HELP
     VRFY".

5. Reboot.

   * Telnet to port 25 and send some generated mail. If you can't do this on
     your own......
   * Telnet to known ports, and see what happens

6. Do #5 from off-site (home)

9. Custom Configurations

One of the sites where I've contracted, we had an "internal-ish" webserver
that we needed to allow people into. OpenBSD comes with netcat, which allows
you to do neat things. Using netcat as a sort of "proxy" one can
transparently allow sessions from outsite the firewall to servers on the
inside. A typical inetd.conf entry for this looks like:

     www stream tcp nowait nobody /usr/libexec/tcpd /usr/bin/nc -w 3
     internal_host port_number

Check the nc(1) manpage for more info on netcat. Make sure that you are
using tcpwrappers as well. Happy firewalls have lots of logs.

To make your system even more secure, you can make "root" the only account
on the system (or you can even lock that) and make as many programs as you
can non-suid. This reduces the risk of some suid program's unknown buffer
overflow taking over your system. You can't un-suid sendmail if it is
running as a daemon, as it needs to be root to bind to a priviledged port.

Epilogue:

I know this is pretty spartan documentation. I never professed to be a
technical writer-- I just teach Unix Systems Administration and am a systems
contractor.

(c) 1997 J. Joseph Max Katz and CPIO Network Security