edeca.net » security

Stupid password rules

David — Thu, 24 Nov 2011 20:24:11 +0000

Today I forgot the password for a site I use only occasionally. This is rare, as I have a number of password schemes that I use to create a password unique to each site. After clicking the reset password link, I am confronted with the “password strength checker” below:

This list of rules doesn’t fit very well with my password scheme, primarily because what I computed in my head fails the test for uppercase characters.

Using the phrase “this is an unbelievably long password that would take a very long time to crack” fails this rule too, as well as the tests for a number and punctuation. I’m not suggesting that this is a good password, but it’s certainly better than “aA1!bcde” which passes all the rules. These 8 characters are trivial to brute force on any modern machine even if the underlying software uses a salted hash.

The offending software appears to be Jive, who perhaps need to set some more sensible defaults on their login system.

Welcome to the IPv6 world

David — Sun, 07 Nov 2010 11:04:59 +0000

This blog can now be reached over IPv6 (or ipv6.edeca.net), which is surely the final nail in the coffin of IPv4 across the internet.

After deciding that I knew little about the practical aspects of IPv6 I spoke to my VPS provider, Bytemark, and asked for some addresses. Configuring Debian was simple, as it already comes with a dual stack and just needs the public IPv6 block adding to the existing link-local address.

After a week I have seen a number of accesses to this site using IPv6. I also added an AAAA record for my mail exchanger at the same time, but so far haven’t seen any legitimate messages delivered. SSH login attempts have also been absent, which is good as apparently denyhosts doesn’t support IPv6 just yet.

It is worth considering security too. By default, ip6tables is permissive in ALLOW mode. This has security implications for link-local addresses if the attacker is on the same network segment, but definitely needs thought if you add routable IPv6 addresses. I copied my existing set of iptables rules and modified them where necessary, only allowing the essential services.

Be the first to comment from an IPv6 address!

Blocking SSH brute forcing using denyhosts

David — Thu, 07 Jan 2010 23:04:44 +0000

Tired of seeing repeated attempts to login to a Linux server you run? There are a number of options, all with their own benefits and disadvantages. The easiest way is to move the port that the SSH server runs on, perhaps to 2222 instead of 22. However. this can be annoying behind some firewalls and means that you need to specify the port each time you SSH to a host. This post looks at denyhosts, a viable alternative.

denyhosts will monitor your authorisation log (typically /var/log/auth.log) and ban IPs that repeatedly fail to authorise as a genuine user. It will deny future logins by adding the IP address to /etc/hosts.deny.

On a sensible Debian or Ubuntu install, getting denyhosts is as simple as running:

1	$ aptitude install denyhosts

denyhosts should work as soon as it is installed. However, a few options can be tweaked to make it work nicely. The configuration file is at /etc/denyhosts.conf.

Firstly, set a proper administration email by changing ADMIN_EMAIL. The option RESET_ON_SUCCESS might also be important to you, by setting it to yes the failure count for an IP address will be reset if there is a successful login. If you want the blocks to expire (which is more important if you use synchronisation) then you should tweak PURGE_DENY to a sensible value, for example 1 week.

Synchronisation is one nice feature of denyhosts that means that information on IPs that attempt SSH bruteforcing can be shared between servers. Information about synchronisation can be read in the FAQ but enabling it is as simple as uncommenting the SYNC_SERVER line. By default, your server will share information on bruteforcers and receive it from other administrators who run denyhosts.

You can check how denyhosts is working by watching the logfile at /var/log/denyhosts. You can see newly added blocks logged as a line like the below:

new denied hosts: ['202.107.228.xxx']

Of course, you don’t need this as you’ve already disabled SSH password logins and your firewall disables access to port 22 from anywhere except a specially crafted list of IPs. But for 5 minutes work, it provides some peace of mind.