MS BackOffice Unleashed

• Why You Need Security
  • Windows NT and the IIS
    • How the IIS Applies Security
• Placing Your Server
  • Firewalls
  • Proxy Server
  • Packet Filters
  • Network Protection Strategies
    • Allowing Anonymous Access
    • Requiring Usernames and Passwords
    • Other Network Services
    • LAN Internet Server Connections
  • Security Administration
    • Logging
    • Windows NT Performance Monitoring
    • Windows NT Auditing
• Secure Sockets Layer
• NetBIOS Security
• Service Message Block (SMB) Security
• Java Security
• ActiveX Security
• Catapult Proxy Server
• Stay Informed—Stay Secure
• Summary

— 18 —

Internet/Intranet Security

Security is the cornerstone of any successful computer system. Placing a system on the Internet or a corporate intranet can make system resources available to illegitimate as well as legitimate users. System security is always a balancing act of providing ease of access and usefulness to the legitimate users, while preventing access by the illegitimate users, which always involves a compromise. The most secure computer system is one that functions in isolation; placing a system on an Internet/intranet involves by definition placing the system on a network of hundreds or, in the case of the Internet, millions of other computer systems and users. Hackers are continually learning about potential security holes that exist in Internet sites and ways to exploit them. It’s almost impossible to completely secure an Internet/intranet server, but there are a number of measures that can be taken to decreases the risks involved. The most important steps that can be taken to ensure the most effective security for a Internet/intranet site are taking the necessary steps from the start of implementation and continually staying informed regarding potential risks.

Because businesses are setting up Internet and intranet sites in record numbers, ensuring the security of corporate systems is becoming increasingly important. An Internet Web server can provide access to corporate information to Internet users worldwide, whereas an intranet Web Server provides access to corporate data within a corporation. Although the security implications in the setup of an Internet server are slightly different from an intranet server, they are based on a few basic concepts: proper placement of the Web server, simplifying operations, and proper administration.

The Internet Information Server (IIS) and Windows NT provide a number of mechanisms to help ensure security:

• Windows NT Event Logging system is integrated with the IIS to help track usage and avoid potential problems.
  
  
• Windows NT Security, which has been granted C2 compliance rating by the United States National Security Agency, can provide secure access to files by requesting a username and password from clients before access is granted.
  
  
• The capability of setting up user accounts and directory permissions can help protect important data from unauthorized access.
  
  
• Internet Information Sever can use Secure Sockets Layer (SSL) when transferring data between the client and server. SSL provides a mechanism to encrypt the transmissions between the client and server, a mechanism to provide secure logons to the server, and mechanisms to verify message integrity.
  
  

Why You Need Security

When a computer system is connected to the Internet, it is open to numerous routes for potential attack by hackers, viruses, unauthorized internal users, and competitors, just to name a few. A server connected to the Internet can be accessible to millions of potential users, many of which may not have your best interests at heart. An intranet server can be just as vulnerable to attack from authorized users attempting to access unauthorized information. It may be even easier for an authorized user to exploit backdoors (undocumented methods used to access a host system) or unnoticed security holes.

Hackers who gain unauthorized access to the Windows NT administration account can cause a great deal of damage. They can execute programs, move, copy, or delete files, or access sensitive corporate data without ever leaving a trace. A hacker can attempt to crack an administrator's password by running applications that repeatedly generate login attempts by guessing random passwords until successful, or simply guess the administrator’s password because it is too common (for example, ADMIN). For this reason, it is extremely important to change the administrator’s password often, and to keep it complex so that it cannot be guessed at easily. A password is the first line in defense of a system, and since the administrator, and any other user with administrative privileges has the greatest system rights, it is of utmost importance to protect these accounts.

Here are some recommendations to follow when choosing a password:

• Don’t use the login name as the password.
  
  
• Don’t use your name or nickname, or your spouse's, children's, or friend’s name.
  
  
• Don’t use the server name.
  
  
• Don’t use your birthday or social security number.
  
  
• Don’t use a single word that may appear in a dictionary (a common hacking technique is to use a dictionary of words for passwords when attempting to break into an account).
  
  
• Don’t use a repeated series of the same number or letter—for example, AAAAA or 11111.
  
  
• Don’t write your password down.
  
  
• Do use numbers and alphabetic characters (upper- and lowercase) in your password.
  
  

Even proper passwords and user privileges may not be enough to prevent unauthorized access to sensitive information by a internal intranet user. An internal user may be able to gain access to restricted data by accessing an unsecured network workstation with administrative capabilities. From that workstation, users could access unauthorized data or change their own system privileges. It is important to educate users to practice due diligence in protecting their workstations from attack. Users logged into the network should not leave their workstations unattended, especially if that user has administrative privileges. All servers should be located in a secure area with only authorized personal granted access.

There are a number of high-tech mechanisms to help ensure system security. It is important to remember, though, that an effective security strategy begins internally. A system that takes all the appropriate measures to ensure proper file and directory protections, sets up a firewall and proxy server, and employs packet filtering can still be vulnerable to a low-tech attack of to someone guessing the administrator’s password or gaining access to an unsecured workstation.

Windows NT and the IIS

When planning security for the IIS and Windows NT Server, there are some major considerations to account for:

• Use of the NTFS file system is the only way to protect access to files on a user-by-user, file-by-file basis.
  
  
• Use the integrated Windows NT Event Logging and the IIS to track unauthorized access and detect security holes.
  
  
• Use IP filtering to prevent internal network users from accessing unauthorized sites, and to block users and groups from unauthorized sites from accessing your server.
  
  
• Use the Administrator account properly. Be sure to set up an account with limited authority to test new applications and prevent viruses. Because an account with Administrative privileges can access system files and directories, a potential virus could be easily spread throughout the system from these accounts.
  
  

How the IIS Applies Security

The IIS applies security using the following process:

1. The IIS receives a request for data.
   
   
2. The IIS verifies the IP is permitted; if not, access is denied.
   
   
3. The IIS verifies the user is permitted; if not, access is denied.
   
   
4. The IIS verifies that IIS permissions will allow access; if not, access is denied.
   
   
5. The IIS verifies that NTFS file system permission allows access to the requested file; if not, access is denied.
   
   
6. If all of these conditions are met, access is granted.
   
   

Placing Your Server

The most secure server is one that is locked up in isolation. Unfortunately, an isolated server is virtually unusable. A system that offers unrestricted access to its information can be the easiest to use, but obviously is totally insecure. A continual balance between security and usability must be maintained. Physical and communications barriers can be constructed to help prevent unauthorized system access.

A physical barrier is easy to construct. A server should be placed in a environment where only authorized personnel have access. A communications barrier can be erected by utilizing firewalls, proxy servers, and packet filtering.

Firewalls

A firewall is a computer system that bridges a trusted and untrusted network by examining incoming and outgoing packets and filtering out unwanted data. A firewall can prevent unauthorized external users from accessing the local area network (LAN) and can restrict how internal users access the Internet. A firewall can also be utilized to keep internal users from accessing internal servers to which they have no rights. A firewall can filter data based on an IP address so that only certain IP addresses can pass through the firewall. A firewall can also filter traffic based on a port number. Web servers usually use port 80; to prevent internal users from accessing external Web sites, a firewall could block access to port 80.

Proxy Server

When a request is made to a remote system and packets are exchanged, these packets can disseminate unwanted information about your server and network configuration, such as its IP addresses. A firewall alone cannot prevent this information from being released. A proxy server runs on the firewall host. It operates on a store-and-forward mechanism. Instead of each individual user connecting directly to outside Internet resources, a proxy server directs all requests and responses through itself. When a request is made to an external Internet resource, the proxy server examines the request and communicates with the remote system to satisfy the request. The only system the outside world "sees" is the proxy server.

Some proxy servers can cache often accessed external information to help speed up future requests. A proxy server can also log client requests, which can be useful to track and detect attacks against your server. The downside of running a proxy server is that it can degrade system performance, especially database queries.

Packet Filters

A packet filter examines all packets that pass in and out of the network, and can prevent packets from passing through that do not conform to the configurable rules that are defined. A packet filter can filter packets based upon several criteria:

• The protocol that the packet belongs to (TCP, UDP, and so forth)
  
  
• The originating address
  
  
• The destination address
  
  
• The port number of the destination resource (see Table 18.1 for port numbers of common services)
  
  
• The packet direction, out to the Internet or into the local network
  
  

The IIS can provide packet filtering of a specific IP address. To set up IP address filtering in the IIS, open the Service Manager applications and double-click on the server to configure. Click on the Granted Access button or the Denied Access button. If the Granted Access button is selected, you can specify which IP addresses you want to restrict. If you choose Denied Access, you can specify the IP addresses you want to allow. Click on the Add button to specify these exceptions. Click on Single Computer and specify the IP address you want to create an exception for, or click on Group Of Computers and enter the IP address and subnet mask to create an exception for a group of computers.

Network Protection Strategies

There are a number of measures that must be taken to help ensure the security of your IIS.

Allowing Anonymous Access

During the setup of the IIS, the user account IUSR_computername is created for anonymous access. If the computer name is IDCSERVER, the anonymous access account is IUSR_IDCSERVR. By default, all client requests to the IIS use this account. IIS clients are logged into the server using the IUSR_computername account. The IUSR_computername is only allowed to log on locally. The IUSR_computername is also added to the Guest group, if any changes have been made to the guest group, they will also apply to the IUSR_computername account. The Guest group privileges should be reviewed to assure their appropriateness to the IUSR_computername account. If remote access is allowed only through the IUSR_computername account, remote users will have the only permissions assigned to that account, which can help prevent hackers from gaining access to the server.

Requiring Usernames and Passwords

The IIS can also allow authenticated client access, which requires a valid Windows NT username and password to access system resources. The basic authentication mechanism provided by the IIS does not encrypt the username and password; they are simply encoded using UUEncode. They can easily be decoded by anyone who can intercept packets transferred over your network.

The WWW Service of the IIS supports the Windows NT Challenge/Response encrypted password transmission mechanism. The Challenge/Response mode can be configured by double-clicking on a specific service in the Service Manager application. On the Service tab, the Password Authentication mode can be selected. The only Web browser client that supports Windows NT authentication is the Microsoft Internet Explorer for Windows 95.

Both authentication mechanisms, basic and Windows NT-authenticated, allow access only when a valid username and password is supplied. Both IUSR_computername and authenticated access can be enabled at the same time.

Other Network Services

A thorough review of all services being run on the IIS system should be conducted to ensure the highest level of security. With a fewer number of services running on the system, the risk of an administration problem causing an exploitable hole is reduced. Using the Service applet in the Control Panel, review all the services that are currently enabled and running.

Using the Bindings option on the Network applet in the Control Panel, verify the services bound to the adapter connected to the Internet. The FTP Server services included with Windows NT Server should also be disabled. The FTP services in the IIS should be used instead.

LAN Internet Server Connections

There are a number of different ways the IIS system can be connected to the LAN and the Internet. Isolating the IIS system from the LAN offers the most security. Multiple adapters in a single IIS system running different protocols offers a high degree of security. A router with packet filtering can offer various levels of security depending on the model. Multiple adapters in a single IIS system, where each adapter is connected to a separate network can also offer a high degree of security, when routing is disabled. Each of the IIS system connection strategies offers different levels of security and usability. You need to choose the model that works best in your organization.

Isolation

In the Isolated configuration of the IIS system (see Figure 18.1), the IIS system is connected to a network separate from the LAN. To achieve the highest level of security, users connected to the LAN can be connected to the Internet through a firewall. The disadvantage of this configuration is that users who need to access the IIS system servers to update files or Web pages need to connect to one of the workstations connected to the IIS system network.

FIGURE 18.1. Isolated IIS system configuration.

Multiple Network Adapters Running Different Protocols

With multiple adapters in a single IIS system running different protocols (see Figure 18.2), each adapter in the IIS system runs a different network protocol isolating the LAN and Internet traffic from each other. The LAN can run any networking protocol supported by NT Server (except for TCP/IP); the Internet is connected using the standard TCP/IP protocol. This configuration addresses the main disadvantage of the Isolation configuration, because users who need to update files for access by the IIS can do so from their own workstations. The disadvantage of this configuration is that LAN users do not have access to the Internet. As long as the adapter cards are not configured for protocol conversion, this configuration offers a high degree of security. When setting up this configuration, it is important to ensure that the adapter card connected to the Internet is bound only to the TCP/IP protocol, and the adapter connected to the LAN is bound only to that protocol. Check the adapter bindings from the Network applet in the Control Panel.

FIGURE 18.2. Multiple adapters with different protocols in a single IIS system configuration.

Router Packet Filtering

There are a number of commercially available routers that can perform packet filtering (see Figure 18.3). These routers can be configured to filter packets according to predefined specifications. Some of these routers can offer proxy services along with packet filtering. Packet filtering is not as secure as multiple adapters with different protocols in a single IIS system.

FIGURE 18.3. Router packet filtering configuration.

Multiple Network Adapters Attached to Different Networks

With the multiple network adapters in an IIS system attached to different networks, each adapter can run the same protocol, but with routing disabled, the network traffic can be isolated (see Figure 18.4). Each adapter card can run the TCP/IP protocol, with each adapter being assigned its own IP address. The main advantage to this configuration is that LAN clients could use the TCP/IP protocol, allowing access by internal users to IIS resources. To set up this configuration, IP forwarding must be disabled for each network adapter. This can be done from the TCP/IP configuration dialog box by clicking on the Advanced button and then disabling the Enable IP Routing option.

FIGURE 18.4. Multiple network adapters attached to different networks configuration.

Security Administration

The IIS can be configured to log the activity of the Web Server. This information can be used to monitor the server, along with information provided by the Windows NT Performance Monitor, and Windows NT Auditing. This information can be used to track who site users are, when peak access times occur, and which services receive the most access.

Logging

The IIS can be configured to log activity. Log files can be created as standard text files or as part of SQL/ODBC databases. To configure logging in the IIS, open the Services Manager, then double-click on the server for which you want to enable logging. The Properties dialog box will be displayed. Click on the Logging tab of the dialog box. Click on the Enable Logging checkbox to turn on logging. Choose the Log to File or the Log to SQL/ODBC Database option. If logging to a file, click on the Automatically Open New Log checkbox to create a new log file every specified period. A new log file can be created on a daily, weekly, or monthly basis, or when the log file reaches a certain size, by selecting the appropriate radio button. Enter the name of the log file directory in the corresponding edit box. It's advisable to specify a secure directory in which to create the log file. The log file is named based on the following specifications:

Log Filename	Logging parameters.
SLOG.LOG	When the Automatically Open New Log option is not enabled.
Snnn.LOG	When the File Size Reaches option is enabled. The nnn is incremented sequentially each time a new log file is created.
Mmddyy.LOG	When one of the Daily, Weekly, or Monthly options is selected. Mm specifies the month, dd specifies the day, and yy specifies the year.

If the Log to SQL/ODBC Database option is selected, you can log information to a SQL database. It works best if Microsoft SQL Server version 6.0 or greater is installed. The Data Source Name (DSN) specifies the name of the database defined with a device for SQL Server or the filename of the database for Microsoft Access. Table 18.2 specifies the name of the database table the logging information will be appended to. Username and Password specifies the name and password of the user account required to log into the database.

The information in Table 18.2 is logged by the IIS system. This field definition information should be used to create the database table for logging.

The Service field identifies which service was accessed, W3SVC indicates the Web Service, MSFTPSVC indicates the FTP Service, and the GopherSVC indicates the Gopher Service. The Services Status Codes can be of different levels: 200 level codes indicate n operations successful, 300 level codes indicate data has been moved to another site, 400 level codes indicate client errors, and 500 level codes indicate server errors.

Text-based log files can be imported into Microsoft Excel or Microsoft Access for further analysis. IIS log files can also be converted to one of two other formats using the convlog utility. The log files can be converted to European Microsoft Windows NT Academic Centre (EMAC) format, or to Common Log File Format. These formats can be used by a number of different log analysis formats. The convlog utility is located in the \INTERSRV\ADMIN directory, and accepts the following command-line syntax:

convlog -s[f|g|w] -t [emwac|ncsa[:GMTOffset]|none] -o [output directory] 

[ccc]-f [temp file directory] -n[m[cachesize]|i] -h LogFileName

The -s parameter specifies which services log entries should be converted to: f for FTP, g for Gopher, or w for Web entries. The -t parameter specifies the target conversion format, emwac or ncsa for Common Log File format. The -o parameter specifies the output directory. The second -t parameter specifies the temporary file directory. The -n parameter specifies whether to convert IP addresses to domain names. The default I option is not to perform this conversion. The m option specifies the IP conversion, the default cache size is 5000 bytes. The -h parameter displays help. The LogFileName specifies the name of the log file to be converted.

Windows NT Performance Monitoring

The Windows NT Performance Monitor can track processes and services running on a Windows NT Server. There are a number of different counters that can be used to track the IIS on a dynamic basis. The Performance Monitor can also create alerts, logs, and reports, which can be effective tools in dynamic security management. The Performance Monitor can track information for HTTPD Services (in Table 18.3) and for the IIS Global Object (in Table 18.4).

Windows NT Auditing

Windows NT Auditing can track events performed by authorized and unauthorized users. The Windows NT Event Viewer can be used to filter and view these audited events. When auditing is enabled, performance will be decreased and large amounts of disk space can be utilized quickly. Two types of auditing can be tracked:

• User Account Auditing tracks and logs user-level security events.
  
  
• File System Auditing tracks and logs file system events.
  
  

User Account Auditing Setup

To configure User Account Auditing, from the User Manager for Domains utility, choose Audit on the policies menu, then click on the Audit These Events button. Selecting the following options to track these events:

• Logon and Logoff tracks when a user logged on, off, or connected to the server.
  
  
• File and Object Access tracks when a user accesses a file, directory, or printer that has been set for auditing.
  
  
• Use of User Rights tracks when a user exercises a user right.
  
  
• User and Group Management tracks when a user account is created or changed.
  
  
• Security Policy Changes tracks when a change was made to User Rights, Audit, or Trust Relationship policies.
  
  
• Restart, Shutdown, and System tracks when a user restarts the system, a user shuts down the system, or an event occurs that affects system security, respectively.
  
  
• Process Tracking tracks events such as program activation and exits.
  
  

These events can then be filtered and viewed using the Windows NT Event Viewer.

File System Auditing Setup

To assure the highest level of security for your file system, it should be placed on an NT File System (NTFS) partition. NTFS can control file access on a file-by-file, user-by-user basis. If there is a conflict between NTFS files permissions and IIS settings, the stricter of the two settings will be utilized.

To configure Windows NTFS auditing, from the File Manager, select the Security menu option, then choose the Auditing option. Add the user or group account you want to enable auditing for by clicking on the Add button. The following success or failure of the following events can be audited: Read, Write, Execute, Delete, Change Permission, and Take Ownership. These events can then be filtered and viewed using the Windows NT Event Viewer.

Secure Sockets Layer

The IIS provides Secure Sockets Layer (SSL) to ensure secure communications by using data encryption. An IIS that is enabled with SSL can send and receive data across the Internet to an SSL-enabled client and ensure that it remains private.

SSL operates as a layer between the TCP/IP network protocol and the HTTP applications. Server authentication, encryption, and data integrity are provided through SSL utilization. Data integrity ensures that data that has been transmitted has not been altered. Encryption ensure the privacy of the data transferred. SSL provides RSA-compliant encryption. Authentication ensures the client side that its data is sent to the correct server, and that the server is secured. SSL is an important component of protecting financial transactions over the Internet.

To enable SSL on the IIS, follow these steps:

1. Change the current directory to C:\INETSERV\SERVER (or to the directory where the IIS was installed).
   
   
2. Use the KEYGEN.EXE utility to create the key pair KEYPAIR.KEY and certificate request REQUEST.REQ files.
   
   
3. A fully distinguished name for the server must be specified using the following variables:
   C = A two-letter ISO Country code (US, CA, FR, AU, UK).
   S = State or province (New York, Maine, Washington). Do not abbreviate.
   L = Locality (Buffalo, Portland, Redmond).
   O = Organization (preferably the ISO-registered top-level organization or company name).
   CN = Common Name (the domain of the server—for example, www.microsoft.com).
   
   
4. If the KEYGEN utility is used more than once, it will return an error 80. You must be sure to delete existing KEYPAIR.KEY and REQUEST.REQ files.
   
   
5. Run the KEYGEN application. The command line to generate the file pair for the marketing department of IDC Consulting, Inc. in Buffalo, New York uses the following command line (replace password with your appropriate password choice):
   KEYGEN {Password} KEYPAIR.KEY REQUEST.REQ "C=US,S=NEW YORK, L=BUFFALO,
   O=IDC CONSULTING, OU=MARKETING, CN=www.idcconsult.com"
   
6. Edit the REQUEST.REQ file, and enter the command line used to create the REQUEST.REQ file; be sure to remove the password from the command line. E-mail the REQUEST.REQ file to the appropriate certification organization. Verisign, Inc. is a widely known certification agency. The may be contacted on the Web at http://www.verisign.com.
   
   
7. Once all the appropriate documentation and authorization steps have been taken by the certifying agency, an e-mail response will probably be returned containing a signed certificate from the certification authority. Save this message to a file (CERTIF.TXT, for example).
   
   
8. Use the SETKEY.EXE utility to install the signed certificate. The SETKEY.EXE utility is in the C:\INETSERV\SERVER (or the directory where the IIS was installed).
   
   
9. Run the SETKEY utility using the following example command line (the password must be the same password as specified in step 5):
   SETKEY {Password} KEYPAIR.KEY CERTIF.TXT {IP Address}
   
10. Activate SSL on the IIS. Start the Internet Service Manager, and double-click on the server you would like to configure for SSL. On the Service properties page, select the Windows NT Challenge/Response to enable secured HTTP authentication. On the Directory properties page, double-click on the directory that will require secure connections. Microsoft recommends that separate content directories be used for secure and public content. If the directory is not listed, click on the Add button and fill out the dialog box to add the directory.
    
    
11. Back up the KEYPAIR.KEY file to a floppy disk and remove it from the server, in case it is required in the future. It is important to also remember the password utilized in steps 5 and 9.
    
    

---

If an IP Address is not specified, the certificate will be applied to all virtual servers supported by the IIS that are configured to utilize the SSL channel.

---

NetBIOS Security

NetBIOS is the Windows-based file and print sharing protocol, and is used by Windows NT Browser, Messenger, and Net Logon services. The NetBIOS protocol maps unique computer and services names. The NetBIOS protocol can be used over the TCP/IP protocol, providing NetBIOS client access over a Wide Area Network (WAN). Using the NetBIOS protocol over TCP/IP when a computer is connected to the Internet can be a potential security risk. An unauthorized user could impersonate an authorized user, issue a NET VIEW command to view resources, and issue the NET USE command to attach to those resources gaining access to the server’s file system. There are some steps that can be taken to reduce the potential security risk of NetBIOS over TCP/IP:

• As described previously, install two network adapters using different protocols—one adapter running TCP/IP and the other the NetBIOS protocol. On the adapter card bound to the TCP/IP protocol, remove the NetBIOS, Workstation, and Server bindings. On the adapter card bound to the NetBEUI protocol, bind the NetBIOS, Workstation, and Server.
  
  
• Disable the UDP/TCP ports 137, 138, and 139, on your router. These ports are used by the NetBIOS over TCP/IP protocol.
  
  

Service Message Block (SMB) Security

Microsoft’s proprietary Service Message Block (SMB) handles file and printing requests, no matter which network protocol stack is used. SMB fulfills the OSI presentation layer functionality, but it operates in the application layer as a software module. SMB is a core component of Microsoft Networking and installed by default whenever Microsoft Networking is installed.

---

By default, a Guest account is created when the NT Server is installed. The Guest account is configured with a blank password. When a server with the Guest account enabled is connected to the Internet, it is possible for anyone to connect to the server, log in as Guest, and cause problems with the shared resources or even the registry, utilizing the SMB functionality. For this reason, it is imperative that any server connected to the Internet disable the Guest account.

---

Java Security

With the introduction of the Java programming language to the Internet, a new set of system security concerns has been introduced. Java applets are retrieved from the Internet just like any other Web Page. Once the Java applet has been retrieved, the Java interpreter in the Web browser executes the applet. In theory, the Java interpreter should enforce security restrictions, limiting an applet's behavior. A number of different security problems have been uncovered in the Netscape Navigator and Internet Explorer. Although there have not been widespread reports of Java applets that attack a system, there is still reason for concern. It is possible to execute Java applets that send back sensitive data from your system to another server. It is also possible to execute a Java application that monitors your Web browsing session and sends back details to another server—all without leaving any trace that these applets were run. It is important to educate users on the potential security risks of Java applications. In Netscape Navigator 2.0, Java can be disabled through the Options, Security Preferences dialog box.

ActiveX Security

With the release of Microsoft’s Internet Explorer Version 3.0, ActiveX controls were introduced. ActiveX controls can be developed using tools native to the Windows Operating System, producing applets that can run much quicker than Java applets. Although the Java programming language has built-in security restrictions, the ActiveX specification does not. There are no restrictions on what an ActiveX applet can do. ActiveX is based on Object Linking and Embedding (OLE) technology. Although OLE linked files to an external application, ActiveX creates an applet within an existing document.

Without any built-in security restriction, the potential for abuse by an ActiveX applet is quite large. To counter these effects, Microsoft has presented a solution based on digital signatures. Using a digital signature, the creator of an ActiveX applet signs the applet with a private key. When an ActiveX applet is downloaded, the digital signature is checked against a public key to verify its authenticity. If the applet has been tampered with, the authenticity check will fail. Although digital signatures are new technology, they have been in use for quite some time in e-mail with the Pretty Good Privacy (PGP) shareware application.

A number of concerns must be addressed before digital signature technology can be effective with ActiveX applications: digital signatures need to be more effectively integrated with existing applications, digital signatures do not ensure that the applet does not contain a virus or malicious code, and end-users must decide whose digital signatures they will trust.

Catapult Proxy Server

With the release of Windows NT Server Version 4.0, Microsoft will be releasing a new proxy server (which is currently in beta testing) named Catapult. Catapult will become another member of the Microsoft BackOffice family of applications. Catapult provides the following features:

• Support for all Internet protocols, including HTTP, FP, RealAudio, VDOLive, IRC, and news and mail.
  
  
• Capability of filtering and replicating Web pages for corporations and Internet Service Providers.
  
  
• Support for IPX/SPX transport.
  
  
• Capability of Web browsers running on any operating system of accessing Internet sites through Catapult.
  
  
• Proactive caching of frequently accessed information. Catapult can automatically refresh cached copies of frequently accessed information based on heuristics of usage.
  
  
• Support over dial-up lines.
  
  
• Capability of granting or denying inbound or outbound connections based on user, service, port, or IP domains. Specific sites can also be blocked.
  
  
• Mechanisms to interconnect branch offices by using the Internet and encrypted transmissions.
  
  
• Tight integration with Windows NT Server, including Event Logging, Performance Monitor, and User Manager.
  
  
• Support for ISAPI (Internet Server API), which allows extension such as customized logging, authentications, and access control.
  
  
• Filtering of packets that do not originate from an internal user.
  
  
• Support Policy Domain Name filtering, which creates a list of domain that users can or cannot access.
  
  
• User level permissions, which control what users can and cannot access Internet resources.
  
  
• Remote management capabilities.
  
  
• Support for Secure Sockets Layer (SSL) and Private Communication Technology (PCT) protocols.
  
  
• Integration with other BackOffice components, including SQL Server and Exchange Server.
  
  

To set up and configure a Catapult proxy server, two network adapters are required. One adapter is attached to the LAN, and the other is connected to the Internet. The network card attached to the LAN utilizes Remote Procedure Calls (RPC) to transmit Internet requests and responses over the network. The LAN can utilize the TCP/IP, IPX/SPX, NetBEUI, or other protocols. The Internet-connected adapter must utilize the TCP/IP protocol. Catapult manages communications between the LAN and the Internet.

To configure the Catapult services, IP routing between the LAN and the Internet must be disabled. This prevents Internet packets from reaching the LAN, so unauthorized Internet users cannot gain access to the LAN. Routing can be disabled by accessing Advanced Options from Network applet in the Control Panel.

Clients on the LAN must also be configured to direct their Internet requests through the Catapult server. The Gateway applet in the control panel enables users to specify which gateway to use for Internet access.

Stay Informed—Stay Secure

Potential intruders to your systems stay well-informed regarding potential security holes. To maximize the security of your system, it is essential that you stay just as informed. There are a number of Internet Web sites available to keep up-to-date on current security issues and IIS updates, including the following:

• Microsoft: http://www.microsoft.com
  
• Netscape: http://www.netscape.com
  
• Javasoft Web Site: http://www.javasoft.com/java.sun.com/sfaq/index.html
  
• Verisign: http://www.verisign.com/netscape/
  
• World Wide Web Security FAQ: http://www-genome.wi.mit.ed/WWW/faqs/www-security-faq.html
  
• Computer Emergency Response Team: http://www.cert.com
  
• Computer Incident Advisory Capability site: http://ciac.llnl.gov/
  
• National Computer Security Association: http://www.ncsa.com
  
• NT Security Issues: http://www.somarsoft.com/security.htm
  
• Yahoo!: http://www.yahoo.com/Computers_and_Internet/Security_and_Encryption
  
• World Wide Web Consortium: http://www.w3.org
  

Summary

The threat of a security breach from the outside is, in all likelihood, very low. Data is more likely to be lost due to a natural disaster or internal theft by a trusted user. This does not mean that security issues should be overlooked. Internet/intranet security with the IIS should be given its due diligence. It is always best to take the necessary security precautions in a proactive manner. It is impossible to make a networked system completely secure. Increased security almost always comes at the cost of usability. This compromise must continually be evaluated to ensure safety and usability.