Graphing SSH dictionary attacks with HighCharts

After my 10-year-old basement Linux server died this week from a power outage, I took the sad step of giving up on it. It’s died before and I’ve patched it back together with a new power supply here or an addon PCI SATA card there, but I finally decided to throw in the towel since I had a newer old computer that had been idle for several years. The one that died was an Athlon K7 750 MHz with 512 MB ram. The new one is an Athlon 2 GHz (3200+) with 1 gig. For my uses, specs don’t really matter that much, but it’s nice to have more power for free.

I put CentOS 6 on it and configured Samba and copied all the data off the old machine and was back up and running within a few hours. Since I forward ports through my FiOS router to this box I did my standard lockdown procedure, including adding myself to the AllowUsers in sshd_config. Afterwards I took a look in /var/log/secure and saw the typical flood of dictionary attacks trying to get in as root or bob or tfeldman or jweisz. I have iptables configured to rate-limit SSH connections to 2 per 5 seconds per IP so the box doesn’t get DoSed out of existence, but some stuff does make it through to sshd.

Looking through /var/log/secure, I got to thinking it would be interesting if there was some way to visualize the attacks in a handy graph. Then I remembered, oh, wait, I can do that.

I wrote a perl script to parse out the attacks from /var/log/secure and insert them into a Postgres DB. This turned out to be pretty easy. Then I thought it would be more interesting to tie the IP of each attack to its originating country. I’ve used MaxMind’s GeoIP DB pretty extensively before, but I was looking something free. That’s when I remembered that MaxMind has a free GeoIP DB: GeoLiteCity. I grabbed it and yum-installed the Perl lib and added the geo data to the attack DB. Rather than worry about normalizing the schema I just shoved the info into the same table. Life is easier this way, and it’s just a for-fun project.

So I got that all working and parsed it against the existing /var/log/secures via

[root@lunix2011 ~]# zcat /var/log/secure-20111117.gz | perl 

I wrote ssh.php to see what’s in the table:

ssh.php list of hacking attempts
ssh.php list of hacking attempts

So now that the data was all in place, time to move on to the graphs, which is what I really wanted to do. Last time I wanted to graph data programmatically I used JPGraph, which does everything in PHP and is super versatile. But I wanted something… cooler. Maybe something interactive. A little Googling turned up Highcharts which is absolutely awesome, and does everything in JavaScript. I basically modified some of their example charts and pumped my data into them and got the charts below.

Pie chart of attacks grouped by country for the past 30 days:

Pie chart by country
Pie chart by country

Bar graph of attacks per day:

Bar graph of daily attacks
Bar graph of daily attacks

So, that’s that. Code is in github if anyone wants to play around with it. I’ve cronned to run every 5 minutes so the data gets updated automatically.

Using SSH tunnel & Squid to create a private encrypted proxy for true private browsing (mostly)

I once worked at this place where I got a stern talking-to for viewing non-work-related pages. It was around Christmas and I was doing my shopping online (since I left the house at 7 AM and got home at 8 PM). It’s not like I was farting around all the time. Anyway, the idea that I was being proactively watched by someone with an axe to grind pissed me off, so I decided I wouldn’t give him anything to read.

I don’t have that problem anymore, but I do frequently connect to open wifi points where my traffic can be viewed. I use SSL for things like email, but why even let them see that I’ve gone to

My solution to both problems was the same: on my Linux box at home, run a proxy server, and pipe all my traffic to it via an SSH tunnel.

Step 1: Install Squid

Since I use CentOS, to do this I just did a yum install squid

Step 2: Configure Squid

Well, the default squid config (/etc/squid/squid.conf) was pretty much fine, although I needed to add an ACL clause so I could actually use the proxy. The LAN in my house is, so I put these lines in my squid.conf:

acl subnet_192 src
http_access allow subnet_192

Then start Squid.

Step 3:Create the SSH tunnel

I run Linux, so that’s the syntax I can provide (You can use putty to do this from a Windows machine):
ssh -f evan@public-hostname-of-proxy-server -L -N
This opens an SSH connection from your local machine (port 3128) to the remote server’s private IP on port 3128 (3128 being the default port on which squid listens). So connections to localhost:3128 will be forwarded over the SSH tunnel to port 3128 on the other machine’s private IP.

Step 4: Set your browser to point to localhost:3128 as proxy server

Well, that’s pretty self-explanatory. In the browser’s options (lots of other apps support HTTP proxies as well – AIM, etc), find the section about proxy settings and set the HTTP and HTTPS proxies to “localhost” and port 3128.

That’s it. To test if it’s working, try going to and confirm that it shows you as coming from the home machine’s IP.

If you have a strict network admin who’s locked down outbound SSH, you can just have sshd listen on port 80 or 443, which almost everyone allows. A really nosy admin may notice encrypted traffic going to the server and kill it, but… well, I never said it was foolproof. 🙂

Passwordless SSH Everywhere

I’ve known about ssh keys for a long time and frequently use them, most frequently so that a script can transfer a file between two servers without having to do some mumbo-jumbo where I try to pipe a password into it or some other wacky thing. I hadn’t fully embraced ssh keys, though, because I didn’t like the idea that if I lost my laptop, I’d be losing a free key into my servers. Then I discovered ssh-agent. This isn’t new, so I’m kind of embarrassed I didn’t know about it, but I’ve been using it for a few months now and I can’t imagine going back.

Continue reading “Passwordless SSH Everywhere”