5 Days of SSHD Stats on a Public IP

Over the last 5 days my pub­licly acces­si­ble sys­tem at 198.61.231.43 has had 5,092 attempted SSH logins from 8 IP Addresses.

Unsur­pris­ingly, the most com­monly attempted ssh user­name is “root”, the default admin­is­tra­tive account on Linux sys­tems.
2013.02.22_sshd_percentchart

What I did find sur­pris­ing, was that most of the IPs gave up after a rel­a­tively low num­ber of attempts.
2013.02.22_sshd_totalchart

Even more so was that for each user­name tried which wasn’t root, the num­ber of pass­words attempted was rarely more than a dozen.
2013.02.22_sshd_userschart

Here are the IPs observed attempt­ing the unau­tho­rized logins:

  • 121.254.179.36
  • 122.194.113.201
  • 193.200.241.222
  • 202.165.179.53
  • 218.26.89.179
  • 37.98.241.242
  • 61.236.64.56
  • 64.237.49.52

All data was col­lected via syslog-ng from an Arch Linux server hosted by Rack­space sent to Splunk Storm

Tracking SSHD Login Activity in SplunkStorm

After a night out with my wife I decided to cre­ate a search for SSHD logins in Splunk Storm. See­ing that port 22 is open to the world on 198.61.231.43, I won­der how long before ran­dom bots start attempt­ing to log into it. As a secu­rity prac­ti­tioner its always inter­est­ing to see the effects of just being on the inter­net; and SplunkStorm is a great way to mon­i­tor those effects.

SSHD — Logins (Accepts and Failures)

sshd | rex field=_raw ”]: (?<sshd_action>.*) pass­word for (?<sshd_username>.*) from (?<sshd_ip>.*) port” | search sshd_action=”*” | table _time host sshd_action sshd_username sshd_ip

Here’s a look at the result:
sshd_screenshot

If you’re run­ning syslog-ng, it’s super sim­ple to send your logs over to a Splunk instance. Below is what I added to my /etc/syslog-ng/syslog-ng.conf file where the X’s are val­ues pro­vided by your SplunkStorm admin console:

des­ti­na­tion d_splunk { tcp(logsX.splunkstorm.com” port(XXXXX)); };
log { source(src); destination(d_splunk); };

Splunk Query: Processes Created & Terminated

This morn­ing I installed and con­fig­ured Snare on my AWS EC2 Win­dows 2012 Server to ship logs to my SplunkStorm project.

Below is a basic query for chart­ing the top processes that have started on the sys­tem:
Even­tID 4688 — A new process has been cre­ated. (Details)

4688  | rex field=_raw “Process Name: (?<Process_Name>.*) Token Ele­va­tion Type:”  | sort Process_Name | top limit=10000 Process_Name

Here is a mod­i­fied ver­sion of the query for processes that have ter­mi­nated:
Even­tID 4689 — A process has exited. (Details)

4689  | rex field=_raw “Process Name: (?<Process_Name>.*) Exit Sta­tus:”  | sort Process_Name | top limit=10000 Process_Name

More to come.…

Annual Refresh

It seems that every year for the last six years, I refresh the web­site look with a dif­fer­ent theme, and make a renewed attempt to add con­tent. This year is no different.

This year I’m also tak­ing advan­tage of the free Cloud­Flare ser­vice to pro­vide secu­rity pro­tec­tion for the blog, any view­ers, and faster deliv­ery of the site via their CDN net­work. If you’re sus­pected of being infected with mal­ware, cloud­flare will notify you and per­haps require a captcha to access the site. Addi­tion­ally, they pro­vide Web Appli­ca­tion Fire­wall capa­bil­ity that pro­tects from com­mon attacks such as SQLi and XSS.

Some other recent tech­nolo­gies I’m tak­ing a look at include Ama­zon Web Ser­vices EC2 Win­dows 2012 Micro Instance and the cloud offer­ing from Splunk — Splunk Storm

So far the AWS instance seems to be a nice way to try out the lat­est server plat­form with­out hav­ing to obtain a copy of the OS Instal­la­tion mate­r­ial. Pre­vi­ously, this was eas­ily done through a cor­po­rate MSDN account to quickly try it out in a dev envi­ron­ment. My cur­rent posi­tion doesn’t afford me that lux­ury, so it’s nice to see that I can still try it through AWS EC2.

Until next time.