They’re out there: the unseen heroes of the Internet underground. Continuously looking for a new way to bring your Web server down, these hackers are finding new ways to hurt even the big boys. This was most evident in early February, when a group of hackers was able to bring down three major Internet sites by using a technique known as a distributed denial-of-service (DDoS) attack. They were able to send a continuous stream of worthless data to a Web server, bombarding it to the point of shutting it down.

A single DoS attack is just one way that hackers can hurt your business. Another way is finding “back doors” or somehow gaining access to your Web server and either removing or altering the appearance of your business’s Web site. Most of these hackers know the systems they are breaking into better than the administrators or consultants that put these complicated Web systems together. PC- or UNIX-based Web servers are the most popular and therefore the easiest to find information on and hack into.

What do these malicious fiends gain from this activity? Nothing. What does a business lose? Hours or days of reconfiguring its servers, losing business and customers in the process. In the end, this can cost the business a lot of revenue.

Your Secret Weapon

While these hackers target systems they are familiar with, you can rest assured, for now, that the AS/400 architecture is probably foreign to them and a waste of time to most. This is your secret weapon in fighting hacker attacks. The AS/400 has always had exemplary statistics when it comes to security. The AS/400 HTTP Server is no exception. But, as with all security, it is only as secure as the time you take to make it so. Taking shortcuts when setting up security on your AS/400 Web Server, especially when it is connected to the Internet, can cause serious complications. As the saying goes, “bad security is worse than no security.” In this article, I will show you the three basic steps you should follow when setting up an AS/400 as a Web server. These are the easiest ways to protect and monitor your machine while it is connected to the dangerous world known as the Internet.

Step One: User Profiles and Directives

When you first get your AS/400 ready to serve the Web, you will discover that two user profiles seem to be the keys to your HTTP Server. These user profiles are QTMHHTTP

and QTMHHTP1. They come set up on your machine ready to roll and play an important part in the security of your Web server.

QTMHHTTP and QTMHHTP1

User profile QTMHHTTP is the HTTP Server profile. This means that, when your machine is serving documents from your AS/400, this is the user profile that is used for security. If this user profile can’t access something, someone with a Web browser will not be able to access it, either. This user profile comes set up with your machine so that no one can sign on using this profile, and it should be kept this way. Never change the password of this user profile from its default setting of *NONE unless you want a security risk for your machine. If someone happens to sign on with this user profile, she will have access to anything that the Web server does, potentially allowing her to change, delete, or copy documents that your Web server uses.

User profile QTMHHTP1 is the Common Gateway Interface (CGI) HTTP Server profile. This user profile is similar to QTMHHTTP, but, instead of being used to serve documents, it is used to run CGI programs on your AS/400. If user profile QTMHHTP1 does not have authority to run a specific program on your machine, then someone from the Web cannot run the CGI object, possibly causing big problems. This user profile has the potential to cause more harm than the QTMHHTTP user profile simply because it is used by the HTTP Server to run programs that can access other objects on your machine.

When setting up security for your AS/400 Web server, it is a good idea to make sure that you do not simply take the easy way out and grant *PUBLIC user authority to documents and CGI programs. Instead, take the extra time to make sure that the appropriate user profiles, QTMHHTTP for documents and QTMHHTP1 for CGI programs, are the only user profiles with authority to these other than your security administrator profile. Granting *EXCLUDE authority to *PUBLIC is a very good idea as well. The reason for this is that it will not allow user profiles to have authority to Web documents unless you specifically grant it to them.

PASS Directive

The next step in securing your Web server is using the HTTP directives in your configuration files as they were intended to be used. You should do this to keep people out of directories and libraries they aren’t meant to be in. The two main directives to worry about are PASS and FAIL. However, if the PASS directive is used with careful planning and execution, the FAIL directive shouldn’t be needed.

The PASS HTTP configuration directive is used to tell your system which directories, files, and libraries a person browsing your Web site is able to view. It’s a simple yet brilliant method of security: Tell the system where a user can go instead of where he can’t go. For example, the following PASS directive will allow access only to the /html directory of the AS/400 Integrated File System (AS/400 IFS):

PASS /html/*

In consulting with people setting up their HTTP Servers, I am finding one thing that is fairly consistent: Security has become as relaxed as it was in the days when the only problem was keeping employees out, and the same bad habits, such as granting *ALLOBJ authority to every profile, has spread to the Web server. The administrators have all the intentions in the world of “going back and changing it when it’s working,” but you know how that goes. Sure, it was easy to simply grant *ALLOBJ authority to users so that security setup wasn’t difficult, but it is even more important that you not use these methods when setting up a Web server.

What I am seeing is people using the following PASS directive:

PASS /*

This directive says to the HTTP Server, “You can access anything on my machine that you have object authority to.” This includes all directories, folders, and libraries! The combination of this directive and the dangerous *ALLOBJ authority for all user profiles spells one thing: danger. Even the IBM HTTP Server for AS/400 Webmaster’s Guide V4R4 specifically states that this is a big no-no.

Of course, administrators don’t mean to create such risk; it is simply easier to do things this way to get things working. You are all extremely busy now that the post-Y2K projects are underway, and you may think you can’t afford to research setting up security correctly on your AS/400. But answer this question: Do you have the time to recoup losses and destruction that could have been prevented by an extra day of research and setup?

Step Two: Using Logs to Track Down Hack Attempts

Other often-overlooked pieces of the AS/400 HTTP Server are the logs that your system creates when you tell OS/400 to start logging HTTP. These logs are most often used to find out how many hits you are receiving, but they can also tell you whether anyone is snooping around your system to try and find a back door.

The AS/400 allows two major types of logs: access and error. The AS/400 also allows you to store these logs in one of two formats. The first is the familiar DDS format, in which the logs are stored in a physical file in a library on your system. The second is the “common” log format. I find the latter much more useful. In fact, when I started using the HTTP Server and the logs in particular, I quickly found that the DDS log format was almost useless in my case. Sadly, DDS is the default, so, if you do not specify the common log format in your HTTP configuration, you will get the DDS format. The reason I find the common log format more useful is that it is “common” among other platforms and is stored in a directory of the AS/400 IFS. This means that tools used to build reports from this common format on other platforms can also be used with the AS/400. So my first piece of advice in logging is to specify the common log format and store the logs in a directory that only the system administrator has access to.

Using these two access logs can work to your advantage in helping track down possible attacks on your system. The access log will show you which files were accessed. This technique is used mainly to see which items people are viewing on your site. The error log, however, is used to report to you files that people were denied access to. Also, the IP address of the person trying to access the files, as well as the referring page, comes in handy when tracking down potential problems.

Figure 1 (page 77) shows an example of entries in an error log for a file. Someone tried to gain access to it, but the HTTP Server wouldn’t allow it, either because it didn’t exist or because the person didn’t have authority. The first log entry shows that an error occurred for a request for the document /info.html. The entry occurred because this document does not exist on the server. The second entry, for file /sales/monthlysales.html, occurred because this page was password-protected and the user entered an invalid user ID and/or password. Notice that this entry also shows the referrer of the document. The referrer is the page that the user was previously on before trying to access the protected document. This information can be a clue in some cases as to where people are learning of this protected document. For example, a hacker may have a site with links to your private data.

An even more interesting error log is one made when the AS/400 detects what it thinks is a denial-of-service attack. Figure 2 shows how the entry in the error log will look. Important things to note are the time at which the system perceived the attack and the time at which it ended the connection. In this case, the two events were 20 minutes apart, which is

the default used when specific entries are not used on the DoS HTTP Configuration parameters (which I will explain in the next section). There are usually more clues included in the log to help you decide whether it really was a DoS attack. For example, if you have files on your system for people to download and, for some reason, the download process takes more than the allotted 20 minutes, the HTTP Server will consider this a DoS attack in some cases.

It is best to view and examine your logs frequently. In particular, viewing the error log will give you clues as to whether anyone is attempting to cripple your server or access files for which she does not have authority. Finding a good program to report the data in the access logs will help your cause as well. There are many such programs available on the Internet that will work with the Common access log format. One tool I found that worked very well is called SurfStats Log Analyzer and can be found at www.surfstats.com
.

Step Three: Controlling DoS Attacks

DoS attacks have been a big part of the news lately. Basically, a DoS attack is a user or group of users flooding a particular Web server with useless data, slowing the machine or bringing it to its knees. This usually causes many headaches for the system administrators, not only in getting their sites back up and running but also in trying to track down the culprits.

The AS/400 may have a slight advantage over other Web servers in the DoS arena. Most PC-based Web servers are just that, used solely for serving a Web site. The AS/400, on the other hand, is a multitasking machine that runs (or can run) multiple types of servers as well as your day-to-day business. The AS/400 can run a mail server, a Web server, a file server, an FTP server, and your inventory software all at once. The machine and the operating system were designed to do this, unlike a PC machine, which was and, in my opinion, still is designed to serve a single user and a single operation.

Each server type on the AS/400, whether it is an email server or an HTTP Server, runs with its own set of jobs, separate from everything else. This separation is the first defense against attacks designed to bring down a system. At worst, a DoS attack on an AS/400 will slow down the machine and possibly end the HTTP Server jobs that are processing the attack. Unlike a PC that devotes all its processing to one function, an AS/400 splits its processing power between multiple jobs. Even the default settings that come loaded on your machine will end the connection with the perceived DoS attack.

But if you find that your AS/400 needs some tweaking in recognizing a DoS attack, there are three configurations that you can use. These are penalization, detection, and trust. These settings are controlled by HTTP configuration directives. Figure 3 shows each directive, a short description of it, and its default setting if it’s not specifically used in your HTTP configuration.

Penalization

Penalization, determined by the DenialOfServicePenalty HTTP configuration directive, is used to limit the effect that a perceived DoS attack will have on your system. There are two parameters used on this directive: Percent and Time-value. They are specified in the following form:

DenialOfServicePenalty percent time-value

The Percent parameter tells the system the percent of the server’s threads that a hacker is allowed to use. As you may know, you can specify a minimum and a maximum number of threads to start processing requests to your Web page. Each thread (or job) is used to process a request. If a particular thread is processing a request when another request comes to your server, your system will use the next available thread to process it. If

all threads are currently in use and the maximum number of threads has not been reached, a new thread will be started to process the request. The minimum and maximum number of threads can be set for each HTTP Server instance using the Change HTTP Attributes (CHGHTTPA) command if the instance is set to use the global parameters, or each instance can be set specifically with these values using the HTTP Configuration Web pages. The value *NOMAX is allowed for the maximum number of threads setting, but using it is probably not a good idea, because, in theory, the setting will make DoS attacks even more dangerous. It is a good idea to keep track of your Web site’s activity and adjust these settings accordingly.

The Time-value parameter is used to specify the amount of time a hacker is limited to. In other words, this is the amount of time that must pass after the last timeout before a hacker has access to the server threads again. If your server determines that a DoS attack is taking place and ends the connection, the hacker will not have access to your server again for this amount of time.

Detection

Detection, determined by the DenialOfServiceDetection HTTP configuration directive, is used to specify the number of timeouts that are allowed within the specified amount of time. The HTTP Server has three types of timeouts. These are input, output, and script timeouts. For a more detailed description of these timeouts, see the section on this directive in the HTTP Server for AS/400 Webmaster’s Guide V4R4. One thing to keep in mind is that you may not need to use this directive on your AS/400 if you are using a firewall or router that has DoS detection. This is because requests will all be coming from one location (the firewall or router) and the HTTP Server may misinterpret requests from that one location as a DoS attack.

Trust, specified by the DenialOfServiceTrusted HTTP configuration directive, is used to specify the locations or IP addresses of known firewalls or routers that should not be considered for a DoS attack. This directive allows you to set up your server so that false detection of DoS attacks does not occur if you are using a firewall or a router in front of your AS/400 Web server.

It may take some time to fully understand how these three directives work together to protect your system from a DoS attack, and you may find you need to do some tweaking if you have a slower connection and are allowing downloads of large files. Checking the error logs will help you determine which attacks are real and which are not.

Still a Step Ahead

You’ve grown to expect great things from the AS/400, and security is just one of those things that make your platform of choice a step ahead of the rest. Its sometimes-frowned- upon proprietary architecture makes it more secure than the average Microsoft Windows NT or UNIX platform. What people often forget is that this ambiguity makes it harder to hack. Also, by using a few easy steps and taking a little extra time to set up security when using your AS/400 as an HTTP server, you can rest assured that, while the others are fighting attacks, your AS/400 will be running your business smoothly.

References and Related Materials

• e-RPG: Building AS/400 Web Applications with RPG. Bradley V. Stone. Carlsbad, California: MC Publishing Co., 2000

• HTTP Server for AS/400 Webmaster’s Guide V4R4 (GC41-5434-04, CD-ROM QB3AEO04)

Trust

• OS/400 Security—Reference V4R4 (SC41-5302-03, CD-ROM QB3ALC03)

• SurfStats Web site: www.surfstats.com

[11/Feb/2000:04:48:28 +0000] [MULTI FAILED] [host: xxx.xxx.xxx.xxx] /info.html
[11/Feb/2000:12:19:53 +0000] [NOT AUTHENTICATED] [host: xxx.xxx.xxx.xxx referer: http://www.site.com]
/sales/monthlysales.html [11/Feb/2000:18:34:48 +0000] Denial of service attack detected from IP -nnnnnn
[11/Feb/2000:18:54:49 +0000] Denial of service attack ended on IP -nnnnnn

Figure 1: The file error log records entries when someone tries to gain access to a file but is denied by the HTTP Server.

Figure 2: This error log entry occurred when the AS/400 detected what it thought was a denial-of-service attack.

Directive Description Default Value

DenialOfServicePenalty The penalty you wish to impose on a 10 percent of maximum active

DoS attack that your server detects threads and 20 minutes DenialOfServiceThreshold The number of timeouts that are Five timeouts and 1 minute allowed in a certain amount of time
DenialOfServiceTrusted Specifies trusted or well-known IP None addresses, routers, or firewalls that should not be considered in a DoS attack

Figure 3: You can use three configuration directives to improve your AS/400’s ability to recognize a DoS attack.