On 5/5/2015 4:34 PM, Mark Andrews wrote:

In message <20150505113445.GB24399@gsp.org>, Rich Kulawiec writes:

...

I break them up by function and (when necessary) by the topology enforced by geography. The first rule in every firewall is of course "deny all" and subsequent rulesets permit only the traffic that is necessary.

Deny all really isn't needed with modern machines but that is a matter of policy.

The firewalls I've worked with don't log denies if they are due to an implicit deny-all at the end of the policy. I always put one in at the end to make sure that the attempt is logged. Gene

this is really a form of: "A subnet should contain all things of a like purpose/use." that way you don't have to compromise and say: "Well... tcp/443 is OK for ABC units but deadly for XYZ ones! block to the 6 of 12 XYZ and permit to all ABC... wait, can you bounce off an ABC and still kill an XYZ? crap... pwned." segregation by function/purpose... best bet you can get. On Wed, May 6, 2015 at 3:59 PM, <charles@thefnf.org> wrote:

...

Consider setting up a separate zone or zones (via VLAN) for devices with embedded TCP/IP stacks. I have worked in several shops using switched power units from APC, SynAccess, and TrippLite, and find that the TCP/IP stacks in those units are a bit fragile when confronted with a lot of traffic, even when the traffic is not addressed to the embedded devices.

Yes! This.

I used to have my PDUs/term serves/switches all on one VLAN. As growth occurred, they get broken out to dedicated VLANs. With that, the amount of false positives from Zenoss went way down (frequently port 80 would report down, then clear). I still get some alerts, but far less frequently.

I'd certainly forget anything with "service provider" in the name. Different problem, different architecture. Last time I built this, I built a core network (WAN links, routers, etc) that enforced anti-spoofing rules, so I knew if I saw an "internal" IP address (either public assigned to me or RFC1918) on a given device inside this "core", it came from the network segment it claimed to have come from. Then I built building-specific firewalls using proper firewalls. These might have anywhere from two interfaces (branch office) to thousands of interfaces (datacenters) with lots of VLANs. Checkpoint is a good product for this. The firewalls' job was to protect the building/segments behind it, not to protect things "upstream" (towards the core) of it. There was obviously an edge firewall. Users were segmented by job role. Workstations were typically considered to be *MORE* secure from a network perspective. AD servers need to be contacted by everything in your Windows domain. Most workstations don't. And your Windows domain, nowadays, probably includes cloud services over the internet. So it's hard to say AD servers are "secure" from a purely "how many open network ports are there?" standpoint. Servers were likewise segmented. I'd consider putting department file servers on the same LAN as the users, but only if performance required it - otherwise I'd put them on their own segments too. The benefit of this in a large organization is that a subdivision could put a firewall behind one of my anti-spoofing interfaces (so I validate packets come from them) and run it themselves without ruining everyone else's security. I second the thoughts about embedded management stacks. As for management, I put workstations used by IT management on their own segment (and give them a "Stand up the infected workstation you're working on" LAN separate from that segment). I put servers used for management on yet another segment. I've never had a problem with giving those workstations and servers access to management segments in the wild, but I trusted my skilled admins I worked with. Think mesh of connections, not "tiers" or levels or DMZs. Because you'll find that super-secure accounting server needs access from some random vendor across the internet, and stuff like that, such that everything eventually ends up in the DMZ anyhow (except MAYBE workstations). You can use separate firewalls for particularly sensitive segments - for instance, your management stuff might not be behind your main firewall - that way when Joe User gets a virus and fills the connection table on his firewall(s), you can still manage things. One more thing: Guest network access. When it was needed, I built a virtual network on top of the "real" Corporate LAN that tunneled this around. I terminated it on a DSL modem (which was sufficient for my needs). Just about every building with a conference room these days will need a guest network. It also helps if your employees can use their cell phones for checking work email and such - do you really want them on your main LAN? On Tue, May 5, 2015 at 7:01 AM, Keith Medcalf <kmedcalf@dessus.com> wrote:

It is called the Purdue Enterprise Reference Architecture ...

...

-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of nanog1@roadrunner.com Sent: Monday, 4 May, 2015 20:56 To: nanog@nanog.org Subject: Network Segmentation Approaches

Possibly a bit off-topic, but curious how all of you out there segment your networks. Corporate/business users, dependent services, etc. from critical data and/or processes with remote locations thrown in the mix which could be mini-versions of your primary network.

There's quite a bit of literature out there on this, so have been considering an approach with zones based on the types of data or processes within them. General thoughts:

- "Business Zone" - This would be where workstations live, web browsing occurs, VoIP and authentication services live too. Probably consider this a somewhat "dirty" zone, but I should generally be OK letting anything in this zone talk fairly unfettered to anything else in this zone (for example a business network at my HQ location should be able to talk unfettered to an equivalent network at a remote site).

I'd probably have VoIP media servers in this zone, AD, DNS, etc.

- Some sort of management zone(z) - Maybe accessible only via jump host -- this zone gives "control" access into key resources (most likely IT resouces like network devices, storage devices, etc.). Should have sound logging/auditing here to establish access patterns outsid the norm and perhaps multi-factor authentication (and of course FW's).

- Secure Zone(s) - Important data sets or services can be isolated from untrusted zones here. May need separate services (DNS, AD, etc.)

- I should think carefully about where I stick stateful FW's -- especially on my internal networks. Risk of DoS'ing myself is high.

Presumably I should never allow *outbound* connectivity from a more secure zone to a less secure zone, and inbound connectivity should be carefully monitored for unusual access patterns.

Perhaps some of you have some fairly simple rules of thumb that could be built off of? I'm especially interested to hear how VoIP/RTP traffic is handled between subnets/remote sites within a "Business Zone". I'm loathe to put a FW between these segments as it will put VoIP performance at risk (maybe QoS on FW's can be pretty good), but maybe some sort of passive monitoring would make sense.

(Yes, I've also read the famous thread on stateful firewalls[1]).

Thanks!

[1]

http://markmail.org/thread/fvordsbnuc74fuu2#query:+page:1+mid:fvordsbnuc74

...

fuu2+state:results