Date: Fri, 09 Apr 2010 15:55:21 -0400 From: DAve <dave.list@pixelhammer.com> To: freebsd-pf@freebsd.org Subject: Re: Issues with pf and snmp Message-ID: <4BBF8629.1090109@pixelhammer.com> In-Reply-To: <m2r7731938b1004091234yeaf9eaa1i92a48fbf28610408@mail.gmail.com> References: <4BBF59E2.80303@pixelhammer.com> <m2r7731938b1004091234yeaf9eaa1i92a48fbf28610408@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@pixelhammer.com
> <mailto:dave.list@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BBF8629.1090109>