Rust Sandwiches

Although I've made a number of posts relating to my research and planning, I haven't said much about the actual work in progress on my Beetle. Alas things are not going too well. Bad health, bad weather, and a need for out of stock parts have all played their part in delaying things however the largest factor has been that I keep discovering even more bits that need replacing.



I knew when I bought her that the left hand heater channel was in poor condition. I was quite pleased with myself at the time for spotting it because it wasn't glaringly obvious and in a matter of weeks, I'd gone from knowing almost nothing about cars to knowing enough about Beetles to spot it. However I failed to spot that during a previous repair, the heater channel had been welded to the floor pan. It's really obvious when you see it but I just didn't notice and the fact is that it's the same on the right hand side meant that both sides looked the same and didn't alert me to it.

That in itself is not a huge problem but in the process of removing the left hand heater channel and floor pan half I've also come to realise that the corner of the front-head base-plate is rotted away, along with the end of the front chassis support, where they bolt to the heater channel. At the back, the outer part of the rear cross member is rotten and there were so many bad areas lurking beneath thick layers of underseal in the rear wheel arch (covered by glued on carpet on the inside) that it probably makes more sense to replace the rear quarter rather than repair it.

Now while all of that is possible, it would be a heck of a lot easier with the body off. However, while I've got replacement floor pans for both sides and a new heater channel for the left hand side, the heater channel for the right hand side is out of stock. Remember that the one on my car is welded to the floorpan and you'll relised that I can't get the body off and make the car roadworthy again before I get my hands on a new right hand heater channel.

Vol 7 of the Bug Me Videos shows them removing a heater channel in one piece, and while that makes a lot of sense for demo purposes (and let's face it the new one is going to have to go in in one piece) it's not necessarily the most practical way to do it if there are 'unknowns'. I've already said that mine was welded to the floorpan but in the video they say that there are no welds along the top of the channel where it meets the front wheel arch on the inside of the car; just spotwelds on the outside. There clearly was a weld on the inside of mine and things became even more interesting when I started to cut it out. It turned out that there were four, yes four, layers of metal.

On top of the original, rusted to bits, heater channel was a patch. Presumably this had also started to rust at the bottom at some point because there was another patch on top of that, and another patch on top of that.

Now that I've got it out of there I can see that the bottom part of the front wheel arch also has a patch on the outside, plus a patch on the inside, and the original rusted piece of metal is sandwiched between the two. Clearly that's going to need replacing too.

Apparently there's a saying in VW circles about having replaced the bottom six inches of the car. I seem to be discovering what that means.

Opening Ports With PHP

In my previous post I described how I'd set up iptables. The important thing to note about that is that I set my default INPUT policy to DROP anything that isn't specifically accepted by a rule. This means that I can easily open and close ports using the iptables command to add or delete rules. For example, the following can be used to open the port for webmin:

/sbin/iptables -A INPUT -p tcp --dport 10000 -m state --state NEW -j ACCEPT

I can then close it again by deleting the rule with:

/sbin/iptables -D INPUT -p tcp --dport 10000 -m state --state NEW -j ACCEPT

Note that:

1. Webmin is always running, and listening, even when the port is closed, so I don't have to issue commands to start and stop it. I just need to open and close the port.

2. I don't have to leave the rule in place for the entire session as the commands above allow and disallow NEW sessions. Other rules in my iptables setup allow established sessions to continue. (Although in fact Webmin tends to stop and start the session as you use different elements of it so it's as well to leave the port open until you are done.)

3. The iptables command can only be used by root.


Now I'd like to be able to do the same thing with SSH but of course there's a catch: if I close port 22 then I can't SSH in to issue the command to open it. Don't get caught out by that one!

However, as mentioned in a previous post, my intention was to use a secret backdoor by getting one of my .php web pages to watch out for a special input and use exec() to run the iptables command. However there is a catch here also: the PHP script runs as apache but the iptables command can only be run by root.


Now there are a couple of ways around this and what I've chosen to do is to use the sudo command. This allows a user to run a command as another user however they have to be given permission in the /etc/sudoers file. I did this by adding the following line to the file (using visudo to edit it - as it tells you that you must in the file itself).

apache ALL = (root) NOPASSWD: /sbin/iptables

This gives apache the ability to run the iptables command without the need for a passwork. Shock! Horror! Isn't that a security problem?

Well, not really, the addition allows apache to run iptables, and that's it, nothing else. It's also important to realise that on my server, you cannot log in as apache, and in fact I am the only user allowed to log into my server at all. I am also the only person who can upload .php files to my server so I am the only person who could install a .php script that uses exec to run iptables as apache. Now even if somebody else did figure out a way to get around that, 'all' they would have achieved is the ability to open and close ports. They'd still need to crack other passwords before they could do anything useful/nasty. Furthermore, the instructions being issued to iptables are reported in my Logwatch report so I'd be made aware of it.

Of course if you don't have the luxury of being the only person who needs access to your server then you may be better to consider another approach. For example you could use your php script to create a file or change a setting in a database to act as a flag for a cron job. You would then create a cron job, which you set to run every couple of minutes, to check the flag and run the iptables command when the flag is set. The downside of course is that after setting the flag you have to wait for the cron job to run before you can get in. The upside is that apache no longer needs the ability to run the iptables command. Apache just sets the flag and the cron job (which you run as root) issues the iptables command.

Incidentally, there's a heap of info about the sudoers file available by typing 'man sudoers' at the Linux command line with loads of examples down at the bottom of the man page. Check it out and you will see that you have a heck of a lot of control over what you do and do not allow sudo to be used for. Given the various other restrictions on my server, I'm happy to allow apache to use sudo to run iptables and can therefore use the following PHP to open and close a port for SSH when I tell it to:

// create an iptables rule to allow access on port 22
exec('/usr/bin/sudo /sbin/iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT')

// delete the iptables rule to allow access on port 22
exec('/usr/bin/sudo /sbin/iptables -D INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT')

Note that my iptables setup (as I described a my previous post) is such that port 22 is open when my server boots, and I leave it that way.

Under normal circumstances, after rebooting the server, I would tell my PHP script to close port 22 and would then leave it closed when I'm not using it. However, I leave it so that the default after a reboot is to have it open. This means that if something should go wrong such that I can no longer access my PHP script to open the port (which I would need to do to change the PHP script), I can get it open again by requesting a reboot.

Watch out for this:

Perhaps the biggest headache that I had in setting this up was that initially I couldn't 'sudo' via exec(). I spent hours looking for the problem and it was driving me crazy because everything I found on the subject indicated that what I was doing was absolutely spot on. The breakthough came when it was suggested that I try this:

echo exec('/usr/bin/sudo /usr/bin/whoami 2>&1');

The result should be 'root' but what I got, courtesy of the bit on the end, was this: 'sudo: sorry, you must have a tty to run sudo'

A search on that told me that the issue related to a setting in /etc/sudoers which is used in Fedora Core 6 namely:

Defaults requiretty

I didn't get entirely to the bottom of why it's there. Something to do with there being circumstances when the password you are entering for sudo can be visible on the screen. Apparently it's a new thing in FC6 and all the advice I saw suggested that the solution was to comment it out (which leaves me wondering if that setting will still be present in FC7). Either way, I'm using sudo in such a way that I'm not typing a password so I don't see that it's an issue.

iptables

iptables is something that I've steered clear of until recently. Partly because it looks blooming complicated (and why bother when scripts such as system-config-securitylevel will set up a firewall without getting involved in the nitty-gritty), but also for fear of locking myself out of the server (which is 100+ miles away at a server farm and doesn't have a screen and keyboard attached). When I became interested in port-knocking however, it seemed that the time had come to do a little research.

The first bit of good news came when I discovered that you can 'mess' with iptables without making the changes permanent. When the server boots and iptables sets up the firewall, it loads rules from /etc/sysconfig/iptables however you can then change those rules from the linux command line using the iptables command. In fact you can create a script to delete the current rules and load a new set. The crucial thing here is that you do not edit /etc/sysconfig/iptables directly. Firstly because it's 'system generated' and secondly because if things go wrong, you can reinstate the original set of rules by rebooting the server. While I can't get physical access to my server, there's a mechanism by which I can request a reboot. Of course when you have a set of rules that work you will want the server to use them when it boots and you do this by issuing the following command causing the rules that are currently in memory to be written to the /etc/sysconfig/iptables file:

service iptables save

Safe in the knowledge that we can dabble, it's time to look at creating the script that will install our rules. The first three lines look like this:

#!/bin/sh
/sbin/iptables --flush
/sbin/iptables --delete-chain

Obviously the first line starts our shell. The next two lines clear out any existing iptables rules and user defined chains (of rules) that are currently in memory.

iptables works by looking at packets that are wanting to cross the firewall. These could be packets coming into the computer from the network, going from the computer out to the network, or being forwarded (if the computer is also being used as a router). Because of this it is normal for a set of iptables rules to start with a set of default policies such as:

/sbin/iptables -P INPUT DROP
/sbin/iptables -P FORWARD DROP
/sbin/iptables -P OUTPUT ACCEPT

I've seen examples sets that work on the basis of accepting anything that doesn't get blocked by a later rule, and I've seen others that block everything unless it's accepted by a later rule. I've gone for a mixture. Nothing comes in unless a later rule allows it. My server is not being used as a router so all packets for forwarding are dropped. All outgoing packets are allowed.

It might seem odd that you would want to do anything other than allow all outgoing packets however in a scenario where the computer is allowing a number of machines on a LAN to connect to a WAN, you may want to implement restrictions.

The next thing is to set up the loopback interface:

/sbin/iptables -A INPUT -i lo -j ACCEPT
/sbin/iptables -A OUTPUT -o lo -j ACCEPT

This allows local traffic such that daemons running on our computer can send packets to other daemons running on our computer via the firewall. Stricly speaking, we only need the first of the above lines in our script because our default policy for output already allows outgoing packets from our daemons.

With the default policies set up and our daemons able to talk to each other, our computer can see out, but nothing can see in. If this were a home computer being used to access the web, we could stop right here, however I'm creating rules for a web server and there's no point having a server if nothing can access it.

Before we create a few rules to open things up, it's important to understand that we can split and packets reaching the interface into one of two groups: those initiating a connection, and those that are part of an established connection. This simplifies things because we can allow packets for established connections to pass through unhindered because we already did all our checks before we allowed the initial connection.

/sbin/iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

The first line says that all new TCP connections must start with a SYN packet i.e. that they must start properly. The second line says that packets for established or related connections are allowed through. If we stop there then we will still be blocking all input because we haven't allowed anything to establish a new connection yet.

/sbin/iptables -A INPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 25 -m state --state NEW -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT

The three lines above allow new connections by accepting packets coming in on ports 22, 25, and 80 i.e. SSH, SMTP and HTTP. Note that this does not mean that anybody can connect via SSH. The still have to be on the list of allowed users and they have to know a password. The above simply means that the port it 'open' such that it is possible to connect.

We're almost done now although there are lots of other things that could be done with our rules and that you will see in other suggested iptables setup scripts. Sometimes you may need other ports open and sometimes you may want to do things like blocking traffic from IP addresses that are being a nuisance. You can also do things like locking out an IP (for a period of time) that has made more than a given number of connection attempts in a given amount of time. In a later post I'll describe describe a technique that I've implemented to greatly enhance the security of my server using iptables rules but in the meantime I want to make just one final addition:

/sbin/iptables -A INPUT -p ICMP --icmp-type 8 -j ACCEPT

This accepts incomming type 8 ICMP messages and allows people to ping the server. If this were a desktop computer from which I wanted to issue the traceroute command then I should also allow type 11 ICMP messages. However it isn't, so I won't, and our final script looks like this:

#!/bin/sh

# Flush old rules, old custom chains
/sbin/iptables --flush
/sbin/iptables --delete-chain

# Set default policies for all three default chains
/sbin/iptables -P INPUT DROP
/sbin/iptables -P FORWARD DROP
/sbin/iptables -P OUTPUT ACCEPT

# Enable free use of loopback
/sbin/iptables -A INPUT -i lo -j ACCEPT
/sbin/iptables -A OUTPUT -o lo -j ACCEPT

# All TCP sessions should begin with SYN
/sbin/iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

# Accept inbound TCP packets
/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 25 -m state --state NEW -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT

# Accept inbound ICMP messages
/sbin/iptables -A INPUT -p ICMP --icmp-type 8 -j ACCEPT

Of course the final steps are to save our script, make it executable, and run it as root. We then need to check that everything works as we expect. Most especially that we can still initiate new SSH connections to our server. When we are happy we use the 'system iptables save' command to write our configuration to /etc/config/iptables and we're done.

Thinking About Port Knocking

In a previous post I described how I'd tweaked my server's security with respect to SSH and Webmin however I really wanted to make it more difficult for a potential abuser to get anywhere near them. I also wanted, if possible, to rid my Logwatch reports of the hundreds (sometimes thousands) of lines reporting failed attempts to log in via SSH.

Using a non-standard port for these services is a commonly suggested 'solution' but while this may throw most of the current crop of bots off the scent, any half-serious hacker can easily do a port scan first. You can also be fairly certain that if the bots aren't currently doing a preliminary scan, it's only a matter of time before they will. Thus using a non-standard port is little more than a temporary side-stepping of the problem. Should you opt to try it, don't forget to open the new port in your firewall first or you'll lock yourself out of your server.

Secure Authentication - setting things up so that your computer authenticates itself to the server rather than logging in with a password - means you can then disable the ability to make connection by logging in with a password and this is very cool option so long as you don't find yourself away from home, needing to log into your server from another machine, and without your authentication keys on a memory stick.

Other solutions that I've seen use programs like fail2ban or denyhosts to scan logs and act upon what they find. Typically they'll scan the logs at a 20 minute intervals and block any IP address that has tried and failed to log in more than a specified number of times. As I see it, the problems with this type of approach is that you'll still see numerous attempts taking place because the IP address isn't blocked until the log scan takes place.

pam_abl, an addition to PAM, looks for repeated failures to log in and if a given IP address fails more than X times in Y seconds, it gets banned. This has a more immediate effect however the info I saw suggested that the bans were permanent and that's not what I want. Any defence mechanism that blocks IP addresses should also ensure that they are unblocked a short while later because if the attacker is logged into the web via an IP addess allocated from a pool at AOL or attacking via a hacked server, then you could end up blocking legitimate traffic when the address has been reallocated, or the server being sorted out. I guess using a cron job to unblock them would be an option.

Port knocking - a scheme by which you have to 'knock' on a number of prespecified ports in a set sequence in order to open another port - had an immediate appeal because the knock cab be carried out with something as commonly available as Telnet so getting access while away from your normal machine merely requires that you remember the port numbers. Wikipedia has a good article on port knocking with links to an article explaining how to do it using iptables (although you need to have the ipt_recent module loaded to do it).

However, while discussion port knocking over at the Fedora project forums (click here to see the topic), sej7278 suggested that you could use something on a webpage to trigger the opening an closing of a port. Further to that it occurred to me that you could use a url that was normally used for something else. For example, if the front page of my site were:

http://www.luntaticatics.com/index.php

I could use:

http://www.luntaticatics.com/index.php?open_port=22

to open SSH. All I'd need to do is to make the index.php script look for the additional parameters and use exec() to issue the command to open the port.

I'll explain how that works in a later post however for now I would just like to say to any crackers who may be reading this:

1. The front page of my site is not index.php and I'm not using a page at lunaticantics.com so you'll have to start by guessing the name an location of the .php file that I'm using. Note that there's no reason for the page to be linked into the rest of the site so you'll have to guess.

2. I wouldn't be so stupid as to use something as simple as open_port=22 and publish it here. So if you do manage to find the .php file, you'll need to guess what parameters are needed to trigger it. Note that there's no need for the parameter name and value to make any sense to anybody or anything other than myself and the .php script that's watching for it.

3. Probably your best bet for finding the above to monitor the network traffic to my server but even if you do find it, you will then need to figure out my SSH user login name, password, and root password (as described in my earlier post you can't just log in as root), and any failed attempts will be show up in my Logwatch report thus alerting me that you've found my port opener, and prompting me to change it.

Thoughts About Paint

Car paint is pretty tough stuff and readily stands up to the range of temperatures and humidities thrown at it by our British weather. The reason that paintwork needs maintenance is because it gets chipped, scratched, and defecated upon by birds (which, if you judge by the effects of their excrement, live on a diet of battery acid and paint strippper). Thus we need to repair damaged paintwork before rust takes a hold on the metal beneath.

Maintaining paintwork would be easy if we were happy to just rub off (note that any wax and dirt should be removed BEFORE you start with the abrasives) the damaged paint, and any rust, and blob on a couple of coats of paint. So why the hell are we so hung up on the idea that a car has to have a super-smooth, high-gloss, paint job that's a really pain in the ass to achieve and even harder to repair? Metallics are even more difficult to patch up, and even more popular!

Of course this is really good for the manufacturers because it means that most people simply won't bother, the car will rot, and the owner will be back to buy a shiny new one a heck of a lot sooner than if maintenance of old one had been easier. Given that maintainability is my number one priority with the ol' bug I'm determined not to go down that route. On the other hand, the rat look isn't to my taste either so I needed an alternative solution. Thus I began to consider things like camouflage and other patterns that would allow me to divide the surface a the car into smaller areas.

To be honest, the Beetle isn't that difficult to divide into small areas. All four wings can be unbolted. Hood, decklid and doors can all be removed or treated seperately. However, as I don't have a garage or suitable shed in which to paint panels and will have to work outside, dealing with areas of this size would still be very difficult. It's also the case that no matter how hard you try to match them, newly painted panels tend to look different to the others.

Having considered lot's of different patterns I've decided upon a cubist inspired (check out Picasso's analytical cubist works) pattern of rectangles and shapes in shades of pinky blue. Here's a mock up that I did on the computer:



I intend to apply the paint with a brush because it will be easier to get the effect that I want and using a variety of shades means that I won't be tied to any particular colour that may prove difficult and/or expensive to obtain at a later date.

Note that the patterns will not hide the shape of the car as much as they do in the mock-up because they'll be following the curves of the surface. I'll also be doing the painting a bit at a time, so the pattern will gradually spread accross the car, rather than trying to do it all at one.

Having come up with a plan for the outside/top of the car, I also needed a plan for the rest and in fact it's the other areas that are more prone to rust. While water runs off the exterior of the car it can get into cavities and get's held onto the underside of the car in a mud poultice. When rust does begin to form, the porous nature of the rust means that it holds moisture thus furthering to rot. Clearly this is something I want to prevent.

Weld-Thru Primer

The first thing I've done is to buy a can of Weld-Thru Zinc Rich Primer Aerosol from Frost and I'll be applying this to all cleaned up metal that I intend to weld.

Hammerite

The next thing is that I've bought tins of smooth black and smooth silver Hammerite paint for use on underbody areas including wheel arches and steering/suspension components. I'll may also be use some other colours under and inside the car before I install carpet and such.

Now I've heard a lot of criticism of Hammerite but it strikes me that most of the problems are caused because people don't use it correctly. Many years ago I used it on with a wrought iron gate and was disappointed to find that the gate started to rust again a couple of months later. It was only afterwards that I realised just how many mistakes I'd made:

Firstly, I cleaned the loose rust off the workpiece. But more than that, I'd cleaned it back to bright shiny metal. I had failed to realised that Hammerite paint is designed to bond to rust. If you're painting bright shiny metal, you should be be using Hammerite Anti-Rust Primer and not the 'normal' Hammerite paint.

Then I shook the tin. This was also a mistake because it introduces air which takes a long time to come out of something as thick as Hammerite. Hammerite, unlike Mr Bond's martinis, should be stirred and NOT shaken.

Then I set about painting by dipping my brush into the tin. Wrong again as this will contaminate the paint in the can as you move the brush from workpiece to can. What you should do is to pour the paint you intend to use into another container and if there is any left over it should be discarded and NOT returned to the tin.

Then I left it to dry overnight and applied a second coat the following day. It seems I really was determined to screw this up because, for it to do it's job, you MUST apply a second coat of Hammerite within four hours of the first such that it does all the chemical bond stuff that it needs to do in order to work. Leave it for more than four hours you're just wasting your time because the second coat won't 'react' with the first coat.

As I say, I've seen a lot of criticism of Hammerite, and the critics generally advocate alternative products that are harder to find and are generally somewhat more expensive. Having done a bit of research, I'm inclined to believe that the main reason that people have any more success with these 'more exotic' products is that they read the instructions and follow them whereas they assume they can use Hammerite like ordinary paint. Hammerite is NOT like ordinary paint and if you treat as such, you will fail to achieve the desired result.

Note that I've chosen to go for the smooth finished stuff (as opposed to the hammered effect) because I want to be able to inspect it for damage on a regular basis and it'll be easier to spot stone chips and the like on a smooth finish.

Dinitrol

While Hammerite should protect the areas where I can apply it with a brush, spraying it into cavities seems a bit hit and miss. On the other hand, products like Waxoyl and Dinitrol are designed for the purpose. These products can also be use to apply a waxy coating the underside of the car.

Bitumen based products are another option for 'undersealing' however the are frowned upon in car restoration circles. In this case I am inclined to agree as it seems that the problem with the bitument based products is that they tend to harden with age and that when they get damaged, water gets behind them, and the metal rots away out of sight behind the coating. Of course the only way to check for this would be by scraping the stuff off, and of course removing something to see whether it's still doing it's job properly is undesireable.

It strikes me that the same is true for the wax based products, many of which are brown or black. How are you supposed to tell if that uneven black/brown surface is still doing it's job or hiding rot? Thus my plan is not to use underbody seal but to paint these areas with Hammerite which I can then inspect and maintain. It has been suggested that I could use 'clear' Waxoyl however I am told that this is really a light brown/yellow colour as opposed to clear and it also presents the additional problem of having to clean it off in order to replain any damage that does go through to the paint. Better methinks to forget it and concentrate on maintaining the paint.

Of course the cavities are a different kettle of fish because I can't see inside heater channels and other seriously enclosed spaces to inspect/maintain them. Thus I figure that the colour of the protective wax is insignificant in these areas. The blurb in the Frost catalogue about Dinitrol Corromax 3125 says "A specially forumulated wax which penetrates rust and dirt preventing further corrosion." That sounds like just the ticket to me, even if it is brown.

Hot Spots

The final consideration is that there are a few places where special paints are needed. Exhausts and engine blocks need paint that will stand the heat and while I have no immediate plans to paint the engine block I do need to do something about the rust on my exhaust pipework. I've also obtained (from Frost) some special paint for painting brake calipers and drums.

Having formulated a plan, all I need to do now, is to get painting.

Urethane Parts for Beetles

Progress with the Beetle is slow but everybody warned me that I'd discover more problems than I could see initially and that it'd take longer than I'd anticipated to do the work; so while the nature of the extra problems and work is a surprise, the discover of it isn't. I'll say more about that in another post (it's about time I posted a progress report) because in this post I wanted to say something about urethane parts.

I'd seen them on sale in a number of places and was tempted by their pretty red colour. Of course I wasn't about go changing everything just because of the colour but when one of the rear bump stops broke off in my hand, such that new brackets and 'rubbers' were added to my shopping list, I thought I might give them a try.

Before diving in however I did a search on the VZi forum and was surprised to see that hardly anybody had a good word for urethane. I started a new thread to try to get to the bottom of it (click here) and based on this, plus a little reading elsewhere, I came to the following conclusions:

Most of the urethane parts for Beetles are for use in places where they will be flexed and/or squashed (as opposed to having mechanical movement against them). These inclide bump stops, suspension bushings and gearbox mounts. My research indicates that urethane parts are harder than their rubber equivalents so while they will hold a gearbox more firmly, they will also transmit more vibration into the car. This seems even more counter productive in the case of bump stops and suspension components where they will transmit more vibration, and shocks in the case of bump stops, to the metal components they are supposed to be cushioning. I've been lead to understand that this has benefits in off-road vehicles like dune buggies (where you're expecting a rough ride anyway) because they will last longer. It would appear however that the additional life of the component is little compensation for the loss of ride comfort and protention of other parts in a road car.

There is one major deviation from the flex/squash use of urethane parts in a Beetle and that is in the form of urethane bushings for the front beam where they are used as replacements for the original metal roller bearings and rubber seals. It seems however that they have only one advantage over the original parts: they're cheaper. They will (apparently) wear out much faster and the only argument that I've seen that held any water was that if you're using them in an off road car where you might anticipate knackering and having to replace bearings on a regular basis because of the way you are using the car as opposed to through normal wear and tear...

Thus I will be replacing my bump stops, and any other relevant bits, with rubber as I've concluded that while urethane parts might be of use on an off road vehicle or one whose primary purpose is to look pretty, they have no place on a road car intended for daily use.

Tightening Security on SSH & Webmin

I haven't finished moving everything over to my new servers yet however I am getting a few opportunities to look into new things and today I made a couple of changes to tighten up security.

In the greater scheme of things I'm not what you'd consider to be a prime target. I'm not mega-corp and I doubt there's anybody out there who hates my guts or wants to get into my systems in the hope of finding secrets. On the other hand, the fact that I am small-fry implies that I probably won't have paid too much attention to security issues and may be an easy target for being turned into a spam relay or similar i.e. the attraction of my server to a cracker is not what they might find on it, but what they might be able to use it for if they can get in.

A few days ago for example I awoke to a Logwatch report that telling me that another server at the farm where mine lives had made 400+ attempts to log into my server using SSH. I emailed tech support and got a reply about 15 minutes later saying that they'd checked it, shut it down, and emailed the owner. Now it's hardly likely that the owner of that server had instigated the attack, however they would be left with the big pain in the ass problem of finding out how their server was hacked and dealing with it. Obviously I want to do everything I reasonably can to make sure the same thing doesn't happen to me.

I am fortunate (by design) that I'm the only person who needs to log into my server. Thus I don't need to worry about other users having inadequate passwords or installing problematic scripts/programs. I have a firewall, and have shut down any services that I don't use (like telnet and ftp), so you might think I'd be happy to sit back an relax. However, as I am the only person who needs to use SSH or Webmin, (pretty powerful tools), I figuered that there were probably a few ways that I could make it harder for anybody to abuse them.

The most important line of defence is of course to have good passwords and if you don't know what I mean by 'good passwords', you need to do some research. If you are 99% sure that you do know: that's not good enough and you still need to do some research. If you are 100% sure then you are being way too arrogant and you still ought to do some research. The things is that this stuff changes and what we thought was a good password 10 years ago is mediocre by today's standards because the knowledge and tools available to the crackers is more powerful. Unless you did it just last week, do a search and read half a dozen current documents about passwords. If you find anything in any of them that you didn't know, read half a dozen more. My own current thinking on the subject can be found here.

Starting with SSH then:

It's fairly normal for my Logwatch reports to show a few hundred (occasionally a few thousand) failed attempts to log in via SSH. These are generally split between a dozen or so IP address (that change on a daily basis so there's little point trying to block the addresses), and several dozen common names. Amongst all the toms, dicks and harrys who don't even exist on my server (but are fairly common user names generally) there are also a good number of attempts to log in as apache, root, mysql, and other names that are pretty much always present on any LAMP server.

A fairly simple but substantial increase in security therefore is to create a user with a really weird name (that looks like a password), give them an equally cryptic password, and make them the only user with access to SSH. While brute force attempts to log in via SSH will regularly try lists of common names, they are highly unlikely to try 'random' collections of characters. You've now made it just as hard for someone to guess a user name as it is for them to guess a password. Of course this also means that when you log in via SSH you have to use the weird user name and su to root before you can do anything. A small price to pay and it also means of course that anybody who did guess your weird username and the weird password now needs to guess your root password too. That's "something blooming difficult" three times in a row and probably equates to something pretty near to impossible.

Of course that doesn't stop the failed attempts from bloating my Logwatch reports (something I'm looking into and will report on later) but it does mean that I can safely ignore them.

Having now made SHH a heck of a lot more secure, my other concern was Webmin. Again, I'm the only person who needs to use it but when I do I go in as root so there's 'only' a password between me any somebody else getting in there.

I did some searching and found this document (amongst others) that had some interesting information about securing Webmin. My setup was already doing things like using it with SSL however I did opt to go into Webmin: Webmin Configuration: Authentication and change the number of failed logins required before a host is blocked and the time for which it is blocked. These were set at 5 and 60 seconds but I reckon anybody who gets their password wrong five times in a row shouldn't be allowed anywhere near a server in the first place. As we're blocking IP addresses (as opposed to users) however we don't want an attacker who's accessing the server via somewhere like Tiscali or AOL causing an IP address that's been temporarily allocated from a pool being blocked for long periods of time either. As I'm the only one who should be using Webmin on my server I changed the values to 2 and 600.