Can an attacker "simulate" a private IP address?

Question

I have a SSH server with a rule that does not allow password connections outside the local network.

So people already on the local network, either physically or via VPN, are allowed to connect with passwords but connections from external IPs must use a key (the weaker security for internal IPs is ok because if the network is breached, that server does not matter any more).

Would it be possible for an attacker who does not have access to the local network to "fake" his IP address and pretend that it is in one of the private IP ranges (or could an attacker have an actual public IP that falls in one of those ranges)?

Answer 1

In short no. Because SSH runs on TCP (although there is a UDP version, this is unusual) a TCP handshake is required to commence the SSH protocol's own authentication and its following communication. A private address will not cross your perimeter router to and from the public internet so any spoofing of an internal address as it comes inbound (assuming no anti-spoofing on the router or firewall which is a common security measure) will result in the SSH terminating server attempting to reply to that internal address and it will never get back out to the public internet and the attacker's own computer. No connection can be established.

Answer 2

Before the attacker can send any data to the SSH server, he has to complete a TCP handshake. This means the attacker has to guess a 32 bit sequence number. (If SYN cookies are used, the attacker's chances may improve.)

Assuming your server is generating good sequence numbers, this will significantly reduce an attackers ability to attack your SSH server using a spoofed client IP address.

But maybe you don't trust your server to generate good sequence numbers, or maybe you think 32 bit of security isn't good enough. So you might still want to know, what would happen once the attacker guessed a correct sequence number.

First of all we notice that the attacker will be able to figure out whether a guessed sequence number was correct or not. A correct guess will cause a connection to be opened, so it will count towards the limit specified using MaxStartups. The attacker can attempt to open another connection using a non-spoofed address in order to find out if that limit has been reached. He can keep your server just below that limit at all times, such that a successful connection with a spoofed address would always take the last available connection.

Without the trick to notice a successfully guessed sequence number, the attacker would have had to send password guesses in the blind without knowing whether the connection they were send across even exists. That could potentially have slowed the attacker down by a factor of 2³².

But even though an attacker can get feedback to indicate whether a sequence number was guessed correctly, there are other roadblocks preventing password guessing on a spoofed TCP connection.

During key exchange both client and server will choose a random value to be send over the connection. These random values influence the session key. This means an attacker working in the blind (because he doesn't see replies send from the server to the spoofed IP) will not know the session key.

The lack of knowledge about the session key means the attacker will have to guess a message authentication code. This is essentially equivalent to performing a MITM-attack on a legitimate connection. Additionally, the attacker has to send the password encrypted to be decrypted by the server. Since the attacker don't know the encryption key in use, he will not know which passwords he has tried.

The time window for the attacker to complete the attack only lasts until the spoofed IP address has replied with a TCP RST packet. Since the roundtrip time between attacker and server is likely going to be larger than the roundtrip time between server and local addresses, this could prevent the attacker from using any sort of feedback including the verification of correctly guessed sequence number.

You can give the attacker a longer window to complete the attack by installing a firewall that prevent the SYN ACK from reaching the spoofed IP address or by preventing the RST from reaching the server. This does however not make the attack much more feasible.

Answer 3

The answer is yes, it is possible. However, there are some significant limitations. Through the use of IP spoofing, it could be possible to establish a connection which could be used to deliver a payload to the target, but it will not be possible to establish a true bi-directional TCP connection. In simple terms, the attacker can get the target machine to respond, but they will not recieve the responses as they won't be routed to them (this is why IP spoofing is more commonly used with UDP rather than TCP type connections). However, the attacker can simulate receiving the packets and send back fake acknowledgment packets and from there get to the point where they can potentially deliver a payload. This payload could theoretically be used to setup a trojan on the target which then calls out to the attackers C&C system, establihsing a connection into your internal system.

While this is possible, it is a difficult hack and may not be possible on all systems as there have been changes to how various platforms handle TCP connections which make it harder for the attacker to simulate the ack packets. Given all the recent disclosures about the poor security in routers, the much more likely attack would be to compromise your router and setup port forwarding or use UPnP to trick your system into initiating an external connection etc.