1

We had been testing an AWS instance accessing an internal Ubuntu 10.04.3 server, so had modified our firewall to allow all ports from that specific IP address to the server. We then released the AWS instance but forgot to remove the firewall rule.

Yesterday, someone noticed failed login attempts in auth.log which were coming from various China and Korea locations (according to whois.sc). So we removed the firewall rule, and the login attempts stopped.

Here's a section of auth.log showing a failed login attempt:

Feb 23 12:33:15 TestServer1 sshd[18822]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=117.21.226.10  user=root
Feb 23 12:33:15 TestServer1 sshd[18822]: pam_winbind(sshd:auth): getting password (0x00000388)
Feb 23 12:33:15 TestServer1 sshd[18822]: pam_winbind(sshd:auth): pam_get_item returned a password
Feb 23 12:33:15 TestServer1 sshd[18822]: pam_winbind(sshd:auth): request wbcLogonUser failed: WBC_ERR_AUTH_ERROR, PAM error: PAM_USER_UNKNOWN (10), NTSTATUS: NT_STATUS_NO_SUCH_USER, Error message was: No such user
Feb 23 12:33:17 TestServer1 sshd[18822]: Failed password for root from 117.21.226.10 port 2539 ssh2

Obviously, since the firewall rule was still in place for the AWS instance, it was letting traffic through for that IP, but I'm wondering how the external IP 117.21.226.10 was getting access to our internal server. Is that possibly a spoofed IP, and not the real originator? If that's true, doesn't it mean that Amazon allows spoofed packets on their network?

I'm not the network configuration guy here, and am wondering for my own benefit, so please excuse me if this is a noob question.

1
  • SSH is a protocol that runs over TCP and TCP connections can't be spoofed. That is the true IP your machine saw connecting to it. It might be interesting to see the firewall rule if you still have it. – Ladadadada Feb 26 '14 at 18:29
1

No, TCP connections can't be spoofed[*]. TCP requires two-way communication, so your response packets have to make it back to the source and be acknowledged before your connection can proceed. To you know with near certainty that you traffic is being sent to you by that address.

That said, you can't guarantee that the traffic is originating at the address in question. You just know that the address you found is the "last hop" that traffic takes before getting to you. Attackers will frequently bounce their connections off compromised servers or use hacked servers in other datacenters to conduct automated attacks.

So the address you see typically represents another victim of the same attacker whose resources are now being used to make the attacker's location.

[*] Technically you can spoof TCP packets, but to do so you have to be somewhere on the route that the TCP packets would have otherwise taken. So for example your ISP can spoof traffic to you from anywhere, but a server in Brazil communicating with you in Amsterdam would have trouble spoofing an address in China.

1

As Ladadadada said, the IP logged by SSH was indeed the attacking system's address.

I talked with our network guy and he had set up a One-to-One mapping of the AWS instance's IP address to an external IP in our firewall that pointed to our internal server.

192.168.30.36 <-- 123.123.123.123 (our external ip) <-- Internet <-- Amazon IP

He believes that when we released the AWS instance somebody later got a new instance with that same IP. They used the instance as a gateway for bots to probe the network and happened to find our server.

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.