Web Security Fundamentals

In this section you'll look at the fundamental concepts regarding web-application server security. Many of these items don't directly touch on 10g AS as a product, but you need to be aware of them.

Harden Every Layer

There are so many ways to break into a system from both the inside and outside that you need to apply security at every level. A layered defense against hackers is the best policy to implement and is difficult to defeat. A common flaw is to assume that just because you're behind a firewall, security isn't important because no one can get in. Under that approach, once someone from the outside does get in or if it's an inside job, your system is wide open . The sections are a high-level list of areas to check to make sure security is in place.

Web Server

In this section you identify common fundamentals of web-server security.

• Shut down all ports and listeners except for the ones that you need. When specifying listening addresses, use specific IP and port combinations; not wild cards like port 80 on all addresses.

• Change your port numbers from the default, publicly documented ports, if possible. You'll still need to work with industry defaults like port 80 and 443, but it isn't necessary to leave port 1810 as the default administrative port for the Application Server Control (ASC) utility.

• Shut down nonessential software features and services. For example, if you're not using Web Cache or the ASC, shut them down. Just because you might not be using them doesn't mean a hacker won't take advantage of them.

• Remove demo software on production machines. They aren't needed by your customers and pose a potential security risk.

• Use HTTPS secure traffic wherever possible. Many Internet sites just use this for sensitive traffic such as credit card processing, but other organizations use it exclusively.

• Stay current on patches and work-arounds. There's a near-continual stream of published security alerts that demand your time and attention.

• Implement solid security polices with Apache directives and development technologies. For example, CGI applications have long been a potential security weakness for web servers. If you're not explicitly using CGI, disable it.

• Check your access and error logs for unusual activity and access attempts. Ideally , you should know how many hits your site is getting and from where, although there are may caveats with regards to interpreting information from these logs.

Database

Databases, especially Oracle databases, have multiple layers of security and a complex array of security and auditing options. (See http://otn.oracle.com/documentation/database10g.html for more details.) Normally, one or more DBAs are tasked with managing the database, with security being part of their job. The following is a list common security items that should be addressed regarding databases:

• Change default passwords for database accounts. These include the well-known SYS and SYSTEM accounts, but there are others (depending on the database version) such as CTXSYS, MDSYS, PORTAL30, PORTAL30_SSO , and so on. Unused demo accounts like SCOTT should be removed and unused system accounts should be locked.

  Note 

  Be careful when changing passwords for Oracle Portal or OID accounts within the infrastructure database, asdb . Many of these passwords are also stored internally within Oracle tables and would not be updated by an ALTER USER xxxx IDENTIFIED BY "new5passwd!"; . Change these types of passwords within OID and PORTAL to make sure the necessary synchronization occurs.

• Apply security patchsets and upgrades when they become available. Try to standardize on the terminal release for each database release because these will be supported longest. For example, 8.1.7.4 would be an acceptable version for 8i databases.

• Enable auditing within the database and application where appropriate. Also review the logs and schedule them to be removed on a periodic basis. Keep in mind that some industries have legal requirements for this type of information so check your requirements.

• Restrict roles and privileges within the database to the smallest privilege level possible for both schema accounts and user accounts. This won't make you popular with developers and users, but it's your job to promote a secure system. Support from management is sometimes necessary.

• Encrypt data within the database where appropriate. Examples of data to encrypt would be credit card numbers of social security numbers.

• Implement Oracle row-level security where appropriate. This enters into the topic of Virtual Private Databases, but the idea is to restrict what a data a user can see. For example, two users with different permissions but the same SQL statement would retrieve different data.

• Use discretion when creating test and development environments based on production. It's common to export a production database and import it into another database for testing and development, but what about the production data in it? Test and development systems are usually less secure, but if they have production data in them they still must be protected. A better approach is to export only the production data and structures you need and then use dummy user accounts. Or run a script after the import to hide and scramble important information.

• Secure your backup copies of the production system because even old data can be useful to a hacker or criminal. This is commonly overlooked. The same holds true of DBAs or developers taking exports of production systems, but leaving the export .dmp files carelessly on a server or PC.

Operating System

Operating system security topics can fill entire books, but here are some common practices used by system administrators to secure their system.

• Shut down nonessential software features and services. It's common to find mail , ftp , and rhost commands disabled unless you need them. Linux installations come with many packages available, but security dictates that you only install what you need.

• Force the use of more secure alternatives to FTP and Telnet such as ssh and sftp .

• Set default umask permissions so files and directories aren't readily accessible. Permissions for most files and directories (for example oracle:dba) should be at most 750 and even these can often be further restricted.

• Run password crack routines to determine which accounts use weak passwords (see www.password-crackers.com and www.atstake.com/products/lc/ as examples).

• Apply security patchsets and operating system upgrades when they become available. This also reduces the number of patches needed when new Oracle software needs to be installed.

• Check your system logs for unusual activity. This should be done for both a preventative maintenance and security perspective.

• Secure your backup copies of the production system because even old data can be useful to a hacker or criminal. This is commonly overlooked.

Network

The following are some common practices for network administrators.

• Implement one or more firewalls to restrict access. There are several firewall topologies available and we'll identify them later in the chapter.

• Open only those ports necessary to do the job. Don't just "open everything" to all locations because it's the easiest way to work. Lock down everything and then open just what's necessary.

• Watch for unusual traffic and attempts to access from unauthorized locations. This can be an indicator of an attack.

• Encrypt traffic where appropriate. However, keep in mind that encryption is a performance hit so use it where the risk is greatest. For example, credit card transactions on the Internet must be encrypted. However, accessing the corporate intranet from within inside several firewalls may not necessarily demand encryption.

Application

Applications, especially custom-written ones, tend to have more security holes than any other component. The reason for this is that while large vendors can afford to have large security reviews of their code, smaller homegrown applications often place security behind functionality. These are some of the items to consider when developing secure applications:

• Review the process flow of the application in order to identify security problems with the processes (not just the code).

• Review auditing and security permissions within the application. For example, can the same user write and approve the same financial disbursement?

• Identify what sensitive data is being stored in the database and if it should be encrypted. Examples would be credit card numbers and social security numbers.

• Identify if the application handles password expirations in a timely manner. If it doesn't force password-change functionality and expirations, see if it can be implemented.

Users

Training users about security and enforcing standards is usually a tough, thankless job but it needs to be done. It's amazing the number of times carefully architected security schemes can be rendered useless by a group of users sharing the same password or doing something else wrong. In some cases the users are just lazy while in others they just don't know the right way to do things. This is where training, documented polices, and enforcement are necessary. The following is a list of actions you can impose to reduce security problems caused by users.

• Fix the most obvious of all security breaches by users: poor or shared passwords. Establish a policy of forcing users to change their passwords every 30 to 90 days and make sure it's enforced. Sometimes management has to support this because people complain or attempt to "defeat" the password scheme. Also make sure passwords are "strong" with a combination of letters , numbers, and some special characters .

• Many websites and applications offer a Remember Password button. Educate the users on the risks of this, particularly with business-oriented application software.

• Unauthorized software commonly finds its way onto networks. Most problems with this center around incompatibilities with other software (a desktop issue). However, problems with licenses and viruses can be introduced into systems in this manner because there's no control over what's being installed. Illegal and infected software can appear in this situation.

The preceding items aren't meant to be an exhaustive list of policies and practices, but they can be used as a starting point. No one person can secure everything and security should be handled by the appropriate people for an area: web admins, DBAs, system admins, network admins, desktop support staffs.

One final note about the previous items: Implementing security isn't a one-time event. It's a continual, time-consuming , iterative process of reviewing potential vulnerabilities and implementing patches, work-arounds, and policies. Over time, systems need upgrading and policies need revision due to changing conditions; be sure to be responsive to these changes.

Network Design and Firewalls

Network design and firewall security is outside the scope of this book, but we'll cover the fundamentals. A firewall can be considered a "smart router" because it's a network device that can be configured to allow or block incoming and outgoing traffic. Rules governing this traffic include source, destination, protocol type, and port number. For example, the network team can set up the firewall so that only HTTPS traffic on port 443 to a specific server IP (for example, wc-test. name ) will be allowed to reach the server from outside the firewall. Other incoming requests can occur and the server itself may be listening for those requests , but that unauthorized traffic will not reach it. Within Oracle HTTP Server (OHS) you can also specify similar settings using Allow and Deny directives. However, these protections need to be initially established at the firewall level.

In Figure 20-1, you can see a simple, single firewall in front of the OHS server.

Figure 20-1: Single firewall architecture

In Figure 20-1 you can see what might be set up for a very small company. In it you have one firewall separating the public Internet from the internal corporate network. The firewall is configured to allow only HTTP traffic via port 80 to access the OHS server. Any other incoming (and potentially outgoing) traffic is blocked at the firewall. Traffic from the mid- tier to the database server is internal within the network and therefore clients from outside the firewall cannot directly access the database.

Within the internal corporate network, traffic is unrestricted so if an administrator needed to connect to the mid-tier ASC utility via port 1810 she could because she isn't going through the firewall.

The preceding architecture is conceptually simple and certainly better than no firewall, but it can be improved. One drawback with the previous network is that the single firewall represents a single point of failure. If it goes down, all the ports are open exposed to the public and you had better have hardened the web application and database servers. Additionally, if your web application server is compromised, the intruder has unrestricted network connectivity to the entire internal corporate network.

In Figure 20-2, you can see an improved network configuration using two firewalls to create a Demilitarized Zone (DMZ) to separate the web servers from the rest of the network and servers.

Figure 20-2: DMZ firewall architecture

The DMZ created between the external and internal firewalls acts as a buffer zone between the external Internet and the secure internal corporate network. The idea is that if the external firewall fails or an intruder does somehow get past it, he doesn't have unfettered network access to the internal corporate network. This is a way of protecting your web server with the external firewall, but not risking your entire network because you have an additional layer of protection with the second firewall.

In Figure 20-2 we've increased security by allowing HTTPS on port 443 traffic from the Internet into the DMZ. Once inside the DMZ, only the web application server is located there. There ideally shouldn't be any sensitive data or databases on servers inside the DMZ, so even if the web application server does get hacked the loss will not be catastrophic.

Access from the DMZ into the sensitive internal corporate network is restricted by the internal firewall to Oracle Net ( formally called SQL*Net) traffic on port 1521. It's important to note that this traffic must originate from inside the DMZ to the database server.

For the administrator to access the ASC inside the DMZ, his PC is located within the secure internal corporate network. HTTP traffic initiating from his PC on port 1810 will be allowed to pass from the internal firewall and into the DMZ to connect to the mid tier. In this manner his PC isn't at risk inside the DMZ and no one can access the mid-tier ASC from outside the external firewall.

Tip 

Work closely with the firewall administrator to block only the traffic you need. Also have the firewall administrator monitor your traffic when attempting to set up the mid-tier instance. Many connectivity errors that occur during setup and configuration of the mid tiers are because the firewall is blocking traffic. Generally, administrators configure their firewalls to block everything unless you explicitly ask for a port and IP to be opened. Although this may cause problems during the initial setup, it's a good security policy.

Firewalls play a critical role and no commercial system should be placed on the Web without them, but you need to ensure they aren't your only line of defense.

Shut Down Unnecessary Services and Ports

10g AS comes with many intriguing features and options, but if you're not going to use them, don't install or configure them. You can add on to an existing installation or install into a new ORACLE_HOME if you find you need a previously uninstalled feature. The Oracle Universal Installer (OUI) provides multiple wizards that you can use to configure options after the installation, but only select the ones you'll need. If necessary you can run these wizards later if you need a component configured.

By reviewing the $ORACLE_HOME/install/portlist.ini file you can see that there are many ports available. Although some of these ports are dynamic, they have a defined range and can easily be guessed. After the installation, change these ports, if possible. For example, your website should only be listening on port 80 for HTTP and port 443 for HTTPS traffic. Your firewall should block all other ports externally.

It's possible and recommended to shut down administrative pages unless you need them. There's no runtime need to keep utilities like the ASC and the Web Cache Manager running; doing so only consumes resources and provides an intrusion opportunity because the utilities represent additional ways into your system. Wherever possible it's a good idea to change the default, publicly known ports for these tools and make sure that they are SSL enabled. You'll see in a later section how to change the ASC ports and passwords.

Apply Patches

The first step after installing 10g AS should be to apply all security patches and any applicable work-arounds recommended by Oracle. Although DBAs almost exclusively apply software patches to fix problems, 10g AS administrators often have to make configuration file changes to " work-around " security issues until a patch is made available. These work-arounds are typically listed in Oracle Security Alerts and are normally simple to implement. These patches and work-arounds should be done prior to configuring the software and putting it on the open network.

We usually open a Technical Assistance Request (TAR) with Oracle and ask specifically what security alerts, patches, and work-arounds apply to our version of the software. This provides the following two benefits:

• Patches and work-arounds change from release to release and no one is better staffed to know what needs to be applied than Oracle Support.

• By saving a copy of the TAR documentation and my patch logs, we have "proof" that our system met the standard patching requirements in case a security audit or hack occurs.

Patches are obtained from the Oracle Metalink forums, which are available for Oracle Support customers. Simply go to the Patches link, enter the patch number and operating system, and click Go. Often there will be multiple patches listed for both the database OHS and 10g AS so make sure you get the correct patch. Also be sure to carefully read the README.txt file because there are often multiple manual steps that need to be performed, backups to be taken, and software to shut down prior to applying the patch. Of course you should have a patch back out and recovery plan in case the patch causes problems and should test patches in development and test before applying to production.

Tip 

If the patch is a simple shell script that only copies over a new file such as httpd , you should make a backup copy of that file before overwriting it. Restoring this file is easy if problems occur. Larger patchsets requiring the OUI are more difficult to back out of. Take an operating system backup of the $ORACLE_HOME , but also make a tar backup of the oraInventory and jre directories in $ORACLE_BASE . It's this directory that stores OUI information regarding what patches have been applied. If you need to restore your ORACLE_HOME after a patch, you'll also need to restore these directories so the OUI and ORACLE_HOME remain synchronized.

Tracking patches is important from an auditing perspective and to ensure that your development, test, and production systems are consistent. Create a patches subdirectory under $ORACLE_HOME . In that directory, make subdirectories for each patch or bug number and download the patch file from Metalink to that location, as shown here:

 $ cd $ORACLE_HOME/patches $ ls 2701372 README.txt 

Keeping a copy of the download patch file in the patches subdirectory provides a good record of what has been applied. Additionally, it allows you to easily find all the software patches in one location in case you need to build an identical environment on another machine.

A detailed README.txt file should be kept in the patches directory for additional auditing purposes. It's also useful when creating Oracle TARs and Oracle Support asks you what patches have been applied to your system, as you see in the following sample file:

 $ more README.txt #Patch/Bug: 2701372 #Title: Oracle Security Alert 65: SOAP Vulnerability #Date Applied: 2/28/04 #Files Changed: soap.jar #Description: Vulnerability in SOAP resulting in possible DoS attack. $ 

Applying patches is a necessary and frequent part of being a 10g AS administrator. Some are security related while others fix bugs with products. Expect to spend some time keeping your environments up to date.

Check Security Alerts Regularly

Since 10g AS is a web server and it's based on Apache, there are frequently new security vulnerabilities being found with this software. That isn't to say the software has any inherent problems with it, rather it's under continual scrutiny and repeated testing in order to find vulnerabilities. When a security vulnerability is found and a patch or work-around has been developed, it's posted on the following Oracle Technology Network (OTN) site (see http://otn.oracle.com/deploy/security/alerts.htm ).

From this page you can see all the security alerts for both 10g AS and 9iAS and Oracle databases. Work-around and patch information is also provided within each alert document. However, you still need to obtain patches from Metalink. The default Metalink My Headlines page with News & Notes also shows security alerts as they occur, but OTN provides a more comprehensive listing.

Outside security companies and organizations searching for new Apache vulnerabilities originally identified many of the security alerts listed on OTN. Because 10g AS is based on Apache 1.3.28, any vulnerabilities with that version will also likely apply to 10g AS. However, when non-Oracle organizations provide patches or recommend upgrading Apache, do not apply their fixes to OHS. Oracle has made changes to their Apache OHS and those may not be compatible with outside patches. At a minimum your system would no longer be supported by Oracle because you would have modified a core component of the software. The best solution is to wait for Oracle to provide a patch or work-around. However, if the work-around is something generic and you can easily undo it, you can implement it until Oracle officially addresses it (but use caution).

The versions of Apache that the OHS is based on often trigger security auditing software as being a risk. Especially with earlier versions of 9iAS, security software will find what it thinks is a normal Apache installation and will then check its version. For example, it may find a 9iAS installation that appears to be running Apache 1.3.22, which has vulnerabilities. The security software (which isn't programmed for 9iAS or 10g AS) will recommend that you upgrade to a higher version. However, it doesn't know that Oracle may have already fixed the vulnerability in the base release or later, may have provided a patch, because Oracle patches don't upgrade the Apache version number. Therefore, although the software may show that 9iAS is running Apache 1.3.22, the OHS may actually be patched and is OK, but it may not be showing a higher Apache version. To know for sure, you need to check your version of 10g AS (or 9iAS) against known security alerts and patches. Oracle Support can provide time-saving help in this area.

Use Common Sense and Be Vigilant

It's 100 percent necessary to apply patches and shut down unnecessary ports and services in order to guard against advanced hacker attacks, but you also need to defend against silly mistakes made by your own organization. Many security breaches occur not because of the dedicated, brilliant hacker who spends countless hours trying to infiltrate a system; but rather because of someone inside the organization who didn't think about what he was doing and did something dumb. In other words, use common sense when working on systems.

The following sections describe a couple of examples of real cases that we've seen.

Giving Up System Data and Control

More than once we've had an overseas support technician simply ask for complete database exports of sensitive production systems, login access into the system, or key configuration files containing usernames and passwords to "troubleshoot a problem." Normal users have logins and passwords, auditing processes, and perhaps even have security clearances to access a system, but you're supposed to just turn over that same data or system to an outside support tech you don't even know? Absolutely not! If you blindly give up system access to anyone who just asks for it, perhaps you shouldn't be managing systems.

More than likely the support technicians are honest people trying to solve a problem, but you just don't know for sure or if they secure the data on their side. If someone asks for your data or system access under the guise of troubleshooting, find a work-around with dummy data or access, or at least get management approval first.

Usernames and Passwords in Text Files

It's not uncommon to find unencrypted usernames, passwords, connect strings in configuration files, and shell scripts. This practice should be avoided wherever possible and passwords should be encrypted. At a minimum, the file permissions should be kept locked down at the operating system level. The obvious threat is an outside hacker who knows files that commonly contain this information ( connections.xml, wdbsrv.app (9iAS V1), dads.conf , and so on) and exploit them. Fortunately, some files like these can also be configured with 10g AS to store encrypted passwords that are read by the software and unencrypted when needed. When using the GUI configuration tools, this encryption is often automatic. In contrast to an intruding outside hacker, a less obvious but more likely event is a nosy user, developer, or administrator who has machine access, and who is finding these files and gaining unauthorized access to other systems. Files such as these need to be identified and placed under the control of the administrative account without read permissions to other users.

Sometimes files with sensitive data can be created and you, as the administrator, will not know they exist. Core dumps on UNIX and Linux are an excellent example. When a process aborts, it can leave behind a large, binary core file containing the memory contents of that process when it died. These files can be useful when debugging problems and are often requested legitimately by support organizations. However, if you run the Unix strings command on the file (for example, strings core ) there are sometimes embedded usernames, passwords, database names , and ports available in clear text. This makes sense because this information is needed by the process during runtime and will exist in memory. You need to be careful to either remove or secure the permissions of any core files created. Also check them to make sure no sensitive information is in them before uploading them to an outside support organization.

Sometimes log files can contain sensitive information. One recent example was some patches for Oracle 9iAS Portal. The OUI prompted you for a DBA username, password, and database name for the Portal repository database. Upon completion of the patch upgrade, log files were in the $ORACLE_HOME/portal30 subdirectories, which contained SYS and PORTAL30 usernames (with full DBA permissions), clear text passwords, and the corresponding database name. Worse yet, these files happened to be world-readable (755) so anyone on the machine could potentially get this information. In this case the problem was with this specific patch, but the point is that you need to be aware of your log files and what they might contain.

Developer and Application Errors

While troubleshooting an unrelated HTML problem for a developer, we noticed that the text contained a username, password, and the complete database connection information in a comment. This raised concern and the developer was contacted. After a brief discussion, we learned that this was intentional! The developer was faced with getting default login information to thousands of users, but did not or could not contact them individually. Therefore, the developer devised a plan of hiding the username, password, and database information inside the HTML and then having the users do a "ViewSource" (menu option is View Source) with their browsers in order to find this information.

Although the database account had minimal privileges, this was an inappropriate method for Internet applications. Default accounts are acceptable, but not in this manner, especially when actual database, server, and port names are given out to the Internet. The developer was simply rushing to get the system implemented and didn't fully appreciate the security implications. After a brief discussion, a more secure and cleaner default login approach was developed.

The point here isn't the specific incident, but that you need to be on the lookout for security risks everywhere.

Cost of Security

Managing security issues is itself expensive in terms of human resources and system downtime. It takes time and effort from one or more administrators to stay on top of new security alerts. Just reviewing the logs and system configuration files to determine if there is a susceptibility to vulnerability takes time. Finally, to shut one or more systems down for patching can have a cost associated with the downtime. Additionally, implementing security features can slow down performance, create inconveniences for users, require extra effort by developers, and sometimes cause unexpected outages if too many features and ports are turned off.

These costs need to be weighed against the potential risks and costs caused by an intrusion. Keep in mind that these costs must include downtime and lost revenues by the system while it's down and being investigated and repaired. Some organizations will quarantine the server for criminal investigation if it's hacked, so your application will be down during this time unless you have a backup machine. Additionally, if your system is compromised it will also impact any other application connected to yours, because those systems will also have to be examined.

Unfortunately, in many organizations administrators are already so overburdened with daily tasks and projects that important security tasks are given a lower priority. Although few people like to admit it, security usually isn't taken seriously until after there is a problem. It's not that systems cannot be secure; rather it's usually that some vulnerability alert was missed or something "fell through the cracks" because people were too busy with other tasks . It's up to management to make security a priority and fully support their administrators when they make unpopular decisions in favor of security or take extra time to investigate security issues.

Although applications have to be accessible and this does imply some risk, we've covered some items to reduce that risk. Next we'll cover several 10g AS-specific tools: securing the ASC, using OWM, and exploring Identity Management.