Wiping disk drive data with Darek’s boot and nuke

Over the years I have accumulated dozens of disk drives. As I upgrade drives and donate my older hardware to friends and charities, I like to make sure the data on those drives is wiped. I’ve been using Darik’s boot and nuke (DBAN) to wipe my drives for the past year or two, and the entire process couldn’t be easier.

DBAN is a bootable Linux CDROM image that wipes a hard drive using one of several strong data destruction algorithms (Gutmann wipe, DoD short, Dod long, etc.). To wipe a drive you boot from a CDROM with the DBAN ISO image, select the drives you want to wipe, hit “M” to choose the algorithm to wipe the drives with and then sit back and watch as the program wipes your drives clean:

null

If you decided to use this technique, make sure to unplug all disk drives with valid data. If you forget and leave them plugged in and accidentally select one of them (or use the autonuke option), your data WILL BE DESTROYED! Use this information at your own risk. The author will not be held liable for any data loss that results from the information in this blog entry.

Securing your Linux vsftp installations by locking down your server and chroot()’ing users

As much as we all hate FTP and the insecurities of the protocol, I’ve given up on the fact that it’s going to be retired anytime soon. A lot of old legacy systems (mainframes, AS400s, etc.) don’t support SSH, but they so support the infamous FTP protocol. These two factors force a lot of companies to continue to use it, so we need to take every measure we can to protect the FTP servers that receive files from these systems.

I’ve been using vsftpd for quite some time, and it has one of the best security track records of the various FTP server implementations. When I’m forced to use FTP, I always install vsftp and perform a number of actions to lock down my FTP server installation. Here is a short list:

– Enable SELinux
– Change the default vsftp banner (“ftpd_banner” controls the string displayed)
– Limit connections to known IP addresses (tcp_wrappers and iptables can help with this)
– Disable anonymous logins (“anonymous_enable” controls this behavior)
– Tighten up the umask to disable writeable files (“local_umask” controls the default umask to use)
– Increase logging and use centralized log servers (“xferlog_enable” and syslog-ng can help with this)
– Validate all identities in /etc/passwd and remove unneeded system accounts
– Disallow ALL system accounts from logging in
– Chroot all users to their home directory

The last item is especially important, since you don’t want users wandering around your file systems looking for files and directories that *could* be exploited through a software bug or misconfiguration. Chroot support is built into vsftpd, which is now the default FTP daemon in Redhat and CentOS Linux. Enabling chroot support is super easy, since you only need to uncomment the following line:

chroot_local_user=YES

Once enabled, users will only be able to see the files and directories in their home directory.

$ ftp ftp.prefetch.net
Connected to localhost (127.0.0.1).
220 Welcome to Matty’s FTP server. Unauthorized access prohibited!
ftp> user bingo
331 Please specify the password.
Password:
230 Login successful.
ftp> pwd
257 “/”

By default all users will be chroot’ed to their home directories, which may not be ideal in some situations. If you need to selectively allow access to directories outside of the chroot, you can enable “chroot_local_user” and add the usernames you want to be allowed to “browse” to /etc/vsftpd/chroot_list. If on the other hand you want to allow all users to access the server and only chroot a few, you can set chroot_list_enable to YES and list the user’s you want to chroot in the /etc/vsftpd/chroot_list. The location of the file that lists the users (/etc/vsftpd/chroot_list in the examples above) is controlled by the chroot_list_file variable, which can be set to the absolute path of a file that contains a list of users. While FTP sucks, it’s going to be with us for some time to come. If we have to support it, we might as well do all we can to secure it!

Running an SSH client inside your Firefox web browser

I recently came across FireSSH, which is an SSH client that runs inside Firefox. The FireSSH plug-in allows you to create an SSH connection to a remote host using just a web browser, and I can see all kinds of uses for this! The plug-in is written entirely in javascript, and uses a couple of features that require Firefox 4 (Firefox 4 rocks, so upgrading to it should be a no brainer). To access the plug-in, you will first need to surf over to the mozilla plug-in site and install it using your choice of installation options. Once installed, you can run FireSSH by opening Firefox and running Tools->FireSSH. This will present the following screen:

null

Once you fill in the connection attributes you will we logged in and presented with an interactive SSH window similar to this:

null

FireSSH also supports public-key authentication, so you don’t need to rely on passwords to get into your hosts. This is a killer app, and I LOVE Firefox 4. It loads quickly, it’s super fast and the UI layout rocks. Niiiice!

Making sense of the various routing / firewall solutions that are available

I am currently running dd-wrt at home. Dd-wrt works pretty well, but I recently started to do some digging to see what other routing / firewall solutions existed. There are a bunch of routing / firewall gateway solutions available, and each one provides a unique experience. Some run on Linux, some on OpenBSD, and others on Linux. Most of the solutions have a GUI of some sorts to assist with configuring the device, but one or two require you to use the good old CLI. A number of solutions provide pretty visuals to review traffic and connectivity information, while others require you do use character-based tools to see what is up with your router. Of the various solutions I’ve look at, the following ones stood out:

IPcop – Linux firewall distribution with a web-based GUI.

pfsense – Customized FreeBSD distribution tailored for firewall / routing use.

Tomato – Replacement routing / firewalling firmware for Linsys and Buffalo routers.

dd-wrt – Replacement routing / firewalling firmware for various routers.

m0n0wall – Embedded firewall package for FreeBSD.

There are additional solutions out there, and I suspect the decision on which one to use really comes down to how customizable you need it to be and more importantly how much time do you want to devote to installing and maintaining it. There are also questions like do you want to dedicate a PC to routing and firewalling your networks? Will a cheap $50 router from Fry’s be able to handle your traffic? Maybe you want to fine tune everything about your firewall so rolling your own installation with OpenBSD or Linux is the only solution. I’ve been extremely content with dd-wrt, and about the only thing I could see myself doing is upgrading to a newer router that has a faster CPU, more memory and 802.11N. What routing / firewalling solution do you use? Any other quality firewall / routing gateways you would add to this list?

Displaying GPG public keys in ASCII format

I was debugging a gpg issue earlier this week, and needed to dump the contents of a public key in some type of human readable form. After a bit of googling I came across the crazy awesome pgpdump utility, which provides a command line interface to display the contents of a GPG public key. To use this tool, you can pass the key file as an argument to pgpdump:

$ gpg –export -a > $HOME/pub.asc

$ pgpdump $HOME/pub.asc

Old: Public Key Packet(tag 6)(418 bytes)
	Ver 4 - new
	Public key creation time - Tue Jun 22 10:33:25 EDT 2010
	Pub alg - DSA Digital Signature Algorithm(pub 17)
	DSA p(1024 bits) - ...
	DSA q(160 bits) - ...
	DSA g(1021 bits) - ...
	DSA y(1023 bits) - ...
Old: User ID Packet(tag 13)(31 bytes)
	User ID - Test Key 
Old: Signature Packet(tag 2)(96 bytes)
	Ver 4 - new
	Sig type - Positive certification of a User ID and Public Key packet(0x13).
	Pub alg - DSA Digital Signature Algorithm(pub 17)
	Hash alg - SHA1(hash 2)
	Hashed Sub: signature creation time(sub 2)(4 bytes)
		Time - Tue Jun 22 10:33:25 EDT 2010
	Hashed Sub: key flags(sub 27)(1 bytes)
		Flag - This key may be used to certify other keys
		Flag - This key may be used to sign data
	Hashed Sub: preferred symmetric algorithms(sub 11)(5 bytes)
		Sym alg - AES with 256-bit key(sym 9)
		Sym alg - AES with 192-bit key(sym 8)
		Sym alg - AES with 128-bit key(sym 7)
		Sym alg - CAST5(sym 3)
		Sym alg - Triple-DES(sym 2)
	Hashed Sub: preferred hash algorithms(sub 21)(3 bytes)
		Hash alg - SHA1(hash 2)
		Hash alg - SHA256(hash 8)
		Hash alg - RIPEMD160(hash 3)
	Hashed Sub: preferred compression algorithms(sub 22)(3 bytes)
		Comp alg - ZLIB (comp 2)
		Comp alg - BZip2(comp 3)
		Comp alg - ZIP (comp 1)
	Hashed Sub: features(sub 30)(1 bytes)
		Flag - Modification detection (packets 18 and 19)
	Hashed Sub: key server preferences(sub 23)(1 bytes)
		Flag - No-modify
	Sub: issuer key ID(sub 16)(8 bytes)
		Key ID - 0xA7B71783E5016F25
	Hash left 2 bytes - ad 6b 
	DSA r(157 bits) - ...
	DSA s(159 bits) - ...
		-> hash(DSA q bits)
Old: Public Subkey Packet(tag 14)(525 bytes)
	Ver 4 - new
	Public key creation time - Tue Jun 22 10:33:25 EDT 2010
	Pub alg - ElGamal Encrypt-Only(pub 16)
	ElGamal p(2048 bits) - ...
	ElGamal g(3 bits) - ...
	ElGamal y(2046 bits) - ...
Old: Signature Packet(tag 2)(73 bytes)
	Ver 4 - new
	Sig type - Subkey Binding Signature(0x18).
	Pub alg - DSA Digital Signature Algorithm(pub 17)
	Hash alg - SHA1(hash 2)
	Hashed Sub: signature creation time(sub 2)(4 bytes)
		Time - Tue Jun 22 10:33:25 EDT 2010
	Hashed Sub: key flags(sub 27)(1 bytes)
		Flag - This key may be used to encrypt communications
		Flag - This key may be used to encrypt storage
	Sub: issuer key ID(sub 16)(8 bytes)
		Key ID - 0xA7B71783E5016F25
	Hash left 2 bytes - b1 38 
	DSA r(158 bits) - ...
	DSA s(159 bits) - ...
		-> hash(DSA q bits)

Pgpdump will display the algorithms used to create the key, as well as the key-lengths that were used. This is amazingly helpful when debugging key-related issues (hash algorithm mismatches, key-size discrepancies, etc.), and I will definitely be adding this tool to my SysAdmin toolkit!

Wide open remote root exploit on dd-wrt

As reported on Slashdot, there is a wide open exploit on dd-wrt due to how the httpd server handles and parses incoming requests without being authenticated.  The HTTP get code to execute has been posted on milw0rm.

If you haven’t already, you should either update your dd-wrt installation to build 11533 (most router firmwares have already been updated to this latest build on dd-wrt’s router database) or insert the following firewall rules:

The below was taken from dd-wrt’s site directly.

The exploit can also be stopped, using a firewall rule: Go to your router’s admin interface to > Administration > Commands and enter the following text:insmod ipt_webstr
ln -s /dev/null /tmp/exec.tmp
iptables -D INPUT -p tcp -m tcp -m webstr –url cgi-bin -j REJECT –reject-with tcp-reset
iptables -I INPUT -p tcp -m tcp -m webstr –url cgi-bin -j REJECT –reject-with tcp-reset
press “Save Firewall” and reboot your router. This rule blocks any attempt to access sth that has “cgi-bin” in the url. You can verify that the rule is working by entering: http://192.168.1.1/cgi-bin/;reboot in your browser. That should give a “Connection was reset” (Firefox).