Re: Network Segmentation Approaches
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 the firewall type/implementation, that might be the rule that's lexically first or last (or maybe somewhere else). ---rsk
Re: Network Segmentation Approaches
It depends on the software used and implementation. Many rulesets for pf on BSD start with 'block in on interfaceX' for instance, because it uses a last match wins system, unless you use the 'quick' keyword to make rule processing stop if that rule matches. Andrew On 07.05.2015 08:30, Scott Weeks wrote: --- r...@gsp.org wrote: From: Rich Kulawiec r...@gsp.org The first rule in every firewall is of course deny all and subsequent rulesets permit only the traffic that is necessary. I think you got this backward? That way all traffic is blocked, so none is allowed through. Also, deny by default at the end of the rule set is not the best thing for every network that needs a firewall. Some just want to block bad stuff they see and allow everything else. (And some have stated here that they will block entire countries until their culture changes!) scott
Re: Network Segmentation Approaches
On Wed, May 06, 2015 at 03:30:01PM -0700, Scott Weeks wrote: --- r...@gsp.org wrote: From: Rich Kulawiec r...@gsp.org The first rule in every firewall is of course deny all and subsequent rulesets permit only the traffic that is necessary. I think you got this backward? That way all traffic is blocked, so none is allowed through. Nope, I said exactly what I intended (and what I do, in practice). Doing so forces one to understand in detail what traffic actually needs to pass in/out and to craft specific rules for it. This in turn helps avoid making mistake #1: The Six Dumbest Ideas in Computer Security http://www.ranum.com/security/computer_security/editorials/dumb/ ---rsk
Re: Network Segmentation Approaches
--- r...@gsp.org wrote: From: Rich Kulawiec r...@gsp.org The first rule in every firewall is of course deny all and subsequent rulesets permit only the traffic that is necessary. I think you got this backward? That way all traffic is blocked, so none is allowed through. Also, deny by default at the end of the rule set is not the best thing for every network that needs a firewall. Some just want to block bad stuff they see and allow everything else. (And some have stated here that they will block entire countries until their culture changes!) scott
Re: Network Segmentation Approaches
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, char...@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.
Re: Network Segmentation Approaches
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.
Re: Network Segmentation Approaches
From: Rich Kulawiec r...@gsp.org On Wed, May 06, 2015 at 03:30:01PM -0700, Scott Weeks wrote: From: Rich Kulawiec r...@gsp.org The first rule in every firewall is of course deny all and subsequent rulesets permit only the traffic that is necessary. I think you got this backward? That way all traffic is blocked, so none is allowed through. Nope, I said exactly what I intended (and what I do, in practice). Doing so forces one to understand in detail what traffic actually needs to pass in/out and to craft specific rules for it. This in turn helps avoid making mistake #1: The Six Dumbest Ideas in Computer Security http://www.ranum.com/security/computer_security/editorials/dumb/ - After reading your emails all these years, I figured you meant it the way you wrote it. When you wrote ...subsequent rulesets permit only the traffic that is necessary I misunderstood and thought you meant rules put in after the default deny, which are useless. But by subsequent rulesets you meant rule sets put in later in time and above the deny all not after the deny all. Small confusion over wording... :-) scott
Re: Network Segmentation Approaches
On 07.05.2015 08:30, Scott Weeks wrote: --- r...@gsp.org wrote: From: Rich Kulawiec r...@gsp.org The first rule in every firewall is of course deny all and subsequent rulesets permit only the traffic that is necessary. I think you got this backward? That way all traffic is blocked, so none is allowed through. Also, deny by default at the end of the rule set is not the best thing for every network that needs a firewall. Some just want to block bad stuff they see and allow everything else. (And some have stated here that they will block entire countries until their culture changes!) --- --- a...@jonesy.com.au wrote: From: Andrew Jones a...@jonesy.com.au It depends on the software used and implementation. Many rulesets for pf on BSD start with 'block in on interfaceX' for instance, because it uses a last match wins system, unless you use the 'quick' keyword to make rule processing stop if that rule matches. - I was assuming stop looking on first match. So, deny ip any any blocks everything at the very beginning. scott
Re: Network Segmentation Approaches
On Mon, May 04, 2015 at 07:55:43PM -0700, nan...@roadrunner.com wrote: Possibly a bit off-topic, but curious how all of you out there segment your networks. [snip] 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. Determing what's necessary is done via a number of tools: tcpdump, ntop, argus, nmap, etc. When possible, rate-limiting is imposed based on a multiplier of observed maxima. Performance tuning is done after functionality and is usually pretty limited: modern efficient firewalls (e.g., pf/OpenBSD) can shovel a lot of traffic even on modest hardware. ---rsk
Re: Network Segmentation Approaches
On Mon, May 4, 2015 at 9:55 PM, nan...@roadrunner.com wrote: 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: It depends on the users and tasks on the network.. Different segmentation strategies / tradeoffs get selected by people dependent upon what there is to be protected, Or where needed to control broadcast domain size, and value tradeoffs. Segmenting certain systems, or segmenting certain data, Or more likely both are called for to mitigate selected risks: both security risks, as well as network risks, Or to facilitate certain networks being moved independently to maintain continuity after DR. - Business Zone - This would be where workstations live, but I should [] generally be OK letting anything in this zone talk fairly unfettered to anything else in this zone Since you imply all workstations would live on the same zone as each other, instead of being isolated or placed into job-role-specific access segments, then what you have here is a non-segmented network; that is: It sounds like this begins to look like your generic non-segmented zone with small numbers of exceptions strategy; you wind up with a few huge business zones which tend to become larger and larger over time -- are really still at highest risk, then a small number of tiny exception zones such as 'PCI Card Environment' zone, which are okay, until some users inevitably develop a requirement to connect workstations from the massive insecure zone to the tiny zone. Workstations talking to other workstations directly is an example of one of the higher risk things, that is probably not necessary, but remains unrestricted by having one single large 'Business' segment. A stronger segmentation model would be that workstations don't get to talk to other workstations directly; only to remote devices servicing data that the user of a given workstation is authorized to be using, with every flow being validated by a security device. I'd probably have VoIP media servers in this zone, AD, DNS, etc. AD + DNS are definitely applications that should be at a high integrity protection level compared to generic segment from security standpoint; Especially if higher-security zones are dependent on those services. An AD group policy configuration change can cause arbitrary code execution on a domain-joined server in any segment attached to a domain using that AD server. 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. Never?No internet access? Never say never, but there should be policies established based on needs / requirements and dependent on the characteristics of a zone and the assumed risk level of other zones. An example for some high risk zone might be that outbound connections to A, B, and C only through a designated application-layer proxy itself residing in a security service zone. 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), The ideal scenario is to have segments dedicated to primary VoIP use, so VoIP traffic should stay in-segment, except if interconnecting to a provider, and the firewalls do not necessarily have to be stateful firewalls; if VoIP traffic leaves a segment, some may use a simple packet filter or application-aware proxy designed to maintain the performance. If the security requirements of the org implementing the network are met, then very specific firewall devices can be used for certain zones that are the most suitable for that zone's traffic. but maybe some sort of passive monitoring would make sense. -- -JH
RE: Network Segmentation Approaches
It is called the Purdue Enterprise Reference Architecture ... -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of nan...@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
Re: Network Segmentation Approaches
On 05/04/2015 07:55 PM, nan...@roadrunner.com wrote: 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. Add management zone or infrastructure zone: 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. Separately, an ISP discovered that a consumer-grade NAS has the same problem. These should be on a separate subnet anyway, with unfettered access from the outside disallowed at the edge. To access the infrastructure equipment, you would use VPN to bypass your edge router access lists. If you have a lot of inside equipment not under your direct control, consider locking them out of the infrastructure subnet, too. Needless to day, watch the load you direct at these embedded devices. My current day job installed Solar Winds to monitor everything. The probes from the software knocked out the SNMP access to all too many of the PDU devices on the network.
Re: Network Segmentation Approaches
On 5/5/2015 4:34 PM, Mark Andrews wrote: In message 20150505113445.gb24...@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
Re: Network Segmentation Approaches
In message 20150505113445.gb24...@gsp.org, Rich Kulawiec writes: On Mon, May 04, 2015 at 07:55:43PM -0700, nan...@roadrunner.com wrote: Possibly a bit off-topic, but curious how all of you out there segment your networks. [snip] 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. The first rule of every firewall should be to enforce BCP 38 out bound. Deny all really isn't needed with modern machines but that is a matter of policy. Determing what's necessary is done via a number of tools: tcpdump, ntop, argus, nmap, etc. When possible, rate-limiting is imposed based on a multiplier of observed maxima. Performance tuning is done after functionality and is usually pretty limited: modern efficient firewalls (e.g., pf/OpenBSD) can shovel a lot of traffic even on modest hardware. ---rsk -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Network Segmentation Approaches
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 kmedc...@dessus.com wrote: It is called the Purdue Enterprise Reference Architecture ... -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of nan...@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
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:fvordsbnuc74fuu2+state:results
