Issues with pf and snmp

[DAve]

Peter Maxwell wrote:
> 
> Hi DAve,
> 
> This may be a daft question, but is the destination IP in your tcpdump
> of 10.0.241.41 (one of) the IP address(es) assigned to dc0?

Yes it is.

> 
> The next question isn't actually related to your problem; when you say
> "I've been working to enable pf on all our servers in preparation for
> moving them outside the PIXs we currently use", does that mean the
> servers that have services running on them will also do their own packet
> filtering?  If so, then your existing setup with a PIX sounds better.
>  Your packet filters should - whenever possible - be on a separate box
> from the hosts running any services.  The reason being if one of your
> daemon processes are compromised then so is your fw ;-)

Yea, well, I get to voice my opinions and then wait for the decision. If
we do *not* move outside the PIX, I will still leave PF on each box for
the layered security. So I still need to get snmp to work.

I poked around the manuals for quite a while this morning and found
nothing that I saw as an answer. Searching the net for anything with pf
and snmp provided links to monitoring pf, not filtering snmp.

I am not certain the problem is not of my own creation, but I may have
to look at snmp as the issue if I cannot find anything incorrect in my
pf rules. Though, cacti has been querying this server for over two years
without a problem until I turned up pf.

Still digging...

DAve
> 
> Best wishes,
> 
> Peter
> 
> 
> 
> 
> 
> "
> On 9 April 2010 17:46, DAve <dave.list at pixelhammer.com
> <mailto:dave.list at pixelhammer.com>> wrote:
> 
>     Good afternoon.
> 
>     I've been working to enable pf on all our servers in preparation for
>     moving them outside the PIXs we currently use. The first server I
>     tackled was our ftp server, it currently is only used to support VOIP
>     phones via ftp, http, and tftp. I used ipfilter extensively but that was
>     10? years ago.
> 
>     Everything is working at this point except snmp. Cacti connects to the
>     server to query snmp and gets part of a result, then snmp stops and
>     takes 80% of the CPU. Cacti is on the <monitoring> network. I am at a
>     loss to understand what is wrong with my ruleset.
> 
>     ### Macros ###
>     # define common values, so they can be referenced and changed easily.
>     ext_if="dc0"    # replace with actual external interface name i.e., dc0
>     int_if="dc1"
>     loop_if="lo0"
> 
>     ### Tables ###
>     table <martians> persist { 127.0.0.0/8 <http://127.0.0.0/8>,
>     172.16.0.0/12 <http://172.16.0.0/12>, 169.254.0.0/16
>     <http://169.254.0.0/16>,
>     192.0.2.0/24 <http://192.0.2.0/24>, 0.0.0.0/8 <http://0.0.0.0/8>,
>     240.0.0.0/4 <http://240.0.0.0/4> }
>     table <monitoring> persist { 192.168.32.0/24
>     <http://192.168.32.0/24>, 10.0.241.0/24 <http://10.0.241.0/24> }
>     table <sshguard> persist
> 
>     ### Normalization ###
>     # reassemble fragments and resolve or reduce traffic ambiguities.
>     scrub all random-id
> 
>     ### Default Filtering ###
>     block in log all
>     block out log all
> 
>     # Lets make certain localhost and the private network is unrestricted
>     set skip on $loop_if
>     set skip on $int_if
> 
>     # Now lets start hammering anything obvious
>     block drop in quick on $ext_if from <martians> to any
>     block drop out quick on $ext_if from any to <martians>
>     block in quick on $ext_if inet proto tcp from <sshguard> to any port 22
>     label "ssh bruteforce"
>     antispoof for $ext_if
> 
>     # Lets pass ssh, time and dns, we always need those. Also connections
>     from the office and monitoring
>     pass in quick on $ext_if inet proto tcp from any to $ext_if port 22 keep
>     state
>     pass out quick on $ext_if inet proto udp from $ext_if to any port 53
>     keep state
>     pass out quick on $ext_if inet proto udp from $ext_if to any port 123
>     keep state
>     pass in quick on $ext_if inet proto { tcp, udp, icmp } from <monitoring>
>     to $ext_if keep state
> 
>     ### Server Specific rules ###
>     # We gotta support those FTP users, that's why we are here and not a
>     kiosk in a mall
>     pass in quick on $ext_if inet proto tcp from any to $ext_if port 21 keep
>     state
>     pass in quick on $ext_if inet proto tcp from any to $ext_if port
>     65000:65500 keep state
>     # Yep, Cisco phones still using tftp, we do not understand what internet
>     they use at Cisco.
>     pass in quick on $ext_if inet proto udp from any to $ext_if port 69
>     # We use www to serve config files as well
>     pass in quick on $ext_if inet proto tcp from any to $ext_if port 80 keep
>     state
> 
>     I would think the line allowing tcp,udp,icmp would allow snmp to work
>     from the monitoring server, but snmp is certainly not behaving. here is
>     the relevant pflog entry.
> 
>     480683 rule 0/0(match): block in on dc0: 10.0.241.28.39107 >
>     10.0.241.41.161:  C=SECRET GetNextRequest(21)  .0.1[|snmp]
> 
>     Thanks for any help.
> 
>     DAve


-- 
"Posterity, you will know how much it cost the present generation to
preserve your freedom.  I hope you will make good use of it.  If you
do not, I shall repent in heaven that ever I took half the pains to
preserve it." John Adams

http://appleseedinfo.org