From owner-freebsd-pf@FreeBSD.ORG Sun Nov 9 10:03:24 2008 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 0DE141065673 for ; Sun, 9 Nov 2008 10:03:24 +0000 (UTC) (envelope-from omasnjak@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by mx1.freebsd.org (Postfix) with ESMTP id D851B8FC0A for ; Sun, 9 Nov 2008 10:03:23 +0000 (UTC) (envelope-from omasnjak@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so1924080wfg.7 for ; Sun, 09 Nov 2008 02:03:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=UsoxTQMh1a2d8vwnQFHzGoZoxCta9M8LF2oSiSnpxFo=; b=h3K8ddPbIldlGQv2ekucLiGnbXfLb4OLVjgTlFo1pfudANxkI6tvT0h+3EOgqSuCzs eXOiATEEBzNOTTvofXuPMO887ZCpHExA8HGAB2E1kfy+LZOVVzgEcTwkJFqJGfMbkeBe UKeNuqs+iR3hiuqjE+qj2RpgamR0oFR6KF7Fc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=Cw2BJTAX5/Oe7XE98aPixVk48Ymy9rp3ZLFoUPwbCd7B5+XyYLS6DsmSMT1veRnLX4 p9VWHSx8vvynrMEhm8/JPqIZ3CtjXC6RIvfyEybL28M+34RPceOvqG1KMf9fzhVX1X23 9+3XdCQuOsII9Vx9ilgomGHahgU5CLLAi32Dg= Received: by 10.142.163.1 with SMTP id l1mr1742423wfe.263.1226223449735; Sun, 09 Nov 2008 01:37:29 -0800 (PST) Received: by 10.143.93.6 with HTTP; Sun, 9 Nov 2008 01:37:29 -0800 (PST) Message-ID: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com> Date: Sun, 9 Nov 2008 10:37:29 +0100 From: "Elvir Kuric" To: freebsd-pf@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: 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, 09 Nov 2008 10:03:24 -0000 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. Any suggestion is welcome, With Regards, Elvir Kuric From owner-freebsd-pf@FreeBSD.ORG Sun Nov 9 11:05:40 2008 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 37253106567E for ; Sun, 9 Nov 2008 11:05:40 +0000 (UTC) (envelope-from omasnjak@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by mx1.freebsd.org (Postfix) with ESMTP id 0857A8FC2E for ; Sun, 9 Nov 2008 11:05:39 +0000 (UTC) (envelope-from omasnjak@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so1937624wfg.7 for ; Sun, 09 Nov 2008 03:05:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=hTo5Jri7yInZUEu+nhCYulRdWX6QEpMhKeEbXwJjc70=; b=IPdeoM6H1DThzZVoGnAP5xZtwRh50/K3Ve/hqmo/edTg+xslB3uUfe1Da40FQ03QlB V2ek1sbIMRjBAcVFZoTcUKY9+U86Ps1jUq82WtwB1Zm4Z3pu6NqpvW8BZLJTtrBxceLc UIDOiqg++6w8+uQ7Tz3Ftxqu7dCdBwd+Y+3LQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=E9XMIb7tJ0bWf//wX5XqXEyjLWHDNdoFCdXofQgDN7QIZKNtX6vAjuRLAAlSA6k+Gc 5eYD+oIqa2IX+xkEK0AIq+I3Nm2RyfZTXZUKnIJGHNEpxYQnL8z8JQ9J/FOyHg3TL7KX dyuA5STkWrHG0ALSGtevgSdwPdHQlzCONyz8w= Received: by 10.142.237.19 with SMTP id k19mr1768433wfh.296.1226228739313; Sun, 09 Nov 2008 03:05:39 -0800 (PST) Received: by 10.143.93.6 with HTTP; Sun, 9 Nov 2008 03:05:39 -0800 (PST) Message-ID: <1814bfe70811090305y48b493c8h501f8d031510e62d@mail.gmail.com> Date: Sun, 9 Nov 2008 12:05:39 +0100 From: "Elvir Kuric" To: "Daniel Gerzo" In-Reply-To: <425228071.20081109114720@rulez.sk> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com> <425228071.20081109114720@rulez.sk> Cc: freebsd-pf@freebsd.org 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, 09 Nov 2008 11:05:40 -0000 Hello Daniel, thank you for answer, I understand, but I know pf is very powerful tool I want to make some workaround using pf to perform blocking udp floods, rule creation is not problem and I understand pf syntax. ISP also use I suppose pf as firewall on their machines, so if they can, I/we using pf aslo can make that :). I am reading manuals, HOWTOs, because I know it must be some way to make what I want using pf firewall tool Kind regards, Elvir On Sun, Nov 9, 2008 at 11:47 AM, Daniel Gerzo wrote: > Hello Elvir, > > Sunday, November 9, 2008, 10:37:29 AM, you wrote: > >> 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. > > Ask your ISP to block UDP upfront, so that it won't hit you at all. > You probably don't need incomming UDP anyway... > > -- > Best regards, > Daniel mailto:danger@FreeBSD.org > > From owner-freebsd-pf@FreeBSD.ORG Sun Nov 9 11:07:26 2008 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 830E21065674 for ; Sun, 9 Nov 2008 11:07:26 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from services.rulez.sk (services.rulez.sk [92.240.234.125]) by mx1.freebsd.org (Postfix) with ESMTP id 39B7A8FC2E for ; Sun, 9 Nov 2008 11:07:26 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from localhost (services.rulez.sk [92.240.234.125]) by services.rulez.sk (Postfix) with ESMTP id 6777613344A1; Sun, 9 Nov 2008 11:47:35 +0100 (CET) X-Virus-Scanned: amavisd-new at rulez.sk Received: from services.rulez.sk ([92.240.234.125]) by localhost (services.rulez.sk [92.240.234.125]) (amavisd-new, port 10024) with ESMTP id paEVV9VgOWGc; Sun, 9 Nov 2008 11:47:34 +0100 (CET) Received: from DANGER-PC (danger.mcrn.sk [84.16.37.254]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: danger@rulez.sk) by services.rulez.sk (Postfix) with ESMTPSA id 877661334493; Sun, 9 Nov 2008 11:47:34 +0100 (CET) Date: Sun, 9 Nov 2008 11:47:20 +0100 From: Daniel Gerzo X-Mailer: The Bat! (v3.99.3) Professional Organization: The FreeBSD Project X-Priority: 3 (Normal) Message-ID: <425228071.20081109114720@rulez.sk> To: "Elvir Kuric" In-Reply-To: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com> References: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-pf@freebsd.org Subject: Re: Blocking udp flood trafiic using pf, hints welcome X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Gerzo 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, 09 Nov 2008 11:07:26 -0000 Hello Elvir, Sunday, November 9, 2008, 10:37:29 AM, you wrote: > 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. Ask your ISP to block UDP upfront, so that it won't hit you at all. You probably don't need incomming UDP anyway... -- Best regards, Daniel mailto:danger@FreeBSD.org From owner-freebsd-pf@FreeBSD.ORG Sun Nov 9 11:21:27 2008 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 1337A106564A for ; Sun, 9 Nov 2008 11:21:27 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by mx1.freebsd.org (Postfix) with ESMTP id E98E58FC0C for ; Sun, 9 Nov 2008 11:21:26 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id czDe1a0010S2fkCA2zMSob; Sun, 09 Nov 2008 11:21:26 +0000 Received: from koitsu.dyndns.org ([69.181.141.110]) by OMTA09.emeryville.ca.mail.comcast.net with comcast id czMR1a0072P6wsM8VzMR8V; Sun, 09 Nov 2008 11:21:26 +0000 X-Authority-Analysis: v=1.0 c=1 a=6t4FfcucIIQA:10 a=tb0012eOZ7UA:10 a=QycZ5dHgAAAA:8 a=60CcDk4GsQpdapS_NbgA:9 a=yLppJgZqXCbkzMAREewA:7 a=kY1aOGcxi2s9Dmz33wP9AkloYd4A:4 a=B021log7hrUA:10 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 9F1C05C19; Sun, 9 Nov 2008 03:21:25 -0800 (PST) Date: Sun, 9 Nov 2008 03:21:25 -0800 From: Jeremy Chadwick To: Elvir Kuric Message-ID: <20081109112125.GA36707@icarus.home.lan> References: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-pf@freebsd.org 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, 09 Nov 2008 11:21:27 -0000 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. -- | 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 Nov 9 11:33:54 2008 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 58AC81065678 for ; Sun, 9 Nov 2008 11:33:54 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.189]) by mx1.freebsd.org (Postfix) with ESMTP id D927A8FC19 for ; Sun, 9 Nov 2008 11:33:53 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: by fk-out-0910.google.com with SMTP id k31so2674771fkk.11 for ; Sun, 09 Nov 2008 03:33:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Y0dSPu6UokWR7VF8tVUNVg59Ap/jxFAEX1dJo0aEalo=; b=BJE6CaCKEpGFNMRP7JfZQ1IXVvkjBe3XlNzocilsW4if+1ItAxryBiPgfToUqIdE9Q 0matDdfqLwXvwlFoVqxcyNdipiONLf/UMhavaquBURT6axn5WKWFO8hPR1ZOj3XpeFjP 2SpClUCMsBbL+yLVO73ZQJiJx1I2qOfHwcHC4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Zvt/w6XV0MXFWEB4cQAOIKB6xnhbLzmE+n5trRP5sA9VwG0Zp0KyS9rBlOl5VDIpNM gKbkx8PKfZLrje7FqvSpUwylj7cfcHSaBsH7g82W3LGlExiryg97umvoZofmCTEERQQ4 rskliX/uIAnx1nvZ5WWeSw7tS+TNje8OpEjIY= Received: by 10.187.226.5 with SMTP id d5mr1161467far.102.1226228953756; Sun, 09 Nov 2008 03:09:13 -0800 (PST) Received: by 10.187.194.10 with HTTP; Sun, 9 Nov 2008 03:09:13 -0800 (PST) Message-ID: <4ad871310811090309le19b2bwd2de855155b3797b@mail.gmail.com> Date: Sun, 9 Nov 2008 06:09:13 -0500 From: "Glen Barber" To: "Elvir Kuric" In-Reply-To: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com> Cc: freebsd-pf@freebsd.org 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, 09 Nov 2008 11:33:54 -0000 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 -- Glen Barber "If you have any trouble sounding condescending, find a Unix user to show you how it's done." --Scott Adams From owner-freebsd-pf@FreeBSD.ORG Sun Nov 9 13:16:33 2008 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 8F4BA1065672 for ; Sun, 9 Nov 2008 13:16:33 +0000 (UTC) (envelope-from omasnjak@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by mx1.freebsd.org (Postfix) with ESMTP id 5CD518FC1A for ; Sun, 9 Nov 2008 13:16:33 +0000 (UTC) (envelope-from omasnjak@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so1969419wfg.7 for ; Sun, 09 Nov 2008 05:16:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=dHe1W+Jw8UAatTgc6NFkuJKQSyzZnU7eo0ZW3NJXCto=; b=czmrUpWl22GgKZ1H/S4fLwwHQPQG1AIfGZ8fWnUrkxHiNOZXlkzrBXMZBHi6WvGpAc EMhsKuBJS73Kalky9VwDJ9C5rSQSJQu+QCdCXcZdZhb9fv3Cwd1f3gDsk10dALrR0kHi gjrCdGXEf7kuuSb7dyNLIhYAJCtIBZBab+5SI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=lGcfP401mx+loTSq/5Klwp2intOoEXyILnFi3eROwyaVcfg6awH77S1OXa3ianMm1g sWM3gNg6DokHyZRG//qkYajjA48izwyXMHNcFTE+D0JPxYP8bO0/FNJ/WNuTdejlwaab +neut05fwBA5CEIn6nGRDI/W/GKIQk4sdGMHk= Received: by 10.142.156.2 with SMTP id d2mr1812418wfe.102.1226236592939; Sun, 09 Nov 2008 05:16:32 -0800 (PST) Received: by 10.143.93.6 with HTTP; Sun, 9 Nov 2008 05:16:32 -0800 (PST) Message-ID: <1814bfe70811090516m78bdec90wa464606bdfa6c1ea@mail.gmail.com> Date: Sun, 9 Nov 2008 14:16:32 +0100 From: "Elvir Kuric" To: "Glen Barber" In-Reply-To: <4ad871310811090309le19b2bwd2de855155b3797b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com> <4ad871310811090309le19b2bwd2de855155b3797b@mail.gmail.com> Cc: freebsd-pf@freebsd.org 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, 09 Nov 2008 13:16:33 -0000 Hi Glen, Thank you for mail and help, actually I do not have these options on my openBSD box, on freeBSD box there are and I will implennt this. Thank you very much Kind regards, Elvir Kuric On Sun, Nov 9, 2008 at 12:09 PM, Glen Barber wrote: > 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 > > -- > Glen Barber > > "If you have any trouble sounding condescending, find a Unix user to > show you how it's done." > --Scott Adams > From owner-freebsd-pf@FreeBSD.ORG Sun Nov 9 13:44:54 2008 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 1D6661065673 for ; Sun, 9 Nov 2008 13:44:54 +0000 (UTC) (envelope-from omasnjak@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by mx1.freebsd.org (Postfix) with ESMTP id E0C4E8FC0C for ; Sun, 9 Nov 2008 13:44:53 +0000 (UTC) (envelope-from omasnjak@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so1977765wfg.7 for ; Sun, 09 Nov 2008 05:44:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Ig+kZTy8YnKbb8YS65L2K8557gFSdyeJHzuW6YMEvuE=; b=BHHNFznfWntNflUCo03H0Z39QA9FyC6kwBdeMlE7odZRNiSb1r7+kxcIHGikMz+Ico NK8eTUSZkMx3fV9okEpDxVwJGzN551KsVhjzFZ+YrSzyt8gLaz7CUZVycaBD0hrx2zTt pzORc7eW4SrcfAqqIMJ1jN9UvIS+xwm6gh7z8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Y0h9BWBGll8obHtI5YFvC+PP+RXNT5C3AZnXinMHd9r/cJ4z+1bpXOqabW6XKjiJqE pWWVjUZtVn1fVTQ68EL33892gUi4Tw6+x5a9KLDRF9TGbOqbzX0THhtIrg4ryVvSGTEw Y9QnljMhD3AQQUdwEGxlaZ/wez2dmGXW6N4Ck= Received: by 10.142.223.20 with SMTP id v20mr1822393wfg.7.1226238293492; Sun, 09 Nov 2008 05:44:53 -0800 (PST) Received: by 10.143.93.6 with HTTP; Sun, 9 Nov 2008 05:44:53 -0800 (PST) Message-ID: <1814bfe70811090544o28c29c5u185e3c0f2b8e85b4@mail.gmail.com> Date: Sun, 9 Nov 2008 14:44:53 +0100 From: "Elvir Kuric" To: "Jeremy Chadwick" In-Reply-To: <20081109112125.GA36707@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com> <20081109112125.GA36707@icarus.home.lan> Cc: freebsd-pf@freebsd.org 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, 09 Nov 2008 13:44:54 -0000 Hello Jeremy, Thank you for your time and your answer, > 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. :-) I absolutely agree with you regarding logging, and I do not practice this, only logging specific data. The biggest problem with this DoS attacks ( udp floods ) is, processor must spend some time on packet arrive ( even dropping will take some processor power ). > > 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). Actually it is OpenBSD, but it is not important for this case. > > 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. Block works fantastic, connection goes down due to milions of packets arrived. > > 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. No IRC is present here, or similar staff it is just firewal/router runing at the edge of internal network. Also on machines in internal network there is not some, "interesting " stuff. Thank you very much for your answer it is very helpful. > > 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. > > -- > | 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 | > > Kind regards, Elvir Kuric From owner-freebsd-pf@FreeBSD.ORG Sun Nov 9 18:17:59 2008 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 E90C41065676 for ; Sun, 9 Nov 2008 18:17:59 +0000 (UTC) (envelope-from allicient3141@googlemail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by mx1.freebsd.org (Postfix) with ESMTP id BC41A8FC12 for ; Sun, 9 Nov 2008 18:17:59 +0000 (UTC) (envelope-from allicient3141@googlemail.com) Received: by wf-out-1314.google.com with SMTP id 24so2056631wfg.7 for ; Sun, 09 Nov 2008 10:17:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=oxMMa1/tnpbBx/plNTj2kLXhRF7Vp129MJN4UBVs/WI=; b=eddKcBmAH+hsRXygTYw5AEXSwV9uaq7Ddgh8c+P+ydbESlG96kPueJ8qT+A4QVvK0M CClmuohJnRRsVIC6HqPTF4Jv3F+SeOeLau1N6hVqyUWZF1N214Rv9vAoR2bgAftnCAL9 HT4fticvcIexGFlpQLy3sd6fc48XKpsFq7o3M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=TT+YH6a4gN+Qfqr0TvK1VEFiy3tlNFDLe5yeC0w524TH2Vat29tVNd2hP1HYZoGFmo nyHJzyRfbZLrXMvRcmMFqvirLPwD6vqkaVSm3mDMohww4D5sRnHOfjwogtV83vHtjuWa v5REjVUhOh0K0pxHVp3uINV0jdqH/WSHZ+eyk= Received: by 10.142.193.13 with SMTP id q13mr1909610wff.49.1226252874433; Sun, 09 Nov 2008 09:47:54 -0800 (PST) Received: by 10.142.43.1 with HTTP; Sun, 9 Nov 2008 09:47:54 -0800 (PST) Message-ID: <7731938b0811090947j4796680cj7344ca3333c05779@mail.gmail.com> Date: Sun, 9 Nov 2008 17:47:54 +0000 From: "Peter Maxwell" Sender: allicient3141@googlemail.com To: freebsd-pf@freebsd.org In-Reply-To: <1814bfe70811090544o28c29c5u185e3c0f2b8e85b4@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com> <20081109112125.GA36707@icarus.home.lan> <1814bfe70811090544o28c29c5u185e3c0f2b8e85b4@mail.gmail.com> X-Google-Sender-Auth: e35d5fd26f17d1f5 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, 09 Nov 2008 18:18:00 -0000 Hi Elvir, I'd second the advice given further up the thread about getting your ISP to filter upstream - that's about the only really effective solution. Once UDP packets hit your firewall's external interface there's very little you can do about it. The only other advice I could offer is; i) Make sure the block rule for UDP gets hit first or very early in the rulebase (this can actually make a lot of difference for large rule sets) - and that the packet is dropped immediately without having to traverse the rest of the rule set (i.e. use "block quick" and "set block-policy drop"). ii) Ensure you're using a good NIC, the CPU offload abilities in Intel (and I think Broadcom) cards can reduce the impact on CPU generally. iii) Repeating the advice given from others in the thread above, only use logging very carefully. iv) Check the limits on the state table are high enough (and that you have enough memory to accomodate this) - its not entirely uncommon for a DDoS attack to completely fill the state table and block legitimate traffic (might be worthwhile checking that this isn't happening). v) There may be some mileage in tinkering with the udp timeout values, but it could also be counter productive if the state processing is faster than the initial rule processing - so you'd have to test this for yourself. If the bad traffic is coming from a massive range of source addresses (spoofed or not), then you're better clearing them from state quickly - if there is only a selection of source IPs then keep them in state longer. vi) Is your connection got enough bandwidth to handle legitimate traffic alongside the DoS traffic - if it doesn't you're stuck anyway. viii) Can you upgrade the CPU on the box? The ALTQ facilities will not help you with this. ALTQ only queues *outgoing packets* so cannot help with incoming UDP. The reason you may sometimes see advice that ALTQ can manage incoming packets is to do with TCP return ACK packets, you can ensure the return ACK packets don't have to compete with outgoing traffic by restricting outgoing bandwidth just a little - and hence speeding up your TCP connections. But again, no use here. To be honest I'm slightly surprised that CPU resource is the first limit you've hit, its usually going to be bandwidth. Packets filters are generally very very fast at doing simple drops - is the actual transfer of data or VPN stuff that usually kills a firewall. How wide is your connection? Cheers, Peter ---------------------------------- http://www.allicient.co.uk/ 2008/11/9 Elvir Kuric : > Hello Jeremy, > > Thank you for your time and your answer, > > >> 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. :-) > > I absolutely agree with you regarding logging, and I do not practice > this, only logging specific data. The biggest problem with this DoS > attacks ( udp floods ) is, processor > must spend some time on packet arrive ( even dropping will take some > processor power ). > >> >> 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). > > Actually it is OpenBSD, but it is not important for this case. > > >> 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. > > Block works fantastic, connection goes down due to milions of packets arrived. > >> >> 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. > > No IRC is present here, or similar staff it is just firewal/router > runing at the edge of internal network. > Also on machines in internal network there is not some, "interesting " stuff. > > Thank you very much for your answer it is very helpful. > > > > >> >> 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. >> >> -- >> | 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 | >> >> > > Kind regards, > > Elvir Kuric > _______________________________________________ > 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" > From owner-freebsd-pf@FreeBSD.ORG Sun Nov 9 20:35:46 2008 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 EB23C106567E for ; Sun, 9 Nov 2008 20:35:45 +0000 (UTC) (envelope-from ddesimone@verio.net) Received: from relay2-bcrtfl2.verio.net (relay2-bcrtfl2.verio.net [131.103.218.177]) by mx1.freebsd.org (Postfix) with ESMTP id AAD828FC14 for ; Sun, 9 Nov 2008 20:35:45 +0000 (UTC) (envelope-from ddesimone@verio.net) Received: from iad-wprd-xchw01.corp.verio.net (iad-wprd-xchw01.corp.verio.net [198.87.7.164]) by relay2-bcrtfl2.verio.net (Postfix) with ESMTP id 471281FF00B0; Sun, 9 Nov 2008 15:07:01 -0500 (EST) thread-index: AclCproic1H3H2xkRc+E6oTYAgMQeQ== Received: from limbo.int.dllstx01.us.it.verio.net ([10.10.10.11]) by iad-wprd-xchw01.corp.verio.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 9 Nov 2008 15:07:00 -0500 Received: by limbo.int.dllstx01.us.it.verio.net (Postfix, from userid 1000) id 5EAD98E29E; Sun, 9 Nov 2008 14:07:00 -0600 (CST) Date: Sun, 9 Nov 2008 14:07:00 -0600 From: "David DeSimone" Content-Transfer-Encoding: 7bit To: "Elvir Kuric" Content-Class: urn:content-classes:message Importance: normal Message-ID: <20081109200659.GA8477@verio.net> Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.3168 Mail-Followup-To: Elvir Kuric , freebsd-pf@freebsd.org References: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com> <20081109112125.GA36707@icarus.home.lan> <1814bfe70811090544o28c29c5u185e3c0f2b8e85b4@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <1814bfe70811090544o28c29c5u185e3c0f2b8e85b4@mail.gmail.com> Precedence: bulk User-Agent: Mutt/1.5.9i X-OriginalArrivalTime: 09 Nov 2008 20:07:01.0096 (UTC) FILETIME=[BA18C680:01C942A6] Cc: freebsd-pf@freebsd.org Subject: Re: Blocking udp flood trafiic using pf, hints welcome X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Nov 2008 20:35:46 -0000 Elvir Kuric wrote: > > I absolutely agree with you regarding logging, and I do not practice > this, only logging specific data. The biggest problem with this DoS > attacks ( udp floods ) is, processor must spend some time on packet > arrive ( even dropping will take some processor power ). You may want to consider adding "keep state" to your "block log" rules. If you keep state on the blocked packets, only the first packet that is blocked will get logged; the others will be blocked statefully without consulting the rulebase, which may save some processing time. Note that "keep state" is only implicit on "pass" rules, you must add it on "block" rules. > No IRC is present here, or similar staff it is just firewal/router > runing at the edge of internal network. > > Also on machines in internal network there is not some, "interesting " > stuff. I suppose what you mean is "No IRC is present here" that you know of. A nefarious hacker can actually install these tools in ways that you are not aware of, and this is often the cause of any DOS attacks you receive. I agree with the above, DOS attacks do not typically happen without reason. There is probably a reason that your system is coming under attack, and you need to do some real forensic examination to make sure that your systems (all of them, the ones that forward traffic through this BSD gateway of yours) are clean and not doing anything they shouldn't be. It's easy to say that you did not set up anything bad on your systems, but can you really say with certainty that no one has broken into your systems and installed something you don't know about? -- David DeSimone == Network Admin == fox@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. From owner-freebsd-pf@FreeBSD.ORG Sun Nov 9 21:07:10 2008 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 D316D1065688 for ; Sun, 9 Nov 2008 21:07:10 +0000 (UTC) (envelope-from ddesimone@verio.net) Received: from relay1-bcrtfl2.verio.net (relay1-bcrtfl2.verio.net [131.103.218.142]) by mx1.freebsd.org (Postfix) with ESMTP id A52D48FC1C for ; Sun, 9 Nov 2008 21:07:10 +0000 (UTC) (envelope-from ddesimone@verio.net) Received: from iad-wprd-xchw01.corp.verio.net (iad-wprd-xchw01.corp.verio.net [198.87.7.164]) by relay1-bcrtfl2.verio.net (Postfix) with ESMTP id DD700B0380CF; Sun, 9 Nov 2008 16:07:09 -0500 (EST) thread-index: AclCryEITltmD7q7TYCgrbnlonTFJw== Received: from limbo.int.dllstx01.us.it.verio.net ([10.10.10.11]) by iad-wprd-xchw01.corp.verio.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 9 Nov 2008 16:07:09 -0500 Received: by limbo.int.dllstx01.us.it.verio.net (Postfix, from userid 1000) id 11D058E29E; Sun, 9 Nov 2008 15:07:09 -0600 (CST) Date: Sun, 9 Nov 2008 15:07:09 -0600 From: "David DeSimone" Content-Transfer-Encoding: 7bit To: "Eric Williams" Content-Class: urn:content-classes:message Importance: normal Message-ID: <20081109210708.GB8477@verio.net> Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.3168 Mail-Followup-To: Eric Williams , freebsd-pf@freebsd.org References: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com> <20081109112125.GA36707@icarus.home.lan> <1814bfe70811090544o28c29c5u185e3c0f2b8e85b4@mail.gmail.com> <20081109200659.GA8477@verio.net> <49174EEA.2040609@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <49174EEA.2040609@gmail.com> Precedence: bulk User-Agent: Mutt/1.5.9i X-OriginalArrivalTime: 09 Nov 2008 21:07:09.0689 (UTC) FILETIME=[20FC5E90:01C942AF] Cc: freebsd-pf@freebsd.org Subject: Re: Blocking udp flood trafiic using pf, hints welcome X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Nov 2008 21:07:10 -0000 Eric Williams wrote: > > David DeSimone wrote: > > You may want to consider adding "keep state" to your "block log" rules. > > Doesn't seem to work, it just gives "keep state on block rules doesn't > make sense" as an error. I guess what I mean is that "blog log" rules can keep state. So that they don't log every packet, just the first packet that creates the state. -- David DeSimone == Network Admin == fox@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. From owner-freebsd-pf@FreeBSD.ORG Sun Nov 9 21:30:01 2008 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 D1A7E1065674 for ; Sun, 9 Nov 2008 21:30:01 +0000 (UTC) (envelope-from purpleshadow100@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by mx1.freebsd.org (Postfix) with ESMTP id 5E4EB8FC17 for ; Sun, 9 Nov 2008 21:30:01 +0000 (UTC) (envelope-from purpleshadow100@gmail.com) Received: by ey-out-2122.google.com with SMTP id 6so779400eyi.7 for ; Sun, 09 Nov 2008 13:30:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=J3cVAyh5t/TQMqQrXJOhGc1QOJHnIf9Wh6vgfxn7cj4=; b=E11oPfbwCy10HTLAO7t1si8rSidpfGgtKYEhL8qZpc8djx8iWQw/mVVEC+jszXKgV9 +wIM3Bb8ZCKmcsWqkLLUKt8eO+zMUphUaUcOozFApYA7dXsckiWJETTF1gV9zq6kHkmi coJ8/E8WtIiPCVkr4ts05o1+34TU9iDCApCf0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=cNyZqYk++iN+4SHC/3Ni69MGXKAZxYl/fURp85articeIalxWKG+wAEcpsUru+Glqb UagSwcqOyJgQUOblj0jiAocb4PDNq3jJb7kXvWVvTLYs22K5HDp9dB6FjxXkZOo4DPFQ yhZcpa1GzvkIXSYFSY0gvR0LQqwL70Z69d7+M= Received: by 10.210.12.18 with SMTP id 18mr6889995ebl.135.1226264308936; Sun, 09 Nov 2008 12:58:28 -0800 (PST) Received: from ?10.10.10.67? (cpe-70-112-151-108.austin.res.rr.com [70.112.151.108]) by mx.google.com with ESMTPS id 20sm9006211eyk.4.2008.11.09.12.58.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 09 Nov 2008 12:58:28 -0800 (PST) Message-ID: <49174EEA.2040609@gmail.com> Date: Sun, 09 Nov 2008 14:58:18 -0600 From: Eric Williams User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: David DeSimone References: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com> <20081109112125.GA36707@icarus.home.lan> <1814bfe70811090544o28c29c5u185e3c0f2b8e85b4@mail.gmail.com> <20081109200659.GA8477@verio.net> In-Reply-To: <20081109200659.GA8477@verio.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-pf@freebsd.org 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, 09 Nov 2008 21:30:01 -0000 David DeSimone wrote: > You may want to consider adding "keep state" to your "block log" rules. > If you keep state on the blocked packets, only the first packet that is > blocked will get logged; the others will be blocked statefully without > consulting the rulebase, which may save some processing time. > > Note that "keep state" is only implicit on "pass" rules, you must add it > on "block" rules Doesn't seem to work, it just gives "keep state on block rules doesn't make sense" as an error. From owner-freebsd-pf@FreeBSD.ORG Mon Nov 10 08:38:41 2008 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 7B5EA106567C for ; Mon, 10 Nov 2008 08:38:41 +0000 (UTC) (envelope-from sebastian.tymkow@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by mx1.freebsd.org (Postfix) with ESMTP id 040948FC21 for ; Mon, 10 Nov 2008 08:38:40 +0000 (UTC) (envelope-from sebastian.tymkow@gmail.com) Received: by ey-out-2122.google.com with SMTP id 6so847348eyi.7 for ; Mon, 10 Nov 2008 00:38:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=4WtucFVc3zlQvwK5jwi+h1T7urRslq+8Vq//ogNQiqo=; b=JO4dfBXRl8Sn8DaOYPCVUx+l9xD4l1WfF6KPEnxvsHFVVvmAbKNL7w5R9Af7Gm8OKl jrpS0NNxAg89SxOwNaNJyCPSv4n4W1mBpGvXOMH7kdyQJOnw02L2N9ogYfMCXy8aULRJ fkmBpnXXILPgvTFVsbSm/URDSAgRbIMsmDc9Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=RDUPEwRsHME88HUS+T9Z5DY2Om8h/0034yfZo73Y1Newb88bNRSXKOphD4CXbSZuzk hZAh3HfeTNUCFPkwNlDrRu+gVpKyKZWRuT86SETtS5swrpqfyGe+8QrpXHAzMCnqGyWX Ik/V/nbRn6so4z/6vpMoUYjcOH0VjnQYleNUA= Received: by 10.210.54.19 with SMTP id c19mr7379483eba.24.1226304908119; Mon, 10 Nov 2008 00:15:08 -0800 (PST) Received: by 10.210.57.20 with HTTP; Mon, 10 Nov 2008 00:15:08 -0800 (PST) Message-ID: <692660060811100015p140b4d7bma034b32a25504ce4@mail.gmail.com> Date: Mon, 10 Nov 2008 09:15:08 +0100 From: "=?ISO-8859-1?Q?Sebastian_Tymk=F3w?=" To: "Elvir Kuric" In-Reply-To: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com> MIME-Version: 1.0 References: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-pf@freebsd.org 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: Mon, 10 Nov 2008 08:38:41 -0000 I wonder how does udp.blackhole working with DNS. Does it interfere bind or no ? Best regards, Sebastian Tymkow From owner-freebsd-pf@FreeBSD.ORG Mon Nov 10 08:49:40 2008 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 531321065670 for ; Mon, 10 Nov 2008 08:49:40 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id 330CB8FC08 for ; Mon, 10 Nov 2008 08:49:39 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id dLm01a0040mlR8UA1LpfjV; Mon, 10 Nov 2008 08:49:39 +0000 Received: from koitsu.dyndns.org ([69.181.141.110]) by OMTA11.emeryville.ca.mail.comcast.net with comcast id dLpf1a0012P6wsM8XLpf7c; Mon, 10 Nov 2008 08:49:39 +0000 X-Authority-Analysis: v=1.0 c=1 a=6t4FfcucIIQA:10 a=tb0012eOZ7UA:10 a=QycZ5dHgAAAA:8 a=yK766ql9vLGRvU4S6rkA:9 a=wSz36gXlUwYjR50f28j43ccAJ3IA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id DD9FE5C19; Mon, 10 Nov 2008 00:49:38 -0800 (PST) Date: Mon, 10 Nov 2008 00:49:38 -0800 From: Jeremy Chadwick To: Sebastian =?iso-8859-1?Q?Tymk=F3w?= Message-ID: <20081110084938.GA62562@icarus.home.lan> References: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com> <692660060811100015p140b4d7bma034b32a25504ce4@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <692660060811100015p140b4d7bma034b32a25504ce4@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-pf@freebsd.org 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: Mon, 10 Nov 2008 08:49:40 -0000 On Mon, Nov 10, 2008 at 09:15:08AM +0100, Sebastian Tymków wrote: > I wonder how does udp.blackhole working with DNS. Does it interfere bind or > no ? No. -- | 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 Mon Nov 10 09:20:13 2008 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 12E3C106564A for ; Mon, 10 Nov 2008 09:20:13 +0000 (UTC) (envelope-from omasnjak@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 D1AF48FC1F for ; Mon, 10 Nov 2008 09:20:12 +0000 (UTC) (envelope-from omasnjak@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so2247587rvf.43 for ; Mon, 10 Nov 2008 01:20:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=+kvFn92WPkBSAN7ldwAakYSYYs2HBJuVsveNmZejvFk=; b=id09ZvkF38zU7lxt60I9FdbwGv99v+lqDsl6thJ7i5FlYG7Sb7jANXfdfgn9RcI67/ oKQTYzHlKxNSicBUUblyW62tXHYocEsasum/8CN9vCbIrsKJ8C3eri0j/64ZHlwuDgH7 ov++XuSjmiOkqXMTLoxe6sRZsSOWsiLN1LqV8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=JKfd+g4fVfeFgdb+C5jEsCBm7y+4ZqmcaRqpcR+tTRKDAN18rfi3FakYSXBtRxKACm g5N+JrEt424M1yajjwo5Ew+t3B+s3xbLm1+dwsBEY5U5NGAshHxmbVGm2Q7IBd2VYjvE sI6YZUU/9m0l8aQg2pT5rSymhJ3EOW+O2687o= Received: by 10.143.5.21 with SMTP id h21mr2288314wfi.183.1226308812207; Mon, 10 Nov 2008 01:20:12 -0800 (PST) Received: by 10.143.93.6 with HTTP; Mon, 10 Nov 2008 01:20:12 -0800 (PST) Message-ID: <1814bfe70811100120if6b7102p54905f1f7dde98ae@mail.gmail.com> Date: Mon, 10 Nov 2008 10:20:12 +0100 From: "Elvir Kuric" To: "Peter Maxwell" In-Reply-To: <7731938b0811090947j4796680cj7344ca3333c05779@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com> <20081109112125.GA36707@icarus.home.lan> <1814bfe70811090544o28c29c5u185e3c0f2b8e85b4@mail.gmail.com> <7731938b0811090947j4796680cj7344ca3333c05779@mail.gmail.com> Cc: freebsd-pf@freebsd.org 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: Mon, 10 Nov 2008 09:20:13 -0000 Hi Peter, Thank you for this excessive answer and it is really helpful. On Sun, Nov 9, 2008 at 6:47 PM, Peter Maxwell wrote: > Hi Elvir, > > I'd second the advice given further up the thread about getting your > ISP to filter upstream - that's about the only really effective > solution. Once UDP packets hit your firewall's external interface > there's very little you can do about it. > > The only other advice I could offer is; > > i) Make sure the block rule for UDP gets hit first or very early in > the rulebase (this can actually make a lot of difference for large > rule sets) - and that the packet is dropped immediately without having > to traverse the rest of the rule set (i.e. use "block quick" and "set > block-policy drop"). > UDP drob rule is at very begginig, it is clear to stop packets which are not necessary in network as soon as possible just to prevent them to " eat " CPU, memory resources, etc > ii) Ensure you're using a good NIC, the CPU offload abilities in Intel > (and I think Broadcom) cards can reduce the impact on CPU generally. This could be weak point in chain. I will try to change some hardware, maybe the whole machine, it is not some representative hardware. But for purpose of filtering ( with udp hosts ) it works super. > > iii) Repeating the advice given from others in the thread above, only > use logging very carefully. > > iv) Check the limits on the state table are high enough (and that you > have enough memory to accomodate this) - its not entirely uncommon for > a DDoS attack to completely fill the state table and block legitimate > traffic (might be worthwhile checking that this isn't happening). > > v) There may be some mileage in tinkering with the udp timeout values, > but it could also be counter productive if the state processing is > faster than the initial rule processing - so you'd have to test this > for yourself. If the bad traffic is coming from a massive range of > source addresses (spoofed or not), then you're better clearing them > from state quickly - if there is only a selection of source IPs then > keep them in state longer. > > vi) Is your connection got enough bandwidth to handle legitimate > traffic alongside the DoS traffic - if it doesn't you're stuck anyway. > > viii) Can you upgrade the CPU on the box? > As I said, I will upgrade box, change it, with some better, this one is not very good. > > The ALTQ facilities will not help you with this. ALTQ only queues > *outgoing packets* so cannot help with incoming UDP. The reason you > may sometimes see advice that ALTQ can manage incoming packets is to > do with TCP return ACK packets, you can ensure the return ACK packets > don't have to compete with outgoing traffic by restricting outgoing > bandwidth just a little - and hence speeding up your TCP connections. > But again, no use here. Regarding this all is clear, UDP is connectionless so tracking it will not be useful, :) and as you write is could help just to manipulate with ack answers in tcp connections > > To be honest I'm slightly surprised that CPU resource is the first > limit you've hit, its usually going to be bandwidth. Packets filters > are generally very very fast at doing simple drops - is the actual > transfer of data or VPN stuff that usually kills a firewall. How wide > is your connection? > 1Mb/2Mb > Cheers, > > Peter > > ---------------------------------- > http://www.allicient.co.uk/ > Nice regards, Elvir Kuric > > > > > > > > > 2008/11/9 Elvir Kuric : >> Hello Jeremy, >> >> Thank you for your time and your answer, >> >> >>> 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. :-) >> >> I absolutely agree with you regarding logging, and I do not practice >> this, only logging specific data. The biggest problem with this DoS >> attacks ( udp floods ) is, processor >> must spend some time on packet arrive ( even dropping will take some >> processor power ). >> >>> >>> 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). >> >> Actually it is OpenBSD, but it is not important for this case. >> > >>> 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. >> >> Block works fantastic, connection goes down due to milions of packets arrived. >> >>> >>> 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. >> >> No IRC is present here, or similar staff it is just firewal/router >> runing at the edge of internal network. >> Also on machines in internal network there is not some, "interesting " stuff. >> >> Thank you very much for your answer it is very helpful. >> >> >> >> >>> >>> 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. >>> >>> -- >>> | 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 | >>> >>> >> >> Kind regards, >> >> Elvir Kuric >> _______________________________________________ >> 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" >> > _______________________________________________ > 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" > From owner-freebsd-pf@FreeBSD.ORG Mon Nov 10 09:31:43 2008 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 BE0431065674 for ; Mon, 10 Nov 2008 09:31:43 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by mx1.freebsd.org (Postfix) with ESMTP id 624848FC39 for ; Mon, 10 Nov 2008 09:31:43 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA02.westchester.pa.mail.comcast.net with comcast id dMXT1a00616LCl052MXVDk; Mon, 10 Nov 2008 09:31:29 +0000 Received: from koitsu.dyndns.org ([69.181.141.110]) by OMTA06.westchester.pa.mail.comcast.net with comcast id dMXh1a00N2P6wsM3SMXiPg; Mon, 10 Nov 2008 09:31:42 +0000 X-Authority-Analysis: v=1.0 c=1 a=6t4FfcucIIQA:10 a=tb0012eOZ7UA:10 a=QycZ5dHgAAAA:8 a=WTcsL0a13su-rhFRyOAA:9 a=WqHm2HDSeeP4pnaJgR3OPahuecUA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 7FB135C19; Mon, 10 Nov 2008 01:31:41 -0800 (PST) Date: Mon, 10 Nov 2008 01:31:41 -0800 From: Jeremy Chadwick To: Peter Maxwell Message-ID: <20081110093141.GA63259@icarus.home.lan> References: <1814bfe70811090137v39cd6434l49b545eb3b6eb88c@mail.gmail.com> <20081109112125.GA36707@icarus.home.lan> <1814bfe70811090544o28c29c5u185e3c0f2b8e85b4@mail.gmail.com> <7731938b0811090947j4796680cj7344ca3333c05779@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7731938b0811090947j4796680cj7344ca3333c05779@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-pf@freebsd.org 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: Mon, 10 Nov 2008 09:31:43 -0000 On Sun, Nov 09, 2008 at 05:47:54PM +0000, Peter Maxwell wrote: > ii) Ensure you're using a good NIC, the CPU offload abilities in Intel > (and I think Broadcom) cards can reduce the impact on CPU generally. I think (hope) what you're referring to are TSO, LRO, and TX/RX checksum offloading. Assuming you are, you should be aware of the following: * These features do not greatly reduce CPU usage; the impact is minimal. * Both TSO and TX/RX checksums are known to be buggy on many NICs, including some developed within the past year. I can refer you to many threads on -hardware, -current, and -stable discussing this fact, specifically from the driver authors themselves. Sometimes it's just rxcsum which is buggy, or just txcsum. I do not believe Broadcom or Intel NICs are affected by such issues, but regardless it's important users understand these features *can* lead to packet corruption on some NICs. * TX/RX checksum offloading often confuse users who use tcpdump or Wireshark -- "why are all of my packets showing checksum errors??!" being a common question even today. It often leads users on a wild goose chase, thinking those messages indicate the source of their problems If you weren't referring to these features, what were you referring to? I'm curious to know. -- | 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 Mon Nov 10 11:06:55 2008 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 74BA8106568A for ; Mon, 10 Nov 2008 11:06:55 +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 5BB998FC2E for ; Mon, 10 Nov 2008 11:06:55 +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 mAAB6tIS049806 for ; Mon, 10 Nov 2008 11:06:55 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mAAB6sUW049802 for freebsd-pf@FreeBSD.org; Mon, 10 Nov 2008 11:06:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 10 Nov 2008 11:06:54 GMT Message-Id: <200811101106.mAAB6sUW049802@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, 10 Nov 2008 11:06:55 -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 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/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 24 problems total. From owner-freebsd-pf@FreeBSD.ORG Wed Nov 12 23:21:31 2008 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 2D268106564A for ; Wed, 12 Nov 2008 23:21:31 +0000 (UTC) (envelope-from freebsd@optiksecurite.com) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by mx1.freebsd.org (Postfix) with ESMTP id 029AF8FC17 for ; Wed, 12 Nov 2008 23:21:30 +0000 (UTC) (envelope-from freebsd@optiksecurite.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed Received: from [69.69.69.183] ([69.70.93.206]) by VL-MO-MR005.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-4.01 (built Aug 3 2007; 32bit)) with ESMTP id <0KA8000NZREN5Z41@VL-MO-MR005.ip.videotron.ca> for freebsd-pf@freebsd.org; Wed, 12 Nov 2008 17:20:47 -0500 (EST) Message-id: <491B5715.8040601@optiksecurite.com> Date: Wed, 12 Nov 2008 17:22:13 -0500 From: FreeBSD User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) To: freebsd-pf@freebsd.org Subject: RDR not triggered 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, 12 Nov 2008 23:21:31 -0000 Hi everyone, I'm a little confused as to why my RDR is not working. Quick explanation of my setup: We have 2 webservers, a frontend and a backend. The frontend have a jail for Lighttpd (images server) and Apache on the base system (for PHP). There is one public IP associated to the jail on the public side of the frontend server. There is only one internal private IP. The jail is bound to 127.0.0.25 and a RDR on the external interface is redirecting the traffic in the jail when the request arrive with it's public IP as destination. rdr on $EXT_IF proto tcp from any to $IMG_SERVER port http -> $LIGHTTPD port http That's working great for external connections. The problem is that the backend server needs to access the Lighttpd jail by the public IP of the frontend server. I understand that I can't redirect the traffic inside the jail with a RDR on the external interface because the packets didn't passthrough the interface. That's why I created I copy of the above RDR but on the internal interface. rdr on $INT_IF proto tcp from any to $IMG_SERVER port http -> $LIGHTTPD port http That rule is never triggered even when the traffic, according to tcpdump, is corresponding to the criteria. At the moment, the RDR for the internal interface is just before the external one. The pfctl -gvvvsn output for these 2 rules: @0 rdr on bge1 inet proto tcp from any to 66.AAA.BB.66 port = http -> 127.0.0.25 port 80 [ Skip steps: d=end f=9 p=9 sa=end sp=12 da=2 dp=2 ] [ queue: qname= qid=0 pqname= pqid=0 ] [ Evaluations: 91246 Packets: 0 Bytes: 0 States: 0 ] @1 rdr on bge0 inet proto tcp from any to 66.AAA.BB.66 port = http -> 127.0.0.25 port 80 [ Skip steps: i=9 d=end f=9 p=9 sa=end sp=12 ] [ queue: qname= qid=0 pqname= pqid=0 ] [ Evaluations: 91246 Packets: 3261224 Bytes: 2403004153 States: 2531 ] The tcpdump -nevvvi output from the internal interface of the frontend (where the RDR is not triggered) 17:16:24.683316 00:18:8b:f9:3f:94 > 00:19:b9:f7:a8:13, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 53680, offset 0, flags [DF], proto: TCP (6), length: 60) 10.0.0.11.61428 > 66.AAA.BB.66.80: S, cksum 0x8827 (correct), 766260635:766260635(0) win 65535 17:16:24.683342 00:19:b9:f7:a8:13 > 00:18:8b:f9:3f:94, ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 64, id 59837, offset 0, flags [DF], proto: TCP (6), length: 64, bad cksum 0 (->b615)!) 66.AAA.BB.66.80 > 10.0.0.11.61428: S, cksum 0xf1e7 (correct), 2408882600:2408882600(0) ack 766260636 win 65535 17:16:24.683520 00:18:8b:f9:3f:94 > 00:19:b9:f7:a8:13, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 53681, offset 0, flags [DF], proto: TCP (6), length: 52) 10.0.0.11.61428 > 66.AAA.BB.66.80: ., cksum 0x112c (correct), 1:1(0) ack 1 win 8326 17:16:24.683672 00:18:8b:f9:3f:94 > 00:19:b9:f7:a8:13, ethertype IPv4 (0x0800), length 265: (tos 0x0, ttl 64, id 53682, offset 0, flags [DF], proto: TCP (6), length: 251) 10.0.0.11.61428 > 66.AAA.BB.66.80: P 1:200(199) ack 1 win 8326 17:16:24.684461 00:19:b9:f7:a8:13 > 00:18:8b:f9:3f:94, ethertype IPv4 (0x0800), length 545: (tos 0x0, ttl 64, id 59838, offset 0, flags [DF], proto: TCP (6), length: 531, bad cksum 0 (->b441)!) 66.AAA.BB.66.80 > 10.0.0.11.61428: P 1:480(479) ack 200 win 33304 17:16:24.684803 00:18:8b:f9:3f:94 > 00:19:b9:f7:a8:13, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 53683, offset 0, flags [DF], proto: TCP (6), length: 52) 10.0.0.11.61428 > 66.AAA.BB.66.80: F, cksum 0x0e83 (correct), 200:200(0) ack 480 win 8326 17:16:24.684823 00:19:b9:f7:a8:13 > 00:18:8b:f9:3f:94, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 59839, offset 0, flags [DF], proto: TCP (6), length: 52, bad cksum 0 (->b61f)!) 66.AAA.BB.66.80 > 10.0.0.11.61428: ., cksum 0xacef (correct), 480:480(0) ack 201 win 33304 17:16:24.684845 00:19:b9:f7:a8:13 > 00:18:8b:f9:3f:94, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 59840, offset 0, flags [DF], proto: TCP (6), length: 52, bad cksum 0 (->b61e)!) 66.AAA.BB.66.80 > 10.0.0.11.61428: F, cksum 0xacee (correct), 480:480(0) ack 201 win 33304 17:16:24.684956 00:18:8b:f9:3f:94 > 00:19:b9:f7:a8:13, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 53684, offset 0, flags [DF], proto: TCP (6), length: 52) 10.0.0.11.61428 > 66.AAA.BB.66.80: ., cksum 0x0e82 (correct), 201:201(0) ack 481 win 8325 Nothing is blocked on both of the servers. The packets are simply not redirected and passed to the Apache on the base system of the frontend server instead of going in the Lighttpd jail, only when coming the the internal network. I'm using FreeBSD 6.2 on the frontend and 7.0 on the backend. Thanks everyone for helping me shed some light on this Martin From owner-freebsd-pf@FreeBSD.ORG Thu Nov 13 12:10:07 2008 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 2E3A51065678 for ; Thu, 13 Nov 2008 12:10:07 +0000 (UTC) (envelope-from gofdp-freebsd-pf@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id AF5C78FC0C for ; Thu, 13 Nov 2008 12:10:06 +0000 (UTC) (envelope-from gofdp-freebsd-pf@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1L0b1O-0003JS-RZ for freebsd-pf@freebsd.org; Thu, 13 Nov 2008 12:10:03 +0000 Received: from 195.208.174.178 ([195.208.174.178]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 13 Nov 2008 12:10:02 +0000 Received: from vadim_nuclight by 195.208.174.178 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 13 Nov 2008 12:10:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-pf@freebsd.org From: Vadim Goncharov Date: Thu, 13 Nov 2008 11:50:39 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 67 Message-ID: References: <491B5715.8040601@optiksecurite.com> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 195.208.174.178 X-Comment-To: FreeBSD User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Subject: Re: RDR not triggered X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru 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, 13 Nov 2008 12:10:07 -0000 Hi FreeBSD! On Wed, 12 Nov 2008 17:22:13 -0500; FreeBSD wrote about 'RDR not triggered': > Quick explanation of my setup: > We have 2 webservers, a frontend and a backend. The frontend have a jail > for Lighttpd (images server) and Apache on the base system (for PHP). > There is one public IP associated to the jail on the public side of the > frontend server. There is only one internal private IP. The jail is > bound to 127.0.0.25 and a RDR on the external interface is redirecting > the traffic in the jail when the request arrive with it's public IP as > destination. > rdr on $EXT_IF proto tcp from any to $IMG_SERVER port http -> $LIGHTTPD > port http > That's working great for external connections. > The problem is that the backend server needs to access the Lighttpd jail > by the public IP of the frontend server. I understand that I can't > redirect the traffic inside the jail with a RDR on the external > interface because the packets didn't passthrough the interface. That's > why I created I copy of the above RDR but on the internal interface. > rdr on $INT_IF proto tcp from any to $IMG_SERVER port http -> $LIGHTTPD > port http > That rule is never triggered even when the traffic, according to > tcpdump, is corresponding to the criteria. At the moment, the RDR for > the internal interface is just before the external one. > The pfctl -gvvvsn output for these 2 rules: > @0 rdr on bge1 inet proto tcp from any to 66.AAA.BB.66 port = http -> > 127.0.0.25 port 80 > [ Skip steps: d=end f=9 p=9 sa=end sp=12 da=2 dp=2 ] > [ queue: qname= qid=0 pqname= pqid=0 ] > [ Evaluations: 91246 Packets: 0 Bytes: 0 > States: 0 ] > @1 rdr on bge0 inet proto tcp from any to 66.AAA.BB.66 port = http -> > 127.0.0.25 port 80 > [ Skip steps: i=9 d=end f=9 p=9 sa=end sp=12 ] > [ queue: qname= qid=0 pqname= pqid=0 ] > [ Evaluations: 91246 Packets: 3261224 Bytes: 2403004153 > States: 2531 ] [...] > Nothing is blocked on both of the servers. The packets are simply not > redirected and passed to the Apache on the base system of the frontend > server instead of going in the Lighttpd jail, only when coming the the > internal network. > I'm using FreeBSD 6.2 on the frontend and 7.0 on the backend. It is possible that you have "set skip on $INT_IF" - in that case oll that interface rules will not work. Or another reason, need to see complete pf ruleset. Or try "rdr pass ..." I've asked some people, they tried similar (but not exact!) setup on 6.1/7.0, it worked. So it may be a bug in your version of pf, if not ruleset. The last possible reason - architectural flaw of pf, which binds IPs for states to interfaces, in that case you will need to do ipfw fwd (can use both ipfw and pf simultaneously). -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-pf@FreeBSD.ORG Thu Nov 13 15:57:38 2008 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 3F987106567B for ; Thu, 13 Nov 2008 15:57:38 +0000 (UTC) (envelope-from freebsd@optiksecurite.com) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by mx1.freebsd.org (Postfix) with ESMTP id 1BBD58FC0C for ; Thu, 13 Nov 2008 15:57:37 +0000 (UTC) (envelope-from freebsd@optiksecurite.com) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed Received: from [69.69.69.183] ([69.70.93.206]) by VL-MH-MR001.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-4.01 (built Aug 3 2007; 32bit)) with ESMTP id <0KAA006OB4C0CX90@VL-MH-MR001.ip.videotron.ca> for freebsd-pf@freebsd.org; Thu, 13 Nov 2008 10:57:36 -0500 (EST) Message-id: <491C4E9F.90903@optiksecurite.com> Date: Thu, 13 Nov 2008 10:58:23 -0500 From: FreeBSD User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) To: vadim_nuclight@mail.ru References: <491B5715.8040601@optiksecurite.com> In-reply-to: Cc: freebsd-pf@freebsd.org Subject: Re: RDR not triggered 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, 13 Nov 2008 15:57:38 -0000 Vadim Goncharov a écrit : > Hi FreeBSD! > > On Wed, 12 Nov 2008 17:22:13 -0500; FreeBSD wrote about 'RDR not triggered': > >> Quick explanation of my setup: > >> We have 2 webservers, a frontend and a backend. The frontend have a jail >> for Lighttpd (images server) and Apache on the base system (for PHP). >> There is one public IP associated to the jail on the public side of the >> frontend server. There is only one internal private IP. The jail is >> bound to 127.0.0.25 and a RDR on the external interface is redirecting >> the traffic in the jail when the request arrive with it's public IP as >> destination. > >> rdr on $EXT_IF proto tcp from any to $IMG_SERVER port http -> $LIGHTTPD >> port http > >> That's working great for external connections. > >> The problem is that the backend server needs to access the Lighttpd jail >> by the public IP of the frontend server. I understand that I can't >> redirect the traffic inside the jail with a RDR on the external >> interface because the packets didn't passthrough the interface. That's >> why I created I copy of the above RDR but on the internal interface. > >> rdr on $INT_IF proto tcp from any to $IMG_SERVER port http -> $LIGHTTPD >> port http > >> That rule is never triggered even when the traffic, according to >> tcpdump, is corresponding to the criteria. At the moment, the RDR for >> the internal interface is just before the external one. > >> The pfctl -gvvvsn output for these 2 rules: > >> @0 rdr on bge1 inet proto tcp from any to 66.AAA.BB.66 port = http -> >> 127.0.0.25 port 80 >> [ Skip steps: d=end f=9 p=9 sa=end sp=12 da=2 dp=2 ] >> [ queue: qname= qid=0 pqname= pqid=0 ] >> [ Evaluations: 91246 Packets: 0 Bytes: 0 >> States: 0 ] >> @1 rdr on bge0 inet proto tcp from any to 66.AAA.BB.66 port = http -> >> 127.0.0.25 port 80 >> [ Skip steps: i=9 d=end f=9 p=9 sa=end sp=12 ] >> [ queue: qname= qid=0 pqname= pqid=0 ] >> [ Evaluations: 91246 Packets: 3261224 Bytes: 2403004153 >> States: 2531 ] > [...] >> Nothing is blocked on both of the servers. The packets are simply not >> redirected and passed to the Apache on the base system of the frontend >> server instead of going in the Lighttpd jail, only when coming the the >> internal network. >> I'm using FreeBSD 6.2 on the frontend and 7.0 on the backend. > > It is possible that you have "set skip on $INT_IF" - in that case oll that > interface rules will not work. Or another reason, need to see complete pf > ruleset. Or try "rdr pass ..." > D'OH!!! You're right, there was a set skip on $INT_IF... I wasted all mey afternoon trying to debug that. Thanks a lot for your reply. You just made my day :) Martin > I've asked some people, they tried similar (but not exact!) setup on 6.1/7.0, > it worked. So it may be a bug in your version of pf, if not ruleset. > > The last possible reason - architectural flaw of pf, which binds IPs for states > to interfaces, in that case you will need to do ipfw fwd (can use both ipfw and > pf simultaneously). > From owner-freebsd-pf@FreeBSD.ORG Fri Nov 14 08:31:30 2008 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 51E6C1065678 for ; Fri, 14 Nov 2008 08:31:30 +0000 (UTC) (envelope-from salvador_d13@yahoo.com.ph) Received: from n56.bullet.mail.sp1.yahoo.com (n56.bullet.mail.sp1.yahoo.com [98.136.44.52]) by mx1.freebsd.org (Postfix) with SMTP id 2BD258FC1B for ; Fri, 14 Nov 2008 08:31:30 +0000 (UTC) (envelope-from salvador_d13@yahoo.com.ph) Received: from [216.252.122.217] by n56.bullet.mail.sp1.yahoo.com with NNFMP; 14 Nov 2008 08:17:45 -0000 Received: from [124.108.115.242] by t2.bullet.sp1.yahoo.com with NNFMP; 14 Nov 2008 08:17:45 -0000 Received: from [124.108.114.84] by t1.bullet.mail.sg1.yahoo.com with NNFMP; 14 Nov 2008 08:17:42 -0000 Received: from [127.0.0.1] by omp104.mail.sg1.yahoo.com with NNFMP; 14 Nov 2008 08:17:45 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 599615.83607.bm@omp104.mail.sg1.yahoo.com Received: (qmail 64399 invoked by uid 60001); 14 Nov 2008 08:17:45 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.ph; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=VaQ+cj7Zgr5+0EJITBPokT0O/CWxvxz4jZzggUSU0mX6p6Wa4MAxgCEaUlWTB2tYO8az6GvCx0tyGJQsXLPZMC8ksaD9YtXNfjwO0fuuYH2huYr4/T2qOQCVAKhZQsybMD8rRmZOA7trXgx2beZODDvJhK/epaUJm/h1hSFZh8w=; X-YMail-OSG: Kx2HXIAVM1kGWyAuDdIrmoUyI5aOE09Lf8iadxU5EiysbV.ymi4DVKSpXqD8iGmZibvXfGTq5l8sny0qdh6NTLoaaJVXNKJpYDLEk9ElckHFrkp3RWjRhxbLG_mTz4Wu7CPykPI9GTodv2pc6WoP58QUz1k- Received: from [58.71.34.137] by web76108.mail.sg1.yahoo.com via HTTP; Fri, 14 Nov 2008 00:17:45 PST Date: Fri, 14 Nov 2008 00:17:45 -0800 (PST) From: Diego Salvador To: freebsd-pf@freebsd.org MIME-Version: 1.0 Message-ID: <519620.64150.qm@web76108.mail.sg1.yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Need for igb(4) driver support with ALTQ 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, 14 Nov 2008 08:31:30 -0000 Hi, I have read from this mailing list http://lists.freebsd.org/pipermail/freebsd-net/2008-August/019224.html about igb(4) driver support in FreeBSD for newer releases of Intel Gigabit NICs but unfortunately I haven't found any support for altq(4). If someone could provide some patch on this, then I am willing to test. Regards, Diego --------------------------------- New Email names for you! Get the Email name you've always wanted on the new @ymail and @rocketmail. Hurry before someone else does! From owner-freebsd-pf@FreeBSD.ORG Fri Nov 14 12:20:14 2008 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 129281065678 for ; Fri, 14 Nov 2008 12:20:14 +0000 (UTC) (envelope-from max@love2party.net) Received: from mout-bounce.kundenserver.de (mout-bounce.kundenserver.de [212.227.17.1]) by mx1.freebsd.org (Postfix) with ESMTP id 9E9428FC0C for ; Fri, 14 Nov 2008 12:20:13 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-052-032.pools.arcor-ip.net [88.66.52.32]) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis) id 0MKwtQ-1L0xel2mku-0007Ku; Fri, 14 Nov 2008 13:20:12 +0100 Received: (qmail 16892 invoked from network); 14 Nov 2008 12:20:11 -0000 Received: from fbsd8.laiers.local (192.168.4.151) by ns1.laiers.local with SMTP; 14 Nov 2008 12:20:11 -0000 From: Max Laier Organization: FreeBSD To: freebsd-pf@freebsd.org Date: Fri, 14 Nov 2008 13:20:10 +0100 User-Agent: KMail/1.10.1 (FreeBSD/8.0-CURRENT; KDE/4.1.1; i386; ; ) References: <519620.64150.qm@web76108.mail.sg1.yahoo.com> In-Reply-To: <519620.64150.qm@web76108.mail.sg1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811141320.10484.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1/YTikrU4Og4RS8vnpy4mfiFr/23TXMmTrABu3 DMPGzLNBF9YPWoaqeSWmB+IX3v/Ee/dhdbWnpnBdWyrzK8tWnV HcuJRU54e7y5vv9Wk1tIQ== Cc: Subject: Re: Need for igb(4) driver support with ALTQ 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, 14 Nov 2008 12:20:14 -0000 On Friday 14 November 2008 09:17:45 Diego Salvador wrote: > Hi, I have read from this mailing list > http://lists.freebsd.org/pipermail/freebsd-net/2008-August/019224.html > about igb(4) driver support in FreeBSD for newer releases of Intel Gigabit > NICs but unfortunately I haven't found any support for altq(4). If someone > could provide some patch on this, then I am willing to test. according to the code, igb(4) supports ALTQ since it was first committed back in February. What makes you think that it isn't? -- /"\ 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 Sat Nov 15 14:03:50 2008 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 03CED1065679 for ; Sat, 15 Nov 2008 14:03:50 +0000 (UTC) (envelope-from salvador_d13@yahoo.com.ph) Received: from n59.bullet.mail.sp1.yahoo.com (n59.bullet.mail.sp1.yahoo.com [98.136.44.43]) by mx1.freebsd.org (Postfix) with SMTP id D2BE38FC0C for ; Sat, 15 Nov 2008 14:03:49 +0000 (UTC) (envelope-from salvador_d13@yahoo.com.ph) Received: from [216.252.122.218] by n59.bullet.mail.sp1.yahoo.com with NNFMP; 15 Nov 2008 14:03:49 -0000 Received: from [124.108.115.242] by t3.bullet.sp1.yahoo.com with NNFMP; 15 Nov 2008 14:03:49 -0000 Received: from [124.108.114.83] by t1.bullet.mail.sg1.yahoo.com with NNFMP; 15 Nov 2008 14:03:46 -0000 Received: from [127.0.0.1] by omp103.mail.sg1.yahoo.com with NNFMP; 15 Nov 2008 14:03:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 64190.89404.bm@omp103.mail.sg1.yahoo.com Received: (qmail 68749 invoked by uid 60001); 15 Nov 2008 14:03:49 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.ph; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=wToW/O2OmReXa219OT7b1dOD/fl4It2j+dwbR+1/09rkvLze0LHVHd11xBPLdwJO+EPk6ytDjdq+lra0rBONTaxmniFI9/G6XVnvkZE9RjFKXUzfePqKT3pFl2kMgO7E+SY97482+/RNLxzvPHIrBfGCpQXnxsLrZh1rwzZm2dA=; X-YMail-OSG: J8vCPvcVM1kCrnkGUxZQkwu52LPT28gIzwLq1vYjZI2XYng5e0_Z1eoG_zoHsSbeJfNt5ACH9I7IYTi827x2GjIZABTQu4lFYSEPTMQN8DPLp5Mdl2zyoepnB0X8pFQok6tTuftEJbW5sGDUeED2zSWHN5WHHojgqAWmFsfPSmauLUdVgV8v53RZ9ZCJ Received: from [124.106.231.243] by web76105.mail.sg1.yahoo.com via HTTP; Sat, 15 Nov 2008 06:03:48 PST Date: Sat, 15 Nov 2008 06:03:48 -0800 (PST) From: Diego Salvador To: Max Laier , freebsd-pf@freebsd.org In-Reply-To: <200811141320.10484.max@love2party.net> MIME-Version: 1.0 Message-ID: <931259.67719.qm@web76105.mail.sg1.yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Need for igb(4) driver support with ALTQ 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, 15 Nov 2008 14:03:50 -0000 Max Laier wrote: On Friday 14 November 2008 09:17:45 Diego Salvador wrote: > Hi, I have read from this mailing list > http://lists.freebsd.org/pipermail/freebsd-net/2008-August/019224.html > about igb(4) driver support in FreeBSD for newer releases of Intel Gigabit > NICs but unfortunately I haven't found any support for altq(4). If someone > could provide some patch on this, then I am willing to test. according to the code, igb(4) supports ALTQ since it was first committed back in February. What makes you think that it isn't? -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News Hi Max, First of all, thank you for answering my concern because you are right, igb(4) driver already supports ALTQ. Second, please always consider that some users will read manual pages first posted in the web site before or without reading the code because altq(4) man page, doesn't say so. Lastly, I was asking you a polite question so please answer question professionally and ethically. Regards, Diego --------------------------------- Get your preferred Email name! Now you can @ymail.com and @rocketmail.com. From owner-freebsd-pf@FreeBSD.ORG Sat Nov 15 14:19:51 2008 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 A0EF71065672 for ; Sat, 15 Nov 2008 14:19:51 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by mx1.freebsd.org (Postfix) with ESMTP id 843BC8FC18 for ; Sat, 15 Nov 2008 14:19:51 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id fRSS1a0010cQ2SLAASKrHc; Sat, 15 Nov 2008 14:19:51 +0000 Received: from koitsu.dyndns.org ([69.181.141.110]) by OMTA10.emeryville.ca.mail.comcast.net with comcast id fSKq1a0062P6wsM8WSKqDB; Sat, 15 Nov 2008 14:19:51 +0000 X-Authority-Analysis: v=1.0 c=1 a=EWOk6H46Kv4A:10 a=Fv6CWCyuZcYA:10 a=QycZ5dHgAAAA:8 a=u29xqFenPItnXfeLoscA:9 a=A89pTxvnYCIOhy3ApSoCittGy6oA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 46AF033C36; Sat, 15 Nov 2008 06:19:50 -0800 (PST) Date: Sat, 15 Nov 2008 06:19:50 -0800 From: Jeremy Chadwick To: Diego Salvador Message-ID: <20081115141950.GA75796@icarus.home.lan> References: <200811141320.10484.max@love2party.net> <931259.67719.qm@web76105.mail.sg1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <931259.67719.qm@web76105.mail.sg1.yahoo.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-pf@freebsd.org Subject: Re: Need for igb(4) driver support with ALTQ 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, 15 Nov 2008 14:19:51 -0000 On Sat, Nov 15, 2008 at 06:03:48AM -0800, Diego Salvador wrote: > First of all, thank you for answering my concern because you are right, igb(4) > driver already supports ALTQ. Second, please always consider that some > users will read manual pages first posted in the web site before or without > reading the code because altq(4) man page, doesn't say so. Please file a PR for this, specifically to the doc team, so we can get the man pages/documentation updated. > Lastly, I was asking you a polite question so please answer question > professionally and ethically. I thought Max's response was both professional and ethical. His question was an honest one, and you've answered it just as honestly. No harm done. -- | 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 Sat Nov 15 17:33:14 2008 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 227C7106568C for ; Sat, 15 Nov 2008 17:33:14 +0000 (UTC) (envelope-from mouss@netoyen.net) Received: from imlil.netoyen.net (imlil.netoyen.net [91.121.103.130]) by mx1.freebsd.org (Postfix) with ESMTP id DA8808FC13 for ; Sat, 15 Nov 2008 17:33:13 +0000 (UTC) (envelope-from mouss@netoyen.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=netoyen.net; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received: x-virus-scanned; s=msa; t=1226769432; bh=qfXraq5jdl3gus760FMCuXq aGuLPJnvIBdWDP4xaEDk=; b=Sx73WuLJVEj3eV0N6sitXOO08soRhjW3nkkCdrF KvjJ92DeFdm37Gcnd5T9Zj4OwalBMnD9rxjBZmBmjnFX2APZJNYs9yfOjbftRInh j8J3ZF+QTjDJlMQ5J744CVyLn7ZTVK4BPKEkhAt/adJt4w4Em+AIWMR9YbWI2QQh lgvY= X-Virus-Scanned: amavisd-new at netoyen.net Received: from [192.168.1.65] (ouzoud.netoyen.net [82.239.111.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mouss@netoyen.net) by smtp.netoyen.net (Postfix) with ESMTPSA id 2C12BE54896 for ; Sat, 15 Nov 2008 18:17:12 +0100 (CET) Message-ID: <491F03F6.4020307@netoyen.net> Date: Sat, 15 Nov 2008 18:16:38 +0100 From: mouss User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: freebsd-pf@freebsd.org References: <49106B68.2060007@cyanide-studio.com> In-Reply-To: <49106B68.2060007@cyanide-studio.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: can't add a port forwarding 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, 15 Nov 2008 17:33:14 -0000 Bastien Semene wrote: > Hi everyone, > > I'm currently facing a weird problem. I have a pf box acting as a > gateway for some services and want to add a port forwarding for https. > > So I added the following rule : > > rdr pass on $ext_if proto tcp from any to any port 443 -> $atlas_ip > //variables are correct since I have a similar rule for port 80. > > The "pfctl -s nat" shows this : > > nat on bge0 inet from 10.1.8.1 to any -> "external_interface_ip" > rdr pass on bge0 inet proto tcp from any to any port = http -> 10.1.8.1 > rdr pass on bge0 inet proto tcp from any to any port = https -> 10.1.8.1 > > An Nmap from outside shows this : > > # nmap -P0 -p80,443,17900 "external_interface_ip" > > Starting Nmap 4.20 ( http://insecure.org ) at 2008-11-04 16:22 CET > Interesting ports on "external_interface_ip": > PORT STATE SERVICE > 80/tcp open http > 443/tcp closed https > 17900/tcp filtered unknown > maybe you allow port 80 but not 443 in your pf rules? > I tried reloading pf rules with "pfctl -F all -f /etc/pf.conf", > restarting the machine, but nothing changed. The securelevel is also at > -1, so pf should take the changes into account. > And of course the destination https server receives nothing on https port. > http and preconfigured nat/forwards works perfectly. > > I tried to comment the "scrub in all" option, but because the rdr line > doesn't seem to be affected, I'm not sure this one is. > > If someone has an idea or direction to follow I take every piece of > thought. > Thanks all. > _______________________________________________ > 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"