asa nat

[whanson]

I just discovered something that I don't believe should work but it does. I always thought if you were going from a lower to higher security that you required static entries and access list however I discovered the following

nat (dmz) 0 172.16.1.20 255.255.255.255

access-list dmz permit ip any any

172.16.1.20 can access anything on the inside. I would have thought you would have to statically define what the dmz could get to but apparently not

[husycisco]

Hello Bill,

With a little correction, yes it needs "address translation entries" and access list while going from low sec to high sec.

As you know, control on address translation in Cisco firewalls, is one of the feature that distinguishes firewalls from routers. If you put a Cisco firewall into your lab, simply connect and configure two interfaces, and permit traffic any any at both interfaces, you will get "no translation group found" or "portmap translation creation failed" errors on syslog when you try to establish a simple test connectivity between segments.

Cisco sees that as a security measure. And the command that adds this behaviour to firewall and distinguishes it from a router "nat-control", is by default enabled (except "legacy" versions)

Thats why security admins now have to enter a path that introduces new types of NAT.

First, "directions" were introduced. What is that? In a simple routing device, if I create a NAT rule, the translated address can both reach a remote destination and also can "be reached" from remote destination. It is bidirectional. But now, there are two categories. Bidirectional as traditional NAT explained above, and unidirectional ones, which only the translated address can originate traffic, which means only the return traffic will be allowed to translated address. A remote client wont be able to connect to that translated address. Keep in mind that this is not provided via ACLs! Here they are

BD=Bidirectional

UD=UniDirectional

*Static NAT (BD)

static (inside,outside) 81.214.255.216 172.16.5.1 netmask 255.255.255.255

81.214.255.216 can be reached from outside and traffic forwarded to 172.16.5.1. 81.214.255.216 also reaches remote clients when 172.16.5.1 is translated. Ideal for web or exchange servers that are needed to access/be accessed from/to internet.

*Identity NAT (UD)

nat (inside) 0 172.16.5.10

This command bypasses the NAT by translating the 172.16.5.10 again to 172.16.5.10 when traffic destined for another interface. 172.16.5.10 can originate traffic and connect to any clients located in any interfaces, and "only!" the return traffic to 172.16.5.10 is allowed. A client located at an interface except inside can not reach 172.16.5.10. Ideal for management stations that only pull information from remote machines.

*Static Identity NAT (BD)

static (dmz,inside) 192.168.16.99 192.168.16.99 netmask 255.255.255.255

Same function with above Identity NAT except you define the destination (mapped interface) interface which you want to bypass NAT. But this time, 192.168.16.99 can also be accessed by inside hosts and 192.168.16.99 can access inside hosts.

*Nat Exemption (BD)

access-list crypto_10_map permit ip 172.16.5.0 255.255.255.0 10.5.20.0 255.255.255.0

nat (inside) 0 access-list crypto_10_map

Common used type of bypassing NAT. Includes a ACL, consider it a policy, and when this policy is met, the bypassing rule kicks in. The source can both reach/be reached to/from the destination specified in ACL only.

Lol I hope I didnt get confused and mix them up :) Looks complex at first. So long story short, what we have to do is configuring NAT. "would have to statically define(using static command) " or using nat command is only the "form" of it.

As I previously mentioned, this "permission of direction" thing is handled at routing process, which is "after" the filtering process at interface inbound buffer. So either If ACL permits and NAT is UD or ACL does not permit and NAT is BD, traffic wont flow (except inspected return traffic)

You may get pissed when I say this one in the end :D but here it goes ... If you say that "I dont want an extra layer of security at routing layer, I can do my job with ACLs, let the firewall behave like a router" then simply issue

no nat-control

Regards

[whanson]

Thank you very much. I learn something everyday, but I do disagree with it and I'll bet most people don't see it. We have customers that divide up their class b address space; some for outside some for dmz. As a matter of course, they are not going to nat the dmz addresses because they are public, but that opens up the very real possibility, unless you control it with ACL, that if the dmz device is compromised access to the inside is very likely. The other one I find extremely interesting is the access list. As you know most folks don't want to translate going to a DMZ so they nat 0 access-list, but from what you are saying depending on how the dmz access is structured you could very well have opened up huge holes.

Bill

[bmcginn]

Mate,

That was a very good post, and I have given it a 5 purely for your ability to articulate and communicate your understanding.

Well done!

[cisco24x7]

"As you know, control on address translation in Cisco firewalls, is one of the feature that distinguishes firewalls from routers. If you put a Cisco firewall into your lab, simply connect and configure two interfaces, and permit traffic any any at both interfaces, you will get "no translation group found" or "portmap translation creation failed" errors on syslog when you try to establish a simple test connectivity between segments."

That is NOT correct. On version 7.x and 8.x, "no nat-control" is the default. Therefore,

traffics from higher security interfaces can traverve the firewall and access resources

on lower security interfaces (with the exception of icmp traffics). By design of default,

the ASA is a router with the exception that traffics on lower security interfaces can not

access resources on higher security interfaces WITHOUT ACLs.

"Cisco sees that as a security measure. And the command that adds this behaviour to firewall and distinguishes it from a router "nat-control", is by default enabled (except "legacy" versions)"

This is a stupid design by Cisco. Checkpoint firewall has the most security market share

and I do not use this. It makes Checkpoint firewall much easier to manage than Cisco ASA

appliances but it is another story for another story.

"You may get pissed when I say this one in the end :D but here it goes ... If you say that "I dont want an extra layer of security at routing layer, I can do my job with ACLs, let the firewall behave like a router" then simply issue

no nat-control"

That is correct; however, the minute you enable NAT/PAT, this command becomes useless.

[husycisco]

"As you know most folks don't want to translate going to a DMZ so they nat 0 access-list, but from what you are saying depending on how the dmz access is structured you could very well have opened up huge holes."

That is correct Bill. This is where the default behavior of ASA comes into play at interface buffer level instead routing thread. It denies DMZ (low sec) originated traffic. I agree with the “huge holes” especially 60 of 100 security admins usually back off when they see an access-list consists of hundreds of ACEs (some has permit any any statement after hundreds of ACEs lol) and say “Yea this way was fine and will be fine” or add wide permit statements to DMZ. The security level design and nat-control behavior of ASA tells us “Man I know you are lazy that why I came up with settings that I wont work if you dont configure so you cant ignore me” and insists, but lazies still go on with widely open configurations, disable features, leave defaults. These are the ones who actually don't have the need and understanding of Isolation, or the ones who are not paid for securing the campus specifically, System engineers etc.

“That was a very good post, and I have given it a 5 purely for your ability to articulate and communicate your understanding”

Thanks mate :)

"That is NOT correct. On version 7.x and 8.x, "no nat-control" is the default"

YOU are correct David. Looks like what I described there was actually "my defaults" not Cisco's :). I sometimes get confused about if that was default on legacys or on the new ones since I deal with enabled ones most of the time.

"This is a stupid design by Cisco. Checkpoint firewall has the most security market share

and I do not use this."

Having the most market share does not mean that it is technically excellent. Actually, it is the market itself which tailors the technology to itself not tailoring itself to technology. Even us and our abilities. Market wants the "cheap". Market wants the Unifieds not Distributeds. That may include the use of ASA alone with a router for PBR capabilities, serial int termination, BGP ISP dual homing etc; conserving processor cylcles to security only while Checkpoint or any x does them both alone, as well as include employing IT personnel or engineers; HR will employ a NetProfessional+SecProfessional+MCSE instead Netprofessional+Secprofessional while they need a NetProfessional only.

But that does not mean one is bad and other is good. %85 of the market is fine with the understanding I described above, while %15 like government and military employ the device, the personnel which/who is best at its profession. They would prefer a CCIE Sec + CISSP over a Quintuple CCIE when their need is Security. Or Cisco leaves the antivirus part of their architectures to TrendMicro, web filtering to Websense, which are the best of their industry and gets only 5 ICSA labs certification, and more expensive, while Fortigate does everything itself alone and gets all ICSA certifications, but cheaper. That discussion lasts forever between a IT Specialist and Sales Specialist, any way lets get back to track :)

[husycisco]

Well the "design" thing is totally notional. I respect to your opinions, but I can come up and say I will build a pure perimeter security device, and my algorithm I call Adaptive Security Algorithm will have stateful packet inspection as its base. Admin will tell me which interfaces I should trust and which I wont and I will block flow by default. Only initiator and its return traffic will be permitted. I create the device and I am the god early in time, special thanks to SPI. Everybody likes my product except blackhats. That was a nice hammer on their possible Layer2 to 7 approaches on vulnerabilities of my perimeter. Time passed, someone came up with a research that showed %70+ of attacks were originated from secured networks. What the hell? How? Above described made blackhats evolve and invent techniques on data layers. SPI, My firewall excellently covered perimeter that forced them to change theirs, thus the security market's, perimeter point security approach to a network to host approach. Man my device can only inspect L7 data and see if protocols are used RFC compliant but nothing more. Trusted network gets infected, thus lower sec networks get infected. Now my design became “stupid” ? Hell no! The approach on vulnerabilities changed so that now made whitehats to evolve, and Defense In Depth approach on securing is born. My device at perimeter + a device that can deeply inspect in broader criterias and determine whats going on in data packets (IPS) + a software installed at host (HIPS) or an antivirus. If applicable and suitable for campus design, here I have AIP modules for the device to overcome that. Yet, if you don't like the sec-level design, then simply assign same sec levels to all interfaces, allow same sec traffic, and live your life traditionally.

Personally, I expect ASA to protect my perimeter, and I am fine with what it does. I as Security Admin, has to adapt my ASA to my security backbone by configuring it accordingly. I would sure welcome any additions to device software/hardware but cant expect it to change its algorithm that its built on entirely, everytime approaches change.

[whanson]

you have a wealth of understanding on the NAT aspects. Have a new one for you, Customer has a VPN concentrator hanging off of a dmz port of ASA. They now want the vpn concentrator site to site tunnels moved to the ASA. Interesting though for one tunnel they have a static for the inside to the dmz of 172.x.x.5 10.0.0.60. so when 10.0.0.60 goes out it ends up at the concentraor as 172.x.x.5.

to duplicate this on the ASA will this work.

nat (inside) 99 access-list towhereever

global (outside) 99 172.x.x.5

access-list towherever permit ip host 10.0.0.60 host 172.30.1.1 (which is the ip address we are attempting to get to at the other end. thx again