Ten Ways To Improve The Security Of Your Systems
Mischief-makers are constantly searching and scanning the Internet for vulnerable systems. They could be snooping recreationally, conducting espionage, looking for free bandwidth, attempting to vandalize a system, or to sabotage an entire network. There are two classes of these people: the experts and the “script kiddies”. The experts have an in-depth understanding of operating systems, networks, databases, and programming. Script kiddies do not necessarily have in-depth knowledge or experience, but they do have the tools that have been written by the experts. If an expert has more expertise than the best in your enterprise, then you may be in for trouble regardless of what you do. On the other hand, some experts and most script kiddies may just be looking for an easy target. It is the responsibility of every enterprise to be a difficult target.
If you follow the ten well-known practices discussed in this paper, you will be able to prevent the majority of attacks. The purpose of this paper is simply to remind the reader of the basics. This paper will not be a highly technical discourse on how to protect systems, nor will it be introducing new and sophisticated methods of protecting networks.
1) Use Secure Passwords
One of the most important defenses against an attack is to use good passwords across all servers. This includes test servers as well as production servers. Never use names, dates, or words that can be found in a dictionary (English or foreign). These types of passwords can be easily guessed. People need to be aware that password guessing software is widely available. Processing power is dirt cheap and available to everyone. With an inexpensive computer, downloaded software, and a list of words, names, commonly used passwords, and character combinations, it’s not difficult to “harvest” passwords. John the Ripper is one of the better-known password crackers. It can “guess” millions of passwords in a single minute.
On most operating systems, passwords are stored in encrypted form. This is done by an “irreversible hash”. This means that a password in cleartext can be mathematically encrypted into a hash. The math doesn’t allow the hash to be converted back into cleartext, even when the encrypting algorithms are well known (which they are). A password-guessing program can encrypt a “guess” and compare it to an already hashed password. When they match, it has “guessed” a password.
Since technology makes it easy to “guess” passwords, it’s important to keep encrypted passwords in non-public directories. In some UNIX systems, passwords are readable by anyone with a login, i.e. /etc/passwd. UNIX has been around for years, long before computers with sufficient power to guess passwords were widely available. These days, it’s more common to store passwords in /etc/shadow which is not publicly accessible.
Since passwords are encrypted on most operating systems, even the systems administrator does not have direct access to unencrypted passwords. However, they do have access to encrypted passwords. With a password cracker, they can eventually guess your password. One might ask, in most cases if the systems administrator has access to everything on the system anyway, what does it matter? The answer: In this day and age, computers are everywhere. Most computers require some type of password. A systems administrator or I/T professional can have access to a dozen or more computers. That’s quite a few passwords to remember. It’s common (but poor) practice to use the same password across multiple systems. Unless the user uses a different password on every single system, an unscrupulous systems administrator can “harvest” passwords for systems that s/he shouldn’t have access to.
It may be impractical or unreasonable to ask people to use a different password on every system but at the very least keep the following in mind:
Test systems should have the same level of security as production systems. If encrypted passwords are protected on production systems and not on test systems, then production passwords can become compromised. Even if corporate policy states that employees should use different passwords on every system, unless the policy can be software enforced, some people likely will violate the policy. People should NEVER use their corporate passwords on servers outside of company control.
As stated before, password crackers can easily guess millions of passwords every minute. Even with this processing power, it can take a very long time to guess a password. Crackers use word lists to narrow down the choices. The best way to create an un-guessable password is to not use words that can be found in a dictionary or cracker word list (e.g. abcdef, qwerty, 123456, etc.). Be aware that crackers are smart enough to guess common word-number combinations such as password1 or secret2 etc. Therefore, wherever possible use nonsensical passwords containing both upper and lower-case letters, numbers, and punctuation characters. Password complexity rules should be software enforced where possible, such as the NT/W2K system policy editor. Rules that enforce password complexity on other systems will be dependent upon the operating system and software.
Another important password security measure is to require people to change passwords at periodic intervals. How often will depend upon a number of factors but generally the interval should be about 45 – 90 days. Also, don’t forget to delete or disable a person’s logins immediately after s/he leaves the organization.
When managing passwords, it’s important to keep close tabs on vendor and default accounts. For example, staff should take precautions to activate vendor accounts only when necessary to solve a specific problem and to de-activate the account immediately afterwards. Furthermore, do not allow vendors to use standard passwords on their accounts (i.e. insist that vendor passwords be unique to your site). Finally, change default passwords and/or disable default accounts immediately after installing new software. This should go without saying. Even so, negligent system administrators often fail to change default passwords. Hackers already know the default passwords. Default password information can easily be found with a simple Google search or getting a list of defaults from a site such as: http://www.phenoelit.de/dpl/dpl.html
In the first half of 2003 the Voyager Alpha Force Worm attacked SQL Server databases with the SA (DBA) password set to null (which is the default). The worm wreaked havoc on the Internet and servers all over the world. SQL Server is not generally a consumer product. In the majority of cases, it’s an I/T professional that installs and configures SQL Server. Of all people, sys admins. should know better than to leave the SA account set to null! Granted, in some cases a run-time version of SQL Server may be imbedded in an independent application. Still, with good change-control policies and procedures, systems administrators will have tools to help them identify the susceptible software. The lesson to be learned is that we should follow standard security practices and change control on all systems, regardless of their importance.
Note that Oracle may not have the same vulnerabilities as SQL Server, and the default Oracle DBA passwords aren’t null, but they are widely known. The SYS, SYSTEM, OUTLN, PERFSTAT, and DBSNMP accounts should all be changed.
Manage and Document System Changes/Keep a Software Inventory
Systems do not necessarily become unstable because of nefarious activity. Sometimes it’s because of configuration changes, buggy patches, or applications. And sometimes systems do become unstable because of nefarious activity. When things go wrong, one of the first questions asked is “what changed?”
Systems are continually changing and evolving. People come and go and people forget what they did last year (or last month, last week, yesterday, or even ten minutes ago), and people deny that they “messed up”. For these reasons, it is necessary to have a change management system. A change management system should be like a newspaper story. It should tell who (made the change), what (was changed), where (the software resides), when (the change was made), and why (the change was made). When problems occur, this information should answer the question (what changed?). Since hackers aren’t likely to follow change management procedures, a change management system will provide a “leg up” in determining if problems were caused by approved or illicit activity.
Change management and software inventory systems also can help systems administrators manage patches. When patches are announced, a software inventory and change management system will help systems people identify the software and systems that require attention.
There are numerous other benefits of having a change management system. A good change management system will help to ensure that the appropriate parties are notified when changes are made. It can answer many of the questions that would otherwise require the presence and good memory of the person who made the change. It can help prevent duplication of effort and help prevent people from working against one another.
2) Pay Attention!
Remember Blaster? On July 16, 2003, Microsoft announced a patch to correct a newly discovered security vulnerability. The patch went unnoticed by systems administrators. It didn’t go unnoticed by hackers. By mid-August, systems everywhere were being infected by the Blaster worm. People are now starting to pay attention to security patches. But for how long?
People responsible for maintaining security need to be continually aware of the latest threats. Threats occur in all types of environments – not just Windows. Attacks against the Windows environment may be the most prevalent, but Windows systems are by no means the only target for hackers. Open source, proprietary UNIX variants, and other operating systems are all susceptible. It is therefore important to keep abreast of all the newly discovered security flaws in the organization’s operating environment. This can involve regularly checking with the vendor’s web sites and/or the security trade press. There are organizations that provide free email newsletters describing newly discovered threats. Below are two of the organizations that provide this type of service. Just visit the sites and sign up:
http://www.sans.org/newsletters/
http://www.securitypipeline.com/newsletter.html
Both provide details about some of the latest threats. However since the notification is not instantaneous, the warning may not be timely enough. Nevertheless, email newsletters may provide warnings of security threats that would have otherwise have gone unnoticed.
Security breaches can occur even when an organization’s staff is extremely skilled and diligent in protecting corporate security. It’s important that when breaches (or attempted breaches) do occur, that they be quickly detected. It should become a habit to review logs at least once a day. Reviewing logs is not only a good security practice; it’s a good practice in general. It’s a proactive way of keeping ahead of a variety of hardware, software, and disk problems. If logs are reviewed frequently, and if the organization is lucky, it’s possible that attempted security breaches can be identified before they cause damage. When this is the case, action can be taken to ward off the breach. If a successful breach is identified, then action can be taken to mitigate the damage and strengthen security against future breaches.
Attackers will often attempt to delete or alter logs to hide their tracks. Therefore, persons responsible for maintaining security should take action to protect the logs themselves. Furthermore, computer hacking is a crime, especially where there is economic damage. It is therefore very important to protect the integrity of the logs so that they can be used as evidence in court proceedings and/or any internal or law enforcement forensic analysis of the breach. Protecting logs could involve ensuring that the logs are in secure directories, and where practical, placing logs in locations other than the default directories. Better yet, put logs on a different server entirely. Finally, to ensure that log timestamps are accurate and synchronized throughout the network, enable Network Time Protocol (NTP) on every computer connected to the network.
Procedures for viewing, maintaining, and protecting logs will depend upon the environment. The following are examples of logs that should be monitored.
IIS (Microsoft)
Apache (Open source)
/var/log or /var/adm (LINUX/UNIX)
Database alert logs (Oracle)
Keep Patches up-to-Date
In the real world, it may be unreasonable to expect systems administrators to apply patches as soon as they are released. On the other hand, any unapplied patch could mean a potential open door for hackers. It is therefore reasonable to expect administrators to review newly announced patches, and where applicable, quickly develop a plan for testing and installing them.
Before installing patches ensure that
the patch release notes have been reviewed.
the applicable testing is complete (Be aware that a patch may cause more problems than a possible hack).
there is a good, current backup.
the changes are logged and change control procedures are followed.
that all the required resources are available.
It is important that systems administrators perform a careful analysis of each patch that becomes available. Although it isn’t necessary to apply every patch, systems administrators should keep in mind that operating environments are in a constant state of flux and that patches that don’t apply today may apply tomorrow.
Microsoft Update and Microsoft Baseline Security Analyzer (MBSA) are tools that will help Windows administrators review patch levels and apply patches. In addition to patch management, MBSA can help sys admins. by making other recommendations regarding the security of Windows servers.
Systems can often be configured to automatically apply patches. It is up to the organization’s security and change management policies to determine if automatic updates should be enabled. Automatic updates will help to ensure timely patch installation, but may bypass standard change control, notification, and testing procedures.
Patch management tools will vary depending upon the operating environment. Regardless of the tools or the environment, it is essential that security patches be kept up-to-date. It only takes one hacker who is more up-to-date than you are to ruin your day. In addition to keeping patches up-to-date, don’t forget to keep virus definitions up-to-date.
3) Turn off What You Don’t Need
______ recently discovered a security flaw in the________ service which will allow an attacker to take complete control the affected computer. Sound familiar? Different words can go in the blanks, but otherwise it’s the same story over and over again. Hackers are constantly testing code and finding bugs that can leave systems vulnerable. They write code to exploit bugs that others have discovered. What happens when a flaw is announced before the patch becomes available? Before you find out about it? Hackers continually scan open ports looking for avenues of attack. If your systems are vulnerable, they will find them.
Do you need FTP, Telnet, Net Meeting, IIS, Finger, etc.? What about the Windows Messenger Service? One of the most effective countermeasures is to simply turn off the unneeded services and processes. When a new security flaw is discovered in a deactivated service, the workaround may already be in place and the urgency of applying a corrective patch is diminished. For example, Windows Messenger is a great tool for spamming people with irritating pop-up windows, but is it really needed? There are well-known security flaws in Windows Messenger. A single Windows Messenger attack could cripple a network of un-patched systems. This type of attack could spread very rapidly, but only if the service is turned on. Be proactive and turn off unneeded services before flaws are discovered.
The methods for closing ports will depend upon the operating system. In Windows, many ports can be closed by stopping and disabling the services from control panel/administrative tools/services. On Microsoft IIS, consider the IISLockdown and URLScan tools (both downloadable). These tools will restrict access to virtual directories and HTTP commands. On Unix/Linux, remove what isn’t needed from /etc/services, /etc/init.d, and/or /etc/inittab.
To check out how easy it is to find vulnerabilities, go to https://www.grc.com and click on the ShieldsUP link. This is a benevolent site. The site will scan the ports of the requesting system and report which ports are open. Bear in mind that every one of those open ports is a potential avenue of attack. Also bear in mind that the not-so benevolent hackers can see exactly the same thing. Deactivating unneeded services and processes may also provide the additional benefit of reduced memory and CPU consumption.
Internal and external firewalls are another way to “block” ports. External firewalls can help prevent attacks from the outside, but won’t do much to protect a server from internal attacks. Remember that not all attacks are deliberate. Viruses and worms often cause attacks. An employee could unknowingly connect an infected laptop to a network, bypassing the external firewall, and then infect internal systems. Firewall software running on servers and workstations can help to provide an additional level of protection against intentional or unintentional attacks from the inside.
4) Use Wireless Encryption
Organizations are discovering that wireless is a very inexpensive way of providing access to portable devices such as laptop computers and PDAs. Wireless is inherently insecure. With enough time, and with minimal skills, a person could gain access to a wireless network. The trick is to make them spend enough time to be discovered or dissuaded from attempting to gain access.
It is extremely simple to add wireless capabilities to a network. Wireless access points and routers require almost no set-up or configuration. By default, wireless access points are usually configured with no security at all. Hackers and bandwidth thieves are well aware of these facts. An un-configured access point is begging for trouble. It’s like an engraved invitation for snoops, bandwidth thieves, and criminals. As a matter of fact, the owner of the access point could be held criminally responsible if it is used for illegal activity.
There are free, downloadable tools that almost anyone can use to find wireless networks. Two of the better known tools are:
Netstumbler: www.netstumbler.com (Windows):
Kismet: www.kismetwireless.net (Linux)
Note: there are also versions of Kismet for the Sharp Zaurus (a Linux PDA).
Hackers use these types tools on portable wireless devices to search for unsecured wireless networks. These people are called “War Drivers”. War Driver is really just a term for a “mobile hacker” looking for un-secure wireless networks. When war drivers find a wireless network they will often “war chalk” (mark) their “conquests” for the entire world to see. This is like putting up a big sign that says: “Hackers welcome!”
A non-technical staff member who doesn’t know better can create a HUGE security hole by connecting an unauthorized access point to a network. Wireless access points are so inexpensive that users may even pay for them with their own money. The technical staff should use the available tools to verify that there aren’t any unauthorized access points on the network, and that the authorized access points are properly configured.
Windows XP can automatically connect to wireless networks when it encounters an SSID broadcast. A Windows XP user doesn’t even need to make a deliberate effort to find and connect to an un-secure wireless network! If it matters who can access the network (it does matter, doesn’t it?), then it is necessary to configure all the wireless access points on the network. Every single one. It is also important to note that most wireless networks are behind firewalls so if a wireless network is penetrated, the corporate firewall will offer no protection at all.
The three mostly widely used wireless protocols are 802.11a, 802.11b, and 802.11g. 802.11a and 802.11b even when correctly configured, offer only minimal security and are not recommended for commercial applications. If 802.11b is to be used, it should be configured with security in mind even though that security isn’t very good. The first step is to change the default service set identifiers (SSID). Next configure the access point to not broadcast its SSID. Broadcasting the SSID is essentially an invitation to connect to it. Turning off broadcast won’t increase the security much, but it will a little. 802.11b does offer encryption known as Wired Equitant Privacy (WEP). WEP is 64 bit encryption scheme of which only 40 bits are configurable. It is very well known that WEP is not a very secure encryption. It can be cracked without a great deal of difficulty. Furthermore, WEP only encrypts data packets. It does not encrypt packets containing MAC addresses, source and destination address and SSID. Most 802.11b devices also offer 128 bit encryption (of which 104 bits are configurable). 104 bit encryption is better than 40 bit encryption, use it.
The 802.11g standard is beginning to gain market acceptance. It offers higher bandwidth than 802.11b and offers Wi-Fi Protected Access (WPA) encryption. WPA was intended to be an improvement over WEP, but the jury is still out about whether or not it really is. Robert Moskowitz wrote a paper “Weakness in Passphrase Choice in WPA Interface” that asserts that in some cases the newer WPA may be less secure than WEP.
5) Protect the Physical Space
Servers need to be in secure areas with controlled access. This means that the computer room needs to be locked at all times. Passwords, firewalls, change controls, and patches will not protect a server in an unlocked computer room. With physical access, an unethical competitor or disgruntled employee can wreak havoc in considerably less time that it takes to crack a password. This may be obvious, but it’s easier to tape a sticking lock than it is to fix it (it’s only temporary!). If it’s not part of the corporate culture, an employee may be uncomfortable challenging unfamiliar people in secure areas. This would be unfortunate if the stranger entered a secure area to do harm.
Some people who wouldn’t think of permitting unprotected root access on the Internet will leave terminals logged-on and available to any stranger who happens to be in the building. In an open office environment, it may not be practical to physically secure all workstations. However, it’s important to take whatever precautions can be implemented. These precautions could be bios locks, screen savers and the like. Windows 95, 98, and ME are totally un-secure and should be upgraded where possible.
Rather than have the attitude “It’s not my responsibility, it’s no skin off my nose if something bad happens”, think this way: “This is my livelihood, if something bad happens to my employer, I could end up unemployed”.
6) Keep Good Backups
Backups are the last line of defense against malicious attacks, unanticipated failures, or “acts of God”. In spite of our best efforts in providing “soft” and “hard” security, systems can still be compromised.
The necessity for a good backup is obvious. Backups are easy. Restores are hard. The importance of testing and practicing restores is also obvious. Unfortunately, testing of restores is often impractical. The worst possible time to find out that a backup isn’t good is when something bad happens. Notwithstanding the difficulty, it is essential that restores be tested. Regularly. The backup rotation schedule needs to be carefully planned. A restorable backup is useless if the oldest backup occurred after the corruption or lost data.
It is also important to consider what it will take to restore a system to a functional state. With a good backup, it might not be a major issue if only a few data files were lost. But reloading and reconfiguring an entire operating system could take substantial amount of time and effort.
Things to consider:
Is the operating system backed up or just the data?
Can we get the software and system configuration to a point before the failure?
What about the add-on software?
Do we have all the license keys we need?
Will we need to re-activate the software?
Unless we’re going to restore everything, we need to know the extent of the damage or corruption.
By the way, how good is your system documentation?
7) Implement A Formal Security Policy
The steps outlined in this paper are only the most basic security precautions. Even basic security can be cumbersome and time consuming. Without a policy, the professionalism of the staff is the only thing that will determine whether or not good security practices are followed. By implementing a written security policy, the responsibility for system security becomes the responsibility of management. The policy should state that everyone must be vigilant in protecting security, but ultimately the security of the enterprise is management’s responsibility. It should state that management will be held accountable for security lapses.
A well-written policy will be a guideline of common-sense security rules. It will enable staff to say “No, I’m not allowed to do that”. At the very least, a good security policy will get people to think before they give out information or do things that they shouldn’t be doing.
Providing a comprehensive list of all items that should be covered is beyond the scope of this paper. Furthermore, each organization needs to tailor the policy to its own needs. There are a number of resources available that will cover security policies in greater detail. Kevin Mitnick’s book The Art of Deception devotes an entire chapter to a sample security policy. Also check out: http://www.sans.org/resources/policies/ which provides samples and suggested policies covering a variety of security related topics.
8) Train Everyone
An organization’s security is only as good as its weakest link. Depending on the organization, access to critical information can be available from the most junior clerk through the highest levels of management. A lapse by a single individual, from the most to least technical, from the most junior to most senior employee, can put the entire organization in jeopardy.
All employees should be trained on the corporate security policy. Keep in mind that in order to train anyone on the corporate policy, it’s necessary to have a corporate security policy. The levels and amount of training each person receives should be dependent upon their role within the organization. At the very least, a two-tiered training program should be implemented.
9) Training for Individual Employees
Even when the systems and database administrators exercise due diligence and take every security precaution, systems can still be compromised by authorized personnel. An uneducated user may be completely unaware of security practices that should be common sense to an experienced I/T professional. People not trained in basic security practices can compromise security without even realizing that they have done so.
In addition to advanced technical skills, a skilled hacker will have “social engineering” skills. Skilled social engineers can convince others to do their legwork by making seemingly innocuous requests. Since new employees are not familiar with the organization’s systems, personnel, or policy, social engineers will often target them when they attempt to glean sensitive information or attack systems:
“Personnel, this is Sam from the Acme Business Card Company. I’d like to provide a free sample box of business cards to any new employee. Just give me a name, and I’ll call them and make the arrangements…. Joe in accounting at extension 1234. Got it, thanks!”
“Company information, this is Joe, I’m a new employee. Who do I talk with to find out how to logon to the email server? Oh, it’s Bob at the help desk, thanks!”
“Joe, this is Bob, from the I/T help desk. I need your password so that I can remove a very destructive virus from your system. I’d hate to see your computer messed up the first week you’re here. It’s ‘password1’. Thanks, and good idea adding the number, it makes your password harder to guess. By the way can you go to www.nastyspyware.com and download computerspy.exe? Thanks!”
This type of activity occurs all the time. To an experienced professional, this example may be an exaggeration of a social engineering attack, but it might not be for an untrained user.
A training program for all employees and contractors will make them aware of the importance of security and teach them how to avoid being the victims of social engineers. Ideally, all employees and contractors (especially new employees) should be trained before being granted access to secure areas or sensitive information.
Training doesn’t necessarily need to be in a classroom environment. Depending upon the complexity of the organization and its systems, a simple briefing by a supervisor may be adequate. After the training, it’s a good idea to provide an individual copy of the security policy for each employee or contractor to keep.
For more information on social engineering, read The Art of Deception by Kevin Mitinck. The book contains many eye-opening accounts of social engineering attacks.
10) Training for Technical Personnel
In addition to policies for non-technical personnel (“users”), there will likely be policies that apply only to technical personnel. Technical personnel should be briefed on all the policies that may apply to them. Additionally, system administrators, network administrators, database administrators and systems security personnel should be trained in the latest threats and countermeasures. Training should also include “best practices” for the applicable scope of responsibility. The Training should be as in-depth as possible, with refresher courses.
Conclusion
Security is inconvenient. Security takes effort. Trained people violate standard security practices even when they know better. Untrained users violate security practices without knowing better. Inadequate security occurs because people fail to follow the basic practices. We see something we know isn’t right and think “gee someone should do something about that!”. We rush to install new systems with the full intention of implementing proper security. Then security gets “postponed” as deadlines approach. Later, as we move on to new projects, security becomes a “future” project (when we have time). Eventually security becomes forgotten entirely. These lapses create security holes. A hacker only needs to find one of these holes to be able to cause extensive damage or to steal sensitive information. Hackers don’t just destroy systems. Hackers can also cause considerable embarrassment, bring ruin to corporations, or wreck people’s reputations and careers.
Security is everyone’s responsibility, but ultimately the buck stops with management. Management needs to ensure that security is part of the corporate culture by implementing a written security policy and insisting that everyone be trained in the basic security precautions. When security really becomes part of the corporate culture, everything else should fall into place.
References
Mitnick: The Art of Deception ISBN 0-7645-4280-X
McNamara: Computer Espionage ISBN 0-7645-3710-5
Mandia: Incident Response & Computer Forensics ISBN 0-07-2222696-X
Russell, et al. Stealing the Network How to Own the Box ISBN 1-931836-87-6
http://www.warchalking.org
http://www.pcworld.com/news/article/0,aid,113340,00.asp
http://www.sans.org/newsletters/
http://www.securitypipeline.com/newsletter.jhtml
http://www.sans.org/resources/policies/
