Date: Sat, 10 Apr 2010 01:18:18 +0100 From: Peter Maxwell <peter@allicient.co.uk> To: freebsd-pf@freebsd.org Subject: Fwd: Issues with pf and snmp Message-ID: <q2m7731938b1004091718m17ab4750u66308a1120337065@mail.gmail.com> In-Reply-To: <h2s7731938b1004091716z2f460770w2eb2034c8d6a411c@mail.gmail.com> References: <4BBF59E2.80303@pixelhammer.com> <m2r7731938b1004091234yeaf9eaa1i92a48fbf28610408@mail.gmail.com> <4BBF8629.1090109@pixelhammer.com> <h2s7731938b1004091716z2f460770w2eb2034c8d6a411c@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hit reply in haste and forgot to send to list... ---------- Forwarded message ---------- From: Peter Maxwell <peter@allicient.co.uk> Date: 10 April 2010 01:16 Subject: Re: Issues with pf and snmp To: DAve <dave.list@pixelhammer.com> On 9 April 2010 20:55, DAve <dave.list@pixelhammer.com> wrote: > 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. > Darn, I thought that one would be too easy ;-) > > > > > 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. > Can't see anything obvious but have you tried these things in the event something strange is going on: - removing the scrub rule; - removing the antispoof rule; - add 'log' to the the pass rules and then check to see if there are any other snmp udp packets getting passed/dropped in the wrong place. > > 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 > > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?q2m7731938b1004091718m17ab4750u66308a1120337065>