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. is the sensor management IP. is the VPN CFG management IP. is the nameserver.


cmd="ipfw -q add "

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

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

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

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

# Allow connections initiated by local system

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

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

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

$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?


Anonymous said…
Why not use PF?
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.
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.
When I build dedicated firewalls, I build them on OpenBSD using Pf.
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 ;)

Mark Shaw said…
Hey Richard-

Why don't you use PF?


Popular posts from this blog

Five Reasons I Want China Running Its Own Software

Cybersecurity Domains Mind Map

A Brief History of the Internet in Northern Virginia