Many of us who use use security products on our computers religiously are bewildered to find that we still get infected with malware. How does this happen? No matter what we do, our computers are constantly in touch with the vectors that carry malicious software. Thomas Greene explains what this means, and what we can do about it.


NO DOUBT MOST OF US can sympathize with this Register reader:

Hi Mr. Greene, I have just read your article on the severe Windows security hole and I still cannot for the life of me fathom ports—there are so many! I have been on line now for two years and have had to reformat my hard drive so many times due to viruses, etc., that I’m getting bored with it—lol! I have the latest antivirus software and a firewall up and running, but still I get problems. Any help will be so greatly appreciated; I’m not IT informed in any way—as u can tell! I can work my way round a PC with the basics. Any help at all with the security of a PC (is there such a thing?) will be much appreciated.

Thanks, –Rich in the UK

Rich’s good-natured attitude may be concealing a trace of exasperation as he closes, wondering if securing a PC is even possible. It is possible, of course, and not even terribly difficult, but there’s a good deal more to it than antivirus software and firewalls. He seems to have learned the conventional wisdom well enough, yet his computer is still getting infected with malware. Although we may use security products conscientiously, malicious programs still find their way onto our systems in large numbers. How does this happen? Blame it on software bugs, system vulnerabilities, malware, and the vectors that deliver them to us. Vector comes from the Latin vehere, to carry. Our computers are in constant contact with vectors, or carriers, of infection and exploitation. Generally speaking

A bug is any programming error that causes unforeseen and undesirable conditions, including, but not limited to, vulnerabilities.

A vulnerability is any security weakness that can be attacked deliberately, either with software or with a series of commands, to cause undesirable system behavior or impede desired behavior.

An exploit is any command or any sequence of commands that can leverage a bug or a vulnerability (and when the command sequence is designed to be executed automatically, we call this a scripted exploit).

Malware is any software program or any component such as a plugin or an ActiveX control that can exploit a bug or a vulnerability, or cause undesirable system behavior or impede desired behavior in and of itself.

A vector is any mechanism or agent that spreads, or enables the spread of, malware and scripted exploits.

From a security point of view, the Internet is a vast, virtual ecosystem filled with predators and parasites as well as “prey” and “hosts,” much as we find in any biological system. Just as living things are susceptible to attack from parasites and disease germs, software systems are vulnerable to malware and exploits, and some more so than others. And just as parasites, germs, and the vermin that carry them are everywhere in the real world, the Internet too is teeming with malware and exploit code and the vectors that deliver them—and that’s why Rich’s firewall and AV software have let him down. He is, in a sense, relying on a flu shot to protect against lice.

There’s an important advantage in the real world that has no analogy in the realm of information technology: biodiversity. The entire IT ecosystem is divided into a few technological monocultures, analogous to the agribusiness and livestock industries, where a lack of genetic diversity can lead to blights and epidemics. The world of computing is very much the same, with Cisco Systems running much of the Internet and high-end network infrastructure; Microsoft, Oracle, and Sun running much of the enterprise application (e.g., database) and server realm; and Microsoft acting as the McDonald’s of personal computing, running nearly everything in the consumer desktop arena. In this environment, if you’ve got an exploit against Cisco, then you’ve got an exploit against most routers on the Internet; if you’ve got an exploit against Windows, you’ve got an exploit against virtually every client system and quite a few servers as well. Monocultures, whether biological or artificial, invite epidemics. Just as the operators of agricultural conglomerates and factory feedlots must aggressively control disease-carrying vermin to protect their genetically challenged inventory of plants and animals, so we must control the many vector of contagion affecting our rather inbred computer systems and networks.

This chapter is from Computer Security for the Home and Small Office by Thomas C. Greene (Apress, 2004, ISBN: 1590593162). Check it out at your favorite bookstore today. Buy this book now.

{mospagebreak title=Common Vectors}

The Internet may not be crawling with dangerous hackers as the news media like to pretend, but it is inundated with billions of bytes of incredibly lousy and often malicious code, while most PCs are loaded with gigabytes of wretched software that either offers no protection or is itself malicious. Hackers are not your primary security concern; bad software is. This may not be terribly sexy news, but it’s true. Your computer is insecure because your software is insecure and because you’ve probably got several malware applications installed on it to boot.

Before we dig into the details, let’s take a brief survey of the most common malware vectors and other common routes to exploitation.


The Microsoft e-mail clients Outlook and Outlook Express have for years been the Internet’s most prolific virus and worm vectors. They are joined by instant messaging (IM) clients and P2P file-sharing utilities for that dubious distinction. However, the Microsoft e-mail applications are particularly dangerous because they are deeply integrated into the Windows system, and also because, like most clients, they are code-execution environments. That is, the e-mail client itself is capable of executing code, such as HTML, ActiveX controls, and JavaScript, automatically in the body. Such code is said to be delivered in line when it appears in the body of a memo, as opposed to code contained in a file attached to it. Virtually all modern e-mail clients are capable of executing code, though the Mozilla mail client recommended in the Introduction allows users to disable all remote images, HTML, and in-line scripts and plugins. Others do as well, but Irecommend Mozilla because it’s not deeply integrated with the Windows operating system, its data traces are easy to control, and it’s both free and open source.

In addition to executing code, e-mail also transports a great number of malicious file attachments. People are repeatedly warned never to open attachments without first scanning them for malware, but still they do so every day. Some mass-mailing viruses are capable of sending themselves automatically to each correspondent in a victim’s e-mail address book. The next recipient recognizes the sender as a known contact and is therefore more likely to open the attachment and infect himself, propagating the virus to his own contacts, and so on. The Melissa, IloveYou, and Slammer e-mail worms used this technique and managed to clog up portions of the Internet for brief periods, though they contained no destructive payloads. However, many in-line scripts and e-mail attachments do contain malicious payloads, so it is very important to disable code execution (i.e., switch off HTML and all scripting and plugin support) and never to open any attachment, regardless of who sent it, without first scanning it for the presence of malware. E-mail attachments are probably the single largest vector of malware. Switching off HTML is also an important step because spam is often loaded with malicious scripting and remote images that can track recipients. Admittedly, it can be irritating to read HTML-formatted mail rendered in plain text. If your friends and regular correspondents have the habit of sending HTML e-mail, take a moment to explain the security risks of in-line scripting, and suggest that they consider sending mail in plain text.


Most of us think of the browser as a simple window on the Internet. It is that, of course, but it has developed considerably since the early days of the humble Mosaic browser in the early 1990s, gradually swelling into what it is today: a major code-execution environment. We now have Java, JavaScript, Flash, ActiveX, PHP (Hypertext Preprocessor), XML (Extensible Markup Language), ASP (Active Server Pages), and other pulsating, decorative accessories to make our browsing experience memorable, and risky. After all, if a browser can execute code, it can execute malicious code.

It’s easy for an attacker to force a victim’s browser to run malicious code and scripts, and this is especially true of Internet Explorer. Sometimes an attack involves redirecting a browser session to a malicious Web site without the user’s knowledge; sometimes it involves enticing a user to visit a malicious site with a link in an e-mail message; sometimes it involves spoofing or obscuring URLs and filenames; sometimes it involves sending malformed packets to the browser, and sometimes it involves tricks that cause code from untrusted sites to execute in the “trusted” Internet Explorer security zone. Cookies can be misused to compromise privacy and even to hijack browser sessions and gain access to private online accounts. Local files can be read by remote attackers; downloaded files can be forced to execute automatically; and buffer overflows can be caused, allowing arbitrary code to run on a victim’s machine without any user interaction. There are literally hundreds of ways for an attacker to turn a victim’s browser against him. Some have been patched; others have not.

Here again, Windows users are at a disadvantage. The Internet Explorer browser is designed primarily as a code-execution environment and is deeply embedded in Windows. This makes it particularly dangerous because there are a vast number of exploits against it and because attacks against the browser can more readily become attacks against the system. For one ironic example, in July of 2003 an online “security scan” offered by security services giant Symantec was found to be loading a dangerous, and exploitable, ActiveX control on Windows users’ machines, which in turn allowed external code to run with the victim’s level of privilege. An ActiveX control is an executable program that can operate at a very low level within the Windows operating system, often delivered as Web content.

Internet Explorer also makes it difficult for users to clear their computers of data traces from their browsing sessions. A great deal of data is stored in the Windows Registry; and the default directories where the URL history, page cache, and cookies are stored can be difficult to clear.

Internet Explorer also does not permit fine-grained control of images to be loaded and so offers little protection against Web bugs, a commercial tracking and profiling gimmick that uses tracer images embedded in Web pages by third-party marketers. The scheme is similar to the tracer images in HTML e-mail, by which a spam victim’s e-mail account is verified. In this case, the bugs track a person’s surfing habits by logging their IP address, and possibly cross-referencing this behavior with login information and data stored in cookies.

According to Coremetrics, a marketing outfit that supplies tracer images for use on Web sites, their LIVE (lifetime individual visitor experience) profile technology (i.e., Web bugs) will “deepen and enhance customer relationships by gaining a better understanding of individual users’ behavior on your site and product preferences, giving you the insight you need to cross-sell financial products more effectively.” As you can see from the Coremetrics sales boilerplate, surfers can be identified personally with the bugs, though no doubt the decorative “privacy policy” on many of the Web sites using them will claim that personally identifiable data is not gathered. Web bugs, like tracer images in e-mail, are difficult to spot. The images themselves can be one pixel in size, making them invisible. The only way to avoid this sort of abuse in Internet Explorer is to deny all images, which makes surfing a rather dull affair. However, Mozilla allows the blocking of third-party images and cookies, which in turn helps surfers to defeat marketers while allowing a fair bit of image content to enliven their surfing experience.


This is a generic term for quite a few similar things. Essentially, a script is a series of commands to be executed without user interaction. They are not programs per se but, rather, commands that programs will respond to or instructions they will execute. The simplest ones are called batch files in Windows parlance and shell scripts in UNIX parlance. Most users have entered commands at a shell prompt or a command prompt. A batch file or shell script would simplify this by entering the commands in sequence automatically until the desired task is completed.

A macro is a scripted series of commands taking fairly complex action at the touch of a few keys. Many people use macros to automate repetitive tasks with word processors and spreadsheets. Not surprisingly, a command is translated into code that your computer can understand by a command interpreter. There are various interpreters, just as there are different scripting languages, such as JavaScript, VBScript, Perl, and so on.

Scripts are everywhere and come in many forms. They often appear in Web pages and e-mail memos, where they provide interactive features and dynamic content. What they all share is the ability perform tasks without user interaction. They are wonderful tools for automating repetitive chores and therefore of great value to sysadmins, Webmasters, and users alike. They are also of tremendous value to attackers. Scripts in Web pages and e-mail are frequently used as weapons because scripting languages are easy to learn: an attacker does not need any experience in programming to hack out a malicious script. A trick called cross-site scripting (XSS) allows an untrusted Web site to execute code in the security context of a trusted Web site without the user’s knowledge. Therefore, scripting support in any type of Internet client, including instant messaging, and in programs that invoke Internet clients (such as a word processor might do when one activates a hyperlink in a document file) is inherently risky. Scripting support is a significant and ever-present vector of compromise, and it must be controlled by the user with prejudice against allowing it except where necessary.

Instant Messaging

Instant messaging, or IM, is one of the more enjoyable services available over the Internet, one that can bring people together from anywhere in the world in real time for the price of an ISP account. However, graphical IM clients like MSN Messenger, AIM, and ICQ, as well as the text-based IRC (Internet relay chat) clients, are major vectors of infection. One reason is that the clients offer scripting support. There are many useful and innocent capabilities associated with IM and IRC scripts, though it should be said that the vast majority of packaged ones available for download have at least some malicious function, such as mass messaging (spamming), channel and network flooding, grabbing user IP addresses and other data, hijacking accounts and screen names, and the like. Another problem is that IM attracts children and teenagers and makes exchanging files very convenient. Young people tend to trust their peers and so typically end up accepting a great number of malicious files that can compromise not only their own privacy, but the overall security of a home network. Finally, it is important to know that many of the graphical IM and IRC clients contain adware and may reveal more about a user than he is willing to share with the IM service provider.

Businesses are also using IM as an inexpensive way for telecommuters to touch base with workmates on site in real time, and even for virtual conferences. This is an extremely insecure method of communication. IM clients can reveal a user’s true IP address; they can leave one open to man-in-the-middle attacks where one’s chat session is intercepted by a third party; they can be hijacked by scripts; and users can easily be impersonated. IM is fine for casual communication, but it is not an appropriate substitute for teleconferencing via a secure VPN (virtual private network). Simply permitting IM clients on a company network is a moderate security risk; using them for sensitive communication is positively reckless.

The MSN Messenger IM client is tied to a user’s Passport and Hotmail accounts and is deeply integrated with Windows as well. Browser action, such as logging into Hotmail, can invoke the IM client and vice versa. There is also a very dubious feature in Messenger called “shared browsing,” which enables two people on different computers to synchronize their browsers. “Even if you’re in Hollywood, CA, and your friend is in Hollywood, FL, you can both be on the same page—literally. You’ll see each other’s cursors on screen and you can chat in real time via MSN Messenger,” an MS marketing copywriter gushes. This level of integration and “synergy” is an open invitation to system compromise and privacy violation from many fronts. Exploits against Passport, Hotmail, and MSN Messenger are common, and a weakness in one increasingly implies a weakness in the others, since Microsoft’s trend is toward more, not less, application and Internet service integration. It is not a bad idea to replace MSN Messenger with a third-party clone like Trillian, which does not burrow so deep in the bowels of Windows and allows connections to numerous other IM networks. Even better from a security point of view is Gaim for Windows or Linux, which is both open source and adware-free, and, like Trillian, features cross-network compatibility. Gaim lacks the handsome user interface of many IM clients, but it is a fine choice for security reasons. However, all IM clients have been found susceptible to numerous exploits in the past and need to be patched regularly.

P2P Software

Much loved by young people for trading music files, illegally cracked editions of expensive software, and pornography, P2P applications like Morpheus, KaZaA, Grokster, and the like are major malware vectors even worse than IM clients. For one thing, most are infected with adware or spyware to help fund the developers. A great deal of user behavior is tracked across the Internet in this way, though the companies producing the applications soft-pedal this fact with the same dissimulating PR-speak that any flack from the music lobby would use. For example, KaZaA “contains no spyware,” developer Sharman Networks claims. The company “does not condone the use of spyware nor support the distribution of spyware to others,” we’re told. However, the KaZaA application feeds advertisements to users through third-party ad servers. Sharman assures us that this is all benign, that no one is tracked. But since you cannot possibly verify this claim, you would be foolish to believe it. “No spyware” is pure marketing spin. The company can call it what they please, but to any security-conscious user, adware is spyware.

P2P applications also function as servers so that users can upload files to each other’s machines, which means that their potential to spread malware is tremendous. Most of them are also capable of acting as super nodes, meaning that they can relay search requests from potentially millions of users. Enabling (or, rather, not disabling) the super-node function may cause users to violate their ISP’s use policy by inadvertently exceeding bandwidth limits, and the server function can expose users to every manner of malware known. These dangerous functions are often enabled by default, so users should take care to ensure that their P2P application is not behaving more promiscuously than they wish.

Permitting strangers to load files on your machine is essentially foolhardy. So is taking files from machines to which anyone can perform uploads. All such files must be scanned with antivirus software before activation, and users who permit uploads should scan their share directory periodically. However, AV software is only effective against known malicious files; it is hardly foolproof, so some risk will always remain no matter how careful or conscientious one is. Files downloaded via P2P applications or stored in an open share directory should be treated as malicious until proven otherwise. Careful scrutiny of file extensions is not an adequate defense: even seemingly normal MP3 files have potential to cause buffer overflow conditions against media players and use them as springboards to further system exploitation. While it may seem antisocial to use P2P software only to find and download files for yourself, this is, if not quite safe, the least risky way to go about it.

Assuming that the embedded adware and real potential for attracting root-kits hasn’t daunted you, there is yet another hazard. A powerful and quite ruthless lobbying organization for the music labels, the Recording Industry Association of America (RIAA), initiated a vendetta against file sharing in the summer of 2003. Armed with federal legislation called the Digital Millennium Copyright Act (DMCA) of 1998, written by the music and film lobbies and pushed through Congress on the wings of lavish campaign donations, the labels have begun identifying and suing file sharers with a streamlined subpoena process made possible by the DMCA. According to the Act, any copyright owner is permitted to file a simple subpoena obtained from a court clerk against anyone suspected of copyright violation, without a judge’s approval. There is no standard of evidence or probable cause.

The RIAA has been serving these inexpensive, do-it-yourself court orders against ISPs and obtaining the identities of P2P users, who are then sued. Usually, the accuser will be a simple software robot automatically trawling P2P networks, identifying likely candidates for legal persecution by their online nicknames or screen names. The subpoenas, essentially fishing licenses enabling the RIAA to accuse first and gather evidence later, are then used to obtain the suspected infringer’s true identity from their ISP. The RIAA is conducting an intimidation campaign in the form of a vendetta, lashing out at random members of a virtual “family” in order to chasten everyone else.

Meanwhile, telecommunication outfit Verizon objected to revealing its customers’ names on the basis of these flimsy subpoenas and fought the RIAA in court. The U.S. Court of Appeals for the District of Columbia ruled against the quick-and-dirty subpoena process, though no doubt a long, bitter legal battle over the music industry’s tactics will ensue. The practice may be reprehensible, but it may yet be upheld by the U.S. Supreme Court, thanks to the eternal inflooding of entertainment industry money into the U.S. political system. While there are valid political reasons for defying the RIAA and its sister organization, the Motion Picture Association of America (MPAA), and the custom-designed legislation they purchased on Capitol Hill, from a security point of view, P2P sharing is moderately risky at best, and positively self-destructive if all the features are enabled.

Users of P2P applications would do well to run a packet sniffer on their Internet connections from time to time and observe directly what sort of data is being exchanged, and with whom (we will learn to do this in Chapter 4). One should be especially suspicious of encrypted data shuttling back and forth between their computers and some Internet marketing outfit. It’s also wise to seek an open-source P2P application so that no secret functions can be hidden in the code. When choosing any open-source product, always look for the availability of source-code packages. Many P2P developers like to call their products “open,” a marketing label with no more meaning than any other PR copywriter’s phrase, such as “all natural.” Unless the source-code files are available so that you can build the application yourself, it is not open source.

This chapter is from Computer Security for the Home and Small Office by Thomas C. Greene (Apress, 2004, ISBN: 1590593162). Check it out at your favorite bookstore today. Buy this book now.

{mospagebreak title=Other Vulnerabilities}

Now let’s look briefly at several other common weaknesses that computer users need to remain aware of.

Operating System Vulnerabilities

Every operating system has vulnerabilities that are constantly being discovered. Some of these may be very old, having propagated in legacy code through numerous versions of an operating system before their security implications ever become known. The only practical defense is to remain aware of newly discovered vulnerabilities and to patch systems promptly. There are several e-mail lists, such as the Focus-MS and Focus-Linux lists from, the ISN (InfoSec News) list from, and The Register’s daily newsletter, to which users can subscribe for up-to-date security news. (See Appendix C.)

Remaining informed of new system vulnerabilities is one thing; acting on them is another, and users often neglect this important chore. Fortunately, Windows and the major packaged Linux distributions offer online update features that make patching easier. However, bad patches do occasionally get released, so there is some risk in relying on automatic updates. They are absolutely inappropriate for mission-critical systems, but for home users, the benefits of prompt patching may outweigh the risks. Still, manual online updating is better, so long as one remembers to check for new patches regularly. It is never a good idea to permit a software vendor to decide what code should be installed on your machine, and when.

When we compare security vulnerabilities affecting Windows systems and Linux systems overall, they run basically neck and neck. However, when we look more narrowly at vulnerabilities that require patching the Windows or Linux operating system kernels, we find that Linux is immensely cleaner. It’s rare for a patch affecting the Linux kernel to be released, though it’s common for Windows due to the interdependent nature of the system. In other words, with Windows, the majority of vulnerabilities affect the kernel, whereas with Linux, they rarely do. As we noted in the Introduction, kernel-level patches stand a greater chance of breaking things than application-level patches. Furthermore, Linux system vulnerabilities tend to affect services that can be disabled to achieve a temporary workaround, whereas Windows services often cannot be disabled without negative consequences. Security-minded users should give careful thought to installing Linux in place of Windows. In Chapter 6, we will look in depth at the advantages and disadvantages of migrating to Linux.

Application Vulnerabilities

All software applications contain significant vulnerabilities that must be dealt with in addition to operating system vulnerabilities. Microsoft packages a number of useful applications with Windows, but many other applications must be obtained either from Redmond or from secondary sources, called independent software vendors (ISVs). Windows is essentially an à la carte computer system. Your office suite, your graphics and image-manipulation programs, many of your multimedia applications, PC games, third-party clients, and utilities are distributed separately and must be patched with software provided by the individual vendors. These applications will not be patched when the Windows online update is run, so users must remain aware of security alerts and the availability of new patches for all of their third-party software. Microsoft is not responsible for third-party applications and utilities. It can be difficult to keep up with all the vulnerabilities as they emerge, but again, subscribing to a security news e-mail list like ISN or The Register’s daily newsletter is a good way to stay on top of them.

Because of the licensing advantages in open source software, the major Linux distributors like SuSE and Mandrake can package virtually every application a computer user might need, and these will be patched during online updates. Linux users enjoy morecomprehensive updates from their vendors than Windows users. However, software packages not included in the distribution and installed separately will not be updated, so these must be monitored for new vulnerabilities and patched as needed. Still, Linux users who stay with the packages shipped in their distribution can be confident that the online update feature will keep their systems patched with a minimum of bother.

Vulnerable Services

A service is a background process running on a system that supports other processes and applications as needed. Generally, the user doesn’t access or invoke a service directly; rather, an application or a utility will do so. In addition, one machine can offer services to other machines across a LAN or the Internet. For example, Samba and SMB are services that provide file and print sharing over a network. Kerberos is a service that provides network authentication. Bind is a service that enables an Internet server to translate domain names, such as, into an IP address, such as (Machines use IP addresses to communicate, but of course people have a far easier time remembering domain names.) SSH (secure shell) is a service that allows a computer to connect to a remote machine via an encrypted link over the Internet. The actual code that provides a service is called a daemon in UNIX parlance and a system agent in Windows parlance, and the feature or capability that it provides is called a service or a daemon process.

All of the services I’ve just mentioned, and many others not listed, have contained vulnerabilities that have in turn led to system compromises. Therefore, an important bit of security housekeeping involves identifying the services your computer is offering and disabling those you don’t need. For example, your PC should not be offering to accept SSH connections from other machines on the Internet unless you actually use this service and know how to set it up properly. For another example, the RPC (remote procedure call) service, which enables one computer to execute code on another, is a useful feature for networked machines sharing expensive hardware, such as a printer over a LAN, say. But it’s very risky when the computer offering RPC is connected to the Internet. (The MSBlaster worm that struck in the summer of 2003 leveraged insecurities in RPC through another service called DCOM.) Unfortunately, Microsoft has made a number of crucial Windows services dependent on RPC, so it can’t be disabled. In that case, prompt patching and firewalling are the only practical solutions. On the other hand, Linux users can shut off RPC without penalty. Later in this chapter, we’ll walk through the various services provided by Windows and Linux, and eliminate those that pose the greatest security risks.

This chapter is from Computer Security for the Home and Small Office by Thomas C. Greene (Apress, 2004, ISBN: 1590593162). Check it out at your favorite bookstore today. Buy this book now.

{mospagebreak title=“Unsafe at Any Speed”}

Many, if not most, home PC users are working with a single-user edition of Windows, such as Windows 95, 98, or Me. There are also multiuser editions such as Windows NT, 2000, and XP. UNIX and its cousins, BSD and Linux, are also multiuser systems.

The multiuser environment offers several distinct security advantages and should always be preferred, even in the home, and even when there is only one user.

The chief weakness of a single-user system is that whoever sits at the keyboard is the administrator, capable of taking any action he pleases. He can install programs and delete files or wipe out whole directories; he can alter system settings with the same privileges as the owner. This is bad in two ways. First, anyone with physical access to the machine can reconfigure it and possibly destroy important data files, whether intentionally or accidentally. Second, when every user is automatically an administrator, any malware that the user might pick up will run with the administrator’s level of access—that is, with unlimited privileges. Similarly, any remote intruder will automatically have full system access as well.

However, when we run a multiuser system like Windows XP or Linux, we can limit the level of system access granted to each user, and so limit the impact of malware and malicious attacks. There are other benefits as well: parents can prevent children from altering system settings that restrict their freedom on the Internet, for example. Even if a child is given his own computer, a parent can set up an administrator account on that machine for himself, and a user account for the child with fewer privileges. Similarly, if one wishes to share a computer with housemates but does not want them to access one’s own personal files or install software or fiddle with system settings, one can assign them user accounts in which to work.

Even when you are the only user, running your computer from an unprivileged account is always safer than running it as an administrator, or as root in UNIX parlance. If your machine is compromised, the intruder will likely (though not certainly) gain only your lower system privileges and may therefore fail to assume much control. This is true also when malware is inadvertently installed; it too will have fewer privileges if it’s installed under a user account. When you need to perform administrative tasks, such as installing software or hardware or changing the system configuration, you can simply log in as an admin or as root and do whatever you please.

Properly set up, a multiuser system can prevent attackers both remote and local from manipulating files and settings, prevent children from exceeding their privileges, and reduce the effectiveness of malware and remote exploits. The best advice I can offer to readers with single-user systems is that they switch to a full-fledged multiuser environment such as Windows XP or Linux right away. The recommendations offered throughout this book are based on a presumption that readers are working with multiuser systems, because the inherent weaknesses of single-user environments cannot be overcome and will undermine the best efforts of even the most conscientious, security-minded user. A single-user system is “unsafe at any speed,” so to speak.

A New York Times article from August of 2003 by Ian Austen did a good job of advocating the multiuser environment on grounds that it allows parents to regulate their children’s computer activity and permits each user to customize his desktop. But the author failed to grasp the important security implications of the multiuser environment and made a serious blunder, noting that “Windows XP … allow[s] owners to set up a password-protected account for every user. When a computer has a single user, the log-on feature of Windows XP can be a bit of a nuisance.1

It is far from a nuisance. It is, in fact, a significant security enhancement, and it should be exploited as such. Even when you are the only user, habitually logging on to an unprivileged user account will make all of your Web activity safer and reduce the impact of malware and scripts.

Admittedly, a multiuser system is no guarantee against exploitation. There are numerous remote and local attacks against both UNIX-compatible and Windows-based systems with which an attacker can increase his privileges, but we can, and should, at least make him work for it. It’s foolish, even negligent, to hand over administrative privileges at the front door. By habitually working from, and accessing the Internet through, a nonprivileged user account, we can frustrate a large number of unsophisticated attacks and a good deal of malware from the start. But just like firewalling, virus scanning, eliminating insecure proprietary software, and patching promptly, a multiuser system is no security panacea, though it is an important layer of defense. However, by assembling these layers and building on them, users can disappoint attackers, even fairly sophisticated ones.

It might seem that talking about vectors of infection and multiuser computing environments in the same chapter is an odd mix, but the two are well connected. This is because the security context, or the level of system access, that a user is granted affects the potential of malware and malware vectors such as browsers, e-mail, and IM clients to deliver and execute malicious code. It is generally, though not universally, true that we can limit the harmful impact of malicious code by limiting the user’s access to the system. This is a basic principle, and an important one, though it’s not foolproof. It is, however, a useful rule of thumb to keep in mind: generally speaking, an unprivileged user will run unprivileged malware. This is why even the owner and sole user of a system should always work from a limited-access account, except when performing administrative chores.

Single-user editions of Windows attempt to control code execution with so-called “security zones” for online clients like Internet Explorer and Outlook Express. Since everyone using the computer either already is an administrator or can become one with ease, the idea here is to categorize Web content and software providers and their products as trusted or untrusted. For example, Internet Explorer allows a user to choose Web sites from which content like JavaScript and ActiveX controls will be trusted. Content from untrusted Web sites can be assigned reduced privileges on the machine. Similarly, there are digital certificates testifying to the origins of software, which the user can choose to trust or not. The security zone approach might make sense on a single-user system in lieu of something better, but Microsoft has extended this band-aid approach to its multiuser systems, where it actually undermines the essential benefits of the multiuser environment.

Windows is designed to grant and deny system privileges to third-party software, and even to outside parties, based on preselected trust criteria. Digital certificates for Web sites and for software are proffered to persuade users that their trust criteria have been met. Meanwhile, the operating system is designed to trust code when Microsoft or the user trusts it or its provider, and this means that even users on a multiuser system can sometimes run or install powerful and potentially destructive code from an unprivileged account.

This approach is wrongheaded from the start. It is the user whose privileges should be regulated, not the provider of a service or a piece of software. By making it possible for a piece of code to be trusted automatically by the system, Microsoft has made it possible for software to exceed the privileges of the user who installs it and scripts to exceed the privileges of the user who runs them. Thus a malicious program, apparently certified by Microsoft with a digital certificate, can be installed by a user and the system will grant it access to the deeper layers of the kernel. Incredibly, not only is Microsoft still clinging to this slapdash security scheme left over from the days of Windows 9x, it’s actually expanding it in Windows XP and all future versions, and incorporating it into its Web services.

The new regime is called Next-Generation Secure Computing Base (NGSCB), or Palladium, a complicated, hence fragile, trust scheme meant to improve the level of confidence a user can place in a Web service or a piece of software by means of “improved” certification. (Actually, certification will become more complicated, though not necessarily better.) Unfortunately, this approach ignores the fundamental problem of allowing the system to trust code that the administrator has not approved, and even to exceed the administrator’s authority in these matters. You can see the problem: even a minor flaw in this scheme could allow malicious code to be trusted and permit it to operate at a low level regardless of who installs it. This completely undermines the security benefits inherent in a multiuser environment. It means that your security will only be as good as Microsoft’s grand trust scheme makes it, and considering Redmond’s history in this area, I wouldn’t put much faith in it.

Users should not be expected to know whose content can be trusted and whose can’t, or what code is safe to run and what isn’t. There are too many variables for anyone to make an informed decision every time some script is about to execute in a Web page or some program is about to install a plugin or an ActiveX control. The right way to do it is the way Linux does it: keep everyone, including the machine’s owner, in unprivileged accounts except when administrative tasks need doing. When the system doesn’t trust software or its provider based on preselected criteria, users needn’t worry about the origins and security implications of some Web script, ActiveX control, patch, or program file. The worst they can do is make a mess of their own home directories. They can’t make a mess of the entire system.

The simple way is often the right way, and this case is no exception. On Linux, if root installs a program, it will be trusted systemwide. If a user installs a program, it won’t be. Generally, a program installed by a user will have no impact outside his home directory. Similarly, if a user’s Web clients execute scripts, they too won’t have impact outside his home directory. That is the right way to manage permissions. Ideally, nothing a user does, or allows a piece of code to do, in an unprivileged account should affect the guts of the system. Ideally, only root can make decisions with systemwide implications. I say “ideally” because there are ways for attackers and some malware and scripts to get around these restrictions, but this is no reason to ignore the benefits. Even Windows users should take advantage of the security enhancements in a multiuser environment, in spite of the fact that Microsoft’s basic security scheme often gives them, and the code they execute, more privileges than they ought to have.

We’ve already done away with Internet Explorer and Outlook Express in favor of Mozilla, partly because the Windows security zone scheme is a failure. The company remains in denial of this fact because it’s stuck with a very old and very poor design reaching back to Windows 9x, which it has been patching and elaborating instead of finding ways to abandon in favor of simpler, and better, solutions. Security zones and trusted content are band-aid approaches to the fundamental problem with single-user systems: the fact that all users are administrators—an extremely foolish design that should never have been chosen in the first place. Microsoft’s original approach was bad enough, although, admittedly, there are limited options for controlling code execution in a single-user computing environment. But carrying this model forward into its multiuser systems, which would otherwise be a good deal stronger, and steadily building additional layers on top of a failed scheme that’s unsound in its footings, is pure folly that will cripple Windows security for years to come.

Fortunately, there are steps we can take to enhance the security of a multiuser Windows system and leverage its inherent superiority to earlier versions in spite of Microsoft. There is much to learn and much to do, but it can be achieved.

This chapter is from Computer Security for the Home and Small Office by Thomas C. Greene (Apress, 2004, ISBN: 1590593162). Check it out at your favorite bookstore today. Buy this book now.

{mospagebreak title=Defense}

Now, after considering a number of basic system weaknesses and routes to exploitation, it should surprise no one that our correspondent, Rich, was let down by his firewall and antivirus software. Still, we can control many of the risks that firewalls and AV packages can’t. There are two essential elements:

  • Disabling unnecessary services to reduce our attack profile

  • “Sandboxing” users, or limiting their access to the system so that the code they run will also have limited access

This involves a bit of work, especially for Windows users, but it’s not difficult.

NOTE  In order to make the following Windows configuration instructions and their accompanying screen shots easier for Win-NT and Win-2K users to follow, they will be shown in the default Windows XP theme.Win-XP users should change their Start Menu theme to Classic in order to harmonize their screens with our examples. Simply go to the desktop Start Menu and select Control Panel ? Taskbar and Start Menu. A dialog will pop up. Click on the Start Menu tab at the top of the dialog and then choose Classic Start Menu. Click Apply and clear the dialog.

What follows is a detailed set of instructions for both Windows and Linux users to strengthen security by disabling unnecessary services and setting up a multiuser environment the right way. It may be helpful to owners of single-user systems, but to enjoy the full security benefits, a multiuser system is crucial. Again, I strongly urge users of Windows 3.x, 9x, and Me to install Windows XP, or better yet, Linux.

Windows Services

Both Windows and Linux make numerous services available to applications and to local and remote users. A fair number are superfluous on the typical home system and merely act as potential security holes that may one day be exploited, if they haven’t been already. Services are important vectors of exploitation, generally attacked by worms and by the more capable class of malicious hacker.

Unfortunately, with Windows, disabling services can be a tricky affair: there are quite a few dependencies, and you can inadvertently disable desirable functions or even make your system unstable if you get too aggressive. However, unnecessary services are a route to exploitation and a waste of system resources to boot, so it’s worth doing away with as many as you can.

NOTE  All of the Windows-related instructions in this chapter assume that you have already logged in to your administrator account on Windows XP.

To see which services are running on Windows

  1. Go to the Start menu, choose Run, and type in services.msc. Click OK.

  2. You will now be confronted with an enormous list of running services with obscure names like Application Layer Gateway Service, Background Intelligent Transfer Service, and COM+ Event System (Figure 2-1). Highlight any service and right-click. You will get a menu allowing you to start it, stop it, or view its properties.

   3.  Use the right-click menu to display the properties of the service
       you chose above. The Properties dialog will launch (Figure 2-2).

   4. You will find four tabs at the top of the dialog: General, Log On,
       Recovery, and Dependencies. The General tab will show you the
       service’s name, a brief description, the path to the relevant
       executable file, a drop-down menu allowing you to choose how it
       should start (i.e., Automatic, Manual, or Disabled), and finally,
       four buttons allowing you to start, stop, pause, and resume the


     Figure  2-1.  The Windows Services  menu with the        Remote Access Connection Manager service highlighted

Figure 2-2.  The Properties dialog associated with the Remote Access Connection Manager service

You will notice right away that the descriptions tell you little of value, such as how much memory the service uses, how many remote exploits have been found against it, or whether or not you can safely disable it. I’m going to list services with security implications that can usually be disabled safely on a machine that is not providing network services over a LAN but is used for Internet access. Unfortunately, Microsoft enables most of them by default, so disabling all the risky ones will be tedious and time consuming, though it’s very important that you press on and get it done. It’s best to stop a service using the Properties dialog as described previously, then use the system normally for a while and observe its behavior. You can usually reenable a service if shutting it off causes problems. If nothing untoward happens after a bit of daily use, you can disable it permanently.

Now let’s look at the most important insecure services enabled by default on Windows:

Automatic Updates: This service will automatically connect to the Internet, check for available patches, and install them. I recommend running Windows Update manually and choosing the upgrades and patches to be downloaded, unless you like the idea of letting Microsoft decide what code belongs on your system and when it should be installed. Set it to Disabled. (But don’t forget to run the update manually on a regular basis. Just click on Start -> Windows Update.)

ClipBook: This service stores cut and paste information and allows you to share it with other computers. It multiplies data traces, which complicates the practice of good data hygiene, and also wastes memory. Set it to Disabled.

Error Reporting Service: This service phones home to Microsoft when application errors occur. Set it to Disabled.

Indexing Service: This service essentially maintains data about your data (i.e., metadata) to speed up searching the local drive and the contents of files. It multiplies data traces, completely undermines the practice of good data hygiene, and wastes a good deal of memory. Set it to Disabled.

Internet Information Service (IIS): This is Microsoft’s notoriously insecure Web server. It is usually not installed on XP systems, but if it has been installed it should be uninstalled with prejudice unless you’re actually using it. If you need a Web server, Apache for Windows is a safer alternative that I recommend. However, you should never install any sort of server on a home system unless you need one and know how to run it securely.

Messenger: Often called Windows Messenger, this service broadcasts messages on a network. It is not the MSN Messenger chat client. It is often exploited to broadcast spam across the Internet but has no other useful function on a home or small business network, though it can be useful on large networks when the administrator needs to broadcast a message to all users. Set it to Disabled.

Net Logon: This service allows logging on to a domain controller. This is not required for home and small office networks. Set it to Disabled unless your machine is a member of a domain.

NetMeeting Remote Desktop Sharing: This service permits others to access your computer using NetMeeting. This is a major security hole. Set it to Disabled unless you need it.

Network DDE: This service enables applications on different computers to share data. It’s of no use to most home and SOHO users. Set it to Disabled.

Network DDE DSDM: This service manages network shares. It’s of no use to most home and SOHO users. Set it to Disabled.

Network Location Awareness: This service collects location and configuration information about networked computers. It’s of no use to most home and SOHO users. Set it to Disabled.

Protected Storage: This service saves your login passwords for e-mail, your ISP, and the like. This is not dangerous on a properly configured PC, but I do recommend disabling it on laptop computers, which have a tendency to grow legs. If your laptop is stolen, stored passwords will enable the thief to access your ISP account, VPN, e-mail, etc. Set it to Disabled on laptop computers, and get into the habit of logging in manually.

QoS RSVP: This service provides network traffic information to certain applications. It’s of no use to most home and SOHO users. Set it to Disabled.

Remote Access Auto Connection Manager: This service creates a connection to a remote network whenever a program references a remote DNS or NetBIOS name or address. In other words, it’s a shortcut for embedded links. Set it to Disabled unless you need it.

Remote Access Connection Manager: This service establishes a network connection when Windows Internet Connection Sharing is in use. Using a router for connection sharing makes this service unnecessary. Set it to Disabled unless you need it.

Remote Desktop Help Session Manager: This service controls the Windows Remote Assistance feature, which allows remote users, such as malicious script kiddies, to connect to your machine and tweak all its settings. I strongly recommend against using this service; it is far too susceptible to abuse. Set it to Disabled.

Remote Packet Capture Protocol: This service allows remote users to intercept packet traffic on your machine. This is useful for remote administration, but it is suicidal otherwise. A great boon to malicious hackers and script kiddies: set it to Disabled, with prejudice.

Remote Registry Service: This service allows remote users, such as malicious script kiddies, to tweak your Registry settings to their liking. Set it to Disabled.

Routing and Remote Access: This service allows other computers to dial in to yours through a modem to access the local network. You may need it for some VPN software. Unless you need it, set it to Disabled.

Server: This service permits file and print sharing from your computer, which is a very foolish thing to allow if the computer also connects to the Internet. Unless you are using these features (and preferably on a LAN only), set it to Disabled.

SNMP Service: This is a network monitoring service. It is not necessary on most home or small office computers. Set it to Disabled.

SNMP Trap Service: This service handles messages exchanged between SNMP agents on networked computers. It’s of no use to most home and SOHO users. Set it to Disabled.

SSDP Discovery Service: This service enables discovery of UPnP (Universal Plug and Play) devices on your network. UPnP is very insecure, easily exploited, and should never be used on a machine with Internet access (see UPnP later on this list). Set it to Disabled.

TCP/IP NetBIOS Helper Service: This service provides support for NetBIOS over TCP/IP. However, you should not be using NetBIOS over TCP/IP because it is very insecure. Uninstall NetBIOS if you have it (see the instructions that follow), then set this “helper service” to Disabled.

Telnet: This is a very insecure mechanism allowing remote users to log on to your computer. Never make Telnet available for any reason. If it is installed, set it to Disabled.

Terminal Services: This is an insecure service allowing remote users to log on to your computer. However, a very useful feature called Fast User Switching depends on it. Fast User Switching allows users to move between accounts without ending their sessions. Tasks in one account will remain active while another user is logged in. Unfortunately, Microsoft has made this handy feature dependent on an insecure service. If you disable Terminal Services, your computer will be more secure, but whenever you log out of an account you will have to save all your work because your applications and tasks will be shut down. Choose your poison.

Universal Plug and Play (UPnP): Don’t confuse this with Plug and Play, which is useful and safe. The UPnP service detects and configures UPnP-compatible devices over a network. It is very susceptible to remote exploitation, so set it to Disabled. It works with the SSDP Discovery Service, which should also be set to Disabled (see SSDP Discovery Service earlier on this list).

Upload Manager: This service manages file transfers between clients and servers on a network. Very few home users will have any use for it. It also phones home to Microsoft seeking driver information when devices are installed. Set it to Disabled.

WebClient: This service allows Windows and MS applications to modify Web-based content. Some Microsoft applications may need it. If you have difficulty with MSN Messenger or Media Player, you may need to enable WebClient later. However, if you follow my recommendations and substitute more secure Internet clients for the ones Microsoft supplies, there is little chance you will ever need this service. Set it to Disabled.

There’s a crucial service that cannot be disabled in Windows, which is unfortunate because it is exceptionally insecure. It’s called remote procedure call (RPC), and it allows one computer to execute code on another across a network. This is fine on a LAN, but it is extremely risky if the computer is connected to the Internet. Sadly, the roster of services and applications that Microsoft has chosen to make dependent on RPC is enormous. Disabling it can leave your computer unstable, and, in some situations, unbootable. RPC is essentially a security hole that you can’t live without. The only practical solution is to set your firewall to block TCP/UDP ports 135–139, 445, and 593. Home users may not be able to configure their firewalls to block specific ports, but a good packet filter or router capable of stateful packet inspection should prove adequate.

It is important to uninstall TCP/IP NetBIOS. This is not a good service to have on any machine connected to the Internet. To remove it, follow these steps:

  1. Go to the Start menu and choose Settings -> Network Connections or -> Control Panel -> Network Connections. Click on your network connection device, then on the Properties button.

  2. A dialog will launch. Under the General tab you will find your installed network protocols, services, and clients. If your PC is used for Internet access and does not require additional networking capability, you should uninstall everything except Internet Protocol (TCP/IP). Get rid of File and Print Sharing, NetBIOS, Client for Microsoft Networks (unless you use PGP), and the rest of these superfluous whistles and bells. TCP/IP is the only component you need for an Internet connection to work.

  3. After uninstalling all the unnecessary networking components, left-click on Internet Protocol (TCP/IP) to launch its Properties dialog.

  4. Click the Advanced button and another dialog will launch, labeled Advanced TCP/IP Settings. Choose the WINS tab at the top (Figure 2-3).

   5.  Choose the option labeled Disable NetBIOS over TCP/IP at the 
        bottom. You will need to reboot for all of these settings to take  

Figure 2-3.  The Advanced TCP/IP Settings dialog with proper WINS settings

There is one more notoriously insecure service that we need to disable on Windows, called DCOM (Distributed Component Object Model), which enables software components to communicate directly over a network. It is quite unnecessary for home users, terribly obscure, and the particular service that enabled the MSBlaster worm to attack the Windows RPC service. Power users can open the Registry and alter the key HKEY_LOCAL_MACHINESoftwareMicrosoft OLEEnableDCOM with a value of N and reboot. Novices should disable DCOM thus:

  1. Go to the Start menu, choose Run, and type in dcomcnfg. Click OK, and the Component Services dialog will launch.

  2. In the left pane, choose the menu item Component Services and expand the tree below it. Next choose Computers, expand the tree again, and choose My Computer.

   3.   In the left pane, right-click on My Computer and choose
         Properties from the drop-down menu (Figure 2-4). The My
         Computer Properties dialog will launch.

   4.   Choose the Default Properties tab on the My Computer
         Properties dialog and clear the checkbox in front of the option
         Enable Distributed COM on this computer
(Figure 2-5). You will
         need to reboot for the change to take effect. If the option is
         not available, you’ll need to use the Registry hack mentioned

Figure 2-4.  The Component Service dialog with tree expanded, right-click menu activated 

Figure 2-5.  The My Computer Properties dialog with proper DCOM settings

By disabling insecure services, not only do you shut off many vectors of attack and exploitation, you also create a second line of defense in case you miss an important security patch. This is not to say that you should get careless with system updates, but it’s good to know that if you should miss an important security fix, there’s at least a decent chance that the vulnerable item will have been disabled and the problem therefore will not affect you. Disabling unnecessary services is a good proactive step that can protect you from new exploits, viruses, and worms before they become widely known and before patches become available. For example, if you had disabled DCOM before the Blaster worm struck, you would have been blithely unaware of it.

This chapter is from Computer Security for the Home and Small Office by Thomas C. Greene (Apress, 2004, ISBN: 1590593162). Check it out at your favorite bookstore today. Buy this book now.

{mospagebreak title=Linux Services}

For Linux users, disabling superfluous services is a good deal easier. There are fewer to worry about and far fewer dependencies among them. For example, Linux users can disable RPC without negative consequences, and they should do so unless they need it for NFS (Network File System) or NIS (Network Information Service). Home network users and home business users are unlikely to be using these services, so it’s almost always good to disable RPC.

Unlike Microsoft, most Linux vendors will not install many superfluous services and Web applications by default. But it is important to check the following list in case you’re running a service that you don’t need. If you’re using a major, packaged distribution, it’s likely that only a few of these services will have been enabled by default.

There are numerous ways to disable services in Linux, though these depend on the particular distribution you’re using. For this reason, it will not be practical to provide screen shots. Essentially, you want to halt the daemon, ensure that the system continues to work normally, and then disable it permanently. An easy way to do this is via a GUI admin interface, but of course these vary by distribution. Usually, there will be an admin utility allowing you to select runlevels for various components, where your services or daemon processes will be displayed and can be enabled, disabled, started, and stopped. Linux is usually very tolerant of having services disabled, but you should stop the daemon first and see how the system behaves before making a commitment. If your machine continues to function normally, you can remove it from all runlevels, and even from your /etc/init.d directory so that it can’t start again if you reboot.

Here are the main ones you should look out for:

Apache: This is a fine Web server. Most Linux distributions are filled with more packages than any person could possibly use, and sometimes, due to this embarrassment of riches, servers like Apache can be installed without the user’s realizing it. If you don’t need a Web server or don’t know how to run one securely, you should uninstall it promptly.

Berkeley Internet Name Domain (BIND): This service translates domain names to IP addresses. Unless you are operating a server, you have no use for it. Disabling it will not affect your Internet clients: your ISP will provide BIND or DNS services for you. The daemon is called named and should be disabled.

File Transfer Protocol (FTP): This is a file server. Few home users will have any use for it. The daemons are called wuftpd and proftpd; get rid of them unless you need to make FTP available and know how to secure it.

Line Printer Daemon (LPD): This service allows users to connect to a printer across a network. It is exceptionally insecure and should be disabled with prejudice.

Nessus: This is a vulnerability scanner that runs a daemon process. It’s not terribly dangerous, but there is no point leaving it running when it’s not in use, lest others connect to it. I recommend enabling and disabling the nessusd daemon from the command line and leaving it out of your runlevels.

Network Information Service (NIS): This service allows networked machines to share a common interface. It is not so much vulnerable in itself but it requires RPC, which is. Home users should not have any use for it.

Network File System (NFS): This service provides remote access to shared file systems across a network. As with NIS, it is not so much vulnerable in itself but it requires RPC, which is. Home users should not have any use for it.

Postfix: This is a fairly reliable mail server. Few home users need a mail server or know how to run one securely, so this should be disabled, but not uninstalled. Some mail clients may require it to be present, though not running.

Remote Procedure Call (RPC): Sometimes called sunrpc or portmap, this should be disabled except when NIS or NFS are in use. Any daemon with rpc or portmap in the name is a good candidate for disabling.

Rlogin: This service accepts remote logins. It is only slightly more secure than Telnet and should be disabled. Use SSH or Webmin if you need to log in to your machine remotely.

Samba: This is a file and print sharing service that offers Windows compatibility. It’s unnecessary on most home machines. Computers used primarily to contact the Internet should not be offering such services unless they have to, though Samba can be quite useful in an office if you know how to run it securely.

Secure Shell (SSH): This service accepts remote logins. You should disable the SSH daemon (sshd) unless you need to connect remotely to your computer. If you do connect remotely, SSH is the most secure method and should always be preferred to Telnet and rlogin. Disabling the SSH daemon will not cause any problems when using an SSH client.

Sendmail: This is a mail server. You probably don’t need a mail server, so uninstall it. If you do need a mail server, you should still uninstall Sendmail and replace it with Postfix, which is more secure. Some e-mail clients may require Postfix to be installed, though not running, so disabling it is better than uninstalling it.

Simple Network Management Protocol (SNMP): This service allows for configuring devices over a network. Home users should have no use for it. There are plenty of exploits against it, so disable the snmpd daemon unless you really need it.

Squid: This is a proxy server, and a fine one, but it’s a security issue if you don’t need it and don’t know how to secure it. If you don’t know what a proxy server is, then you absolutely don’t need one. Uninstall it if you find it’s been installed.

Telnet: This is a hopelessly insecure service that permits remote logins. Disable it; remove it from /etc/init.d; exorcise it.

Webmin: This is a fairly trustworthy server for remote administration. However, if you don’t need it, uninstall it. If you’re not going to use it, there’s no point making it available to others on the Internet, like malicious script kiddies.

Ypbind: This daemon supports Network Information Services (NIS). There have been exploits against it. Again, as with any service, if you don’t need it, disable it.

Power User Tip

Linux power users can prevent their X server from listening on the Net by editing the relevant configuration file. Depending on your distribution, the file might be found in one of these locations: /etc/ opt/kde3/share/config/kdm/ Xservers, / etc/X11/xdm/ Xservers, / usr/X11R6/lib/X11/xinit/xserverrc, or /etc/X11/ xinit/ xserverrc. Find the line starting with :0 local [etc…], and without altering it otherwise, add -nolisten tcp at the end. The X server’s TCP access is not considered a menace, but this will keep you safe from a new or unknown exploit.

This chapter is from Computer Security for the Home and Small Office by Thomas C. Greene (Apress, 2004, ISBN: 1590593162). Check it out at your favorite bookstore today. Buy this book now.

{mospagebreak title=Becoming a User}

If you’re the owner of a Windows machine—even if you’re the only person who uses it—the surest step that you can take toward improved system security and user privacy, after installing Mozilla and disabling unnecessary services, is to set up an individual user account with limited privileges for yourself and everyone else who uses the computer.

Before you begin, it’s necessary to set your file display characteristics and permissions so that you can control them yourself. Windows defaults to a condition called simple file sharing, which is an obstacle to good security in general, and to setting proper file and directory permissions in particular.

  1. Go to the desktop Start menu and choose Settings -> Control Panel -> Folder Options. The Folder Options dialog will launch.

  2. Choose the tab labeled View from the top of the Folder Options dialog.

  3. Check the boxes or radio buttons next to the items labeled Display the contents of system folders and Show hidden files and folders (Figures 2-6 and 2-7).

  4. Next, clear the checkbox next to the item labeled Hide protected operating system files (Recommended). You will be warned against clearing this box, but you need to know what’s on your system if you want to make it more secure. Ignore the warning (Figures 2-6 and 2-7).

  5. Finally, clear the checkbox next to the item labeled Use simple file sharing (Recommended). Click Apply and finally OK (Figures 2-6 and 2-7).  

Figure 2-6.  The Folder Options dialog with recommended settings

Figure 2-7.  The Folder Options dialog with recommended settings, continued

Now, if you didn’t choose an Administrator password when you installed Windows XP, do this first. Incredibly, Microsoft permits users to run XP as a single-user system, defeating its inherent security advantages, and permits the creation of accounts without password protection. However, there’s no reason for you to follow a bad example.

If you’re installing Windows XP, it’s best to set an Administrator password when the opportunity is presented so that you won’t have to bother with it later. Windows makes setting an Administrator password after the installation more complicated than it ought to be, but if it hasn’t been done, it definitely needs doing. So let’s get it out of the way. 

  1. Go to the desktop Start menu and choose Run and type in compmgmt.msc. Click OK, and the ComputerManagement dialog will launch.

  2. In the left pane, select Local Users and Groups, expand the tree, and choose Users.

  3. >You will see several users listed in the right pane, such as the Administrator, Guest, and the name you chose for yourself when you installed Windows, which is also an administrator (Figure 2-8). Windows XP sets the person who installs the system as an administrator, but not the Administrator. What’s the difference between the Admin and an admin? Basically, the Admin is an inbuilt account coded into Windows, whereas an admin is whoever installed the system, plus any other users he decides to nominate for the honor. Let’s concern ourselves first with the Admin, or the built-in account.
  4. Highlight the Administrator account and right-click. The drop-down menu allows you to set or reset the password. If you’ve already set a password but think it might be weak, then you should reset it with a better one, using the instructions that follow.

    Make your password a difficult one, combining uppercase and lowercase letters, numerals, and special characters like the dollar and pound signs. It should be at least eight characters in length, though when it comes to passwords, longer is always better. I recommend using a short phrase that makes no sense, like “sleazy bricks.” Use some uppercase and some lowercase letters, and substitute characters that resemble a few of the other letters so it looks something like this: sl34ZybR1@k$. Note that we’ve substituted numbers and special characters that, at least vaguely, resemble the letters they’re standing in for to make the password easier to memorize. You can write it down and keep it in a secure place until you’re sure you’ve memorized it. A password like this will be practically impossible to brute force or crack with a dictionary attack.

    When you set the Admin password, you will receive a warning that numerous problems might arise. Ignore it.
  5. Once you’ve pass-protected the built-in Administrator account, set a strong password for yourself as an administrator, associated with the username you chose when you installed Windows XP.You can use the same password for both accounts with little risk, so long as it’s a tough one according to our guidelines. It is usually safe for home users to disable the remaining  built-in accounts provided by Microsoft, except the Guest account, which may prove useful. Personally, I would disable every account except the Admin, your admin account, and the Guest account at this point (unless you’ve already added users, obviously).
  6. To enable or disable an account, select it in the Computer 
    Management dialog, use the right-click menu, and choose Properties. In the Properties dialog, under the General tab, find the checkbox next to the option Account is disabled (Figure 2-9).

    Figure 2-8.  The Computer Management dialog with  Users selected

    Figure 2-9.  The Computer Management Properties dialog with default MS”Help Assistant” account disabled

If you haven’t established a user account for yourself or added any other users, you should do so now. But you can close the Computer Management dialog at this point; things will get easier from here.

Now it’s time to add users, and this means you too.You’ll remain an administrator, of course, but you’re going to set up and start working from an unprivileged account except when admin access is needed for altering system settings or installing software, just like any security-savvy person. This is not difficult:

  1. Open the Start menu and go to Settings -> Control Panel -> User Accounts. A window will open, most likely reminding you that you are the system administrator.

  2. Create a user account for yourself. Choose Create a new account, and then choose a login name. Choose limited for the account type and click the Create Account button.

  3. Now create a password for the account. This is the account you should use at all times, except when you need to perform administrative tasks.

  4. Simply repeat the process, choosing limited accounts for each user. You can also activate the Guest account so that occasional visitors and house guests can use your computer without accessing any of the established user accounts. However, the Guest account is not password protected, so anyone can use the machine with it. Privileges are low, but this is not a good option if you are unable to supervise use of the computer for extended periods. If you don’t set up the Guest account, it will not appear on the boot screen.

Once you’ve got yourself and every other user working from limited-access accounts, you will enjoy a fundamental security advantage. Malware that you and other users pick up while surfing the Web or from e-mail or instant messaging will have less impact on the system. Scripts and malicious files will have less access to the system. Computer and Internet use by children can be restricted.

Linux does a far better job of sandboxing user accounts from the system than Windows, better limiting the impact of malware and risky behavior. Linux passwords are also more difficult to crack because they’re hashed more effectively. However, by taking full advantage of the multiuser features of Windows XP, you will in fact go a considerable distance toward improving security and user privacy.

Linux users have it easier from the start. They are required to set up a root account with a password, plus at least one user account (also with a password), when they install the system. Linux doesn’t allow users to make the mistake of running their PCs as single-user systems. Novices who are in the habit of running their computers from the root account should immediately switch to running from a user account. It is rarely necessary to use the root account as a working environment, because virtually all administrative functions are available from your user account. With a command shell, simply enter the command su and you will be prompted for the root password and granted root access. Close the shell when you’ve finished your task, or anyone with access to your machine when your back is turned will have access to a root shell. Alternatively, you can lock the screen if you need to leave your computer while a root shell is open, that is, you can activate your screen saver in such a way that your password is needed to clear it, by choosing the Lock Screen option from the KDE Start menu. If you prefer using a GUI admin interface, such as Mandrake’s DrakX or SuSE’s YaST, simply select it from the desktop menu and enter the root password when prompted. Make sure that your root password is at least eight characters long and difficult to guess according to the previous example. It’s best to hash passwords using MD5, which is stronger than the default. You will find this option in your admin interface under a category such as security and users. If you set up your system with weak passwords, by all means reset them with better ones.

This chapter is from Computer Security for the Home and Small Office by Thomas C. Greene (Apress, 2004, ISBN: 1590593162). Check it out at your favorite bookstore today. Buy this book now.

{mospagebreak title=Read, Write, Execute}

Permissions for limited user accounts can be fine-tuned beyond the default levels of access afforded by Windows and Linux, which may be too permissive in some situations. However, tweaking file and directory permissions is not trivial and can cause problems if done carelessly.

The three basic file and directory permissions are read, write, and execute. Such permissions are usually granted, in varying levels of authority, to groups such as users or administrators. However, it is possible in both Windows and Linux to choose individual directory and file permissions for particular users. This enables the machine’s owner to set up a user account for himself with fairly liberal permissions, and to set up another user account for a child, say, or a housemate, with more restrictive ones. This way, people sharing your computer can be kept from opening (i.e., reading) files and directories with sensitive data, from altering (i.e., writing to) program configuration files, and from activating (i.e., executing) programs you choose not to make available to them.

However, altering permissions recursively, that is, applying access restrictions that affect all of the contents in a directory, can result in unpleasant surprises. A directory, or a subdirectory within it, may contain program executables or configuration files needed by applications. If these files are unintentionally restricted with recursive changes, a user might be unable to launch programs that he is otherwise authorized to use.

Applying permissions is a good deal more complicated in multiuser versions of Windows than it is in Linux, but Windows allows more granular control, which is good for experienced administrators, though it presents a challenge to home users. The procedure may seem confusing, but basically, you will first choose the directory or file to be restricted, then choose the users to be permitted or denied access. To restrict individual users from running particular programs or browsing certain directories in Windows, do the following:

  1. Log in to your administrator account and left-click on the My Computer desktop icon.

  2. Under Hard Disk Drives, click on Local Disk (C:). You will see a list of top- level directories such as Program Files, WINDOWS, etc. (Alternatively, you can launch the Windows Explorer file browser; the procedure is the same.)

  3. Let’s assume that you have a user called tcg with an account on your machine and you want to disable access to the system directory for him alone. Navigate to the WINDOWSsystem directory.

  4. Highlight the directory, right-click, and select Properties from the right- click menu (Figure 2-10). 

Figure 2-10. Selecting properties for the system directory

   5.  When the Properties dialog pops up, choose the Security tab.
        There will be two fields: at the top, a list of user groups, and 
        below, a list of possible permissions. However, if you apply
        restrictions to a group such as Users, then every user will be
        denied access. To specify an individual user, click on the
        Advanced button (Figure 2-11).

       Figure 2-11. Choosing the Advanced user permissions dialog

   6.  This will bring up the advanced security settings dialog. Again,
        you will see Users listed as a group. Click the Add button and
        enter the desired username, tcg, manually in the lower field 
        under Enter the object name to select (Figure 2-12). Click OK.

Figure 2-12.  Choosing a user instead of a group

   7.  You will then get another dialog showing the user you chose
        associated with the system directory. You can now choose the
        user’s permissions for that directory. Unfortunately, there is a
        plethora of options. To make it simple, choose Deny in the top
        line labeled Full Control to remove the user’s permission to view
        or launch files in the system directory. This will change all of the
        options at once (Figure 2-13).

Figure 2-13.  Denying a user access to the system folder

   8.   Click the OK button; you will return to the advanced security
         settings dialog. Click Apply.

   9.   You will see a new line with the word Deny followed by the
         username. Click OK and close the system directory Properties
         box. The user you chose will not be able to view or activate 
         any files in the system directory.

You can use this basic procedure to fine-tune file and directory permissions for each user. You could, for example, deny a small child permission to use a chat client like ICQ or an e-mail client on his own. But remember, if you apply limits to the Users group, all users will be kept from the directory or program file chosen. To specify users for particular file and directory restrictions, you must bring up the advanced security settings dialog and apply the restrictions individually as just described.

This technique can be used to keep children from applications and directories that parents don’t want them to access without supervision, even when they’ve been given their own computers. A parent simply needs to set up an administrator account for himself with which to maintain the machine and assign user accounts to each child. Children can be granted different levels of access depending on their ages, regardless of whether they use their parents’ computer, share one among themselves, or have their own machines. This way, young children can be kept from e-mail, browsers, and chat clients, while older children can be allowed to use them in their own accounts. This can help ensure that the very young will not be exposed to online content unless an older sibling or a parent is around to supervise them. Even when each child has his own computer, a parent can still administer it and decide which programs can be accessed. Thus, multiuser systems like Windows XP and Linux offer significant advantages for parental control regardless of whether children use their parents’ computers, each others’, or their own. Because a good deal of malware installs itself to the C:WINDOWSSystem, C:WINDOWSSystem32 and ~Startup directories, it’s not a bad idea to restrict write access for all users following the preceding instructions. This way, if a user encounters a bit of malware, it will not be able to install itself to these directories. This will not prevent all malware from installing itself, but these are popular destinations, so disabling write access is worth the effort. Simply navigate to the ~System and ~System32 directories and disable write access for the entire group Users. You should deny the actions Write and Modify in the Properties -> Security setup field. You will still be able to write to these directories from your administrator account, which may be necessary when you’re installing new software or hardware.

NOTE  The tilde (~) can indicate two things: a shortened directory path or a directory whose name would vary on different computers. Thus,
C:WindowsTemp might be shortened to ~Temp, and /home/username/ Documents might appear as /home/~/Documents.

Unfortunately, there is a separate Startup directory for each user, and write access must be disabled for each one individually. The Startup directories are located in C:Documents and Settings~Start Menu ProgramsStartup, that is, C:Documents and SettingsusernameStart MenuProgramsStartup.

  1. Navigate to the Startup directory for each account, including your administrator account and the accounts All Users and Default User, and deny write access to these directories for the group Users.

  2. It may be necessary to add the group Users with the Advanced button in the Properties -> Security dialog.

  3. You should deny the actions Write and Modify in the setup field. This is not at all difficult, but it is tedious, though worthwhile.

You will still be able to add startup programs to any user account and install software from your administrator account.

Linux goes about things differently. An unprivileged account under Linux is better controlled than one under Windows: users have a harder time getting into mischief or mucking up the system because there’s not much damage they can do outside their home directories to begin with. Thus, malware is far less likely to affect the system overall.

NOTE  Setting up the /home directory alone on a separate primary partition will further enhance the system protection inherent in the Linux user sandbox.

On Windows, it’s often easier to work with users, whereas on Linux it’s often easier to work with groups. When you wish to restrict users on a Linux system from directories or program files, a simple approach is to raise the level of privilege needed, then increase the privileges of users to whom you wish to grant access by adding them to a group with greater privileges. (You can do this on Windows, too, but with so many options it can become confusing.) For example, on Linux you might confine the ICQ (licq) program file to access by the group trusted, and then add yourself, your spouse, and your older children to that group. Young children would remain in the group users only, and not be able to access the ICQ binary from their accounts. The other users would belong to two groups, users and trusted, and so be permitted access by virtue of their membership in the trusted group.

The easiest way to change file and directory permissions is by using a GUI file browser like Krusader or Nautilus, because if you have a lot of files to deal with, making these changes at the command line will be ted You can certainly make these changes from a user account with a root shell if you understand the commands chmod, chuser, and chgroup (well worth learning, by the way), but if you want to use a GUI method, you’ll have to log in as root. Simply navigate to the files you wish to restrict, right-click, and pull up their properties. You will find a simple dialog for setting permissions. The options are read, write, and execute. If you want only one user to have access, then clear the checkboxes on the lines labeled Group and Others. If you wish to allow a group to access it, simply check off the permissions you intend to grant on the line labeled Groups and then specify the group in the field below. If you wish to allow every user to have some access, check off the permissions you intend to grant to members of additional groups on the line labeled Others.

In Figure 2-14, the user tcg is the only one permitted to view, enter, or write to his /home/tcg/Documents directory. Root has free access to the entire system by default, but fellow members of the group to which tcg belongs (users), and all others, are denied access.

Figure 2-14.  Setting directory permissions with Krusader

Because permissions are simpler on Linux than on Windows, it’s easier to work with groups than with individual users. If you wish to grant file or directory access to some but not all users, you can assign a directory’s or a file’s access rights to a more privileged group, such as trusted, then add only the users you choose to that group. And that’s all there is to it. Linux makes this procedure quite painless.

You can do permission tweaking with directories, but the earlier cautions about recursive changes apply. If you overprotect a directory, you may block user access to program files or configuration files that you wish to make available. It’s also very easy to edit group permissions in terms of the system services available. Small children can have Internet access disabled, for example, by raising the permission level needed to access the service and then denying them membership in the group authorized to do so.

So, if you’ve carried out the instructions in this chapter, you’ll have hardened your machine significantly according to the first two of our trio of principles: prevention, resistance, and tolerance.

And neither your firewall nor your antivirus software had a thing to do with it.

1. Ian Austin, “To Each, His Own: Sharing a Family PC,” New York 
, August 14, 2003.

This chapter is from Computer Security for the Home and Small Office by Thomas C. Greene (Apress, 2004, ISBN: 1590593162). Check it out at your favorite bookstore today. Buy this book now.

[gp-comments width="770" linklove="off" ]

chat sex hikayeleri Ensest hikaye