From owner-freebsd-net@FreeBSD.ORG Fri Jan 27 02:41:56 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 C66C3106564A for ; Fri, 27 Jan 2012 02:41:56 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4AFB58FC12 for ; Fri, 27 Jan 2012 02:41:55 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so1408833wib.13 for ; Thu, 26 Jan 2012 18:41:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=/0/mjQ/B+YuI2yg9j3aftQDSyUnnPxrB8OvEA6WbNR0=; b=wAXdEwnGixjcF8l7F0DUqxzB2dvV5iH0eTupCxOZQp6dSK3BVps6kk3HvtLguGh+am Z8FKOUAcM+tWIAWhDyhfIVfxB9xK/HKvdrQzrPb14cPH+19M6LQ4gxhcCdDhGB5iZHXP wnweawDIAjko7YtE0fu1aGmfI/KHGFnaqEK3E= MIME-Version: 1.0 Received: by 10.181.11.231 with SMTP id el7mr4382046wid.0.1327632114726; Thu, 26 Jan 2012 18:41:54 -0800 (PST) Received: by 10.223.101.196 with HTTP; Thu, 26 Jan 2012 18:41:54 -0800 (PST) In-Reply-To: References: Date: Thu, 26 Jan 2012 18:41:54 -0800 Message-ID: From: Kevin Oberman To: Chuck Swiger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 02:41:56 -0000 On Thu, Jan 26, 2012 at 11:41 AM, Chuck Swiger wrote: > Hi-- > > On Jan 26, 2012, at 9:24 AM, satish amara wrote: >> I have question regarding the size of the state table kept in FreeBSD fo= r >> 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 sess= ion >> and state table is filled full. In that case I guess FreeBSD would rejec= t >> new sessions. =A0Just 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 HTT= P >> connection. What are options in terms of configuration or new feature in >> BSD would address this issue. > > A securely designed firewall will drop connections when the state table i= s full. > > You can increase the size of the state table by following the IPF FAQ: > > =A0http://www.phildev.net/ipf/IPFques.html#ques25 > > ...but in point of fact, keeping state for high-volume traffic is general= ly > a losing game, and you are better off (IMHO) setting up stateless bidirec= tional > rules which permit such high volume traffic. > > HTTP isn't generally too much of a problem, though-- something like a pop= ular > stratum-1 or 2 public NTP timeserver will easily blow out a stateful fire= wall > if you try to keep state for NTP's UDP traffic. 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. 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. 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.) 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