Why it’s important to monitor logs

A while back I wrote sshfail. It’s a script to look at attempts on the ssh protocol on servers. You can find it up on git hub if your interested and want to install in your self. https://github.com/nevetsanderson/sshfail .

The interesting thing is that even if you use a non standard port to run ssh on (which is what this data relates to) it’s only a matter of time before modern hackers or bots or some Bs8dutard’s find that information and it gets propergated. Have a look at this raw data.


As you can see things got ugly after about 11 days… from 28 to 5873 attempts on the server per day and within 2 weeks. Also worth considering is how did things go from weeks of no one being able to detect this, to 28 ip address suddenly finding my machine on the same day and then it increasing to 195 (Jan 3-9). I’d love to know what’s going on in the background. How is information is being propergated?

So as you can also observe on the 15 th, I changed the port and things have been have quiet since then but the issue is… If I hadn’t been observant and actually looked at the numbers then I’d be giving the bad guys a chance at reeking havok…

Stay safe out there people, and actually look at your log data!

Old blog and rss feed now working (again!)

Tape deck

Something I have been meaning to get around to for a few weeks now since the new machine rebuild – the Old blog and the rssfeed are now working! Among other historic gems you can find out “Why I like pfsense” and a cool little script I wrote back in 2008 with regards web site health (stay tuned I’m going to elaborate on this). Sorry if anyone was missing this historic data. It’s interesting from a curative perspective keeping this project alive – I’ve been bloging in one form or another since 2005!

Old blog is at https://gingercatsoftware.com/Blog.php

Point your rssfeed reader to https://gingercatsoftware.com/rssfeed.php

Your machine and it’s code

So I’ve been thinking a lot of late about machines, exploits and how to stop this sort of thing. I’ve been in situations where developers have created “stuff” on production machines and then left the company. The problem then becomes interesting if that code does not work with an up dated version of the software say wordpress, drupal or the operating system.

Urban dross

Your then in a situation (if the machine is a web server or open and available on the net) where about the only thing you can do is lock down the firewall and harden the old un patched OS and hope that no one finds a way in / attacks the machine.

It’s always good to have at least 2 people who understand custom code in any company especially if you have a number of web servers to mange. But even then re building something and re creating that functionality is not always easy – and management need to be aware of the fact that this will take time and cost money.

So if that keen shiny developer comes along one day promising you a widget that will sell your own grandmother and only cost you a few hundred bucks worth of con-sultan fees, my advice is to run screaming from the room.

The up shot I’m trying to put to you? Have the ability to own your own code – because if you don’t and if it gets hacked or is found to be vulnerable it’s going to cost you!

A simple approach is best – easier management and long term savings.