Simple IPFW Rules to Defend Sensors

I'm considered deploying the following rule set on a new batch of network security monitoring sensors running the FreeBSD IPFW firewall. I'm running the IPSec tunnel scenario I outlined earlier to carry packets between the sensor and a VPN concentrator / firewall / gateway (VPN CFG) running FreeBSD.

My goal is to limit who the sensor can talk to, and to limit who the sensor accepts connections from. In this case, I'm telling the sensor to speak only with the VPN CFG and a specified DNS server. I leave the option of adding additional permitted systems, such as a trusted host that is allowed to SSH directly to the sensor for maintenance purposes.

Here is the rule set I plan to run on the sensors. 192.168.2.10 is the sensor management IP. 192.168.2.7 is the VPN CFG management IP. 192.168.2.1 is the nameserver.

#!/bin/sh

int="fxp0"
cmd="ipfw -q add "
mgt_ip="192.168.2.10"
vpncfg_ip="192.168.2.7"
nameserver="192.168.2.1"

ipfw -q -f flush

$cmd 00500 check-state

# Allow connections initiated by remote systems

# SSH from specified hosts
$cmd 01000 allow tcp from $vpncfg_ip any to $mgt_ip 22 in via $int keep-state

# ISAKMP
$cmd 01100 allow udp from $vpncfg_ip any to $mgt_ip 500 in via $int keep-state

# IPSec ESP
$cmd 01200 allow esp from $vpncfg_ip to $mgt_ip in via $int keep-state

# ICMP
$cmd 01300 allow icmp from $vpncfg_ip to $mgt_ip in via $int keep-state

# Allow connections initiated by local system

# SSH to VPNCFG 
$cmd 02000 allow tcp from $mgt_ip any to $vpncfg_ip 22 out via $int keep-state

# ISAKMP 
$cmd 02100 allow udp from $mgt_ip any to $vpncfg_ip 500 out via $int keep-state

# IPSec ESP
$cmd 02200 allow esp from $mgt_ip any to $vpncfg_ip any out via $int keep-state

# ICMP
$cmd 02300 allow icmp from $mgt_ip any to $vpncfg_ip out via $int keep-state

# DNS resolution
$cmd 02400 allow udp from $mgt_ip any to $nameserver 53 out via $int keep-state

# Default deny all
$cmd 03000 deny log all from any to any

Does anyone have any comments?

Comments

Anonymous said…
Why not use PF?
7:11 PM
Richard Bejtlich said…
I considered using Pf, but I had already compiled IPFW support into the kernel on the sensor. I was also using IPFW on the VPN CFG as described in my IPSec article.
8:22 PM
Anonymous said…
I second using PF. It seems to be a more popular choice these days. Not that popularity is a basis for choosing a firewall... ;). I'm a big fan of PF anyways. It works great and its written by some pretty talented coders, IMO.
10:19 PM
Richard Bejtlich said…
When I build dedicated firewalls, I build them on OpenBSD using Pf.
7:00 AM
Anonymous said…
When I originally did this setup at BATC MNSS (ah the good ole days ;) ), we had problems with IPF (yes I realize IPF != PF) and IPSEC playing nice with each other (I don't remember the details). With IPFW we ran into another set of issues where each packet is processed twice. IPFW would first process the packet as it came in as ip proto 50 and again after the packet was decrypted (still retaining the "in via interface" tag). This means you could run into headaches if you start blocking RFC 1918 addresses on your external interface like all good security guys/gals do ;)

Bammkkkk
9:47 AM
Post a Comment

Popular posts from this blog

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

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

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