Issues with pf and snmp

Peter Maxwell peter at allicient.co.uk
Fri Apr 9 19:34:45 UTC 2010


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?

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 ;-)

Best wishes,

Peter





"
On 9 April 2010 17:46, DAve <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, 172.16.0.0/12, 169.254.0.0/16,
> 192.0.2.0/24, 0.0.0.0/8, 240.0.0.0/4 }
> table <monitoring> persist { 192.168.32.0/24, 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
>
> _______________________________________________
> freebsd-pf at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-pf
> To unsubscribe, send any mail to "freebsd-pf-unsubscribe at freebsd.org"
>


More information about the freebsd-pf mailing list