Bảo mật hệ thống mạng part 52 ppsx

APPENDIX
B
Unix vs. Windows:
Which Is More Secure?
353
Copyright 2001 The McGraw-Hill Companies, Inc. Click Here for Terms of Use.
354
Network Security: A Beginner’s Guide
T
he debate about which operating system is more secure has been raging for years. Is
Unix more secure than Windows? Is Windows more secure than Unix? Which op
-
erating system should be used for mission-critical applications? If you ask these
questions of ten security professionals, you are likely to get ten different answers and you
will still not have a clear cut answer.
An examination of both operating systems reveals that both have incorporated secu
-
rity into their designs. Both Unix and Windows have access control mechanisms, authen
-
tication mechanisms, and audit mechanisms. On the flip side, both Unix and Windows
are made up of many lines of code (millions). There will certainly be bugs in that much
code, and some of those bugs will cause security problems.
In the following sections, we will take a look at various issues in the overall security
debate. Hopefully, by the time you reach the end of this section, you will have a better un
-
derstanding of the issue (if not the solution).
TIMES CHANGE
The Internet has been around for a while. TCP/IP was designed many years ago and
Unix followed closely behind it. In fact, the history of Unix and the history of the Internet
are so intertwined that it is difficult to separate the two.
Of course, the security issues surrounding the Internet were not immediately appar-

ent. It took a while for the Internet to grow into an online community where some of the
inhabitants were not completely trustworthy. When these individuals tried to break into
systems, there was only one type of system to break into—Unix. And so they did.
At first, the vulnerabilities that were used to gain access to systems were poor config-
urations and even poorer passwords. Mostly the attackers did not do bad things to the
systems but rather they wanted to see what the systems could do.
Regardless of that, by the late 1980s criminal hackers were in the mix. In 1988, two
events occurred that transformed the way we looked at security:
▼
The Morris worm was launched and disrupted the entire Internet. The worm
used known vulnerabilities and weak passwords to gain access to a system.
Once there, it replicated itself and gained access to more systems.
▲
At the end of 1988, the Computer Emergency Response Team (CERT) at
Carnegie-Mellon University was formed. The first advisory was issued
at the end of 1988.
The perception that was gained from these events was that the Unix systems on the
Internet were insecure. In fact, for all of 1989, 1990, and 1991, the only CERT advisories
were about problems on Unix systems. It was not until 1992 that a CERT advisory men
-
tioned Windows systems (CA-92.02). This advisory was not about attacks against Win
-
dows systems but instead it was about the Michelangelo virus. The next CERT advisory
that included Windows occurred in 1997 (CA-97.28), which described denial-of-service
attacks called teardrop and land. These attacks also affected Unix systems.
In fact, it was not until 1998 (CA-98.04) that a CERT advisory specifically for a vulner
-
ability in a Windows system was finally released. If you just look at the number of adviso
-
ries until that point, it would be easy to assume that Windows was a much more secure

operating system. There were many fewer advisories against Windows than against Unix
systems.
Of course, the main reason for this was that Windows (specifically Windows NT) had
not been in use very long and toward the end of the 1990s was only beginning to be used
on the Internet. At the same time, the World Wide Web was coming into its own and Web
servers were being made to run on Windows systems.
Now there are many security advisories for Windows systems. In fact, every month
there are several that are issued by Microsoft itself plus others that are issued by software
vendors and other organizations. To the casual observer, it may appear that the tables
have turned and now there are more vulnerabilities in Windows than in Unix. This is not
quite true as vulnerabilities continue to be found in various versions of Unix and on
Unix-specific applications.
VIRUSES, TROJAN HORSES, AND WORMS, OH MY!
Computer viruses have existed since MS-DOS was in use on PCs. First, they spread by
people exchanging floppy disks. Then they spread over computer bulletin boards where
unwary users downloaded infected files. Viruses were a PC problem and the problem
has continued into Windows NT and Windows 2000. The newest viruses spread by
e-mail and can infect documents as well as executables and boot sectors.
Unix does not have any viruses, right? Wrong. There are Unix viruses but you don’t
hear about them much because it is much harder for them to spread on Unix systems due
to the way Unix systems segregate user memory and actions from the system and admin-
istrator memory and actions. This would appear to show that Unix was more secure than
Windows. Viruses are one of the most costly security issues in organizations today. Per
-
haps we could eliminate the problem if we all used Unix workstations? Perhaps, or per
-
haps the people that write such programs would just change the way they work.
Unix systems have their own forms of malicious code. Remember the Morris worm
that I mentioned? It was able to infect most of the systems on the Internet at the time. In
fact, it was able to effectively shut down large portions of the Internet. Has any Windows

virus done that? And just recently (late 2000, early 2001), the Ramen worm made an ap
-
pearance. This worm was capable of scanning target systems for vulnerabilities, identify
-
ing vulnerable systems, exploiting the vulnerability, and installing itself in the new
system. Sounds pretty bad, doesn’t it?
But what about the Trojan horse programs that are running around the Internet in
-
fecting Windows systems? (The most recent set of *.vbs programs are actually Trojan
horses, not viruses as has been reported.) These programs masquerade as either a picture,
movie, or program that people might want to run. When the unfortunate victim runs the
file, the program infects the local system and spreads to others. The ability to call any DLL
on the Windows system from inside a Visual Basic file (or a macro for that matter) allows
Appendix B: Unix vs. Windows: Which Is More Secure?
355
the program to send itself via the victim’s e-mail to other potential victims. This certainly
qualifies as a major security vulnerability in Windows, right?
Perhaps, but Unix systems can also be infected with Trojan horses. They could arrive
via e-mail attachments or they could be placed on the system by an intruder. The only real
difference is that the administrator of the system must be tricked into running the pro
-
gram. In most cases, a normal user running the program will not achieve the same results.
OPERATING SYSTEM VULNERABILITIES
VS. APPLICATION VULNERABILITIES
When we talk about vulnerabilities, we should note a difference between operating sys
-
tem vulnerabilities and vulnerabilities within an application running on the operating
system. From a results point of view, many will say that it is a difference without a differ
-
ence since either type will get you root or administrator. While this is true, we are discuss

-
ing the relative security of operating systems and thus we should limit our discussion to
operating system vulnerabilities, right?
On the surface, this sounds like a no-brainer. But where do we draw the line between
operating system and application? Is RPC part of Unix? Is Explorer part of Windows? In
many cases, it is not so simple to separate out the application from the operating system.
Perhaps a program like WU-FTP could be separated out as Unix systems do not need to
have an FTP server and even if they did, it could be something other than WU-FTP. Same
is true for MS IIS. A Windows system could use a Netscape Web server rather than IIS.
But this is not the issue at all, is it? The real issue is that if an attacker can break an ap-
plication, why does this allow the attacker to gain control over the entire system? Unfor-
tunately, many applications must run as root or administrator in order to work properly.
This forces the administrator of the system in question to trust the application to work
properly and to not have any vulnerabilities. Well, we already know that that is not a
good assumption. The list of application vulnerabilities is long and includes mail, DNS,
FTP servers, Web servers, and so on. Just about every type of application that runs on top
of Unix or Windows and makes services available over the network has had a serious vul
-
nerability at one time or another.
And it seems that system administrators are powerless to control the root access of
these applications! If for no other reason, applications that open ports below 1024 must be
root just to open the port and listen for connections. Perhaps this is a reason to scrap both
Unix and Windows and start from scratch to get rid of some of these problems!
INTERACTIVE VS. NON-INTERACTIVE
Let’s leave the discussion of vulnerabilities for a moment and talk about how the two op
-
erating systems are used. Unix systems tend to be interactive via the command line. If
you telnet into the system, you are interacting with a shell and providing commands to be
356
Network Security: A Beginner’s Guide

carried out by the operating system. You can move around the directory structure by is
-
suing cd commands. You can look at files and run programs.
On a Windows system things are a little different. Sure, there is a command prompt
where I can do similar things but the command prompt is available via the system con
-
sole (the desktop). I can’t telnet into a Windows system (by the way, with Windows 2000,
you can start a telnet daemon and thus telnet into the system for a command prompt, but
let’s talk more about history for a moment). Generally, it is difficult to get the same type of
interactive access to a Windows system. There are, of course, programs that give you con
-
trol of a remote Windows desktop. These tools range from commercial tools like PC Any
-
where to hacker tools like Back Orifice and Sub Seven.
Perhaps we should think of these remote control tools as the equivalent of telneting
into a Unix system or gaining a root shell through an exploit. If you think about it, before
these remote control tools came on the scene, hackers did bad things to Windows systems
but they always had to load software to do it. Now, if the remote control tool exists on a
system, I can look for the same types of vulnerabilities that I looked for on Unix sys
-
tems—bad configurations and weak passwords. If I can guess the administrator’s pass
-
word to PC Anywhere loaded on a server, I can control the server.
So maybe there was something to this interactive versus non-interactive concept at
one time but maybe it has gone away. Of course, the attacker still needs to get the remote
control tool loaded on a system but there are many ways to do this (just think back to the
fun you could have if one of the *.vbs Trojans loaded Back Orifice on all of your
desktops!).
SOURCE CODE OR NO SOURCE CODE
There is a concept in the security world that says that a program that has been reviewed

by others is more secure than one that has not. Cryptographers take this to extremes by
saying that any algorithm that has not been reviewed by the world is not appropriate for
use (OK, so I am exaggerating a bit). The U.S. government used to put all software that
was written for nuclear weapons release through a program called IV&V (Independent
Verification and Validation). This meant that the code was written by one team and an
-
other team from a different company would review it line by line to verify what it did.
This makes sense for code that could launch a nuclear weapon.
But does this concept make sense for operating systems or applications? Certainly,
peer review makes code better. There are hundreds of stories of reviews identifying
better ways to do things to make the code more efficient or to spot problems before they
get into the complied executables. I am also sure that every manufacturer of software has
some mechanism for internal peer review. It only makes sense.
There is a difference here between some forms of Unix and Windows. You can get the
source code for some forms of Unix (such as Linux, FreeBSD, and so on). You can’t get the
source code for Windows. Does this mean that we should lump versions of Unix that do
not have released source code in with Windows as far as security is concerned? I don’t
know. How are we dividing up our operating systems? Is the debate no longer Unix
Appendix B: Unix vs. Windows: Which Is More Secure?
357
versus Windows but rather open source versus closed source? That would change things
a bit, wouldn’t it?
I’m not sure that you would find the proof to make this type of argument anyway.
Some of the software with the most security vulnerabilities has been open source. On the
other hand, some of the most secure versions of Unix are also open source.
One thing I should mention on this topic, however, is that open source had one real
benefit. If I have the appropriate expertise and I have an open source operating system, I
can change it and perhaps reduce the security vulnerabilities. If the operating system
does not come with source code, I can’t do that. I have to live with the security provided
by the vendor and wait for the vendor to make patches for security vulnerabilities.

EXPERTISE
There is one last issue I would like to mention on this topic. A good system administrator
is the best security your organization can have. What makes a good system administra
-
tor? Perhaps it is knowledge of the operating system or number of years of experience.
Perhaps there are other character traits that make someone just a good employee.
Is a good system administrator a good system administrator on any operating sys-
tem? I’m sure there are some people like this. But I would be willing to bet that a good
Windows administrator might not be too good at Unix (at least at first) and vice versa.
Maybe it is better to say that a good system administrator could be good at any oper-
ating system given the appropriate amount of training and experience. If we accept this
statement as true, then perhaps the expertise of the administrators plays a role in the se-
curity of the operating system. It would be silly to claim otherwise. Of course, the exper-
tise of the administrator plays a role in the security of a system.
CONCLUSION
So what can we finally say about the security of Unix versus Windows? In the end, not
much. When Windows NT first began to be used for Internet applications, there may
have been an argument (albeit weak) that Windows was more secure since it had fewer
known vulnerabilities. Of course, the reason that fewer were known was that the systems
were hard to find on the Internet. Most of them were deep inside organizations where the
common attacker could not reach them. Over time we saw this myth contradicted.
What about inherent problems in the operating systems? Windows allows viruses but
both operating systems have trouble with Trojan horses and worms seem to be more of a
problem for Unix. It would appear that malicious code causes problems for both operat
-
ing systems.
We could almost argue that both operating systems are fairly secure and that it is the
applications that cause all the problems. Almost. But where does the operating system
stop and the application start? And, is it not the operating system’s problem when many
applications have to run with excessive privileges?

358
Network Security: A Beginner’s Guide
Both operating systems appear to be interactive these days. So if an attacker gains ac
-
cess, he can really gain access. Once into the system, the attacker can take total control of
the system. Files can be deleted and even the CD-ROM can be opened remotely.
Does peer review and the availability of source code make one more secure than the
other? Hardly. If this were the case, Linux should have no bugs at all! And Solaris and
Windows should be equivalent in security.
What are we left with? The expertise of the administrator. When it comes right down
to it, the security of the system depends overwhelmingly on the expertise of the adminis
-
trator. The administrator must configure the system securely on setup. The administrator
must add and remove software as necessary. The administrator must follow procedure to
add and remove users from the system. The administrator must keep up with patches
and fixes on the system. And finally, the administrator must keep watch on the system to
identify when problems occur.
Is Unix more secure than Windows? Is Windows more secure than Unix? The answer to
both questions is yes and no. Who is the system administrator for the system in question?
Appendix B: Unix vs. Windows: Which Is More Secure?
359
This page intentionally left blank.
TEAMFLY

Team-Fly
®