From owner-freebsd-net@FreeBSD.ORG Fri Jan 27 04:43:35 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5B93106564A for ; Fri, 27 Jan 2012 04:43:35 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 606EF8FC0C for ; Fri, 27 Jan 2012 04:43:34 +0000 (UTC) Received: by eaaa14 with SMTP id a14so481820eaa.13 for ; Thu, 26 Jan 2012 20:43:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=17OGqnR9HyHOzLkZB52+lq4BOlwv6r9w+7RlcQjuEG0=; b=kFWmKqvVBAQBh+L8x5FQxn3Bb7OwsxMbeSW5nWqf90F7URTChEZ/A7IRzBZOz+Ibm1 mC+JH89xSisDklQqx10ATI0VKZMOk30+Y9RaOblaHX+Q4OmbbgVtNUtqQCwg/iH4f5YP 3T5DYQLGkG4KbI2YoM8aABRFqrpXtx4zfrQLQ= Received: by 10.213.114.129 with SMTP id e1mr174770ebq.124.1327639413086; Thu, 26 Jan 2012 20:43:33 -0800 (PST) Received: from imba-brutale.totalterror.net (93-152-152-135.ddns.onlinedirect.bg. [93.152.152.135]) by mx.google.com with ESMTPS id s16sm24312761eef.2.2012.01.26.20.43.30 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 Jan 2012 20:43:31 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Nikolay Denev In-Reply-To: Date: Fri, 27 Jan 2012 06:43:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1A4CBF45-8ABB-4BFB-A83A-2906CBD32667@gmail.com> References: To: Kevin Oberman X-Mailer: Apple Mail (2.1251.1) Cc: satish amara , freebsd-net@freebsd.org Subject: Re: stateful firewall implementation in FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 04:43:35 -0000 On Jan 27, 2012, at 4:41 AM, Kevin Oberman wrote: > On Thu, Jan 26, 2012 at 11:41 AM, Chuck Swiger = wrote: >> Hi-- >>=20 >> On Jan 26, 2012, at 9:24 AM, satish amara wrote: >>> I have question regarding the size of the state table kept in = FreeBSD for >>> stateful packet inspection. Say we have a valid senario where we = have >>> stateful firewall rule for HTTP and we get lot of incoming new HTTP = session >>> and state table is filled full. In that case I guess FreeBSD would = reject >>> new sessions. Just want to know what is the latest on this. How = does >>> FreeBSD would handle if the state table is full and we get valid new = HTTP >>> connection. What are options in terms of configuration or new = feature in >>> BSD would address this issue. >>=20 >> A securely designed firewall will drop connections when the state = table is full. >>=20 >> You can increase the size of the state table by following the IPF = FAQ: >>=20 >> http://www.phildev.net/ipf/IPFques.html#ques25 >>=20 >> ...but in point of fact, keeping state for high-volume traffic is = generally >> a losing game, and you are better off (IMHO) setting up stateless = bidirectional >> rules which permit such high volume traffic. >>=20 >> HTTP isn't generally too much of a problem, though-- something like a = popular >> stratum-1 or 2 public NTP timeserver will easily blow out a stateful = firewall >> if you try to keep state for NTP's UDP traffic. >=20 > To put it very clearly, a stateful firewall "protecting" a server is > an open invitation to DOS. It is trivial to generate enough UDP > traffic to overflow any limit on connections in a stateful firewall. > Various tricks have been tried but the reality is that none has really > succeeded. Some do help, but nowhere near enough to solve the problem. >=20 > Stateful firewalls are for clients and systems that don't provide > publicly accessible services. Servers require stateless filters along > with IDS/IPS for effective protection. >=20 > And I do expect to get people saying that you HAVE to have a stateful > firewall is a basic requirement for a device on the Internet. I can > only say htat I know of many well known servers that do not have them > and few that do. There is a reason for that. At my old employer we > were under government security oversight and I can remember the > auditors back a few years ago who had a fit when told that no firewall > was employed, just an IDS/IPS with RTBH. The problem is that their red > team of attackers never could successfully attack which really annoyed > them to the point that they tryed toi order that the IDS be disabled > for their attack attempts. (We refused, siting terms of the testing > agreement.) >=20 > Today, auditors still are a bit surprised that they don't use a > firewall, but are no longer upset by it as they are seeing it more > often. > --=20 > R. Kevin Oberman, Network Engineer > E-mail: kob6558@gmail.com >=20 In my experience (and I've had a few DDoS attacks), the state table was = never an issue (unless left at default settings), the machine would either die from interrupt/cpu overload, or the pipe = will be filled. For example the pf(4) firewall can be tuned to have millions of state = entries, then you can configure thresholds which reached will make the existing = state entries expire sooner, leaving room for new ones. P.S.: Stateful firewalls are required by the PCI DSS (requirement 1.3.6)