Question about port scans

After all this studying, I'm feeling dumb. The whole CEH book assumes you can scan the pc, find out info, etc...but if the pc is behind a router which performs NAT (which almost all do now) then that whole concept goes out the window, right? So what do you do...?

Find more posts tagged with

Comments

JDMurray

What you need to do is perform several recon "attacks" to discover the topology of the network behind the router. You first need to discover the IP addressing scheme and net mask of the segment(s). You can start by guessing they are using a scheme defined in RFC 1918, or even Microsoft's APIPA. Some people like to screw up the net mask by using classless addressing (e.g., 10.0.0.0/24), so consider that.

Once you know the IP address ranges, you can perform ping, UDP, and TCP scans to identify all network hosts. Chances are the private network will also be using a firewall, so your scanning won't work unless there are some pretty careless holes in the ACLs. ICMP may be blocked, so ping sweeps won't work. The firewall should also block all packets with internal IP addresses that are inbound from the public network.

If the firewall is setup properly, then sniff all in/outbound packets looking for unencrypted clues that can reveal info. You can get an idea of what ports are being used, and therefore what services are being run on the private network. Some of these services may have vulnerabilities that can be exploited.

You also need to try and determine if the router/firewall can be managed from the outside (public) network. You might be able to telnet into the router, or sniff an SNMP or HTTP management session, and pick up topology info (and possibly gain control and disable the firewall). Use a sniffer to see if any NetBIOS, CDP, or routing protocol packets are leaking out on to the public network and revealing any useful private network topology info.

I recommend the book Hacking Exposed, 4th ed., for some really good exercises and case studies on this subject.

/usr

Late reply...

What I was meant was, it is not possible to scan hosts when a router is doing NAT, even if you know the address range behind the router.

Webmaster

True, it is impossible to initiate a connection from the public side to the private side in a typical NAT config (public-private translation). If the hacker wouldn't give up because of that, he would try to hack the router first performing NAT first. Or, he would try to send Trojan Horses to implement malicious code on one of the internal clients that would initiate the connecting instead, allowing the hacker on the public side to 'reply'.

I honestly don't know how much the situation has improved since security became a hot issue, but I've encountered several networks where the external (border-) router was easier to attack than the average internal Windows NT file server.

/usr

Then again, web servers are more commonly hacked than internal file servers anyway...and you could scan those.

Usually any type of internal access will have to be done with some sort of social engineering. If you can port scan a companies internal machines, they are just asking for it.

Webmaster

LostInSpace wrote:

Then again, web servers are more commonly hacked than internal file servers anyway...and you could scan those./quote]Yes, and that's why companies really shouldn't attach webservers to their LAN or WAN unless they have a really good reason. Placing it at a decent host is often much safer.

Usually any type of internal access will have to be done with some sort of social engineering. If you can port scan a companies internal machines, they are just asking for it.

Yeah, with a decent firewall (i.e. PIX or Checkpoint) configured by a competent professional you have a lot less to worry about attackers using the front door to enter, by technical means.

JDMurray

You can try spoofing packets with common, private IP address ranges and seeing if the gateway device will pass them through. If the device isn't using SPI--or any kind of packet inspection at all--then that might be your ticket. ACL rules will also reject packets with private IPs as source IPs.

It's best to try discovering and compromising the border device and then work your way inward. Of course, even a little tickle on a router may trigger IDS alarms. Not knowning if the scanning is throwing alsrms that are noticed immediatly by a human is the part that always concerns me.

Ten9t6

/usr wrote:

After all this studying, I'm feeling dumb. The whole CEH book assumes you can scan the pc, find out info, etc...but if the pc is behind a router which performs NAT (which almost all do now) then that whole concept goes out the window, right? So what do you do...?

you are correct that nat'd addresses are not routable over the internet...others are correct about scoping out the boarder devices to see what they tell you. Even though they are performing nat, there are usually ports open that can be used to forward you to inside devices...all you have to do is find one hole and start working it. A lot of devices now come with a ingress filter for internal addresses.......

JDMurray

Ten9t6 wrote:

A lot of devices now come with a ingress filter for internal addresses.......

Yeah, it's simply too easy to construct ACLs in a firewall that do not permit packets that have internal addresses as source addresses to enter a private network.

I would attempt to locate any DMZ hosts behind the firewall that may have a trust relationship with the private (protected) hosts and work from there. (You gotta love the default, two-way transitive trust relationship in W2K AD. It made things much easier for the admins, but also for the crackers...

)

Ten9t6

yes...its always nice to find a domain controller out there...