The Node

Archive for September, 2010

Last time I talked about protecting your server from brute force attacks against your server, but what about the enemy within, like root-kits and viruses? Everybody is familiar with computer viruses these days, especially if you’re using Windows and entire industries have sprung up to combat this threat. While it’s true that viruses are commonly written to target Windows systems and rarely if ever affect Linux machines, they can still be present on your system even if they are incapable of doing any damage. Although they may be harmless on your Linux system (for now), you still want a way of getting rid of them, especially if you use your Linux server as a Windows file server with technologies like Samba.

While there are many commercial virus scanners available for Linux, I am going to concentrate on ClamAV, an open source virus scanner that is primarily intended as an email scanner for servers. While this is true, you can still use it as a stand-alone virus scanner and, being open source, the virus updates are free.

ClamAV is available for most Linux distributions, including Ubuntu and Fedora. To install ClamAV if it isn’t already on your system, you can install it with Fedora using: -

yum install clamav-*

and under Ubuntu, you can install it with: -

sudo apt-get install clamav*

If you’re using Ubuntu or Fedora as a desktop system with GNOME, you can use clamtk as a nice front-end for virus scanning by simply running: -

clamtk

After that, the user-interface is pretty straight-forward and I imagine you can work it without any help. However, I’ll concentrate on using ClamAV in a server environment, as that is my primary interest :-)

Once ClamAV is installed, you can get the latest virus definitions database with: -


/usr/bin/freshclam


and if your virus definition is up to date, you’ll see out something like: -


main.cld is up to date (version: 52, sigs: 704727, f-level: 44, builder: sven)
daily.cld is up to date (version: 12038, sigs: 132716, f-level: 53, builder: guitar)
bytecode.cld is up to date (version: 74, sigs: 10, f-level: 53, builder: edwin)


Once this is done, running ClamAV is simplicity itself: -

clamscan -r -l /var/log/scan.log /home/user

The above runs ClamAV recursively against the “home/user” directory and puts the output of the scan into file /var/log/scan.log. Once the scan is completed you can either check the log file manually, or run a quick grep to see if it found anything: -

cat /var/log/scan.log | grep FOUND >> /var/log/found.log

This outputs any “FOUND” entries to /var/log/found.log along with the complete file path to the suspect files. Very useful! I like to setup ClamAV to run as a cron job with something like the following (remember to run as root!): -

My avscan.sh bash script file looks like this: -

#!/bin/bash
/usr/bin/clamscan -r /home >> /var/log/scan.log
cat /var/log/scan.log | grep FOUND >> /var/log/found.log


This will check every user’s /home directory for viruses. Remember to make your script file executable with

chmod u+x avscan.sh

I then add a cron job by running: -

crontab -e

and adding the entries: -


0 1 * * * /usr/bin/freshclam >> /var/log/freshclam.log
0 4 * * * /root/avscan.sh


This will run a virus definition file check at 1am every day and append the output of this check to the /var/log/freshclam.log file and then run the above virus scanning script at 4am every day, appending the output to the /var/log/avscan.log. This should alert you to any viruses present on your system.
Okay, so that’s viruses out the way, what are root-kits then? A root-kit is a piece of software that enables continued privileged access to your system while actively hiding its presence from the administrator by posing as some innocuous system command. Typically, a hacker installs a root-kit on a computer after having first obtaining user-level access, either by exploiting a known vulnerability or cracking a password via brute force methods like I discussed before. Once a root-kit is installed, it allows an attacker to mask his intrusion while gaining root or privileged access to the machine. So it’s a good idea to scan for known root-kits on your system in much the same way as you would for viruses. For this, I’m going to use a utility called rkhunter, which is a root-kit scanner for *nix systems. It will scan your system for known root-kits, backdoors into your system or suspicious files and alert you if it finds anything. It works by comparing SHA-1 encryption hashes of important files with known good ones in it’s online database and searching for default directories of known root-kits, wrong permissions, hidden files, suspicious strings in kernel modules and things like that. Be warned, like all root-kit scanners, it does sometimes come up with false positives which I will cover in a bit. First we have to install it on our Fedora system with: -

yum install rkhunter

and under Ubuntu with: -

sudo apt-get rkhunter

You can even install it from source if you’re using another distribution with: -


wget -c http://downloads.rootkit.nl/rkhunter-1.3.6.tar.gz
tar -zxvf rkhunter-1.3.6.tar.gz
cd rkhunter-1.3.6
./installer.sh


Once rkhunter is installed, you should first update rkhunter’s database with the latest known root-kits to search for: -

rkhunter –update

Once you’re up to date, you can run rkhunter directly with: -


rkhunter -c -sk


This will output the results by default to /var/log/rkhunter/rkhunter.log. The -sk flag simply overrides rkhunter’s propensity of asking you to press “enter” after each section of the scan. If you want to review the output as it happens, you can miss out this switch. After a while, you’ll get a summary something like: -


System checks summary
=====================

No warnings were found while checking the system.


In this sample, the system is clean and nothing untoward was detected.

I’ve got a positive! Is it real?

Probably not, although it doesn’t hurt to check. Remember that rkhunter stores the SHA-1 hashes of significant files on your system in it’s database. If you’ve recently updated your system, these files will be out of sync with rkhunter. If you’re unsure if you have been rooted or not, you can reinstall these files with yum or via an RPM file or a backup. For example, say that rkhunter states that the “mailx” application is actually now a root-kit, I could use yum to reinstall that package: -

yum reinstall mailx

…just to be safe. You can then update rkhunter’s database with the new hashes, so it won’t detect them in future: -

rkhunter –propupd

This way a fresh copy of your current system state will be used the next time you run rkhunter for scanning. These are pretty much all the useful flags you might want to use, but there are many more switches via the man page for rkhunter at “man rkhunter”.
It’s also useful to set up rkhunter as a cron job. First, create the bash script: -


vi rkhunter.sh


and enter the commands that will first check that rkhunter is up to date and then run a scan: -


#!/bin/bash
TODAYS_DATE=`date +%F`
/usr/bin/rkhunter --update
/usr/bin/rkhunter -c -sk --cronjob | mail -s "${TODAYS_DATE} - rkhunter Scan Report" root@localhost


This will e-mail the results to “root@localhost”, but you can change this to whatever you like, assuming your Linux box has outisde access. Enter your root user crontab with: -


crontab -e


and enter the following: -


30 4 * * * /root/rkhunter.sh


This will run my rkhunter script at 4.30am everyday, mailing the results to your system root account. If you’ve not got e-mail access, you can follow my tutorial on using sendmail to route system e-mails to any e-mail account :-)

With the release of Fedora 14 just around the corner I thought it would be a good time to revisit my post about who exactly Fedora Linux is aimed at. In that post, I commented about the clear vision that Ubuntu Linux has for the desktop and how this vision is seemingly not present for Fedora. Ubuntu, with it’s marketing clout and stewardship from Canonical obviously have a very clear goal for Linux – to finally make Linux great for desktops. BUt nobody ever really thought to ask why. This “shine” extends to their website which is streets ahead of Fedora’s rather timid site. Marketing and a shiny website may not be everything, but it’s sure helped Ubuntu. Canonical may have it’s share of detractors in the open source community, but you can’t deny their skill in getting eyeballs to desktops. Everybody knows from the recent war of words about how much code Canonical allegedly contributes back to the open source community compared to Red Hat (which is an open source company through and through), but Canonical have had remarkable success getting Linux pushed through to the average computer user even if they cannot boast the same type of revenue that Red Hat commands in the enterprise. And make no mistake, the enterprise is where the money is. Red Hat has made a bucket of money with it’s certification programme and support contracts. And you can bet Canonical see that revenue stream. Canonical’s mission to make Linux great on the desktop is a fine and laudable goal – I mean, somebody had to step up and really try for it. But that’s only part of the reason, I think.

I quite like Ubuntu especially with version 10.04. I think the new GNOME desktop is great, I like the Software Center and Ubuntu One cloud services and all the little things like a separate netbook edition for my Samsung N120. I don’t even mind Canonical moving the window buttons to the left. I just don’t like Debian-based systems (such as Ubuntu) quite as much as Red Hat ones (like Fedora). But based on the amount of content out there on the net, I’m in a minority – at least for desktop users.

If Linux has any awareness with the general public, it’ll be Ubuntu that they know about. For them, Ubuntu is Linux. While general public perception isn’t strictly necessary for any Linux distribution to succeed, it gets you hearts and minds. Computer folk who want to try Linux and learn about Linux will try Ubuntu first simply because that’s what they’ve heard about. And as Microsoft know, if you get ‘em young and get ‘em early, this is the experience and skillset they’ll potentially take into the workplace. So you’ll no doubt see more Ubuntu systems appearing in organisations because that is the distro that people know and use at home and this could be dangerous in the long-term for a Red Hat-based distro and Red Hat themselves. These things tend to have a cascade effect. Red Hat like servers and enterprise stuff and that’s fine…but they could end up being blindsided by Ubuntu by continuing to disregard the desktop and the importance it has for what people end up learning. Red Hat’s CEO Jim Whitehurst doesn’t get the desktop and even said so.

“First of all, I don’t know how to make money on it. Very few people are running a desktop that’s mission-critical, so they do not want to pay the company for a desktop OS.”

and…

“There is some money in the Linux desktop, but not much. We do have a desktop [version of Linux], but we typically sell it to big server customers who want some desktops. The concept of a desktop is kind of ridiculous in this day and age. I’d rather think about skating to where the puck is gong to be than where it is now”

What Jim misses here is that the Linux desktop is not about making money – at least not directly. It’s about exposing users to your distribution and your way of doing things rather than somebody else’s. Because that’s the knowledge they’ll pass around, that’s what they’ll recommend at work and that’s what people will end up using in the server room. Why is that so hard to grasp? Canonical get this just fine. Granted, Fedora doesn’t depend on Red Hat as it’s a community project – anybody can contribute to Fedora in the same way Red Hat does, but for all intents and purposes Fedora is what RedHat Enterprise Linux becomes and Red Hat sponsor Fedora and commit a lot of code and time to it for exactly that reason and seeingly only for that reason. This is a mistake. Perhaps the Fedora Project people see this even if their sponsors at Red Hat do not.

With the release of Fedora 14, Fedora is obviously trying to remedy this situation a little (with or without Red Hat) as the follow Fedora Project tweet stated: -

Want to do something great for #Fedora advocacy? Help our Marketing team create one-page notes for F14! http://2tu.us/2q74

With the kind of apathy from Red Hat displayed above to desktop Linux, it is any wonder that the Fedora Project is basically asking it’s users to market it for them? Ubuntu don’t have this problem with Canonical :-)

If you follow the link in the tweet, you’ll end up on a page that asks you to dispell “common Fedora myths” such as the perception that it’s merely a proving ground for new technologies.

MYTH – Fedora is unstable and unreliable, just a testbed for bleeding-edge software

FACT – This myth comes from misunderstanding two things:

Red Hat Enterprise Linux (RHEL) is derived from Fedora every few years.
Fedora has rapid releases, a short life-cycle, and a lot of new code.

The first item means that Red Hat uses Fedora as a platform to promote the development of new technology, some of which might end up in Red Hat Enterprise Linux, and be inherited by other derivative distributions. Red Hat contributes to Fedora efforts in the same way as any other contributor can. Fedora provides a platform in which any contributor, large or small, can integrate and offer technologies for a large audience of consumers. This does not mean that Fedora is untested, it simply means that Fedora is a rapidly progressing platform.

For the second item, this does mean that Fedora is often running in uncharted innovative territory, but not that it is using too-new code. The programs in Fedora are generally stable releases or well-tested pre-release versions. There are guidelines behind the inclusion of pre-release software, and thorough testing is always done prior to Fedora releases. Refer to QA for more information about our extensive quality testing practices, which, like all other Fedora teams, are open to community participation.

Each new Fedora release receives updates from the Fedora community for two subsequent releases, plus one month — on average, about thirteen months. We do everything we can to make sure that the final products released to the general public are stable and reliable. Fedora has proven that it can be a stable, reliable, and secure platform, as shown by its popularity and broad usage. Additionally, our well-managed packaging and review process adds an extra layer of safety not found in some other distributions.

You can count on Fedora.

Well, that’s fine – I personally have had no problems with stability in Fedora. I love it and use it every day. But nobody seems to have told Fedora’s project leader that…

Red Hat uses Fedora as a proving ground for new technologies for its RHEL (Red Hat Enterprise Linux). While not all of the features in Fedora end up in RHEL, it is a good way for people to test and use features before deploying them in a production environment or using them as part of RHEL, said Paul Frields, Red Hat’s Fedora Project Leader. A combination of Red Hat and third-party developers contribute code to Fedora, and Frields manages the integration of Fedora features into RHEL.

Now, stability and use in a production environment may be two different things but to most people if a piece of software is not suitable for a production environment, it is unstable. Mixed messages there! The other problem which Fedora has freely admitted above is the quick turnaround of releases. On average a new version of Fedora comes out every six months. Ubuntu throws a version out almost as quickly. The difference is that that every two years or so, Canonical release a version of Ubuntu which is an “LTS” release – a Long Term Support release. With an LTS version you get 3 years support on Ubuntu Desktop, and 5 years on Ubuntu Server. That’s pretty good as Canonical make no distinction between commercial and free releases. There is no such long term support for Fedora. If you need that, you’re supposed to download CentOS instead – the free version of RHEL which is binary compatible and just as stable. But CentOS, while great, is not a desktop operating system and never claimed to be. It’s packages don’t change very often to keep it in line with the older but proven RHEL packages. Fedora only offer support for thirteen months for each version and then you need to upgrade. While I’ve never had a problem doing this, it’s a deal-breaker for some…especially if they’re asking for help with Fedora on Linux forums. If you’re at End of Life for a particular version of Fedora and have a software or configuration problem, you’ll more than likely just get told to upgrade to the latest version. New users don’t want to hear that and nor should they have to.

As I’ve said before, I love Fedora and want to see it succeed. I think it’s file-system and account settings are far saner to navigate that Ubuntu’s, regardless of the GNOME shine that Ubuntu has added. I just wish somebody at Red Hat would wake up to the fact that, although the desktop may not be important to Red Hat’s bottom line right now, it will be and Fedora (as the second most popular Linux distro) is the path that most will tread if they are to use Red Hat Linux. Desktops gain you users and the Fedora community needs somebody like Canonical to show Red Hat the way. Canonical appear to be taking the long-term view that will eventually win them a foothold in the server room and they’re doing it on less money. Why can’t Red Hat do that in the other direction? They can surely afford it.

For this reason, I believe Red Hat needs to commit to Linux on the desktop far more than it has been doing and this includes lending marketing muscle to the Fedora Project and basically throwing money at them, even if it sees it as irrelevant to it’s core enterprise server business at the moment. The Fedora Project also has to either slow down Fedora releases or implement an LTS programme much like Canonical do. What can really be achieved for a whole new release version in six months? Does that really get users excited enough to try it? I don’t think so.

It wouldn’t take much of Red Hat’s banked earnings (compared to Canonical’s at least) to really push Fedora as a “gateway drug” to it’s own commercial Enterprise-level Linux distro. And I think they should do just that.
I’d just like Fedora to have the same kind of desktop polish and consideration for ordinary users that Ubuntu has because I think it’s a great system to use and I think Canonical have the right idea with their approach. It’s simply a shame that Red Hat don’t see it because whether they like it or not, I have a sneaking suspicion that their future may well end up depending on Fedora.

Last time I wrote about basic server security, I talked a little about ports, firewalls and SSH. You’ll probably notice after a time that you get lots of failed attempts to connect in your /var/log/secure system logs, sometimes directly to SSH but especially if you use such juicy services as FTP. These are more likely to be automated scripts running against your server rather than somebody actually trying to get in as they tend to use accounts such as “Administrator” to try and gain access and they’ll hit these accounts over and over with common passwords. While these are annoying, it would be useful to block such attempts at the system firewall level. This is where a little tool called fail2ban becomes handy. It’s a tool that monitors your system logs (such as /var/log/secure) for failed connection attempts and when a certain threshold is reached, will dynamically add rules to iptables to ban that IP address for a certain amount of time. Usually this is enough for the attacking host to give up and move on. It sure beats manually adding IP addresses to your firewall rules for each attacker and I’ve found it incredibly useful. I often get entries such as the following in my /var/log/secure system log: -

Jan 23 14:04:14 Fedora6Srv1 vsftpd: pam_unix(vsftpd:auth): authentication failure; logname= uid=0 euid=0 tty=ftp ruser=Administrator rhost=123.123.123.123

Here, a remote host “123.123.123.123″ is trying to use a default Administrator account on FTP to try and gain access and this is the sort of thing that fail2ban will monitor. fail2ban is available through most distribution repositories, but since I use Fedora, this is the command I’ll use to install it: -

yum install fail2ban

Once this is done, you’ll need to edit the /etc/fail2ban/jail.conf which controls the default behaviour of fail2ban. You can leave the /etc/fail2ban/fail2ban.conf on the defaults for the most part.

The first section you’ll see is [DEFAULT], which are settings that apply to all other sections below it unless specifically overridden.


[DEFAULT]

ignoreip = 127.0.0.1 192.168.1.172
bantime = 1000
findtime = 1000
maxretry = 3
backend = auto


“ignoreip” contains a list of space-separated IP addresses that you wish fail2ban to ignore. Here I’ve set the localhost IP address to be ignored, else fail2ban will ban itself from connecting and another machine in my local network.
“bantime” is the default number of seconds a specific host should be banned for in seconds. “findtime” is a setting that states that a host is banned if it has generated “maxretry” attempts during the last “findtime” in seconds. “backend” should generally be left as auto.

After this, you’ll see various services that fail2ban can monitor – we’ll concentrate on SSH and vsFTPd, although you can add other by setting “enabled” from false to true.


[ssh-iptables]

enabled = true
filter = sshd
action = iptables[name=SSH, port=ssh, protocol=tcp]
sendmail-whois[name=SSH, dest=root, sender=root@localhost]
logpath = /var/log/secure
maxretry = 3


Above is the jail.conf entry for monitoring SSH. The default log path for Fedora is not correct, so I’ve set it to monitor the /var/log/secure log file as this is the log where all failed connection attempts are logged. This has been set to enabled and I’ve also set the “sendmail-whois” to mail the WHOIS details of the attacking host to the root system account – useful to see where the attacker is coming from :-) I’ve set the “maxretry” for SSH connection attempts to 3.

Next, we’ll set fail2ban to monitor vsFTPd as well.


[vsftpd-iptables]

enabled = true
filter = vsftpd
action = iptables[name=VSFTPD, port=ftp, protocol=tcp]
sendmail-whois[name=VSFTPD, dest=root@localhost]
#logpath = /var/log/vsftpd.log
logpath = /var/log/secure
maxretry = 10
bantime = 1800


The above details are similar to the entry for SSH, except that I’ve set the “logpath” to /var/log/secure again, as /var/log/vsftpd.log only logs successful connection attempts and what a connected host has downloaded. I’ve upped the “maxretry” number because if you’re using a browser-based FTP client by using ftp:// instead of http://, this sometimes logs many anonymous connections even if you’ve got a password-protected FTP account as the browser seems to attempt to connect anonymously before it thinks to ask for your login details.

Once you’ve set up the service entries pointing to the correct log files that log such connections, you’ll want to set fail2ban to start in certain Linux runlevels automatically. I’ll set it to run in runlevels 3, 4 and 5 as these are the most common.

chkconfig --level345 fail2ban on

And lastly, start the fail2ban service: -

/etc/rc.d/init.d/fail2ban start

…and you’re done. Any failed connection attempts from a specific host that exceed the number that you’ve specified to the services you’ve defined will now be banned by iptables dynamically and the WHOIS details mailed to your root account. Fail2ban logs to /var/log/fail2ban.log by default (you can change this path in the /etc/fail2ban/fail2ban.log file), so you can check that file to find out if/what hosts got banned. You can also list your current iptables firewall rules with: -

iptables -L

to verify the current firewall rules and that fail2ban is writing blocking rules if you wish. Happy banning!

I’m always torn about Apple. On the one hand I like their hardware, especially the iPod which is far and away the best music player out there. On the other hand, Steve Jobs appears to have gone mad with power in the last decade or so and gone gang-busters to lock everyone into a walled garden. It’s the Apple way or the highway, buddy. I know why he’s doing it – for most people, a controlled computing environment free from viruses and malware would suit them just fine and lead to a safer Internet if nothing else. I mean let’s face it, most people don’t give a hoot about software freedom. But Apple’s strategy sometimes confuses me.

I was reading this article in the Guardian’s Tech section detailing John Naughton’s opinion that iTunes is out of date and needs to be rewritten. I can heartily agree – although not for exactly the same reasons. Mr Naughton appears to think that feature creep is the main problem with iTunes these days. The Ping social music network is the latest addition to iTunes version 10 although not one that I’ve used myself and it appears that it is this addition that is the main thing that has drawn the ire of many a blogger. Has iTunes got too many things in it now? It’s certainly puzzling for a company that prides itself on the user experience and the design of it’s products that iTunes seems to be such a confusing mess of functionality. Ping, the iTunes Store, a media player and god knows what else. This hasn’t really bothered me to any great extent however – it’s easy enough to get around after a fashion although I’m sure a case could be made for the poor layout.

No, my major complaint against iTunes is the fact that it is such a god-awful buggy pile of junk. Before I start getting hate-mail from indignant Apple users stating that the Mac version of iTunes is just fine, thank you….I don’t own a Mac so I couldn’t comment, although I plan to someday if only to experience UNIX with the shiny Apple joy. While Apple Macs are certainly selling more than they used to, the sheer number of iDevice users really dictates that most users of iTunes are Windows users. And iTunes under Windows is essentially a crime. Every time I get a new album to put on my iPod or think about downloading this week’s Linux Outlaws podcast, I eye my Windows 7 laptop with a vague feeling of dread, fully aware of the battle I’m about to engage in and already imagining the key combination that will bring up the Task Manager so I can kill the “Not Responding” iTunes process again and begin the whole tiring procedure for the fourth time in an hour.
While I’m aware that at least part of the blame can probably be laid at Windows feet in regards to application and process stability, surely not all of it can, right? It may make sense to Apple for people buying Apple’s products for the first time to recognise a superior experience on OSX than Windows, but that can’t be all of it because Apple still has a vested interest in Windows iTunes. They’ve sold so many iPhones and iPads that Mac and OSX, while gaining ground, are still a tiny percentage of the market compared to Microsoft’s juggernaut. Most people who use iTunes are still probably doing so on a vanilla Dell under Windows. Even if they’re not, I find it hard to believe that iTunes under OSX is such a different beast that many of the complaints of Windows iTunes suddenly no longer apply.

It’s puzzling that Apple hasn’t done anything about the iTunes situation because as many writers have noted, iTunes really is the keystone in the Apple Media Empire. As Mr Naughton notes above, there is actually very little you can do with an iDevice that doesn’t hinge on using iTunes to some degree whether it’s putting music on your device to actually making Apple money by using the iTunes Music and App Stores. Apple need iTunes to keep selling iPads and iPhones. A perfect time to announce an updated iTunes would have been their recent media event when the Ping social network was announced as the latest addition to iTunes 10. If Apple want to keep selling iDevices, iTunes is required – but Ping isn’t. So why is the experience such a dreadful one for the majority of users? Apple can’t be foolish enough to hope that once users realise that updating their 64GB iPad on Windows is such a painful experience, they’ll run out and buy a Mac to mitigate the bug-fest of Windows iTunes can they?
But then, software has never really been Apple’s focus. They are and always have been, a hardware company. iTunes is there to sell iPods, not the other way around. Perhaps we all got caught up with the fact that OSX is an excellent (albeit closed) operating system and expected that attention to detail to extend to iTunes. I don’t know. But I think Apple is making a grave error – if iTunes fails, all Apple’s devices fail because Apple has engineered it so that using them without this bulky, slow and buggy software colossus is pretty much impossible. Certainly if Apple wants to make money, people need the iTunes Store.

So Apple needs to step up and rewrite iTunes completely (and quickly) before the whole thing falls apart.

The only other possibility for this perceived apathy to their golden goose is that Apple has been quietly working to retire iTunes. You’ve only got to look at Google to see how that might be done – with a web application, HTML5 or otherwise. It always bothered me that there wasn’t an “itunes.com” where you’d login and do pretty much the same things that are currently done with the iTunes client.

The iTunes store makes sense as a web application in the same way Amazon does as a website – you wouldn’t use Amazon if you had to download a 90MB client to buy a book would you? Ping as a social networking tool doesn’t make much sense being locked into a fat client-side piece of software, not in the age of Facebook anyway. And a iTunes as a clean, standards-compliant web-app would wrap up the last bit of the market – those of us who want to use our iPods with something other than Windows or a Mac. Linux users, basically. Because iTunes sure doesn’t run well under WINE. Why would it, when it runs so badly natively? Granted, Linux users are probably not Apple’s main concern, being slightly more resentful of Apple’s all-encompassing computing eco-system but if they’ve got iPods and iPhones they’re still Apple customers, right? So even if an iTunes web-app meant that a small percentage of people would continue to use Linux rather than bite the bullet and go Mac, Apple would still be selling them an iDevice. Granted, a mechanism would be needed to actually transfer your iTunes Library to your device, but a client-installed “iTunes” browser plugin would take care of that, much like Google’s Voice/Video chat does today. If you offered a small plugin for Firefox, IE, Chrome and Safari, you’d still have more audience market share than a huge client for only Mac and Windows.

So what’s Apple’s problem? Are they simply biding their time to create a cleaner, redesigned iTunes client (web application or not) or do they simply not have the foresight or software talent to bring iTunes up to speed with the rest of their product line? For a piece of software that is so important to them, they don’t seem to be giving it a lot of love. And this could be a huge mistake for them in the future if they don’t act.

If I must use iTunes to use my iPod, I’d rather do it without having to see Windows Task Manager every ten minutes, please.

Server security no matter what operating system you’re using is a big deal. It may not be such a huge deal for a home server or, depending on your data, it may be a very big deal. Today, I’m going to talk about various things you can do to improve your server’s security. I say improve because, as everyone should know, if a hacker is determined enough, they will eventually compromise your system. Fortunately, I doubt your home server is important enough to anyone to have to withstand that sort of sustained attack, but it never hurts to use some common sense and secure your system as best you can. Here I will touch on various things you can do to at least keep your system secure from the kind of casual penetration attempts that will happen if your machine is connected to the wild n’ wooley Internet.I will stress here that I am not an expert on server security, I simply employ a little common sense to prevent most casual attempts to hack into my system. Hopefully this stuff will at least perk your interest enough to look into your own security setup and how you might improve it. Please note that I use Fedora for all examples given, but it shouldn’t be too hard to change for other distributions.

The first thing to do is to use really strong passwords. By this I mean passwords that are difficult to guess, so nothing that is the name of your dog, birthdays, family members or anything that somebody might logically try to use that they might find on social networking sites or Google or anything like that. While shadowed password files now mean that any user on the system cannot just filch the /etc/passwd file and run a brute force attack to get the root password, brute force programs can still run against common accounts with dictionary words over and over in the hopes of guessing the password. And obviously the root user is the one account that is guaranteed to be present on your system. So don’t use dictionary words as passwords. Best practice is to use a long password with a mixture of letters and numbers of various cases, but not something obtuse enough that you cannot remember it.

Remember only to expose system accounts to the wider Internet that you need. For example, you might want to disable remote access to your root account and use a nice strong password for your user account. Not only does an attacker need to guess your user account name, but also the password – while the root account as mentioned before is bound to be on your system. To disable the root account from being accessed remotely via SSH, you can edit the sshd_config file and disable root login: -

vi /etc/ssh/sshd_config

Add the following line: -

PermitRootLogin no

You’ll need to restart your SSH daemon for this change to take effect.

/etc/rc.d/init.d/sshd restart

When you now try to login via SSH as root, you’ll get an Access Denied error. The next thing you can do is to run SSH on a non-standard port. SSH normally runs on port 22. To make things a little difficult for a hacker, you can run SSH on any port, although it’s a good idea to use one above 1024 so that it doesn’t interfere with standard network services that might run on ports below that. To do this, edit your /etc/ssh/sshd_config again and edit the line: -

Port 22

…to be a different port, such as 47002 for example. As above, make sure you restart your SSH daemon for this change to take effect. While we’re here, this is a good place to talk about iptables – a common Linux firewall. Once you have changed your SSH default port, you will obviously have to change the firewall port associated with SSH so that you can still accept SSH connections remotely to your machine. I like to have a default set of basic ports open to the outside world kept in a file called “/etc/sysconfig/iptables.BACKUP”. The way to create this file is to edit the “/etc/sysconfig/iptables-config” and add the following line: -


IPTABLES_SAVE_ON_STOP="yes"


When you next stop or restart iptables with: -

/etc/rc.d/init.d/iptables restart

the file “/etc/sysconfig/iptables” will be created. This is a list of all ports that iptables keeps open. It’s nice to have a backup of your iptables configuration as it’s easily editable if you want to open/close other ports. So copy this file to your backup file with: -

cp /etc/sysconfig/iptables /etc/sysconfig/iptables.BACKUP

This file has entries such as: -


-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 47001 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 47002 -j ACCEPT


In the above example, ports 80 (HTTP), 47001 and 47002 are open. You can add comments to this file with the ‘#’ to remind yourself which ports are open for which services and add others as need be to your .BACKUP file. You then have a nice safe “baseline” iptables configuration for your system which you can copy to the “/etc/sysconfig/iptables” file and simply restart iptables for this firewall configuration to take effect with: -


cp /etc/sysconfig/iptables.BACKUP /etc/sysconfig/iptables
/etc/rc.d/init.d/iptables restart


Only the ports defined in the “/etc/sysconfig/iptables” file are opened on iptables start/restart. Prevents you needing to add ports on the fly with your iptables command! I find it very handy as I know only the ports open in this file are actually open on system reboot and I can customise it as needed.

You should essentially have two firewalls on your system – your router firewall which exposes ports onto your home network to the wider Internet and your server firewall itself. For example, I might have the Samba service open on my Linux server to expose Samba services to my local area network, but I wouldn’t open these ports on my router firewall because I don’t want the wider Internet to access my Samba services. Likewise, I would possibly have ports open for SSH on both my Linux server firewall and my router firewall because I want SSH to be available from the wider Internet so I can access my Linux server remotely. And remember to change the default password on your router web admin screen – hackers love accessing your router with well-known default router passwords – default passwords are available on the Web for most common makes and models. I’m actually surprised that the ISPs never ever mention to do this.

That covers the basics of iptables, user accounts, root access and passwords. Next time, I’ll talk about different services you can use to strengthen the security of your system.

When I built my first Linux server, I had terrible trouble with secondary SATA drives dying unexpectedly. The first time this happened, I had no warning at all, the drive simply went into read-only mode and then vanished from the system, never to be mounted again. While this taught me never to use old drives that I had lying around for important data, it also taught me that I should have been using SMART monitoring tools :-)

While I’ve discussed such data retention techniques as backups and RAID here before, it’s always useful to know when a drive is becoming unreliable if only to prevent system downtime through drive replacement.

SMART stands for Self-Monitoring, Analysis and Reporting Technology and is a technology built into many ATA-3 and later ATA, IDE and SCSI-3 hard drives. The purpose of SMART is to monitor the reliability of the hard drive, predict drive failures and to carry out different types of drive self-tests. It will help you monitor a hard disk drive’s general health and allow you to check a drive for errors, thus giving you a heads up to perform an important backup before the drive kicks the bucket.

While SMART works with many operating systems such as FreeBSD and Windows, obviously here, I’ll just be talking about Linux :-)

First, you’ll need to install the software tools that will allow you to take advantage of SMART as, at least under Linux, it is not installed by default. For Debian-based systems, you can install it with: -

sudo apt-get install smartmontools

And for Fedora/CentOS or other RedHat-based systems, you can install it via Yum using: -

yum kernel-utils

Once you’ve installed the SmartMonTools, you’ll need to check that the drive in question is actually SMART-capable. I’ll assume that you’re checking the secondary drive on your system which is typically /dev/sdb.

smartctl -i /dev/hda

There is a fair amount of output here, including drive size, firmware version and things like that. The two lines to look for however, are: -


SMART support is: Available - device has SMART capability.
SMART support is: Enabled


If SMART support is disabled, you can switch it on with: -

smartctl -s on /dev/sdb

Three self-tests are supported by SMART. These are:

Short self-test routine = short test
Extended self-test routine = long test
Conveyance self-test routine = conveyance test

Keep in mind that anything beyond short self-test will take a while depending on the size of your disk, although in the output produced by the above, SMART will attempt to estimate the time taken for each test. The short test is good, but more accurate results of errors, you’ll want to use the long test. Don’t attempt to run more than one test at once! These tests can be invoked with: -


smartctl -t short /dev/sdb
smartctl -t long /dev/sdb
smartctl -t conveyance /dev/sdb


smartctl” will print how long the test will take and the estimate date/time of completion. After the test time has elapsed, you can check the results with: -

smartctl -l selftest /dev/sdb

This will show the results of whichever self-test you performed. If any errors are shown here, it might be time to perform a backup :-)


smartctl version 5.32 Copyright (C) 2002-4 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Conveyance offline Completed without error 00% 4697 -
# 2 Extended offline Completed without error 00% 4697 -
# 3 Short offline Completed without error 00% 4696 -


The above shows no errors.

If you want to use the SMART daemon (smartd) to monitor your disks rather than having to perform manual self-tests, you’ll need to edit your /etc/defaults/smartmontools file (under Debian/Ubuntu) or /etc/smartd.conf (under Fedora/CentOS). I’m currently using: -


#S/../.././3 = short test every day at 03:00
#C/../.././4 = conveyance test every day at 04:00
#L/../../7/2 = long test every Sunday (7) at 02:00
#-m root = root will be emailed if anything strange occurs
/dev/sda -a -o on -S on -s (S/../.././3|L/../../7/2|C/../.././4) -m root
/dev/sdb -a -o on -S on -s (S/../.././3|L/../../7/2|C/../.././4) -m root
/dev/sdc -a -o on -S on -s (S/../.././3|L/../../7/2|C/../.././4) -m root


This works under under Fedora at least – I had a problem getting this working under Ubuntu Netbook Remix, as not only is the “DEVICESCAN” environment variable not set (which scans all drives for errors instead of /dev/sd* as above), but when attempting to restart the smartd monitor, I got “/dev/sda: Permission Denied” which I can’t figure out….especially as I was running as root. But this may be something to do with Ubuntu Netbook Remix or Ubuntu’s strange use of the root account access. I’ll post a solution here for Ubuntu users if I get it figured out.

Anyhow, assuming your smartd.conf file works (:-)) you can restart the smartd monitor with: -


/etc/rc.d/init.d/smartd restart


…under Fedora/CentOS and: -

sudo service smartmontools restart

under Debian/Ubuntu. Just to reiterate that SMART monitoring tools are simply there to provide some early warning for disk failure – it is not a backup measure in any way, so keep regular backups folks!

A note on Ubuntu Desktops

If SMART encounters an error and you’re using Ubuntu on a desktop machine with GNOME or similar rather than a server, you might want SMART to notify you of problems via a visual notification. In that case, you’ll want to install “smart-notifier” as well: -

sudo apt-get install smart-notifier

which will pop up a window alerting you to potential problems. Or you can use a graphical application such as GSmartControl, which you can install under Ubuntu with: -

sudo apt-get install gsmartcontrol

Looks like my favourite Linux distribution, Fedora has gone into final beta. Full details here. The final release is scheduled for 2nd November 2010.