0

I'm new to networking and I've got a lot of the basics down, but I don't understand how the internet couldn't obtain direct contact with your devices on your local area network.

I know routers and NATs allow all your devices to have the same IP for your network, and it routes the requests out to the web and back to the client that requested it, but my question is this:

Say I wanted to hack someones computer and I knew his home network (router) IP. Couldn't I just transmit data to that IP with data encoded to go to some of the most common private addresses (192.168.1.1-80 for example) and actually get data sent to a "private" device?

IP's typically take data directly to and from the devices that made a request, so if I knew a router IP and guessed correctly at the private IP, what's to stop me from hacking in to that device?

I'm assuming there's another means to route data to the correct client happening in the router/NAT that isn't just IP, but I'm not sure how this is done.

Or is it simply that you COULD send ill-intended data this way, but there would be no benefit if all the software doesn't do anything with the data anyway (didn't send a request).

Any info I find usually just talks about how private IP's allow less public IP's to be used overall, and never really mention what cuts off access to your private IP clients to the outer world.

Can someone explain this to me?

  • When router NATs a packet it memorizes (sourceIP:sourcePort, destinationIP:destinationPort) in session table. When the answer obtained it is transferred according to memorized info. If no records found in session table, router drops the packet as a mistakenly received. So it will not be transferred into private network. – Akina Aug 8 '18 at 12:40
0

I don't understand how the internet couldn't obtain direct contact with your devices on your local area network.

IP's typically take data directly to and from the devices that made a request

Keep in mind that the original design of the Internet is that this is the way things are supposed to work - the Internet is supposed to be "end-to-end" and IP addresses are supposed to be literally global - as in no matter where a given IP address is in the world, I can talk to it and it can talk to me.

The problem is we ran out of IPv4 addresses so schemes like NAT had to be used.

NAT was not the way things were supposed to work, and while it has security benefits as a side effect, it breaks the end-to-end principle of the Internet and encourages services that do nothing but act as middlemen - good for security/rent collection, bad for freedom/poor people.

I know routers and NATs allow all your devices to have the same IP for your network

It only appears this way outside of your network.

Behind your network, each system has a unique IP - from one of the private IP ranges.

NAT manages this illusion at your router so that systems behind your router can reach out to other IPs, and IPs can talk to systems behind your router if ports are forwarded properly.

Couldn't I just transmit data to that IP with data encoded to go to some of the most common private addresses (192.168.1.1-80 for example) and actually get data sent to a "private" device

Nope.

192.168.1.80 doesn't exist on the Internet. It only exists behind NAT routers. You have get behind a NAT router first. The only way to do that is talk to the NAT router's public IP first.

As a matter of fact - if that IP 192.168.1.80 and your own IP is in the same subnet, what will happen is that traffic won't even leave your network - your system will try to reach 192.168.1.80 out of the local NIC and it won't even reach your router.

so if I knew a router IP and guessed correctly at the private IP, what's to stop me from hacking in to that device?

NAT routers monitor and track incoming connections.

If a new TCP connection is trying to connect to a forwarded port, then and only then will they forward the data to the system behind the router.

UDP is connectionless, so a NAT router, if it's doing its job properly, will not forward UDP traffic it hasn't seen in a while to a system behind it. It's possible to trick NAT routers with UDP due to its connectionless nature, but only if you can first get the system behind it to send something on that port and convince the NAT router that incoming traffic might be coming back. There's a few protocols that depend on something like this, like STUN, for example.

0

Just because you knew the router public IP address as well as an internal address doesn't automatically make the internal address publicly addressable.

IP allows you to connect to a public address, it doesn't automatically imply that there are addresses behind that public address or provide any means to forward data on even if there was.

The address is "go to this machine and this port", not "go to this machine and port, and once there forward on to another machine and port, and from there this other address and port"

Think of it as someone sending you a letter. The post office doesn't care about who is at the address, just that they put the post in the right slot. If the post he is through the slot then someone at the address must look at the letter and figure out who the letter needs to get to.

The same happens in a network, but NAT does not allow "Jim" as a permanent internal address, the internal to external mappings occur when something internal to the network reaches out to the internet requesting a connection. At that time it effectively creates a mailbox "jimTmp12345@PublicIP" which is used until the connection closes at which point the address is invalid and anything addressed to it is dropped in the local landfill.

0

Most NATing routers will also be configured to act as a firewall, not just a router.

Consider the following network:

example network


Without NAT, the devices must communicate directly:

  • 192.168.1.2 wants to talk to 192.168.0.2
    • Its default route is 192.168.1.1 (Router A)
    • Router A knows that 192.168.0.0/24 is reachable via 198.51.100.2 (Router B)
    • Router B is directly connected to 192.168.0.0/24 and delivers the packet
  • 192.168.0.2 wants to reply to 192.168.1.2
    • Its default route is 192.168.0.1 (Router B)
    • Router B knows that 192.168.1.0/24 is reachable via 198.51.100.1
    • Router A is directly connected to 192.168.1.0/24 and delivers the packet

With NAT on router A, but not router B, things change slightly:

  • 192.168.1.2 wants to talk to 192.168.0.2
    • Its default route is 192.168.1.1 (Router A)
    • Router A is configured for "IP masquerading", so rewrites the source address as 192.51.100.1 (it's external interface)
    • Router A knows that 192.168.0.0/24 is reachable via 198.51.100.2 (Router B)
    • Router B is directly connected to 192.168.0.0/24 and delivers the packet
  • 192.168.0.1 wants to reply to 198.51.100.1
    • Its default route is 192.168.0.1 (Router B)
    • Router B is directly connected to 198.51.100.0/24 and delivers the packet
    • Router A reviews it's translation table, and rewrites the destination as 192.168.1.1
    • Router A is directly connected to 192.168.1.0/24 and delivers the packet

At this point, there is nothing to stop a host from using 192.51.100.1 as a router, and asking it to forward a packet to 192.168.1.2... Nothing. Responses are likely to be masqueraded, so communication might be a little "challenging", but communication is communication.

Expanding this out to "the internet" might change my "There is nothing to stop..." statement somewhat. I don't have supporting materials, but I would be very surprised if internet routers were actually configured to forwarded traffic targeted at a private network address. Instead they will likely just drop such packets. The upshot is that trying this on the internet isn't likely to work, even if the router was poorly configured.

In addition to this again, because of how routing works (i.e: if a host isn't on the local network, the MAC address targets the router, while the IP address targets final host), there isn't a way to make use of 192.51.100.1 as a router unless either A) you are connected to it; or B) existing routes will push your traffic in its direction.


To prevent other hosts from simply using 198.51.100.1 as a simple router, firewall rules are required.

One approach is to reject (or drop) incoming packets at Router A's external interface (198.51.100.1) that are not explicitly targeted at its address.

This will also resolve the weak-host model that Linux implements (e.g: Router B can communicate with Router A via it's external interface, using the address assigned to the internal interface).

0

[NAT] routes the requests out to the web and back to the client that requested it

right, but as a point of clarification on how that works: NAT causes your private IP addresses to look like a public IP address, typically before the traffic leaves your network. So, the web doesn't route the traffic back to your private IP address. The web returns the traffic to the public IP address where you are seen.

Issue number 1:

I think if you understand how NAT works in detail, this will help answer some of your questions. The most typical implementation that I've seen is NAPT ("Network Address Port"-based Translation). When you send data from a private address, the router takes that private address and adds that information to a chart/table in the router's memory. The router also chooses a TCP or UDP port number (probably selected rather randomly), and keeps track of that in the same chart/table. The router then sends the information to the Internet using the public IP address, and identifies the "source port" number as the number it chose. (Both TCP and UDP use two port numbers: a "source" number, and a "destination" number.) When the destination (say, a web server listening on TCP port 443) notices the traffic going to TCP port 443 and coming from a different TCP port (e.g., TCP port 53874), that server may reply by sending traffic back to the originating router's public IP address on that same TCP port (e.g., TCP port 53874). The router then looks up information in its table/chart, and knows which private IP address to send the information to.

If you just chose a private IP address at random, the router should not have that private IP address in its table/chart, so that wouldn't work.

I'm assuming there's another means to route data to the correct client happening in the router/NAT that isn't just IP, but I'm not sure how this is done.

No.

I mean, well, yes, there is. There is some other routing that can occur, and so I will just quickly acknowledge that. There's use of 802.1q "VLAN" tagging and other technologies that can be used for some data/signaling clouds, and could impact how traffic ends up travelling through a network. However, those additional routing methods are typically deployed for purposes of speed, security, or compatibility (mainly with non-IP networks, like maybe some older networks inside a phone company). You don't really need to think that these advanced professional-level networking techniques are going to introduce a new and necessary part of understanding how basic routing works, because basic simple IP routing can be used to explain what you're asking about.

Issue #2: The router's internal defenses

Now, let's just pretend like the router isn't performing NAPT, so we're just going to ignore the whole table/chart that matches public TCP/UDP port numbers to private addresses. Let's just pretend like you're sitting at the customer's ISP, and want to maliciously send the packet through the router to the customer's private IP addresses.

Most routers, performing some very basic firewall-like actions, will notice that the incoming traffic is arriving on the port labelled "WAN" (which stands for "Wide-Area Network"). To provide some protection, the routers will realize that incoming traffic on that network port should be using the router's public IP address, and certainly not any of the common "private" IP address ranges.

So, the router will defend the network by dropping the packet.

Issue 3: ISP's protect us better

The standard for any ISP is to not allow any traffic to or from the private IP address ranges (which are the network address ranges identified in IETF RFC 1918 Section 3 for IPv4, or addresses starting with "fd" for IPv6).

So, if you are trying to send traffic from your home, through your ISP, and then through the rest of the main Internet backbone of ISP's, then through the victim's ISP, then through your victim's router, and finally to the "private IP" address of your choice, then you ought to fail. This is because ISPs typically follow the convention of blocking traffic involving the private IP addresses. (ISP's would be crazy not to do this.)

In the above scenario, the protection isn't provided by the target victim's ISP. Granted, the target victim's ISP is likely set up to drop the packets, thereby protecting the target victim's router. However, your ISP is also likely to drop the packets, so the packets won't even reach the target victim's ISP.

Issue 4: ISP Motivation

Why would ISP's would be crazy to allow traffic involving private IPs?

Well, keep in mind that all organizations are allowed to use the private IP addresses for their own internal networks. That includes ISPs. Your ISP might be using private addressing for some of the ISP's local equipment. You shouldn't be able to notice/detect whether they are doing that or not.

The way that ISP's route traffic is that they rely on "routing tables" that determine where the traffic should go to next. These "routing tables" do not specify which other ISP will be happy to receive traffic that has a private address as a destination. The ISP will have nowhere to send the traffic to, except possible to some of its own internal equipment. Since a lot of traffic involving private IP addresses are likely to be malicious or otherwise problematic (perhaps involving traffic coming from a device that is set up incorrectly), the ISP certainly doesn't want such traffic to be sent to its own internal equipment (and possibly causing problems for the ISP). Therefore, the ISP will want to block packets going to a private address immediately, before allowing the traffic any further through the ISP's network.

If an ISP broke these rules, the ISP would likely be inviting malicious traffic that would likely have no effect (other than using bandwidth), but if there were any effect, that would likely be bad for the ISP.

Issue 5: What would really happen

So far, I've explained why the Internet will block the traffic. But let's look at what is really going to happen.

If you're sitting on your computer, and you decide to send a malicious packet to a private IP address, what's going to happen?

If the traffic got as far as your local ISP, that local ISP would block the traffic immediately, as already explained.

However, what's really likely to happen is that the traffic won't get as far as your local ISP. Instead, your local router will figure out what to do with that traffic.

If you are not using the same "private" IP address yourself, then your own router will probably not know what to do with the traffic, so the traffic will be discarded.

Otherwise, if you are using the same "private IP" address yourself, then you will likely be attacking a device on the network you are on. If you are the administrator of that network, then you'd be attacking your own network!

In any case, your router is not likely (when using common default configurations) to pass the traffic on through the Internet.

Review:

All of these issues are about why the Internet won't allow your attack to a private IP address. If you are actually on the same local network as your target, you might not even need to go through a router, so none of these defenses will be in your way. However, if you are located elsewhere on the Internet, these defenses probably will get in the way of an attempt to make such an attack.

Although you can violate certain standard rules with (at least some types of) routers that you may be able to control, other organizations are likely to also block private IP addresses, thereby effectively preventing attacks on remote systems.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.