NAT & non-RFC1918 addressing

rrgb_security · ‎12-04-2003

Well the title probably didn't make much since, but I'm looking for help understanding the following method of configuring a PIX that I recently ran across....

%75 of LAN systems do not use restricted subnets as defined by rfc1918 (10.x.x.x, etc.), remainder do. The larger portion of systems noted above contains all of the critical business apps/servers, etc.

The PIX is configured similar to this;

global (outside) 10 xx.xx.xx.10

nat (inside) 10 hostname mask 0 0

static (inside,outside) xx.xx.xx.10 xx.xx.xx.10 netmask etc. etc.

static (inside,DMZ) xx.xx.xx.10 xx.xx.xx.10 netmask etc. etc.

Yes, a LAN system configured with a routable/registered IP address is being statically mapped back to itself.

The above configuration goes on for basically another 150 hosts.... Is it safer than it appears to me, or am I just nitpicking?

I look at that and think, if I know the IP and try a couple open ports, and get lucky.... That remote system might as well consider themselves exposed to threat.

Thoughts, ideas?

rgrcommo · ‎12-04-2003

So you have an IP on a LAN that is not RFC 1918 Just one PC or the entire LAN?

so WAN---->PIX---->LAN-->non-RFC-1918-addrs?

The PIX is double nated then back to the LAN? If you try a couple of ports lets say w/ Nmap and you have ports open in the ACL for the IP - yes it will see them if you have "ANY" being able to access that IP thru that port.

The PIX has the door open for that service so it will just let it pass right thru. Do you have a perimeter router in front of the PIX - you could put CBAC on that and filter the ports then have it goto the PIX etc.. I would like to hear more about exactly what you’re trying to do etc..

Jeff

rrgb_security · ‎12-04-2003

Inet-router-->PIX-->LAN

%90 of all hosts within first two hops of the PIX's Inside interface are using real world IP's (not compliant with rfc1918).

Roughly 40 Srvrs, 300 users, and if RAS is counted (RAS users also recieve real world IP upon dial-in) you could tack on another 1500 accounts.

As for double nat'ing... Got me at this point. This is part of a system I've been tasked with assessing (Risk, BC, Cap. & Performance, etc.) and the firewall has me a bit perplexed. I understand the PIX, nat/pat, global, static, etc. But used in the manner in which they are....??

I've ran a few different port scans and such on it, and the results were as expected - able to touch open ports and the actual client system - occasionaly up to 4 or 5 hops deep into the private network.

There is a perimeter router, of sorts, but I've yet to get a glimpse at it's config - that shouldn't take long tho, since an SNMP walk picked up all of the routers info (uh.. is anyone home?).

So I gather from your questions and correct presumptions, that my initial (churning) gut feeling is correct;

client system: ip addr 207.63.29.230 open ports=21,23,25,80,443

PIX: 207.63.29.10 (inside int) 207.63.1.200 (outside)

207.63.2.1 (DMZ)

using the existing nat commands: static (inside,outside) (and inside to DMZ on the next line) 207.63.29.230 207.63.29.230

Config looks to contain static entries for all local subnet hosts, and NATs the remaining hosts on further subnets...

That make any more sense?

rgrcommo · ‎12-05-2003

Hi,

Your exactly right - even if all the hosts hanging off the inside were RFC 1918 but still had ports open -services running i.e smtp,www,pcanywhere etc and the PIX ACL has ACE (Access Control Entries) providing access to those ports from anywhere or even certain hosts out there in the internet then they will be easily scanable by an intruder checking your block of IP space.

So, if someone uses nmap and scans 207.63.29.0/24 for pcanywhere vulnerabilities on the inside interface port tcp 5631 and like you said he/she will see that host come up as being "open" - again the pix will just let it pass right thru to the host.

Even if the PIX is nated or double nated back to a host off the "inside" interface and the ACE entries are like:

access-list permit_out_inside permit tcp any host 207.63.29.11 eq www

access-list permit_out_inside permit tcp any host 207.63.29.11 eq smtp

access-list permit_out_inside permit tcp any host 207.63.29.11 pcanywhere-data

access-group permit_out_inside in interface outside

They will be able to see that host by scanning just that IP even if the PIX is in the middle.

You could implement, if design permits what is called a “Firewall Sandwich” an FW IOS router on the "outside" interface and a FW IOS router on the inside interface:

Internet---->FWIOS_rtr---->PIX----->inside_net--->FWIOS_rtr---LAN

These two FWIOS routers should have IDS along with CBAC on them to filter traffic as needed before going to the PIX and the inside net. The one on the "inside" also protects unwarranted traffic from returning back to unauthorized hosts on the outside etc..

Each design case is different and your policy may not allow this but it will help in the prevention of scanning hosts like in your case.

You could start by using or fine-tuning a CBAC configuration on a FW IOS router on the "inside" interface of the PIX -making sure outside hosts only connect with valid TCP connections and only certain traffic can go back to the "outside". This would be the lower cost alternative.

- Hope this helped

Jeff

l.mourits · ‎12-06-2003

The PIX is configured similar to this;

global (outside) 10 xx.xx.xx.10

nat (inside) 10 hostname mask 0 0

static (inside,outside) xx.xx.xx.10 xx.xx.xx.10 netmask etc. etc.

static (inside,DMZ) xx.xx.xx.10 xx.xx.xx.10 netmask etc. etc.

Yes, a LAN system configured with a routable/registered IP address is being statically mapped back to itself.

You do understand what static command does on PIX?

Not only does it do translation, it also provides proxy-ARP. It does not give access, this is done via the ACL´s or if no ACL exist via the securitylevels.

Looking at the particular config you provided I assume that your servers which have to be reachable from the outside reside on the DMZ. Then config is indeed strange. You would expect static (outside, DMZ) in that case for all systems that have to be reachable.

The above configuration goes on for basically another 150 hosts.... Is it safer than it appears to me, or am I just nitpicking?

Well, safety is more depending on ACL and securitylevel then on translation rules used on the config. But I agree this config does not make much sense.

I look at that and think, if I know the IP and try a couple open ports, and get lucky.... That remote system might as well consider themselves exposed to threat.

If you are finding open ports which should not be open then there must be an ACL or securitylevels are not correctly set.

I've ran a few different port scans and such on it, and the results were as expected - able to touch open ports and the actual client system - occasionaly up to 4 or 5 hops deep into the private network.

Sounds like someone did configure this PIX while not knowing to much about it.

There is a perimeter router, of sorts, but I've yet to get a glimpse at it's config - that shouldn't take long tho, since an SNMP walk picked up all of the routers info (uh.. is anyone home?).

*sigh* No further comments needed

As I understand there´s no need for translating, since inside systems all use private adresses. If this is the case, and all hosted systems are on the DMZ, the better way to configure this would be:

nat (inside) 0

:only needed if systems on the inside need to initiate sessions

nat (dmz) 0

:only needed if systems on the inside need to initiate sessions

static (dmz, outside)

:you can safely put in the whole range within one command, cause

:ACL determines which traffic is allowed.

:this static is needed for sessions initiated from the outside to the

:dmz, cause the static does also provides proxy-ARP

:if your systems on the dmz need to initiate sessions to the

:inside (not recommended) you need to setup a static (inside, dmz) also

Kind Regards,

Leo

rrgb_security · ‎12-07-2003

Thanks for the info Leo, it was all very helpful. I'll respond, and please let me know if the additional info changes the situation at all.

1. My level of understanding of the static command:

I have a good grasp on it, but am no expert; have a couple years exp. on the pix, mostly in OJT mode. Your definition confirmed my thoughts and the static commands are listed correctly in my previous post.

2. ACL's are abundent in the pix cfg. So many it took my a few solid hours just to map out exactly what was allowed to come in and to where (due to Names, object-groups, and such) - that was for the outside to Internal Lan (not DMZ) ACL alone.

3. Re: servers reside in DMZ and expected (outside,dmz) acls:

Yes, systems in the DMZ require external access, and yes (outside,dmz) acl group exists and configured appropriately (I haven't dug into that one much yet).

However, I also wanted to point out the reason I posted on this config (my fears) where because the 150 or so systems I mentioned being static translated, are nearly ALL in the LAN (inside interface, and it's probably like %95 of the systems rather than %100).

4. re: ACLs and port scan findings:

SecurityLevels set to defaults, but I believe the first ACL entry basically shuts that statement off... Either way, an example of a port scan done externally, on an internal system (LAN port not DMZ) returned 5 TCP ports open - mostly standard, and 521 open UDP ports.... But only like 12 of those had any kind of hostile risk associated. Still, that's scary.

5. Final questions and examples:

No, inside systems DO NOT use private addressing (the straw that broke the camesls back so to speak) - only about %15 of the internal LAN uses private restricted IP, the rest use the same public routeable IP address (recv'd from ISP), what are the same, on a host by host basis, addresses that the global and static commands translate the inside to outside ACL with.

Example: internal lan pc = x.x.x.4 (ISP, public subnet) translated to x.x.x.4 to the outside int.

ACL's are pretty locked down, but I have been unable to find any statement similar to acl(outside,int) TCP (or IP, etc.) Deny ANY ANY.

All that above is what got me concerned - Win Srv on Internal LAN, NOT using private IP, with standard ports open through PIX, and pix is doing either nat or static but the addresses are not changing, it's the exact same before and after.

In my opinion, that config is begging for trouble... just wanting to verify before I open my mouth.

Thanks again,

Clint

l.mourits · ‎12-08-2003

Clint,

Config seem to s*ck indeed :-)

Don't know if you could grab the config, remove passwords and real IP's and mail it to me? If so, I can have a look at it later on this week if you want.

If you see UDP ports open, they have to be open in config somewhere. PIX does not open ports if not cofigured. Only in case no acl is bound to an interface and packets travel through this interface to a lower security interface all traffic is permitted, but as soon as an acl is bound to any interface the securitylevels do not have any influence because of the implicit deny any any at the end of each acl (same as in IOS), that's correct.

I have some tips for you based on your follwoing statement.

ACL's are abundent in the pix cfg. So many it took my a few solid hours just to map out exactly what was allowed to come in and to where (due to Names, object-groups, and such) - that was for the outside to Internal Lan (not DMZ) ACL alone.

<\quote>

If you use show config you will see configured access-list and object-groups and (indeed) this can be very time consuming to read.

You could go into config-mode and issue the command "no names" which will get rid of the names if a show config is executed. The command "no names" does not effect the operation of the PIX.

If you use show access-list instead of show conf the PIX will show you the parsed access-lists including how many hits on each line. In this case you will see much easier what exactly is configured within you acl without going to all object-group commands.

Could save you several hours of time and making less mistakes :-))

Hope this helps and keep me posted,

Leo