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 geoscientist’s desk? In a data-manager’s 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, "I’m 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:

• Don’t 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 people’s 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 someone’s 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 employee’s 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. That’s 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 else’s 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.

Sun’s "pkgadd" utility requires root to run. Applications should not be installed using pkgadd, so that they are not exposed to running under root.

The author

	Part 2