3

I have a raspberry-pi (running GNU/Linux) and I recently allowed my router to forward port 22 (ssh) to the raspberry-pi so that I could log in while away from home.

I then noticed a bunch of apparent break-in attempts (failed root logins coming from a chinese ip address) in auth.log, and I have a couple questions about the timing of the failed root logins.

Here's a snippet from my /var/log/auth.log file (the first number is just the line number from vi):

5966 Sep  7 11:50:19 raspberrypi sshd[13759]: Failed password for root from 122.225.103.125 port 34328 ssh2
5967 Sep  7 11:50:20 raspberrypi sshd[13755]: Failed password for root from 122.225.103.125 port 32582 ssh2
5968 Sep  7 11:50:20 raspberrypi sshd[13763]: Failed password for root from 122.225.103.125 port 35381 ssh2
5969 Sep  7 11:50:21 raspberrypi sshd[13759]: Failed password for root from 122.225.103.125 port 34328 ssh2
5970 Sep  7 11:50:22 raspberrypi sshd[13763]: Failed password for root from 122.225.103.125 port 35381 ssh2
5971 Sep  7 11:50:24 raspberrypi sshd[13767]: Failed password for root from 122.225.103.125 port 39706 ssh2
5972 Sep  7 11:50:24 raspberrypi sshd[13763]: Failed password for root from 122.225.103.125 port 35381 ssh2
5973 Sep  7 11:50:25 raspberrypi sshd[13771]: Failed password for root from 122.225.103.125 port 40360 ssh2
5974 Sep  7 11:50:26 raspberrypi sshd[13767]: Failed password for root from 122.225.103.125 port 39706 ssh2
5975 Sep  7 11:50:26 raspberrypi sshd[13771]: Failed password for root from 122.225.103.125 port 40360 ssh2
5976 Sep  7 11:50:28 raspberrypi sshd[13767]: Failed password for root from 122.225.103.125 port 39706 ssh2
5977 Sep  7 11:50:28 raspberrypi sshd[13775]: Failed password for root from 122.225.103.125 port 41540 ssh2
5978 Sep  7 11:50:29 raspberrypi sshd[13771]: Failed password for root from 122.225.103.125 port 40360 ssh2
5979 Sep  7 11:50:31 raspberrypi sshd[13775]: Failed password for root from 122.225.103.125 port 41540 ssh2
5980 Sep  7 11:50:31 raspberrypi sshd[13767]: Failed password for root from 122.225.103.125 port 39706 ssh2
5981 Sep  7 11:50:31 raspberrypi sshd[13771]: Failed password for root from 122.225.103.125 port 40360 ssh2
5982 Sep  7 11:50:33 raspberrypi sshd[13775]: Failed password for root from 122.225.103.125 port 41540 ssh2
5983 Sep  7 11:50:33 raspberrypi sshd[13771]: Failed password for root from 122.225.103.125 port 40360 ssh2
5984 Sep  7 11:50:34 raspberrypi sshd[13767]: Failed password for root from 122.225.103.125 port 39706 ssh2
5985 Sep  7 11:50:35 raspberrypi sshd[13775]: Failed password for root from 122.225.103.125 port 41540 ssh2
5986 Sep  7 11:50:35 raspberrypi sshd[13771]: Failed password for root from 122.225.103.125 port 40360 ssh2
5987 Sep  7 11:50:36 raspberrypi sshd[13767]: Failed password for root from 122.225.103.125 port 39706 ssh2
5988 Sep  7 11:50:37 raspberrypi sshd[13775]: Failed password for root from 122.225.103.125 port 41540 ssh2
5989 Sep  7 11:50:38 raspberrypi sshd[13779]: Failed password for root from 122.225.103.125 port 46112 ssh2
5990 Sep  7 11:50:39 raspberrypi sshd[13775]: Failed password for root from 122.225.103.125 port 41540 ssh2

And, here's a snippet from my /etc/pam.d/login file (the first number is just the line number from vi):

9 auth       optional   pam_faildelay.so  delay=3000000

As you can see the delay is set in pam.d/login to three seconds... However the failed root logins are coming at about 1 second apart. How is this possible? Is it because the logins are coming from different ports or ttys? Also, when I try to emulate this behavior myself by putting in the wrong root password, I find that after three attempts I get disconnected and this shows up in auth.log like:

231 Sep 17 11:51:57 raspberrypi sshd[17591]: Failed password for root from 192.168.42.71 port 34208 ssh2
232 Sep 17 11:52:01 raspberrypi sshd[17591]: Failed password for root from 192.168.42.71 port 34208 ssh2
233 Sep 17 11:52:04 raspberrypi sshd[17591]: Failed password for root from 192.168.42.71 port 34208 ssh2
234 Sep 17 11:52:04 raspberrypi sshd[17591]: Connection closed by 192.168.42.71 [preauth]

My three failed attempts are spaced out by at least 3 seconds (as specified in pam.d/login). How is it possible for whoever is trying to break in to make more that one attempt every three seconds and why is the connection not being closed after three failed attempts?

Any help understanding this behavior would be greatly appreciated. Feel free to give references if you are not in the mood to type out an answer. Oh, also, if anyone has any idea as to how my ip address was targeted or if it is just random, I would be interested to hear about it.

Improve this question
8
  • 2
    Your machine is accepting multiple simultaneous TCP connections (evidenced by the differing remote port numbers). However, per connection, it seems to be doing more than three attempts at less than a 3 second delay, which I can't explain.
    – apsillers
    Commented Sep 17, 2014 at 19:38
  • Thanks for the help. Do you have an idea as to how specifically they are doing this (making multiple tcp connections with different ports by the same ip) and how I would go about blocking it?
    – hft
    Commented Sep 17, 2014 at 19:41
  • possible duplicate of What to do about ssh breakin attempts
    – Xander
    Commented Sep 17, 2014 at 19:49
  • @Xander, I don't see this as a duplicate. This question is asking how the attacker manage to bypass the delay for failed logins, where that question is asking about how to deal with SSH brute-force attacks.
    – Mark
    Commented Sep 17, 2014 at 20:02
  • @hft, Is each of those "Failed password" lines the complete log entry? Looking at the logs for my servers, each brute-force attempt generates six lines of log entry (OpenSSH) or three lines (dropbear).
    – Mark
    Commented Sep 17, 2014 at 20:12

2 Answers 2

Reset to default
2

As pointed out by apsillers in the comment, what you are seeing are multiple TCP connections from the same IP address. If you group the source port numbers, you will be able to see that each connection is making a login attempt at a maximum rate of one per two seconds:

5967 Sep  7 11:50:20 .... sshd[13755]: Failed .... from 122.225.103.125 port 32582 ssh2

5966 Sep  7 11:50:19 .... sshd[13759]: Failed .... from 122.225.103.125 port 34328 ssh2
5969 Sep  7 11:50:21 .... sshd[13759]: Failed .... from 122.225.103.125 port 34328 ssh2

5968 Sep  7 11:50:20 .... sshd[13763]: Failed .... from 122.225.103.125 port 35381 ssh2
5970 Sep  7 11:50:22 .... sshd[13763]: Failed .... from 122.225.103.125 port 35381 ssh2
5972 Sep  7 11:50:24 .... sshd[13763]: Failed .... from 122.225.103.125 port 35381 ssh2

5971 Sep  7 11:50:24 .... sshd[13767]: Failed .... from 122.225.103.125 port 39706 ssh2
5974 Sep  7 11:50:26 .... sshd[13767]: Failed .... from 122.225.103.125 port 39706 ssh2
5976 Sep  7 11:50:28 .... sshd[13767]: Failed .... from 122.225.103.125 port 39706 ssh2
5980 Sep  7 11:50:31 .... sshd[13767]: Failed .... from 122.225.103.125 port 39706 ssh2
5984 Sep  7 11:50:34 .... sshd[13767]: Failed .... from 122.225.103.125 port 39706 ssh2
5987 Sep  7 11:50:36 .... sshd[13767]: Failed .... from 122.225.103.125 port 39706 ssh2

The reason why the same IP address can make multiple SSH connections is because several terminals are being opened at the same time. You should be able to observe the same thing by firing up three terminals, run ssh root@localhost and pressing enters upon password prompt.

For your PAM configuration settings, you should be looking at /etc/pam.d/sshd instead of /etc/pam.d/login. Also, from the man page of pam.d, it says:

optional
the success or failure of this module is only important if it is the only module in the stack associated with this service+type.

No, your IP address is not the only one targeted. It is an automated scan by several compromised computers mainly in China. This is a list of IPs targeting port 22 that I have collated in just a few days:

61.174.50.184
61.174.50.213
61.174.51.194
61.174.51.197
61.174.51.198
61.174.51.202
61.174.51.203
61.174.51.209
61.174.51.210
61.174.51.216
61.174.51.217
61.174.51.218
61.174.51.219
61.174.51.221
61.174.51.224
61.174.51.229
61.174.51.233

114.80.246.144

116.10.191.162
116.10.191.163
116.10.191.165
116.10.191.167
116.10.191.168
116.10.191.169
116.10.191.171
116.10.191.174
116.10.191.176
116.10.191.177
116.10.191.179
116.10.191.180
116.10.191.181
116.10.191.186
116.10.191.187
116.10.191.189
116.10.191.190
116.10.191.194
116.10.191.195
116.10.191.199
116.10.191.201
116.10.191.202
116.10.191.203
116.10.191.206
116.10.191.208
116.10.191.214
116.10.191.215
116.10.191.217
116.10.191.218
116.10.191.220
116.10.191.224
116.10.191.229
116.10.191.231
116.10.191.235
116.10.191.236

117.21.173.140
117.21.227.58

122.225.103.125 <= WENZHOU GAOJIE TECHNOLOGY CO.LTD

122.225.109.100

122.225.109.103
122.225.109.104
122.225.109.107

122.225.109.195
122.225.109.196
122.225.109.203
122.225.109.205
122.225.109.216
122.225.109.218
122.225.109.220
122.225.109.221

183.60.202.238

183.110.253.233

183.136.213.180

222.186.21.78
222.186.52.160
222.186.56.7
222.186.56.76
222.186.56.119

223.255.205.201

For you particular case, if you have the time to spare, you may like to contact Shengzhong Liu of WENZHOU GAOJIE TECHNOLOGY CO.LTD at +86-13738375522 (from whois record) to let him know that one of his computers is compromised. Alternately, you may consider switching ssh to another port and disabling root login to avoid the harassment.

Improve this answer
3
  • Thanks for your reply. Lots of good information here. I'm going to have a look at my pam.d/ssh when I get home to see if there's a two second setting. Any idea how specifically they are making so many tcp connections at once from the same ip?
    – hft
    Commented Sep 18, 2014 at 20:08
  • @hft, see my update for the reason why this is possible.
    – Question Overflow
    Commented Sep 19, 2014 at 2:19
  • I was trying to reproduce the behavior by opening multiple terminals on one machine and running ssh root@[pi-address] in all of the open terminal windows... but I'm not able to reproduce the behavior this way. Is there some other automated way it could be done?
    – hft
    Commented Sep 19, 2014 at 16:15
1

I'm posting this new answer to my question because one part of my original question was not completely addressed. Specifically, what kind of tool could be used to make so many connection attempts, seemingly more quickly than the minimum delay time I had set in my pam configuration.

Well, it looks like a tool like hydra (see www.thc.org) was used. To check this I installed Kali Linux (which comes with hydra) on a spare machine and used hydra to try and brute force the root password on my raspberry pi.

The resulting auth.log file is very similar to the actual attack; it has way more login attempts than one every three seconds... I'm still not sure how this is accomplished in hydra, but I feel pretty confident a tool similar to (or equal to) hydra was used for the attack.

Finally, in order to increase the security of my pi I made a few changes to the system. I setup and started the "UFW" firewall service. I installed and started the "fail2ban" service. And, finally, I switched from password authentication to SSH keys.

Ah... I do feel so much better now.

Improve this answer
1
  • With just ssh keys, you're stopping brute forcing into the system. You don't really need fail2ban. Also your sshd now serves to soak up the connections, slowing down the scans to other parts of the network.
    – munchkin
    Commented Mar 2, 2015 at 9:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .