From owner-freebsd-pf@FreeBSD.ORG Sun Jan 18 11:05:49 2009 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 EB7A010656D3 for ; Sun, 18 Jan 2009 11:05:49 +0000 (UTC) (envelope-from siquijorphilips@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by mx1.freebsd.org (Postfix) with ESMTP id C30D68FC25 for ; Sun, 18 Jan 2009 11:05:49 +0000 (UTC) (envelope-from siquijorphilips@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so2335347rvf.43 for ; Sun, 18 Jan 2009 03:05:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=mB8X3TCQeMrIRr81DQqVfdp6oLPeLLWkhfZ+VhMoZQM=; b=i4WMf3L6YIx+QnQO+h6KXgmKgj5COE8HTeqc17j/yzts94jWhhqmIJM5SA0bhm2h7X IjonRMjCZFQBfvOtRE0VxMClsx99iiXLQidlTO9WUUSVelQv2jevcaOzSnXt++fzsbvP gcIg3NALhZWYnbLQmhJ9iORjnr9rhsHvgC9Eg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=QdSQck0fVV3l+rht4Pw/s/zggHI7JPhMSOvO9IOTicawG3AXvnFxm0+1CgdCrrko3q s5rR60vkaIkXIPL0sy1Ts3oaP1HFAr9Se5VSPDcNaL/jgsu9Zp9SwEP25rmrU2xoT2RX i/mrycklVsGqdN6qWaMXa9yy7ac0bAFuJspWg= MIME-Version: 1.0 Received: by 10.142.103.11 with SMTP id a11mr1870266wfc.208.1232275285558; Sun, 18 Jan 2009 02:41:25 -0800 (PST) Date: Sun, 18 Jan 2009 18:41:25 +0800 Message-ID: From: Siquijor Philips To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: PF with TSO 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: Sun, 18 Jan 2009 11:05:50 -0000 Hi, FreeBSD-7.1 is shipped with TCP segmentation offload (TSO) feature to some network interface cards by default such as Intel and Broadcom. I would like to know if there's any impact when PF is enabled together with TSO in terms of performance and packet inspection? Thank you, Regards, Siquijor From owner-freebsd-pf@FreeBSD.ORG Sun Jan 18 11:43:49 2009 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 1B3121065702 for ; Sun, 18 Jan 2009 11:43:49 +0000 (UTC) (envelope-from infos@dnswatch.com) Received: from fast.dnswatch.com (fast.dnswatch.com [75.160.109.234]) by mx1.freebsd.org (Postfix) with ESMTP id DABD48FC1B for ; Sun, 18 Jan 2009 11:43:48 +0000 (UTC) (envelope-from infos@dnswatch.com) Received: from webmail.dnswatch.com (localhost.dnswatch.com [127.0.0.1]) by fast.dnswatch.com (8.14.2/8.14.2) with ESMTP id n0IBAULm028856 for ; Sun, 18 Jan 2009 03:10:36 -0800 (PST) (envelope-from infos@dnswatch.com) Received: from hitme.hitometer.net ([75.160.109.235]) (DNSwatchWebMail authenticated user infos) by webmail.dnswatch.com with HTTP; Sun, 18 Jan 2009 03:10:36 -0800 (PST) Message-ID: <59e0bfe9193784283b7c7aaa2d958ad7.dnswclient@webmail.dnswatch.com> Date: Sun, 18 Jan 2009 03:10:36 -0800 (PST) From: infos@dnswatch.com To: freebsd-pf@freebsd.org User-Agent: DNSwatchWebMail/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: basic rule request - allow_all/block_bad 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: Sun, 18 Jan 2009 11:43:49 -0000 Greetings, I know very little about creating an initial pf.conf. I know /very/ /much/ that I want/need PF, and will need a fair amount of time to "tune" pf to work optimally for each server. BUT, in an effort to get started, I'm hoping that some kind soul will provide me with a very basic pf.conf that will not interrupt the current application/server block policies I already have in place - which is to say; I currently block at the application/server, but hope to merge (transfer) them to PF. So. can anyone share a pf.conf that will allow all, but block ALL_EVIL_IP requests on ALL ports? In other words, if I only wanted to block (drop) ALL traffic coming from a /single/ IP address. How would I do it? I have one (active) NIC in each of my servers, and there are anywhere from 3 to 12 IP's aliased to them above and beyond the IP assigned to the host itself. All addresses are fully qualified, internet route-able addresses (no internal/private IP's). Thank you for all your time and consideration. --Chris From owner-freebsd-pf@FreeBSD.ORG Sun Jan 18 12:12:58 2009 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 D6CB3106567D for ; Sun, 18 Jan 2009 12:12:58 +0000 (UTC) (envelope-from fbsdmail@dnswatch.com) Received: from fast.dnswatch.com (fast.dnswatch.com [75.160.109.234]) by mx1.freebsd.org (Postfix) with ESMTP id 9FD5A8FC1C for ; Sun, 18 Jan 2009 12:12:58 +0000 (UTC) (envelope-from fbsdmail@dnswatch.com) Received: from webmail.dnswatch.com (localhost.dnswatch.com [127.0.0.1]) by fast.dnswatch.com (8.14.2/8.14.2) with ESMTP id n0ICCqgw029323 for ; Sun, 18 Jan 2009 04:12:58 -0800 (PST) (envelope-from fbsdmail@dnswatch.com) Received: from hitme.hitometer.net ([75.160.109.235]) (DNSwatchWebMail authenticated user infos) by webmail.dnswatch.com with HTTP; Sun, 18 Jan 2009 04:12:58 -0800 (PST) Message-ID: <2b1dc259cdb3912c5dc6ba9be9929e9b.dnswclient@webmail.dnswatch.com> Date: Sun, 18 Jan 2009 04:12:58 -0800 (PST) From: fbsdmail@dnswatch.com To: freebsd-pf@freebsd.org User-Agent: DNSwatchWebMail/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: Blocking udp flood trafiic using pf, hints welcome 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: Sun, 18 Jan 2009 12:12:59 -0000 Greetings, On Sun, Nov 9, 2008 at 4:37 AM, Elvir Kuric wrote: > > Hi all, > > > > I am playing with pf tool on openbsd/freebsd platforms and it is super > > tool for firewalls. On thing is interesting for me, and I am hopping > > someone has expeience with this. > > > > If I say > > > > block log all > > block in log (all) quick on $ext_if proto udp from any to $ext_if > > > > this would block all traffic on $ext_if, but on my ext_if I recive a > > lot of ( huge amount ) of udp generated traffic which make me a lot > > of problems. > > I also tryed to add small pipe and play with ALTQ to handle this but > > it did not help a lot. Also I know that every packet which hit my > > ext_if should be > > processed ( or least take a little processor resources, if I block > > it with keyword quick ), but I am wondering is there some way to > > decrease impact on system > > when a lot of packets arive in short time. > > > > My question would be, what are your experinces with battling against > > boring udp flooders ? Platform are FreeBSD / OpenBSD and all works > > like a charm except time to time, stupid udp flood atacks. > > > > Not sure if this will help in your situation, but you could try > setting the 'blackhole' for UDP. (There is also one for TCP.) > > net.inet.tcp.blackhole > net.inet.udp.blackhole Those options require a bit more syntax. The options I've been using as part of my installs are: net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 and while they will nearly prevent you from becoming a "drone", they won't prevent you from being attacked /by/ a "drone". I know from personal experience. :( Good advice on your part, none the less. :) Best wishes. --Chris > -- > Glen Barber From owner-freebsd-pf@FreeBSD.ORG Sun Jan 18 12:13:48 2009 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 AF3D1106566B for ; Sun, 18 Jan 2009 12:13:48 +0000 (UTC) (envelope-from fbsdmail@dnswatch.com) Received: from fast.dnswatch.com (fast.dnswatch.com [75.160.109.234]) by mx1.freebsd.org (Postfix) with ESMTP id 6FE288FC12 for ; Sun, 18 Jan 2009 12:13:48 +0000 (UTC) (envelope-from fbsdmail@dnswatch.com) Received: from webmail.dnswatch.com (localhost.dnswatch.com [127.0.0.1]) by fast.dnswatch.com (8.14.2/8.14.2) with ESMTP id n0IBx6kF029203 for ; Sun, 18 Jan 2009 03:59:12 -0800 (PST) (envelope-from fbsdmail@dnswatch.com) Received: from hitme.hitometer.net ([75.160.109.235]) (DNSwatchWebMail authenticated user infos) by webmail.dnswatch.com with HTTP; Sun, 18 Jan 2009 03:59:12 -0800 (PST) Message-ID: <9f9bf26296b3f05db555b7f37bd42226.dnswclient@webmail.dnswatch.com> Date: Sun, 18 Jan 2009 03:59:12 -0800 (PST) From: fbsdmail@dnswatch.com To: freebsd-pf@freebsd.org User-Agent: DNSwatchWebMail/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: Blocking udp flood trafiic using pf, hints welcome 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: Sun, 18 Jan 2009 12:13:49 -0000 Greetings, see below... > On Sun, Nov 09, 2008 at 10:37:29AM +0100, Elvir Kuric wrote: > > I am playing with pf tool on openbsd/freebsd platforms and it is super > > tool for firewalls. On thing is interesting for me, and I am hopping > > someone has expeience with this. > > > > If I say > > > > block log all > > block in log (all) quick on $ext_if proto udp from any to $ext_if > > > > this would block all traffic on $ext_if, but on my ext_if I recive a > > lot of ( huge amount ) of udp generated traffic which make me a lot > > of problems. > > I also tryed to add small pipe and play with ALTQ to handle this but > > it did not help a lot. Also I know that every packet which hit my > > ext_if should be > > processed ( or least take a little processor resources, if I block > > it with keyword quick ), but I am wondering is there some way to > > decrease impact on system > > when a lot of packets arive in short time. > > > > My question would be, what are your experinces with battling against > > boring udp flooders ? Platform are FreeBSD / OpenBSD and all works > > like a charm except time to time, stupid udp flood atacks. > > First, you should be very careful with use of the "log" directive on > your rules. I've personally witnessed an attack which triggered "log" > entries in block rules causing pflog to log at such a tremendous/fast > rate, that newsyslog could not rotate+compress the log files fast > enough, resulting in CPU maxing out and so on (a true self-induced > denial-of-service). Consider this warning. :-) > > Secondly, and this is more a direct answer of your question: I believe > what you're referring to is a UDP-based DoS attack against your FreeBSD > machine(s). > > The "block" directives you're using will only stop your FreeBSD box from > responding to those packets (whatever you do, silently deny those > packets; do not use "reject", or else your box will be trying to send > back denial responses to the attackers, which just makes the problem > worse). It *cannot* solve the problem of your network connection > becoming saturated. > > Your next question will be: "okay, so how do I solve this problem?" This > is where it gets both technical and political. There are two things to > do first: > > 1) See if the attacks are distributed (multiple IPs or even spoofed IPs > hitting your machine with UDP packets). If they're distributed or > spoofed, you're out of luck. > > If the packets are legitimate (e.g. some compromised machine on the > Internet is being used to attack you), you need to find out who own that > IP address, and contact them. ARIN (WHOIS) can be of help here. Pray > they have an abuse department. If you do not get a prompt response > (24-48 hours), try to figure out who their upstream network provider is, > and send them a similar message. Continue up the chain until you get a > response. Phone calls (even international) often work wonders > decreasing mitigation time. > > 2) Investigate your own machine. I cannot stress this enough. Most DoS > attacks I've seen in my years ARE NOT random -- there's a reason they > happen. > > The majority of attacks I've seen involve IRC in some way, either as a > central cause of attack (arguments, channel takeovers, whatever), or > indirectly (a compromised account on your machine). If your machine is > a shell box for friends/customers, I highly recommend considering *not* > permitting IRC from it; this includes bouncers and eggdrops. > > Many IRC-induced attacks are done against a machine solely to knock it > offline (so the user on IRC pings out for a channel takeover, or just to > keep the user from getting back on IRC). > > And if your machine(s) run IRC servers... well, this is one of the many > dangers in hosting a server. You have to weigh what's more important to > you in this case: IRC, or the availability of your machines. I speak > from personal experience as someone who used to administrate a public > EFnet server, and as someone who has used IRC for the past 16 years. > Whichever matters to you more is what you should stick with. > > The second most common reason for attack I've seen are controversial > websites or domain names -- things that induce arguments, controversy or > heated discussions, or are of a "shady" nature and would bring shady > or questionable attention to you (e.g. wehaveeggdropshellz.com). If > you host anything like this, consider suspending it, or removing the > customer due to incidents which cause the network to become unavailable. > Remember: one customer/user is not worth sacrificing all the rest. > > Finally: work with your own service/uplink provider. In the case of a > very large-scale attack, your ISP will need to do the filtering to > ensure that the packets never reach your machine. "What can they filter > on if it's DDoS?" Good question -- very little. But your uplink should > at least be told of the problem, both out of respect, and for your own > benefit (especially if you are billed for *incoming* traffic!) > > If you don't find decent answers here, I highly recommend freebsd-net > or freebsd-isp. Others may have better advice. > > Footnote: Like SMTP and spam, IRC as an entity is not evil or bad -- the > problem is that in this day and age, it can breed trouble. I don't want > to sound like I'm slamming IRC ("IRC sucks! Ban IRC!"); I'm not. I'm > simply pointing out the realities that are involved with IRC in this day > and age. The degree of anonymity DoS and IRC provide sometimes brings > out the worst in people, and that's sad. Hello Jeremy, I just joined this list. Then started parsing the archive, and ran into this - what you refer to, is exactly the reason I'm getting off my a$$ and getting PF configured on my servers - something I've been too busy to get to, but now finding myself /having/ to. :( To the point. I'm receiving an inordinate amount of UDP traffic lodged against DNS on all the servers. I immediately fired off emails to the RP's, and received prompt responses. /However/ one of the RP's indicated they've been up against this since /Christmas/. While I'm not going to mention the Firm, I will tell you that they are quite large (xxx.xxx.128.0/20 - xxx.xxx.128.0 - xxx.xxx.143.255). I've now been suffering the consequences for 3 days, with no end in sight. So, while I have a hard time understanding how an entity managing such a large amount of IP real-estate, can't figure out how to keep from becoming/continuing to produce "drone's", I /do/ understand that /I/ am capable of putting up a wall to block the abuse emanating from their network. Which brings me here. :) Am I correct in understanding from your response that FreeBSD PF can't effectively drop UDP packets? My current defence (aside from my application/server block polocies) is some sysctl(8)/sysctl(5) tunables: net.inet.udp.log_in_vain=0 net.inet.tcp.log_in_vain=1 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.inet.tcp.icmp_may_rst=0 net.inet.tcp.drop_synfin=1 # don't accept sourcerouted packets (they are evil) net.inet.ip.accept_sourceroute=0 net.inet.ip.sourceroute=0 security.bsd.see_other_uids=0 While all of these are not INET TCP/ICMP/SYN/UDP related, it's a pretty good rule of thumb for sysctl security tunables. But isn't there some pf.conf that I can create that will simply drop all UDP traffic from the offending IP? Based on the data in my logs, and my understanding of all the powerful tools that are available (for both good, /and/ evil), I'm near positive that the attacker is bouncing the packets off the "drones" with HPING. Anyway, I felt the need to chime in when I noticed you addressed all the topics that described my current situation, hoping PF would be the solution (my savior). Best wishes. --Chris > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-pf@FreeBSD.ORG Sun Jan 18 13:55:19 2009 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 950A71065672 for ; Sun, 18 Jan 2009 13:55:19 +0000 (UTC) (envelope-from fbsdmail@dnswatch.com) Received: from fast.dnswatch.com (fast.dnswatch.com [75.160.109.234]) by mx1.freebsd.org (Postfix) with ESMTP id 33F148FC13 for ; Sun, 18 Jan 2009 13:55:19 +0000 (UTC) (envelope-from fbsdmail@dnswatch.com) Received: from webmail.dnswatch.com (localhost.dnswatch.com [127.0.0.1]) by fast.dnswatch.com (8.14.2/8.14.2) with ESMTP id n0IDt7WT030027; Sun, 18 Jan 2009 05:55:13 -0800 (PST) (envelope-from fbsdmail@dnswatch.com) Received: from hitme.hitometer.net ([75.160.109.235]) (DNSwatchWebMail authenticated user infos) by webmail.dnswatch.com with HTTP; Sun, 18 Jan 2009 05:55:13 -0800 (PST) Message-ID: In-Reply-To: <7731938b0901180510p4be2e580h9d1c8f75cbbc2255@mail.gmail.com> References: <9f9bf26296b3f05db555b7f37bd42226.dnswclient@webmail.dnswatch.com> <7731938b0901180510p4be2e580h9d1c8f75cbbc2255@mail.gmail.com> Date: Sun, 18 Jan 2009 05:55:13 -0800 (PST) From: fbsdmail@dnswatch.com To: freebsd-pf@freebsd.org User-Agent: DNSwatchWebMail/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Re: Blocking udp flood trafiic using pf, hints welcome 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: Sun, 18 Jan 2009 13:55:19 -0000 Hello Peter, and thank you for your reply... On Sun, January 18, 2009 5:10 am, Peter Maxwell wrote: > Comments inline... > > >> Hello Jeremy, >> I just joined this list. Then started parsing the archive, and >> ran into this - what you refer to, is exactly the reason I'm getting off >> my a$$ and getting PF configured on my servers - something I've been too >> busy to get to, but now finding myself /having/ to. :( To the point. I'm >> receiving an inordinate amount of UDP traffic lodged against DNS on all >> the servers. I immediately fired off emails to the RP's, and received >> prompt responses. /However/ one of the RP's indicated they've been up >> against this since /Christmas/. While I'm not going to mention the Firm, >> I will tell you that they are quite large >> (xxx.xxx.128.0/20 - xxx.xxx.128.0 - xxx.xxx.143.255). I've now >> been suffering the consequences for 3 days, with no end in sight. So, >> while I have a hard time understanding how an entity managing such a >> large amount of IP real-estate, can't figure out how to keep from >> becoming/continuing to produce "drone's", I /do/ understand that /I/ am >> capable of putting up a wall to block the abuse emanating from their >> network. Which brings me here. :) Am I correct in understanding from >> your response that FreeBSD PF can't effectively drop UDP packets? My >> current defence (aside from my application/server block polocies) is >> some sysctl(8)/sysctl(5) tunables: >> > > > Chris, you've rather missed the point here: pf can easily drop the UDP > packets, however *whatever* you do there's going to be CPU cycles used to > drop them. You could use a whole different array of packet > filters/firewalls to drop the UDP packets but its still going to drag down > your firewall machine and/or internet connection. Hence the only real > solution is upstream filtering, or if you are piering directly your router > should be fast enough. Oh, I understood the thread topic, but got the impression from Jeremy's reply, that attempting to block UDP via PF wasn't feasible. It was also my understanding that the OP's biggest shortcoming was his attempt to log all the communication. For me neither will be an issue; 1) I'm not interested in anything more than "first attempts" in the logs. 2) All the servers have a spare onboard NIC that I haven't even enabled yet. Which means I can "bind" them, there-by allowing me better throughput to hadlde excessive traffic. 3) they are all multi-cpu servers. So I have enough cycles available. Thanks again, for taking the time to reply. --Chris >> net.inet.udp.log_in_vain=0 net.inet.tcp.log_in_vain=1 >> >> net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 >> >> net.inet.tcp.icmp_may_rst=0 net.inet.tcp.drop_synfin=1 >> >> # don't accept sourcerouted packets (they are evil) >> net.inet.ip.accept_sourceroute=0 net.inet.ip.sourceroute=0 >> >> security.bsd.see_other_uids=0 >> >> While all of these are not INET TCP/ICMP/SYN/UDP related, it's >> a pretty good rule of thumb for sysctl security tunables. But isn't there >> some pf.conf that I can create that will simply drop all UDP traffic >> from the offending IP? Based on the data in my logs, and my >> understanding of all the powerful tools that are available (for both >> good, /and/ evil), I'm near positive that the attacker is bouncing the >> packets off the "drones" with HPING. Anyway, I felt the need to chime in >> when I noticed you addressed all the topics that described my current >> situation, hoping PF would be the solution (my savior). >> >> Best wishes. >> >> >> --Chris >> >> > From owner-freebsd-pf@FreeBSD.ORG Sun Jan 18 17:42:28 2009 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 0E9E2106566B for ; Sun, 18 Jan 2009 17:42:28 +0000 (UTC) (envelope-from fbsdmail@dnswatch.com) Received: from fast.dnswatch.com (fast.dnswatch.com [75.160.109.234]) by mx1.freebsd.org (Postfix) with ESMTP id C50538FC0A for ; Sun, 18 Jan 2009 17:42:27 +0000 (UTC) (envelope-from fbsdmail@dnswatch.com) Received: from webmail.dnswatch.com (localhost.dnswatch.com [127.0.0.1]) by fast.dnswatch.com (8.14.2/8.14.2) with ESMTP id n0IHgGi7031589; Sun, 18 Jan 2009 09:42:22 -0800 (PST) (envelope-from fbsdmail@dnswatch.com) Received: from hitme.hitometer.net ([75.160.109.235]) (DNSwatchWebMail authenticated user infos) by webmail.dnswatch.com with HTTP; Sun, 18 Jan 2009 09:42:23 -0800 (PST) Message-ID: <0ec20388586080a91b7ee1ec8ffb7e64.dnswclient@webmail.dnswatch.com> In-Reply-To: <7731938b0901180844j2d143903q41cc131ef64a2c24@mail.gmail.com> References: <9f9bf26296b3f05db555b7f37bd42226.dnswclient@webmail.dnswatch.com> <7731938b0901180510p4be2e580h9d1c8f75cbbc2255@mail.gmail.com> <7731938b0901180844j2d143903q41cc131ef64a2c24@mail.gmail.com> Date: Sun, 18 Jan 2009 09:42:23 -0800 (PST) From: fbsdmail@dnswatch.com To: freebsd-pf@freebsd.org User-Agent: DNSwatchWebMail/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Re: Blocking udp flood trafiic using pf, hints welcome 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: Sun, 18 Jan 2009 17:42:28 -0000 Hello again Peter, and thank you for your thoughtful reply... On Sun, January 18, 2009 8:44 am, Peter Maxwell wrote: > 2009/1/18 : > >> Hello Peter, and thank you for your reply... >> >> >> On Sun, January 18, 2009 5:10 am, Peter Maxwell wrote: >> >>> Comments inline... >>> >>> >>> >>>> Hello Jeremy, >>>> I just joined this list. Then started parsing the archive, and >>>> ran into this - what you refer to, is exactly the reason I'm getting >>>> off my a$$ and getting PF configured on my servers - something I've >>>> been too busy to get to, but now finding myself /having/ to. :( To >>>> the point. I'm receiving an inordinate amount of UDP traffic lodged >>>> against DNS on all the servers. I immediately fired off emails to >>>> the RP's, and received prompt responses. /However/ one of the RP's >>>> indicated they've been up against this since /Christmas/. While I'm >>>> not going to mention the Firm, I will tell you that they are quite >>>> large (xxx.xxx.128.0/20 - xxx.xxx.128.0 - xxx.xxx.143.255). I've now >>>> been suffering the consequences for 3 days, with no end in sight. >>>> So, >>>> while I have a hard time understanding how an entity managing such a >>>> large amount of IP real-estate, can't figure out how to keep from >>>> becoming/continuing to produce "drone's", I /do/ understand that >>>> /I/ am >>>> capable of putting up a wall to block the abuse emanating from their >>>> network. Which brings me here. :) Am I correct in understanding >>>> from your response that FreeBSD PF can't effectively drop UDP >>>> packets? My current defence (aside from my application/server block >>>> polocies) is some sysctl(8)/sysctl(5) tunables: >>>> >>> >>> >>> Chris, you've rather missed the point here: pf can easily drop the >>> UDP >>> packets, however *whatever* you do there's going to be CPU cycles used >>> to drop them. You could use a whole different array of packet >>> filters/firewalls to drop the UDP packets but its still going to drag >>> down your firewall machine and/or internet connection. Hence the only >>> real solution is upstream filtering, or if you are piering directly >>> your router should be fast enough. >> >> Oh, I understood the thread topic, but got the impression from >> Jeremy's reply, that attempting to block UDP via PF wasn't feasible. >> It was also my understanding that the OP's biggest shortcoming was >> his attempt to log all the communication. > > Appologies, I think I've missed a post somewhere along the way - pf > can deal with UDP no bother. > >> >> For me neither will be an issue; >> >> >> 1) I'm not interested in anything more than "first attempts" in >> the logs. > > pf does handle UDP quite well, Glad to hear it. :) > although UDP is technically stateless pf > will create a state for it based on IP/port numbers. Default logging also > only logs the *first* packet in a state, so if you enable logging by > default it will only log the first packet - although in high traffic > scenarios that in itself may kill a box. > > >> >> 2) All the servers have a spare onboard NIC that I haven't even >> enabled yet. Which means I can "bind" them, there-by allowing me better >> throughput to hadlde excessive traffic. > > I take it your upstream pipe(s) is/are bigger? Somewhat dynamic. > > >> >> 3) they are all multi-cpu servers. So I have enough cycles available. >> > > Then you're probably ok with the logging ;-) Might be worthwhile > setting up the box and testing it first, then you'll know whether the disc > array, etc will keep up. As you'd generally use tcpdump to view the logs, > always copy them off the firewall box first. Assuming I feel the need to scan the PF log(s), I imagine dump(8) will suit me just fine. :) > > If you're interested, pf can also do state sync so if you've got two > boxes you can have a redundant configuration. Never tried it with pf, but > have used the equivalent with Checkpoint firewalls and it is invaluable > (e.g. you can swap then out without losing service). Sounds like a plan. This project could turn out to be a real testament to FreeBSD, and PF itself. I have only one problem - this will be a first go 'round with PF. I'll need to experiment on one of the servers. I don't suppose you'd be willing to /suggest/ a reasonable "starting point" for a pf.conf, would you? Assuming you (or anyone else) would - a little more info is in order; I'll slice out a /27 segment, and just start small. ;) OH, and I have no private IP's involved - think dummynet. To make the numbers easy to work with, I'll use the following: ifconfig_fxp0="inet xxx.xxx.xxx.1 netmask 255.255.255.224" as I mentioned, all of the servers have at least 3 /aliased/ IP's ifconfig_fxp0_alias0="inet xxx.xxx.xxx.3 netmask 255.255.255.255" ifconfig_fxp0_alias1="inet xxx.xxx.xxx.4 netmask 255.255.255.255" ifconfig_fxp0_alias2="inet xxx.xxx.xxx.5 netmask 255.255.255.255" xxx.xxx.xxx.0 --> NET xxx.xxx.xxx.1 --> NS1 (this is the box we're dealing with) xxx.xxx.xxx.2 --> any ... xxx.xxx.xxx.3 --> alias0 xxx.xxx.xxx.4 --> alias1 xxx.xxx.xxx.5 --> alias2 ... xxx.xxx.xxx.30 --> gateway xxx.xxx.xxx.30 --> BCAST Given this scenario, what would be a simple starting (but working) pf.conf, that would allow trapping (drop) the UDP spam, but not really mess with anything currently in use (NFS,SSH,WWW,DNS,etc...)? While I haven't setup PF before, I have done a boatload of reading. Only problem being; I can't seem to find anything similar to my needs. Most all are designed for traffic shaping, are NAT'd, or are OpenBSD centric. So I've been afraid to try to adapt any of them on my /first/ go'round. My scenario /seems/ like it'd be pretty easy - assuming I had any /prior/ experience with PF. ;) Thank you again for your response! Best wishes. --Chris > > > >> >> Thanks again, for taking the time to reply. >> >> >> --Chris >> >> >>>> net.inet.udp.log_in_vain=0 net.inet.tcp.log_in_vain=1 >>>> >>>> net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 >>>> >>>> net.inet.tcp.icmp_may_rst=0 net.inet.tcp.drop_synfin=1 >>>> >>>> # don't accept sourcerouted packets (they are evil) >>>> net.inet.ip.accept_sourceroute=0 net.inet.ip.sourceroute=0 >>>> >>>> security.bsd.see_other_uids=0 >>>> >>>> While all of these are not INET TCP/ICMP/SYN/UDP related, it's >>>> a pretty good rule of thumb for sysctl security tunables. But isn't >>>> there some pf.conf that I can create that will simply drop all UDP >>>> traffic from the offending IP? Based on the data in my logs, and my >>>> understanding of all the powerful tools that are available (for >>>> both good, /and/ evil), I'm near positive that the attacker is >>>> bouncing the packets off the "drones" with HPING. Anyway, I felt the >>>> need to chime in when I noticed you addressed all the topics that >>>> described my current situation, hoping PF would be the solution (my >>>> savior). >>>> >>>> Best wishes. >>>> >>>> >>>> >>>> --Chris >>>> >>>> >>>> >>> >> >> >> > From owner-freebsd-pf@FreeBSD.ORG Sun Jan 18 19:45:50 2009 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 36339106566B for ; Sun, 18 Jan 2009 19:45:50 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [91.103.162.4]) by mx1.freebsd.org (Postfix) with ESMTP id E92C58FC1D for ; Sun, 18 Jan 2009 19:45:49 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id BBE0219E05C; Sun, 18 Jan 2009 20:27:27 +0100 (CET) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 2357E19E057; Sun, 18 Jan 2009 20:27:25 +0100 (CET) Message-ID: <497382D3.8040408@quip.cz> Date: Sun, 18 Jan 2009 20:28:19 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: infos@dnswatch.com References: <59e0bfe9193784283b7c7aaa2d958ad7.dnswclient@webmail.dnswatch.com> In-Reply-To: <59e0bfe9193784283b7c7aaa2d958ad7.dnswclient@webmail.dnswatch.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-pf@freebsd.org Subject: Re: basic rule request - allow_all/block_bad 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: Sun, 18 Jan 2009 19:45:50 -0000 infos@dnswatch.com wrote: > Greetings, > I know very little about creating an initial pf.conf. > I know /very/ /much/ that I want/need PF, and will need a fair amount > of time to "tune" pf to work optimally for each server. > BUT, in an effort to get started, I'm hoping that some kind soul will > provide me with a very basic pf.conf that will not interrupt the > current application/server block policies I already have in place - > which is to say; I currently block at the application/server, but hope > to merge (transfer) them to PF. So. can anyone share a pf.conf that will > allow all, but block ALL_EVIL_IP requests on ALL ports? > In other words, if I only wanted to block (drop) ALL traffic coming from a > /single/ IP address. How would I do it? > I have one (active) NIC in each of my servers, and there are anywhere from 3 > to 12 IP's aliased to them above and beyond the IP assigned to the host > itself. All addresses are fully qualified, internet route-able addresses > (no internal/private IP's). If you really need to block one IP, you can use following simple ruleset: block in quick from 10.20.30.40 to any pass all If you need to block more than one address, or you need easy manipulation with list of addresses, you can use tables in ruleset: table persist file "/etc/pf.badguys.table" block in quick from to any pass all You can put IPs in to persistent file /etc/pf.badguys.table, these IPs will be loaded in the boot time. You can add / remove address on the fly by pfctl command: pfctl -t badguys -T add 10.11.12.13 pfctl -t badguys -T delete 10.11.12.13 Miroslav Lachman From owner-freebsd-pf@FreeBSD.ORG Sun Jan 18 20:00:05 2009 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16292106566B for ; Sun, 18 Jan 2009 20:00:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EF3488FC13 for ; Sun, 18 Jan 2009 20:00:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n0IK04DT023678 for ; Sun, 18 Jan 2009 20:00:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n0IK04Wm023676; Sun, 18 Jan 2009 20:00:04 GMT (envelope-from gnats) Date: Sun, 18 Jan 2009 20:00:04 GMT Message-Id: <200901182000.n0IK04Wm023676@freefall.freebsd.org> To: freebsd-pf@FreeBSD.org From: Petko Bordjukov Cc: Subject: Re: kern/127920: [pf] ipv6 and synproxy don't play well together X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Petko Bordjukov 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: Sun, 18 Jan 2009 20:00:05 -0000 The following reply was made to PR kern/127920; it has been noted by GNATS. From: Petko Bordjukov To: bug-followup@FreeBSD.org, hlh@restart.be Cc: Subject: Re: kern/127920: [pf] ipv6 and synproxy don't play well together Date: Sun, 18 Jan 2009 21:29:56 +0200 I am having the same problem. FreeBSD router.supranet.eu 7.1-RELEASE-p2 FreeBSD 7.1-RELEASE-p2 #2: Wed Jan 14 15:58:07 EET 2009 root@router.xxx.yyy:/var/src/sys/i386/compile/H5A8S i386 pf.conf: > ... > > # Settings > > set block-policy drop > set skip on lo0 > > ## TRAFFIC NORMALIZATION > scrub in on $ext_if all fragment reassemble > scrub out on $ext_if all fragment reassemble random-id no-df > scrub in on $tunnel_if all fragment reassemble > scrub out on $tunnel_if all fragment reassemble random-id no-df > > # Queueing > > # Translation > > > # Filtering > > # activate spoofing protection for all interfaces > # block in log quick from urpf-failed > antispoof log quick for $loopback_if label "Antispoof for $if interface." > antispoof log quick for $int_if label "Antispoof for $if interface." > > # default rule > block log all label "Block all." > block in on $ext_if proto { tcp udp } from any to any port { 137, 138, 139, 445 } label "Block netbios broadcasts and don't log." > > pass out from self to any modulate state label "Permit outgoing traffic from the firewall." > pass out on !$int_if from $localnet6 to any modulate state label "Permit outgoing traffic from the local v6 net." > pass inet proto icmp all icmp-type { 0, 3, 4, 11 } keep state label "Permit safe ICMP." > # http://www.freebsd.org/cgi/man.cgi?query=icmp6 > pass inet6 proto icmp6 all icmp6-type { 1,2,3,4 } keep state label "Permit safe ICMPv6." > pass in on $tunnel_if inet6 proto icmp6 from $tun_endpoint icmp6-type {128,135,136} keep state label "Permit IPv6 ping, neighbor solic., advert. from endpoint." > > > # Allow access to services > pass in inet proto tcp from any to $pub_ips port $tcp_services synproxy state label "Access to $dstaddr $proto/$dstport." > > > > #### Trouble comes from this rule > pass in inet6 proto tcp from any to $pub_ips port $tcp_services synproxy state label "Access to $dstaddr $proto/$dstport." > > > > > pass in proto udp from any to $pub_ips port $udp_services keep state label "Access to $dstaddr $proto/$dstport." > pass in on $ext_if inet proto {tcp udp} from any to $localnet port $connectable synproxy state label "Allow incoming connections -> mapped $proto ports on $if." > > # trusted IPs > pass from to any keep state label "Grant access to trusted IPs." > > # trust local network > pass in on $int_if all modulate state label "Permit incoming traffic from the Local network." > pass out on $int_if proto {tcp, udp} from any to $localnet4 port $connectable modulate state label "Allow connections to mapped ports to reach LAN destinations." > pass proto tcp from any to $localnet6 port $client_tcp_services modulate state label "Allow IPv6 access to/from the ($proto) client services." > pass proto { tcp, udp } from any to $localnet6 port $connectable modulate state label "Allow IPv6 access to/from the connectable ($proto) ports." -- - Petko From owner-freebsd-pf@FreeBSD.ORG Mon Jan 19 11:07:03 2009 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 25101106564A for ; Mon, 19 Jan 2009 11:07:03 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EBE6F8FC14 for ; Mon, 19 Jan 2009 11:07:02 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n0JB72CO063052 for ; Mon, 19 Jan 2009 11:07:02 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n0JB72CI063048 for freebsd-pf@FreeBSD.org; Mon, 19 Jan 2009 11:07:02 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 19 Jan 2009 11:07:02 GMT Message-Id: <200901191107.n0JB72CI063048@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-pf@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org 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: Mon, 19 Jan 2009 11:07:03 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/130381 pf [rc.d] [pf] [ip6] ipv6 not fully configured when pf st o kern/129861 pf [pf] [patch] Argument names reversed in pf_table.c:_co o kern/129060 pf [pf] [tun] pf doesn't forget the old tun IP o kern/127920 pf [pf] ipv6 and synproxy don't play well together o conf/127814 pf [pf] The flush in pf_reload in /etc/rc.d/pf does not w o conf/127511 pf [patch] /usr/sbin/authpf: add authpf folders to BSD.ro o kern/127439 pf [pf] deadlock in pf o kern/127345 pf [pf] Problem with PF on FreeBSD7.0 [regression] o kern/127121 pf [pf] [patch] pf incorrect log priority o kern/127042 pf [pf] [patch] pf recursion panic if interface group is o kern/125467 pf [pf] pf keep state bug while handling sessions between s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented o kern/124364 pf [pf] [panic] Kernel panic with pf + bridge o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf o kern/121704 pf [pf] PF mangles loopback packets o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o bin/118355 pf [pf] [patch] pfctl(8) help message options order false o kern/114567 pf [pf] [lor] pf_ioctl.c + if.c o kern/114095 pf [carp] carp+pf delay with high state limit o kern/111220 pf [pf] repeatable hangs while manipulating pf tables s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5. o kern/103283 pf pfsync fails to sucessfully transfer some sessions o kern/103281 pf pfsync reports bulk update failures o kern/93825 pf [pf] pf reply-to doesn't work o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/92949 pf [pf] PF + ALTQ problems with latency o kern/82271 pf [pf] cbq scheduler cause bad latency 29 problems total. From owner-freebsd-pf@FreeBSD.ORG Wed Jan 21 13:08:42 2009 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 57C551065758 for ; Wed, 21 Jan 2009 13:08:42 +0000 (UTC) (envelope-from fbsdmail@dnswatch.com) Received: from fast.dnswatch.com (fast.dnswatch.com [75.160.109.234]) by mx1.freebsd.org (Postfix) with ESMTP id 036498FC24 for ; Wed, 21 Jan 2009 13:08:41 +0000 (UTC) (envelope-from fbsdmail@dnswatch.com) Received: from webmail.dnswatch.com (localhost.dnswatch.com [127.0.0.1]) by fast.dnswatch.com (8.14.2/8.14.2) with ESMTP id n0LD8XRK060346; Wed, 21 Jan 2009 05:08:40 -0800 (PST) (envelope-from fbsdmail@dnswatch.com) Received: from hitme.hitometer.net ([75.160.109.235]) (DNSwatchWebMail authenticated user infos) by webmail.dnswatch.com with HTTP; Wed, 21 Jan 2009 05:08:41 -0800 (PST) Message-ID: <2bac2a6d6830391e797190f7a398e7e6.dnswclient@webmail.dnswatch.com> In-Reply-To: <497382D3.8040408@quip.cz> References: <59e0bfe9193784283b7c7aaa2d958ad7.dnswclient@webmail.dnswatch.com> <497382D3.8040408@quip.cz> Date: Wed, 21 Jan 2009 05:08:41 -0800 (PST) From: fbsdmail@dnswatch.com To: "Miroslav Lachman" <000.fbsd@quip.cz> User-Agent: DNSwatchWebMail/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-pf@freebsd.org Subject: Re: basic rule request - allow_all/block_bad 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: Wed, 21 Jan 2009 13:08:42 -0000 Greetings Miroslav, and thank you for your reply... On Sun, January 18, 2009 11:28 am, Miroslav Lachman wrote: > infos@dnswatch.com wrote: > >> Greetings, >> I know very little about creating an initial pf.conf. >> I know /very/ /much/ that I want/need PF, and will need a fair amount >> of time to "tune" pf to work optimally for each server. BUT, in an effort >> to get started, I'm hoping that some kind soul will provide me with a >> very basic pf.conf that will not interrupt the current >> application/server block policies I already have in place - which is to >> say; I currently block at the application/server, but hope to merge >> (transfer) them to PF. So. can anyone share a pf.conf that will >> allow all, but block ALL_EVIL_IP requests on ALL ports? In other words, >> if I only wanted to block (drop) ALL traffic coming from a /single/ IP >> address. How would I do it? I have one (active) NIC in each of my >> servers, and there are anywhere from 3 to 12 IP's aliased to them above >> and beyond the IP assigned to the host itself. All addresses are fully >> qualified, internet route-able addresses (no internal/private IP's). >> > > If you really need to block one IP, you can use following simple ruleset: > > > block in quick from 10.20.30.40 to any pass all > > If you need to block more than one address, or you need easy > manipulation with list of addresses, you can use tables in ruleset: > > table persist file "/etc/pf.badguys.table" block in quick from > to any > pass all > > > You can put IPs in to persistent file /etc/pf.badguys.table, these IPs > will be loaded in the boot time. You can add / remove address on the fly by > pfctl command: pfctl -t badguys -T add 10.11.12.13 pfctl -t badguys -T > delete 10.11.12.13 Thank you. That's perfect! I seem to be stumped on one last issue; All the information, and pf.conf files all provide for 2 interfaces - INT_IF, and EXT_IF. Assuming a single NIC (ethernet adapter), and only Internet routable IP addresses, and a l0 (loopback). How would I define/use the 2 IF's? Dummynet, maybe? Thank you again for your thoughtful reply. --Chris > > Miroslav Lachman > > From owner-freebsd-pf@FreeBSD.ORG Wed Jan 21 17:32:25 2009 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 9D584106564A for ; Wed, 21 Jan 2009 17:32:25 +0000 (UTC) (envelope-from fbsdmail@dnswatch.com) Received: from fast.dnswatch.com (fast.dnswatch.com [75.160.109.234]) by mx1.freebsd.org (Postfix) with ESMTP id 583298FC19 for ; Wed, 21 Jan 2009 17:32:25 +0000 (UTC) (envelope-from fbsdmail@dnswatch.com) Received: from webmail.dnswatch.com (localhost.dnswatch.com [127.0.0.1]) by fast.dnswatch.com (8.14.2/8.14.2) with ESMTP id n0LHWH9Q062168; Wed, 21 Jan 2009 09:32:24 -0800 (PST) (envelope-from fbsdmail@dnswatch.com) Received: from hitme.hitometer.net ([75.160.109.235]) (DNSwatchWebMail authenticated user infos) by webmail.dnswatch.com with HTTP; Wed, 21 Jan 2009 09:32:24 -0800 (PST) Message-ID: <5b1b0988c6b59c6422697ab790624621.dnswclient@webmail.dnswatch.com> In-Reply-To: <49775195.80809@radel.com> References: <59e0bfe9193784283b7c7aaa2d958ad7.dnswclient@webmail.dnswatch.com> <497382D3.8040408@quip.cz> <2bac2a6d6830391e797190f7a398e7e6.dnswclient@webmail.dnswatch.com> <49775195.80809@radel.com> Date: Wed, 21 Jan 2009 09:32:24 -0800 (PST) From: fbsdmail@dnswatch.com To: "Jon Radel" User-Agent: DNSwatchWebMail/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-pf@freebsd.org Subject: Re: basic rule request - allow_all/block_bad 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: Wed, 21 Jan 2009 17:32:26 -0000 Greetings, and thank you for your reply... On Wed, January 21, 2009 8:47 am, Jon Radel wrote: > > fbsdmail@dnswatch.com wrote: > >>> block in quick from 10.20.30.40 to any pass all >>> >>> If you need to block more than one address, or you need easy >>> manipulation with list of addresses, you can use tables in ruleset: >>> >>> table persist file "/etc/pf.badguys.table" block in quick >>> from to any >>> pass all >>> >>> >>> You can put IPs in to persistent file /etc/pf.badguys.table, these >>> IPs >>> will be loaded in the boot time. You can add / remove address on the >>> fly by pfctl command: pfctl -t badguys -T add 10.11.12.13 pfctl -t >>> badguys -T delete 10.11.12.13 >> >> Thank you. That's perfect! >> >> >> I seem to be stumped on one last issue; >> All the information, and pf.conf files all provide for 2 interfaces - >> INT_IF, and EXT_IF. >> Assuming a single NIC (ethernet adapter), and only Internet routable >> IP addresses, and a l0 (loopback). How would I define/use the 2 IF's? >> Dummynet, maybe? >> >> > > Ick (if you don't mind my saying so). No, don't make your life hell by > coming up with dummy interfaces. The example line you were given by > Miroslav at very top of my reply is standalone if you wish. A rule set > like: > > > > set skip on l0 block in quick from 10.20.30.40 to any pass all > > should be completely stand-alone. It means: > > 1) Completely ignore the loopback interface for filtering purposes > (supposedly more efficient than setting up a pass all or something to > make sure other rules don't give you weird side effects on the loopback). > > 2) On any interface (since you didn't mention one in the rule) (other > than on lo0, since you're ignoring it) block any incoming packets that come > from 10.20.30.40. The fact that there's only one interface is of no > particular consequence. > > 3) Pass everything else in and out on all interfaces (other than lo0, > which is passing everything since it's being ignored). Again, that there > is only one interface is of no concern. > > All those INT_IF, etc., macros you see in examples are there because > it's considered best practice to use macros and document your rule set. For > a 3 line rule set where you're the only maintainer, feel free to rip that > all out.... ;-) > > After you get that running, I'd suggest you start making things fancier > with Miroslav's recommendation about using a table, putting in scrub with > some of the less agressive options, protecting yourself from packets with > spoofed addresses, etc., etc. All good advice. I decided shortly after sending this question, to simply dive in and take a chance. So I simply omitted the IF part I was asking about, and modified the suggestion(s) Miroslav was kind enough to offer. I have one NIC which is assigned the hosts address, I also have to additional IP's aliased against it. I only brought up lo0 because I wasn't sure if, or why that might be a consideration. Anyway, as you might imagine, Miroslav's suggestion worked perfectly - THANKS Miroslav. :-) I actually had several reoccurring "baddies" so I chose the "table" method. Now their noise has vanished. :-) Now, it's off to tweak (tune) the settings, and make some more additions, so as to make better use of it. Thank you again for taking the time to respond. Thanks again to you Miroslav. Best wishes. --Chris > > --Jon Radel > > > From owner-freebsd-pf@FreeBSD.ORG Wed Jan 21 17:47:51 2009 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 1B2E4106566B for ; Wed, 21 Jan 2009 17:47:51 +0000 (UTC) (envelope-from jon@radel.com) Received: from wave.radel.com (wave.radel.com [216.143.151.4]) by mx1.freebsd.org (Postfix) with ESMTP id C576F8FC23 for ; Wed, 21 Jan 2009 17:47:50 +0000 (UTC) (envelope-from jon@radel.com) Received: by wave.radel.com (CommuniGate Pro PIPE 4.1.6) with PIPE id 8308081; Wed, 21 Jan 2009 11:47:50 -0500 Received: from [216.143.146.251] (account laura@radel.com HELO 84.sub-70-223-142.myvzw.com) by wave.radel.com (CommuniGate Pro SMTP 4.1.6) with ESMTP id 8308079; Wed, 21 Jan 2009 11:47:25 -0500 Message-ID: <49775195.80809@radel.com> Date: Wed, 21 Jan 2009 11:47:17 -0500 From: Jon Radel User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: fbsdmail@dnswatch.com References: <59e0bfe9193784283b7c7aaa2d958ad7.dnswclient@webmail.dnswatch.com> <497382D3.8040408@quip.cz> <2bac2a6d6830391e797190f7a398e7e6.dnswclient@webmail.dnswatch.com> In-Reply-To: <2bac2a6d6830391e797190f7a398e7e6.dnswclient@webmail.dnswatch.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Radel.com-MailScanner-Information: Please contact Jon for more information X-Radel.com-MailScanner: Found to be clean X-Mailer: CommuniGate Pro CLI mailer Cc: freebsd-pf@freebsd.org Subject: Re: basic rule request - allow_all/block_bad 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: Wed, 21 Jan 2009 17:47:51 -0000 fbsdmail@dnswatch.com wrote: >> block in quick from 10.20.30.40 to any pass all >> >> If you need to block more than one address, or you need easy >> manipulation with list of addresses, you can use tables in ruleset: >> >> table persist file "/etc/pf.badguys.table" block in quick from >> to any >> pass all >> >> >> You can put IPs in to persistent file /etc/pf.badguys.table, these IPs >> will be loaded in the boot time. You can add / remove address on the fly by >> pfctl command: pfctl -t badguys -T add 10.11.12.13 pfctl -t badguys -T >> delete 10.11.12.13 > > Thank you. That's perfect! > > I seem to be stumped on one last issue; > All the information, and pf.conf files all provide for 2 interfaces - > INT_IF, and EXT_IF. > Assuming a single NIC (ethernet adapter), and only Internet routable > IP addresses, and a l0 (loopback). How would I define/use the 2 IF's? > Dummynet, maybe? > Ick (if you don't mind my saying so). No, don't make your life hell by coming up with dummy interfaces. The example line you were given by Miroslav at very top of my reply is standalone if you wish. A rule set like: set skip on l0 block in quick from 10.20.30.40 to any pass all should be completely stand-alone. It means: 1) Completely ignore the loopback interface for filtering purposes (supposedly more efficient than setting up a pass all or something to make sure other rules don't give you weird side effects on the loopback). 2) On any interface (since you didn't mention one in the rule) (other than on lo0, since you're ignoring it) block any incoming packets that come from 10.20.30.40. The fact that there's only one interface is of no particular consequence. 3) Pass everything else in and out on all interfaces (other than lo0, which is passing everything since it's being ignored). Again, that there is only one interface is of no concern. All those INT_IF, etc., macros you see in examples are there because it's considered best practice to use macros and document your rule set. For a 3 line rule set where you're the only maintainer, feel free to rip that all out.... ;-) After you get that running, I'd suggest you start making things fancier with Miroslav's recommendation about using a table, putting in scrub with some of the less agressive options, protecting yourself from packets with spoofed addresses, etc., etc. --Jon Radel From owner-freebsd-pf@FreeBSD.ORG Thu Jan 22 19:51:22 2009 Return-Path: Delivered-To: pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB6A91065672 for ; Thu, 22 Jan 2009 19:51:22 +0000 (UTC) (envelope-from mksmith@adhost.com) Received: from mail-defer01.adhost.com (mail-defer01.adhost.com [216.211.128.176]) by mx1.freebsd.org (Postfix) with ESMTP id C4D038FC24 for ; Thu, 22 Jan 2009 19:51:22 +0000 (UTC) (envelope-from mksmith@adhost.com) Received: from mail-in05.adhost.com (mail-in05.adhost.com [10.212.3.15]) by mail-defer01.adhost.com (Postfix) with ESMTP id 097A510A70 for ; Thu, 22 Jan 2009 11:32:45 -0800 (PST) (envelope-from mksmith@adhost.com) Received: from ad-exh01.adhost.lan (exchange.adhost.com [216.211.143.69]) by mail-in05.adhost.com (Postfix) with ESMTP id C66D598D9FF for ; Thu, 22 Jan 2009 11:32:44 -0800 (PST) (envelope-from mksmith@adhost.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 x-pgp-encoding-format: MIME x-pgp-mapi-encoding-version: 2.5.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="PGP_Universal_5A781E29_FCEFC1C4_1D7F44BB_4804FD13" x-pgp-encoding-version: 2.0.2 Content-class: urn:content-classes:message Date: Thu, 22 Jan 2009 11:32:44 -0800 Message-ID: <17838240D9A5544AAA5FF95F8D520316056585C1@ad-exh01.adhost.lan> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issues with PF and 7.1 Thread-Index: Acl8yC9uy9wFHp43T8q2iECwNCp0Qg== From: "Michael K. Smith - Adhost" To: Cc: Subject: Issues with PF and 7.1 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: Thu, 22 Jan 2009 19:51:23 -0000 --PGP_Universal_5A781E29_FCEFC1C4_1D7F44BB_4804FD13 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: QUOTED-PRINTABLE Hello All: We are having memory issues with PF and 7.1p2 that we didn't experience wit= h 6.3. Here's what happens. # pfctl -f /usr/local/etc/pf.conf /usr/local/etc/pf.conf:135: cannot define table smtpd_reject_policyd: Canno= t allocate memory /usr/local/etc/pf.conf:139: cannot define table smtpd_reject_spam: Cannot a= llocate memory pfctl: Syntax error in config file: pf rules not loaded # pfctl -t smtpd_reject_policyd -T flush 94390 addresses deleted. # pfctl -t smtpd_reject_spam -T flush 62464 addresses deleted. # pfctl -f /usr/local/etc/pf.conf So, after I flush the tables it loads. Sometimes, however, we get a global= out of memory error " DIOCADDRULE: Cannot allocate memory " Here are my entries from pf.conf for various limits. Everything else is de= faults. set limit tables 500 set limit table-entries 250000 set limit { states 1000000, src-nodes 300000, frags 100000 } set optimization normal set skip on lo0 set state-policy if-bound set timeout interval 300 set timeout src.track 1200 Finally, the box is using EM interfaces with VLAN's and has 4 Gig of physic= al RAM. There are two PF boxes in Active/Failover and the errors show up o= n both, although they seem to show up more often on the Backup device, whic= h seems odd. Any help would be greatly appreciated. =20 Regards, Mike -- Michael K. Smith - CISSP, GISP Chief Technical Officer - Adhost Internet LLC mksmith@adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) --PGP_Universal_5A781E29_FCEFC1C4_1D7F44BB_4804FD13 Content-Type: application/pgp-signature; name="PGP.sig" Content-Transfer-Encoding: 7BIT Content-Disposition: attachment; filename="PGP.sig" -----BEGIN PGP SIGNATURE----- Version: 9.9.1 (Build 287) iQEVAwUBSXjJ3PTXQhZ+XcVAAQjvdAf9EYGGtY0H+CHvXxHrqf0c7PH8v+RK3KPB s+SagdF6t3My+qg91pTtbwKOsz3jnYux2WdQzO+d+kvZOqHfpEWT8cgCi6MZBrEI gODuw32yoiAhEEgtk4Q2jDR8wS1s7USdo8tcv6WteqMUxc7YY7rSvB5ifwzy8Bxw wYIljG3+cqlBPM1ZSkVsHGilwA4oMc2hWOoSAKP4h4/Lb66dd0kPfqJshaE0BiH/ Bz8ngVISxEEWMOdKhgWsAM15aibOJn7Zqz1KEDPjRJ+U4We0LiJ4t1o/Mz6ZF4Iv tmin739E6G2WRHhHw/BZqlm+xleqV39tZZU8db+AWeRzdc+FFOJWJQ== =ziCP -----END PGP SIGNATURE----- --PGP_Universal_5A781E29_FCEFC1C4_1D7F44BB_4804FD13-- From owner-freebsd-pf@FreeBSD.ORG Fri Jan 23 17:47:18 2009 Return-Path: Delivered-To: pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58CEB106567B for ; Fri, 23 Jan 2009 17:47:18 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from mail-ew0-f20.google.com (mail-ew0-f20.google.com [209.85.219.20]) by mx1.freebsd.org (Postfix) with ESMTP id B4C3B8FC1D for ; Fri, 23 Jan 2009 17:47:17 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: by ewy13 with SMTP id 13so4599003ewy.19 for ; Fri, 23 Jan 2009 09:47:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=h5pPpSVbvxF8a8gbtstuGZCko7+8z1Q/xBZWfdEZpEQ=; b=KgMHUp3/d5WS4wMYg13hFFUiPVCERTlSNFrEmFdrPxHeIVZRLzW7hZ1NBux+qou9YP wRzMp4HuOMdcYceEOMGFlvPL2cp4dLsXr1LBKpr7jHw3HMAiwzE6bQuHeIhQ821QZ50n dYtP6Ka46zWrV+a0TRFD3XLiAD1lJBxRF5d/w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=j0/SRPMr3uGkiQvH1wFqPnEbH2EsfO+vVzZnSEs7kZqBsGP/Hi5DoN5ppiS+WGHZs6 Q4Vfi5wXB8bXVdypll1C1rpZe0gQj8cVQdm6mBlREVRRz7QTSLAW5ju9w5cIz5V3ytby 4eUt2NrMCwg/KkAeFjsT2p/GSIWerCoy0DEPk= MIME-Version: 1.0 Received: by 10.103.161.16 with SMTP id n16mr147muo.79.1232731292468; Fri, 23 Jan 2009 09:21:32 -0800 (PST) In-Reply-To: <17838240D9A5544AAA5FF95F8D520316056585C1@ad-exh01.adhost.lan> References: <17838240D9A5544AAA5FF95F8D520316056585C1@ad-exh01.adhost.lan> Date: Fri, 23 Jan 2009 12:21:32 -0500 Message-ID: From: Scott Ullrich To: "Michael K. Smith - Adhost" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pf@freebsd.org Subject: Re: Issues with PF and 7.1 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: Fri, 23 Jan 2009 17:47:18 -0000 On Thu, Jan 22, 2009 at 2:32 PM, Michael K. Smith - Adhost wrote: > Hello All: > > We are having memory issues with PF and 7.1p2 that we didn't experience with 6.3. Here's what happens. > > # pfctl -f /usr/local/etc/pf.conf > /usr/local/etc/pf.conf:135: cannot define table smtpd_reject_policyd: Cannot allocate memory > /usr/local/etc/pf.conf:139: cannot define table smtpd_reject_spam: Cannot allocate memory > pfctl: Syntax error in config file: pf rules not loaded > # pfctl -t smtpd_reject_policyd -T flush > 94390 addresses deleted. > # pfctl -t smtpd_reject_spam -T flush > 62464 addresses deleted. > # pfctl -f /usr/local/etc/pf.conf > > So, after I flush the tables it loads. Sometimes, however, we get a global out of memory error " DIOCADDRULE: Cannot allocate memory " > > Here are my entries from pf.conf for various limits. Everything else is defaults. > > set limit tables 500 > set limit table-entries 250000 > set limit { states 1000000, src-nodes 300000, frags 100000 } > set optimization normal > set skip on lo0 > set state-policy if-bound > set timeout interval 300 > set timeout src.track 1200 > > Finally, the box is using EM interfaces with VLAN's and has 4 Gig of physical RAM. There are two PF boxes in Active/Failover and the errors show up on both, although they seem to show up more often on the Backup device, which seems odd. > > Any help would be greatly appreciated. My first response would have been to set set limit table-entries but you already did that. Next thing I would check is a shot in the dark, but worth trying.. What does sysctl vm.kmem_size_max show? Try increasing that size a bit in loader.conf and see if that helps. Scott From owner-freebsd-pf@FreeBSD.ORG Fri Jan 23 18:04:24 2009 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 8144D106564A for ; Fri, 23 Jan 2009 18:04:24 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.freebsd.org (Postfix) with ESMTP id 111068FC17 for ; Fri, 23 Jan 2009 18:04:24 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-034-230.pools.arcor-ip.net [88.66.34.230]) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis) id 0MKwtQ-1LQQOF0EUN-0004tH; Fri, 23 Jan 2009 19:04:23 +0100 Received: (qmail 29760 invoked from network); 23 Jan 2009 18:04:22 -0000 Received: from fbsd8.laiers.local (192.168.4.200) by router.laiers.local with SMTP; 23 Jan 2009 18:04:22 -0000 From: Max Laier Organization: FreeBSD To: freebsd-pf@freebsd.org Date: Fri, 23 Jan 2009 19:04:22 +0100 User-Agent: KMail/1.10.4 (FreeBSD/8.0-CURRENT; KDE/4.1.4; i386; ; ) References: <17838240D9A5544AAA5FF95F8D520316056585C1@ad-exh01.adhost.lan> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901231904.22558.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1+MAURQE8ncjaZ3mYNlZujZwbY5AIVCBM3XfpK +MT+qxYmNRxm7flV/69lpTnA0O/q+Jhc2fh0qYkQVDdep6Jl4/ YE44uy1Fq9NgRt+5AoToQ== Cc: Subject: Re: Issues with PF and 7.1 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: Fri, 23 Jan 2009 18:04:24 -0000 On Friday 23 January 2009 18:21:32 Scott Ullrich wrote: > On Thu, Jan 22, 2009 at 2:32 PM, Michael K. Smith - Adhost > > wrote: > > Hello All: > > > > We are having memory issues with PF and 7.1p2 that we didn't experience > > with 6.3. Here's what happens. > > > > # pfctl -f /usr/local/etc/pf.conf > > /usr/local/etc/pf.conf:135: cannot define table smtpd_reject_policyd: > > Cannot allocate memory /usr/local/etc/pf.conf:139: cannot define table > > smtpd_reject_spam: Cannot allocate memory pfctl: Syntax error in config > > file: pf rules not loaded > > # pfctl -t smtpd_reject_policyd -T flush > > 94390 addresses deleted. > > # pfctl -t smtpd_reject_spam -T flush > > 62464 addresses deleted. > > # pfctl -f /usr/local/etc/pf.conf > > > > So, after I flush the tables it loads. Sometimes, however, we get a > > global out of memory error " DIOCADDRULE: Cannot allocate memory " > > > > Here are my entries from pf.conf for various limits. Everything else is > > defaults. > > > > set limit tables 500 > > set limit table-entries 250000 > > set limit { states 1000000, src-nodes 300000, frags 100000 } > > set optimization normal > > set skip on lo0 > > set state-policy if-bound > > set timeout interval 300 > > set timeout src.track 1200 > > > > Finally, the box is using EM interfaces with VLAN's and has 4 Gig of > > physical RAM. There are two PF boxes in Active/Failover and the errors > > show up on both, although they seem to show up more often on the Backup > > device, which seems odd. > > > > Any help would be greatly appreciated. > > My first response would have been to set set limit table-entries but > you already did that. > > Next thing I would check is a shot in the dark, but worth trying.. > > What does sysctl vm.kmem_size_max show? Try increasing that size a > bit in loader.conf and see if that helps. Seconded. My guess is that the system flushes buffers when you first load the tables due to memory pressure, so when you load the tables a second time there is more space available. This, however, suggest that you are pretty thin stretched regarding kvm and should really increase it. I'd shoot for at least 512M which I believe is the maximum in 7.1 with the stock kernel. It seems that there is work in progress to increase that limit for amd64 in releng_7, however. Increasing this is worthwhile in any case, as I have a hard time imagining what else you'd be doing with those 4G on the firewalls (unless you are running heavy webcaches on them, too). -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-pf@FreeBSD.ORG Fri Jan 23 23:07:30 2009 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 47D10106567C for ; Fri, 23 Jan 2009 23:07:30 +0000 (UTC) (envelope-from mksmith@adhost.com) Received: from mail-defer02.adhost.com (mail-defer02.adhost.com [216.211.128.177]) by mx1.freebsd.org (Postfix) with ESMTP id 1D1828FC1F for ; Fri, 23 Jan 2009 23:07:29 +0000 (UTC) (envelope-from mksmith@adhost.com) Received: from mail-in06.adhost.com (mail-in06.adhost.com [10.212.3.16]) by mail-defer02.adhost.com (Postfix) with ESMTP id 38AFD1748ACF for ; Fri, 23 Jan 2009 14:48:51 -0800 (PST) (envelope-from mksmith@adhost.com) Received: from ad-exh01.adhost.lan (exchange.adhost.com [216.211.143.69]) by mail-in06.adhost.com (Postfix) with ESMTP id 0DA53D5CAC7; Fri, 23 Jan 2009 14:48:49 -0800 (PST) (envelope-from mksmith@adhost.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 x-pgp-encoding-format: MIME x-pgp-mapi-encoding-version: 2.5.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="PGP_Universal_049A5D3D_A7A9586A_C05CE6F8_3588547D" x-pgp-encoding-version: 2.0.2 Content-class: urn:content-classes:message Date: Fri, 23 Jan 2009 14:48:48 -0800 Message-ID: <17838240D9A5544AAA5FF95F8D52031605658786@ad-exh01.adhost.lan> In-Reply-To: <200901231904.22558.max@love2party.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issues with PF and 7.1 Thread-Index: Acl9hQlJKxMLuSJxQp2usOTy0+m5FQAJGwhQ References: <17838240D9A5544AAA5FF95F8D520316056585C1@ad-exh01.adhost.lan> <200901231904.22558.max@love2party.net> From: "Michael K. Smith - Adhost" To: "Max Laier" , Cc: Subject: RE: Issues with PF and 7.1 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: Fri, 23 Jan 2009 23:07:30 -0000 --PGP_Universal_049A5D3D_A7A9586A_C05CE6F8_3588547D Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: QUOTED-PRINTABLE Hello All: > > What does sysctl vm.kmem_size_max show? Try increasing that size a > > bit in loader.conf and see if that helps. >=20 > Seconded. My guess is that the system flushes buffers when you first loa= d the > tables due to memory pressure, so when you load the tables a second time = there > is more space available. This, however, suggest that you are pretty thin > stretched regarding kvm and should really increase it. I'd shoot for at = least > 512M which I believe is the maximum in 7.1 with the stock kernel. It see= ms > that there is work in progress to increase that limit for amd64 in releng= _7, > however. Increasing this is worthwhile in any case, as I have a hard time > imagining what else you'd be doing with those 4G on the firewalls (unless= you > are running heavy webcaches on them, too). >=20 Thanks for the info. In stages, we upped the vm.kmem_size_max from 300M to= 1536M after modifying the kernel (we actually tried 2048M but that caused = a panic). With the 1536M setting the 'DIOCADDRULE: Cannot allocate memory'= doesn't occur anymore, but we still have to flush the tables manually when= the system comes up. Now, at least, the flush actually works and PF loads= successfully, but only after we do the flush on all the tables. As you ca= n imagine, this is not optimal for unattended/random reboots, which we see = about 3 times a week. Regards, Mike --PGP_Universal_049A5D3D_A7A9586A_C05CE6F8_3588547D Content-Type: application/pgp-signature; name="PGP.sig" Content-Transfer-Encoding: 7BIT Content-Disposition: attachment; filename="PGP.sig" -----BEGIN PGP SIGNATURE----- Version: 9.9.1 (Build 287) iQEVAwUBSXpJUPTXQhZ+XcVAAQgjdQf/QmzlgzNbjvDbd5SC+JytZQCmznhH6QPg HFXUCf8VUR1EFNmJSohrHoCwq9S0K6A6bpaCZ5RMxt523Om6UfRBD3VEi/ADKcNZ 4Uieew895GZ/0oQjPodnae5cE5MvD9u7LHwmQSZIFdS6bLm/sMxAKx7rG6x4A7sg Ffjv+r9H1Uu5Sn8xwBaKJRqxEUAWqMxC01pvdVVPea5uFgSIQ6aU/55I3kGKRViK sTjpPWfkqkcJpEk0fNvrhL58fNZoWN3Fj5eogIPJfQj242W5JrJ7E+TsOTEgCNCm HIvuBIug+sK6JjJk7zq08VyvVWbJU1NClONnx8pGKjimzGHrTS6VEw== =GX/3 -----END PGP SIGNATURE----- --PGP_Universal_049A5D3D_A7A9586A_C05CE6F8_3588547D--