5. Adding Applications
In addition to providing an exemption for a port,
you can also provide exemptions for applications. An application may
require direct access to a Website for updates or to obtain
information. Normally, the Windows Firewall will try to prevent such
access because the application could perform this task for wicked
reasons, such as infecting your machine. When an application garners
the trust required to interact directly with the Internet or other
online source, it requires an exemption to do so. The Add Application
example shows how to perform this task.
The Add Application example begins with a Windows Forms application. You add two buttons: Add (btnAdd) to add the application to the exemption list and Remove (btnRemove) to remove the application from the list. The addition process will appear to work without the manifest, but the
system won't actually add the application to the list. The example
doesn't require any special references or using statements. It does require that you add the following constants:
// Define Constants from the SDK
// Scope
const Int32 NET_FW_SCOPE_ALL = 0;
const Int32 NET_FW_SCOPE_LOCAL_SUBNET = 1;
const Int32 NET_FW_SCOPE_CUSTOM = 2;
// Set constants
const Int32 NET_FW_PROFILE_DOMAIN = 0;
const Int32 NET_FW_PROFILE_STANDARD = 1;
Ports and applications vary in their intent. A port
opens a gate for any application that knows about the port, while an
application exception applies only to a specific application.
Theoretically, it's safer to create an exception for an application
than it is to open a new port, so you should use the application
exception option whenever possible. Listing 8 shows the code used to add an application exception to the Windows Firewall.
Example 8. Adding an application exception to the Windows Firewall
private void btnAdd_Click(object sender, EventArgs e)
{
// Create the firewall type.
Type FWManagerType = Type.GetTypeFromProgID("HNetCfg.FwMgr");
// Use the firewall type to create a firewall manager object.
dynamic FWManager = Activator.CreateInstance(FWManagerType);
// Obtain the firewall domain profile information.
dynamic FWProfile =
FWManager.LocalPolicy.GetProfileByType(NET_FW_PROFILE_DOMAIN);
// Create the application type.
Type AppType = Type.GetTypeFromProgID("HNetCfg.FwAuthorizedApplication");
// Create an instance of the application type.
dynamic NewApp = Activator.CreateInstance(AppType);
// Supply the application specifics.
NewApp.ProcessImageFileName = Application.ExecutablePath;
NewApp.Name = Application.ProductName;
// The application entry must also include either a scope
// or a remote address entry, but not both.
//NewApp.Scope = NET_FW_SCOPE_ALL;
NewApp.RemoteAddresses = "10.1.1.1/255.255.255.255";
// Enable the application.
NewApp.Enabled = true;
try
{
// Try adding the application.
FWProfile.AuthorizedApplications.Add(NewApp);
// Display a success message.
MessageBox.Show("Application successfully added!");
}
catch (Exception err)
{
// Display an error message.
MessageBox.Show("Couldn't add the Application!\n" +
err.Message);
}
}
|
The code begins by creating the Windows Firewall Manager Type and object (FWManager).
It then accesses the profile. However, notice that the technique used
in this example is different from the other examples in the chapter.
The example uses the GetProfileByType() method to obtain the domain profile using the NET_FW_PROFILE_DOMAIN constant.
There are actually three levels of profile: domain, private, and public. The NET_FW_PROFILE_STANDARD constant provides access to the private profile, while the NET_FW_PROFILE_DOMAIN
constant provides access to the domain profile. The SDK apparently
doesn't provide a constant for the public profile. The vast majority of the application
exceptions you create appear in either the private or domain profile.
The public profile is generally reserved for applications and services
such as File and Print Sharing and Network Discovery, to give two
examples. Some services and low-level applications use a combination of
profiles or sometimes all three. For example, Routing and Remote Access
uses all three profiles for its exceptions.
To create an application exception, the code defines the AppType Type using the HNetCfg.FwAuthorizedApplication program identifier. It then creates the NewApp object using the Activator.CreateInstance() method with AppType
as an argument. The code shows typical entries you need to provide to
define an application. Make certain that you define either the Scope property or the RemoteAddresses property but not both.
At this point, the code calls AuthorizedApplications.Add() to create the new application exception. You supply the AppType object, NewApp,
as input to the method. As with ports, creating a new application
exception defines two entries, one for TCP and another for User
Datagram Protocol (UDP). You'll want to place the AuthorizedApplications.Add() method call within a try...catch block to catch any errors generated by the addition. Figure 7 shows typical entries generated by this example.
Double-clicking either of these entries displays the Add Application Properties dialog box shown in Figure 8.
Notice that the entries are much the same as a port entry. The big
difference is the content differences for items such as the entries on
the Programs and Services tab, where an application exception entry
will have the This Program option selected and the name of a particular
program defined.
At some point, you'll probably want to remove the
application exception. Leaving an application exception in place after
you uninstall the application is a big security risk, so you'll
definitely want to remove the entry as part of your uninstall routine. Listing 9 shows the code used to remove an application exception from the Windows Firewall.
Example 9. Removing an application exception from the Windows Firewall
private void btnRemove_Click(object sender, EventArgs e)
{
// Create the firewall type.
Type FWManagerType = Type.GetTypeFromProgID("HNetCfg.FwMgr");
// Use the firewall type to create a firewall manager object.
dynamic FWManager = Activator.CreateInstance(FWManagerType);
// Obtain the firewall profile information.
dynamic FWProfile =
FWManager.LocalPolicy.GetProfileByType(NET_FW_PROFILE_DOMAIN);
try
{
// Delete the application based on the application path.
FWProfile.AuthorizedApplications.Remove(Application.ExecutablePath);
// Display a success message.
MessageBox.Show("Application successfully removed!");
}
catch (Exception err)
{
// Display an error message.
MessageBox.Show("Couldn't remove the application!\n" +
err.Message);
}
}
|
As with the btnAdd_Click() code, the btnRemove_Click() method begins by creating a Windows Firewall Manager object, FWManager, and using it to access the domain profile using the GetProfileByType() method. The code then calls AuthorizedApplications.Remove() with the executable path of the application (Application.ExecutablePath) as an argument. As with adding the application exception, you want to place the removal code in a try...catch statement.
