[179802] in North American Network Operators' Group
No subject found in mail header
daemon@ATHENA.MIT.EDU (Jimmy Hess via NANOG)
Thu May 7 19:39:33 2015
In-Reply-To: <20150507121254.GA26854@gsp.org>
To: Rich Kulawiec <rsk@gsp.org>
From: Jimmy Hess via NANOG <nanog@nanog.org>
Cc: NANOG list <nanog@nanog.org>
Reply-To: Jimmy Hess <mysidia@gmail.com>
Errors-To: nanog-bounces@nanog.org
Date: Thu, 7 May 2015 23:39:32 +0000 (UTC)
Return-Path: <mysidia@gmail.com>
X-Original-To: nanog@nanog.org
Delivered-To: nanog@nanog.org
Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234])
by mail.nanog.org (Postfix) with ESMTPS id 10DE22C0440
for <nanog@nanog.org>; Thu, 7 May 2015 23:39:30 +0000 (UTC)
Received: by iepj10 with SMTP id j10so48596842iep.0
for <nanog@nanog.org>; Thu, 07 May 2015 16:39:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc:content-type;
bh=xeCXFG5bznIKGVtvjjAwSBS+jjeh0lTlD/+Zs99g2zI=;
b=eBY88Whg6kc3CHga9+aCQEaf+ZBz8DfUB+EAGdjyES5mHdj1gFJIdqdIuzQSwrFYkj
HI189cU5njRoHkMkS8dHY4qxRYUZTREAWGk+k1T4AR9qdHx21t3/TFRZkkdu/Xe6KpBH
P12+pAIYUCSYpPOXGw/NsnDR47G8t0N0yUWykirjHISpeAJ1SSvjROjPKz9ECiIJ+eWI
QZ5J77e7WmxzQf0LHAAJeiagd/h7QJr9QsZvfmyV5cciQdjAWlBoNhgEPMTqa/PCDhTW
OGIWWTYsMuUGPNj0ys5zTOsMnHrKlzx+ExbUE633WndXAYjKPs+tQcLxq9zA2q1Srx+s
ZcEw==
X-Received: by 10.42.178.7 with SMTP id bk7mr1141561icb.79.1431041969595; Thu,
07 May 2015 16:39:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.50.205.42 with HTTP; Thu, 7 May 2015 16:39:09 -0700 (PDT)
In-Reply-To: <20150507121254.GA26854@gsp.org>
References: <20150506175831.C4959377@m0005311.ppops.net> <20150507121254.GA26854@gsp.org>
From: Jimmy Hess <mysidia@gmail.com>
Date: Thu, 7 May 2015 18:39:09 -0500
Message-ID: <CAAAwwbXKespJvS34hJqdVwGjkDAan1Co8tQsAPn7N9cRqE_YXg@mail.gmail.com>
Subject: Re: Network Segmentation Approaches
To: Rich Kulawiec <rsk@gsp.org>
Cc: NANOG list <nanog@nanog.org>
Content-Type: text/plain; charset=UTF-8
On Thu, May 7, 2015 at 7:12 AM, Rich Kulawiec <rsk@gsp.org> wrote:
> Ah...got it, this was sloppy phrasing on my part. I meant "first"
> in the sense of "first rule that one should write". Depending on
Security best practice to always have an active "cleanup" rule for
every traffic direction
applicable to every pair of zones (or interfaces) with a default DROP,
to catch traffic matching no accept rule.
In practice... however.... in the real world, many firewalls get
configured with
this only in the INBOUND direction (Default deny Write packet to
Higher integrity level
zone from lower level security zone), and Default Accept for
packet from more secure
zone to less secure zone, Since this has superior usability and is
lower maintenance.
And for client devices, in a low security environment: with just a
simple Layer4 stateful
inspection firewall, this is probably the right solution.
"Permit only traffic that is necessary"
Only works out if you are able to rigidly define what exactly that
traffic is in advance.
Which is feasible to do for servers and other single-purpose devices,
but very expensive to do for clients, at least without a firewall aware of
the communications at the application layer that can look at those
UDP connections
and say "OKAY, This is skype... allow it",
Or... "This connection going out on port 80.. it's not a valid HTTP request,
Drop the connection now and cache a rule to Deny further connections
to that IP:Port number pair.".
> the firewall type/implementation, that might be the rule that's
> lexically first or last (or maybe somewhere else).
> ---rsk
--
-JH
