Managing IP Routes Through WMI

Managing the IP routes that direct computers and users to your network resources is an important aspect of Windows management, especially on systems that function as RAS or VPN servers and act as gateways for mobile users. And as rare as IP route­configuration changes are in many enterprises, monitoring them is important from a security standpoint because some intruders attempt to modify or add routes to gain access to your enterprise resources. You can use the route.exe utility to add, view, and delete IP routes, but route.exe has limitations--primarily, its inability to manage IP routes remotely. Fortunately, if your systems run Windows Server 2003 or Windows XP, you can use Windows Management Instrumentation (WMI) and two WMI IP Route provider instances--RouteEventProvider and RouteProvider--to overcome that limitation and examine, modify, and monitor the IP version 4 (IPv4) routing table from any Windows 2003 or XP system. RouteEventProvider is an event provider that can trigger WMI events to notify you of additions, modifications, or deletions to the routing table. RouteProvider is an instance provider that provides access to routing table information. These providers are available in the root\cimv2 namespace and support the classes listed in Web Table 1.

Catching Changes
Before digging into the code that you can use to manage the IP routing table, let's look at how to monitor changes to the table. I've created a script, GenericEventAsyncConsumer.wsf, that submits WMI Query Language (WQL) event queries to get notifications about routing-table modifications. You can download the script, which is included in the 43024.zip file.

To receive notification that a change has been made to the routing table, use the following command, which references the Win32_IP4RouteTableEvent class, to launch the script on the local system. (Although some of the commands I mention in this article are printed on multiple lines, you should enter all commands on one line.)

GenericEventAsyncConsumer.wsf 
  "Select * From 
  Win32_IP4RouteTableEvent"

When you run this query on a system, the script will output information similar to the text that Web Figure 1 shows whenever the IP routing table on that system is modified.

As you can see in Web Figure 1, the Win32_IP4RouteTableEvent class provides only timestamp information specifying when the change occurred. If you want to determine what was added to or deleted from the table, you must use a query that leverages the capabilities of the RouteProvider instance provider. To detect an addition to the routing table, use the following command:

Select * From
  __InstanceCreationEvent 
  Within 10
  Where TargetInstance ISA 
  "Win32_IP4RouteTable"

To track a deletion from the routing table, use the command

Select * From 
  __InstanceDeletionEvent 
  Within 10
  Where TargetInstance ISA 
  "Win32_IP4RouteTable"

These two queries ask WMI to poll the routing table every 10 seconds to determine whether a route has been added or deleted. By exploiting the TargetInstance object in the returned WMI event, the script can determine which route was added or deleted.

Note that I don't provide a command that uses the __InstanceModificationEvent class to tell GenericEventAsyncConsumer.wsf to detect routing table modifications. Because the system constantly refreshes the routing table, which in turn constantly uses the __InstanceModificationEvent class to generate event-modification notifications for subscribers, doing so would require the script to use the Win32_IP4RouteTableEvent class to retrieve notifications about any changes in the routing table, then compare the new state of the table with its original state. This requirement supposes that the script logic reads the table's content at start-up to determine the table's original state, but GenericEventAsyncConsumer.wsf is a generic script that doesn't implement that logic. I'll show you later in the article how to retrieve and display the routing table information.

Also, note the difference in behavior between the first query, which exploits RouteEventProvider and doesn't wait to notify the WMI event consumer (which can be an application or a script), and the latter two queries, which exploit RouteProvider and poll the table every 10 seconds. The first query illustrates how event providers notify subscribing WMI consumers as soon as an event occurs.

Managing the IP Routing Table from a WMI Script
I've written another WMI script, WMIIP4Route.wsf (included in the 43024.zip file, along with two VBScript files that contain helper functions), that provides all functions to manage the content of the routing table from the command line. To do so, the script uses the Win32_IP4RouteTable, Win32_IP4PersistedRouteTable, and Win32_ActiveRoute classes. The script also uses the Windows Script Host (WSH) 5.6 XML command-line parsing technique that I discuss in "Secure Script Execution with WSH 5.6," August 2002, InstantDoc ID 25644.

WMIIP4Route.wsf uses parameters similar to those that route.exe uses. For example, you can retrieve the routing table's content by using the PRINT parameter, which produces output similar to the route.exe PRINT command. (For a list of all supported route.exe parameters and options, run route.exe, without parameters, from the command line.) So, what's the added value of WMIIP4Route.wsf over route.exe if both tools provide the same parameters and level of functionality? Because WMIIP4Route.wsf is based on WMI, which in turn is based on COM and Distributed COM (DCOM), the script can leverage WMI's DCOM capabilities to let you remotely manage IP routes. WMIIP4Route.wsf supports /machine, /user, and /password switches that let you remotely access a system and add or delete an IP route. (The /user and /password switches are optional if you already have Administrator privileges on the remote system, but you must always be an Administrator or equivalent to locally or remotely manage the IP routing table.) Let's look at how you can use WMIIP4Route.wsf to view the information in the routing table, add a route to the table, and delete a route from the table.

   Previous  [1]  2  Next