Xinet Security Overview

The Web presents a unique set of trust and security issues that businesses must address to minimize risk. The purpose of this chapter is to educate end users and integrators about the real risks related to doing business on the Internet. Included are suggestions for securing your Xinet server to decrease the likelihood of a successful “hacker” attack.

There is a lot of misinformation and hype about hacking (or cracking to be more precise). Sensationalism from the news media and Hollywood turned the issue into one of magical and mystical proportions that does not accurately reflect what is really going on in the real world.

Hackers are usually after one of several things:

•

Access to a system that will allow them to cover their tracks when hacking other systems. This is usually about finding open e-mail systems to forward e-mail anonymously, or opening proxy servers to anonymously forward their HTTP requests, or locating an open FTP server to deposit pornography or pirated software to share with others.

•	Access to a system to provide a platform to launch a denial of service attack against someone else.

•	For the thrill of beating someone’s security and just having a look around… and possibly finding credit card information.

•	Industrial espionage. This one is very hard to harden your site against since these attackers have big budgets and state of the art equipment and tools. Most industries and companies will have very little to worry about from this kind of attack.

Remember that most hackers probing your defenses will be “script kiddies” or other amateurs that are just looking around. These people can be stopped fairly easily since they will not spend any time poking at your system if their initial probes show you have spent the time to plug the obvious and common security holes.

You do not need to be afraid to connect your servers to the Internet. Just do your homework, read all the documentation, and follow the guidelines below and statistically you will reduce your risk to nearly zero. Remember that no security system is impenetrable, so you still need to make plans for the worst-case scenario.

Some groundwork: Anatomy of a Web transaction

Definitions:

•	URL stands for Universal Resource Locator. A URL Consists of 2 items: protocol and location

•	DNS stands for Domain Name Service

Protocols can be one of the following: http://, ftp://, nfs://, afp://, https://, etc. The protocol can also contain a port number, but the well known port number of the requested service is assumed if no port is specified. An example of a port number is http://www.foo.com:8080. In this case 8080 is a custom port number to which an http service is attached. More about this later.

For example, the location: www.foo.com/test/mypage.html consists of the DNS name of the server and a relative path to the requested file.

What happens when a user enters a URL in a browser?

1.	Client does DNS lookup of location part of URL to determine IP address.

2.	Client connects via TCP/IP to the server and sends HTTP request.

3.	Server analyzes the request, checks credentials, then reads files from local storage and sends first MIME header and then data.

4.	Server makes a log entry of the transaction and may do a DNS lookup if the client receives the data. It also formats it for the user or calls a helper application based on the MIME header.

What does destination port number XXX mean?

A connection consists of the pair of IP addresses that are talking to each other, as well a pair of port numbers. The destination port number often indicates the type of service being connected to. This section describes some of the meanings of these port numbers.

Port numbers are divided into three ranges:

•

The Well Known Ports are those from 0 through 1023. These are tightly bound to services, and usually traffic on this port clearly indicates the protocol for that service. For example, port 80 should always be used for HTTP traffic. On Unix systems these Well Known Ports can only be accessed by processes that are owned by root. This prevents user-level processes from impersonating these services and hijacking them.

•

The Registered Ports are those from 1024 through 49151. These are loosely bound to services, which means that while there are numerous services “bound” to these ports, these ports are likewise used for many other purposes. For example, most systems start handing out dynamic ports starting around 1024.

•	The Dynamic and/or Private Ports are those from 49152 through 65535. In theory, no service should be assigned to these ports.

If you would like a comprehensive list of these, on any Unix machine (OSX, Sun, SGI, Linux) you can open a terminal and type > more /etc/services.

In order for someone to gain access to your system, there must be something listening to a port that can pass command and control information or can be used to transfer the contents of a file to or from the server. Examples include telnetd and ftpd, both daemons that listen to ports. It is very important that all unnecessary daemons are turned off. It is also important that any necessary daemons like Apache’s httpd be configured correctly.

None of the Xinet CGIs can pass command or control information to/from the native OS via httpd. As an added security feature, the CGIs are also specifically designed to be incapable of accessing sensitive configuration or password data. Remember, systems are “hacked” by exploiting a weakness in a CGI or in the Web server itself to get information about the system’s configuration that would allow an attack through a bidirectional link, such as a terminal session. If all those bidirectional links are closed, they can’t be exploited even if someone were to somehow get a password for the system (perhaps from those pesky users who put their passwords on stickies on their monitor or use easy to guess passwords).

Authentication

Note: For a smoother user experience, higher security and easier integration with Third Party software, we recommend using SAML2.0 based Single Sign On (SSO) support. See Set Up the Xinet Server to Use SAML2.0-based Single Sign On (SSO).

The biggest security weakness in any system is usually its users. Therefore an important line of defense is choosing and enforcing a good password policy.

Let’s take a look at Basic Authentication, the most common authentication mechanism in use today. When a user’s browser asks a server for a page, the server matches the URL against a list. If there is a match, the server sends the browser a “realm” to which the client must authenticate. The browser displays this realm string and prompts the user for a username and password that is valid in the given realm. The browser then passes this username and password back to the server in clear text when it retries the original request. (The username and password are obfuscated with Base-64.)

There are several other authentication schemata that you can use including Kerberos and LDAP. As Xinet uses the built-in Apache authentication, whatever method you implement should work but you must test it first as Xinet can’t qualify every possible combination. Using a third-party authentication module rather than just Basic Authentication will allow you to increase authentication security. The reason for this is that they often support stronger encryption algorithms including the ability to use biometrics and smart card input from client-attached modules. Using an authentication module such as mod_ldap will allow you to centralize the authentication for all of your network services.You may also wish to consider using SSL for the target realm to ensure that the authentication is encrypted when it is passed to the server.

The URL to an https connection looks like this:

https://www.foo.com/webnative/listdir