From owner-freebsd-pf@FreeBSD.ORG Wed Jul 28 19:30:02 2010 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4ECB1065675 for ; Wed, 28 Jul 2010 19:30:02 +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 653028FC0C for ; Wed, 28 Jul 2010 19:30:02 +0000 (UTC) Received: from iad-wprd-xchw02.corp.verio.net (iad-wprd-xchw02.corp.verio.net [198.87.7.165]) by relay1-bcrtfl2.verio.net (Postfix) with ESMTP id 2316BB0380D6 for ; Wed, 28 Jul 2010 15:30:01 -0400 (EDT) Thread-Index: AcsuiuJJVXUSBPGLQ9eik0HfQVaALw== Received: from dllstx1-8sst9f1.corp.verio.net ([10.144.2.52]) by iad-wprd-xchw02.corp.verio.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Jul 2010 15:27:13 -0400 Received: by dllstx1-8sst9f1.corp.verio.net (sSMTP sendmail emulation); Wed, 28 Jul 2010 14:27:13 -0500 Content-Transfer-Encoding: 7bit Date: Wed, 28 Jul 2010 14:27:13 -0500 From: "David DeSimone" To: Content-class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4657 Message-ID: <20100728192712.GW1280@verio.net> Mail-Followup-To: freebsd-pf@freebsd.org References: <20290C577F743240B5256C89EFA753810C46894B92@HIKAWSEX01.ad.harman.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20290C577F743240B5256C89EFA753810C46894B92@HIKAWSEX01.ad.harman.com> Precedence: bulk User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 28 Jul 2010 19:27:13.0639 (UTC) FILETIME=[E1A73F70:01CB2E8A] Subject: Re: For better security: always "block all" or "block in all" is enough? 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: Wed, 28 Jul 2010 19:30:02 -0000 It's all about layers of defense, and whether the reduced convenience is worthwhile. Limiting outbound traffic from your system is a hassle, but I like to think about this scenario: Suppose an attacker did manage to find an exploitable method on your system, and was able to open up a shell. What would they try to do? I think a common next step is for the attacker to download his "bag of tools" onto the system and to try to exploit further, or make himself at home. If your outbound policy blocks him from being able to download his rootkit or exploit tools, you may very well stop him from getting any further into your system. Spenst, Aleksej wrote: > > I have to provide for my system better security and I guess it would > be better to start pf.conf with the "block all" rule opening > afterwards only those incoming and outcoming ports that are supposed > to be used by the system on external interfaces. However, it would be > easier for me to write all pf rules if I start pf.conf with "block in > all", i.e. if I block only traffic coming in from the outside and open > all ports for outgoing traffic. > > - Incoming ports: only udp/68 (for dhcp client) and http/80 (for http > server) always open; > - Outgoing ports: all ports always opened. All traffic going outside > from the system has "keep state"; > > What disadvantages does it have in term of security in comparison with > "block all"? In other words, how bad it is to have all outgoing ports > always opened and whether someone can use this to hack the sysem? > > Thanks a lot for any tips!! > Aleksej. -- 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.