Paranoid Penguin - Brutally Practical Linux Desktop Security
What about Targeted Malware?
I don't want you to come away from this with the notion that malware never figures into Linux security or that it never will. In settings where you can't control what software people run or install on their systems or can't fully enforce automated, timely patching, good antivirus software is essential.
And, I worry quite a bit about targeted malware—that is, hostile code that has been custom created to attack a specific organization or individual. That is becoming an increasingly common tool used by organized crime in stealing large quantities of sensitive data (most typically credit-card numbers and identity data) from specific organizations. Often, the worm or virus will be “planted” in the target network by someone with inside access.
Because a given worm, virus or trojan of this type has been “handcrafted” and never has been released against the general public, there's zero likelihood that any antivirus software vendor even will know about it, let alone provide antivirus signatures that can detect it. Mainstream, signature-based antivirus software is, therefore, generally useless against targeted malware. For this and other reasons, targeted malware is very, very difficult to defend against, even with good patching practices.
But, this article isn't about protecting large networks or even about defending yourself from targeted attacks by well-funded attackers. It's about protecting yourself from attacks by more or less random strangers you may encounter on the Internet, at your local coffee shop's wireless LAN and so forth. And in those contexts, I don't worry very much about Linux malware.
So, assuming you're fully patched already—and I assure you I am—let's get busy disabling network listeners. The first step in doing this is to find them. If I run the command netstat --inet -al on my Ubuntu laptop, I see what is shown in Listing 1.
Listing 1. Network Listeners (Pre-Hardening)
Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 *:swat *:* LISTEN tcp 0 0 *:ssh *:* LISTEN tcp 0 0 localhost:ipp *:* LISTEN tcp 0 0 *:3128 *:* LISTEN udp 0 0 iwazaru:netbios-ns *:* udp 0 0 *:netbios-ns *:* udp 0 0 iwazaru:netbios-dgm *:* udp 0 0 *:netbios-dgm *:* udp 0 0 *:49176 *:* udp 0 0 *:57500 *:* udp 0 0 *:icpv2 *:* udp 0 0 *:bootpc *:* udp 0 0 *:mdns *:*
You can see I'm running the Swat front end for administering Samba services, the Secure Shell dæmon, the Internet Printing Protocol and Squid (whose default port is TCP 3128). Hmm, you'd never guess that I recently wrote articles on Samba and Squid, would you?
Well, those articles are long finished, so right now I don't have any compelling reason to keep any of these services running, especially when I travel. I not only need to shut them down, but also disable their startup scripts. I could simply uninstall them, but I might need them later. Still, as a general rule, if you can uninstall unnecessary software, you should. Doing so via your preferred package manager is simple enough for me to skip describing here.
At the application level, I can use Swat to shut down Samba cleanly. This clobbers the netbios nameservice (netbios-ns) and netbios datagram (netbios-dgm) udp listeners in Listing 1. But, I also need to disable the Samba startup scripts and Swat itself.
Distributions vary in how they handle startup scripts for system dæmons like these. On SUSE, you can use YaST2 or the command insserv. On Red Hat, Fedora and CentOS systems, use the command chkconfig.
Because my system runs Ubuntu, I can use either the Services Settings applet (Figure 1) in my X Window System's Applications menu or the update-rc.d command. Let's start with the Services Settings applet, which, by the way, is part of GNOME and, therefore, may very well be installed on your non-Ubuntu GNOME desktop too.
Figure 1 shows the Services Settings applet after I've already clicked the Unlock button and provided my root password. Figure 1 also shows the bottom of the list of services running on my system, but that's where some of the juicier items are. I definitely want to uncheck the boxes next to Proxy cache service (squid), Remote shell server (ssh) and Web server (apache2).
What about Printer service (cups)? I'll disable that too, because at DEFCON, it's highly unlikely I'll need to print anything (or even have the opportunity to). But, note that as Listing 1 shows, my system is listening only for incoming IPP connections on the loopback interface (localhost:ipp). It isn't listening for remote connections to this service.
Me being me, I'll disable it anyhow. A “local” attack vector is local only until some other process is hijacked by a remote attacker, at which point the hijacked process might be used to spawn some other process that can attach to the thing having the “local” vulnerability.
Along the same lines—that is, in the interests of generalized paranoia—I'll also disable the following in Services Settings (not shown in Figure 1):
Account information resolver (winbind).
Folder sharing service (samba).
Multicast DNS service discovery (avahi-daemon).
Network service (xinetd).
Those are all things I'm sure I can live without in an untrusted environment. File sharing in particular, in the form of Samba and its winbind service, is to be avoided in such settings. Now if I re-run my netstat --inet -al command, I see only what is shown in Listing 2.
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Designing Electronics with Linux | May 22, 2013 |
| Dynamic DNS—an Object Lesson in Problem Solving | May 21, 2013 |
| Using Salt Stack and Vagrant for Drupal Development | May 20, 2013 |
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
- New Products
- Linux Systems Administrator
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Web & UI Developer (JavaScript & j Query)
- Designing Electronics with Linux
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Reply to comment | Linux Journal
4 hours 20 min ago - Reply to comment | Linux Journal
4 hours 36 min ago - Favorite (and easily brute-forced) pw's
6 hours 28 min ago - Have you tried Boxen? It's a
12 hours 19 min ago - seo services in india
16 hours 51 min ago - For KDE install kio-mtp
16 hours 52 min ago - Evernote is much more...
18 hours 52 min ago - Reply to comment | Linux Journal
1 day 3 hours ago - Dynamic DNS
1 day 4 hours ago - Reply to comment | Linux Journal
1 day 5 hours ago





Comments
I just have been to a seminar
I just have been to a seminar and they told us the exact same thing. Thanks for sharing, you made a great point.
Great Article, but can you tell us some more?
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!