Return to: U of M Home |
|
myU | One Stop | Directories | Search U of M |
|
|
|
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|
STANDARDS & GUIDELINES GUIDELINE—Server Security Guideline (Appendix J)Responsible Office: Office of Information Technology GUIDELINE ContentsServer Security Guideline-Overview
Installation Notes- By Operating System Appendix A: Additional Steps for Protecting 'Not Public' Data Appendix B: List of Services to disable- By Operating System Appendix C: More detail on Unix-Like operating systems Appendix D: More detail on Windows operating systems Appendix E: Installation Configuration Process IntroductionPurpose This document is intended to provide a set of guidelines for the installation of computers that are part of the University of Minnesota network so that they meet at least a minimally acceptable level of security. Due to the volatile nature of what is considered to make a computer "secure", please consider all of these guidelines as highly recommended unless otherwise noted. Since computer security is a rapidly changing field with constantly changing vulnerabilities and fixes to those vulnerabilities, making a computer absolutely secure is just not possible. Securing a computer amounts to determining the worth of each computer and the data that passes through it and then deciding how far one has to go to protect that computer and data. Installing every single computer security tool on every single computer is usually not a good investment. It would be serious overkill for the majority of computers that are probably best protected with a few well-chosen security tools and a vigilant maintainer. These guidelines take this rapid evolution into account and present a philosophy of installing computers rather than a cookbook for how to install computers. There is a large continuum of computer security ranging from computers that don’t contain private data and need minimal security to highly secure computers that need extraordinary measures. While, neither of these extremes is generally true within the University's environment, it is really up to the individual computer's owner to choose the appropriate level of security for each computer, and then to implement appropriate security measures to maintain that level of security. Other factors such as state and federal laws or industry standards may help determine the level of security needed. Some examples are the Minnesota Data Practices Act, FERPA, GLB, HIPAA and Payment Card Industry (credit card) standards that address certain “not public” data such as social security numbers, student records, patient data and credit card numbers. Definitions Before continuing it is best to address the sometimes confusing definitions of the words “service”, “server” and “client”. To avoid any confusion about their usage here, the definitions for this document are as follows:
A good working definition of a server within the University might be a computer that more than one individual or “concurrent” user uses as a “common share point” for databases, data files, word processing files, or images. Other functionality that may be provided includes calendaring, document management, mail distribution/handling, or web-based services. Maintenance One good issue to keep in mind while reading this document is that to simply install a good mix of computer security tools onto a computer is never enough. All security tools require at least occasional care and maintenance. This can be anything ranging from the installation of new patches to the operating system to modifying the availability of services due to the changing role of a computer or an organization. With the quickly changing nature of things in the computer world, it is important to keep up with the time and to know before hand that any computer security model must adapt with these changes. Server Security Guideline- OverviewFor any operating system, it is important to follow the general guidelines below. The actual details used to implement these guidelines may vary slightly (see the checklist in the next section), but the ideas are the same regardless of the operating system. If followed, these will go a long way toward securing a computer. In addition to the guidelines the following standards are required to be followed for all computers:
Here are some general recommendations for all operating systems. Do these roughly in the order listed. ( ) Review the purpose or role of the computer
( ) Set up authentication & account management before connecting to the network
( ) Install and patch the operating system before connecting to the network
( ) Run minimum number of services
( ) Install filters or firewall
( ) Install security related software
( ) Maintain physical security
( ) Maintain backups and operational continuity
( ) Identify the computer for security event notification
( ) Run a network-based vulnerability scan
Additional steps to enhance security:
For general information on the installation process and some tools to help audit, see Appendix E. For computers with “not public” or private information In addition to the above, here are some questions to ask yourself:
See Appendix A for additional information and requirements for Securing “Private” and “Not Public” Data. Server Security Guideline( ) Review the purpose or role of the computer
( ) Set up authentication & account management before connecting to the network
( ) Install and patch the operating system before connecting to the network
( ) Run minimum number of services
For a basic client computer, the only services that should be enabled if needed via inetd are the remote access services, if needed: shell, login and telnet. SSH should be installed and working, then inetd can be turned off all together since it provides far superior remote access than any of the inetd spawned services. There are a few cases where inetd can not be disabled even though SSH is working properly. These include systems that use CDE as the login environment that must also run the CDE daemons and a few other minor cases.
( ) Install filters or firewall
( ) Set up and review logs
( ) Install security related software
( ) Maintain physical security
( ) Maintain backups and operational continuity
( ) Identify the computer for security event notification
( ) Run a network-based vulnerability scan
Resources:
http://www.opensolaris.org/os/community/security/files/s10-cis-appendix-v1.1.pdf Mac OS X is the latest operating system from Apple Computer, Inc. Since Mac OS X is based on BSD Unix, it has some of the same security concerns of a traditional Unix system. By default, the Mac OS X has very few services enabled, which reduces the number of ways an attacker could possibly gain unauthorized access. Nevertheless, it is still more important than ever to keep Mac OS X up to date. Refer to the Unix security section for more information on securing the operating system. For steps to secure Mac OS X desktops, see http://www.umn.edu/oit/security/MacOSXDesktop.html. ( ) Review the purpose or role of the computer
( ) Set up authentication & account management before connecting to the network
( ) Install and patch the operating system before connecting to the network
http://www.apple.com/support/security/security_updates.html
( ) Run minimum number of services
( ) Install filters or firewall
( ) Set up and review logs
( ) Install security related software
( ) Maintain backups and operational continuity
( ) Identify the computer for security event notification
( ) Run a network-based vulnerability scan
Resources:
Any Windows 2000/2003 server needs a designated server administrator. That person needs to decide if the computer should be set up as a stand-alone or part of the tree. For steps to secure Windows 2000/XP desktops, see http://www.umn.edu/oit/security/windows2000xpinstall.html. For steps to secure Windows Vista, see http://www.umn.edu/oit/security/windowsVistaDesktop.html ( ) Review the purpose or role of the computer
( ) Set up authentication & account management before connecting to the network
( ) Install and patch the operating system before connecting to the network
http://www.umn.edu/oit/security/domain.html
http://www.microsoft.com/technet/security/tools/locktool.mspx
http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/iis/tips/iis5chk.mspx ( ) Run minimum number of services
( ) Install filters or firewall
( ) Set up and review logs
( ) Install security related software
( ) Maintain physical security
( ) Maintain backups and operational continuity
( ) Identify the computer for security event notification
( ) Run a network-based vulnerability scan
Resources:
http://www.microsoft.com/technet/security/prodtech/Windows2000.mspx
http://www.microsoft.com/technet/security/prodtech/windowsserver2003/w2003hg/sgch00.mspx
https://www.umn.edu/oit/security/Protected/Windows2000-SbyS.pdf (PDF)
http://www.cisecurity.org/
( ) Review the purpose or role of the computer
( ) Set up authentication & account management before connecting to the network
( ) Install and patch the operating system before connecting to the network
( ) Run minimum number of services
For example, even if you need to have the Apache Web server loaded, you most likely do not need Tomcat or exteNd Application Server running. ( ) Install filters or firewall
( ) Set up and review logs
( ) Install security related software
( ) Maintain physical security
( ) Maintain backups and operational continuity
( ) Identify the computer for security event notification
( ) Run a network-based vulnerability scan
Resources:
Post installation cleanup:
Resources:
http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=bpj05999
U of M ResourcesHere's a list of links to University of Minnesota resources.
University of Minnesota Policies Acceptable Use of Information Technology Resources
Developing a Plan for Operational Continuity http://policy.umn.edu/Policies/Operations/Safety/OPERATIONSPLAN.html Appendix A: Additional Steps for Securing “Private” and “Not Public”DataIn addition to the general guideline, it is recommended that departments or collegiate units with private or “not public” data develop a security plan. The plan should be reviewed and approved by an appropriate person such as the Dean, Director or Department Head. For more information, see the Securing Private Data Standard at http://www.umn.edu/oit/security/privatedata.html The following baseline requirements substantially improve security: ( ) Local data owner: Computers and other devices must have an identified local data owner (such as the principal user of the data or the unit supervisor) who is responsible for the data and can act as a point of contact. ( ) Technical support required: Computers and other devices must be either continuously managed or reviewed on an ongoing basis for appropriate security measures by a full-time information technology professional, such as competent local information technology support staff. ( ) Staffing level: Units are responsible to have appropriately supervised professional technical support staffing sufficient to maintain information security. The staffing level should be appropriate to the environment, i.e. the amount and type of private information for which they are responsible and the level of risk. See the Information Technology Support Staffing Standard and the related Information Technology Support Guideline for additional information. ( ) Configuration: Computers and other devices must be set up in accordance with applicable University security guidelines and standards. As received from the vendor, computers and other devices are not configured for security and require initial as well as ongoing review of the configuration and security of the operating system and software. ( ) Maintenance and patching: Security vulnerabilities are regularly found and publicized for software. Regular patching, installation of newer versions, and other maintenance must be performed to protect private data (see the Security Patch Standard). Automatic settings or centralized updating of security patches is recommended for most desktop computers. ( ) Authentication: Access to private data must be authenticated (e.g. by using a strong and complex password) with file access privileges differentiated by user. Administrator or root level passwords should be exceptionally strong, since these accounts allow complete control of the system. User accounts with fewer privileges should be used instead of root accounts whenever possible. Periodic review of access (through the authorization processes) for databases and tables that are multi-user and outside of those "centrally-administered" is required. ( ) Encryption: If sent across the Internet (external to the University's network) or other open networks such as wireless connections, both the authentication data (e.g. a userid and password) and the data itself must be encrypted with strong encryption. Encryption of private data stored on laptop computers or other portable devices is required. An offsite plain-text backup version in a secure location is recommended to protect against lost encryption keys. See encrypting stored data. The University's wired network is not considered an open network. ( ) Anti-virus technology: Desktops and laptop computers must have anti-virus software or filters installed and updated daily (automatic updates recommended). In addition, other Windows computers, including servers, must have anti-virus software installed and updated daily. (See the Anti-Virus Standard). ( ) Firewall or filtering: A software firewall, hardware firewall, or other network filtering (e.g. port or IP address filtering) technology must be used to limit network access to the device storing private data. ( ) Access: Physical access to computers must be restricted as much as possible. Devices not in use for extended periods (e.g. at night and on weekends) must be turned off. Laptops must be physically restrained (e.g. via an anchoring device) at work stations and servers must be appropriate and secure physical facility. See Physical Security for Critical Servers Guideline. Password protected screen saver programs should be used in open locations. ( ) Security event logging: Host security log files must be configured and reviewed for anomalies. Logs must be of sufficient size to provide useful information in case of a security event (at least 90 days of logs). See Information System Activity Review procedure in the Securing Private Data Standard. ( ) Reporting Critical Servers: Servers storing private data must register with OIT Security & Assurance as "critical servers" and be scanned regularly with vulnerability testing software with corrective actions taken as appropriatee. Registration of the server can be accomplished by completing the online form, see Critical Server Identification for more information. ( ) Vulnerability scans: Servers storing private data must be scanned regularly with OIT Security vulnerability scanner with corrective actions taken as appropriate. See http://www.umn.edu/oit/security/scanprocess.html for information on the scan process. ( ) Backups: Periodic backup copies of software and data must be made, tested, and stored securely (not in staff cars, homes, etc). The physical security of the removable media must be maintained and plans made to allow recovery from unexpected problems. ( ) Disposal of data and equipment: A “secure deletion” program must be used to erase data from hard disks and media prior to transfer or disposal of hardware. (See secure deletion). Permanent media (e.g. CD's, etc.) must be physically destroyed. ( ) Limit services: Services available on computers or other devices must be as limited as possible. Web server, ftp server, mail server, peer to peer, and anonymous file sharing software can significantly raise the security risk to private data. Unless a high level of expertise is available and these services are closely monitored at all times, this higher risk software should not be installed. ( ) Training: Training provided by the University on data security practices must be completed by both new and existing employees. In certain units (e.g. units subject to the HIPAA and other regulations) University community members in addition to employees are also required to complete training. Some additional tools:
Note: Per the Internal Access to University Information policy, the term “not public” includes all information, which is not public (e.g., private, non-public and confidential). Appendix B: List of Services to Disable- By Operating SystemList of Services to Disable- By Operating System In general, these services should be disabled on computers on the U of M network.
These services should be reviewed and disabled if unused or unneeded. This list is illustrative and not exhaustive of all the services that should be disabled.
For more information about the service, see http://www.networkice.com/advice/exploits/ports/default.htm Appendix C: More detail on Unix-Like operating systemsPatches Solaris
IRIX
AIX NOTE: patches for AIX are available by ftp, but a much easier way to obtain them is via a program called FixDist available at the given URL. Refer to it's documentation for instructions on obtaining patches with FixDist.
LINUX RedHat/Slackware/Debian/SUSE Linux/Cadera OpenLinux
NetBSD/OpenBSD/FreeBSD
SSH
System logs
Packet Filters IPFilter http://coombs.anu.edu.au/~avalon/ Open BSD Packet Filter http://www.openbsd.org/faq/pf/index.html TCP Wrappers TCP wrappers is an IP packet filtering utility that controls which hosts are allowed access to services in /etc/inetd.conf.
shell stream tcp nowait root /usr/sbin/rlogind rlogind
# Turning off unnecessary services
Appendix D: More detail on Windows 2000 operating systemsRegistry Keys
HKEYLM\System\CurrentControlSet\Control\SecurePipeServers\winreg
And make sure that there are no permissions for Everyone on this registry key.
Creator/Owner: Full Also change the following permissions: Everyone: Read
Administrators: Full The only exceptions to these general permissions are detailed in the following sections.
C:\winnt\system32\repl\import
C:\winnt\fonts Also, some applications require that non administrator users have write or change permissions on some files in C:\winnt and C:\winnt\system32. Modify the permissions on these files individually as needed rather than changing the permissions on the directories themselves.
C:\Temp
C:\winnt\repair
*.exe Tools
http://www.microsoft.com/technet/security/tools/mbsahome.mspx
http://www.microsoft.com/windows2000/downloads/servicepacks/sp3/default.asp Appendix E: Installation Configuration ProcessThis section provides more general information on the configuration process. Acceptable Use - Security Policies The security of any computer or organization really begins with a review of the Acceptable Use Policy (AUP) for the computers in the organization. If there is no need for a more restrictive departmental policy, the default policy is the general U of M policy. The departmental policy is intended to define the right and responsibilities of both the users and system maintainers as well as define who these people are. This is really the first step in the security of any computer as it sets out the rules that everyone is to follow. And when the rules are broken, the AUP also defines what happens to those who’ve broken them. For any department that is developing an AUP within the University, there is really only one rule that must be followed: all departmental AUPs must start with the University’s AUP and add further restrictions. That is, the University’s AUP supercedes all other AUPs within the University. So, for example, a department is not allowed to state in their AUP that the sharing of accounts is allowed since the University’s AUP forbids this. For the University’s Acceptable Use Policy, refer to this web page: http://policy.umn.edu/Policies/it/Use/ITRESOURCES.html For a very good starting point in the creation of an AUP, refer to the Site Security Policy Development paper written by AUCert: http://www.auscert.org.au/render.html?it=2256&cid=1920 Know the worth of the information and services on a computer After the policies, the next thing for anyone implementing a computer security policy is to address the issue of the importance of the computers and the information that they contain. While it might be tempting to say "These computers are not important at all, so why bother securing them?" consider that even the most basic of computers is still powerful enough to be used by unscrupulous individuals to cause havoc on the local or even vastly remote networks. All computers are important no matter how insignificant they may seem to be. But of course some are simply those that are more important than others. To determine the value of a computer, simply look at the type of information that will be flowing through that computer. On the minimal end of the spectrum, consider a computer that is shared by a small group of people in a graduate student office. As long as these students are not working with sensitive or “not public” data, then this is a situation in which minimal security coverage can be appropriate. The only things of real worth on the computer are the operating system itself and all accompanying programs, the system logs, the accounts of the people who use that computer and the general availability of the computer for the people who use it. However, data's value is not always readily apparent. Please be aware that it is the last item listed above, user accounts, which are one of the most valuable assets on any computer. It is user accounts that are frequently targeted by hostile people since they provide a measure of anonymity on the Internet from which attacks can be launched on even more computers. That is, by stealing someone else's identity, computer criminals are able to cover some of their tracks and make it appear that an innocent party is actually the one launching attacks. On the other extreme, is the database server that stores student or patient records and other important information such as social security numbers, addresses, medical records, etc. This is highly sensitive or “not public” data and, under pain of legal action, it must remain so. This is a computer that calls for great care and the strongest computer security tools. It is these sorts of issues that directly determine the value of a computer and thus how far one must go to protect it and the information that it contains. A computer that contains highly sensitive or “not public” information must be highly protected and should be addressed by an approved security plan. The operating system Another critical step before connecting to the University of Minnesota network in securing any computer is for those that install and maintain that computer to be intimately familiar with how that computer's operating system and software function. This doesn't mean that one should know every nuance and feature of every piece of software. It means that one should have a healthy knowledge of the primary features and of its basic behavior in common situations. Without this sort of knowledge, it can be very difficult to determine even if a computer is functioning correctly, let alone if it's being exploited by unauthorized users. If in doubt, ask for help or ask for a scan to check out your configuration. Choosing which services to run Now that the most basic issues of securing a computer have been addressed, it is time to turn to the more practical things that can be done. The most basic of these is to choose what services each computer will offer. Or, seen from another perspective, the role of each computer in an organization needs to be defined. For most computers that fall into the role of a "client" in an organization, it is best to highly limit the services that they offer to only those that are absolutely needed. In some cases, the minimal number of services that are absolutely needed is one: remote access for system administration if administration for clients is centralized. For computers that fill the role of "clients" there is usually no need to provide any other services at all. After all, these computers are almost always acting as clients. The only common exceptions to this one service on client computers rule are where a client computer needs to be specialized for the people who commonly use it. And the most common service that is needed is remote access to the local disk. A few other, less common services include software licensing, calendar access, font services and remote display access. These sorts of exceptions do occur for budgetary or other reasons. But the idea here is to start with the absolute minimum number of services and build up instead of starting with every imaginable service and building down. For computers that fit the role of "server," the situation is similar, but a little more complicated. Having just the minimal, remote access service on a server makes very little sense in most cases. Typically, a computer fits the role of server because it needs to provide one or more services to the entire organization. Common examples include: email servers, file servers, authentication server, compute servers, web servers, and many more. Frequently, several of these services are combined onto a single computer. The idea to follow when configuring server computers is the same as that for clients. Start with the minimum number of services possible and start adding services as needed. For a server, this can sometimes lead to adding quite a few services, but if done with care, this is usually not a big issue. For example, it's not uncommon to find server computers that are simultaneously acting as file server, email server, font server, authentication server, remote access server, web server and ftp server. However, for most installations, it is best to not load down any single computer in this way. The impact upon the organization is tremendous if that computer should be out of service for any reason. Spreading the services out among a few computers limits the impact when one of them should be out of service. Some services, such as web server, are difficult to configure securely and others such as remote access can introduce additional risk, so mixing many services usually leads to a less secure configuration as well. Note that the degree of “secureness” is influenced by the number of services in many cases. Choosing which software to run One of the simplest ways to select which services are installed on a computer happens when the computer is first installed. By carefully choosing which software bundles get installed, the person installing the computer can greatly simplify the task of choosing which services to run after the install is complete. Some other benefits of only installing needed software packages are that the computer will then have more free disk space and be less complex to maintain. From a computer security stand point, this practice is also beneficial. Most operating system vendors have created their installation tools so that the end result is a highly usable system. While this may sound like a good thing, it is usually accomplished by loosening the permissions on files and installing configuration files so as to make services as widely available as possible. Thus, the newly installed system might be highly usable not only for those intended to use its services, but also to those not intended to use them. And finally, a simpler operating system installation means that the job of final configuration of the computer is also simpler. There will be fewer configuration files to customize and fewer files that need to have their permissions tightened, thus making it much easier to identify when a computer is not behaving as it should be. For all of the above reasons, always use a “custom” install option and not the default. Protecting services While the simplest method of protecting a service on a computer is to either not install the software or to not run the service at all, this is not always possible since some services need to be available on some computers. The best line of defense for these running services is to use access control package based like Weitse Venema's TCP Wrappers, available at: ftp://ftp.porcupine.org/pub/security/index.html They are now shipped and installed by default on most of the free operating systems: NetBSD, FreeBSD, OpenBSD and most versions of Linux. TCP wrappers provide an amazingly good first line of defense for these computers. They allow the computer's maintainer to define a set of allow/deny rules for each installed service. The decision to allow or deny is then made based on the location of the clients who attempt to connect to the running services. When allowed, the clients see nothing unusual, they simply access the services as if the TCP wrappers weren't there at all. But when denied, the unauthorized client never gets a chance to talk to the service at all. Its connection to the computer running the service is immediately dropped before the service is even made aware of the request. Besides the ability to allow and deny service requests, the TCP wrappers also provide verbose logging of all connection attempts along with the client's host name, the time of day and whether the connection was allowed or denied. Although quite verbose at times, these logs are immensely useful for a computer's maintainer in debugging network problems or when digging back through logs in an attempt to find out who might be misusing a computer. For Windows platforms, the Microsoft IP Filtering is an option similar to TCP wrappers for UNIX-like operating systems. For Windows XP, use the built in Internet Connection Firewall (ICF). Microsoft IP Filtering does not provide logging. Another important aspect to protecting the services on individual computers is to very carefully examine and tune the configuration files for each piece of software. It is almost always a good idea to turn off all features that are not needed and limit access to the enabled features. It's also very important to not overlook the banner messages that are usually defined within the configuration files. An interesting sidelight is the tendency of people to use the word "welcome" in the messages that appear when a service is first accessed. This is a very bad thing to do. The "welcome" message can actually be used during criminal proceeding by the defense to show that the defendant was actually "welcome" to invade the computers! A good document that talks about banner messages is available from CIAC: http://www.ciac.org/ciac/bulletins/j-043.shtml Perhaps the single most important way to protect any service is to carefully maintain and store the logs generated by that service. These logs will not only tell when the service is broken, but in ideal situations will also tell where connections originated, what features of the service were accessed and when. In terms of computer security, there is nothing more valuable than these logs. With them almost any unauthorized access to any computer can be tracked down. Even if the unauthorized users turn logging off, the first connection to the computer will be logged giving valuable information about where any attacks originated and possibly the user name of the person who launched the attack. To protect these logs, it is always a very good idea to make sure that they are forwarded through the network to another highly secure computer. This configuration keeps the logs secure from modification by unauthorized users. It also keeps them secure from people who just want to sift through them for information about the organization or the people in the organization. Common examples of this type of information include connection patterns, computer names and even people's passwords when mistyped at a keyboard. To further emphasize the importance of the logs generated by the services on a computer, consider the worst case scenario. A highly secure computer that contains payroll information, including social security numbers is penetrated by someone across the country via the Internet. They download all of the payroll records and proceed to post it to publicly available sites including public web sites, UseNet and large email lists. And finally, they erase the computer's hard drive. If the logs for this computer are verbose and forwarded on to a secure computer, then it is possible to go back and look at the logs to determine where the attack originated, when and what was done to gain access to the payroll computer. This is usually enough information to pass to law enforcement to at least give some leads in an investigation. Other information that might also appear in the logs include: the actual username that the attack was using, any local usernames that the attack exploited, which services were exploited and how they were exploited. If the logs were not forwarded on to a secure computer, when the computer's disk was erased, any existing logs would probably have been erased. And backups of that computer don't always give a complete picture of what happened to the computer. Programs for Further Protection Stepping beyond the limits of the software that is usually installed on a computer by the base operating system, computer security steps into the wider world of software that is available on the Internet. This ranges from the most basic drop-in replacement for software commonly shipped with operating systems to more esoteric software intended to identify changes to the operating system itself. While usually not difficult to install or configure, this software can sometime be difficult due to lack of active maintenance, or lack of support for some operating systems. But, the quality is usually good enough for at least minimal usage. Perhaps the single most important piece of software that one can install onto a computer is SSH. A drop in replacement for the client and server side of the UNIX rlogin and rsh services, SSH makes a dramatic leap forward in securing an organization's computers by using strong encryption to encrypt all traffic and also the entire login session itself. This defeats the common practice of using network "sniffers" in an attempt to steal other people's passwords. While a mostly UNIX-oriented tool, SSH clients are available for many different platforms including the MacOS and all varieties of Windows. SSH is ideally suited for use in the system administration of computers. It protects the highly sensitive administrative passwords that frequently give high levels of control to individual computers. SSH also can be used to replace other relatively insecure programs that are used to copy files between computers. These features combined with SSH's ability to tunnel other network connections between computers make SSH an invaluable tool for securely accessing remote computers. Take additional steps to help reduce the risk of SSH password guessing compromises:
For more information on SSH and other related software, look at the SSH User's Group web site: http://www.ssh.org/ or Openssh.org http://www.openssh.org/ Please keep in mind that this site is run by Data Fellows, who sell one of the more common commercial versions of SSH. One of the more common challenges in large organizations is examining the logs created by its computers. They can frequently be extremely verbose, creating many tens of megabytes of logs each day. This makes the job of finding misconfigured or misused computers very difficult. Much like looking for the proverbial needle in the haystack. Luckily, for UNIX-like operating systems there are a few software packages available that make examining the logs much simpler by filtering them based on interesting events. Two software packages based on similar ideas are swatch and logsurfer. Swatch is available for download at: http://swatch.sourceforge.net/ Written in PERL, swatch takes the quick and dirty approach to log filtering by allowing the user to create rules based on PERL regular expressions. Once a line out of the logs matches a rule's regular expression, swatch then performs the action present in the corresponding rule. Usually, this action tells swatch to display or ignore the corresponding log, but far more complex actions such as sending email or executing arbitrary programs are possible. Logsurfer, although the program is similar to swatch in concept, it is a more powerful log filtering program. It is driven by a set of rules built out of regular expression and action, but unlike swatch, it allows other actions that create filtering states. That is, it allows the user to create rules that only match when other rules have already been matched. Thus, with logsurfer, it's possible to look for events that consist of a sequence of events in the logs. Logsurfer is available at: http://www.cert.dfn.de/eng/logsurf/ Stepping away from the issue of computer logs, another important issue in computer security is knowing when changes have occurred to the files stored on a computer's hard drive. This is especially important due to the proliferation of "root kits", or bundles of software that replace the critical parts of an operating system that deal with user authentication. This problem can be addressed with a package called Tripwire. The idea behind Tripwire is that one can store information about files stored on a hard drive such as it's size, modification date and a cryptographic hash of it's contents. Then at a later date, these stored values can be compared to what's found on the hard drive. If there's a difference, then the file has changed. Although this sounds like a simple idea, it's surprisingly difficult to implement correctly. The biggest problem revolves around storing the file information in a secure way. Originally, Tripwire was only runnable on UNIX-like operating systems, but it has now been ported as a commercial product to Windows NT, 2000 & XP available from Tripwire Security Systems located at: http://www.tripwiresecurity.com/ So far, all of the software packages presented are designed to point out existing problems with a computer, it's operating system or it's installed services. In essence all of the software seen so far is passive in nature. That is, it simply observes a computer and then notifies the computer's maintainer when something is broken or changed. Although this is a very important thing for any computer's maintainer to know, it is not always enough. Sometimes it would be nice to know where weak, but not yet exploited points are on a computer. Perhaps the single greatest weak point on any computer is the passwords that users pick to protect their accounts. They frequently pick passwords that are incredibly simple to guess, such as their spouse's first name, their birthday or simply a word in the dictionary. And when asked to choose a new password, they will frequently not do so due to the fact that they'll then have to re-memorize their password. It's this laziness in protecting their accounts that makes users' passwords a prime target of attack for malicious users. Malicious users will obtain a copy of the password file and then they'll attempt to guess the passwords on users accounts. Since this task is easily performed on any computer and since the passwords on users accounts rarely change, the malicious user can take as long as he/she wants to guess passwords in the attempt to guess as many as possible. To stop this situation from being a problem, it has long been common practice for the maintainers of a computer to attempt to guess the passwords on their user's accounts. The difference is that when the computer's maintainer guesses a password, he/she will notify the user and ask them to change their password. When a malicious user guesses another user's password, he/she will frequently make unauthorized use of that account. One of the first password guessing programs written for UNIX-like operating systems is the package known simply as Crack. It is built on the simple idea that one can take multiple dictionaries, permute or modify the words found there in lots of different ways and then use the modified words that result to guess user's passwords. The real power in Crack is in the permutation and modification rules. They are very complex and long, performing over 100 different modification to the words in the supplied dictionaries. Also, in more recent versions of Crack, there is support for running it on many computers simultaneous to use the computing power of more than one computer at a time. Crack can be found here:
A more recent, and powerful password guessing program for UNIX-like operating systems is John the Ripper, or just John for short. Designed along the same as Crack, but with highly tuned assembler code for extremely fast password encryption, John is about the fastest password guessing program available. http://www.openwall.com/john/ For Windows, the problem of guessing passwords is an even larger problem. Due to the abysmal encryption algorithm used in Windows systems before Windows 2000, it is far easier to guess a password for older Windows systems than for UNIX-like operating systems. In fact, the encryption algorithm used in Windows NT is so bad, that it’s possible to try all possible passwords on a reasonably powered Pentium II computer. Obviously, this is not a good thing. Microsoft improved the encryption scheme in the newer Windows systems (e.g., Windows 2000 and XP) with the introduction of NTLM2. This algorithm should be used whenever possible. A patch for some older systems is available from Microsoft to allow use of NTLM2. In general it is a good idea to use strong administrative passwords or passphrases of 14 characters. The most commonly used Windows password guessing program is L0phtCrack: http://sectools.org/tools2.html Where to learn more Want to learn more? Here's a list of some of the better computer security related resources available on the Internet today: CERT (Computer Emergency Response Team)
|
|
||||
|
