Tips and Tricks for Linux Admins: Volatile Debian

Yes folks, it’s time for another enticing batch of useful and amazing Linux tips and tricks! On today’s menu we are serving up Debian going all volatile, the lowdown on cdrkit usurping cdrtools, and a simple way to use iptablesrules to foil brute-force password attacks.

New Volatile Debian Repos

New to me, anyway, though they’ve been around for a couple of years, and those are the sarge-volatile and the etch-volatile repositories. OK, so you’re already rolling on the floor laughing at the idea of anything in Debian being labeled “volatile”, and are thinking “wait, don’t you mean catatonic?”, but really, these are cool and good. These repositories contain mainly spam-filtering and anti-virus applications, such as ClamAV, Spamassassin, F-Prot, Mimedefang, plus an updated tzdata. (So, US citizens, how much daylight did you save this year? Don’t forget to put some away for when you really need it!) These require more frequent updates than what the usual Stable release cycle supports. Because they play crucial roles in system security, many sysadmins are understandably nervous about updating them from Testing or Unstable. Backports isn’t an attractive option, as anything and everything gets stuffed in there, and you have to track down and apply your own security patches.

So the Volatile repositories were created to meet the needs of admins running Debian Stable. Packages in Volatile get security support, and have to meet the same quality control as any Stable packages. So they shouldn’t cause dependency or upgrade problems, but should function as reliably as any Stable package.

You also have the option of using debian-volatile/sloppy. These still get security support, but may not upgrade gracefully without requiring some manual tweaking. Visit debian-volatile for end users for instructions on adding the Volatile repositories to your /etc/apt/sources.list.

cdrkit To The Rescue

I’ll wager most Linux users these days use graphical CD/DVD writers, such as the top-notch K3b, which I think is the best CD/DVD writer on any platform, or the Nautilus CD/DVD creator. I doubt that most Linux users pay much attention to writing disks from the command line, or are aware of the underlying applications behind the pretty GUIs. But the adoption of cdrkit as a replacement for cdrtools is an interesting story, and is one of the reasons that writing CDs and DVDs on Linux works so well.

Linux oldtimers will recall the days of Jörg Schilling’s cdrecord, and the related programs in the cdrtools suite: mkisofs, cdda2wav, readcd, and several others. cdrtools was pretty much the only CD/DVD writing software that worked on Linux and that was maintained, so it was standard in virtually all Linux distributions. But then Mr. Schilling changed the license of his build system for cdrtools, cdrecord itself, and some other bits to Sun’s CDDL (Common Development and Distribution License), which is not GPL-compatible. So in January 2006, a discussion was started in the Debian project that eventually led to the forking of cdrtools, and replacing it with cdrkit.

The various personalities involved are colorful, to say the least; check Resources for links to the, um, lively discussions on the subject.

Meanwhile, back here in Linux luserland, CD writing was nasty and brutish. Well perhaps not that dire, but it’s only in the last couple of years that it has become mature and reliable. A major problem with cdrecordwas that it spoke only to SCSI devices. The vast majority of PCs use the ATAPI interface, which is derived from the IDE interface. If you’ve ever installed a CD or DVD drive, you know this because it plugs into the same motherboard connectors as your IDE hard drive, and can even share the same cable. And you have to set master/slave jumpers just like an IDE drive.

And thus was born the ide-scsi kernel module, which provided a SCSI emulation layer just for the benefit of cdrecord. While it worked, more or less, it was also troublesome. I’ll let Linus Torvalds explain the problems with cdrecord and ide-scsi:

“ide-scsi has always been broken. You should not use it, and indeed there was never any good reason for it existing AT ALL. But because of a broken interface to cdrecord, cdrecord historically only wanted to touch SCSI devices. Ergo, a silly emulation layer that wasn’t really worth it.”

The 2.6 kernel, since about the 2.6.8 release, uses the ide-cd module instead of ide-scsi. Of course this caused all sorts of breakage and user woes, which thankfully are now ancient history, and we can simply fire up our favorite CD/DVD writer and not have to hassle with special boot configurations, or running arcane device-detection commands, or using weird SCSI syntax like dev=1,0,0 instead of /dev/hdb. We don’t even have to shop carefully for a CD/DVD writer—they just work.

Of course Linux development never stands still, and starting with kernel version 2.6.19 all ATA drivers are under a completely shiny new libata subsystem, so all hard drives and CD/DVD drives are now treated as SCSI drives. Mmkay. But at least they stick with the familiar /dev/sdx naming, instead of SCSI LUNs. The plan for the long-term is to have a generic disk subsystem for all drive types. Your distribution may still be using the old ATA drivers; the easy way to tell is if your IDE drives are named /dev/sdx, you have the new system. If you have /dev/hdx, then you’re using the old ATA drivers.

cdrkitis a suite of applications, as the FAQ states:

  • genisoimage: Generate ISO IMAGEs
  • icedax: InCrEdible Audio eXtractor
  • librols: LIB Remains Of LibSchily
  • libusal: LIB Unified/Universal Scsi Access Layer
  • netscsid: NET SCSI Daemon
  • readom: READ Optical Media (see also wodim)
  • wodim:

Q: What does “wodim” stand for?
A: It is not a forest troll and not a winner of the inpronounceability contest. It was simply the next alternative to wom (Writes Optical Media) which was unfortunately already used by other software products.

So wodim replaces the cdrecordcommand, for you fine command line commandos .

iptables Blocks Brute-Force Attacks

There are several excellent programs for blocking brute-force password attacks on your servers, such as DenyHosts and Fail2ban. Another option is to use good old iptables. All it takes is two simple rules per service, as this example shows:

iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 8 --rttl --name SSH -j DROP

This limits all incoming connections to port 22 to 8 per minute. To prevent locking yourself out, you can create a whitelist:

iptables -N ssh-whitelist
iptables -A ssh-whitelist -s [your-ip-address] -m recent --remove --name SSH -j ACCEPT

Then modify your rules like this:

iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -j ssh-whitelist
iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 8 --rttl --name SSH -j DROP

You can easily adapt this for any service. The –set –name option creates an arbitrary name, so you can call it anything you want. Just make sure it matches the –namein your DROP rule.


Latest Articles

Follow Us On Social Media

Explore More