Not bad! Listing 2 shows that by clicking two buttons in the Swat
interface and unchecking some boxes in the Services Setting applet,
I've clobbered 11 out of the 13 network listeners that previously
had been active on my system.

But, I'm not done with listeners yet. There still are two left. I can't
do much about bootpc, which is part of the dhcp client dæmon that
most of us use to configure low-level TCP/IP settings automatically
when we connect to a LAN. Even at DEFCON, I'll need dhcpcd (bootpc)
active in order to connect to the DEFCON WLAN.

Swat, on the other hand, is fair game to shut down, especially considering
I've disabled all the rest of Samba. But hold on a second, I've
forgotten how! There's neither a Swat entry anywhere in the Services
Settings applet nor any applicable script in /etc/init.d. Maybe I can
figure out the name of the actual process listening on the Swat port
using the lsof (list open files) command, as shown in Listing 3.

Oh, now I remember! Swat is run by inetd, which on Ubuntu systems is part
of the package openbsd-inetd. You may remember my disabling xinetd in
Services Settings, but openbsd-inetd's startup script has to be disabled
manually, the old-school Debian way (Listing 4).

In Listing 4, you can see that I first stopped openbsd-inetd via its
startup script and then forcibly removed the various runlevel-links in
/etc/rc0.d, etc/rc1.d and so forth, via the update-rc.d command. I can
undo all this later, as shown in Listing 5.

Obviously, I will need to make note of the sequence number (in
this example, 20 for both the start and kill links) and the runlevels
(2–5 for starting and 0, 1 and 6 for killing). As it happens, the
settings for openbsd-inetd also are Ubuntu's defaults, so I could use
the command sudo update-rc.d openbsd-inetd defaults when re-enabling
that particular service.

I've spent the bulk of this column shutting down network services. Is
that all there is to system hardening?

Ordinarily not. If we were talking about a server, we'd have a lot more
work to do: configuring individual applications for maximum security,
disabling unnecessary user accounts, tightening file permissions,
configuring an integrity checker such as tripwire, maybe creating a
local iptables firewall script and so forth.

But this is my personal laptop, a single-user system. Shutting down and
disabling unnecessary network listeners really is 90% of what I need to
do to “harden” it. Most of the rest of what I need to do concerns how
I use this system. Before I get to that, however, I need to harden
one killer application: my Web browser.

Great read this month. I really like that you address an issue for very insecure networks but relate it to everyday use. I was motivated afterward to check the security of my NFS/SVN server as well. When I did a netstat --inet -al, I saw lost of things I wasn't expecting. Maybe you could cover security of the "small home" server one of these next months (or is there something I missed in the past?).
Also, you mentioned using IMAPS, POP3S, etc... IMAP with the SSL option (say in Thunderbird) is just that, right?
As a closing comment, I appreciate that you also included info on the Firefox Add-ons like Ghostery, I'll be checking those out soon. But what about TOR? Does The Onion Router offer any security? Does it compromise security since you're asking others to handle your packets? What about if VPN isn't an option? I know I've used it in the past to get past domain name filtering on networks (all forums and blogs were blocked at my work once, including the ones on PHP I needed access to).
Thanks again for a good read, just when I was thinking I might not renew my subscription, you convinced me otherwise.
Winfree

The thing about life is, no one gets out alive. Enjoy it while you can!

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.