MetroSphere.com

MetroSphere is an online technical community and information marketplace built with WebSphere Portal. When it's complete, MetroSphere will allow consultants, programmers, and technical writers to gather and share information, tips, and techniques, while at the same time providing a customized portal to information of their choice. MetroSphere.com will be a place where individuals and companies sell and barter technical content and services, as well as enable better collaboration and workflow on new and existing projects. In this series of articles, tutorials, and tips from Studio B, we share our experiences as we build the MetroSphere portal.

This is one of a series of articles detailing the ins-and-outs of deploying IBM WebSphere Portal - Express. While Tom (system administrator for the MetroSphere project) works on setting up WebSphere Portal Enable for the main MetroSphere site (see Resources), Nick (lead developer for the project) is going to set up Portal - Express on a separate server that we'll use as an internal portal. This article explains some of the potential security downfalls of setting up such a system and how to mitigate them.

Back to top

Introduction

Nick is a Web developer, not a system administrator, so he tries to stay out of the operating system as much as possible. He asked me what he should look out for in setting up the Windows 2000 server box for Portal - Express. I explained that there were plenty of reference books out there that he could check out for information. After he stopped laughing, he reminded me of our deadlines and asked for just the basics, all in one place, where he wouldn't have to hunt them down.

This article provides the basics of securing a server attached to the Internet, explaining what a system administrator should do and why. The approach is intentionally high-level. System administration is by nature a complex business, and there are no neat and tidy templates to follow.

The material presented here does not in any way purport to be comprehensive or system-specific. It is a broad overview of several security-related issues that system administrators and IT managers need to be aware of and prepared to act on. System administration is not rocket science -- it's a mix of knowing as much as you can about the product in front of you and having the ability to deal effectively with it.

This article should, however, contain enough information to adapt to your own specific situation.

Back to top

System security overview

Efficient system administration is a careful balancing act. Servers and networks do not exist in a vacuum. Users require appropriate access to resources -- meaning enough access to get the job done, but not so much as to allow vital data to be damaged (either by accident or intent). Administrators need to possess what is commonly referred to as a "healthy sense of paranoia." Loosely translated, all infrastructure planning and analysis begins with an assumption that everyone is out to crash or plunder your server. To balance this paranoia, it's important to develop an intuitive sense of what products to trust and what components present the greatest chance for failure and to have a game plan in place for dealing with every conceivable manner of disaster. Because the inevitable will indeed occur at the worst possible moment -- at the worst possible time.

The term system security is typically broken down into the following individual topologies or components:

• Hardware security
• Network security
• Operating system security
• Application security
• User/group management
• File permissions

Hardware security refers to physically securing important systems.

Network security involves protecting an internal LAN or network from unauthorized outside access, monitoring network transport libraries for security holes, and taking corrective action when problems are found, making sure network traffic makes it to the right place at the right time, ensuring no application is transmitting sensitive information across the network at any time, taking the steps to ensure that if a network service is compromised it doesn't affect other services, and making sure each running service is accessible to only valid users. Yes, that is indeed a mouthful. Needless to say, network security is a critical component of any well-run infrastructure.

The job of the operating system is to protect installed applications and their data files from illegal access. This includes providing secure network transport facilities for interactions between applications and clients (and between different applications as necessary), providing a safe and secure file system for data storage, and providing the necessary authentication services to ensure that only authorized users can access a given piece of data.

Application security involves ensuring that installed applications are working as advertised, applying program updates as necessary, and reconfiguring the installation as necessary when needs or purposes change within the company.

User/group management and monitoring file permissions means just what it implies -- ensuring that applications are running as the correct user (no key applications should ever be run as "Administrator"), adding system users as required, creating and managing user groups, and tracking file permissions on the system to make sure users cannot wander off into a part of the system where they shouldn't be.

As you can see, the above list is very much a top-down hierarchy. It starts at your connection to the Internet, and with each successive step toward file permissions, security typically becomes more granular. Some of the topic areas above overlap to some degree. Network security and operating system security are inextricably intertwined on most systems; user/group management and file permissions are closely interrelated, especially on Windows NT/2000/XP-based systems.

The balance of this article is in looking at each topic area outlined above, discussing cautions and caveats, and where appropriate, providing concrete suggestions to enhance system security.

Back to top

Hardware security

Contrary to popular belief, the amount of malicious damage done every year to corporate data by employees (current or former) far exceeds the damage done by script-kiddies or other low-profile hackers who have to typically brute-force themselves onto a company network. In short, it's a lot easier to attack something from inside than outside, and a former employee with a bad attitude and access to your server room is going to do a lot of long-term damage in a short amount of time if the opportunity presents itself.

The solution is simple: Systems containing data of any value need to be physically secure. Company servers hosting financials or employee payroll records should be, at the very least, behind locked doors. Even better is behind locked doors in an area where access is monitored. Important data needs to be backed up on a routine basis, and copies kept off-site.

(Our Portal - Express server will ultimately reside in the locked company server room, so that's taken care of.)

Back to top

Network security

At the very top of the network security list is the topic of firewalls. A firewall is simply a device (or a software program) that isolates network segments. The most common use of a firewall is to isolate an internal LAN or network from the big bad Internet. Important company servers should always, always, always be located behind a properly installed and configured firewall. Traffic should be allowed past a firewall only when necessary and in such a way that the outsider is routed directly to the one system service they are trying to access.

(Until our Portal - Express box is moved behind the company firewall, Nick has installed a software firewall that enables him to control all traffic in and out of the box, and he has assured me he's got it locked down tightly according to my instructions below.)

Services, ports, and daemons

The role of a server on a network is to provide one or more services to a client. Common services typically run on a server include:

• File Transfer Protocol (FTP)
• Secure Shell (SSH)
• Web server services (HTTP)
• Domain Name Services (DNS)
• Mail server services (POP, IMAP, and SMTP).

NOTE: On a Windows 2000 Server, the term services is equivalent to the UNIX term daemons. Both terms refer to a process of listening on a specific port for a client to request a connection.

Here is a look at an oversimplified example of how a service works. Corporation XYZ runs their own Web server. It's behind a managed firewall. When a user types XYZ's URL into their browser, the URL is translated to a numeric IP by a DNS server and a request is sent to XYZ's firewall using the Hypertext Transfer Protocol (HTTP). The firewall intercepts the request and notes that the system administrator has a rule in place that says "forward all requests arriving on port 80 to 192.168.1.10." Server 192.168.1.10 (the server's unique internal IP) happens to be running a Web server application (IIS, Apache, or perhaps IBM HTTP Server software), which is listening for incoming requests on port 80. The firewall passes the request to 192.168.1.10, and the server responds to the query (which typically means fetching the requested Web page and sending it back to the user's browser) and goes back to listening for the next call to action.

So far so good. But some system services are inherently insecure because the information they need to authenticate the user is passed between the server and requesting client in plain text. Meaning anyone who knows how to use a packet sniffer (a piece of software that enables the user to see any and all unencrypted transmissions exchanged between two systems) can capture the user's username and password and use that data to gain access to the user's account on the system. Some of the most well-known insecure system services include FTP, Telnet, NETBIOS (Microsoft's file sharing protocol), LDAP, POP, and IMAP. In other words, if you're using a non-SSL connection to check your e-mail, your username and password are accessible to anyone with a packet sniffer and a little patience.

There are solutions available to the above insecure protocols. SSH is a viable replacement for Telnet, SCP (Secure Copy) can be used in place of FTP, and POPS/IMAPS connections exchange data fully encrypted using SSL.

One of the first jobs a system administrator should perform when arriving at a new or unknown site is to ensure that the company's firewall is blocking all access to insecure services. If any insecure services are accessible, they should be deliberately accessible, and not simply open because someone forgot to do their job.

You can find out which ports are open on a system using a utility called Nmap (see Resources). Nmap is available as source code and as precompiled binaries for Linux (RPM packages), Windows (95/98/ME/2K/XP), Debian, Free/OpenBSD, Solaris, Mac OS X, and HP-UX. A pre-eminent system administration tool, it's also shipped as a default tool with most major Linux distributions.

To run Nmap, simply open a terminal window (or in the case of a Windows install, start the GUI) and type nmap [ip-address]. You should see output similar to the following (some relevant IP information was changed in the example shown for obvious reasons):

[tom@janus tom]$ nmap 217.4.XX.XXX

Starting nmap V. 3.00 ( www.insecure.org/nmap/ )

(The 1577 ports scanned but not shown below are in state: closed)
Port       State       Service
7/tcp      open        echo                    
9/tcp      open        discard                 
13/tcp     open        daytime                 
17/tcp     open        qotd                    
19/tcp     open        chargen                 
21/tcp     open        ftp                     
25/tcp     open        smtp                    
42/tcp     open        nameserver              
53/tcp     open        domain                  
80/tcp     open        http                    
82/tcp     open        xfer                    
135/tcp    open        loc-srv                 
139/tcp    open        netbios-ssn             
445/tcp    open        microsoft-ds            
637/tcp    open        lanserver               
1002/tcp   open        unknown                 
1025/tcp   open        NFS-or-IIS              
1031/tcp   open        iad2                    
1433/tcp   open        ms-sql-s                
3372/tcp   open        msdtc                   
5800/tcp   open        vnc-http                
5900/tcp   open        vnc                     
44442/tcp  open        coldfusion-auth         
44443/tcp  open        coldfusion-auth

As you can see, the above server is pretty much wide-open to the world. The operating system happens to be Windows 2000 (note the netbios-ssn file sharing protocol), FTP is running, SMTP is running (although there is no mail server setup on the system), and so on.

Compare the above example with another example of a server that has been explicitly locked down:

Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
Interesting ports on syroidmanor.com (142.165.XXX.XX):
(The 1595 ports scanned but not shown below are in state: closed)
Port       State       Service
22/tcp     open        ssh                     
25/tcp     open        smtp                    
53/tcp     open        domain                  
80/tcp     open        http                    
110/tcp    open        pop-3                   
143/tcp    open        imap2                   

Nmap run completed -- 1 IP address (1 host up) scanned in 2 seconds

The system is running SSH, a mail server, and a DNS server. All insecure ports shown are knowingly open, and the applications running the services are all running the latest software patches available. Users of the mail system on this server have been instructed to use a throw-away password (that is, a password that, if compromised, will not affect their access to any other systems or services).

(After installing Nmap on his personal machine, Nick found about a dozen open ports on the Portal - Express box, which we went through and closed off.)

As an administrator, guarding a server behind a firewall and opening those services for outside access is only the first step in ensuring your server stays secure. As long as those ports remain open, you have a responsibility to both yourself and other users of the Internet to ensure that the software behind services is configured correctly and kept up-to-date with appropriate security patches.

Finally, if you're running a public network service of any kind, make sure that if that service is compromised, it does not compromise other services in the process. This means making sure your applications are up-to-date with all relevant security patches and that services are not running with Administrative privileges. Running a service with Administrative privileges means that if the service is somehow hacked, the hacker gains Administrative rights to your system. In other words, you no longer own your server -- someone else does -- and they can do with it pretty much whatever they want.

To see what services are running on a Windows 2000/XP system, go to the Start menu, click Programs > Administrative Tools > Services. You should see a dialog similar to the screenshot below:

The right panel shows all running services, whether they are running as a local service or a network service (that is, accessible by local user only or from a network client), whether the service is stopping, running, or automatically started on request, and the service's current status. By selecting an individual service, you'll get a verbose description of the service, what it's used for, and any other information pertinent to that particular service.

To manually start or stop a service, double click it and choose the appropriate button from the ensuing dialog. You can also see any service dependencies by clicking on the Dependencies tab.

(I preconfigured a fresh installation of Windows 2000 Server on the Portal - Express box before I handed it off to Nick, so he didn't find any wayward services running when he checked the list.)

Back to top

Operating system security

As noted earlier in this article, an operating system's primary role on a system is to provide a safe and secure environment to run applications from. The operating system also provides authentication for local users and a secure file system for storing application and user data.

Keeping your operating system secure is also inextricably linked to keeping your network services secure and running as advertised. While most key network services are run by third party applications, some of the mechanisms used by the client to connect and authenticate with the server are provided by the operating system.

As a general rule, it's a good policy to keep your operating system as up-to-date as possible, provided the updates you're applying are pertinent to your installation. Some administrators are in the habit of applying every security update released to their system, but sometimes taking such an approach breaks more than it fixes.

The recommended procedure for Windows updates is to routinely visit the Microsoft Updates page (see Resources), carefully scan the available updates, and then go to the Security Bulletin page and read the bulletin explaining the patch.

Speaking from personal experience, it's always a good idea to apply any new and desired updates to a non-production machine and test it for a few days before moving the fix to a production box.

(Since it's not yet a production box, Nick brought the Portal - Express box directly up-to-date. Going forward, before moving them over to the server, he'll be testing updates on his own box until he transfers it back to my control.)

Back to top

Application security

The process of keeping your applications secure is similar to that of keeping your operating system secure. Visit the vendor's site regularly. Check to see what updates, if any, are available for your product. Read the documentation accompanying the fix and discern whether or not it affects you. Do not randomly apply updates to a production machine until they've been thoroughly tested on a non-production box.

IBM is typically very specific about program prerequisites and what security patches need to be applied to those prerequisites prior to installation. For example, WebSphere Portal - Express requires either Oracle or DB2 pre-installed on your server. If it's DB2, the program must be at Security Fix level 2. Why? Because Portal - Express stores its authentication information in the underlying database, and if the database is not secure, neither is the application server riding on top of it.

Another important issue for the system administrator regarding application security is that the application does not install and run as Administrator. As noted in a preceding section, if an application is running as Administrator and that application is hacked, whoever hacked the application effectively becomes the Administrative user.

One of the required steps that must be completed prior to the installation of Portal - Express is the creation of user accounts for WebSphere Application Server and DB2. This step ensures that neither application runs as Administrator. Details regarding this procedure are included in our tutorial Installing and configuring Portal - Express (See Resources).

The next section discusses user and group management, as well as Windows security policies and file permissions.

Back to top

User, group, and file management

Unfortunately (or fortunately, depending on your perspective), administering resources under Windows 2000 can be tricky business. The reason is twofold. One, the Windows 2000 resource object model provides a very high degree of granularity for managing system resources, and that granularity increases when Microsoft's domain model is factored into the equation. Two, there is overlap across some of the structures used to manage system resources.

What follows is a cursory overview of Microsoft's resource object model. It is not intended to be comprehensive or complete. If you're responsible for managing users and resources on a Windows 2000 server, do yourself a favor and invest in a good reference book on the subject (see Resources). Understand also that resource management under Windows 2000 is tied very closely to the underlying file system. Most of the options discussed below are available only under NTFS.

User accounts control user access to a resource. That resource can be a file, a printer, or a privilege (for example, changing a password, accessing a modem, or joining a workstation to a domain). User accounts also have scope. A user can be assigned a local account, meaning they can only log on to the machine locally, or a domain account, meaning that after they've been authenticated by the domain controller, they have access to any authorized resource on the domain without the need for re-authentication.

Windows 2000 supports three types of groups: local, security, and distribution. Local groups are recognized only by the local computer. Security groups have a security descriptor attached to them recognized by Microsoft Active Directory. Distribution groups are groups associated with e-mail distribution lists.

Groups also have scope. Possible options include domain local, built-in local, global, and universal. Windows 2000 ships with a dozen or more predefined groups, each associated with a specific group type, which in turn determines what a user who belongs to the group can do on the local system or domain. As you can see, things can get pretty complex in a hurry -- especially if you don't put some thought into how to structure your groups.

Each built-in user and group has associated with it a default set of privileges. For example, system-level or administrative groups can change the system time, alter the state of a running process, increase or decrease the file system quota for an individual or group, or manage the security/audit log.

The bottom line here is that the Windows security model can be extraordinarily empowering, but it can also be dangerous if used without a great deal of conscious forethought. Giving the wrong user more freedom than they need to do their job could potentially result in a compromised system, just as running an application under the wrong user can allow a hacker unrestricted access to sensitive data. Again, one of the key roles of an administrator is to carefully balance access to needed resources and the security of the system and/or network.

Here's where all the above conceptual material becomes grounded in reality: When installing WebSphere Portal - Express, you'll need to both create the aforementioned WebSphere Application Server and DB2 users and associate those users with a local security policy. A local security policy is simply a specific set of tasks/resources that a group of users can complete/access. The word local means that the security policy is only, in effect, on the local machine.

The final topic in this discussion is file permissions. File permissions are the final level of control for a Windows 2000 administrator. File permissions control user access for both local and network access. In other words, if a reader is given read access to a local folder, it doesn't matter whether the user is accessing that folder locally or remotely; read only is what they get -- even if the user is a member of a group that has read-write access on the same folder. Thus, there is an important point to note regarding overlapping file permissions: When file permissions overlap (that is, are in conflict), Windows defaults to the lowest common denominator, which, in the above example, is read-only.

Windows 2000 file permissions differ slightly from those used in the UNIX world. In particular, administrators can allow users to take ownership of a file or folder, append data to a folder (as opposed to modifying existing data), and synchronize a folder. For a full list of possible file/folder permissions, plus their permutations, consult any good Windows 2000 administrative reference.

(Nick isn't planning on installing any extra applications on this box, so we'll be monitoring the file permissions created by Portal - Express to see if anything needs to be adjusted.)

Back to top

Summary

This article should give you a good idea of what you need to think about when securing an application server for public access. Important topics discussed include restricting and monitoring system services, keeping both your operating system and applications up-to-date with security fixes, and understanding user, group, and file management. With the server now properly prepared, Nick can go on to install WebSphere Portal - Express.

Back to top

Stay Tuned...

In the next part of this series, the MetroSphere team brings you a tutorial on learning how to install WebSphere Portal - Express.

Resources

• Stay up-to-date with the MetroSphere Project by visiting the overview page.
  
  
• Take this tutorial from the MetroSphere team to learn how to install WebSphere Portal - Express.
  
  
• Get the Nmap Port scanner at www.insecure.org/nmap.
  
  
• Download and try the latest version of WebSphere Application Developer.
  
  
• Windows Catalog Update Page: windowsupdate.microsoft.com.
  
  
• Windows 2000 Server Downloads Page: www.microsoft.com/windows2000/downloads.
  
  
• Learn the strategy of integrating Tivoli Access Manager with WebSphere Portal server in "Securing Web portals with Tivoli Access Manager" (developerWorks, February 2002, updated June 2002).
  
  
• IBM Redbooks page: The IBM Redbooks site is a treasure-trove of high-level titles geared toward administrators and developers. Most titles are available online or can be downloaded in PDF format. If you're seeking help or insight on an IBM product, this is the place to start your search.
  
  

• Essential System Administration (O'Reilly & Associates), Frisch: If you need a tome that covers all aspects of system administration, look no further. Frisch's coverage is complete, and as an added bonus, her writing is lively and dynamic. Recommended.
  
  
• Practical UNIX & Internet Security (O'Reilly & Associates), Garfinkel & Spafford: An excellent reference to all aspects of system security from user management to drafting a security policy. Some of the security tools covered are dated in version, but the advice offered is time-honored.
  
  
• Windows 2000 Administration in a Nutshell (O'Reilly & Associates), Tulloch: An excellent desktop reference for the Windows 2000 administrator. The title is laid out alphabetically, and grouped by conceptual overview and by task.
  
  
• Windows 2000 Administrator's Pocket Reference (Microsoft Press), Stanek: Another good desktop reference, especially on the subject of understanding and managing users, groups, and security policies.
  
  

About the author

Tom Syroid is a staff writer for Studio B, a literary agency based in Indianapolis, IN specializing in computer-oriented publications. Topics of interest/specialty include *NIX system security, Samba, Apache, DB2, and Web database applications based on PHP and MySQL. He has experience administering and maintaining a diverse range of operating systems including Linux (Red Hat, OpenLinux, Mandrake, Slackware, Gentoo), Windows (95, 98, NT, 2000, and XP), and AIX (4.3.3 and 5.1). Tom lives in Saskatoon, Saskatchewan with his wife and two children.

Rate this article

Comments

Back to top

Table of contents

• Introduction
• System security overview
• Hardware security
• Network security
• Operating system security
• Application security
• User, group, and file management
• Summary
• Stay Tuned...
• Resources
• About the author
• Comments

Next steps from IBM

• Try: WebSphere Portal Express
• Briefing: WebSphere flexible business processes
• Buy: WebSphere Portal Express