What happens if no default gateway is configured on a computer?

Automatic Determination of Interface Metric

As noted in Exercise 3.01, “Configuring the TCP/IP Protocol Manually” and shown earlier in Figure 3.5, the automatic metric feature is enabled by default. The purpose of the automatic metric feature is to determine the speed of the interface for each default gateway and to assign the metric, which is the cost of using a particular route.

The metric is weighted by the number of hops to the destination. The number of hops to any host on the local subnet is one. Every router that must be used to reach the destination is another hop. When it is determined that there are multiple routes to the same destination, the metric is evaluated to determine which is the lowest metric and this the fastest route to the destination.

Exercise 3.02

Determining the Metric for the Default Gateway

In the following exercise, you will learn how to use the route print command to determine the metric for the default gateway on your network.

Open a command prompt window.

Type route print. You will see a route table, as shown in Figure 3.8.

Examine the route table.

Notice the Network Destination list. The destinations are described in Table 3.1.

Table 3.1. Description of Routes in the Route Table

The metric for the loopback adapter and the limited broadcast is always 1. The other addresses have a metric based on the cost of using that route for that network adapter. With multiple network adapters, a multihomed computer, the route table would indicate a different metric for each default route, but only one would be used. Table 3.2 shows a configuration with identical network adapters: one adapter on the 192.168.69.0/24 network and the other on the 192.168.70.0/24 network.

Table 3.2. Description of Routes with a Multihomed Computer

Note that the metric for the default route for the second network, on the adapter for the 192.168.70.100 interface, is higher than the metric for the default route on the 192.168.69.111 interface. This indicates that the 192.168.69.111 network adapter is first in the binding order. Since the metric for the default gateway for the second adapter is higher than the first network adapter, the second gateway is never used and is not necessary.

You can use the route command to add routes and change metrics. The command is route add − p Destination Mask Gateway IF Metric, where:

Destination is the network destination address.

Mask is the appropriate subnet mask defined for the destination network.

Gateway is the address of the router interface used to interface with the network.

IF is the interface you want to associate this route to.

Metric is the metric for this gateway.

The − p parameter specifies that you want to make this route persistent, so that it will be there if you reset the adapter or restart the machine. If you do not specify − p, the route is temporary and will not be saved.

If you want to delete a route, use the route delete Destination command to remove the destination route from the route table.

You can disable the automatic metric feature by accessing the properties for the desired connection, as follows:

Select Internet Protocol (TCP/IP) and click Properties.

In the Internet Protocol (TCP/IP) Properties dialog box, click the Advanced button.

Uncheck Automatic metric.

Provide an Interface metric. The minimum value is 1.

Click OK.

Run the route print command. What changed? You will notice that all of the metric values are now 1.

You can change the values manually, which can allow you to redirect traffic over a slower interface that would normally have a higher metric.

Test Day Tip

You should be familiar with the route table, know how to use the route print command, and understand how to use the information in this table to troubleshoot TCP/IP connectivity problems. More details are provided in the “Creating a Subnetting Scheme” and “Troubleshooting IP Addressing” sections later in this chapter.

Gateways

Although we’ve mentioned the term default gateway earlier in this chapter, we have not really gone into much detail about what a gateway is. Basically, a gateway is a device that connects networks using different communication protocols in a way that allows for information to pass from one network to the other. It both transfers and converts the information into a form that can be used by the protocols on the receiving network. Think of it as a TCP/IP node that has routing capabilities. In other words, a gateway is a kind of router. A router, by definition, is a device or computer that sends packets between two or more network segments as necessary, using logical network addresses, most often IP addresses. The default gateway is the path used to pass information when the device doesn’t know where the destination is. More directly, a default gateway is a router that connects your host to remote network segments. It’s the exit point for all the packets in your network that have destinations outside your network.

Configuring & Implementing…

New & Noteworthy…

Configuring & Implementing…

Configuring Multiple Gateways

To install multiple gateways, follow these steps:

1.

Select Start | Control Panel | Network Connections, and then select the connection you want to configure.

2.

Click Properties and double-click Internet Protocol (TCP/IP) to open the Internet Protocol (TCP/IP) Properties dialog box, shown in Figure 4.5.

Figure 4.5. Internet Protocol (TCP/IP) Properties

3.

Click the Advanced button to open the Advanced TCP/IP Settings dialog box, shown in Figure 4.6.

Figure 4.6. The IP Settings Tab of the Advanced TCP/IP Settings

4.

On the IP Settings tab, you can add default gateways as you deem necessary. Click the Add button, and then type the gateway address in the Gateway text box, as shown in Figure 4.7.

Figure 4.7. Enter the Gateway Address

5.

The metric, as we have discussed previously, provides a relative cost of using this gateway, or route. When multiple gateways are available for a particular IP address, the gateway with the lowest metric will be used. If for some reason the Windows Server 2003 computer cannot communicate with the first gateway, it will try to use the gateway with the next lowest metric. By default, Windows Server 2003 assigns the metric to the gateway automatically. If you want to do so manually, uncheck the Automatic metric check box and enter a metric in the text box.

2.2.1.2.4 Data Flow

Figure 2.4 shows the flow of VPN data traffic across the service provider’s backbone from one customer site to another. Assume that Host 10.2.3.4 at Site 2 wants to communicate with Server 10.1.3.8 at Site 1.

Host 10.2.3.4 forwards all data packets for Server 10.1.3.8 to its default gateway. When a packet arrives at CE2, it performs a longest-match-route lookup and forwards the IPv4 packet to PE2. PE2 receives the packet, performs a route lookup in VRF GREEN, and obtains the following information:

MPLS label that was advertised by PE1 with the route (label=222)

BGP next hop for the route (the loopback address of PE1)

Outgoing subinterface for the LSP from PE2 to PE1

Initial MPLS label for the LSP from PE2 to PE1

User traffic is forwarded from PE2 to PE1 using MPLS with a label stack containing two labels. For this data flow, PE2 is the ingress LSR for the LSP and PE1 is the egress LSR for the LSP. Before transmitting a packet, PE2 pushes the label 222 onto the label stack, making it the bottom (or inner) label. This label is originally installed in VRF GREEN when PE2 receives PE1’s IBGP advertisement for the route to 10.1/16. Next, PE2 pushes the label associated with the LDP- or RSVP-based LSP to PE1 (the route’s BGP next hop) onto the label stack, making it the top (or outer) label. After creating the label stack, PE2 forwards the MPLS packet on the outgoing interface to the first P router along the LSP from PE2 to PE1. P routers switch packets across the core of the provider’s backbone network based on the top label, which is exchanged using LDP/RSVP. The penultimate router to PE1 pops the top label (exposing the bottom or inner label) and forwards the packet to PE1.

When PE1 receives the packet, it pops the label, creating a native IPv4 packet. PE1 uses the bottom label (222) to identify the directly attached CE, which is the next hop to 10.1/16. Finally, PE1 forwards the native IPv4 packet to CE1, which forwards the packet to Server 10.1.3.8 at Site 1.

ISA 2004 Multinetworking

The ISA 2004 marketing team has assigned the term “multinetworking” to the ISA firewall's new and improved networking feature set. Like most marketing terms, it's hard to pin down exactly what multinetworking actually means. It could mean the ISA firewall's ability to control access between any two networks using stateful filtering and stateful application-layer inspection. It could mean the ISA firewall's ability to create multiple types of Network Objects and use those network objects in Access Rules. Or, it could mean the ability to create multiple internal networks, multiple DMZ networks, and multiple external networks. Or, it could mean all of the above. Like the term “stateful,” it has no specific meaning and can be used in just about any way you like.

WARNING

One thing that multinetworking does not mean is the ability to support multiple default gateways on the ISA firewall. This means you can't have one external interface connected to a DSL line, a second external interface connected to a cable line and a third external interface connected to a T1 line, and expect to use all three interfaces to connect to the Internet. While you can use all of these interface to connect to Internet-based computers, only one of these interfaces can be used to connect to the Internet at large, because the other two interfaces will require explicit routing table entries to connect to specific Internet hosts or networks. If you wish to use multiple Internet connections to connect to the Internet at large, check out Rainfinity's RainConnect. RainConnect allows you to connect multiple interface interfaces on the ISA firewall, and also provides for bandwidth aggregation and prioritization. It also allows you to publish resources on a protected network behind the ISA firewall and have those published resources available through all Internet connections and load balance them across the connections.

To get a better idea of how the ISA 2004 multinetworking model works, let's look at a network diagram. Figure 4.22 shows a typical ISA firewall multinetworking configuration.

There are four protected networks directly connected to the ISA firewall in this example. A protected includes all networks defined on the ISA firewall except for the default External network. The default External network represents the Internet. The four protected networks in the diagram are the Wireless Network, DMZ, Internal Network and Services Network.

Using the ISA firewall's new network model, you could create the following access rules:

Wireless clients can access the Internet but are not allowed access to any of the other protected networks. Users on the Wireless segment can VPN to the ISA firewall and gain access to the Internal network segment if access is required.

Servers on the DMZ segment are allowed access to servers on the Services Network segment. For example, the Public Web server could be granted access to the Exchange Server, but not the SQL server. In this way, the Public Web server can act as an RPC over HTTP proxy for Outlook 2003 users. Hosts on the DMZ segment would not be allowed access to the Internet and they would not be allowed access to any other protected network segments.

Users and machines on the Internal network can be granted access to resources on the Internet and the Services network. This allows them to use selected resources that you allow on the Internet and also have access to the Exchange Server. Users on the Internal network would not have access to resources on the Wireless network or the DMZ segment.

Machines on the Services Network can be granted access to selected sites on the Internet (such as the Windows Update site). They could also be allowed restricted access to the Internal network. For example, the Exchange Server may be a member of the Internet network domain and need to communicate with domain controllers on the Internal network.

VPN clients can be allowed access to resources on the DMZ, Internet, Internal Network and Services Network. You can control which VPN clients can access resources on which network via user/group based access control. For example, you may have a user group named ExchangeUsers and you want them to use the Outlook MAPI client to connect to the Exchange Server, but no other resources. You can create an access rule to allow members of the group access to the Exchange Server, but only using the secure Exchange RPC calls to get to the Exchange Server. If members of this group attempted to use any other protocol, such as HTTP or CIFS, their connection attempts would be denied.

The multinetworking features allows you very granular access control over what destination a host on any network can access. Even the VPN clients, which traditionally had access to everything on the corporate network once they connected, can now be locked down tight after establishing the VPN link.

Gateway

A gateway is a point in the process where flows converge or diverge. The default gateway (empty diamond) is an exclusive or. It provides for inputs from alternative paths to proceed on a single output path. If there are multiple output paths, only one can become active as specified by conditions on the outgoing paths. The exclusive or may also be designated with an X in the diamond. An and gateway is designated by a plus sign (+) in the diamond. It requires all inputs (from concurrent paths) to be active before it proceeds, and multiple outputs proceed concurrently, creating parallel paths. It may be called a fork for multiple outputs or a join for multiple inputs. There are other less frequently used gateway types designated with other icons. The complex gateway is designated with an asterisk (⁎). It indicates that the action depends on a complex computation.

2.3.4 Networking device classes

Even though a network device is listed in the previous sample output (“Intel[R] PRO/100 VM Network,” lines 39 through 42) with the motherboard, controller, and the port classes, the sample does not show the network configuration of a network adapter. The classes used in Samples 2.4 through 2.7 do not allow the retrieval of such information. For this, WMI implements some other interesting classes to retrieve and set the network adapter configuration. These classes are listed in Table 2.5.

Table 2.5. The Networking Device Classes

Besides the hardware information related to an adapter, with the help of these classes it is possible to gather information about the adapter protocol configuration (see Samples 2.8 through 2.11). Although the Win32_NetworkAdapterConfiguration class can retrieve IP and IPX network configurations, the script focuses on the IP configuration only (to retrieve the IPX configuration, the code sample can easily be extended by displaying some additional class properties).

As usual, Sample 2.8 starts with the command-line parameter definition (lines 13 through 19), continues with the command-line parsing (lines 56 through 75), and performs the WMI connection (lines 77 through 80).

Notice that the script has a Boolean parameter called/List (lines 15, 56, and 57). This parameter requests the list of adapters available in the system. To extract the network information from one specific network adapter, it is necessary to determine which Win32_NetworkAdapter Key property to use. Because the Key is an index representing the adapter number (called the DeviceID), it is easier to use the name of the network adapter. To do so, the script lists the network adapter names, as follows:

Because the Win32_NetworkAdapter class does not define the adapter name property as a Key property for the class, the script does not instantiate the adapter directly. Instead, the script creates a collection that lists all available adapters. The collection of adapters is retrieved in Sample 2.9 at line 83, while the existing adapter enumeration starts at line 85. If the /List+ switch is specified, the script uses the same collection to list all adapter names available (lines 83 and 87). If the /List+ switch is not specified, the script searches for a match between the name given on the command line and the existing adapter names (line 89). It was possible to use a WQL query to find the adapter name (with the ExecQuery method of the SWBemServices object), but because we usually have a few number of adapters in a computer system, the enumeration technique is acceptable. Moreover, the same loop (lines 85 through 314) is used to list adapters (line 87) or to select the adapter to work with (line 89).

Once a match is found, the script displays all adapter properties (lines 89 through 313). For instance, properties such as the adapter name (lines 90 through 93), state (lines 99 through 103), type (lines 105 through 108), and MACAddress are listed (lines 113 through 116).

You will notice at line 99 the test on the adapter NetConnectionStatus property. If the adapter is enabled, the adapter type, the network connection status, and the MAC address properties are displayed (lines 105 through 116). If the NetConnectionStatus property has a value of 0 (line 99), this means that the adapter is disabled (lines 100 through 103). Table 2.6 summarizes the connection status values resolved by the NetworkConnectionStatus() function included at line 22 and invoked at line 111.

Table 2.6. The Connection Status Values

Next, the script retrieves the hardware resource information used by the adapter: IRQ, DMA, I/O Port, and memory address (see Sample 2.10). The script bases its research on the associations defined in the CIM repository. For instance, Figure 2.2 shows the associated instances available for one network adapter. This should ease the understanding of the relationships that exist between the adapter and the hardware resources.

The script uses an association class called Win32_AllocatedResource to retrieve the instances representing the hardware resources. As we have seen before, the hardware resources are represented by instances of the Win32_IRQResource, Win32_DMAChannel, Win32_PortResource, and Win32_DeviceMemoryAddress classes (lines 136 through 157). Each of these classes is classified in the motherboard, controller, and port classes discussed in the previous section.

To retrieve instances of the Win32_AllocatedResource class that correspond to the adapter (lines 128 through 131), the script uses the Key property (called Index) of the Win32_NetworkAdapter class with the index number of the adapter instance (line 130) previously retrieved in the script with the enumeration at line 85 (see Sample 2.9).

Once hardware resources are examined, the script starts to look at the IP protocol settings (see Sample 2.11). For this, it uses the Win32_NetworkAdapterConfiguration class. This class exposes a large number of properties related to the DHCP settings (lines 188 through 204), IP address settings (lines 208 through 223), DNS settings (lines 226 through 249), WINS settings (lines 252 through 285), and IP Security/Filtering settings (lines 288 through 309).

To retrieve the instance of the Win32_NetworkAdapterConfiguration that corresponds to the adapter (lines 180 through 182 in Sample 2.11), the script uses the Key property (called Index) of the Win32_NetworkAdapterConfiguration class with the index number of the adapter instance (line 182) previously retrieved from the script with the enumeration at line 85 (see Sample 2.9).

You will note that Sample 2.10 jumps from line 159 to Sample 2.11 at line 180. Lines 160 through 179 are not discussed in this section, because they use the Win32_NetworkProtocol class. This class is explained in section 2.4.7 (“Networking classes”) in this chapter (see also Sample 2.42).

When the script is executed, the output is as follows (the section between lines 17 and 63 is skipped, since it is provided by the Win32_NetworkProtocol class examined in section 2.4.7).

Note that for the “IP address” (line 65) and the “Default Gateway and metric” (line 67) properties are displayed on the same line. This piece of code (see Sample 2.11, lines 208 through 211 and lines 216 through 219) takes advantage of the DisplayFormattedProperty() function capabilities (see Sample 1.6, “The DisplayFormattedPropertyFunction.vbs function”) to display two properties that are usually shown together:

The IP address and its mask

The Gateway address and its metric

This allows an output similar to the one obtained with the IPConfig.Exe utility.

The previous scripts are able to retrieve information from the real-world manageable entities (such as a network adapter), but at no time do the samples show how to modify the information retrieved. However, the Win32_NetworkAdapterConfiguration class exposes an important set of methods that allows the modification of the network adapter configuration. Table 2.7 lists the miscellaneous methods.

Table 2.7. The Win32_NetworkAdapter Configuration Methods

To gather more information about the parameters required by these methods, you can use the LoadCIMInXL.wsf script (see Sample 4.32 in the appendix) or refer to the Platform SDK. Because each method corresponds to a network setting, the command-line parameters required by the script represent the parameters required by each Win32_NetworkAdapterConfiguration method. Before diving into the script code (see Sample 2.12), let's examine the script parameters. This demonstrates the script capabilities in terms of network device configuration. The following output shows the script usage information with some command-line syntax samples at the end:

The biggest challenge of this script is to properly parse the command line. Sample 2.12 is 492 lines in length, but the command-line parsing easily takes 50 percent of the code (from line 160 through 319). This comes from the fact that the script exposes more than 20 command-line parameters, while some Win32_NetworkAdapterConfiguration class methods require one or more arrays as input parameters. On a command line, it is only possible to read strings. To work around this difficulty, Sample 2.12 includes a subroutine called ConvertStringInArrayFunction.vbs (line 65) and uses the SplitArrayInTwoArrays() function (lines 456 through 487). These two functions are helper functions to ease the command-line parsing and the string to array conversion required by some of the Win32_NetworkAdapterConfiguration class method parameters. Note that the command line only accepts keywords and does not make use of any keywords starting with a backslash. The script code configuring a network adapter is listed in Sample 2.12 (for the command-line parsing) and in Sample 2.13 (for the WMI network adapter configuration).

Each command-line parameter corresponds to a Win32_NetworkAdapterConfiguration method and uses the name of the method. Although it is interesting to look at the code in detail, we do not examine every parameter because Sample 2.12 accepts more than 20 parameters. Once the most typical parameters are explained, all other parameters parsing use the same scripting logic. Moreover, the scripting technique and principles to analyze command-line parameters in the next samples are the same. This allows us to focus on the WMI coding only. For Sample 2.12, we examine the code corresponding to the following command-line parameters:

EnableDHCP

ReleaseDHCPLease

ReleaseDHCPLeaseAll

RenewDHCPLease

RenewDHCPLeaseAll

EnableStatic

SetIPConnectionMetric

SetGateways

SetDeadGWDetect

EnableIPSec

DisableIPSec

EnableIPSecFilter

For each of these parameters, we also examine the corresponding WMI coding shown in Sample 2.13. Before configuring settings on the desired network adapter, an instance of the considered network adapter is retrieved at line 334. At line 335, the script also retrieves an instance from the Win32_NetworkAdapterConfiguration class. We will see further during the script code analysis why we need to do this.

The script code analysis is as follows:

EnableDHCP: Once this keyword is given on the command line, the script configures the adapter as a DHCP client. The keyword presence is tested at line 186 and the DHCP configuration is performed from line 345 through 348. The Win32_NetworkAdapterConfiguration EnableDHCP method does not require a parameter (line 346).

ReleaseDHCPLease: From a coding technique point of view, this command-line parameter works the same as the previous one. However, once the keyword is given on the command line, the script releases the adapter DHCP IP address. The keyword presence is tested at line 189 and the DHCP IP address release is performed from line 350 through 353. The Win32_NetworkAdapterConfiguration ReleaseDHCPLease method does not require a parameter (line 351).

ReleaseDHCPLeaseAll: Again, from a coding technique point of view, this command-line parameter works the same as the previous ones. However, once the keyword is given, it releases the DHCP address on all network adapters available in the computer. The keyword presence is tested at line 192, and the DHCP IP address release is performed from line 355 through 358. Note that the method invocation is a bit unusual (line 356). Because the ReleaseDHCPLeaseAll method does not relate to a specific network adapter (since it releases the IP address of all network adapters in the computer), the method is not invoked from the network adapter instance but from the network adapter class instance (line 356). The network adapter class instance is created at line 335, while the network adapter instance is created at line 334.

All methods that relate to a network setting that is not specific to a network adapter must be invoked from the class instance instead of the network adapter instance. These methods are defined in the CIM repository as static methods and contain a specific qualifier called static set on True. This specific qualifier method can be viewed with WMI CIM Studio, as shown in Figure 2.3. In this figure, we clearly see that the ReleaseDHCPLeaseAll method contains the static qualifier, while the ReleaseDHCPLease method does not contain this qualifier.

The same rule applies for the following Win32_NetworkAdapterConfiguration methods, since these methods are not specific to an adapter but apply to all adapters available in the system:

ReleaseDHCPLeaseAll (line 356)

RenewDHCPLeaseAll (line 366)

SetDeadGWDetect (line 386)

SetDNSSuffixSearchOrder (line 401)

EnableWINS (line 413)

EnableIPFilterSec (line 442)

All these methods are static methods and must be invoked from a class instance. We see with further samples that there are other classes exposing static methods. This is not a peculiarity related to the Win32_NetworkAdapterConfiguration class only. Classes exposing static methods must all be used in the same way. Let's continue with the remaining methods:

ReNewDHCPLease: The ReNewDHCPLease keyword works in the exact same way as the ReleaseDHCPLease from a coding point of view. However, it requests a new DHCP IP address. The keyword presence is tested at line 195, and the DHCP renewal operation is performed from line 360 through 363. The Win32_NetworkAdapterConfiguration ReNewDHCPLease method does not require any parameter (line 361).

ReNewDHCPLeaseAll: The ReNewDHCPLeaseAll keyword is coded in the exact same way as the ReleaseDHCPLeaseAll. However, it requests a new DHCP IP address for all DHCP-enabled network adapters. The keyword presence is tested at line 198 and the DHCP renewal operation is performed from line 365 through 368. The Win32_NetworkAdapterConfiguration method ReNewDHCPLease does not require any parameter (line 366). This method is a static method similar to the ReleaseDHCPLeaseAll method and is invoked from the Win32_NetworkAdapterConfiguration class instance created at line 335.

EnableStatic. This command-line parameter requires two arrays as parameters. One array contains the IP addresses, while the second array contains the corresponding subnet masks. This keyword with its parameters must be given on the command line in the following format:

The keyword presence is tested at line 201, and the parameters are parsed and converted in two arrays from line 203 through 207. Note the comma to separate the IP addresses if the network adapter is multihosted. We clearly have a direct application of the ConvertStringInArray() and SplitArrayInTwoArrays() functions to help with the command-line conversion into two arrays (lines 203 and 204). The IP address configuration is performed from line 370 through 373. The Win32_NetworkAdapterConfiguration method EnableStatic uses the two arrays as parameters (line 371).

SetIPConnectionMetric. This command-line parameter requires one parameter that contains the IP metric of the network adapter. The keyword must be given on the command line in the following format:

The keyword presence is tested at line 211, and the parameter value is parsed and converted to an integer from line 212 through 215. The metric configuration is performed from line 375 through 378.

SetGateways: This command-line parameter requires two arrays as parameters. One array contains the gateway IP addresses, while the second array contains the corresponding gateway metrics. The keyword must be given on the command line in the following format:

The keyword presence is tested at line 217, and the parameters are parsed and converted in two arrays from line 218 through 225. Note the “m” letter to separate the metric from the IP gateway address and the comma to separate the gateway IP addresses if several gateways are specified. Again, we clearly see the use of the ConvertStringInArray() and SplitArrayInTwoArrays() functions to help with the command-line conversion into two arrays (lines 219 through 220). The IP address configuration is performed from line 380 through 383. The Win32_NetworkAdapterConfiguration method SetGateways uses the two created arrays as parameters (line 381).

SetDeadGWDetect: This command-line parameter requires one parameter, which contains a Boolean value, to determine if the dead gateway detection mechanism must be enabled or disabled. The keyword must be given on the command line in the following format:

The keyword presence is tested at line 227 and the parameter value is parsed from line 228 through 237. The dead gateway detection configuration is performed from line 385 through 388. Note the use of the static method, since the dead gateway detection mechanism does not relate to a specific network adapter.

EnableIPSec, DisableIPSec, and EnableIPSecFilter. It is important to note that these methods are used to configure the IP filtering parameters of the network adapter. Therefore, these methods have no relationship with the configuration of the IPSec protocol, which is totally different. Usually, two of these three command-line parameters are used together. The EnableIPSec requires one parameter that contains three arrays. These arrays contain the IP port numbers to be filtered in the TCP/IP configuration. Setting the IP port numbers is not enough to activate the IP filtering. The IP filters are only enabled if the EnableIPSecFilter command-line parameter is specified. The EnableIPSecFilter accepts one parameter that contains a Boolean value to enable or disable the IP filters. The keywords must be given on the command line in the following format:

To parse the EnableIPSec parameters, the ConvertStringInArray() functions is used (lines 294 through 297). Notice that each array is separated on the command line by a comma (line 294), while a semicolumn separates each item in the array (lines 295 through 297). Each array corresponds to the TCP ports, UDP ports, and protocol filters, respectively. The execution of the EnableIPSec method is made in the script at the level of the adapter instance (line 432), while the EnableIPsecFilter static method is executed at the level of the Win32_NetworkAdapterConfiguration class instance (line 442). This implies that the activation of the IP filters is applied to any existing adapters in the system, while the IP filters are specific to one selected network adapter.

To disable the IP filters, the EnableIPSecFilter method is used with a Boolean parameter equal to False. To clear the IP filter values, the DisableIPSec command-line parameter is required. This parameter does not need any parameter, and its use is similar to the use of the ReleaseDHCPLeaseAll or ReNewDHCPLeaseAll command-line parameters. The keywords must be given on the command line in the following format:

All other parameters and methods from the Win32_NetworkAdapterConfiguration use the same logic and the same set of routines to parse and execute the command-line parameters. Some small changes in the command-line syntax are required based on the IP parameter specified. The following command-line sample shows how to use Sample 2.12 to completely configure a network adapter IP address. The sample also contains the resulting output:

As we can see, it is also possible to specify several command-line parameters at the same time. This forces the script to execute the various Win32_NetworkAdapterConfiguration methods one by one.

3.3 Multihoming Design Considerations

Architecture proposals for multihoming addressing issues such as failure detection, security, path selection and default gateway choice [19,32], should consider different design guidelines to meet one or more of the multihoming goals. Briefly, design considerations include adopting a locator-identifier split approach for end-host, end-site, and hybrid multihoming. Moreover, support at the network level, by modifying site exit routers is required for end-site and hybrid multihoming approaches.

The first guideline that should be considered relates to the locator-identifier split. Conventional IP architectures assume that the transport layer endpoints are the same entities as those used by the network layer. Thus, multihoming support based on a locator-identifier split requires that the transport layer identity is decoupled from the network layer locator in order to allow multiple forwarding paths to be used by a single transport session. Different approaches can be considered [16], either by modifying an existing protocol or by introducing a new layer. With the latter approach, upper layer protocols (e.g., applications) use endpoint identifiers to uniquely identify a session while the lower layer protocols (e.g., network) employ locators. If this approach is used, a mapping between an identifier and a locator is necessary. In a multihoming context, the locator-identifier mapping must be assured by a dynamic process so that a session can include different features, such as invariant endpoint identifiers throughout the session lifetime, and modification of locators to maintain end-to-end reachability.

In principle, this mapping can be maintained at any layer of the protocol stack. One reasonable choice is to place this functionality between the transport and the application layers, so that applications would interface with the endpoint identity protocol stack element through an Application Programming Interface (API). A second approach is to place a new layer between the transport and the network layers. With the modified layer approach, an existing layer can be adapted to perform the mapping between identifiers and locators. For instance, if the transport layer functionalities are modified, a set of locators can be bound to a session, and the locator is communicated to a remote entity. On the other hand, if the network layer is modified, there are two ways to achieve the desired functionalities. The first is by rewriting the packet header and the second is by using encapsulation to perform packet header transformation.

Another consideration for end-site and hybrid multihoming includes the modification of a site exit-router. End-site multihoming can be assured by a network element. For instance, an exit-router can perform packet rewriting for a given locator of a correspondent node. Nevertheless, this type of approach raises security concerns, which might be difficult to overcome. Redirection attacks are such an example, which may compromise routing, since packets for a destination can be redirected to any location [16,17]. Thus, the host should always be able to perform the endpoint-to-locator mapping on its own.

Scalability is of essence in any network architecture and multihoming is not an exception. Multihoming architectures should be scalable and need to strive to minimize the impact on routers and end-hosts. Basic connectivity must be always provided. If any modification is required it should be in the form of logically separating added functions from existing ones [28].

Security is also paramount for future architectures. Multihoming proposals should not introduce new security threats. For instance, multihoming solutions should be resilient to redirection attacks that compromise routing, new packet injection attacks (malicious senders can inject bogus packets into the packet stream between two communicating peers) and flooding attacks, which are normally associated with Denial of Service attacks [17].

Client Configuration Issues

Some of the issues that occur with manual configuration of IP addresses include duplicate addresses, invalid subnet masks, invalid default gateways, and invalid or missing host name resolution settings (such as DNS and WINS). To help identify the problem, start by typing ipconfig /all at a command prompt. Verify the information that is output by the command is correct, and then continue by using ping to help isolate the problem.

Ping the loopback address (127.0.0.1) to verify that the TCP/IP protocol stack is configured correctly on the local computer.

Ping the external IP address of the local computer to ensure the host is on the network and using a valid IP address; that is, no address conflicts.

Ping the IP address of the default gateway to verify that the default gateway is accessible and your local network configuration contains the correct subnet mask.

Ping the IP address of a remote host to verify that you can transmit data over the default gateway.

If you are not able to get traffic through to a site, but you are making it through the default gateway, then you should use tracert to identify the break in the route to the destination. An example of using tracert is shown in Figure 10.36, using the command line tracert www.syngress.com. To prevent the resolution of the hostnames that are shown in the results of Figure 10.36, specify the command with the –d option: tracert -d www.syngress.com.

Another utility that is more useful than tracert and ping combined is pathping. pathping is basically tracert and ping combined. The pathping command line utility provides an overview of latency and loss of data over a network at each hop from a source to a destination. The pathping utility will continue to ping over a specified period of time in seconds, but it will default to a value related to the total number of hops from the source to the destination. pathping computes the latency and packet loss from each router. This allows you to identify firewalls that block icmp but still provide information about latency on the hops past the firewall. You can also use pathping to zero in on problem routers, or slow connections on a route. An example of the command pathping destination address is shown in Figure 10.37. It is also possible to use pathping to trace the latency from a different source to the same destination. This provides a means for you to troubleshoot a connection on another machine, from a different client on the network. The command for specifying a different source address is pathping –i < IP address of source> destination address. It can also provide means for you to monitor a specific set of links in the route that may reduce the overall time to perform the trace. pathping command line options are case sensitive.

New & Noteworthy…

The Windows XP/Windows 2000 Routing Table

8.

Based on the partial routing table provided, what will happen to a packet with the IP address 133.94.228.52 and a default gateway of 133.94.128.1?

The packet will be sent directly to 133.94.228.52 for delivery.

The packet will be sent to 133.94.128.1 for delivery.

The packet will be sent to 133.94.140.26 for delivery.

The packet will be sent to 133.94.128.0 for delivery.

Using the routing table provided, identify the destination of a packet with the IP address of 66.22.221.19 and a default gateway of 66.22.192.1.

66.22.200.13

66.22.192.0

66.22.192.1

66.22.221.19

Network Packet Sniffing

In Chapter 10, we briefly touched on the concept of Address Resolution Protocol (ARP) poisoning when we talked about passive operating system fingerprinting. If we have access to the switch network, we can conduct an ARP poisoning attack; but this time we will use a program designed for Man in the Middle (MITM) attacks.

Figure 12.11 shows a network diagram illustrating how we will accomplish the MITM attack. Ettercap can generate an ARP spoofing attack specifically targeting the 192.168.1.100 disk. The ARP spoof attack will overwrite our victim's ARP table so that the victim routes all traffic through the BackTrack system, regardless of the final destination.

Figure 12.12 is the help menu for ettercap. The section of the menu we are most interested in is the “Sniffing and Attack options.” Because we only have one Ethernet connection on our BackTrack server, we cannot conduct a bridged attack. We also want to capture all traffic crossing the system, so we do not want to select the -o option for our example. We could limit ettercap to only sniff traffic on a particular port, such as Web traffic on port 80 using the -t option. However, there is no need to limit ourselves – we might as well capture all traffic in the hopes we can obtain sensitive data.

To begin, we will want to choose the -M option for our attack. However, the help information does not provide us with any understanding of what additional options are possible. The following text is an excerpt from the man page for ettercap:

-M, --mitm <METHOD:ARGS>

MITM attack: This option will activate the MITM attack. The MITM attack is totally independent from the sniffing. The aim of the attack is to hijack packets and redirect them to ettercap. The sniffing engine will forward them if necessary. You can choose the MITM attack that you prefer and also combine some of them to perform different attacks at the same time. If an MITM method requires some parameters, you can specify them after the colon (for example, -M dhcp:ip_pool,netmask,etc). The following MITM attacks are available:

arp ([remote],[oneway])

This method implements the ARP poisoning MITM attack. ARP requests/replies are sent to the victims to poison their ARP cache. Once the cache has been poisoned, the victims will send all packets to the attacker which, in turn, can modify and forward them to the real destination. In silent mode (-z option), only the first target is selected; if you want to poison multiple targets in silent mode, use the -j option to load a list from a file. You can select empty targets, and they will be expanded as “ANY” (all the hosts in the LAN). The target list is joined with the hosts list (created by the arp scan), and the result is used to determine the victims of the attack. The parameter “remote” is optional, and you have to specify it if you want to sniff remote IP address poisoning a gateway. Indeed, if you specify a victim and the GW in the TARGETS, ettercap will sniff only connection between them, but to enable ettercap to sniff connections that pass through the GW, you have to use this parameter. The parameter “oneway” will force ettercap to poison only from TARGET1 to TARGET2. Useful if you want to poison only the client and not the router (where an arp watcher can be in place). Example: the targets are /10.0.0.1-5/ /10.0.0.15-20/ and the host list is 10.0.0.1 10.0.0.3 10.0.0.16 10.0.0.18; the associations between the victims will be 1 and 16, 1 and 18, 3 and 16, 3 and 18 if the targets overlap each other; the association with identical IP address will be skipped. NOTE: if you manage to poison a client, you have to set correct routing table in the kernel specifying the GW. If your routing table is incorrect, the poisoned clients will not be able to navigate the Internet.

Based on the man page information on the MITM attack option, we can select either a remote or one-way method of ARP poisoning. The remote option allows us to sniff traffic that leaves the local area network through a gateway. The one-way option allows a bit more control within a network; selecting the one-way option will restrict ARP poisoning originating from the first target, which for us will be the victim system (192.168.1.100). If there are ARP manipulation detection controls in place, ARP spoofing the gateway router may be detected, and alarms sent to network security administrators.

Warning

A note in the man pages warns about routing tables within the attack system. If the attack system does not have the default gateway configured, any traffic destined to leave the network will fail to do so, increasing the possibility of detection. It is also possible to create a denial of service (DoS) attack if MITM attacks are not configured correctly.

Figure 12.13 is a screenshot of ettercap conducting an ARP attack against the De-ICE 1.100 disk. We can launch this attack using the following command: ettercap –M arp:oneway /192.168.1.100/. Based on the information already discussed, we know that this command will conduct ARP poisoning against our victim (and only our victim). Because we did not include a second target in the command, all communication leaving and entering our victim will be relayed through our attack host, regardless of the destination Internet Protocol (IP) address. If we had wanted to only capture data between our victim and the pWnOS server, we could add the additional IP address at the end of the executing command: ettercap –M arp:oneway /192.168.1.100/ /192.168.1.118/

As we can see in Figure 12.13, ettercap states it is poisoning the ARP table of 192.168.1.100 and is capturing traffic on Ethernet port eth0. This begins our attack.

If we move to the victim computer and try to log onto the Webmin portal on the pWnOS server, we are presented with the screen shown in Figure 12.14.

Once we enter a username and password, our victim will send the login information to the pWnOS server, which we will then intercept. Figure 12.15 is a screenshot of the login information captured on the BackTrack system. At this point of the penetration test, we have a username and password that should give us access to the target – if the permissions associated with the captured username are those of a system administrator, we could access the system with elevated privileges.

Tip

Ettercap can also be used to sniff traffic that is sent over encrypted channels, including both the Secure Shell (SSH) and Secure Sockets Layer (SSL) protocols.

Despite the fact we intercepted the username and password, the victim will not know anything is amiss. If the login is correct, data will continue to pass back and forth between the victim's system and the pWnOS server unfettered. As long as our MITM attack runs, we will continue to intercept traffic.

There are many other methods in which network data can be captured; exploits that can be used to obtain login credentials during a professional penetration test include as follows:

Domain name system (DNS) cache poisoning Allows an attacker to replace a victim's data request with malicious data. An example of an exploit using DNS cache poisoning is pharming.

DNS forgery This technique is a timing attack where a false DNS query response is returned to a system before the valid DNS query response returns. An example of an exploit using DNS forgery also includes pharming.

User interface (UI) redressing Permits a malicious user to replace a valid link on a Web site with a malicious link, using Web page scripting languages, such as JavaScript. Clickjacking is another term for UI redressing.

Border Gateway Protocol (BGP) hijacking This attack involves obtaining IP addresses by exploiting BGP broadcast communication and injecting invalid routing data. IP hijacking is another term for this attack, which is used for spamming or distributed denial-of-service (DDoS) attacks.

Port Stealing Layer 2 attack which redirects switch port traffic to the attack system by spoofing the victim's Media Access Control (MAC) address, thereby overwriting ARP tables in the network. This permits the attack system to intercept any returning communications intended for the victim. This can be used as a DoS attack or used to intercept traffic.

Dynamic Host Configuration Protocol (DHCP) spoofing An attack on a DHCP server, which obtains IP addresses using spoofed DHCP messages. It is used to push a valid system off the network by spoofing the victim's DHCP lease communications. DHCP spoofing is useful in conducting a DoS attack.

Internet Control Message Protocol (ICMP) redirection This attack sends ICMP redirects to a victim system, informing the system that a shorter network patch exists. This attack permits attack systems to intercept and forward traffic as a MITM attack.

MITM A method of intercepting traffic between two systems by relaying data, which can be cleartext or encrypted data.

The ability to intercept or passively collect data in a network provides the professional penetration tester a means to obtain login credentials or other sensitive data, which can be used to access the target system with elevated privileges.