From owner-freebsd-pf@FreeBSD.ORG Sat Apr 10 00:18:19 2010 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA4BD106566B for ; Sat, 10 Apr 2010 00:18:19 +0000 (UTC) (envelope-from allicient3141@googlemail.com) Received: from mail-yw0-f193.google.com (mail-yw0-f193.google.com [209.85.211.193]) by mx1.freebsd.org (Postfix) with ESMTP id 7DFD38FC0A for ; Sat, 10 Apr 2010 00:18:19 +0000 (UTC) Received: by ywh31 with SMTP id 31so571997ywh.3 for ; Fri, 09 Apr 2010 17:18:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:received:message-id:subject :from:to:content-type; bh=izxeC1mBwlTSnyN3o0RMsso/dsMIozY9e6AvbHHkJRw=; b=NIKXTbUQkQZkMkMnoWnsY2eorgXB7kPP+N3SElXAnD8tz9GFfiqVmL21+QQQeOmhs5 K3YPeJITKy42VgICZekYfIAtuo0s1j5yM89KKWtWOlRkGdeJ+lZZCjXIIz+Jk61su92L l+kYAwLTWIdQo63Acsd97+dl7PwJJy8kgYme0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=MM/NFRjaSNbHsYG3qI+E/iGmEYSiYcCZaD2N2Ykgtn62vxs546BiJiAn4/OSVeUDal vqHETa3I6H62+74nzBzSR0u/f9sxRbNVkFEc+pIpXi7NQHFOEcclhFrdMBNyHY0RXhnt D71Ko984tqQyyZrKtUUMwUTrxipuRjs052Iyc= MIME-Version: 1.0 Sender: allicient3141@googlemail.com Received: by 10.90.86.7 with HTTP; Fri, 9 Apr 2010 17:18:18 -0700 (PDT) In-Reply-To: References: <4BBF59E2.80303@pixelhammer.com> <4BBF8629.1090109@pixelhammer.com> Date: Sat, 10 Apr 2010 01:18:18 +0100 X-Google-Sender-Auth: 4748a45eda3f0b7f Received: by 10.91.165.19 with SMTP id s19mr256989ago.45.1270858698295; Fri, 09 Apr 2010 17:18:18 -0700 (PDT) Message-ID: From: Peter Maxwell To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Fwd: Issues with pf and snmp X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 00:18:19 -0000 Hit reply in haste and forgot to send to list... ---------- Forwarded message ---------- From: Peter Maxwell Date: 10 April 2010 01:16 Subject: Re: Issues with pf and snmp To: DAve On 9 April 2010 20:55, DAve 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 > > 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 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 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 persist { 192.168.32.0/24 > > , 10.0.241.0/24 } > > table 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 to any > > block drop out quick on $ext_if from any to > > block in quick on $ext_if inet proto tcp from 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 > > > 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" >