Scenario:
I have a router with a public IP address provided by the ISP and two hosts behind the router with a private IP (192.168.x.x).
Is it possible to perform a port or vulnerability scan of a private subnet behind public IP address?
Scenario:
I have a router with a public IP address provided by the ISP and two hosts behind the router with a private IP (192.168.x.x).
Is it possible to perform a port or vulnerability scan of a private subnet behind public IP address?
Yes, you don't need NAT, masquerading or even routing (but you do at least need HTTP proxying).
This tool uses websockets and ajax requests but it's possible to do with just img URLs. A simple Java applet will identify and report back the local IP address if you don't want to scan lots of adresses.
Usually, such networks are behind Network Address Translation (NAT). NAT waits for an internal system to send out a packet to a WAN address, then stores the route in a table. It alters the packet to have the router's WAN IP as the source address, and sends it to the internet. When the response comes back, it matches the incoming packet to a route. This is especially easy to demonstrate with TCP, where a connection has a sequence number that can be used to match the packets to the conversation.
The problem with accessing internal ports is that if a packet doesn't explicitly match a route that the router knows about, it is dropped. Note that port forwarding rules create their own routes, so the router knows to route incoming TCP / UDP packets to a particular internal IP. As such, it's quite difficult to enumerate internal IPs from the internet, let alone do port scans.
The only way I know of to do this is to exploit the router. Some of them have badly set up UPnP daemons, allowing you to trick the router into setting up port forwarding rules. There are some other ways to do this, usually via the router's control panel.
Aaron "finux" Finnon (@f1nux on Twitter) did a great talk about pwning UPnP at BSidesLondon earlier this year: http://www.securitytube.net/video/4140
Short answer: No.
Long answer: Possibly. It depends.
NAT routers work by monitoring outbound traffic and creating rules on the fly to send incoming traffic to where it needs to go.
For example:
All other incoming traffic is dropped by the NAT router.
In some cases, machines on the internal network need to be able to accept incoming packets from the external network, without knowing anything about the external machine beforehand. For example, I might set up a web server on 192.168.1.2:80, but want it accessible from the external network. This is facilitated by port forwarding.
Port forwarding adds a permanent rule to the NAT forwarding rules, such that traffic from all (or a preset list of) IP addresses to a specific port is sent to an internal IP address. In the above case, I might say that anything coming to my router on TCP port 80 should be forwarded to 192.168.1.2:80.
This doesn't offer up a vulnerability in itself, but it leads to one. A lot of games and communications software (e.g. IM, VoIP, etc) require incoming connections to be accepted. Because most consumers don't know how to configure their router, and it becomes a hassle to manually enter port forwarding rules every time you install a new game / program, routers needed an API that allows for automatic configuration of these rules. The most popular API for this is UPnP (Universal Plug-n-Play).
UPnP allows a program to tell the router to add a UPnP port forwarding rule. Most routers specify some restrictions on this, e.g. maximum time that a rule may exist before the program needs to renew it, but in general it's pretty lax.
The API works over HTTP, so it's relatively easy to implement in most languages. It also doesn't require any authentication beyond "I have an internal IP address", which means that cross-site AJAX, HTML5 web sockets and even iframes created within a browser may have the ability to set up port forwarding rules. This usually requires a bug in the browser's same-origin policy, but it's certainly possible for an attacker to leverage this to create arbitrary port forwarding rules. These could be used to fingerprint your internal network. They could also use web sockets to fingerprint your internal network directly, by getting you to visit a web page. Of course, the scan would be interrupted when you closed the page. symcbean's answer shows a practical example of this.
The other issue is that UPnP is sometimes implemented on the router in a rather sloppy way. Certain routers allow some crazy things to be done via UPnP without authentication, e.g. turning off wifi, resetting the device to factory settings, flashing firmware. I even found a router that would tell you the wifi SSID and password in cleartext if you sent a certain UPnP request. In fact, in some cases routers allow "limited" UPnP access from the internet-facing side too. It's bizarre and terrible security practice.
As soon as the address is reachable from your network, yes, you can scan ports from a remote network. Of course, equipments between you and your target machine (firewalls, most notably) will influence the results.
If the target IP address is not routable on the internet, then it may or may not be possible to perform a scan on some ports. It all depends on the configuration of the NAT server (and firewall) between the target LAN and the Internet.
There are specialized websites (like this one) for this if you don't have a source machine on a remote network. Of course, to perform such a scan you should have an authorization from the target system owner/admin, if it's not you.
Assuming that you have a public IP address, with a 192.168.x.x private subnet using dynamic NAT to translate the private IP addresses to the public IP address, there is no way for an attacker to do a port/vulnerability scan of your private subnet from the internet.
You should examine a technique called Firewalking, the original paper, and another paper.
Yes, but only if you have a port forward (DNAT; D = destination), which will expose one port (and therefore service if something is listening) on one of the internal hosts (in a simple setup). To scan your internal network, the attacker would need to somehow establish a connection into your internal network through exposed services (VPN, SSH) or even web server or other services, if there is a vulnerability.
*:80 -> 192.168.1.2:31337
Commented
Jul 5, 2012 at 15:35