Don Denoncourt tells the story of Hackeus, the world’s first hacker. Today, the spirit of Hackeus lives on the Internet. This article informs you of how to protect your AS/400 e-commerce site against the ingenuity of the modern-day Hackeus and contains violence and brief neutrality. It is not suitable for young audiences; programming supervision is advised.

Thousands of years ago, a man named Hackeus crossed a sea to gain access to an island fortress. Under cover of thick fog, Hackeus crossed those waters in a vessel captained by the sentinel of the island. He paid the sentinel with a single gold coin and, once upon the island, had to do battle with Cerberus, the three-headed dog. An ordinary man could not even get past the sentinel, much less defeat Cerberus, but Hackeus was no ordinary man. The gods had given him tools and magic that, coupled with his perseverance, enabled him to gain entry. When Hackeus finally came upon the treasure lair, he had to do battle, one last time, against Medusa, the strongest of foes. With a little ingenuity and the proper tools, Hackeus defeated this formidable foe. Did Hackeus take any of the treasure? No. Instead, he hacked off Medusa’s head and returned home. That’s how the term hacker came to be.

The moral of my story is that even the most impenetrable security can be defeated. Without the benefit of a three-headed watchdog, however, we must resort to other measures. With that in mind, securing your treasure trove within an AS/400 e-commerce application is best accomplished with a defense in depth approach similar to those in the story of Hackeus. Figure 1 shows a diagram of the layers of security required for AS/400 e-commerce. At the center of your security strategy is OS/400 security. OS/400 security is where the AS/400 really shines; it is our very own magic shield. Because of OS/400’s object-based architecture and object-level security, it is a highly secure platform.

OS/400 Security Recommendations

Full coverage of OS/400 security extends beyond the scope of this article, but I want to make five general recommendations:

• Set your AS/400’s security level (QSECURITY) system value to 40 or 50.
• Remove nonessential compilers and programming tools that might be used by hackers. (I assume that you are securing a platform that will be serving e-commerce applications and as such most development tools will not be required. You should also disable FTP and Telnet.)

• Enable Internet access only to those AS/400 objects that are part of your e- commerce applications, e.g., AS/400 Integrated File System (AS/400 IFS) files and directories and CGI programs and libraries.

• Do not require passwords for your e-commerce site.
• Isolate your host programs. The cleanest strategy for your e-commerce site is to design it to be an anonymous site. An anonymous site is one that does not require user profiles and passwords. That doesn’t sound very secure, so let me explain. The default configuration for the IBM HTTP Server for the AS/400 is not to require a sign-on. The HTTP Server then uses the default profiles of QTMHHTTP for HTML access and QTMHHTP1 for Common Gateway Interface (CGI) access. These profiles are extremely benign as shipped because neither has access to objects on your AS/400 until granted. The trick is to allow the lowest level access required.

Huge holes are often punched through Internet security with the ingenious use of CGI programs. Because CGI programs don’t usually use AS/400 IFS files, you must specify *EXCLUDE for AS/400 IFS Web directories with your CGI profile (QTMHHTP1). However, because CGI programs use the AS/400 library system (where our RPG and COBOL programs reside along our DB2/400 files), specify *USE for your required Web application and CGI libraries. Then, for your HTML profile (QTMHHTTP), specify *USE for your AS/400 IFS Web directories and files and *EXCLUDE for the Web application and CGI libraries.

TCP/IP Security Configuration

We may not have Cerberus at our disposal, but we do have the three-headed dog of OS/400 TCP/IP security, firewalls, and AS/400 IFS security. The AS/400’s TCP/IP configuration has many powerful security features that can easily be set up to enable a second layer of security. First, you can disable all the TCP/IP ports for those Internet applications that aren’t part of your e-commerce strategy. If you think of a domain name or TCP/IP address as a company phone number, think of TCP/IP ports as a list of extensions. If you don’t want spouses and friends calling your programmers, disable their phone extensions. (Figure 2 shows the list of standard TCP/IP ports.) One way to disable port access is to invoke the Go Configure TCP (GO CFGTCP) menu, select option 4, select the port, and qualify access to that port for specific users.

Another simple security strategy is to start only specific host and TCP servers. The Start Host Server (STRHOSTSVR) command should specify only required system servers. Start TCP/IP Server (STRTCPSVR) should start only required servers. Also, if your TCP servers start automatically, be sure to disable the startup of extemporaneous servers.

HTTP Server Security Configuration

The default configuration file for the IBM HTTP Server for AS/400 denies access to everything. Earlier, I said that you had to set the OS/400 authorities for default profiles to specific files, directories, programs, and libraries. Now, I’m telling you that, even with OS/400 authorities set, visitors still cannot access HTML files and CGI programs until you say so in your HTTP Server’s configuration file. There are four directives for allowing access: pass, redirect, exec, and fail. Use of these directives in the configuration file is known as the rules. You may have received “Access denied according to Rule” errors in your Web browser. Even though the file or program is available, you’re not allowed to access it because the HTTP configuration rules disallow it.

The pass directive is used explicitly to specify what directory and files are accessible. Keep in mind that those files can be HTML, Java classes, or images—anything that is requested to be served to the browser. Redirect simply redirects specific URL requests to other servers. The exec directive enables CGI program access for specific libraries. Finally, fail explicitly disallows access to files.

I keep saying “explicitly,” but, in truth, you can specify global access although it’s not a good idea. The proper strategy is to be specific about what directories and files are accessible. Also note that the pass and exec directives can hide the real name of file directories and CGI libraries so hackers have as little knowledge as possible about your system.

Secure Sockets Layer

The first thing Hackeus did after boarding that boat was to hand the sentinel a coin. Applications must also handle payments, but whereas Hackeus had fog and the integrity of the sentinel for protection, e-commerce sites need more. The Secure Sockets Layer (SSL) protocol enables the privacy, integrity, and authenticity that we require.

SSL uses an encryption technology that employs both public and private keys. The private key stays on the host, but the public key is automatically distributed to the client. A third party called a Certificate of Authority (CA) verifies the authenticity of transactions between client and host. You obtain a private key from a CA during SSL installation. Your clients don’t have to do anything to enable SSL except have a browser that supports SSL and your CA. (Figure 3 shows a partial list of the CAs supported by a popular Web browser.) As a client establishes a connection with your host, an SSL “handshake” is performed. This handshake verifies the authenticity of the connection by asking the CA if the host is, in fact, what it says it is.

Once the browser has established the validity of the secure site, e-commerce transactions can be completed successfully with minimal fear of the information being caught, captured, and interrogated.

Firewalls

The first step in Hackeus’ quest was to cross the sea. The only way was a vessel manned by the island’s sentinel. Like Hackeus’ sea, a firewall restricts users to entering and leaving from a single, controlled point. Firewalls prevent attackers from getting close to your other defenses. There are three categories of firewalls: packet filters, circuit filters, and application-level filters.

You can think of a packet filter as similar to the sentinel; it controls access by checking source Internet Protocol (IP) addresses and ports and destination IP addresses and ports against a list of packet filter rules that you must set up. Packet filters are fast but limited because they are not flexible. The simplest form of a firewall is a router, a simple device with limited packet filtering capabilities. Note that your Internet Service Provider (ISP) can be contracted to perform packet filtering.

For the most part, circuit filters control access from the internal network to the Internet, so I won’t cover them much here.

Application-level filters are implemented in a proxy server on a separate platform. Clients connect to the proxy server, not to the real host. The proxy then checks security using its knowledge of protocol specific to your Internet application. If the client request passes security, the proxy brokers the client request to the real host. Application-level filters are comparable to the image of Hackeus gaining access to an island on a boat: Both can be a bottleneck because of the single entry point. The AS/400 firewall is an example of an application-level filter. It resides on a separate platform, the Integrated NetFinity Server (INSA), “duct-taped” to the inside of your AS/400 for your convenience.

Protect and Proceed, Pursue and Prosecute

A vital component of any security policy that is often ignored is known as protect and proceed, pursue and prosecute. The first point of this fancy phrase is to protect your system and then proceed to log Internet activity. Most HTTP servers allow you to log

accesses and errors in separate files. You may opt not to log accesses, but you should always log errors. You also need to check those logs periodically for security violations. (Various of tools are available to automate this process.) In addition to HTTP logging, use OS/400 auditing for CGI programs. Finally, pursue and prosecute those security infractions. Pursue by increasing security to correct the hole, and prosecute by going after violators aggressively.

Three Firewall Strategies

Numerous firewall strategies can secure your e-commerce site, but their variations can be summarized into three types: simple firewall, dual-homed host, and bastion host. The simple firewall approach is nothing more than a single router, a black box that separates your host from the Internet. The router performs basic packet filtering.

The dual-homed host got its name from the two network interfaces it has for its two homes, the Internet and the internal network. Dual-homed hosts allow for advanced packet filtering because they are powerful computers configured with sophisticated firewall software. The IBM Firewall for AS/400, for instance, includes IP packet filtering; proxy servers for HTTP, FTP, Gopher, Telnet, and Mail; SOCKS server Version 5; DNS; and logging and monitoring for the AS/400.

The bastion host is a firewall that is nested between two routers. Bastion is a French word meaning a highly fortified projection on the outer wall of a medieval castle. You must get through the bastion before you can penetrate the fortress. Here is the path that an IP packet takes: It starts at the Internet then goes to the outside router (where basic packet filtering is performed). Then, it proceeds from the router to the bastion (where application-level filtering is performed). The next stop is the internal network router (where, again, basic packet filtering is performed), and the final stop is the host.

Hackers Are Not Mythical Heroes

E-commerce systems are too precious to discount the ingenuity of hackers like Hackeus. Today’s hackers may not have gods to help them, but nor do they need them because hackers can easily procure magic swords from the Internet itself to penetrate the defenses of your system. Protect yourself. Use your magic shields of AS/400 security effectively. Position your three-headed guard dog of TCP/IP configuration, firewalls, and AS/400 IFS security strategically. Use SSL to ensure the integrity and privacy of your transactions, and, finally, isolate your system with a firewall, lest your own head be hacked off (or worst yet, your company’s and customers’ information be hacked).

Related Reading

AS/400 E-commerce: Internet Connection Servers, Redbook (SG24-2150-00) AS/400 Internet Security: Securing Your AS/400 from HARM in the Internet, Redbook (SG24-4929-00)

HTTP Server for AS/400 Web Programming Guide, Redbook (GC41-5435-02) HTTP Server for AS/400 Webmaster’s Guide, Redbook (GC41-5434-03) Internet Standards and Protocols. Nalik, Dilip C. Redmond, Washington: Microsoft Press, 1998

Web Commerce Technology Handbook. Minoli, Daniel, and Emma Minoli. New York, New York: McGraw-Hill, 1997

Web Proxy Servers. Luotonen, Ari. Upper Saddle River, New Jersey: Prentice Hall, 1977

Secure Sockets Layer Firewall

TCP/IP Security OS/400 Security

HTTP Server Security

Figure 1: The best strategy for security is to have a defense in depth with as many layers of protection as possible.

Port Purpose

20 FTP data connection 21 FTP control connection 23 Telnet session protocol 25 Simple Mail Transfer Protocol (SMTP) 53 Domain Name System (DNS)
70 Gopher
79 Finger protocol
80 Hypertext Transfer Protocol (HTTP) 88 Kerbos authentication protocol
110 Post Office Protocol (POP3)
113 Remote identity service (IDENT)
119 Network News Transfer Protocol (NNTP) 143 Advanced e-mail (IMAP)
161 Simple Network Management Protocol (SNMP) 162 SNMP traps
194 Internet Relay Chat
280 HTTP management
389 Lightweight Directory Access Protocol (LDAP) 427 Server location protocol (SRVLOC)
443 Secure HTTP (HTTPS)
465 Secure e-mail (SSL)
535 Internet Inter-ORB Protocol (IIOP)
551 Secure money transactions (Cybercash)
563 Secure news (SNEWS)
636 Secure LDAP (LDAPS)
989 Secure FTP data connection (FTPS)
990 Secure FTP control connection (FTPS)
992 Secure Telnet (Telnets)
993 Secure IMAP (IMAPS)
994 Secure IRC (IRCS)
995 Secure POP3 (POP3S)
1080 SOCKS protocol circuit-level proxy

Figure 2: Ports with numbers below 1024 are reserved for servers that have standard Internet protocols.

Figure 3: Some of the most popular Web browsers support a variety of Certificate of Authority agencies.