Is there a way to setup an ASA firewall policy in a "zone-based" model where inter-zone traffic is blocked by default without the use of explicit ACLs?
This is what I mean:
- Subnet A may talk to Subnet B
- Subnet C may talk to Subnet D
- Subnet E may talk to Any EXCEPT Subnet B and D
So far the only way I see to accomplish this is to have explicit deny ACLs restricting Subnet E from talking to B and D, then permitting it to talk to Any, but that's not very scalable when there's tons of subnets and traffic patterns like that.
On a Juniper SRX I can say:
- Zone1/Subnet A may talk to Zone2/Subnet B
- Zone3/Subnet C may talk to Zone4/Subnet D
- Zone5/Subnet E may talk to Zone6/Any
This would allow Zone5/Subnet E to talk to anything only on Zone6 and implicitly block talking to Zone2 and Zone4.
I know I can use nameifs, but you still have the issue with "any" rules because nameifs just don't behave like zones. I'm also not sure if security levels or the "same-security intra/inter..." command would help me here. And from what I recall these commands are nullified once you apply an ACL to the interface.
Thoughts?
Part of that is handled with security levels for zones: lower may not talk to higher, by default.
But then, yeah, you're going to have to use ACLs.
Yeah depending on how complex you want it levels might be how you want to go, Higher can talk to lower, but low can't talk to higher, and ones on the same level can't talk between one another by default.
The Juniper way does sound more awesome.
So say I have this:
INTERFACES:
nameif SubnetA
security-level 50
nameif SubnetB
security-level 50
nameif SubnetC
security-level 50
nameif SubnetD
security-level 50
nameif SubnetE
security-level 50
nameif SubnetX
security-level 100
ACL:
Permit SubnetA to talk to SubnetB
Permit SubnetC to talk to SubnetD
Permit SubnetE to talk to Any
Would this imply that SubnetE (security-level 50) will only be able to talk to SubnetX (security-level 100) but NOT Subnets A through D since A through D are the same security level?
Heard that the ASAs recently received a zone-based feature. Looks like 9.3.2 and the feature is called traffic zones. If cisco is five or so years behind the market it probably means it's buggier than an ant hill.
I came across that command/feature earlier while Googling, but looks like it's just for traffic load balancing/ECMP:
http://www.cisco.com/c/en/us/td/docs/security/asa/asa93/configuration/general/asa-general-cli/interface-zones.html
"You can assign multiple interfaces to a traffic zone, which lets traffic from an existing flow exit or enter the ASA on any interface within the zone. This capability allows Equal-Cost Multi-Path (ECMP) routing on the ASA as well as external load balancing of traffic to the ASA across multiple interfaces."
Quote from: packetherder on August 11, 2015, 05:18:33 PM
Heard that the ASAs recently received a zone-based feature. Looks like 9.3.2 and the feature is called traffic zones. If cisco is five or so years behind the market it probably means it's buggier than an ant hill.
I LOLed!!!!
Quote from: killabee on August 11, 2015, 05:07:29 PM
So say I have this:
INTERFACES:
nameif SubnetA
security-level 50
nameif SubnetB
security-level 50
nameif SubnetC
security-level 50
nameif SubnetD
security-level 50
nameif SubnetE
security-level 50
nameif SubnetX
security-level 100
ACL:
Permit SubnetA to talk to SubnetB
Permit SubnetC to talk to SubnetD
Permit SubnetE to talk to Any
Would this imply that SubnetE (security-level 50) will only be able to talk to SubnetX (security-level 100) but NOT Subnets A through D since A through D are the same security level?
with your example above SubnetX can talk to each of the other subnets A, B, C, D, & E.
since the 'same-security-traffic permit inter-interface' command is global to allow same-security interfaces to communicate will allow all security level 50's to talk, you'll need use denies in the ACL to block unwanted traffic flows. subnets A, B, C, D, & E will need ACL's applied to allow communication with subnetX
Quote from: wintermute000 on August 12, 2015, 04:39:23 AM
Quote from: packetherder on August 11, 2015, 05:18:33 PM
Heard that the ASAs recently received a zone-based feature. Looks like 9.3.2 and the feature is called traffic zones. If cisco is five or so years behind the market it probably means it's buggier than an ant hill.
I LOLed!!!!
And what's frustrating is that the "zone" feature isn't even what we think of as a zone in the context of firewall/security speak!!!
Quote from: ristau5741 on August 12, 2015, 07:36:43 AM
with your example above SubnetX can talk to each of the other subnets A, B, C, D, & E.
since the 'same-security-traffic permit inter-interface' command is global to allow same-security interfaces to communicate will allow all security level 50's to talk, you'll need use denies in the ACL to block unwanted traffic flows. subnets A, B, C, D, & E will need ACL's applied to allow communication with subnetX
Damnit! I was afraid of that. I'm going over this with TAC at the same time, hoping there's a way to do this. But the more I think about it, we're essentially using the ASA as a multitenant firewall...and why would Cisco give us true security zones when they can sell us ASA context licenses?
This is one place where I like the SRX better.
Srx if you also want a router/Junos. Checkpoint and palo if you want ngfw.
Ironically I've seen srx rejected on tbe grounds that it was not best practice to run same os on firewalls as normal routing switching infrastructure.
With both Srx and palo you have the option of virtual routers as well as contexts
BUUUUT checkpoint has no zones.... and has rapey per-context licensing... and doesn't give you the config in a text/XML file.... and is checkpoint.....
so: the answer is palo :partay:
IN all seriousness though for multi-tenant, SRX or vSRX is compelling, the R&S factor comes into play quite heavily I find, and when dealing with multi-tenant you don't have the usual NGFW concerns (who has the time/overhead to get into that for each customer?) but rather separation and basic stateful firewalling tickbox / outbound NAT / server 1:1 NAT, SRX is a great fit and the standard go-to in a lot of multi-context firewall/router scenarios.
Disclaimer: work for a palo partner, drinks kool aid
@ Wintermute: why not Fortinet?
And yes, Checkpoint isn't zone-based at all so that's useless here.
Isn't Fortinet just a poor mans Juniper? lol
With only those three, I'd say "Man up and use your ACLs." But you said "tons of subnets" were involved. How many, approximately?
21 interfaces with one subnet each
1 interface acts as the inside/transit to the internal network where the remaining enterprise subnets exist (>100) and Internet is reachable through
The problem is that some of the 21 subnets behind those interfaces need a limited "any" access to the inside/transit side of the network (AKA, the enterprise), so the FW rules on an ASA with ACLs would look something like this:
Subnet1 deny Subnet2
Subnet1 deny Subnet3
Subnet1 deny Subnet4
Subnet1 deny Subnet5
Subnet1 deny Subnet6
Subnet1 permit any
Subnet2 deny Subnet1
Subnet2 deny Subnet3
Subnet2 deny Subnet4
Subnet2 deny Subnet5
Subnet2 deny Subnet6
Subnet2 permit any
[and so on]
So 21 subnets with 1 additional "any" subnet, we're looking at up to 21(21-1)+X=441+X ACLs, where X is the number of "any" ACLs I'll have....maybe my math is jacked up, but you get the point. On the other hand the SRX has around 146 rules or so thanks to its implicit deny at the end of each zone (each subnet ties into a zone)
Sure, I could use object groups...but it still hurts that there isn't a more efficient way to do it :-(
Especially if you want bidirectional communication... yeeesh.
well fortinet is in the mix too I suppose. I don't know much about them TBH other than everyone telling me they're great bang-for-buck and UTM for mid-market, but if you turn all the features on the throughput goes south somewhere shocking. I've also heard that at the enterprise level some of the features/reliability doesn't stack up to the big boys.
Interestingly, I have dealt with one cloud company before that basically bought entire pallets of Fortinet C-series (The little ones), racked them up 2x per RU and maxed out the contexts = 12 contexts per RU = 12 customer instances, they showed me the math and it was by a significant margin the cheapest way to deploy multi context firewalling even considering RU/power etc. Of course each customer was getting SFA processing grunt but they were using them more like stateful fws than a UTM/NGFW anyway - again, cloud multi-tenancy, firewalling is more about separation/internet PAT/tickbox than NGFW.
Fortinet did not please us when we tested them.
Sent from my SM-N900P using Tapatalk
Care to comment why
1. Could not operate well in our environment because we do not have a default route to the Internet. We opened up a permission for it to talk with the outside world, but it couldn't use the proxy server for Internet traffic.
2. The consultant they sent to assist with the testing was affable enough, but technically inept. He gave us some bad info for setting things up and then got confused about it later on and spent a lot of time staring at the screen, trying to figure out what was wrong.
3. Same consultant threw me under the bus when my manager asked what was going on. Blamed the problems on me. When I showed the email that said to set them up the way that they were, my manager was none too pleased with said consultant and his product.
4. If that's the kind of support we can expect from them, we don't want that product in our house.
At least that was better than the McAfee/Intel guy that couldn't figure out how to plug a network cable into a switch port. Seriously. He pushed it almost all the way in and complained that the port was faulty or something. I pushed the cable in just a bit more to get the *tink*, indicating that it was actually all the way in, and it worked fine.
well sounds like an issue with your SE/partner than the actual product.
I've never seen a FW before that used a proxy. Usually the proxy is behind the FW and the FW has access to the default route even if the internal network doesn't and/or is blocked.
Have some fortinet's in production. Had a similar pre-sales experience as dean. My hunch is that there's a small cabal of developers who truly know the product but they are well insulated from customers...and sales...and support. I'm really not a big fan of the NGFW concept anymore because of it, honestly.
Fortinet's a decent firewall, if all you're doing is filtering packets, but the NGFW features are buggy.
Quote from: deanwebb on August 25, 2015, 09:58:15 AM
1. Could not operate well in our environment because we do not have a default route to the Internet. We opened up a permission for it to talk with the outside world, but it couldn't use the proxy server for Internet traffic.
2. The consultant they sent to assist with the testing was affable enough, but technically inept. He gave us some bad info for setting things up and then got confused about it later on and spent a lot of time staring at the screen, trying to figure out what was wrong.
3. Same consultant threw me under the bus when my manager asked what was going on. Blamed the problems on me. When I showed the email that said to set them up the way that they were, my manager was none too pleased with said consultant and his product.
4. If that's the kind of support we can expect from them, we don't want that product in our house.
At least that was better than the McAfee/Intel guy that couldn't figure out how to plug a network cable into a switch port. Seriously. He pushed it almost all the way in and complained that the port was faulty or something. I pushed the cable in just a bit more to get the *tink*, indicating that it was actually all the way in, and it worked fine.
Wow - that's a pretty crappy experience, Dean. Seeing this and your reaction is exactly why I take the approach I do because I remember exactly what it was like being in an engineer's shoes and distrusting vendors. If I don't know - I just say I don't know. I don't care if I look stupid - I haven't been fired for this approach (yet). Customers seem to respond to that well as long as you're willing to dig up the info for them or get them in touch with an SME on the particular tech. I'm not just going to screw up your environment and then blame you for it - what a tool.
And I appreciate your approach, AspiringNetworker :-)
Just to close the book on my issue, we ended up creating a deny rule for each nameif that denied it's network from talking to other networks on the same box, then created permit rules to whereever the network needed to go. Copy and paste saved the day, as usual. This really made me appreciate true zone-based firewalls, but it is what it is.
Having them in production for a year now I can share my Fortinet experience:
Positive: they're absolutely fantastic for stateful inspection. They have a Network Processing Unit, which is basically an ASIC that is stateful. They show little to no jitter under load, have low latency and have good throughput. IPsec VPN encryption in the hardware goes great as well. So for a 'secure router' it's about the best to get. Voice over VPN with these devices is no problem.
Negative: you may have noticed in the 'positive' part that all those functions depend upon the NPU. The software and CPU suck. The moment you activate anything that requires inspection about layer 4, the CPU will be involved and throughput will plummet completely. I'm talking from 1 Gbps L4 throughput on an interface to about 30 Mbps L7 in some cases. Antivirus, website filtering, IPS, application recognition, ... All useless really. The best way to do website filtering on a Fortinet for me is DNS-based: it will intercept DNS requests and check if the requested domain is allowed. This is not CPU intensive and works reasonably.
Conclusion: it's a Secure Router, not a NGFW. But I'm still a fan because it's exactly what some environments need. It just shouldn't be marketed as NGFW, and perhaps with a beefier CPU for some models it would become a good all-round device.
Disclaimer: I'm probably going to make a blog post based on this comment here.
well thats defo known in the community (i.e. start turning features on and watch the headline throughput plummet) but I didn't quite know it was THAT bad. Care to name the specific model that goes from 1Gb to 30Mb?
I might follow up internally next week with the Security team, because that sounds pretty poor
Quote from: wintermute000 on August 29, 2015, 07:20:56 AMit was THAT bad. Care to name the specific model that goes from 1Gb to 30Mb?
Fortigate-60D. Note that I did not involve their support for this one, it may be less bad with the right knobs.
The features I had turned on were flow-based web filtering, anti-virus and Traffic Shaping. Ironically, Traffic Shaping pushes flows through CPU, decreasing throughput... Although high priority indeed gets a lower latency than the other profiles.