IPFW Rules on VPN CFG

I already published the IPFW rules I'm using to defend my sensors, so I figured I would add the IPFW rules I'm using on my VPN concentrator / firewall / gateway (CFG). I relied on the FreeBSD Handbook examples heavily, as the placement of certain sections is crucial when the CFG is also NAT box.

In these rules, interface xl0 is the interface facing the "Internet" while fxp0 faces a private internal network. Host bourque is a remote sensor with IP 192.168.2.7.

Since this entire setup exists in a lab, the 192.168.2.0/24 addresses are considered "public" addresses.

#!/bin/sh

pub="xl0"
pri="fxp0"
cmd="ipfw -q add "
ks="keep-state"
skip="skipto 500"
vpncfg_ip="192.168.2.7"
bourque_ip="192.168.2.10"
nameserver="192.168.2.1"
ok_tcp_out="22,80"
ok_udp_out="53,123"

ipfw -q -f flush

$cmd 002 allow all from any to any via $pri
$cmd 003 allow all from any to any via lo0

$cmd 100 divert natd ip from any to any in via $pub
$cmd 101 check-state

# Authorized outbound traffic
$cmd 120 $skip udp from any to any $ok_udp_out out via $pub $ks
$cmd 121 $skip tcp from any to any $ok_tcp_out out via $pub setup $ks
$cmd 122 $skip icmp from any to any out via $pub $ks
# ISAKMP
$cmd 123 allow udp from me to $bourque_ip 500 out via $pub $ks
# IPSec ESP
$cmd 124 allow esp from me to $bourque_ip out via $pub $ks
# ICMP
$cmd 125 allow icmp from me to any out via $pub $ks

# Deny all inbound traffic from non-routable reserved address spaces
#$cmd 300 deny all from 192.168.0.0/16  to any in via $pub  #RFC 1918 private IP
#$cmd 301 deny all from 172.16.0.0/12   to any in via $pub  #RFC 1918 private IP
#$cmd 302 deny all from 10.0.0.0/8      to any in via $pub  #RFC 1918 private IP
#$cmd 303 deny all from 127.0.0.0/8     to any in via $pub  #loopback
#$cmd 304 deny all from 0.0.0.0/8       to any in via $pub  #loopback
#$cmd 305 deny all from 169.254.0.0/16  to any in via $pub  #DHCP auto-config
#$cmd 306 deny all from 192.0.2.0/24    to any in via $pub  #reserved for docs
#$cmd 308 deny all from 224.0.0.0/3     to any in via $pub  #Class D & E multicast

# Authorized inbound traffic
$cmd 400 allow tcp from 192.168.2.5 to me 22 in via $pub setup $ks
# ISAKMP
$cmd 401 allow udp from $bourque_ip any to me 500 in via $pub $ks
# IPSec ESP
$cmd 402 allow esp from $bourque_ip any to me in via $pub $ks
# ICMP
$cmd 403 allow icmp from $bourque_ip any to me in via $pub $ks

$cmd 450 deny log ip from any to any

# This is skipto location for outbound stateful rules
$cmd 500 divert natd ip from any to any out via $pub
$cmd 510 allow ip from any to any

For now I've disabled the RFC 1918 address blocking section, as it's not an issue where this VPN CFG is located.

Comments

Anonymous said…
Yuck ! Almost as bad as IPTables and just as 'easy' to maintain.

I assume this is on 5.3 or above.

Do yourself a big favour,


~ # grep -i pf /etc/rc.conf
pf_enable="YES"
pf_logd="YES"
pf_conf="/etc/pf.conf"


& 5 minutes perusing

http://www.openbsd.org/faq/pf/index.html

Making for an easier to maintain, readable policy which is syntax checked before loading, so that a typo doesnt inadvertantly lock you out and far more performant (critical on a heavily loaded sensor device), especially when you consider that natd is a userland process.


cheers

Greg
4:39 PM
Post a Comment

Popular posts from this blog

MITRE ATT&CK Tactics Are Not Tactics

Image
Just what are "tactics"? Introduction MITRE ATT&CK  is a great resource, but something about it has bothered me since I first heard about it several years ago. It's a minor point, but I wanted to document it in case it confuses anyone else. The MITRE ATT&CK Design and Philosophy document from March 2020 says the following: At a high-level, ATT&CK is a behavioral model that consists of the following core components: • Tactics, denoting short-term, tactical adversary goals during an attack; • Techniques, describing the means by which adversaries achieve tactical goals; • Sub-techniques, describing more specific means by which adversaries achieve tactical goals at a lower level than techniques; and • Documented adversary usage of techniques, their procedures, and other metadata. My concern is with MITRE's definition of "tactics" as "short-term, tactical adversary goals during an attack," which is oddly recursive. The key word in the tacti...
Read more

Zeek in Action Videos

Image
This is a quick note to point blog readers to my Zeek in Action YouTube video series for the Zeek network security monitoring project .  Each video addresses a topic that I think might be of interest to people trying to understand their network using Zeek and adjacent tools and approaches, like Suricata, Wireshark, and so on.  I am especially pleased with Video 6 on monitoring wireless networks . It took me several weeks to research material for this video. I had to buy new hardware and experiment with a Linux distro that I had not used before -- Parrot .  Please like and subscribe, and let me know if there is a topic you think might make a good video.
Read more

New Book! The Best of TaoSecurity Blog, Volume 4

Image
  I've completed the TaoSecurity Blog book series . The new book is  The Best of TaoSecurity Blog, Volume 4: Beyond the Blog with Articles, Testimony, and Scholarship .  It's available now for Kindle , and I'm working on the print edition.  I'm running a 50% off promo on Volumes 1-3 on Kindle through midnight 20 April. Take advantage before the prices go back up. I described the new title thus: Go beyond TaoSecurity Blog with this new volume from author Richard Bejtlich. In the first three volumes of the series, Mr. Bejtlich selected and republished the very best entries from 18 years of writing and over 18 million blog views, along with commentaries and additional material.  In this title, Mr. Bejtlich collects material that has not been published elsewhere, including articles that are no longer available or are stored in assorted digital or physical archives. Volume 4 offers early white papers that Mr. Bejtlich wrote as a network defender, either for technica...
Read more