Logging shell break-in attempts

Given the recent ShellShock security vulnerability in the news, I thought I’d post this.

Little background first. I have been using my EX2 primarily as an SFTP server for the past 7 months that I owned it, and that’s because I was able to figure out a way to enable non-root user access to the shell. That was tricky and requires compiling custom firmware. But assuming nearly 100% of users are not going to do that or be able to do that even if they wanted to, most folks, at best can just access the shell from outside only as the root user. For secure ftp they can use the FTPS feature of the NAS (but not SFTP). But in order to even be able to make shell access for root user available from the outside world, one has to jump through several hoops (port forwarding, etc.). So the vulnerability of the shell being attacked from outside is already extremely limited. And most folks clamoring for ShellShock patch don’t seem to get this. I won’t delve into an expanded discussion on that here - I will only say, my opinion is that the risk from the default configuration of the EX2 for most users is almost non-existent…because they are not making their SSH port (22) traversable from outside. This is in addition to the bash shell being only included as an optional shell, not the default shell, for EX2, not to mention unauthorized users cannot even login, let alone execute a command. Problem is often people don’t understand some of these important issues - and often people tend to be afraid of things they don’t understand. Having said that, I am all for getting a patched bash shell included in a firmware fix - but it is certainly not as urgent as some folks are making it to be.

But my scenario is different. I do leave the shell reachable from outside in order for SFTP to work. My friends who use SFTP, login using SSH keys - no passwords are involved. Couple months ago, I had also enabled cloud access to EX2’s dashboard, thereby making the web server on EX2 reachable from outside. But because I left the web server open from outside, I also implemented a mechanism to log all web server requests…primarily so I could keep tabs on intrusion attempts through the web server (port 80). And in the nearly past couple months of logging web accesses from outside, I have collected a trove of info on dozens of intrusion attempts on my EX2’s web server daily. I can pretty much tell almost all of them are using various automated scripts that go through IP after IP and run port scanners and once they find port 80 open, those scripts then try a bunch of popular vulnerabilities. I may add some of those log captures in a later post in this thread or in a different thread - but in this post I will discuss my latest endeavor…logging of the shell access.

Given all the noise surrounding the ShellShock and all the intrusion attempts on my web server, I recently started thinking that perhaps I should start capturing logs of login attempts on my EX2’s shell as well. In addition to showing the legit logins by my friends logging into the sftp server, I figured, I will be able to keep tabs on what I knew for sure was alread happening - plenty of intrusion attempts on my EX2’s shell. Again - this is going to be irrelevant for 99.99% of EX2 users, since you don’t expose your shell to the outside world.

So last night I worked on enabling the logging mechanism of my EX2’s shell (BusyBox). These steps won’t be replicable for most folks (unless you are running a modded shell like me)…I am just mentioning it here if you are curious about the steps.

To enable logging I had to do two simple things:

  1. Add the following line in sshd_config: LogLevel VERBOSE (there is an important config already present in this file → SyslogFacility AUTHPRIV)
  2. Uncomment the following line in /usr/local/config/syslog.conf (this file gets copied over to /etc/syslog.conf at boot time): auth,authpriv.* /var/log/auth.log

That’s it - that’s all there is to it. But of course over time these logs will grow and grow quite quickly. So I updated my daily http log archiving mechanism to also include the auth.log file (and I also decided to throw in my sftp.log file as well - why the heck not since sftp log is also being written by the same process as the auth.log, the sys log daemon aka syslogd). I just added the following changes to that cron job’s script:

  • Stop the syslog daemon (kill -TERM cat /var/run/syslogd.pid)
  • Move the auth and sftp logs (in addition to the http log, which is not written/managed by syslogd but by lighttpd, the web server)
  • Restart the syslog daemon (/usr/sbin/syslogd -r -m 0 --rt_line 800). This command is exactly how WD starts the syslogd at boot time.

Once the syslogd starts, it reads the syslog.conf and starts writing to a fresh auth.log and sftp.log.

Anyway, that’s all the changes I had to do - the first 2 steps (enabling logging) were done on the server and the changes to enable log archiving needed to be baked-into the firmware code and then firmware compiled.


Now onto the real reason I wrote this post. Within less than 2 hours of me enabling the shell logging, I started seeing multiple attempts to break-in to the shell. The first attempt starting around 12:47 PM, came from an IP address in Taiwan. The next set of attempts starting around 4:30 PM came in from an IP address in Fujian, China. The third set of attempts came from someone eerily not that far away. And the fourth set of attempts came from an IP address in Seychelles. Talk about global hacking :slight_smile:

Some of you more technical folks will quickly spot something wrong they are doing. If you do spot it, please I request you to keep it to yourself and not blurt it out in a reply on this post. I myself stripped part of one log column to shield some crucial info. Anyway, onto the log entries - I snipped away many duplicate log entries as I am limited by the max message size I can post here:

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2014.10.08 22:32:27 =~=~=~=~=~=~=~=~=~=~=~=
Oct 8 12:47:32 2014 6 WDMyCloud [27448]: Connection from 59.124.94.145 port 2716
Oct 8 12:47:32 2014 6 WDMyCloud [27448]: Did not receive identification string from 59.124.94.145
Oct 8 12:47:32 2014 6 WDMyCloud [27449]: Connection from 59.124.94.145 port 2730
Oct 8 12:47:34 2014 6 WDMyCloud [27449]: Failed password for root from 59.124.94.145 port 2730 ssh2
Oct 8 12:47:35 2014 6 WDMyCloud [27455]: Connection from 59.124.94.145 port 3071
Oct 8 12:47:37 2014 6 WDMyCloud [27455]: Failed password for root from 59.124.94.145 port 3071 ssh2
Oct 8 12:47:37 2014 6 WDMyCloud [27461]: Connection from 59.124.94.145 port 3538
Oct 8 12:47:39 2014 6 WDMyCloud [27461]: Failed password for root from 59.124.94.145 port 3538 ssh2
Oct 8 12:47:40 2014 6 WDMyCloud [27465]: Connection from 59.124.94.145 port 3977
Oct 8 12:47:42 2014 6 WDMyCloud [27465]: Failed password for root from 59.124.94.145 port 3977 ssh2
Oct 8 12:47:42 2014 6 WDMyCloud [27472]: Connection from 59.124.94.145 port 4518
Oct 8 12:47:43 2014 6 WDMyCloud [27472]: Failed password for root from 59.124.94.145 port 4518 ssh2
Oct 8 12:47:44 2014 6 WDMyCloud [27478]: Connection from 59.124.94.145 port 4839
Oct 8 12:47:46 2014 6 WDMyCloud [27478]: Failed password for root from 59.124.94.145 port 4839 ssh2
Oct 8 12:47:46 2014 6 WDMyCloud [27482]: Connection from 59.124.94.145 port 1313
Oct 8 12:47:48 2014 6 WDMyCloud [27482]: Failed password for root from 59.124.94.145 port 1313 ssh2
Oct 8 12:47:48 2014 6 WDMyCloud [27487]: Connection from 59.124.94.145 port 1618
Oct 8 12:47:50 2014 6 WDMyCloud [27487]: Failed password for root from 59.124.94.145 port 1618 ssh2
Oct 8 12:47:51 2014 6 WDMyCloud [27491]: Connection from 59.124.94.145 port 1990
Oct 8 12:47:52 2014 6 WDMyCloud [27491]: Failed password for root from 59.124.94.145 port 1990 ssh2
Oct 8 12:47:53 2014 6 WDMyCloud [27501]: Connection from 59.124.94.145 port 2319
Oct 8 12:47:54 2014 6 WDMyCloud [27501]: Failed password for root from 59.124.94.145 port 2319 ssh2
Oct 8 12:47:54 2014 6 WDMyCloud [27507]: Connection from 59.124.94.145 port 2514
Oct 8 12:47:56 2014 6 WDMyCloud [27507]: Failed password for root from 59.124.94.145 port 2514 ssh2

Oct 8 12:54:03 2014 6 WDMyCloud [28676]: Connection from 59.124.94.145 port 3193
Oct 8 12:54:04 2014 6 WDMyCloud [28676]: Failed password for root from 59.124.94.145 port 3193 ssh2
Oct 8 16:29:59 2014 6 WDMyCloud [22164]: Connection from 117.27.158.98 port 7212
Oct 8 16:30:13 2014 6 WDMyCloud [22164]: Failed none for root from 117.27.158.98 port 7212 ssh2
Oct 8 16:30:23 2014 6 WDMyCloud [22164]: Failed password for root from 117.27.158.98 port 7212 ssh2
Oct 8 16:30:24 2014 6 WDMyCloud [22164]: Failed password for root from 117.27.158.98 port 7212 ssh2
Oct 8 16:30:43 2014 6 WDMyCloud [22164]: Failed password for root from 117.27.158.98 port 7212 ssh2
Oct 8 16:30:43 2014 6 WDMyCloud [22164]: Failed password for root from 117.27.158.98 port 7212 ssh2
Oct 8 16:30:46 2014 6 WDMyCloud [22164]: Failed password for root from 117.27.158.98 port 7212 ssh2
Oct 8 16:30:46 2014 6 WDMyCloud [22164]: Failed password for root from 117.27.158.98 port 7212 ssh2
Oct 8 16:30:59 2014 6 WDMyCloud [22164]: Failed password for root from 117.27.158.98 port 7212 ssh2
Oct 8 16:31:00 2014 6 WDMyCloud [22322]: Connection from 117.27.158.98 port 9121
Oct 8 16:31:00 2014 6 WDMyCloud [22326]: Connection from 117.27.158.98 port 10851
Oct 8 16:31:04 2014 6 WDMyCloud [22322]: Failed none for root from 117.27.158.98 port 9121 ssh2

Oct 8 16:37:12 2014 6 WDMyCloud [23063]: Failed password for root from 117.27.158.98 port 23765 ssh2
Oct 8 16:42:43 2014 6 WDMyCloud [23765]: Connection from 198.71.58.200 port 39757
Oct 8 16:42:43 2014 6 WDMyCloud [23765]: Invalid user oracle from 198.71.58.200
Oct 8 16:42:43 2014 3 WDMyCloud [23765]: error: Could not get shadow information for NOUSER
Oct 8 16:42:43 2014 6 WDMyCloud [23765]: Failed password for invalid user oracle from 198.71.58.200 port 39757 ssh2
Oct 8 16:42:45 2014 6 WDMyCloud [23769]: Connection from 198.71.58.200 port 39942
Oct 8 16:42:45 2014 6 WDMyCloud [23769]: Invalid user oracle from 198.71.58.200
Oct 8 16:42:45 2014 3 WDMyCloud [23769]: error: Could not get shadow information for NOUSER
Oct 8 16:42:45 2014 6 WDMyCloud [23769]: Failed password for invalid user oracle from 198.71.58.200 port 39942 ssh2

Oct 8 16:42:51 2014 6 WDMyCloud [23796]: Failed password for invalid user oracle from 198.71.58.200 port 42413 ssh2
Oct 8 20:56:02 2014 6 WDMyCloud [21661]: Connection from 193.107.17.72 port 51987
Oct 8 20:56:02 2014 6 WDMyCloud [21661]: Did not receive identification string from 193.107.17.72
Oct 8 21:02:44 2014 6 WDMyCloud [22476]: Connection from 193.107.17.72 port 62620
Oct 8 21:02:44 2014 6 WDMyCloud [22477]: Connection from 193.107.17.72 port 62644
Oct 8 21:02:44 2014 6 WDMyCloud [22478]: Connection from 193.107.17.72 port 62683
Oct 8 21:02:44 2014 6 WDMyCloud [22479]: Connection from 193.107.17.72 port 62726
Oct 8 21:02:44 2014 6 WDMyCloud [22480]: Connection from 193.107.17.72 port 62784
Oct 8 21:02:44 2014 6 WDMyCloud [22481]: Connection from 193.107.17.72 port 62788
Oct 8 21:02:46 2014 6 WDMyCloud [22476]: Failed none for root from 193.107.17.72 port 62620 ssh2
Oct 8 21:02:47 2014 6 WDMyCloud [22476]: Failed password for root from 193.107.17.72 port 62620 ssh2

Oct 8 21:02:49 2014 6 WDMyCloud [22477]: Failed password for root from 193.107.17.72 port 62644 ssh2

This is interesting… :dizzy_face:

Thats just one example of why I’m always talking about security.  I dont connect to my drive except by secure protecols to avoid the possibility of someone gathering stray packets containing un-encrypted usernames and passwords. (No un-encrypted FTP for me.)  I have also seen this same type of activity in my router logs. 

Oh, and yes I see the error in their ways, typical hackers.

Thought I’d post the link to this this very relevant article on new NAS vulnerability exploit here instead of creating a separate thread → http://www.bbc.com/news/technology-29595219

And just for reference, here’s my post about enabling logging for the web server →   http://community.wd.com/t5/WD-My-Cloud-EX2/Enabling-logging-for-lighttpd-web-server/m-p/788667