In what situation would a network administrator most likely be required to setup an alternate IP configuration method on a network host?

Internal Network Security Assessment Methodology

Assessing your internal network does not mean attempting to identify and remediate all vulnerabilities in your network. The sheer number of systems on your internal network, multiplied by an astronomical rate of network changes sets up this strategy for failure. And because securing every host on the internal network may not be plausible for most organizations, a number of departments within every company can be determined to deserve special attention. For varying reasons, these departments host data that could pose significant risk to the welfare of the organization as a whole. Assessing your internal network will require you to make difficult decisions about what to secure based on your available resources. You will need to secure the right assets, from the right risks, with the right measures.

Private Addressing

The internal interface (or network card) for the router has an IP address of 192.168.1.1, this is what is called a private address as it can’t be used on the Internet. It is fine for the internal network represented by the gray box in Figure 4.3 as are all of the addresses issued by DHCP, for example the IP address issued to Adam and Bill’s computers. Table 4.1 lists the common private IP addresses that can be used for internal or private networks, but can’t be used on the Internet.

Table 4.1. Private IP Addresses

To access the Internet, the router does a bit of magic called network address translation (NAT) that converts the IP addresses used by Adam and Bill to addresses that can be used on the Internet. This is normally the address that is issued to the router by the cable Internet provider and will be assigned to the external interface (another network card). If a user was to try and use these addresses on the Internet, without a NATing router, the communication would fail as Internet routers and other devices reject these private IP addresses.

Create an Access Rule Allowing DNS from Internal to External

The Internal network DNS server needs to be able to query an Internet DNS server to resolve Internet host names. We can create a DNS Access Rule that will allow the Internal network DNS server access to Internet DNS servers using the DNS protocol. Perform the following steps to create the DNS Access Rule for the DNS server:

In the Microsoft Internet Security and Acceleration Server 2004 management console, click the Firewall Policy node in the left pane of the console.

Click the Tasks tab in the Task Pane and then click the Create New Access Rule link.

On the Welcome to the New Access Rule Wizard page, enter a name for the rule in the Access Rule name text box. In this example, we'll call the rule Outbound DNS Internal DNS Server. Click Next.

On the Rule Action page, select the Allow option and click Next.

On the Protocols page, select the Selected protocols entry from the This rule applies to list. Click the Add button.

In the Add Protocols dialog box, click the Common Protocols folder and then double click the DNS entry. Click Close.

Click Next on the Protocols page.

On the Access Rule Sources page, click the Add button.

In the Add Network Entities dialog box, click the New button. Click the Computer entry.

In the New Computer Rule Element dialog box, enter a name for the computer in the Name text box. In this example, we'll enter the name Internal DNS Server. In the Computer IP Address text box, enter the IP address of the Internal DNS server. In this example, the IP address is 10. 0. 0. 2, so we'll enter that IP address. Click OK.

Click the Computers folder and double click the Internal DNS Server entry. Click Close.

On the Access Rule Sources page, click Next.

On the Access Rule Destinations page, click the Add button.

In the Add Network Entities dialog box, click the Networks folder. Double click the External entry and click Close.

Click Next on the Access Rule Destinations page.

On the User Sets page, accept the default entry User Sets and click Next.

Review the settings on the Completing the New Access Rule Wizard page and click Finish.

Network Address Translation and Port Forwarding

NAT hides the internal network from the external world by rewriting the return address of outgoing packets to the NAT router and rerouting incoming packets to the correct device on the internal network. In a NAT real-network solution, the Simics machines sit behind a virtual NAT router, just like a home or office network usually sits behind a NAT router when connected to the Internet. The virtual NAT router in Simics allows port forwarding so that the external world can initiate connections to simulated machines.

As shown in Figure 5.12, the IP address of the Simics target machine is hidden from the external world. The NAT bridge rewrites the source of outbound packets to match the host address. For inbound port-forwarding, the NAT bridge is configured to map particular host-side ports to particular IP addresses and ports inside of the virtual network. For example, to contact a web server at 10.10.0.20:80, the external computer would contact 192.168.1.10:4080 (or any other chosen port on the host). The NAT bridge would then rewrite the incoming traffic to go to port 80 on the Simics target.

Because NAT needs to rewrite packets, it only works for UDP and TCP. Some protocols such as FTP require some extra awareness in the NAT to work—for example, including IP addresses in the payloads. For such cases, the NAT code needs to rewrite packets based on application knowledge. This is common to all NAT solutions and not specific to Simics.

NAT offers a simple way to connect out from Simics targets to the outside world, requiring no administrative privileges. The Simics process on the host simply opens up TCP/IP ports, and the external world does not need to know that they correspond to ports on simulated computers.

Intranets

Intranets are essentially internal networks that employ Web standards and technologies, such as HTML, HTTP and the use of a web browser client. They are generally available only to employees and to those outsiders who are granted special login or access privileges, and are typically protected from outside ‘invasion’ by firewalls and the use of ‘proxy’ servers (explained in Chapter 7). Intranets are an important tool in the so-called knowledge management environment, allowing enhanced communication within an organisation; the sharing of data, information and expertise; collaboration with partners and suppliers; and the sharing of electronic resources and services such as multimedia products and videoconferencing. Many librarians have been keen to use organisational intranets to disseminate its resources and services – typically to users’ desktops (their computers) – and on some occasions have even been active in the development of their organisations’ intranets. One of the benefits of using web-based technologies is the fact that users can access resources on the intranet via browsers such as Netscape Navigator or Internet Explorer, regardless of the user's computer system.

It was suggested that intranets might on occasion be opened to select outsiders. An extension of this, in which two or more organisations share space on a common server, is called an extranet. At the time of writing, these appear to have little application in the library environment, because of issues such as security and intellectual property, but it is as well to be aware of their existence and development.

F5

F5’s SSL VPN appliance, FirePass, has the sole use of connecting remote clients to the corporate network. These appliances are not designed to create a VPN tunnel between two different networks. FirePass can be configured to accept connections as a Web proxy and/or from a proprietary binary client for Windows.

Some of the internal network protection features of FirePass include:

Automatic detection of security compliant systems, preventing infection

Automatic integration with the largest number of virus scanning and personal firewall solutions in the industry (over 100 different AV &and Personal Firewall versions)

Automatic protection from infected file uploads or e-mail attachments

Automatic re-routing and quarantine of infected or noncompliant systems to a self remediation network—reducing help desk calls

A secure workspace, preventing eavesdropping and theft of sensitive data

Secure Login with a randomized key entry system, preventing keystroke logger snooping

FirePass is especially suited for specific client/server application access via Web browsers. Administrators can restrict server access to specific applications and thereby protect other network resources.

Enables a native client-side application to communicate back to a specific corporate application server via a secure connection between the browser and the FirePass Controller. Thus, user pre-installation and/or configure any software.

On the network side, requires no additional enabling software on the application servers being accessed.

Uses the standard HTTPS protocol, with SSL as the transport, so it works through all HTTP proxies including public access points, private LANs, and over networks and ISPs that do not support traditional IPSec VPNs.

Supported applications include Outlook to Exchange Clusters; Passive FTP, Citrix Nfuse, and network drive mapping. Administrators can also support custom applications, including CRM and other applications that use static TCP ports.

Supports auto-login to AppTunnels, Citrix, and WTS applications, and auto-launch of client-side applications.

Unique support for compression of client/server application traffic over WAN to offer better performance.

Users of Windows 2000/XP can be automatically switched to a protected workspace for their remote access session. In a protected workspace mode, the user cannot write files to locations outside the protected workspace, and the temporary folders and their contents are deleted at the end of the session.

Figure 6.4 shows the various modules used by FirePass and some examples of application access.

Table 6.2 lists the different FirePass appliances and their salient features. Further details about the products are available at www.f5.com/products/FirePass/.

Table 6.2. SSL Product Line Offered by F 5 VPN

Configuring the Firewall with VPN Router

Tom connects a cat 5 Ethernet cable from the wireless router to his firewall. He turns on the firewall. He then connects his computer and printer network ports to the firewall Ethernet ports. He checks that the lights for each of the ports are showing up as connected.

Note

The firewall separates the internal network from the other networks, keeping the interior of the network the most secure. If the wireless network is compromised, the servers on the internal network are not accessible.

He browses to 192.168.0.1 (the default IP address for this particular appliance). He accepts all the defaults allowing the wireless router to give the firewall a DHCP address, and let the firewall give his internal systems their own IP addresses.

Note

The default username and password for the firewall is admin, and password. Change this soon after the basic configuration.

Tom checks the Basic Settings. He can safely accept this basic configuration from the initial setup.

He then checks logging, and checks the All Websites and news groups visited, All incoming TCP/UDP/ICMP traffic, All Outgoing TCP/UDP/ICMP traffic, Other IP traffic, and Connections to the Web based interface of this Router, as he wants to get as much information as possible about what is happening in his internal network. Later, after he feels comfortable with what is normal behavior on his systems, he might turn off some of the logging so it is not as comprehensive. Tom doesn’t worry about the syslog server configuration, as he does not have a logging infrastructure. For now, Tom isn’t going to e-mail the logs to himself; instead, he chooses to look at them and clear them manually.

The logging is now comprehensive. The highlighted portion of the log in Figure 8.2 shows Tom’s access to the Administrator Interface.

On the Rules tab, Tom sees that he can configure specific rules to allow and disallow services, and actions from happening. Tom plans to watch his log for a few days and determine what if anything he needs to tune.

Tom invested in a solution that would give him VPN functionality. This allows him to connect his laptop remotely to the internal system so he can print, or access records from his porch or anywhere in his house. Now that he has the basic firewall configured, he can configure the VPN access. He clicks on the VPN wizard, and gives the connection a name. He reuses his pre-shared key, and chooses remote VPN client.

He downloads the Netgear VPN client software so he can use IPSec to connect to the VPN. Optionally, he could connect direct to another VPN firewall via his firewall if he were to bring on board a remote partner using this same VPN wizard setting on the VPN firewall.

14 The Perimeter

In Fig. e16.3, you will see yet another IP network labeled DMZ. You may ask, why yet another network? The rationale behind this design is as follows.

Users that belong to IN might want to access resources on the Internet, such as to read their email and send email to users on the Internet. The corporation needs to advertise its products on the Internet.

The DMZ is the perimeter network where resources have public IP addresses, so they are seen and heard on the Internet. Resources such as the Web (HTTP), email (SMTP), and DNS are placed in the DMZ, whereas the rest of the resources that belong to this corporation are completely hidden behind the Linksys router. Resources in the DMZ can be attacked by the hacker because they are open to users on the Internet. Relevant TCP and UDP port numbers on the servers in the DMZ have to be left open to incoming and outgoing traffic. Does this create a potential “hole” in the corporate network? The answer to this is both yes and no. Someone can compromise resources in the DMZ without the entire network being exposed to a potential attack.

The first firewall is the Cisco router, and it is the first line of defense, if network security policy is implemented. On the Cisco router it is known as the Access Control List (ACL). This firewall will allow external traffic to inbound TCP port 80 on the Web server, TCP port 25 on the email server, and TCP and UDP port 53 on the DNS server. External traffic to the rest of the ports will be denied and logged.

The second line of defense is the Linksys router that will have well-known ports closed to external traffic. It, too, will monitor and log traffic. It is acceptable to place email and the Web server behind the Linksys router on the private IP network address. Then you will have to open up the TCP ports 80 and 25 on the Linksys router so that external traffic can be mapped to ports 80 and 25, respectively. This would slow down traffic because the Linksys router (or any commercial-grade router) would constantly have to map the port numbers back and forth. Finally, the DNS server would always need to be placed in the DMZ with a public IP address, because it will be used to resolve domain names by both internal and external users. This decision has to be left to the corporate IT staff.

Internal Network

The ISA 2004 Internal Network is quite different from the ISA Server 2000 Internal network. In ISA Server 2000, any network contained in the LAT was considered an Internal network. All communications between LAT (Internal Network) hosts were not filtered and firewalled by ISA Server 2000 firewall. The reason for this is that only communications between LAT and non-LAT clients were firewalled by the ISA Server 2000 firewall.

In contrast to the ISA Server 2000 firewall's approach to Internal and external networks, the ISA firewall's concept of Internal network is related to the System Policy Rules that are automatically configured on the ISA firewall.

In order to understand the Internal Network's role, you have to have a basic understanding of the ISA 2004 System Policy. The ISA 2004 System Policy is a collection of 30 Access Rules that control inbound and outbound access to and from the ISA firewall. These rules are created by default and you can customize them, or even disable them, if you like. Examples of ISA 2004 System Policy rules include:

Allow access to directory services for authentication purposes

Allow Kerberos authentication from ISA Server to trusted servers

Allow Microsoft CIFS from ISA Server to trusted servers

Allow NetBIOS from ISA Server to trusted servers

For each of the System Policy Access Rules, communications are by default assigned from the Local Host network to the Internal Network. The ISA firewall's concept of the Internal network is the network where your main infrastructure servers are located. That way, the default System Policy rules allow communications with the organization's Active Directory servers, DNS servers, DHCP servers, WINS servers, and file servers. However, this concept of the Internal network applies to make setup of the ISA firewall simple, as the Internal network is defined during setup of the ISA firewall software. You are in no way limited to that definition of the Internal network.

One thing that's important to note that is you can create multiple internal networks. Notice that I've used a lower case “i” in this case. An internal network can be any network that is protected by the ISA firewall. In fact, you can create DMZ networks and call them internal networks. Only the default Internal network (with an upper case “I”) has special meaning to the ISA firewall, and that special meaning is related to System Policy.

TIP

We recommend that you take advantage of the default Internal Network and place all of your infrastructure servers behind the same NIC. This makes installation and configuration of the ISA firewall much easier because you can leverage the default System Policy rules.

You can view the Properties of the default Internal Network by going to the ServerName\Configuration\Networks node. The configuration options for the default Internal network are the same as any other network you create on the ISA firewall. We can use the Internal network configuration options as a model on which you can create and configure other internal or perimeter Networks on the ISA firewall.

Click on the Networks tab in the Details pane, and then double-click on the Internal network. Click on the Addresses tab, and you'll see something like Figure 4.24.

On the Addresses tab, you enter the addresses on all networks located behind the Internal Network adapter. In the example shown in Figure 4.25, the internal network includes all addresses in the 192.168.1.0/24 range. These addresses were defined when the ISA firewall software was installed.

You can also easily add addresses in the private address range. Click the Add Private button to add addresses in any of the private network ID address ranges. Figure 4.25 shows the fly out menu from the Add Private button.

WARNING

Do not use private address ranges that are not in use on the Internal network, and do not address an entire private address range to the Internal network if the entire private address range is not in use on the Internal network. This can cause conflicts if you have other networks that use subnets of the private network address range. For example, you may have the Internal Network using IP addresses 192.168.1.0-192.168.1.255 and another internal network using IP addresses 192.168.2.0-192.168.2.255. If you assign the Internal network the address range 192.168.0.0-192.168.255.255, you will create a conflict that prevents you from using the 192.168.2.0/24 network addresses for the second internal network. We recommend that you never use the Add Private button when configuring addresses for networks.

A better way to add addresses to the Internet network (and other networks you create) is to use the Add Adapter button. Figure 4.26 illustrates the effect of clicking the Add Adapter button.

In the Select Network Adapters dialog box you can select the NIC connected to the Internal network and use the addresses in the Windows Routing Table to define the network. This is a much more reliable method of defining a particular network, since the Windows Routing Table should always have knowledge of all networks reachable from the ISA firewall. This knowledge of all reachable networks can be done either via manual configuration of the Windows Routing Table or by using a dynamic routing protocol such as RIP or OSPF.

The last method available for adding addresses to the Network is to use the Add button. Figure 4.27 illustrates the effect of clicking the Add button.

Click the Domains tab (Figure 4.28). Here you enter a list of internal network domains. When the firewall client connects to a host located in one of these domains, the connection request bypasses the Firewall client application. The primary rationale for this is that if all the machines located in the same domain are located behind the same NIC, then the Firewall client machine can communicate directly without looping back through the ISA firewall. This reduces the overall load on the ISA firewall and improves client performance because the connection doesn't incur any Firewall processing overhead. Further, the Domains tab can be used to control the behavior of Web Proxy clients when accessing external sites. We will discuss the relationship between the Domains tab and Web Proxy clients later in this chapter. See Figure 4.28 to see how to enter local domains.

You have to be careful with the entries you make on the Domains tab if your internal network domain extends across multiple NICs. Figure 4.29 shows an example of one scenario where the domain extends across multiple network interfaces.

This is an example of a simple campus network configuration. There are three network interfaces on the ISA firewall. One interface connects the ISA firewall to the Internet. The second interface connects the ISA firewall with the Internet network, and a third interface connects the ISA firewall to a second internal network. The Internal network (with a capital “I,” which is the Faculty and Departments network) contains the Active Directory servers and other infrastructure servers. The other internal network (the Student's Network) contains student machines which have been made members of the campus Active Directory domain, and these machines also have the Firewall client installed.

The Internal network domain name is msfirewall.org. You would include this domain name on the Domains tab. When any host on the Internal network contacts any other host in the msfirewall.org domain, the Firewall client machines on the Internet network will bypass the ISA firewall and connect directly to the hosts in the msfirewall.org domain located behind the Internal network adapter. Since there are no hosts on the Internal network that need to initiate connections to hosts on the Student's network, all is well. That's because all msfirewall.org servers are located behind the Internal network adapter.

Now suppose we place enter msfirewall.org into the Domains tab on the DMZ network, and we create an access rule (we will go over the details of Access Rules in chapter7 that allows HTTP, HTTPS, FTP, SMTP and POP3 to authenticate clients on the Student's Network into the Internal network. What would happen when machines configured as only Firewall clients on the Student's network try to connect to a POP3 server on the Internal network? That's right – the connection request fails. That's because the Student's Network Interface on the ISA firewall was configured with the msfirewall.org domain on its Domains tab. Since the machine configured as a Firewall client will bypass the Firewall client configuration when connecting to resources on domains listed on the Domains tab, the connect never even makes it to the ISA firewall.

What if the Firewall client machine on the Student's Network were configured as SecureNAT client as well as a Firewall client? In this case, the connection attempt from the host on the student's network to a member server on the Internal network in the msfirewall.org domain would be sent to the Student Network interface on the ISA firewall. The connection request in this case would be denied because the SecureNAT client cannot send credentials to the ISA firewall.

TIP

You can also enter external network domains on to the Domains tab. This will allow hosts that are also configured as Web Proxy and/or SecureNAT clients to bypass their Firewall client configuration to access Internet resources in those domains. This is useful in those rare circumstances where the Firewall client may not be compatible with a particular piece of software on the Firewall client computer.

In the Internal Properties dialog box, click on the Web Browser tab. Figure 4.30 shows what you will see in the dialog box.

The settings on this tab control Web browsers on the Internal network that are configured to use the autoconfiguration script (we will discuss the autoconfiguration script in detail in Chapter 5. You have the options:

Bypass proxy for Web servers in this network. This is an interesting setting. The Help file states: “Bypass proxy for web servers in this network. Select this option if the Web browser on the Firewall client computer should bypass the ISA Server computer when accessing local Web servers.” The question is, what is a local Web server? Local to what? The answer is that local means to any Web server located at an address included in this Network's Address range. So, in the case of the Internal network, when a Web Proxy client configured with the autoconfiguration script attempts to connect to a Web server whose address is also on the Internal network, then the Web Proxy client will bypass the Web Proxy on the ISA firewall and connect directly to the Web server on the Internal network. This is a good thing. This prevents hosts located behind the same network adapter from looping back through the ISA firewall to access resources behind the same network interface.

Directly access computers specified on the Domains tab. This allows the Web Proxy client configured with the autoconfiguration script to use the domains listed on the Domains tab for Direct Access. Direct Access for Web Proxy clients allows the Web Proxy client computer to bypass the Web Proxy on the ISA firewall and connect directly to the destination, either via the machines SecureNAT client configuration or via the machines Firewall client configuration. This is useful if you want to leverage the domains already entered on the domains tab and use them for Direct Access. However, beware of issues like those mentioned earlier with the Student's Network and Internal Network in the trihomed DMZ configuration.

Directly access these servers or domains. You can add a list of domains or IP addresses that you want Web Proxy clients configured with for the Autoconfiguration script to bypass the Web Proxy on the ISA firewall. In the example provided in the figure, we have entered a list of domains that should be bypassed when you want to use Outlook Express to access a Hotmail account. When the Web Proxy client computer connects to these domains, the Web Proxy client configuration is ignored, and the client uses alternate client configuration to access these sites, such as SecureNAT or Firewall client configurations.

If ISA Server is unavailable, use this backup route to connect to the Internet: Direct access or Alternative ISA Server. This option is a bit misleading because it implies that the entire ISA firewall must be unavailable before one of the options is triggered. In fact, the ISA firewall can be just fine, but if there is a problem with the ISA firewall's Web Proxy, then one of the alternatives is used. The Direct Access option allows a machine configured as a Web Proxy client to use an alternate client configuration to access the Internet or other destination network. This can be either its SecureNAT client configuration or via its Firewall client configuration. The Alternative ISA Server option allows you to enter the FQDN or IP address of an alternate ISA firewall to which the Web Proxy client can connect to reach the Internet. Do not use the Browse button to find an alternate server. If you use a FQDN in the Alternative ISA Server text box, then make surethe ISA firewall can resolve that FQDN to the correct IP address so that the ISA firewall can locate the alternate Web Proxy.

TIP

It is a little known fact that one of the most powerful methods you can use to control access for Web Proxy clients is the autoconfiguration script. You should always configure the Web Proxy clients to use only the autoconfiguration script if at all possible. The only exception to this is when you use WPAD and autodiscovery to assign configuration information to the Web Proxy clients. When you use autodiscovery, the autoconfiguration script information is automatically copied to the Web Proxy client. The autoconfiguration scripts make it possible to easily create a bypass list for Web Proxy clients so that they can use alternate client configuration to access problematic sites that do not work with CERN-compliant Web Proxy servers (like ISA 2004).

Click on the Web Proxy tab. The Web Proxy tab defines the outbound Web Listener for the Network. Web Proxy clients on this network use this Web listener to connect to the Web Proxy on the ISA firewall. The outbound Web Proxy listener for the Network is enabled by placing a checkmark in the Enable Web Proxy clients checkbox. A checkmark must also be in the Enable HTTP checkbox for Web browsers configured as Web Proxy clients to connect to the Web Proxy on this Network. See these steps illustrated in Figure 4.31.

Many people have wondered for years about the Enable SSL checkbox on the Web Proxy page. This option was also available in ISA Server 2000. This setting posed a curious problem because if you enabled this option and then tried to configure the Web browser to connect to the default SSL port on the outbound Web Proxy SSL listener, the connection attempt would fail. The reason for this is that the Web browser that is configured as a Web Proxy client cannot establish an SSL connection with the Web Proxy listener. The initial connection between the Web Proxy client and the outbound Web Proxy listener must always be over HTTP.

If the connection between the Web Proxy client and the outbound Web Proxy listener must always be HTTP, then why did they make the Enable SSL option available on the Web Proxy tab? The reason is that in a Web Proxy Chaining scenario, you can configure a downstream Web Proxy server to forward Web requests to an upstream Web Proxy server using an SSL connection. This setup allows for outbound HTTP- to-SSL bridging between the downstream Web Proxy and the upstream Web Proxy.

TIP

It's always been a mystery to us why the Web browser wasn't designed to support SSL connections to the Web Proxy on the ISA firewall. This would allow an SSL-secured connection between the client and the Web Proxy, even though the URL might be for HTTP content on the Internet. While you might think that such a feature wouldn't be of much value, the fact is that it's more likely that someone has a sniffer on your network than there is on any interposed networks between yours and the destination host. There is also a greater chance that the person running the sniffer on your network is looking for specific data, such as user names and passwords. Perhaps future versions of the Internet Explorer Web client will support this type of configuration.

Security Authorization/Risk Boundary

The security and risk boundary defines the limits of the security protections implemented in the system and the area of responsibility for the AO. The boundary is the point where one system stops and another system begins. In most cases, there is some type of boundary device between the two systems, like a router or firewall, that can serve as a point of demarcation between the systems. This information must be fully documented in the security plan.

Loudspeaker Authorization/Risk Boundary

The Loudspeaker system connects to the internal network through the internal backbone router, rtr037; the interface to this device is the system boundary on the internal network for this device. The system connects to the organizational TIC through rtrx43; the interface to this device is the system boundary on the demilitarized zone (DMZ)/external network for this device. Both routers are outside the system boundary for the Loudspeaker system. The physical boundary for this system is the network connection between the R900 server and the two routers. The logical and physical boundary is illustrated in Figure 9S-1

Figure 9S-1.