Paranoid Penguin - Brutally Practical Linux Desktop Security
Listing 2. Network Listeners (Post-Hardening)
Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 *:swat *:* LISTEN udp 0 0 *:bootpc *:*
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.
Listing 3. Using lsof to Find Swat's Process
bash-$ sudo lsof -i :swat COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME inetd 29534 root 4u IPv4 521556 TCP *:swat (LISTEN)
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).
Listing 4. Manually Disabling a Startup Script
bash-$ sudo /etc/init.d/openbsd-inetd stop bash-$ sudo update-rc.d -f openbsd-inetd remove Removing any system startup links for /etc/init.d/openbsd-inetd ... /etc/rc0.d/K20openbsd-inetd /etc/rc1.d/K20openbsd-inetd /etc/rc2.d/S20openbsd-inetd /etc/rc3.d/S20openbsd-inetd /etc/rc4.d/S20openbsd-inetd /etc/rc5.d/S20openbsd-inetd /etc/rc6.d/K20openbsd-inetd
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.
Listing 5. Manually Re-enabling a Startup Script
bash-$ sudo update-rc.d openbsd-inetd start 20 2 3 4 5 . stop 20 0 1 6 . Adding system startup for /etc/init.d/openbsd-inetd ... /etc/rc0.d/K20openbsd-inetd -> ../init.d/openbsd-inetd /etc/rc1.d/K20openbsd-inetd -> ../init.d/openbsd-inetd /etc/rc6.d/K20openbsd-inetd -> ../init.d/openbsd-inetd /etc/rc2.d/S20openbsd-inetd -> ../init.d/openbsd-inetd /etc/rc3.d/S20openbsd-inetd -> ../init.d/openbsd-inetd /etc/rc4.d/S20openbsd-inetd -> ../init.d/openbsd-inetd /etc/rc5.d/S20openbsd-inetd -> ../init.d/openbsd-inetd bash-$ sudo /etc/init.d/openbsd-inetd start * Starting internet superserver inetd
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.
- High-Availability Storage with HA-LVM
- DNSMasq, the Pint-Sized Super Dæmon!
- March 2015 Issue of Linux Journal: System Administration
- Localhost DNS Cache
- Real-Time Rogue Wireless Access Point Detection with the Raspberry Pi
- Days Between Dates: the Counting
- PostgreSQL, the NoSQL Database
- The Usability of GNOME
- Linux for Astronomers
- You're the Boss with UBOS