Tag Archives: Network security

Background Noise on the Internet

Not too long ago there was a reasonable amount of press ( in the IT world anyhoo, meatspace pretty much ignored it ) regarding attacks against the SSh protocol. The “SShPsychos” group has been responsible for a large number of coordinated brute force attempts against well known usernames with a variety of common passwords. This isn’t long term targeted attempts against a particular target – rather a scatter-gun approach at anything that’s running an SSh daemon on Port 22 using a short-ish list of dumb passwords.SSh "hack" from the Matrix

To be honest, I’d known about this sort of background level for a long time – and it came as no great surprise to me. It’s been going on as long as I’ve had an SSh server running on a public IP, and to be fair the volume _has_ increased. It has been a great example to students though when I’ve been teaching Linux security – pointing out the reasons for carrying out the basics of securing SSh:

  1. No remote root login
  2. Complex passwords
  3. Specific IP firewall rules if/where possible

And also some of the more complicated ones:

  1. Fail2Ban
  2. Chroot Jails
  3. Multi-Factor Authentication

Even now, logging into my webserver ( “www.thinking-security.co.uk” ) via SSh on Port 22 there are approximately 2000 illegitimate login attempts over the last 20 hours. Quite often when I re-connect after a weekend or more than a few days, this number is in the 10s to even 100s of thousands. I’ll be honest, it doesn’t particularly bother me – it is much rattling of windows and testing of locks – there are much easier fish to fry on the interwebs than that particular machine.

It did cause me to ask two particular questions though:

1) Where are all the attacks coming from ?

2) What usernames and passwords are they trying ?

Turns out that question 1 is easy, and question 2 is half easy …

On any Linux server, the connections made against SSh are logged. These go into /var/log/secure and here is a prime example:

May 15 14:35:55 ts-one sshd[23429]: Invalid user bankid from 37.59.230.138
May 15 14:35:55 ts-one sshd[23429]: input_userauth_request: invalid user bankid [preauth]
May 15 14:35:55 ts-one sshd[23429]: pam_unix(sshd:auth): check pass; user unknown
May 15 14:35:55 ts-one sshd[23429]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=37.59.230.138
May 15 14:35:57 ts-one sshd[23429]: Failed password for invalid user bankid from 37.59.230.138 port 59470 ssh2
May 15 14:35:57 ts-one sshd[23429]: Received disconnect from 37.59.230.138: 11: Bye Bye [preauth]

This is one connection attempt – the source ( from ) is 37.59.230.138, and it has presented the invalid user “bankid” – this has actually failed at this point – but SSh won’t let the attacker know that, it will still allow them to enter three password attempts before terminating the connection. This inability to tell if it is the username or the password that has failed is actually quite important – realise that if you can tell if an account is valid, then you can easily stop wasting time and effort on ones which are not. This non-specific failure method “Either the username or the password is wrong” leaves the whole possible space open requiring a far greater number of attempts to find a valid username _and_ password combination.

37.59.230.138 – great IP address – I’m sure that there are some savants out there who can look at that and tell me where it is from – but I assure you, I am _not_ one of them. I have to look it up – and even then the sources occasionally disagree ( not that it actually really matters as I’m not sending a drone over to wreak revenge ).  For the purposes of the remainder of this process I’ll be using the MaxMind database, and, for the sake of legal compliance:

This product includes GeoLite2 data created by MaxMind, available from http://www.maxmind.com.
Creative Commons Licence
This data is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

There is a direct interface to the data that is available on the front page of the MaxMind website which allows for the query of a single IP address, and, for us in the case above, this tells us:

IP Address = 37.59.230.138
Country Code = FR
Location = France, Europe
Coordinates = 48.86, 2.35
ISP = OVH SAS
Organization = OVH SAS

So it is a French IP address hosted with the OVH Company.

Our friends in France ...

Our friends in France …

As a hosting company, they aren’t directly responsible for the attack, rather it is just being launched from a machine that has been allocated an IP address within their scope. However, having said that, a quick glance at a Google search about them suggests that this is far from the first time that they have been used as a stepping stone onto other things …

The IP address lookup also gave us the Lat / Long ( estimated – by a long shot ! ) of the address. We can plug these into Google Maps to have a look-see at the rough area of operation _of the IP address_. This isn’t, most likely, where our perpetrator is sitting – more likely the recorded head office of the company …

Our location in Paris...

That’s great one IP address down – 2000 to go …

In the next articles in this series, I’m going to extract all of the IP addresses & usernames from the logs ( across multiple servers ! ), and then plot these against a map to show both historic and real-time data … And then we’re going to move on to finding out what passwords are being attempted using a “honeypot” !

Tagged , , , ,

Five free ways to improve your security

Peer Review

Peer Review (Photo credit: AJC1)

We’re in recession, lest we forget – it isn’t like the press is going to let it slip from our minds – so money in a tight field is getting tighter. However, even for large businesses improving security need not cost the earth, or indeed anything at all ( apart from some time, and we must recall that time is equal to money ). To that end, I thought that I’d put down five very cost-effective and pragmatic ways to significantly improve your security.

1. Patching

Certainly at a desktop or server OS level, patches are mostly available for free. ( If you have devices, operating systems or applications that require a maintenance contract for patch updates – this isn’t quite for free, however let’s, for the time being assume that this cost is covered off already. ) Patching up to date ensures that, with the exception of those pesky “zero-day” problems, that your system is protected against known vulnerabilities. I’ve been to many, many organisations where patching is so out of date the measure is years – that’s seriously wrong. The excuse is often – “our application is so unstable we can’t” – let us think carefully about this statement and consider, under these circumstances what we should do about it … if and only if this is true and there is nothing that you can do to get the application maintained – then can it remain as is – however the device or server should be isolated behind other mitigations. ( So much so that if I am scanning your network in a vulnerability or penetration test – I don’t want to be able to see the patch level. )

2. Review your Firewall Rules

When was the last time you reviewed your firewall rules ? You’ve added some recently I’m willing to bet, but have you purged old entries ? Do you have a process for deleting rules when they are no longer needed ? Each “allow” rule is a doorway into your network – if it isn’t needed, lock the door. Incidentally, at this time it is wise to pre-empt the next point, is there supporting documentation surrounding your firewall ruleset ? At a minimum, you need to know what the rule is for in English, ( e.g. “allow port 80 tcp to 123.234.123.234 from 123.235.0.0” doesn’t tell me anything, “http website access to the stock server from the warehouse subnet” does. ) And who owns it ( John Smith from Warehouse Control ). That way, a review involves going through the list calling Bob and asking him if he still needs that rule.

3. Documentation

Review your docs – dry run through processes and procedures – do they still work ? Update them if not. Are there any documents that are clearly missing ? Write them. Review your policies, you are of course doing this annually anyway aren’t you, but IT moves faster than on a yearly basis, and I’m pretty sure that a mid-term review wouldn’t do you any harm – issue errata if you don’t want to actively change the policy at this stage – but keep the changes to hand for the updates and it will save time later. Check that your supporting documentation is up-to-date and relevant – such as your firewall rules above – if it isn’t in English, make a translation – you might know what it means, however if you get hit by the proverbial bus ( or get an offer you can’t refuse ) – then your successor will need to figure it out – the more uncertainty there is in that time the higher the risks of an incident – if you want an incentive a public breach that might be blamed on you after you’ve left ( “My predecessor left such a mess it was impossible to manage” ) might haunt you for a long time. It never ceases to amaze me how small this industry actually is.

4. Cull dead accounts

Like old firewall rules, old, unused accounts are opportunities to an external attacker. Hopefully you have a policy in place for removing accounts when an employee leaves, but it is still well worth going through and auditing. Look for test accounts, administrator accounts, contractor or supplier accounts and system accounts that wouldn’t be identified by a leavers process, and may well not have the same lockout or expiry controls. At the same time, have a quick check to make sure that all accounts have the correct settings – there are many tools and code available for walking AD or other directories to look for specific settings freely available on the net.

5. Educate a bit

I’m not talking about a huge CBT on security here – that’s hardly free. However writing and sending an e-mail to all staff is. Give some thought to what your major concerns and issues are, write a positive statement of ways to manage these risks ( one per e-mail, send a few ) and get it out there. Creating awareness, putting ideas into the heads of staff and giving them details of whom to contact with concerns or questions is going to reap long-term benefits that you can only imagine now. This is probably the largest return on investment that you can imagine – proactive staff will head off problems you have yet to conceive, and, given a voice, they’ll give you ideas and suggestions that will not only improve security, but could well make your business more profitable overall.

These are just five simple suggestions – you could extrapolate a little I’m sure to find a few other things that won’t cost a thing, but will improve your security ( here’s a clue – if you start with the word “review” or “audit” and follow with things like “running services”, “configurations” or “file/folder/group permissions” you’ll probably come up with another few ). It’s an interesting time to be in Security – budgets are down, but threats are up – pro-active low-cost work could be the difference between success and failure – these things really should be part of a security routine anyway – but we are so often firefighting or implementing the next new thing that we don’t get much of a chance – this breathing space might actually be what the doctor ordered …

Tagged , , , , , , ,