Firewall / NAT question/

Printable View

August 18th, 2006, 06:33 PM
thatch

Firewall / NAT question/

forgive me if this question seems pretty basic but could anyone tell explain this to me.

i'm performing a practice assesment and i have located an IP of a web based mail server (OWA). this server is sitting behind a hardware firewall (say PIX or Checkpoint)that is NATing the IP Address to an internal non-routable address. Now, if i use a tool such as Nmap to scan that external IP are my scan results influenced by the Firewall. Do firewalls when NATing take all traffic from the external IP and pass it to the internal nertwork and expect the server to have the remaing services closed down or do they only take traffic destined for a port and drop everything else. if it's the later, when i scan am i only scaning the 1 port that is allowing traffic to be forward to it?

Is there a way of determining if the firewall is blocking the traffic to the other ports or if the Server has been locked down and is blocking them?

Any help would be appreciated.

Regards

Thatch
August 18th, 2006, 06:46 PM
spamdies

Quote:

i'm performing a practice assesment and i have located an IP of a web based mail server (OWA).

If your not the admin of that network or server it is not advised to run scans against it. Doing so can and usually does trigger IDS as well as show up in log files.
August 18th, 2006, 06:53 PM
morganlefay

Yes it does....and then report them also

:D

MLF
August 18th, 2006, 07:56 PM
ShagDevil

Quote:

Now, if i use a tool such as Nmap to scan that external IP are my scan results influenced by the Firewall. Do firewalls when NATing take all traffic from the external IP and pass it to the internal nertwork and expect the server to have the remaing services closed down or do they only take traffic destined for a port and drop everything else

I suspect that the firewall is configured to only allow specific traffic on specific ports. If that's the case, then I would say that the latter is true about the firewall allowing only specific traffic and dropping the rest.
Of course, if the firewall is poorly configured, then the former could be true and everything is passing through the firewall.

Also, you're throwing around two terms (NAT/Firewall) like they're the same in one. Are we talking about NAT or firewall rulesets?
August 19th, 2006, 02:11 AM
jockey0109

I think that it is not so easy to scan systems behind both a firewall and a NAt machine. This I think coz firewall will nt allow traffic to the ports it blocks. Now since you don't know the internal topology or configuartions of the network, it is pretty much that you wont be able to figure out things from the scan though NAT. Now again it depends on the firewall if it allows all trafic to pass to the network and I wonder if will continue to so if the IDS gets invoked / alert with the scan.

You might be even redirected to a honeypot if they are configured to do so. I dunno this is possible or not...but it should be possible in most cases.
August 19th, 2006, 04:03 AM
Tedob1

Re: Firewall / NAT question/

Quote:

Originally posted here by thatch
forgive me if this question seems pretty basic but could anyone tell explain this to me.

i'm performing a practice assesment and i have located an IP of a web based mail server (OWA). this server is sitting behind a hardware firewall (say PIX or Checkpoint)that is NATing the IP Address to an internal non-routable address. Now, if i use a tool such as Nmap to scan that external IP are my scan results influenced by the Firewall. Do firewalls when NATing take all traffic from the external IP and pass it to the internal nertwork and expect the server to have the remaing services closed down or do they only take traffic destined for a port and drop everything else. if it's the later, when i scan am i only scaning the 1 port that is allowing traffic to be forward to it?

Is there a way of determining if the firewall is blocking the traffic to the other ports or if the Server has been locked down and is blocking them?

Any help would be appreciated.

Regards

Thatch

your scan is not only influenced by the fire wall...your scanning the firewall. if a webserver is natted threw it will show as coming from the F/W ip.

the fire wall shows only services that are mapped to it as open but it also gives the same IP as the fire wall. lets say the internal addresss of your webserver is 10.192.62.70 its going to show as the external address of the firewall..thats the purpuse of a f/w...to not show the underlying network. so for instance if your f/w's externel addy is 62.69.110.54 thats going to be the addresses of the server on the internet and the internel address does not affect anything. all traffic to 62.69.110.54 port 80 is mapped to 10.192.62.70. so that would make the external address of your webserver 62.69.110.54.

there are ways around this to map an internal network from the firewall but thats not what your asking and the web server can be hacked from the outside using the external address of the firewall by any bad code written into ithe server pages or the server os itself..like un-sanitised sql querries or missing patches and if its on your network and not in a DMZ just say goodbye to the security of your whole network.

"Is there a way of determining if the firewall is blocking the traffic to the other ports or if the Server has been locked down and is blocking them?".. if you see "denied" or even it thry are just droped thats whats supposed to happen with a fire wall. there are just so many variables and i honestly dont know what answer your looking for.

hope this gives you a clearer picture
August 19th, 2006, 09:44 AM
thatch

I appreciate the replies guys. i should have stated in the origional question, i am the administrator of the network in question and i'm aware of the topology of the network i'm scanning, but i'm trying to learn more about the way a firewall treats the incomming traffic destined to my internal servers or those on my DMZ. i have a OK understanding of the firewall but i didn't set it up. my practice assessment was from the standpoint of an attacker (obviously a newbie attacker as my security skills are still in the early development stages) that had no knowledge of the setup of the network. Anyway, i'll keep reeading and googling i'm sure i'll get there soon.

Thanks again

Thatch
August 19th, 2006, 11:49 AM
thatch

Further to my last reply. i thought about the issue and decided to try the following to see if i could identify whether the firewall was blocking my packets or the server had the ports closed.

i fired up Wireshark and the set a scan going using another tool then looked at my responses in wireshark. i could see that the responses from closed ports were all coming from a source that was a cisco device (which i know to be my firewall). when i performed the same technique on another server i got the same.

Is this technique sufficient to prove that i have identified that the servers are behind a cisco firewall that is NATing addresses and only allowing traffic through on certain ports? or am i missing something obvious that would mean this technique is only valid in this situation?

regards

Thatch
August 28th, 2006, 11:05 AM
Nokia

All you have to do is check the ACL's of the firewall to see what it is allowing through.

Just because it is NAT'ed does not mean traffic is allowed through, it has to be explicitly allowed from the outside to the inside.

Take a PIX for example - out of the box it will allow any traffic from the INSIDE to the OUTSIDE interface - obviously you will need to assign IP addresses to the interfaces first and place a NAT rule if you want to NAT it.

S0, say you static NAT and internal IP to an external one, so:

Code:

pix#static (inside,outside) 80.0.0.1 192.168.2.1 netmask 255.255.255.0

Would place a static NAT saying incoming traffic destined for 80.0.0.1 will be sent to 192.168.2.1 and out going traffic from 192.168.2.1 will be translated to 80.0.0.1 at all times.

If the NAT was dynamic the connection would have to be initiated from the inside - if a connection arrived out of the blue for 80.0.0.1 it would be dropped unless the original connection came from the inside.

So the NAT is in place but, remember traffic is not allowed from the outside to the inside by default - with the above being a Static NAT it will accept the incoming connection (in other word will not drop it straight away) but the first thing it will now do is check for a valid ACL saying that the traffic is allowed.

So an ACL such as:

Code:

pix# access-list ACLNAME permit tcp any host 80.0.0.1 eq www

Would allow and TCP connection destined for 80.0.0.1 on port 80 that is HTTP traffic from any host through the firewall.

SO traffic would arrive out of the blue destined to 80.0.0.1, the PIX would first check if there is an outbound connection already established, if so and if it matched all the right criteria it would be allowed through. If there is not an outbound connection already up it will then check to see if there is a static NAT in place, if there is not the traffic is dropped, if there is the PIX then checks for an ACL to see if the traffic is allowed. If there is an ACL it will abide by what it has been told to do, if there is no ACL the traffic is dropped.

In our case we have permitted TCP traffic to port 80 on 80.0.0.1 and put a static NAT in place. Hence HTTP traffic from ANY IP address that is destined for port 80 on 80.0.0.1 will be allowed to pass through.

If you tried to FTP into it, as this would be destined for port 21 this would not match our ACL we have put in place so the traffic would be dropped instantly.

If you are using NMAP to scan 80.0.0.1 all probes to everything other than port 80 will be dropped by the firewall as there is no ACL to tell it what to do with the traffic.

When the probe comes in for port 80 providing the probe sends HTTP traffic it will be allowed through (notice we put 'eq www' in the ACL [equal to www] and not eq 80 [destined to port 80]) If we had put eq 80 ANYTHING destined for port 80 would be allowed in, with using eq www the firewall will perform deep level packet inspection and check it is HTTP traffic passing through. (Version 7.0(2) only)

I'm not sure if NMAP probes port 80 with HTTP requests or if it just uses normal TCP/IP type traffic? I suspect the Horse will be able to answer this! :D

As for your last post - it leads me to think maybe you are hitting a router with ACL's in place and not a firewall. The reason being is you said you are getting replies from a CISCO device - a PIX would not reply for the reason stated above, it would just drop the packet (unless it has been very poorly configured) a router with ACL's on the other hand would abide by normal TCP rules and send return packets to you.

Pinging is also a useless thing to do if it is a PIX, as a PIX can be configured in everyway possible to handle an ICMP request/echo. You can set it to answer all pings, drop all pings, allow pings through to internal hosts, allow pings through to specific internal hosts, allow pings through but not allow replies out etc etc

A bit late but I hope it helps!

:D
August 28th, 2006, 11:50 AM
SirDice

Quote:

Originally posted here by thatch
or am i missing something obvious that would mean this technique is only valid in this situation?

Yes, the obvious being layer2.. You're seeing the MAC address of the last router before your workstation..
August 28th, 2006, 03:36 PM
Maestr0

You can use TTL to determine if the packets are making it downstream of the firewall.

http://www.packetfactory.net/projects/firewalk/

-Maestr0
August 28th, 2006, 06:00 PM
IKnowNot

thatch, I think you got your answers, but I think everyone looked at this a little differently and answered accordingly.
Let me see if I can clarify:

Quote:

Do firewalls when NATing take all traffic from the external IP and pass it to the internal nertwork and expect the server to have the remaing services closed down

Depends on how it is configured, but usually no. ( it would actually be silly to do so. )

Quote:

do they only take traffic destined for a port and drop everything else.

For the purpose of this discussion, this is a more accurate statement. And, as you know, it may not be just one port to one machine. There may be additional services running on that box so there could be more then one port forwarded to it, and/or it could be to several different boxes for other services and/or load balancing.

Quote:

if it's the later, when i scan am i only scaning the 1 port that is allowing traffic to be forward to it?

Again, this has been answered, but yes, I think you have the idea.

Quote:

Is there a way of determining if the firewall is blocking the traffic to the other ports or if the Server has been locked down and is blocking them?

Yes and no.
No, because once the ports are blocked at the firewall the server will never see the scan if coming in that way.
You could have port 23 wide open on a server, but if you are scanning the perimeter ( from outside hitting the firewall box first ) and that port is blocked by the firewall, the port will appear closed from the outside when on the server it is actually wide open.
Yes, scan the servers from the other side of the firewall.

Quote:

i fired up Wireshark and the set a scan going using another tool then looked at my responses in wireshark. i could see that the responses from closed ports were all coming from a source that was a cisco device (which i know to be my firewall). when i performed the same technique on another server i got the same.

I am wondering here how you scanned the server and got the same results as scanning the firewall ( cisco device responding ) ... how did you scan the server, from inside, or still from the outside? If it was from the inside, is there another cisco device in between? Or, after understanding the other answers is this question now moot?

Quote:

Is this technique sufficient to prove that i have identified that the servers are behind a cisco firewall that is NATing addresses and only allowing traffic through on certain ports? or am i missing something obvious that would mean this technique is only valid in this situation?

I would say no, and leave you to think about this:
what if there actually is no firewall?