ASA... security level question

mikearama

Hey ASA techies... here's one for ya.

We have an internal ASA that seperates the various layers of our EBIZ infrastructure... Web, App/DB, and Bridge to internal networks. The security levels are:

Outside - 0 (to External ASA, connected to internet and DMZ's)
Web - 50 (all web servers)
App/Db - 80 (app and database servers that service our webservices)
Bridge - 100 (all internal networks... servers/users)

The issue I've had for a while revolves around traffic from the Web and App zones getting across the Bridge network to other devices... syslog servers, AD servers, DNS servers, and equivalent servers in UAT. I had to add rules for Web and App to access the more secure Bridge networks.

In doing so, the implicit rule that allows traffic from higher zones to access lower zones disappeared. And since all of our servers must have the ability to access the outside networks (DMZ's, and internet), I had to leave a "permit any any" in place to do that too.

The only thing I can think of to rectify this screwup is to drop the security level of the Bridge interface to something less than 50. By doing so, I can kill all the rules on the Web and App/Db interfaces that are currently required to get traffic to the Bridge network. Then I get back my implicit "higher to lower" rule.

I just wondered if anyone's come across this kinda situation before and may have other options.

Much obliged,
Mike

EDIT: Hey, I just reread that, and the next-most obvious question is... is it even possible to change the "inside" interface (what I call the Bridge) from 100 to something less? Is it mandatory to have an interface with a security level of 100? or can I have levels of 0, 25, 50 and 80 without a corresponding level 100?

If I'm wrong and I have to have a level 100 somewhere, I guess I'd be forced to up the App/Db interface to 100, and then change Bridge to 25.

Just thinking out loud.

Ahriakin

It depends on where/what direction you placed your ACLs. Simplify it and take the Inside -> Outside , the Implicit deny any any is provided by the security level rules, since Outside is lower the rule is in place. Your ACL inbound on the Outside interface allows Outside traffic to initiate the traffic in the ACL, but you are not restricting replies to traffic initiated from the Inside -> Out as that is handled by the stateful engine, to block that you would have an ACL inbound on your Inside interface. It's the same principal with your DMZs. Now you could run into issues if you configure say an ACL outbound on your Inside interface, then it's implicit deny would block anything returning to the Inside that wasn't in the ACL. Personally I try to only use inbound lists when possible with specific permits and an explicit deny any any, and any outbound lists are deny first and then permit ip any any.

As for your other question yes you can change the security level of any interface at any time, just use the security-level command. Also remember that by default the ASA will not let traffic pass between interfaces with the same security level, so either avoid that or use 'same-security-traffic permit inter-interface'

mikearama

I appreciate the rely, Ahriakin.

Just a follow up though, as I read and reread your reply and I don't think you addressed what I cannot help but call a design flaw.

As it stands right now, by DMZ interfaces have security levels of 50 and 80 respectively. Back when I first set them up, they had the built-in "permit any to Any less secure networks" working fine.

Then I was asked to allow the hosts in the DMZ's to be able to access the Inside network (again, for AD/dns/ntp/etc). As soon as I created the first rule to allow a DMZ host to initiate access to the Inside (Bridge) interface, the built-in "permit any to Any less secure networks" rule disappeared. Now the DMZ hosts couldn't get out to the internet.

Based on that, I currently have specific rules for the DMZ interfaces to allow hosts to reach the inside networks, and a "permit ip any any" for those same DMZ hosts to reach the internet. Well that's dumb... a bunch of specific rules followed by a "permit any any". Why even have the specific rules at all if I'm just going to follow it all with a "permit any any"!

There's got to be a better solution that that, no?

bighornsheep

mikearama wrote: »

Based on that, I currently have specific rules for the DMZ interfaces to allow hosts to reach the inside networks, and a "permit ip any any" for those same DMZ hosts to reach the internet. Well that's dumb... a bunch of specific rules followed by a "permit any any". Why even have the specific rules at all if I'm just going to follow it all with a "permit any any"!

There's got to be a better solution that that, no?

Is the ASA the only routing device on DMZ/inside? You can use a router or another ASA/PIX with interfaces on the DMZ/inside as the default gateway to control the interior traffic, and only route to the perimeter ASA for Internet traffic.

mikearama

bighornsheep wrote: »

Is the ASA the only routing device on DMZ/inside? You can use a router or another ASA/PIX with interfaces on the DMZ/inside as the default gateway to control the interior traffic, and only route to the perimeter ASA for Internet traffic.

I wish I knew how to post a pic in here... would make things clearer.

Internet
|
Bell 7200 Router
|
| outside (0)
External ASA - DMZ (50)
| inside (100)
|
MSFC (Cat6509)
|
| outside (0)
Internal ASA - Web DMZ (50)
Internal ASA - App/Db DMZ (80)
| inside (100)
|
Cat4500 core

So while I call them DMZ's for lack of a better term, they might as well just be called "other interfaces" of the internal ASA. And there's no other routing device in each of them... they simply connect back to a block of ports in one of the switch blades in the Cat6509.

Hope that cleared it up a bit. There's no way I'll get the okay to add a routing device in the DMZ's to bypass the internal ASA's... our network was designed with "security in depth", and after blowing the money on 4 pairs of ASA's, I will not be given the nod to work around it.

I appreciate the input.
Mike

bighornsheep

Does your MSFC support VRF? You can add an Int VL <DMZ> and Int VL <inside> to a VRF and put an ip address on there as the default gw. Add a default route (only for that VRF) pointing to the ASA's ip on the DMZ intf for Internet traffic.

mikearama

I don't see how adding VL's to the Cat/MSFC helps with an ACL issue in the DMZ's. Again, I need a solution involving the ASA's, not routing around them. And there is a default route in all DMZ's pointing to the outside interface to the internet.

The issue is the "higher to lower" builtin ACL that is now missing in the Web and App DMZ's. Our cisco support guy suggested condensing all the existing rules into a single "permit ip any any" with all of the required ports condensed into a single service-group, so while the "any any" may have to stay, at least only the required ports will be available. The only con to that is the number of ports... prolly something like 30 by the time I tally them up.

I have a feeling I'll end up dropping the security level of the Bridge (inside) interface, which will allow the Web and App DMZ's to get inside... I'll still have to do something with the Wed DMZ to allow its hosts to access both the App DMZ and the internet.

bighornsheep

Sorry Mike, I didn't read everything.

The reason I suggested the VRF idea is because even if you have a permit ip any any in the APP/WEB zone on the ASA, you can control the return traffic in the core router. In our environment here, our internal zone and the 6509 core router have host routes to permit returning traffic from our syslog, and TFTP going to specific hosts.

In the case if you want to fix it strictly on the ASA, and if you don't want to change the security level, and personally, I wouldn't. What I would do is permit the specific service to the host in the inside network, but followed by a deny ip inside_subnet inside_subnet_mask statement, followed by your permit ip any any for the Internet.

mikearama

bighornsheep wrote: »

What I would do is permit the specific service to the host in the inside network, but followed by a deny ip inside_subnet inside_subnet_mask statement, followed by your permit ip any any for the Internet.

Ah, now that I like. Good thinking. I'll play with this in the lab and see how it plays out.

bighornsheep

mikearama wrote: »

Ah, now that I like. Good thinking. I'll play with this in the lab and see how it plays out.

Geez, you're hard to please.....

Ahriakin

bighornsheep wrote: »

What I would do is permit the specific service to the host in the inside network, but followed by a deny ip inside_subnet inside_subnet_mask statement, followed by your permit ip any any for the Internet.

Nail...Head....Hit
You can still achieve exactly what you need, you just have to be specific on the Subnets to simulate the direction of protection (yes I know that rhymes).

mikearama

bighornsheep wrote: »

Geez, you're hard to please.....

Hah!! No kidding! Hey, just cause you suggested it, and I like it, doesn't mean I know exactly how to implement it. Trust me... I get it wrong and it's my head.

Or as Ahriakin put it:

Ahriakin wrote:

Nail...Head....Hit

Only, literally!