Which Windows utility command can be used to create a custom management console?

Using netsh Commands

Administering your routing server through the Routing and Remote Access console is easy, but in order to pass the exam, as well as get by in the real world, you need to know how to use the command-line utility netsh, introduced in Chapter 3. You might wonder why anyone would want to use the command line when a perfectly acceptable and easy-to-use console is available. There are two main reasons:

You can administer a routing server much more quickly from the command line. This might be especially important over slow network links.

You can administer multiple routing servers more efficiently and consistently by creating scripts using these commands, which can then be run on many servers.

The Netsh utility is available in the Windows 2000 Resource Kit and is a standard command in Windows XP and Windows Server 2003. This utility displays and allows you to manage the configuration of your network, including both local and remote computers. It is designed to simplify the process of creating command-line scripts such as batch files. The utility itself is little more than a command interpreter that connects and interfaces with a number of services and protocols through the aid of a number of dynamic link libraries (DLLs). Each of these DLLs provides the utility with an extensive set of commands that applies specifically to that DLL’s service or protocol. These DLLs are referred to as helper files, and sometimes helper files are used to extend other helper files.

You can use the Netsh utility to perform the following tasks:

Configure interfaces

Configure routing protocols

Configure filters

Configure routes

Configure remote access behavior for Windows 2000 and Windows Server 2003-based remote access routers that are running RRAS

Display the configuration of a currently running router on any computer

Use the scripting feature to run a collection of commands in batch mode against a specific router

The syntax for the Netsh utility is as follows:

netsh [-r router name] [-a AliasFile] [-c Context] [Command |

–f ScriptFile]

Context strings are appended to a command and passed to the associated helper file. The helper file can have one or more entry points that are mapped to contexts. The context can be any of the following: DHCP, ip, ipx, netbeui, ras, routing, autodhcp, dnsproxy, igmp, mib, nat, ospf, relay, rip, and wins. Under Windows XP, the available contexts include AAAA, DHCP, DIAG, IP, RAS, ROUTING, and WINS. Appending a specific context to the input string makes a whole different set of commands available that are specific to that context.

The easiest way to learn how the Netsh utility works is by viewing its help information. Open a command prompt window on your Windows Server 2003 computer and enter the netsh command at the prompt. The command prompt changes to the netsh prompt. Enter a ? to display a list of available commands, as shown in Figure 4.14. To see the subcontexts and commands that are available to use with the routing context, type routing? at the netsh prompt (or simply type netsh routing? at the command prompt), and then press Enter. You can get command-line help for each command by typing netsh, followed by the command, followed by ?.

Rather than entering commands through the netsh utility as shown in Figure 4.14, it is more efficient to use the DLLs without needing to load the Netsh shell. This reduces the amount of coding time required, and you can use multiple DLLs within a single script. To use Netsh commands this way, follow the netsh command with the name of the DLL and the command string. For example, to use the show helper command to see a complete list of the available DLLs, type netsh show helper, as shown in Figure 4.15.

As you can see in Figure 4.15, when the script is processed, you see the results of the script and then are returned to the command prompt, from which you can execute your next script.

Configuring & Implementing…

Using the RRAS Console

When you select to deploy the VPN server only, the Routing and Remote Access console will appear. To set up RRAS, click the Action menu and then select Configure and Enable Routing and Remote Access, as shown in Figure 14.24.

This will open the Routing and Remote Access Server Wizard. After you click Next on the Welcome page, you will see the Configuration page where you can select which RRAS services you want to deploy on the RRAS server. You can enable remote access (dial-up or VPN), Network Address Translation (NAT), both VPN and NAT, a secure connection between two private networks (site-to-site VPN), or you can do a custom configuration to select any combination of these, as shown in Figure 14.25.

To set up a VPN server only, without NAT, select the first option and then you will choose VPN on the Remote Access page that offers the selections of VPN and/or Dial-up, as shown in Figure 14.26.

On the next page of the wizard, you will need to select the network interface that is connected to the Internet, and by default the box is checked to enable static packet filtering for better security. When packet filtering is enabled, only VPN traffic will be able to access the server through the selected interface. See the VPN Connection page of the wizard in Figure 14.27.

On the IP Address Assignment page of the wizard, you can choose whether you want to use a DHCP server to assign IP addresses to your VPN clients automatically or whether you want addresses to be assigned from a range or ranges of addresses in a static pool that you define, as shown in Figure 14.28.

The next step in the wizard is to set up the server to work with a RADIUS server if you have one on your network that you want to use for authentication; this is the common practice when managing multiple remote access servers. If you choose to do this, you will set up the VPN server to forward authentication requests to your RADIUS server. If not, the requests will be authenticated locally. See the Managing Multiple Remote Access Servers page of the wizard in Figure 14.29.

If you choose to use RADIUS for authentication of your VPN users, you will need to enter the information for your primary and alternate RADIUS servers and the password used to access the RADIUS servers, as shown in Figure 14.30.

When you have completed the information required by the Routing and Remote Access wizard, you will be shown a summary of your choices, as illustrated by Figure 14.31.

Note that after the VPN server is set up, you still have to add local accounts for the users who will connect through the VPN, or ensure that they have accounts in Active Directory, and ensure that the accounts are enabled for RRAS connections.

When you click Finish on the last page of the wizard, there will be a short wait while the RRAS service starts. Then the Routing and Remote Access console will display, in the right pane, the message that “Routing and Remote Access is Configured on This Server,” as shown in Figure 14.32.

You can change configuration settings via the nodes in the left pane, including network interfaces, ports, remote access clients, remote access logging, IPv4, and IPv6.

If you click the Ports node in the left pane, and scroll through the ports displayed in the right pane, you will see that ports are available for SSTP, PPTP, L2TP, and IKEv2, as shown in Figure 14.33.

Configuring a NAT Connection

You can also manage the settings for a NAT interface from the Routing and Remote Access console. To access these settings, select the NAT/Basic Firewall entry under IP routing in the left column, and then select Action | Properties from the menu. The Properties dialog box is divided into four tabbed sections:

NAT / Basic Firewall On this tab, shown in Figure 5.3, you can enable or disable NAT for the connection. You can also enable a basic firewall, which prevents unauthorized traffic from the Internet from reaching the internal network. You can also use the Inbound Filters and Outbound Filters buttons to define IP filters to further secure the connection.

Address Pool Allows you to define the Internet addresses that will be used by the NAT server. Don’t confuse this with the pool of private addresses the server can assign to clients. At least one Internet address must be included here. You can also use the Reservations button to define an external address that always reaches the same internal client machine. This is useful if you need to run a Web server or other service and make it accessible over the Internet.

Services and Ports Allows you to enable various services, such as FTP and Simple Mail Transfer Protocol (SMTP), that will be accessible to Internet users, and define the internal machines these packets will be routed to.

ICMP Allows you to enable various types of diagnostic packets. These may be needed if you wish the NAT server to respond to PING or Traceroute diagnostics.

Change the Credentials the ISA Server 2000 Firewall uses for the Demand-dial Connection to the Main Office

The Local VPN Wizard created a demand-dial interface to use to call the main office VPN gateway. It also made assumptions about the naming convention you would use for the demand-dial interface you'll create at the main office. We don't like the assumptions the Local VPN Wizard made, so we're going to change the credentials used by the ISA Server 2000 VPN gateway's demand-dial interface when it calls the main office ISA firewall.

Perform the following steps to change the credentials used by the ISA Server 2000 VPN gateway's demand-dial interface to call the main office ISA firewall:

Open the Routing and Remote Access console, and expand the server name. Click the Network Interfaces node.

Right-click the Branch_Main demand-dial interface that appears in the right pane of the console, and click Set Credentials.

In the Interface Credentials dialog box, change the User name to Branch. Enter a password and confirm the password. The demand-dial interface we create at the main office will be named Branch. We will also create a user account on the main office ISA firewall with the name Branch. Write this information down because we're going to need it when we create the Branch user account at the main office ISA firewall. Click OK.

Restart the Routing and Remote Access Service.

NOTE

The name Branch will be the name of the demand-dial interface we create on the main office ISA firewall. You'll see how this works later in this article.

Controlling Maximum Session Time

Along with the idle timeout, you can define a maximum amount of time a client can remain connected to the server whether they use the connection or not. When your supply of incoming ports is limited, this is one way to ensure that ports are opened up to enable other users to connect.

The maximum session time is also defined in the Dial-in Constraints tab of a profile. Exercise 7.11 demonstrates how to change the idle timeout and session time for a profile.

Exercise 7.11

controlling idle and session times

Follow these steps to modify the idle and session times for a remote access policy’s profile.

From the Routing and Remote Access console, select Remote Access Policies in the left-hand column. A list of the current policies is displayed in the window.

Click one of the policies in the window to highlight it. Select Action | Properties from the menu.

The Policy Properties dialog box is displayed. Click the Edit Profile button.

The Edit Dial-in Profile dialog box is displayed, as shown in Figure 7.21. Check the box next to Minutes server can remain idle before it is disconnected and select a number of minutes.

Check the box next to Minutes the client can be connected and select a number of minutes.

Click OK to return to the Policy Properties dialog box.

Click OK to save your changes and return to the RRAS console.

DirectAccess and RRAS Better Together

If you recall how the Windows DirectAccess worked in the past, you will remember that there was a dedicated DirectAccess console. It looked a little bit like the UAG DirectAccess console but was limited compared to UAG. In Windows Server 2012 you get a single console, the Unified Remote Access Console, where you configure DirectAccess, remote access client VPNs, and site to site VPNs. This provides a single place of configuration, management, and monitoring of all remote access connections, regardless of how the connection was established.

But there is another reason why Unified Remote Access in Windows Server 2012 is a big advancement. If you had not set up DirectAccess using the Windows DirectAccess in the past, you might not know that the DirectAccess could not be configured as a remote access VPN server. There were a number of reasons for this, most of them related to the packet filters RRAS configured to support the remote access VPN client connections and also the DirectAccess Denial of Service Protection (DoSP), which prevented all IPv4 packets and all non-IPv6-protected packets from being forwarded by RRAS.

With the new Unified Remote Access console, Windows Server 2012 prevents these services from stepping on each other. Now you can have your DirectAccess, remote access VPN server, and site-to-site VPN gateway all on the same machine.

Remote Desktop Console Access

Many users require remote access to computers’ consoles. Naturally, some form of secure conduit like an IPSec VPN, SSH, or SSL tunnel should be used to ensure confidentiality of the connection, especially if the connection originates from outside the organization. See the VPN section above for additional details on this layer of the remote console access.

Remotely accessing consoles has been common practice for decades with protocols such as the clear-text and poorly authenticated rlogin and rsh on Unix-like operating systems, which leverage TCP port 513 and TCP port 514, respectively. Two common modern protocols providing for remote access to a desktop are Virtual Network Computing (VNC), which typically runs on TCP 5900 and Remote Desktop Protocol (RDP), which typically runs on TCP port 3389. VNC and RDP allow for graphical access of remote systems, as opposed to the older terminal-based approach to remote access. RDP is a proprietary Microsoft protocol.

Increasingly, users are expecting easy access to a graphical desktop over the Internet that can be established quickly and from any number of personal devices. These expectations can prove difficult with traditional VNC and RDP based approaches, which, for security purposes, are frequently tunneled over an encrypted channel such as a VPN.

A recent alternative to these approaches is to use a reverse tunnel, which allows a user who established an outbound encrypted tunnel to connect back in through the same tunnel. This usually requires a small agent installed on the user’s computer that will initiate an outbound connection using HTTPS over TCP 443. This connection will terminate at a central server, which the user can authenticate to (from outside the office) to take control of their office desktop machine. Two of the most prominent solutions that employ this style of approach are Citrix’ GoToMyPC and LogMeIn.

Integrating the DHCP Server with Routing and Remote Access

RRAS support is being implemented by more and more companies as their employees are beginning to work from their homes over fast DSL/Cable Internet services and VPN connections, in addition to traditional dial-up accounts. Most internal networks today use the TCP/IP protocol as the primary (or only) network/transport protocol for internal communication and resource sharing. In order to facilitate the internal use of TCP/IP for remote access, your RRAS server has to be able to allocate TCP/IP addresses to your dial-in clients, thus acting as DHCP servers.

You can configure your RRAS server to do this in one of two ways:

■

You can configure your RRAS server with a static pool of addresses that it will itself assign to dial-in clients.

You can configure the RRAS server to relay clients to your internal DHCP server. For the purpose of this section on DHCP server integration, we will discuss the latter method.

To configure your RRAS server to use DHCP, you first will need to set up a DHCP Relay Agent as described in Exercise 3.3. Next, you must configure your server to use the Dynamic Host Configuration Protocol (DHCP) option rather that the Static address pool option, as shown in Figure 3.41. To do so, perform these steps:

1.

Open the Routing and Remote Access console from within the Administrative Tools menu.

Right-click on the node for the RRAS server and select Properties.

Click the IP tab to display the DHCP configuration dialog window shown in Figure3.41.

Under IP Address assignment, select the Dynamic Host Configuration Protocol (DHCP) option button.

Click OK.

Hardening the Base ISA Firewall Configuration and Operating System

While the ISA firewall software does an exceptional job of protecting the firewall from attack, there are things you can do to further harden the ISA firewall configuration and the underlying operating system.

In this section, we'll discuss the following hardening and local security issues:

ISA firewall service dependencies You need to know what services the ISA firewall depends on before disabling services on the firewall. In this section, we'll present the list of ISA firewall software dependencies.

Service requirements for common tasks performed on the ISA firewall There are several maintenance tasks that you can run on the ISA firewall that depend on features provided by the underlying operating system. In this section, we'll examine some of these features and the services they depend upon.

Client roles for the ISA firewall client rules This ISA firewall may need to act as a network client to a variety of network services. In this section, we'll review some of the network client roles and operating system services required for the ISA firewall to fulfill those roles.

ISA firewall administrative roles and permissions Not all ISA firewall administrators are created equal. In this section, we'll discuss the ISA firewall administrative roles and how to provide users more granular control over the ISA firewall configuration and management.

ISA firewall lockdown mode The ISA firewall needs to protect itself and the networks dependent on it in the event that an attack shuts down the ISA firewalls Firewall Service. In this section, we'll discuss the ISA firewall's Lockdown Mode.

Connection Limits

The ISA firewall puts a limit on the number of connections made to or through it at any point in time. Connection limits allow the ISA firewall to block connections through the firewall for clients that may be infected with worms that attempt to establish large numbers of connections through the ISA firewall. Examples of such worms are mass mailing worms and the Blaster worm.

For Web Publishing Rules, you can customize a total number of connections limit by specifying a maximum number of concurrent connections in the Properties of the Web listener. Any new client requests will be denied when the maximum number of connections configured to the Web listener is reached.

You can limit the total number of UDP, ICMP, and other Raw IP sessions allowed by a Server Publishing Rule or Access Rule on a per-second basis. These limitations do not apply to TCP connections. When the specified number of connections is surpassed, new connections will not be created. Existing connections will not be disconnected.

You should begin by configuring low connection-limit thresholds. This enables the ISA firewall to limit malicious hosts from consuming resources on the ISA Server computer.

By default, connection limits for non-TCP connections are configured to 1000 connections per second per rule and to 160 connections per client.

Connection limits for TCP connections begin at 160 connections per client. You should not change these limits unless you notice that legitimate hosts are being blocked because the limiting is too low. You can determine if a host is being blocked because it has exceeded its connection limit by an associated Alert. The Alert will provide the IP address of the host exceeding its allowed number of connections.

Perform the following steps to configure connection limits:

1.

Click Start, point to All Programs, point to Microsoft ISA Server, and click ISA Server Management.

2.

Expand the server name in the left pane of the Microsoft Internet Security and Acceleration Server 2004 management console, and expand the Configuration node. Click the General node.

3.

Click Define Connection Limits in the details pane.

4.

On the Connection Limit tab (Figure 6.32), check the Limit the number of connections checkbox. You can then configure the number of Connections created per second, per rule (non-TCP) and Connection limit per client (TCP and non-TCP). Some machines may need access in excess of these numbers, such as busy published servers. In that case, you can click Add and select a Computer Set to apply the Customer connection limit value.

Figure 6.32. The Connection Limits Dialog Box

New connections will not be created after the specified number of connections is exceeded. However, existing connections will not be disconnected. Up to 1000 new connections are allowed per rule, per second by default. When this default limit is exceeded, an alert is triggered.

A log entry is recorded when the limit is exceeded:

▪

Action is Connection Denied

▪

Result code is FWX_E_RULE_QUOTA_EXCEEDED_DROPPED

You should limit the number of connections hosts can make to prevent flood attacks. Many requests are sent from spoofed source addresses when a UDP or IP flood attack occurs, and this can result in a denial of service.

Try the following when the limit is exceeded:

▪

If the malicious traffic appears to originate from an ISA firewall Protected Network, this may indicate a host on the Protected Network has a virus or worm infection. Immediately disconnect the computer from the network.

▪

Create a rule denying access to a computer set that includes the source IP addresses if the malicious traffic appears to originate from a small range of IP addresses on an external network.

▪

Evaluate the overall status of your network if the traffic appears to originate from a large range of IP addresses. Consider setting a smaller connection limit so that ISA Server can better protect your network.

If the limit has been exceeded due to a heavy load, consider setting a higher per-rule connection limit based on your analysis of your network's requirements.

In firewall chaining, and in some back-to-back ISA firewall scenarios, make sure to configure customized connection limits for the IP addresses of the chained server or back-end ISA firewall. Also, if your system publishes more than one UDP-based or raw IP-based service to the External network, you should configure smaller limits to help keep your network secure from flood attacks.

You can limit the total number of UDP, ICMP, and other Raw IP connections allowed per client. You can specify custom limits to apply to specific IP addresses. This is useful when you want to allow specific servers to establish more connections than allowed to other clients.

For TCP connections, no new connections are allowed after the connection limit is exceeded. Make sure you set connection limits high enough for TCP-based services, such as SMTP, so that SMTP servers can send outbound mail and receive inbound mail. For other connections (Raw IP and UDP), older connections are terminated when the connection limit is exceeded so that new connections can be created.

DHCP Spoof Attack Prevention

Some of you may want to use DHCP on the external interface of the ISA firewall so that it can obtain IP addressing information from your cable or DSL company's DHCP server. You might encounter problems with obtaining an IP address on the external interface when that interface is configured to use DHCP to obtain IP addressing information. A common reason for this problem is the DHCP Spoof Attack prevention mechanism.

It's important to understand the DHCP attack prevention mechanism to solve this problem. For each adapter on which DHCP is enabled, the ISA firewall maintains the list of allowed addresses. There is an entry in the registry for each DHCP enabled adapter:

The registry key name is

The values under the key are:

1.

The adapter's name

2.

The ISA network name of the adapter

3.

The adapter's MAC address

4.

ISA network addresses

5.

The adapter's hardware type

Figure 6.33 shows an example of the registry key:

Figure 6.33. Registry Key for DHCP Attack Prevention

When the ISA firewall's driver sees a DHCP Offer message, it validates the offer using the following logic:

1.

Using the DHCP “Client Ethernet Address” field and the “Hardware Type” field, the driver finds the corresponding registry key of the adapter.

2.

If there is no registry key, the packet is allowed (this will be the case during initial setup of the ISA firewall software).

3.

The driver verifies that “Your IP Address” field in the DHCP Offer contains an IP address within the addresses of the adapter's network element (as written in the registry).

4.

If the verification fails, the packet is dropped, and an ISA alert is raised.

Figure 6.34 shows an example of a DHCP offer packet (the relevant fields are marked).

Figure 6.34. Network Monitor Capture of a DHCP Offer Packet

The invalid alert contains the following information (Figure 6.35):

Figure 6.35. An Invalid DHCP Offer Alert

Figure 6.35

In case the network adapter should receive the offered address, the administrator should use the “Renew DHCP addresses” task that appears in the Task pane of the ISA firewall console. Figure 6.36 shows the warning dialog box you'll see when you click Renew DHCP Addresses in the Task pane.

Figure 6.36. The Renew DHCP Addresses Warning

After clicking Yes, all registry keys related to DHCP attack prevention are deleted, and an “ipconfig /renew” is performed. This means that during this period, no offered address will be dropped by the driver (because there are no registry keys). Once the adapters receive their addresses, new registry keys are written with the new values, and the mechanism will be activated once again.

Dropped DHCP offers due to DHCP Attack Prevention may happen in the following scenarios:

1.

If you have two DHCP adapters and you switched them. For example, the one that was connected to the internal network is now connected to the external network, and vice versa.

2.

A DHCP adapter was moved to a different network. For example, ISA's external NIC was connected to a home network where another router made the connectivity to the ISP (and the Internet), and now you try replacing this router to use ISA's external NIC for connecting the ISP.

In such cases you need to use the Renew DHCP Addresses task, in order to allow the DHCP assignment. Note that once it's allowed, you will not need to allow it anymore. This procedure is needed only after changing the DHCP adapter in such a way that it becomes a member of a different ISA network element