What is the difference between a trusted network and an untrusted network?

Example: Configuration for Dual ADSL Modems

Once in dual-untrust mode, you can add the necessary configuration needed for the two separate untrusted paths. For example, imagine a scenario where the preferred path is via one ADSL modem, and the backup path is via a different ADSL modem (or other service relying on PPPoE authentication), as depicted in Figure 12.1.

From the CLI:

From the Web interface:

Go to Network | PPPoE | New.

Name this instance primary-adsl.

Bind this instance to ethernet3.

Enter the ISP's username and password.

Enable the Clear IP on Disconnect option.

Enable Auto-connect and specify 20 seconds.

Click OK to save.

Return to Network | PPPoE | New.

Name this instance backup-adsl.

Bind this instance to interface ethernet2.

Enter the ISP username and password.

Enable Auto-connect and specify 20 seconds.

Click OK to save.

Go to Network | Untrust Failover | Automatic Failover and click OK.

The clear-on-disconnect option is used to ensure that any old interface IP address or default gateway is removed when the PPPoE session goes down. This ensures that packets are routed correctly after a failover instead of being sent to the now unreachable gateway.

The idle-interval option allows you to automatically disconnect the PPPoE session after a certain period of inactivity. In this case, we do not want to do that. By setting it to zero, this feature is disabled and the PPPoE session will not be dropped due to inactivity.

The auto-connect option enables the NetScreen to attempt to reconnect to the PPPoE session if it is dropped. If this is not set, the connection must be manually brought up via the exec pppoe connect command, or by power-cycling the NetScreen. Clearly, this is not a desirable feature in our case; thus, we use auto-connect.

Another interesting aspect of this option is how it interacts with the automatic failover (if enabled). To give the primary untrust interface a good chance of recovering before a failover is initiated, set the auto-connect value lower than the failover hold-down setting, which is 30 seconds by default. This way, the PPPoE connection on the primary interface is retried before the failover is triggered. This might be enough to prevent a failover altogether depending on the reason for the failure of the PPPoE session.

Example: Advanced Configuration for ADSL Modem Plus ADSL Router

For this example, imagine a setup where the primary link is via an ADSL modem and the backup is via an ADSL router to a different ISP. They are used in this order to get the IP address assigned directly to the NetScreen. This way any NAT can take place on the NetScreen. The NetScreen provides more power and flexibility in this area than most ADSL routers commonly do, so it is the sensible thing to do.

To make matters a bit more interesting in this example, also assume that the primary ISP has assigned a static IP address to us (1.1.1.1) that should always be used, even if the remote end attempts to assign a different IP address during the PPP negotiation. Any decent ISP should be able to assign static IP addresses via PPPoE itself, but for the sake of this exercise, let's assume that this ISP cannot. The ISP's equipment is really bad at responding to the Link Control Protocol (LCP) Echo requests that are used to verify that the link is up. Unless more conservative timings are used on our end, the link will keep getting dropped despite actually being up and working fine. Furthermore, this ISP supports only Password Authentication Protocol (PAP); the considerably more secure Challenge Handshake Authentication Protocol (CHAP) is not supported.

From the CLI:

set vrouter trust-vr route 0.0.0.0/0 interface ethernet2 gateway 172.16.32.1

set failover auto

NOTE

Comments can be used in external NetScreen configuration files. They are removed when the configuration is loaded into the NetScreen, but can be very useful for documenting configurations in a noninterfering manner. Full-line comments start with a hash mark followed by a space (#). Half-line comments start with a space followed by a hash mark followed by a space (#).

From the Web Interface:

Go to Network | Interfaces | Edit | ethernet3.

Enter 1.1.1.1/24 for the IP address.

Click OK.

Go to Network | Interfaces | Edit | ethernet2.

Enter 172.16.32.2/30 as the IP Address and Netmask.

Click OK to save.

Go to Network | PPPoE | New.

Name this instance adsl.

Enter the username and password for the ISP.

Bind it to interface ethernet3.

Select PAP as the Authentication type.

Check the Static IP option.

Select the Clear on Disconnect option.

Set Auto-connect to 20 seconds.

Click OK to save.

Go to Network | PPPoE | PPP.

Set LCP Echo Retries to 20.

Set LCP Echo Timeout to 600.

Click OK.

Go to Network | Routing | Routing entries.

Select trust-vr.

Click New to add a new route.

Enter 0.0.0.0/0 as the IP Address and Netmask.

Select ethernet2 as the gateway interface.

Enter 172.16.32.1 as the gateway IP address.

Click OK to save the new route.

Go to Network | Untrust Failover | Automatic Failover and click OK.

IPSec Modes

IPSec in Windows Server 2003 has two different modes: tunnel mode and transport mode. Your choice of which IPSec mode to use depends on your organizational needs. We will take a look at how each of these works and when each is appropriately used.

Tunnel Mode

Tunneling refers to a method of encapsulating a data packet inside another packet and routing the new packet across a network. Tunnels are used to create VPNs that allow data to go across the Internet (or another public or nonsecure network) without compromising security, because the inner packet and its header information are not visible on the public network.

In tunnel mode, IPSec encrypts the IP header and the payload, thereby securing the entire IP packet. It is used primarily when end systems or gateways do not support the L2TP/IPSec or the Point-to-Point Tunneling protocol (PPTP). In other words, tunnel mode allows you to use IPSec to create a tunnel, in addition to encrypting the data within the tunnel, with servers that cannot use the traditional VPN tunneling protocols (L2TP and PPTP). However, Windows Server 2003 does not support using IPSec as the tunneling protocol for remote access VPNs; it is only supported between gateways, routers, and servers. Remote access clients must use PPTP or L2TP for VPN connections.

The entire packet is encrypted by either AH or ESP. These two protocols will be discussed in more detail in the “IPSec Protocols” section. The outer IP header contains the addresses of the tunnel endpoints, and the encapsulated IP header contains the ultimate source and destination addresses, as illustrated in Figure 10.2.

Figure 10.2. The IPSec Tunnel Mode

Tunnel mode is used to protect data traveling between different networks that must pass through an untrusted network (such as the Internet). Tunnel mode works in the following configurations:

■

Gateway to gateway

■

Server to gateway

■

Server to server

Data at Motion

While protecting information at rest is important, it is also critical to protect any information that goes over an untrusted network. Utilizing VPNs when data is sent over an untrusted network is critical to make sure the information cannot be intercepted or compromised. While many organizations typically do a pretty good job of making sure their laptops have VPN clients installed when they communicate over the Internet, the area that we see organizations have trouble is with untrusted clients. More and more people are accessing and connecting to corporate resources from the Web using an untrusted client. Two of the most common examples are personal computers from home and computers at international airports. Many executives travel internationally and many airlines have lounges where people can wait between flights. To make it easier for them to check email or work, many airlines often have computers that can be used to make it easier so someone does not have to turn on their computer between flights. The problem in these cases is the communication is usually encrypted with SSL but there is no protection of the data at rest. When users use the Web and SSL to access sensitive information, information it is often saved to the local hard drive of the untrusted system without the user realizing it. Since the system is untrusted someone else could potentially use the computer and access the sensitive information that the user inadvertently saved to that system. Therefore to provide both data in transit and data at rest protection, SSL VPNs are often used. An SSL VPN is an SSL connection that creates an encrypted RAM drive on the untrusted computer and all of the activity with the session is stored in the encrypted RAM drive. Now any file or information that is saved is in an encrypted area and because it is in memory, it is removed when the system is turned off. Now by using SSL VPNs an organization can ensure that their information is protected when it is going across an untrusted network and when it is stored on an untrusted computer.

National Infrastructure Firewalls

The most common application of a firewall involves its placement between a system or enterprise to be protected and some untrusted network such as the Internet. In such an arrangement for the protection of a national asset, the following two possibilities immediately arise:

Coverage—The firewall might not cover all paths between the national asset to be protected and the untrusted network such as the Internet. This is a likely case given the general complexity associated with most national infrastructure.

Accuracy—The firewall might be forced to allow access to the national asset in a manner that also provides inadvertent, unauthorized access to certain protected assets. This is common in large-scale settings, especially because specialized protocols such as those in SCADA systems are rarely supported by commercial firewalls. As a result, the firewall operator must compensate by leaving certain ports wide open for ingress traffic.

To address these challenges, the design of national security infrastructure requires a skillful placement of separation functionality to ensure that all relevant traffic is mediated and that no side effects occur when access is granted to a specific asset. The two most effective techniques include aggregation of protections in the wide area network and segregation of protections in the local area network (see Figure 3.4).

Aggregating firewall functionality at a defined gateway is not unfamiliar to enterprise security managers. It helps ensure coverage of untrusted connections in more complex environments. It also provides a means for focusing the best resources, tools, and staff to one aggregated security complex. Segregation in a local area network is also familiar, albeit perhaps less practiced. It is effective in reducing the likelihood that external access to System A has the side effect of providing external access to System B. It requires management of more devices and does generally imply higher cost. Nevertheless, both of these techniques will be important in national infrastructure firewall placement.

Effective protection of national infrastructure will undoubtedly be expensive due to the increased management of devices.

A major challenge to national infrastructure comes with the massive increase in wireless connectivity that must be presumed for all national assets in the coming years. Most enterprise workers now carry around some sort of smart device that is ubiquitously connected to the Internet. Such smart devices have begun to resemble computers in that they can support browsing, e-mail access, and even virtual private network (VPN) access to applications that might reside behind a firewall. As such, the ease with which components of infrastructure can easily bypass defined firewall gateways will increase substantially. The result of this increased wireless connectivity, perhaps via 4G deployment, will be that all components of infrastructure will require some sort of common means for ensuring security.

Smart devices have added another layer of complexity to network protection.

Massive distribution of security to smart wireless endpoint devices may not be the best option, for all the reasons previously cited. It would require massive distribution, again, of the security responsibility to all owners of smart devices. It also requires vigilance on the part of every smart device owner, and this is not a reasonable expectation. An alternative approach involves identifying a common transport infrastructure to enforce desired policy. This might best be accomplished via the network transport carrier. Network service providers offer several advantages with regard to centralized security:

Vantage point—The network service provider has a wide vantage point that includes all customers, peering points, and gateways. Thus, if some incident is occurring on the Internet, the service provider will observe its effects.

Operations—Network service providers possess the operational capability to ensure up-to-date coverage of signatures, updates, and new security methods, in contrast to the inability of most end users to keep their security software current.

Investment—Where most end users, including enterprise groups, are unlikely to have funds sufficient to install multiple types of diverse or even redundant security tools, service providers can often support a business case for such investment.

For these reasons, a future view of firewall functionality for national infrastructure will probably include a new aggregation point—namely, the concept of implementing a network-based firewall in the cloud (see Figure 3.5).

A firewall in the cloud may be the future of firewall functionality.

In the protection of national infrastructure, the use of network-based firewalls that are embedded in service provider fabric will require a new partnership between carriers and end-user groups. Unfortunately, most current telecommunications service level agreements (SLAs) are not compatible with this notion, focusing instead on packet loss and latency issues, rather than policy enforcement. This results in too many current cases of a national infrastructure provider being attacked, with the service provider offering little or no support during the incident. Obviously, this situation must change for the protection of national assets.

Dual-Homed Host

A dual-homed host has two network interfaces: one connected to a trusted network, and the other connected to an untrusted network, such as the Internet. The dual-homed host does not route: a user wishing to access the trusted network from the Internet, as shown in Figure 5.28, would log into the dual-homed host first, and then access the trusted network from there. This design was more common before the advent of modern firewalls in the 1990s, and is still sometimes used to access legacy networks.

Remote Access and VPN

Diffie–Hellman Key Exchange Protocol

Based on public key cryptography, the D-H algorithm is a method for securely exchanging a shared key between two parties over an untrusted network. It is an asymmetric cipher used by several protocols including SSL, SSH, and IPSec. It allows two communicating parties to agree upon a shared secret, which can then be used to secure a communication channel.

The D-H algorithm requires each of the communicating parties to have public/private key pairs. By the sender using a private key and the receiver using a public key, the sender and the receiver compute a shared secret number. If the same public/private key pairs of the same sender and recipient are used, both parties will arrive at the same number.

This number is then used as a shared symmetric cryptographic key and can be used as a key-encryption key (KEK) or to generate a content-encryption key (CEK). The CEK is commonly known as a session key. To prevent the same key from being generated in subsequent communication sessions, a random value is incorporated into the initial KEK generation process. This ensures that the resulting KEK is unique for each communication session.

In IPSec implementations, this uniqueness of keys from one key exchange to another is used to provide perfect forward secrecy. D-H is also used by the Internet Key Exchange (IKE) Protocol during session setup, where the identities of the communicating parties established and preferred encryption methods and shared secrets need to be agreed upon between the two entities.

D-H is used in SSL for authentication of the communicating parties and the negotiation of session keys and encryption methods.

When establishing a communication session, the SSH client and server compute a shared secret using the D-H algorithm. A hash of this shared secret is then generated and used as the session key to encrypt the communication channel.

What are trusted and untrusted networks?

What does untrusted network mean?

What is the relationship between the untrusted network the firewall and the trusted network?

Is the boundary between the trusted and untrusted network?