Sept. 2000 Vol. 221 No. 9
Feature Article
|
Practical systems security
Part 1 The upstream IT community needs to be vigilant in keeping
its data systems secure. Risks are often poorly assessed, while myths and misconceptions abound. A systems
administrator gives advice to peers on practical solutions
Will Morse, Anadarko Petroleum Corp., Houston
any people
agree that computer security can be greatly improved in petroleum exploration; yet, practical information on
how to do this is scarce. There are services that offer security audits or break in and show how they
did it; but rarely do these audits result in a practical plan that improves security. There are also many
books on computer security, but these seem oriented toward college campuses or Internet Service Providers
(ISPs). Many suggestions in these books would be difficult to use in petroleum-exploration applications. This
article discusses practical ways that the IT professional can both improve computer security and allow the use
of exploration applications.
What is computer security? For this article, it is defined as: preventing loss
or compromise of business data and function where these data and functions are realized through computing
hardware and software. In Part 1, a variety of risks, myths, some non-solutions and misconceptions will be
addressed. Next month, Part 2 will show a list of practical solutions.
Risks
While general risks major hardware or software vendors going out of
business, loss of key personnel, flood, fire, etc. are not what people usually think of when talking
about computer security, any overall plan to protect information has to include them.
Physical security. Physical security means that no one can walk into
an office and remove a computer data and all or just destroy it in place. There is no point in
using sophisticated tools or changing passwords monthly if someone can just take the computer or remove a map
off the wall.
Physical security also means protecting computers from destruction by power
surges, power outages and air conditioning failures. Whether a power surge, virus or midnight electronic
intrusion erased data, there is not much difference in the effect on business continuity. Although it is
difficult to guard several-hundred individual computers, the data within them can be stored on central data
servers that are kept in a locked, power protected, air conditioned and secure data center. It is easy to
replace dataless desktop computers.
A good backup system and a way to store backups off site are essential. These
should be part of any disaster-recovery process. Physical security will not eliminate risk, but it is a
foundation.
Media security. Where are source-data and backup tapes kept? In a
geoscientists desk? In a data-managers desk? And what about diskettes, CDs, scratch maps and
sections. What happens to paper that is thrown away? All tapes should be checked in / checked out from a
locked cabinet, with some means of verifying that none are missing. The cabinet should be fireproof, water
resistant and located in a protected data center. There should be copies of the most critical data in an
offsite, protected center. Label and catalog tapes and other media. Maps, sections and other discarded
paperwork need to be shredded. A dumpster is not secure.
Inappropriate use. The issue here is what is revealed to potential "enemies"
about your system. There are a lot of systems-administrator newsgroups and other forums on the Internet. If
the systems administrator posts a message such as, "Im having trouble with my firewall; it looks
like this . . . ," it can be an open invitation to troublemakers. Even if a message is not directly a
problem (say someone in your company gets involved in a "flame war" and offends someone) that person
can use Yahoo! to look for information they can use to punish the offender and your whole company in
the process.
Additional basic rules:
- Dont make e-mail names the same as login names. If someone is going
break into your system, the easiest way is with a username and password. Break-in is a little harder if they
have to guess both username and password. Also, ensure that both "From:" and "CC:"
are covered.
- Consider usernames which are not made up of parts of peoples names or
their departments. If someone knows your name, he can guess usual patterns for usernames. Further, many
people use family details as part of their passwords. By making it harder to guess the username, any
association with family details is more difficult. A random number in the username makes it a little harder
without being unusable. Perhaps John Q. Smith could have a username of js039.
- Have everyone use a separate account (not on your system) for personal
e-mail. There are lots of free e-mail accounts from usa.net, hotmail.com and hundreds of others. If personal
e-mail goes to such accounts, it is much harder for someone to use that information to attack your system.
Physical intrusion. It is amazing how much data can be extracted via a
laptop computer plugged into your network outlet during an unguarded lunch hour so much for the
firewall! An unescorted visitor, a cleaning person or a disgruntled employee can download an enormous amount
of data. Many companies in high-security industries do not allow visitors to bring in laptops, palm pilots or
even pagers. These may be extreme restrictions for the oil business, but employees must be made aware of what
can happen. Systems should have a locking screen-saver that turns on after so many minutes of inactivity and
requires a password to let the user back in. The inactivity period should be long enough so as not to
interfere with normal use, engaging when the user leaves his system unlocked and unattended. CDE on Solaris
2.6 has an automatic screen lock that can be set to various time delays.
Most Unix systems cannot be booted from a floppy, but they can be from a CD.
If booted from a CD and the normal boot disk is then mounted, the password file can be changed to remove the
root password. Most desktop systems come with a CD even if nobody uses it. Also, a Unix workstation can
still be booted from tape, and, of course, personal computers can be booted from a floppy.
Guests. It is common in the petroleum-exploration business to have "guests"
in to look at prospects for sale or joint ventures. It is important that guests have heavily restricted access
to the system. Remember that these guests are in your office, so they are probably inside the firewall and
other protections. Ideally, the guest would be supervised at all times, but that is not likely in these days
of minimal staff. Guest accounts should never have access to text editors, an "xterm" or similar
command window.
Direct electronic intrusion. This entails intrusion using a modem or a
network interface such as the Internet. Modems are the first things intruders look for. Every company has a
range of phone numbers. The intruder dials all these numbers (using an automatic dialer), looking for a modem
that will answer. If the machine that answers is a PC, there is a long list of ways to break into that PC,
especially if it is using something like PC Anywhere.
If a modem is needed for collecting morning reports or such, make sure that
the machine that collects these is not on your network or is only connected long enough to transfer reports
when someone is watching. Dedicating a small computer for this task is not very expensive; a "castoff"
could be used when someones desktop is replaced. Most telephone systems can designate lines as dial-out
only. If a modem is essential, put it on a dial-out-only line. Watch out for FAX lines. Sometimes, people will
unplug the FAX machine and plug their modem into the FAX line so they can use the analog line.
It might not be obvious, but for a small company say less than 200
people it might make more sense to use an ISP, get the employees personal accounts and not have
any direct Internet connections. This makes it easier to restrict how many Internet accounts are paid for.
Dial-out-only modems or, better, ISDN lines, can be used on the systems to connect to the ISP.
If there is a direct connection to the Internet, to any other office or
service provider, a firewall is needed. The other office may have an Internet connection or an unprotected
modem. This is not a matter of trust; it is a matter of due diligence and proper procedure. Any outside
network connection or modem ups the ante on security. The system needs to be tightened up firewall or
no firewall.
Indirect electronic intrusion. These are viruses, Trojan horses and
worms. You hopefully know that Unix systems are not as susceptible to viruses as personal computer systems.
This is only true if the superuser account is not compromised. A real virus affects the boot disk, but a
program in the /usr filesystem with set-uid can be just as bad. A virus, Trojan horse or similar program can
modify other programs, making the system more vulnerable to penetration later.
Make sure that employees do not execute programs or scripts that they receive
from untrustworthy sources. Many people send around executable "joke" programs. These are dangerous
and may possibly contain a virus or Trojan horse that the user never suspects, because the program seems to
work correctly (it does the joke). Users may trust the person who sent the file, but he may have innocently
passed it along without knowing of the potential problem. A Trojan horse does not need to be in the program
itself. If your program is dynamically linked (nearly all Solaris programs are), the Trojan can be in a
library.
Telecommunications security. Data sent across the network is
vulnerable to being read by packages such as "snoop" and "tcpdump." These are useful,
standard diagnostic tools, but they can be abused. If a snoop or tcpdump is sent to a support service or
vendor across the Internet, be sure it does not contain any passwords. The same applies to operating-system
diagnostic dumps.
Any transmission across the Internet can be intercepted. This applies to
e-mail as well as newsgroups, web pages, ftp, telnet and so on. There is a lot of data on the Internet, and
someone would have to be pretty interested, but it can be done.
NFS sharing is a common problem. If the sharing is not restricted, the disk is
shared to anyone who can see it on the network or even across the Internet. There have been many cases
where people at one company have NFS-mounted disks from other companies. Proper share commands and firewalls
can minimize this risk.
Risks from taken-over systems. As many people might point out, there
is a low risk that someone will have the specialized knowledge or desire to use your seismic data or
interpretations. There is a much greater risk that someone with a grudge against your company or the
oil industry in general will want to destroy your data.
These are not the big risks, however. Most intruders will not know or care
that you are a petroleum exploration shop. They want to use your computers for other purposes. Those purposes
may involve attacking others such as the recent attacks on eBay, CNN, Yahoo! and others. If your
systems are compromised and used to attack another company, you will have to take steps to restore your
computers. This can involve reinstalling the operating systems on all computers and reloading data from
scratch, because there may be compromised files on your backup tapes.
Myths And Misconceptions
Some people believe it is good to solicit a password for every service, after
so many minutes and so on. Realize that every time a password is sent across the network, it is an opportunity
for the password to be snooped. If people get used to constantly typing in their passwords, they may not stop
and think if the password is solicited by a Trojan horse. It may be more secure to use a trusted relationship
(such as a .rhosts file) rather than to expose passwords.
Root ownership as protection. Being owned by root does not give a file
any special protection beyond what applies to any other username. The only thing root ownership provides is
power. Most programs do not need that power. Very few files on the system should be owned by root.
There are some programs that need to run as root to do their jobs. Some of
these programs do a job that your specific shop may not need. Among these are "ufsrestore." Some
older Solaris 2.5.1 and 2.6 CDs have a version of ufsrestore that has a bug that will let a knowledgeable
person gain root access. If you do not use ufsrestore, you should change the ownership from root and change
permissions to not set-uid.
No applications software should ever be owned by root. You
should never need to be root to install an application. However, if an application is installed using pkgadd
(Solaris) or inst (IRIX), you have to be root. If this is the case, complain to your software vendor. You may
need to be root to put a daemon startup script into /etc/init.d and /etc/rc3.d. Thats fine; be root for
that short period only.
License managers do not need to be owned by root or run as root. License
managers are subject to a number of buffer-overflow attacks that can give an intruder root access. Other
daemons generally do not have to be root.
Firewalls. The best advice is to install a firewall and then pretend
it is not there. Firewalls protect against certain types of attacks; they totally fail against others. What a
firewall does, in very basic terms, is suppress packets that do not have the correct addresses. The
restrictions are generally on what "ports" can be accessed. The firewall cannot be overly specific
about what can or cannot go through, because you may have legitimate traffic for a given port.
It is important to realize that the firewall cannot protect what it does not
see. A firewall does nothing to protect against a modem connection to a PC, a physical intrusion, or a guest
or employee with improper access.
In addition to firewalling the Internet, consider firewalling internal-network
parts from each other. There are those who believe that it is not possible to make a network secure if it
contains any Microsoft software. This is probably not entirely true, since the PCs can be put on one
subnet and the Unix systems on another, with a firewall placed between them. If you have offices in other
buildings or cities, firewall them and have them firewall you. Compartmentalization is key.
Vendors supply secure systems. Most systems that use default
installations are horribly insecure. It is necessary to explicitly turn on security features and apply
security patches. OS vendors want to be sure that the new system can be used, however insecurely, upon
installation. What you do to secure this system is up to you and your company policies.
Security is someone elses problem; we just write applications. Security
is not just a matter of someone else maintaining the file permissions and having good passwords. Any
application or utility program that can run (even incorrectly) as root is an exposure. Any socket server
whether for licenses, databases or interprocess communication that runs as root is an exposure.
Nearly all programs are subject to buffer-overflow attacks. It helps to use "strncpy-like"
calls instead of "strcpy-like" calls, but this is difficult to enforce, especially in light of the
huge legacy-code base in exploration applications and the fact that many parts of the code come from different
groups or even different corporate heritages.
These are not usually a problem when the user is running under his own
username, but it is common for dataloading and some debugging to be done under root. Even "ls" is an
exposure when run by root if there is a chance you are not running /usr/bin/ls.
It is common for applications installation to be done as root, and most
installation scripts give little attention to security. The application vendor does not have to provide the
Trojan horse. If the Trojan exists and the installation program uses it, however unknowingly, the damage is
done. Applications should never be installed by root. Applications should be owned by an "owner
account," that is not in group "staff," and has the password set to NP and the default
shell set to /bin/nologin, if it exists, or otherwise set to else/bin/false.
Suns "pkgadd" utility requires root to run. Applications
should not be installed using pkgadd, so that they are not exposed to running under root.
|
|
|
|
Some practical solutions |
|
|
|
|
|
E-mail protections. In the file "/etc/mail/sendmail.cf"
there is a line: |
|
|
Mprog,P=/bin/sh,F=lsDFM0que9,S=10/30 |
|
|
This line allows anyone to place a script in the "Reply To:"
field of an e-mail message, which the sendmail program can then execute. To fix this, change the "/bin/sh"
to "/bin/false" or "/bin/nologin". |
|
|
Detecting a break-in. Most exploration systems administration
personnel are too busy to do a good, routine scan of systems looking for signs of a break-in. To
detect a break-in, there have to be automated tools to do this scan. This can be a problem for two
reasons:
- The automated script will not detect every break-in technique;
however, people will tend to rely on it religiously, particularly if they dont understand it.
- Detection software or logs are the first thing an intruder will
disable or subvert.
There are free and for-profit log-reduction programs that can help. It
is a good idea to have two locations for logs: one local and one on a dedicated server or NFS
filesystem where the program can add logs but not edit or delete them. |
|
|
How to detect a root-kit. The best way is to compare the
report you get from "echo *" to the report from "ls". Go through all the
directories (/usr/bin, /usr/lib, etc.) where an intruder may have left files he doesnt want you
to see with "ls". If "ls" does not show all the files that "echo *"
does, you have a problem. If a problem exists, the best thing
to do is to reinstall the OS. Remember to reinstall the security patches and to check your other
systems too. Remember that dynamic libraries in both system AND application spaces (these are files
with names like "libc.so.1") can be Trojaned. Remember that your backups for systems,
applications and data may have been compromised. |
|
|
|
|
|
The author
Will Morse is a senior systems
advisor for Anadarko Petroleum Corp. involved in exploration Unix systems. He is also an instructor at the
Geoscience Technology Training Center at North Harris College in Spring, Texas. Morse has a long history
with geoscience applications and papers. He has spoken at every Landmark Worldwide Technology Conference
since its inception (winning best paper award twice) and every GeoQuest North and South America Forum
since its beginning. He was program director for five years for the Energy Related Unix Users Group
(ERUUG) and editor of the ERUUG Unix Cookbook. Morse is also a co-founder of the sci.geo.petroleum
newsgroup. |
|
|
|
Part 2 |
|