Chapter 23

Intranet Security


CONTENTS

Intranet security means not only keeping unauthorized users from reading, changing and deleting company information. It also means keeping employees from wasting time on the Internet and also from making the company look bad by posting sensitive or inappropriate information.

There are, fortunately, some things that can be done to improve the security of your Intranet. These are both technical solutions and policy decisions that can be put in place to help make things safer and more productive.

In this chapter, we will learn:

Security and Access Policies

One of the most important-and most overlooked-part of implementing network security is to have a written policy. A policy is a document that describes what you are trying to protect and what you are trying to protect it against, as well as describing what should and shouldn't be done over the network. Having a policy allows you to measure how effective any procedures you have implemented are. Policies also help explain to users and management why some things need to be done differently or not at all.

Writing polices is not easy and this book will not go into detail on how to do it. We will discuss generally what needs to go into a policy and discuss where to get some sample polices.

Writing Policies

Writing policies is a complicated task because it requires keeping ideas general enough to be flexible but specific enough to be useful. There are normally two different parts to the policy. The first part is the security portion, which describes what needs to be protected and how to protect it. The second part is the access part. This part describes what can be done over the network.

The first step in writing the security portion is to define what needs to be protected. This is the hardest part to determine because most users don't know what they use or how important it is. It is often better to work with each group, determine what they use for files and programs, and compile a list of who uses what.

CAUTION
When writing the policy, you should not use specific filenames because they may change. Instead it should be kept general, such as a statement reading "Payroll files should only be viewed or changed by payroll employees." Keeping the model general allows flexibility and changes to occur without having to rewrite the document.

Next you need to determine who shouldn't be able to get to what. Often security is implemented in layers or tiers. The top tier is for very sensitive machines such as those that create accounts or that enforce security. This could be the NT domain controller, NIS master, or Kerberos master. The NT domain controller handles security and accounts for NT based networks, while the NIS master and the Kerberos master handle accounts for mainly UNIX-based accounts.

The second tier of information should be allowed to be changed by only certain groups. It may need to be viewed by more than one group. Define what those groups are and what access they need.

The third tier is usually readable by everyone and writable by only certain groups. The last tier is information that can be written or read by everyone. The Internet usually falls under one of these tiers. Some companies may only allow certain people or groups of people to post information. This helps to eliminate inaccurate information from being sent out from the company.

NOTE
This security model does not specifically deal with the accesses from the Internet. It is assumed that Internet users can get access to the network, and any document that is readable by everyone can be read by these users as well. Hopefully this is not true, but if you assume it is, then you can prepare for it.

Once the part of the policy describing who can change what files is determined, usage is usually discussed. An example might be a section determining that passwords are required, must be hard to guess, and also that passwords should not be given to anyone or written down. It is common to refer to other documents that explain password procedures or other site specific requirements. This allows specific requirements to be documented and changed without having to rewrite the security policy.

Once the access policy is determined, it is common to put in a section describing what will happen if it is not adhered to. This is often a touchy issue and it will be necessary to get the personnel department or manager involved as well as legal assistance.

Once the policy is written, it should be reviewed by either a lawyer or a legal department. Upper management needs to be informed of what the policy means and how it needs to be enforced. If upper management doesn't understand or agree with the security policy, it is not useful.

Sample Policies

Policies are general guidelines, and it is common for a template policy from another company or institution to be used as a guideline. Sample policies can be downloaded from the following sites:

Again these policies are guidelines and may not describe the requirements of your specific site. They should help explain how the document should be worded and what should be included.

Policy Pitfalls

When writing policies it is important to use careful wording and expressions. In case of disputes, this policy may need to be taken into a court and it should be reviewed by a legal department or lawyer who understands computer laws.

One of the important things to remember when writing either this policy or the security policy is to be consistent in everything you allow or deny. For example, if the access document says no access to online stock quotes, and one of the upper managers has access, then your policy is no good. There should be a way for someone to get access, even if it will not be allowed. A good way to do this is to have a clause that says "No access to online stock quotes without permissions from _____". This allows some people to have it and not others.

Employees' feelings must also be taken into account, especially in companies where employee morale is important. Improper or harsh wording can cause employees to feel "Big Brother" is watching and may get bad feelings about the company. This is not to say that employees should be allowed to do whatever they feel like on the Internet, but a little trust can go a long way.

User Education

One of the most important steps in allowing employees to access the Internet or Intranet is to teach them how to use it. There should be a document or required training class that employees must take before being unleashed on the Internet. This class or document needs to cover a few issues. Among them are:

If the document, or class, covers these basics and teaches the users how to act responsibly on the Internet, many problems can be avoided.

A good example to show employees that what they post is reflected back on the company is to search one or two of the major search engines for the company name and see what comes back. Everyone might be surprised!

Accountability

In our list of topics users need to be educated on, we mentioned accountability. This can be used to help deter employees from spending too much time on personal projects.

Many companies have logs files that contain statistics on user accesses. These may include:

CAUTION
Filenames and destination ports may be misleading. Files can be called anything and do not have to end in particular extensions if the server is configured properly. Servers can also be configured to run at non-standard ports


Many sites institute a billing procedure to hold departments accountable for supplies, and consider billing for network bandwidth. This will at least have the effect of allowing management to see who is using the bandwidth.

Other sites have a "Top Ten Users" or "Top Ten Sites" list. Employees don't want their managers to see their names on the top ten users connecting to www.wastetime.com, and may limit their usage.

Using accountability to convince employees not to abuse the Internet is usually better than trying to use technical tricks to block certain accesses. It often allows for better employee relations since the company is showing that they trust their employees not to waste time, and are only trying to keep track of where the bandwidth is being used.

Security Through Obscurity

One of the easiest ways to prevent casual users from accessing your Intranet is to make it hard to find. This will not prevent someone who is trying to break into your site, but it may keep out some people.

Security through obscurity isn't real security. It is more like camouflage and, like camouflage, once your site is seen it is extremely vulnerable. Obscurity is a good way to make intruders spend time poking around and hopefully do something to set off alarms and alert someone that they are trying to get in. The best defense, though, is to use a combination of security measures, such as server security or firewalls, in conjunction with obscurity. Hopefully this will alert you to intruders knocking at the door before they can get in.

There are a few ways to hide your Intranet. The following ways are covered in detail in the next few sections:

Using Non-Standard Ports

Using non-standard ports is one of the easiest ways to hide your site from prying eyes. Most Web servers have a simple configuration that allows the administrator to change which port to listen on.The default port is 80. Changing the port from 80 to something else will make it harder to find.

Changing the Port Number with Apache

Changing the default port is fairly easy to do. For Apache, there are two ways to do this-depending on how it is run. If you run Apache via inetd, then you simply need to edit /etc/inetd.conf and change the port to something other than 80. Then restart inetd by sending it a HUP signal, for example kill-HUP pid (pid stands for Process ID number).

If you run Apache from a startup script such as rc.local, you need to edit the httpd.conf file, which is usually found in the httpd/conf directory. There is a line in this file that contains a port directive. By default it uses port 80. Simply change this to a different port and restart HTTPd.

Changing the Port with Netware Web Server

Changing the port for Netware Web server can be done using the Web server manager program. Simply choose file and select server. Type in or select the drive that has the Web server tree mapped to it. Change the TCP port number to something other then 80. Next click OK, and then click save and restart. Enter the Web server password when prompted and click OK.

Changing the Port with Netscape Server

To change the port in Netscape enterprise server, you need to use the server manager program. You can start this process by running start-admin and then pointing a forms capable browser at http://intranet.server.name: aport/. Intranet.server.name is of course the Intranet server, and aport is the administrator port.

Your browser should come up to the administrator server page. Go to the line under Global URL Configuration that lists Server Port Number and change it from 80 to a different port number. After you submit the form and restart the server it will be running at the new port.

Using Hard to Guess Names

Most companies want people to be able to find their Web sites so they usually name them www.company.com. This also makes it easy to remember.

However, there is nothing saying that the Web server has to be called www.company.com. It can be named something as obscure as udu33rf.company.com. There is not much of a chance of someone guessing a name like that.

Hiding Your Server's Name

Using a hard-to-guess name is useless if it is listed in the Domain Name Service (DNS), or shows up in public access logs. This section discusses how to setup your machine so it cannot be found easily.

NOTE
DNS is the system that allows machines on the Internet to know who they are talking to. It is a hierarchical, distributed naming system that allows each site to maintain its own list of hostname to IP address mappings. DNS stands for Domain Name Service.

Hiding Via Separate Name Servers

Some sites run separate internal and external name servers to allow internal machines to connect to the Intranet server by name, but not give out information to the rest of the Internet.

Basically it works like this. When an internal user wants to talk to a machine by name, queries go to the internal name server, which does one of two things. If it is a local machine, it replies with the correct answer. If it is an external machine, it queries the external name server to resolve it.

External users can only connect to the external server, which doesn't know about all the internal machines. Because it doesn't have internal names listed, it reports back an error whenever someone asks for them.

Setting up and maintaining two separate name server machines can be cumbersome and costly. Experts disagree on whether running separate name servers gains anything or not, but all experts agree that simply hiding your Intranet is not enough to protect it.

Keeping Your Name from Other Sites' Log Files

It is also important to keep your server name from appearing in other sites' access logs. Some sites don't adequately protect their access logs from being read from Internet users and this can allow your hard-to-guess name to be found out.

The best way to keep your server's name out of other sites' access logs is simply not to use it for Web surfing, Usenet posting, sending e-mail, or any other Internet access.

Whenever someone connects to a Web server it makes an entry in the log file. Some sites, either on purpose or by accident, make their log files publicly readable. If you use your secret Web server for browsing, it might get listed in one of these public log files and get indexed at a search engine site. All a hacker has to do is connect to a major search engine and search for yourcompany.com and look for strange names.

The same is true for Usenet postings and e-mail lists, which are usually archived on a Web site and indexed. It makes sense to occasionally search for your company name on search engines, to check for security problems such as this.

Pitfalls with Security Through Obscurity

Unfortunately there are many programs available that can search for open ports on a machine or a range of machines. These port scanners are available for downloading from the Internet and can run very quickly. In TCP/IP there is a limit of 65,535 different port numbers that can be used so it is not very hard for a hacker to scan all the ports on a host and find any hidden servers.

NOTE
Port scanning software is a hacker's friend, but it can also be a network manager's friend as well. Port scanning software can detect unauthorized servers running that can cause security problems. Port scanners are available from several places, including "strobe" from ftp://suburbia.net/pub/ and "netcat" from ftp://avion.org/src/hacks.

It is possible to booby trap your machine to catch people running port scanning software. You can set up dummy servers that report when someone connected to them and where he or she connected from. Analyzing the logs from these servers may allow you to detect an attack before someone breaks in.

NOTE
TCP Wrappers (ftp://ftp.win.tue.nl/pub/security) are a set of programs written by Wietse Venema. They work by verifying and logging connection information before starting the server. For example, by setting wrappers around your httpd server you can detect what IP addresses have connected, if they really are who they say they are, and accept or refuse the connection. If it is accepted, then it connects with the Web server normally. (See figure 23.1.)
TCP Wrappers also can be used to set up dummy servers. They can be set up to send e-mail, send something to the printer, or send a page if someone tries to connect to a trapped port. Even if you don't need to set up wrappers around your servers, this notification feature makes TCP Wrappers worth downloading.

Figure 23.1 : TCP Wrappers checks the connection before allowing the server to talk to the client.

Using the Server Security

If simply hiding the site is not enough, what better defensive measures are available? Most WWW servers offer a layer of protection called access controls.

These access controls may be used to allow you to define IP address ranges that can retrieve documents from your Web server. Most Web servers also allow you to specify a username and password before allowing any documents to be retrieved.

These two ways of protecting the Web server from being abused and the problems with using them are covered in the next few sections. For specific server configurations see the chapter in Part II related to your Web server, or consult your Web server documentation.

There are two security models you can use to secure your Web server:

Security experts agree that it is best to deny everything and only allow in what is needed. This reduces the chance of the administrator overlooking something. In an Intranet it is better to deny everyone and allow local IP addresses, rather then try to list everyone who can't see what is on the Intranet.

CAUTION
Using the Web server security may stop a hacker from getting information from the Web server, but there are other ways to get information out of a machine, such as shared or exported drives. For more explanation, see the section on "Other Access Methods" later in this chapter.

Restricting by IP Address

Almost all Web servers have an access list that defines what machines or networks are allowed to retrieve documents or submit forms. This access list is usually made up of a list of allow and deny fields.

Using Apache, you can restrict access by IP address. This requires you to create a Limit directive in the access.cfg file. This file is usually in the httpd/conf directory.

The Limit directive should look like the following:

<Limit>
order deny, allow
Deny *
Allow 123.123.123.*
</Limit>

To deny access by IP address to the entire server using Netware Web server, you also need to edit the ACCESS.CFG file and add a Limit directive. The syntax will be the same as Apache uses. The ACCESS.CFG file is located in the \WEB\CONFIG directory.

Setting up access control for Netscape is done via the server manager page. Point your browser to the administration page. See the section on "Changing the Port with Netscape Server" for instructions. Go to the link under Access control labeled "Restrict access from certain addresses." This should bring up a new page. On this page you need to specify what resource you want to protect. To protect the entire server enter *. Then enter the IP addresses that are allowed access. This should be your local network number followed by an *. For example, if the local network is 123.123.123, then you would enter 123.123.123.* to allow all the hosts in your network to have access.

NOTE
TCP Wrappers also can be used to limit access to the Web server by IP address range. They can also be used to send an error message to external users notifying them of where the external server really is.

IP Spoofing

Restricting access based on the IP address of the requesting machine is a good start toward security; however, that security is only as good as the security of the IP protocol. The IP protocol was designed with ease of use, not security, and allows people to masquerade as other hosts. This is called IP Spoofing.

IP Spoofing is, in a nutshell, telling your machine to use someone else's IP address. This also requires some modifications to get the response to go back to the malicious site, but it can be done.

CAUTION
In some cases it isn't even necessary to get a response. For example, if a form automatically creates an account, then all a hacker would have to do would be to pretend to be a trusted host and send the URL to add an account to the Web server. Then simply wait for the account to be created. The hacker doesn't need to see a response; he just needs to be able to send commands.

IP Spoofing can be fixed using router access lists. All that is required is to tell the router not to allow any machines using your IP address in from the Internet. (See figure 23.2.) This way your Web server never sees the packets and doesn't have to worry about them. This won't work, though, if you are sharing your Web server with another company over the Internet because the hacker could pretend to be the other company.

Figure 23.2 : Routers can be used to prevent IP Spoofing attacks.

Usernames and Passwords

Using IP addresses as security protection is a good start but doesn't handle all cases. The most obvious case is when multiple people use the same machine but only one person should have access to your Intranet. This can happen if your users use Internet Service Providers (ISPs) to gain access when they are out of the office.

ISPs generally allow multiple people to log in to one machine or allow dial-up users to share an IP address. Either way it can be disastrous to a security policy based on IP addresses for access decisions.

In this case, it is required to use usernames and passwords. Most Web servers allow username security. (See Part II for specific server configuration information.) Setting up username security is covered in later sections.

When a user encounters a page that is protected, a box appears asking for username. After the username is entered, the password is required. Once the password has been entered, it is checked to make sure it is the correct one. If so, the document is sent to the user; otherwise, an error is sent back. Users usually only need to authenticate once per site, per session. Figure 23.3 shows a password prompt.

Figure 23.3 : Users are prompted for a username and password for secure pages.

One of the problems with username and password protection has to do with the HTTP protocol itself. HTTP sends text "in the clear," which means exactly as you type it. This would allow anyone with a network sniffer on a network segment your traffic goes through to see your username and password.

In Chapter 1we discussed HTTP as well as the secure versions of HTTP (HTTPS and SSL). Using these protocols or an encrypted link will protect against sniffers, however not all servers support SSL and HTTPS. Check the server documentation in Part II before trying to use this security feature.

NOTE
Using the Web server security only limits what files can be retrieved through the HTTP protocol. Other ways to retrieve files must be protected as well. For example, a hacker may be able to use anonymous FTP to get to the protected documents.

Configuring Basic Authentication

Using usernames and passwords with Apache requires editing either the Directory directive in the access.cfg file or the file .htaccess file in the directory you want to protect. The Limit directive needs to contain the following:

<Limit>
require valid-user
AuthName [Auth-domain] 
AuthType Basic
AuthUserFile [user-file]
AuthGroupFile [group-file]
</Limit>

The Limit directive is covered in more detail in Chapter 3 "Installing and Configuring HTTPD for UNIX."

Netscape's servers also allow username and password authentication. To enable it you will need to go into server manager and select the link under Access Control that reads, "Restrict access to part of your server through authentication." Follow the directions on this form. Once it is filled out and submitted you need to restart the server for changes to take effect.

Netware Web server allows either file-based authentication, like Apache, or NDS-based authentication.

To restrict server access, you must manually edit the global access.cfg file. Before the Limit directive for the DocumentRoot directory you must add the following three directives:

Inside the Limit directive you need to add a Require directive telling the server which users can have access to the directory. This can be a list of usernames or "valid_user". Using valid_user allows any user listed in the AuthUserFile to have access as long as he or she enters the correct password.

The encrypted file is created using the command pwgen. It takes as arguments the input file and the output file. The input file is a file containing usernames and clear text passwords. For example:

Rich:secret
Tom:quiet
Al:ring

After running pwgen and copying the encrypted file in ServerRoot (usually SYS:WEB) you should copy the unencrypter file to floppy disk and remove it from the system. This is added protection to keep the passwords from being accidentally discovered.

If you choose to use NDS passwords, you can use the webmgr.exe program to configure the access restrictions. To do this, perform the following:

  1. Start webmgr.
  2. Click File/ Select Server.
  3. Select the correct server directory (probably a drive mapped to SYS:\WEB).
  4. Select the Directory from the drop-down list. To secure the entire server select \.
  5. Select Directory Services from the Authorization list.
  6. Type the NDS context name that contains the user object that should have access.
  7. Select the user.
  8. Click Add to Authorized users list.
  9. Click OK.
  10. Click Save and Restart.
  11. Enter the Web server password and OK for your changes to take effect.

Microsoft IIS can also be used for username authentication. This can be done by opening the Web server properties box and selecting the service tab. Choose Basic under Password authentication. This will force users to supply a username and password. This username must be a valid account for the machine running IIS or in an accessible NT domain.

Other Access Methods

Earlier we mentioned other ways for hackers to get files without going through the Web server. This effectively gets around any security the Web server may be using.

Different operating systems have different ways to get files from the server, UNIX servers have FTP, NFS, TFTP, and others, while NT may have shared drives as well as FTP and TFTP. Netware users may also have FTP, TFTP, and shared drives. It is necessary to determine any way that a file can be retrieved from the server and protect against it.

TCP wrappers can be used to allow only certain IP addresses access to the servers that you know about, but there may always be a server you have missed. Hackers will, if possible, place servers running on high ports to allow themselves a way to get back in, just in case their initial break-in is discovered. Running port scanning software against your machines on a regular basis is a recommended practice to help catch these backdoor servers.

The other alternative is to place your Intranet server behind a firewall. This effectively blocks access to all services except the ones you allow. It is possible to use the other security models and disallow access to any servers that you know are bad, but you may miss some. It is always more secure to disallow everything and allow only what you know is needed.

In order to be sure all services are protected, the network must be told to refuse all connections and only allow through certain ones. This is a job for a firewall. Firewalls are covered in the next section.

Firewalls

Almost every company connecting to the Internet needs a firewall. The Web server software security is just not enough, because there are too many other ways to get information, such as FTP, TFTP, or shared file systems.

Firewalls are a system or group of systems that enforce a policy between two networks. In most cases one of the networks is the Internet; however, firewalls can be placed between any two networks.

CAUTION
Firewalls can protect against many types of attacks by limiting what sorts of protocols can be passed into the company network. However, a firewall doesn't solve all the security problems. User education is required to teach users about security problems such as someone calling them on a phone and asking for a password. Dial-in modems are also a major concern.

Firewalls are split into two different categories: network-level and application-level firewalls. Both have their strengths and weaknesses and it is possible, and often desirable, to use a combination of the two type of firewalls, depending on your security requirements.

Network-level firewalls look at the packet header and see where it is trying to connect to, it then decides if it can pass or not. Application-level firewalls look at the packet and decide what the packet is trying to do and whether it is permitted or not.

Network-Level Firewalls

Network-level firewalls are devices or systems that look at the IP packet header and decide whether the address and port are allowed to pass through or not. It does not look at the data portion of the packet and does not understand what is going through.

The most common network-level firewall is simply a router with an access list defined on it. Machines with two network cards can also be used using special filtering software.

Network-level firewalls are very fast, because they only have to look at the IP header to decide whether the packet can pass or not. Network-level firewalls are also transparent. Because they don't interfere with the packet, users don't need to learn any special commands.

NOTE
Because network-level firewalls pass traffic directly between the two networks, both networks must have valid Internet address ranges.

Network-level firewalls however have shortcomings. The logging they use is often not as sophisticated as application-layer firewalls. Network-level firewalls also don't understand what they are passing and can only refuse or deny the protocol. For more sophisticated logging, or finer access control, application-level firewalls are needed. They are discussed later in this chapter.

Benefits of a network-level firewall are:

Disadvantages of a network-level firewall are:

Router Access Lists

Many routers allow the administrator to define an access policy. These access policies tell the router what packets are allowed to pass and which ones are to be dropped.

A simple access policy would say:

This simple access list allows anyone to send e-mail to the mailhost (Rule 1), and allows customers to get to the external WWW server (Rule 2). It also allows people on the network 123.234.123 to log in to the machine mailhost. The most important line is the last one, which says no one else can get in.

Access lists can and will be much more complex than this. Some routers allow you to define what to do if a packet is refused, such as log the attempt to a host or printer. You can also use other keywords to allow traffic out from the internal network to the rest of the world.

Access lists generally can be placed on the external port, on the internal port, or both, depending on the router.

Allowing traffic to a specific set of machines is commonly referred to as a screened-host firewall. This means that traffic is allowed to a specific host or set of hosts but only if it fits through the screen. Our access policy is an example of a screened-host firewall. (See figure 23.4.) The machines that external machines are allowed to talk to are called bastion hosts. Bastion hosts are hosts that are secured to (hopefully) resist attack.

Figure 23.4 : Screened host firewalls allow certain types of traffic to a bastion host.

In addition to the screened-host firewall is a screened-subnet firewall. This allows a defined set of traffic through to an entire network. These configurations are covered in more detail later in the chapter.

Packet Filters

Packet filters are usually machines with two network cards running special software to allow or disallow packets based on their address and destination port.

Packet filters are similar to routers and can be used to build screened-host or subnet firewalls. Packet filtering software can be downloaded from the following sites:

Packet filter software is available for both DOS machines and UNIX machines and supports many different network cards. Packet filters are often used to act as firewalls because they can run on very cheap hardware. A 386 processor-based machine has more than enough CPU power for a 56 Kbps line to the Internet and can handle T1 speeds, depending on the exact configuration.

Application-Level Firewalls

Application-level firewalls are very secure hosts with two network cards: one set up on the internal side and one setup to run on the hostile side. This bastion host runs proxy servers for each protocol that needs to get through the firewall. This allows no traffic to pass between the two networks and the proxy must instead interpret and relay data back and forth.

Application-level firewalls must understand the protocol they are proxying for and thus can do very sophisticated logging and access controls. For example, a proxy for HTTP may be set up to allow getting pages but not images. It could also be configured to disallow running a CGI program as in figure 23.5.

Figure 23.5 : Application level gateways can be configured to disallow certain parts of a protocol. Here we allow GETtin pages but not POSTing scripts.

Benefits of an application-level firewall are:

The disadvantages of application-level firewalls are:

Address Translation

Because application-level firewalls relay messages instead of passing traffic through, they can be used as Network Address Translators (NATs). NATs are useful for IP networks that are using unregistered address ranges or reserved ranges.

NOTE
With the explosive growth of the Internet it was realized that there were not enough addresses for everyone who used IP to have a registered address. As a result, RFC 1597 was written. It advised setting aside different ranges of addresses not to be used on the Internet, but to be used only on internal networks. Of course some people who started out using reserved numbers decided to get on the Internet and now must use NATs to perform address translation for them.

Because the Internet is designed not to route traffic to any reserved IP address ranges, using them for internal networks can help to prevent attacks from the Internet. This added security is not without a cost, though, because every external connection may require a network address translator to work properly.

Proxy Gateways

Most popular applications have proxy servers written for them. For example, Trusted Information Systems (TIS) has written a firewall toolkit that contains proxy servers for rlogin, telnet, FTP, X-windows, HTTP, and NNTP (Usenet). These proxies understand the protocol and can be used to safely allow these applications through the firewall.

Whether or not you choose to allow these protocols into your network requires looking at the security policy and deciding if they are required. Just because a protocol can be safely allowed through the firewall doesn't mean it should be allowed into the networks.

For a proxy to work it must understand the protocol it is trying to proxy. This means new protocols may not have a proxy written for them yet. These protocols either need to be passed through a network-level firewall or a generic proxy, also known as application forwarders.

Application Forwarders

Application forwarders are sort of emergency measures for firewall administrators. They allow proxy-like support for protocols that do not have special proxy software written for them yet. Application forwarders are also called generic proxies.

TIS includes a software package called plug-gw, which allows any protocol to be forwarded through an application level firewall without having to use a special proxy package.

Plug-gw may not allow as fine control as a special proxy, because it does not necessarily know what the protocol is doing. It can, however, log connection attempts, times, and hosts. It is a sort of compromise between network level firewalls and full proxy support for a protocol.

Socks

Socks is a generic application forwarder that is often used to allow access out to the world. Using Socks allows IP connectivity to hosts that are normally blocked by a firewall. Socks basically accepts connections from the internal network and relays these connections to the Internet hosts. It also relays data back and forth after the connection has been allowed and established.

Socks comes in source code form and must be compiled for each server platform. Socks is fairly easy to compile and can be done in a short amount of time. You can download socks from ftp.nec.com/pub/security/socks.cstc.

Socks is supported for SunPS, Solaris, AIX, SCO, and Linux.

Firewall Configurations

Firewalls are configured in different ways, depending on how your company decides to balance the cost versus security issue. The most secure firewalls often use a combination of security layers to offer the most protection.

There are three types of basic firewall configurations in use today. They are:

Each configuration has a different tradeoff among between security, cost, and performance. For example, dual-homed gateways are easier to configure and set up then screened hosts, but at a slight loss in security.

Dual-Homed Gateways

Dual-homed gateways are hosts configured to support two network interfaces. One faces in toward the secure network and one faces out toward the hostile network. They are configured not to route traffic between them. (See figure 23.6.)

Figure 23.6 : Dual-homed gateways are built with two interfaces-one on each network. They don't allow routing.

The dual-homed machine is also called a bastion host. This machine needs to be as secure as possible, because it is the way a hacker will try to get in from the Internet.

The bastion host is the host that would normally run the external WWW server and FTP server as well as act as a mailhost for the Internet. It also will be the host that runs proxy servers for the users to get access to the Internet.

Dual-homed gateways are the cheapest of the three basic firewalls. However, they have one disadvantage over the other types of firewalls. They have a single point of failure. If any piece of software allows a hacker in, the entire network is exposed.

Screened-Host Gateways

Screened-host gateways are built using a screening router to block traffic to the internal network and to allow traffic to a bastion host. This host has one network interface as opposed to the dual-homed gateway that has two. (See figure 23.7.)

Figure 23.7 : Screened-host gateways are made up of a router and a bastion host.

Because most Internet service providers provide a router at the site, it is easy and often economical to use this configuration. Screened hosts have the advantage of being able to allow certain applications in to the network easily.

The ability to poke holes in a firewall can be a major disadvantage if the firewall administrator is forced to open holes for unsafe protocols.

Another disadvantage to screened-host gateways is the fact that this system relies on two separate security devices: the router and bastion host. If either of these fail, the network is exposed.

Screened-Subnet Gateways

A screened subnet is made up of two screening routers with the bastion in the middle. This makes a small isolated network between the secure and hostile networks. The bastion host sits in this isolated network. (See figure 23.8.)

Figure 23.8 : Screened-subnet gateways have an isolated network separated from both networks via routers.

It is possible to have multiple hosts in this isolated network, also called Demilitarized Zone or DMZ. This can help to alleviate performance problems.

This configuration is the most expensive but it is also the most secure because two devices need to fail to allow the network to be exposed.

Like the screened-host gateway, it is possible to poke holes through both routers to allow protocols in. This should only be done if the protocol is safe and there is no proxy available for it.

General Security

Many times network administrators put a firewall in place and assume that they are safe. However, this is very rarely the case. This is similar to putting a large steel door on the front of your house, and not paying attention to the glass windows scattered around the building.

Modems

Many companies have modems on their employees' machines. These can be for transferring files, connecting to online services, or might not be used at all. Many of these modems might be set to Auto Answer when called.

Auto Answer modems by themselves aren't a problem, especially on PCs that usually don't allow logins. However, UNIX machines are normally configured to allow remote logins on modem ports. This allows people in without going through the firewall.

UNIX machines aren't the only ones with remote capabilities, though. Many PC modem packages allow a remote user to take over a PC just as if he were sitting at the keyboard. This includes any network access that the machine may have.

Even worse than a login session is a PPP or SLIP connection. Many newer systems, such as Windows 95 or Windows NT, come with PPP software built in. It is possible for a user, knowingly or not, to enable this access. This allows the hacker to access any machine on the network virtually untraced.

It is important for a security administrator to be aware of these potential security holes. Hackers have access to many phone number scanners. These scanners work much like port scanners or network scanners. They start dialing numbers until they get a modem tone and then try to break in. Knowing which phone lines are connected to modems and securing them is as important as configuring a firewall.

Other Remote Networks

In addition to the Internet link, your company may have other remote networks that can be a source of attack. These may be something like Tymnet or Telenet, or a dedicated or dial-up link to another company.

Regardless of where these links go, you should always assume they connect to a hostile network and security should be in place on them. This may include a firewall or another safety device.

Physical Security

Physical security is usually not overlooked because this is the part of security most people are familiar with. Still some security teams spend more time looking for large-sized items rather then high importance items.

Many companies use 8mm or 4mm tape drives for backups. These tapes can easily fit in a shirt pocket. This is one way for data to leak out right past the firewall. Of course, employees need to be trusted to a point in any company.

Another problem can be unshredded confidential documents. One effective trick of a system hacker is to go trashing, which is basically going through a company's dumpster for information that may allow a hacker to get in. People often jot down usernames and passwords as well as telephone numbers and other security information. These notes often end up in the trash after they have been used. Shredding documents is a cost effective way of eliminating the usefulness of trashing.

If users and administrators understand the importance of securing the Intranet, many of these problems are taken care of. Having a secure Intranet can make the difference between people using the Intranet for work or for a toy. Making sure people realize they are accountable for the amount of time they spend on the Internet can also help to keep the Intranet from being abused.