[CALUG] Vulnerability Scanner knocks down firewall

[Jason Dixon]

On Dec 12, 2005, at 7:39 PM, Mark Parsons wrote:

> Hello Everyone,
>
> I am currently having an issue with a pf based openbsd firewall that
> fronts several oracle servers, apache, tomcat and jrun
> servers.Recently the network vulnerability scanner that is used by the
> security office knocked down all resources behind the firewall. All
> attempts by their scanner and ours produce the same results.

Is this new behavior on a previously well-behaving firewall?  Or did  
the behavior just start with the introduction of the scanner?

>  We have been doing some testing and a simple tcp port scan with nmap
> (nmap -sT -p 1-10000 ...) to a host (protected by the firewall) causes
> the firewall to not accept new SYN connections but will usually allow
> SYN to go outbound (sometimes). However existing connections are
> always supported.  Within 1 minute after the scan is finished, all
> things recover.  Doing a udp scan does not affect the system.
>
> The servers in question are openbsd 3.6, we have upgraded the test
> server to 3.8 and the symptoms are still there.  Below is the pf.conf
> for the test server that is front a single server that is hosting a
> static website under a Suse Linux Enterprise Server 9 system running
> apache 2.0.53

Comments within.

> We have tried adding flags S/SA and using modulate state to our pf
> entries but still had no luck.

Modulate state is for randomizing the TCP sequence ID for systems  
with predictable TCP sequences.  This should not be needed for a  
Linux server.  However, you SHOULD consider using synproxy state,  
which forces the OpenBSD firewall to complete the initial TCP  
handshake before handing the connection off to the internal host.

> Does any one have any suggestions ? Any and all suggestions are very
> much appreciated.
>
> ext_if="bge0"
> int_if="bge1"
> pri_net="192.168.100.0/24"
>
> network_monitor="xxx.xxx.xxx.xxx"
> vuln_scan="{xxx.xxx.xxx.xxx, xxx.xxx.xxx.xxx}"
>
> fs1_test_pub="xxx.xxx.xxx.121"
> fs1_test_pri="192.168.100.48"
>
> set loginterface $int_if
> set block-policy  drop
>
> binat on $ext_if from $fs1_test_pri to any -> $fs1_test_pub
>
> #block in log all
> #block out log all
> block in all
> block out all
>
> pass quick on lo0 all
> anchor "authpf/*"
> #This allows ssh traffic with out needing authpf
> pass in on $ext_if proto tcp from any to $ext_if port 22 keep state
> pass in on $ext_if proto tcp from any to $fs1_test_pri port 22 keep  
> state

The $ext_if macro also doesn't expand like you think it does.  First,  
you probably want to surround it with parentheses (see the manpage  
for details), and likely also use one of the interface modifiers.   
You probably want the rules to look like this:

pass in on $ext_if inet proto tcp from any to ($ext_if:0) port 22  
flags S/SA keep state
pass in on $ext_if inet proto tcp from any to $fs1_test_pri port 22  
flags S/SA synproxy state

> #This allows port 80 traffic to test box natted behind firewall
> pass in on $ext_if proto tcp from any to $fs1_test_pri port 80 keep  
> state

pass in on $ext_if inet proto tcp from any to $fs1_test_pri port 80  
flags S/SA synproxy state

> # Allow icmp access for Vuln_Scanner
> pass in on $ext_if proto {tcp, udp, icmp} from $vuln_scan to  
> $ext_if keep state
> pass in on $ext_if proto {tcp, udp, icmp} from $vuln_scan to  
> $pri_net keep state

Break your rules down so we can use the TCP options mentioned  
previously.  Also, it might be shorter for you to remove the $pri_net  
macro and use the ":network" modifier.  Examples:

pass in on $ext_if inet proto tcp from $vuln_scan to ($ext_if:0)  
flags S/SA keep state
pass in on $ext_if inet proto { udp, icmp } from $vuln_scan to  
($ext_if:0) flags S/SA keep state
pass in on $ext_if inet proto tcp from $vuln_scan to  
($int_if:network) flags S/SA synproxy state
pass in on $ext_if inet proto { udp, icmp } from $vuln_scan to  
($int_if:network) keep state

> # These allow for nagios to be able to monitor the servers
> pass in on $ext_if proto icmp from $network_monitor to $ext_if keep  
> state
> pass in on $ext_if proto icmp from $network_monitor to $pri_net  
> keep state

You probably only mean to allow inbound ping.

pass in on $ext_if inet proto icmp from $network_monitor to ($ext_if: 
0) icmp-type echoreq keep state
pass in on $ext_if inet proto icmp from $network_monitor to  
($int_if:network) icmp-type echoreq keep state

> pass in on $ext_if proto tcp from $network_monitor to $pri_net port
> 5666 keep state
> pass in on $ext_if proto tcp from $network_monitor to $pri_net port 22
> keep state

pass in on $ext_if inet proto tcp from $network_monitor to  
($int_if:network) port 5666 flags S/SA synproxy state
pass in on $ext_if inet proto tcp from $network_monitor to  
($int_if:network) port 22 flags S/SA synproxy state

> # These allow all outbound traffic to leave the firewall
> pass in on $int_if all keep state
> pass out on $int_if all keep state
> pass out on $ext_if all keep state

None of my suggestions likely addresses the real problem, but I  
figured I might offer up some suggestions while I'm here.  :)

I think that you might be suffering from frag and/or state  
exhaustion, but it's impossible to tell without more information  
about your system and the PF status.  Stuff like a dmesg and the  
output of "pfctl -vsi" would help.  You'll probably have to do some  
creative tcpdump'g as well to see what is (and isn't) getting through  
on $int_if.

HTH.

--
Jason Dixon
DixonGroup Consulting
http://www.dixongroup.net