I’ve been really discouraged by the overall lack of decent solutions for minimizing SSH brute force attacks. There’s the typical and obvious one’s, that just about every article states, like setting AllowUsers/DenyUsers, and setting PermitRootLogin = no. The problem with those, is while they may strengthen security, they don’t stop bots from trying to brute force your server, which does nothing from a performance standpoint. Since having multiple bots trying to brute force your server can cause server load to go through the roof, this can be very important.

Disabling passwords, and only accepting key based logins can make you more secure, however, it still doesn’t deal with performance issues. And also, if you have a drive failure, and loose your SSH key, how do you login? If nobody else can make you a new key pair, and login to copy it over, then you’re locked out of your own server. Also, how do you login from someone else’s computer?

You can move SSH to a different port, but then you have to update the config for all your users. This can be a big pain in the ass to handle, but it can solve both the security and performance issues with brute force attacks. Overall it’s pretty weak, though, since some bots have started probing other ports, like 2222, to see if SSH is running on it. It surely wouldn’t work for anything big.

Then there’s log-based learning, like fail2ban. I have a problem with this too, as log injection attacks can be used to trick the learning daemon into causing a denial of service attack. Overall, this is a pretty weak solution too. There’s already been proof-of-concept log injection attacks for just about every log based learning daemon, and there’s sure to by more in the future.

And on to iptables based solutions. By filtering at firewall level, you can see clients that are trying to connect to SSH. By far, the biggest weakness of this setup is it can’t determine if a login was successful or not, it can only see SYN packets. If you have it setup to block clients that try to connect 3 or more times in a minute, then three successful logins would cause a legitimet client to be blocked. While it may sound absurd that a client would login that frequently, it isn’t when you consider that tab-completion is available in SSH and SCP, and for each tab-completion event, SSH logs in then back out; the limit can easily be exhausted, and cause legit clients to be blocked.

There really needs to be a better solution. It seems like the only real way to solve this, is to build some kind of configurable adaptive firewall into SSH, itself, to detect and deny brute force attacks.

Now that I’ve had a chance to play around with Hardy, I’d thought I’d update my list of problems with it.

• TERRIBLE default fonts. Open /etc/fonts/conf.d/30-metric-aliases.conf and replace all occurrences of “Nimbus Sans L” and “Liberation Sans” with “DejaVu Sans” to fix them.
• Very slow and sluggish performance. Any SQL statements that perform a sequential scan, bring out the worst in it.
• Firefox Flash plugin crashes, and sometimes crashes Firefox. I’m not sure if this is because I’m on x86_64.
• Firefox extremely slow at times.
• Power Management extremely buggy.

I’ve been very disappointed with Ubuntu Hardy. By far, the most noticeable thing after installing it is how much slower it is. If you have a beefier system, you probably don’t notice it, but it’s very noticeably slower on my current system. After using it for a while, it really slowed down, and I noticed that the scrollkeeper process was sucking 80% of my CPU. I just killed that process and removed it from /etc/cron.*, so it wouldn’t be spawned again.

I decided to pull up PostgreSQL to run a quick benchmark. I created a very simple table and added 10,000 rows to it, to see how fast SELECT COUNT(*) performed. The results were shocking:

CREATE TABLE test (id INTEGER PRIMARY KEY);
INSERT INTO test VALUES (generate_series(1,10000));

EXPLAIN ANALYZE SELECT COUNT(*) FROM test;
                                        QUERY PLAN
--------------------------------------------------------------------------------------------------
 Aggregate  (cost=170.00..170.01...) (actual time=63.064..63.067...)
   Seq Scan on test  (...145.00...) (actual time=0.034..27.452...)
 Total runtime: 83.567 ms
(3 rows)

WTF!!??!? 83ms!?! On Feisty, the exact same thing takes 8ms, 10x faster than on Hardy! Something is seriously screwed up!

The first thing about Firefox 3b5 I noticed, is it sucks up way more CPU. Just scrolling down the page on some sites causes it to use 90% of my CPU, even with Smooth Scroll turned off. Just sitting idle it uses 1-3% CPU, which isn’t too bad, but FF 2 uses 0% sitting idle. The new UI is nice, though, and it seems “snappier” at times. Also, installing Flash works off the bat, which is really nice (before, I had to download the 32bit version of FF, and use it instead of the one that comes with Ubuntu).

One of the most irritating things about Hardy, is that Power Management is almost completely broken on my system. I set my display to go to sleep after 15 minutes… Three hours later, and it still isn’t sleeping. Now I have to turn my monitor off manually? Barbaric!!!

I don’t have any other criticisms for now. Everything else worked right away, and installing the proprietary NVIDIA driver was a breeze. Bluetooth support is enabled by default, and the usual GNOME improvements are nice… I’m sure I’ll find more to complain about later.

Update: after installing updates, Power Management is now working, and the entire system seems faster.

Update: Power Management is broken again… It works on and off.