How to disable the Windows 7 filtering platform. Windows Firewall with Advanced Security - diagnosing and solving problems. Windows Firewall with Advanced Security cannot be configured

The Windows Vista™ Microsoft Management Console (MMC) snap-in is a network sensing firewall for workstations that filters incoming and outgoing connections based on configured settings. You can now configure firewall and IPsec settings using one snap-in. This article describes how Windows Firewall with Advanced Security works, common problems, and solutions.

How Windows Firewall with Advanced Security works

Windows Firewall with Advanced Security is a network state logging firewall for workstations. Unlike router firewalls, which are deployed at the gateway between your local network and the Internet, Windows Firewall is designed to run on individual computers. It monitors only workstation traffic: traffic incoming to the IP address of that computer, and traffic outgoing from the computer itself. Windows Firewall with Advanced Security performs the following basic operations:

The incoming packet is checked and compared with the list of allowed traffic. If the packet matches one of the list values, Windows Firewall passes the packet to TCP/IP for further processing. If the packet does not match any of the values ​​in the list, Windows Firewall blocks the packet and, if logging is enabled, creates an entry in the log file.

The list of allowed traffic is formed in two ways:

When a connection controlled by Windows Firewall with Advanced Security sends a packet, the firewall creates a value in the list to allow the return traffic to be accepted. Relevant incoming traffic will require additional permission.

When you create an allow rule for Windows Firewall with Advanced Security, the traffic for which you created the rule will be allowed on a computer that is running Windows Firewall. This computer will accept explicitly allowed incoming traffic when operating as a server, client computer, or peer-to-peer network host.

The first step to solving problems with Windows Firewall is to check which profile is active. Windows Firewall with Advanced Security is an application that monitors your network environment. The Windows Firewall profile changes as your network environment changes. A profile is a set of settings and rules that are applied depending on the network environment and existing network connections.

The firewall distinguishes between three types of network environments: domain, public and private networks. A domain is a network environment in which connections are authenticated by a domain controller. By default, all other network connection types are treated as public networks. When a new connection is detected, Windows Vista prompts the user to indicate whether the network is private or public. The general profile is intended for use in public places, such as airports or cafes. The private profile is intended for use at home or in the office, as well as on a secure network. To define a network as private, the user must have appropriate administrative privileges.

Although a computer can be connected to different types of networks at the same time, only one profile can be active. The choice of active profile depends on the following reasons:

If all interfaces use domain controller authentication, the domain profile is used.

If at least one of the interfaces is connected to a private network, and all others are connected to a domain or private networks, the private profile is used.

In all other cases, the general profile is used.

To determine the active profile, click the node Observation in a snap Windows Firewall with Advanced Security. Above the text Firewall Status will indicate which profile is active. For example, if a domain profile is active, it will display at the top Domain profile is active.

By using profiles, Windows Firewall can automatically allow incoming traffic for specific computer management tools when the computer is in a domain, and block the same traffic when the computer is connected to a public or private network. Thus, determining the type of network environment ensures the protection of your local network without compromising the security of mobile users.

Common problems when running Windows Firewall with Advanced Security

The following are the main problems that occur when Windows Firewall with Advanced Security is running:

In the event that traffic is blocked, you should first check whether the firewall is enabled and which profile is active. If any of the applications are blocked, make sure that the snap-in Windows Firewall with Advanced Security There is an active allow rule for the current profile. To verify that an allowing rule exists, double-click the node Observation and then select the partition Firewall. If there are no active allowing rules for this program, go to the site and create a new rule for this program. Create a rule for a program or service, or specify a rule group that applies to this feature, and make sure that all rules in that group are enabled.

To verify that an allowing rule is not overridden by a blocking rule, follow these steps:

In the snap tree Windows Firewall with Advanced Security click the node Observation, and then select the section Firewall.

View a list of all active local and group policy rules. Prohibiting rules override allowing rules even if the latter are more precisely defined.

Group Policy prevents local rules from applying

If Windows Firewall with Advanced Security is configured by using Group Policy, the administrator can specify whether firewall rules or connection security rules created by local administrators will be used. This makes sense if there are configured local firewall rules or connection security rules that are not in the corresponding section of the settings.

To determine why local firewall rules or connection security rules are missing from the Monitoring section, follow these steps:

In the snap Windows Firewall with Advanced Security, click the link Windows Firewall Properties.

Select the active profile tab.

In the section Options, press the button Tune.

If local rules apply, section Combining rules will be active.

Rules that require secure connections may block traffic

When creating a firewall rule for incoming or outgoing traffic, one of the parameters is . If you select this feature, you must have an appropriate connection security rule or a separate IPSec policy that determines what traffic is secure. Otherwise, this traffic is blocked.

To verify that one or more application rules require secure connections, follow these steps:

In the snap tree Windows Firewall with Advanced Security click section Rules for incoming connections. Select the rule you want to check and click the link Properties in the console scope.

Select a tab General and check if the radio button value is selected Allow only secure connections.

If the rule is specified with the parameter Allow only secure connections, expand the section Observation in the snap-in tree and select section. Ensure that the traffic defined in the firewall rule has appropriate connection security rules.

Warning:

If you have an active IPSec policy, ensure that the policy protects the necessary traffic. Do not create connection security rules to avoid conflicting IPSec policy and connection security rules.

Unable to allow outgoing connections

In the snap tree Windows Firewall with Advanced Security select section Observation. Select the active profile tab and in the section Firewall Status check that outgoing connections that do not fall within the allowing rule are allowed.

In the section Observation select section Firewall to ensure that the required outgoing connections are not specified in the deny rules.

Mixed policies can lead to traffic blocking

You can configure firewall and IPSec settings using various Windows interfaces.

Creating policies in multiple places can lead to conflicts and traffic blocking. The following setting points are available:

Windows Firewall with Advanced Security. This policy is configured using the appropriate snap-in locally or as part of Group Policy. This policy defines firewall and IPSec settings on computers running Windows Vista.

Windows Firewall Administrative Template. This policy is configured using the Group Policy Object Editor in the section. This interface contains Windows Firewall settings that were available before Windows Vista and is used to configure the GPO that controls previous versions of Windows. Although these settings can be used for computers running Windows Vista, we recommend that you use the policy instead Windows Firewall with Advanced Security, as it provides greater flexibility and security. Please note that some of the domain profile settings are common to the Windows Firewall Administrative Template and Policy Windows Firewall with Advanced Security, so you can see here the parameters configured in the domain profile using the snap-in Windows Firewall with Advanced Security.

IPSec Policies. This policy is configured using the local snap-in IPSec Policy Management or the Group Policy Object Editor in the Computer Configuration\Windows Configuration\Security Settings\IP Security Policies section on “Local Computer”. This policy defines IPSec settings that can be used by both previous versions of Windows and Windows Vista. This policy and the connection security rules defined in the policy should not be applied simultaneously on the same computer Windows Firewall with Advanced Security.

To view all of these options in the appropriate snap-ins, create your own Management Console snap-in and add the snap-ins to it Windows Firewall with Advanced Security, And IP Security.

To create your own management console snap-in, follow these steps:

Click the button Start, go to menu All programs, then to the menu Standard and select Execute.

In a text field Open ENTER.

Continue.

On the menu Console select item.

On the list Available accessories select equipment Windows Firewall with Advanced Security and press the button Add.

Click the button OK.

Repeat steps 1 through 6 to add snaps Group Policy Management And IP Security Monitor.

To check which policies are active in an active profile, use the following procedure:

To check which policies are applied, follow these steps:

At the command prompt, type mmc and press the key ENTER.

If the User Account Control dialog box appears, confirm the requested action and click Continue.

On the menu Console select item Add or remove a snap-in.

On the list Available accessories select equipment Group Policy Management and press the button Add.

Click the button OK.

Expand a node in the tree (usually the tree of the forest in which the computer is located) and double-click the section in the console details pane.

Select radio button value Show policy settings for from values current user or another user. If you do not want to display policy settings for users, but only policy settings for the computer, select the radio button Do not display user policy (only view computer policy) and press the button twice Next.

Click the button Ready. The Group Policy Results Wizard generates a report in the details pane of the console. The report contains tabs Summary, Options And Political events.

To verify that there is no conflict with IP security policies, after generating the report, select the tab Options and open Computer Configuration\Windows Configuration\Security Settings\IP Security Settings in the Active Directory directory service. If the last section is missing, then the IP security policy has not been set. Otherwise, the name and description of the policy and the GPO to which it belongs will be displayed. If you use an IP security policy and a Windows Firewall with Advanced Security policy at the same time with connection security rules, these policies may conflict. It is recommended to use only one of these policies. The optimal solution is to use IP security policies in conjunction with Windows Firewall with Advanced Security rules for incoming or outgoing traffic. If parameters are configured in different places and are not consistent with each other, policy conflicts that are difficult to resolve may arise.

There may also be conflicts between policies defined in local Group Policy Objects and scripts configured by the IT department. Check all IP security policies using the IP Security Monitor program or by entering the following command at the command prompt:

To view the settings defined in the Windows Firewall Administrative Template, expand the section Computer Configuration\Administrative Templates\Network\Network Connections\Windows Firewall.

To view the latest events related to the current policy, you can go to the tab Policy Events in the same console.

To view the policy used by Windows Firewall with Advanced Security, open the snap-in on the computer you are diagnosing and review the settings under Observation.

To view administrative templates, open the snap-in Group Policy and in the section Group Policy Results Review whether there are settings inherited from Group Policy that may cause traffic to be rejected.

To view IP security policies, open the IP Security Monitor snap-in. Select the local computer in the tree. In the console scope, select the link Active policy, Basic mode or Fast mode. Check for competing policies that may result in traffic being blocked.

In the section Observation rigging Windows Firewall with Advanced Security You can view existing rules for both local and group policy. For more information, please refer to the section " Using the watch feature in a snap-in Windows Firewall with Advanced Security » of this document.

To stop the IPSec Policy Agent, follow these steps:

Click the button Start and select a section Control Panel.

Click the icon System and its maintenance and select a section Administration.

Double-click the icon Services. Continue.

Find a service in the list IPSec Policy Agent

If the service IPSec Agent is running, right-click on it and select the menu item Stop. You can also stop the service IPSec Agent from the command line using the command

Peer-to-peer policy may cause traffic to be rejected

For connections that use IPSec, both computers must have compatible IP security policies. These policies can be defined using the Windows Firewall connection security rules snap-in IP security or another IP security provider.

To check IP security policy settings on a peer-to-peer network, follow these steps:

In the snap Windows Firewall with Advanced Security select node Observation And Connection security rules to make sure that IP security policy is configured on both network nodes.

If one of the computers on the peer-to-peer network is running a version of Windows earlier than Windows Vista, ensure that at least one of the native mode cipher suites and one of the fast mode cipher suites use algorithms that are supported by both nodes .

1. Click section Basic mode, in the console details pane, select the connection to test, then click the link Properties in the console scope. Review the connection properties for both nodes to ensure they are compatible.

   Repeat step 2.1 for the partition Fast mode. Review the connection properties for both nodes to ensure they are compatible.

If you are using Kerberos version 5 authentication, ensure that the host is in the same or a trusted domain.

If you are using certificates, make sure the required boxes are selected. Certificates that use Internet Key Exchange (IKE) IPSec require a digital signature. Certificates that use Authenticated Internet Protocol (AuthIP) require client authentication (depending on the server's authentication type). For more information about AuthIP certificates, please refer to the article IP Authentication in Windows Vista AuthIP in Windows Vista on the Microsoft website.

Windows Firewall with Advanced Security cannot be configured

Windows Firewall with Advanced Security settings are grayed out (grayed out) in the following cases:

The computer is connected to a centrally managed network, and the network administrator uses Group Policy to configure Windows Firewall with Advanced Security settings. In this case, at the top of the snap Windows Firewall with Advanced Security You will see the message "Some settings are controlled by Group Policy." Your network administrator configures the policy, thereby preventing you from changing Windows Firewall settings.

A computer running Windows Vista is not connected to a centrally managed network, but Windows Firewall settings are determined by local Group Policy.

To change Windows Firewall with Advanced Security settings using Local Group Policy, use the snap-in Local Computer Policy. To open this snap-in, enter secpol at the command prompt. If the User Account Control dialog box appears, confirm the requested action and click Continue. Go to Computer Configuration\Windows Settings\Security Settings\Windows Firewall with Advanced Security to configure Windows Firewall with Advanced Security policy settings.

The computer does not respond to ping requests

The main way to test connectivity between computers is to use the Ping utility to test connectivity to a specific IP address. During a ping, an ICMP echo message (also known as an ICMP echo request) is sent and an ICMP echo response is requested in return. By default, Windows Firewall rejects incoming ICMP echo messages, so the computer cannot send an ICMP echo response.

Allowing incoming ICMP echo messages will allow other computers to ping your computer. On the other hand, this will make the computer vulnerable to attacks using ICMP echo messages. However, it is recommended to temporarily allow incoming ICMP echo messages if necessary, and then disable them.

To allow ICMP echo messages, create new inbound rules that allow ICMPv4 and ICMPv6 echo request packets.

To resolve ICMPv4 and ICMPv6 echo requests, follow these steps:

In the snap tree Windows Firewall with Advanced Security select node Rules for incoming connections and click the link New rule in the console action area.

Customizable and press the button Next.

Specify the switch value All programs and press the button Next.

In the dropdown list Protocol type select value ICMPv4.

Click the button Tune for item ICMP Protocol Parameters.

Set the radio button to Specific ICMP Types, check the box Echo request, press the button OK and press the button Next.

At the stage of selecting local and remote IP addresses corresponding to this rule, set the switches to the values Any IP address or Specified IP addresses. If you select the value Specified IP addresses, specify the required IP addresses, click the button Add and press the button Next.

Specify the switch value Allow connection and press the button Next.

At the profile selection stage, select one or more profiles (domain profile, private or public profile) in which you want to use this rule and click the button Next.

In the field Name enter the name of the rule, and in the field Description– optional description. Click the button Ready.

Repeat the above steps for the ICMPv6 protocol, selecting Protocol type dropdown value ICMPv6 instead of ICMPv4.

If you have active connection security rules, temporarily excluding ICMP from the IPsec requirements may help resolve problems. To do this, open in the snap Windows Firewall with Advanced Security dialog box Properties, go to the tab IPSec Settings and specify the value in the drop-down list Yes for parameter Exclude ICMP from IPSec.

Note

Windows Firewall settings can only be changed by administrators and network operators.

Unable to share files and printers

If you can't share files and printers on a computer with Windows Firewall active, make sure all group rules are enabled Access to files and printers Windows Firewall with Advanced Security select node Rules for incoming connections Access to files and printers Enable rule in the console scope.

Attention:

It is strongly recommended not to enable file and printer sharing on computers that are directly connected to the Internet, as attackers may try to access shared files and harm you by damaging your personal files.

Windows Firewall cannot be administered remotely

If you are unable to remotely administer a computer with Windows Firewall active, make sure that all rules in the default group are enabled Remote Windows Firewall Management active profile. In the snap Windows Firewall with Advanced Security select node Rules for incoming connections and scroll the list of rules to the group Remote control. Make sure these rules are enabled. Select each of the disabled rules and click the button Enable rule in the console scope. Additionally, make sure that the IPSec Policy Agent service is enabled. This service is required for remote management of Windows Firewall.

To verify that the IPSec Policy Agent is running, follow these steps:

Click the button Start and select a section Control Panel.

Click the icon System and its maintenance and select a section Administration.

Double-click the icon Services.

If the User Account Control dialog box appears, enter the required user information with the appropriate permissions and click Continue.

Find a service in the list IPSec Policy Agent and make sure it has a "Running" status.

If the service IPSec Agent stopped, right-click on it and select the item in the context menu Launch. You can also start the service IPSec Agent from the command line using the net start policy agent command.

Note

Default service IPSec Policy Agent launched. This service should be running unless it has been manually stopped.

Windows Firewall Troubleshooters

This section describes tools and techniques that can be used to solve common problems. This section consists of the following subsections:

Use monitoring features in Windows Firewall with Advanced Security

The first step to solving Windows Firewall problems is to review the current rules. Function Observation allows you to view the rules used based on local and group policies. To view the current inbound and outbound rules in the snap-in tree Windows Firewall with Advanced Security select section Observation, and then select the section Firewall. In this section you can also view current connection security rules And security associations (Main and Quick modes).

Enable and use security auditing using the auditpol command-line tool

By default, audit options are disabled. To configure them, use the auditpol.exe command-line tool, which changes the audit policy settings on the local computer. Auditpol can be used to enable or disable the display of different categories of events and then view them later in the snap-in Event Viewer.

To view a list of categories supported by auditpol, enter at the command prompt:

• To view a list of subcategories that are included in a given category (for example, the Policy Change category), enter at the command line:

  auditpol.exe /list /category:"Policy changes"

• To enable display of a category or subcategory, enter at the command line:

  /SubCategory:" NameCategory"

For example, to set audit policies for a category and its subcategory, you would enter the following command:

auditpol.exe /set /category:"Changing policy" /subcategory:"Changing policy at the MPSSVC rule level" /success:enable /failure:enable

Policy change

Changing Policy at the MPSSVC Rule Level

Changing the filtering platform policy

Entry/Exit

IPsec Basic Mode

IPsec Fast Mode

IPsec Enhanced Mode

System

IPSEC Driver

Other system events

Access to objects

Packet drop by filtering platform

Connecting the filtration platform

For security audit policy changes to take effect, you must restart the local computer or force a manual policy update. To force a policy update, enter at the command prompt:

secedit/refreshpolicy<название_политики>

After diagnostics are complete, you can disable event auditing by replacing the enable parameter in the above commands with disable and running the commands again.

View security audit events in the event log

After you enable auditing, use Event Viewer to view audit events in the Security Event Log.

To open Event Viewer in the Administrative Tools folder, follow these steps:

1. Click the button Start.

   Select section Control Panel. Click the icon System and its maintenance and select a section Administration.

   Double-click the icon Event Viewer.

To add Event Viewer to the MMC, follow these steps:

Click the button Start, go to menu All programs, then to the menu Standard and select Execute.

In a text field Open enter mmc and press the key ENTER.

If the User Account Control dialog box appears, confirm the requested action and click Continue.

On the menu Console select item Add or remove a snap-in.

On the list Available accessories select equipment Event Viewer and press the button Add.

Click the button OK.

Before closing the snap-in, save the console for future use.

In the snap Event Viewer expand the section Windows logs and select a node Safety. In the console work area, you can view security audit events. All events are displayed at the top of the console work area. Click an event at the top of the console workspace to display detailed information at the bottom of the panel. On the tab General There is a description of the events in the form of clear text. On the tab Details The following event display options are available: Clear presentation And XML mode.

Configure Firewall Log for a Profile

Before you can view firewall logs, you must configure Windows Firewall with Advanced Security to generate log files.

To configure logging for a Windows Firewall with Advanced Security profile, follow these steps:

In the snap tree Windows Firewall with Advanced Security select section Windows Firewall with Advanced Security and press the button Properties in the console scope.

Select the profile tab for which you want to configure logging (domain profile, private profile, or public profile), and then click Tune in section Logging.

Specify the name and location of the log file.

Specify the maximum log file size (from 1 to 32767 kilobytes)

In the dropdown list Log missing packets enter the value Yes.

In the dropdown list Record successful connections enter the value Yes and then click the button OK.

View firewall log files

Open the file you specified during the previous procedure, “Configuring the Firewall Log for a Profile.” To access the firewall log, you must have local administrator rights.

You can view the log file using Notepad or any text editor.

Analyzing Firewall Log Files

The information recorded in the log is shown in the following table. Some data is specified only for certain protocols (TCP flags, ICMP type and code, etc.), and some data is specified only for dropped packets (size).

Note

The hyphen (-) is used in fields of the current record that do not contain any information.

Creating netstat and tasklist text files

You can create two custom log files, one to view network statistics (a list of all listening ports) and another to view service and application task lists. The task list contains the process identifier (PID) for events contained in the network statistics file. The procedure for creating these two files is described below.

To create text files of network statistics and a task list, follow these steps:

At the command prompt, enter netstat -ano > netstat.txt and press the key ENTER.

At the command prompt, enter tasklist > tasklist.txt and press the key ENTER. If you need to create a text file with a list of services, enter tasklist /svc > tasklist.txt.

Open the tasklist.txt and netstat.txt files.

Find the code of the process you are diagnosing in the tasklist.txt file and compare it with the value contained in the netstat.txt file. Record the protocols used.

Example of issuing Tasklist.txt and Netstat.txt files

Netstat.txt
Proto Local Address Foreign Address State PID
TCP 0.0.0.0:XXX 0.0.0.0:0 LISTENING 122
TCP 0.0.0.0:XXXXX 0.0.0.0:0 LISTENING 322
Tasklist.txt
Image Name PID Session Name Session# Mem Usage
==================== ======== ================ =========== ============
svchost.exe 122 Services 0 7,172 K
XzzRpc.exe 322 Services 0 5,104 K

Note

The real IP addresses are changed to "X" and the RPC service is changed to "z".

Make sure essential services are running

The following services must be running:

Basic Filtering Service

Group Policy Client

IPsec key modules for Internet key exchange and IP authentication

IP Ancillary Service

IPSec Policy Agent Service

Network Location Service

Network List Service

Windows Firewall

To open the Services snap-in and verify that the required services are running, follow these steps:

Click the button Start and select a section Control Panel.

Click the icon System and its maintenance and select a section Administration.

Double-click the icon Services.

If the User Account Control dialog box appears, enter the required user information with the appropriate permissions and click Continue.

Make sure the services listed above are running. If one or more services are not running, right-click the service name in the list and select Launch.

Additional way to solve problems

As a last resort, you can restore your Windows Firewall settings to their defaults. Restoring default settings will lose all settings made after installing Windows Vista. This may cause some programs to stop working. Also, if you control the computer remotely, the connection to it will be lost.

Before restoring default settings, make sure that you have saved your current firewall configuration. This will allow you to restore your settings if necessary.

Below are the steps to save your firewall configuration and restore the default settings.

To save the current firewall configuration, follow these steps:

In the snap Windows Firewall with Advanced Security click link Export Policy in the console scope.

To restore your firewall settings to default, follow these steps:

In the snap Windows Firewall with Advanced Security click link Restore Defaults in the console scope.

When you receive a Windows Firewall with Advanced Security prompt, click Yes to restore default values.

Conclusion

There are many ways to diagnose and resolve problems with Windows Firewall with Advanced Security. Among them:

Using the function Observation to view firewall actions, connection security rules, and security associations.

Analyze security audit events related to Windows Firewall.

Creating text files tasklist And netstat for comparative analysis.

Starting with Server 2008 and Vista, the WFP mechanism was built into Windows,
which is a set of APIs and system services. With its help it became possible
deny and allow connections, manage individual packets. These
innovations were intended to simplify the life of developers of various
protection The changes made to the network architecture affected both kernel-mode and
and user-mode parts of the system. In the first case, the necessary functions are exported
fwpkclnt.sys, in the second - fwpuclnt.dll (the letters "k" and "u" in the library names
stand for kernel and user respectively). In this article we will talk about the application
WFP for intercepting and filtering traffic, and after familiarizing yourself with the basic
Using the definitions and capabilities of WFP, we will write our own simple filter.

Basic Concepts

Before we start coding, it is absolutely necessary for us to familiarize ourselves with the terminology
Microsoft - and additional literature will be useful for understanding the article
It will be easier to read :). So, let's go.

Classification- the process of determining what to do with a package.
Possible actions: allow, block or callout.

Callouts is a set of functions in the driver that perform inspection
packages. They have a special function that performs packet classification. This
the function can decide the following:

• allow(FWP_ACTION_PERMIT);
• block(FWP_ACTION_BLOCK);
• continue processing;
• request more data;
• terminate the connection.

Filters- rules indicating in what cases it is called
this or that callout. One driver can have several callouts, and
We will develop a driver with callout in this article. By the way, colautas
There are also built-in ones, for example, NAT-callout.

Layer- this is a sign by which various filters are combined (or,
as they say in MSDN, "container").

To tell the truth, the documentation from Microsoft looks quite unclear, so far
you can't look at the examples in the WDK. Therefore, if you suddenly decide to develop something
serious, you definitely need to get acquainted with them. Well, it's smooth now
Let's move on to practice. For successful compilation and tests you will need WDK (Windows
Driver Kit), VmWare, a virtual machine with Vista installed and the WinDbg debugger.
As for the WDK, I personally have version 7600.16385.0 installed - everything is there
necessary libs (since we will develop the driver, we only need
fwpkclnt.lib and ntoskrnl.lib) and examples of using WFP. Links to all
The tools have already been presented several times, so we will not repeat them.

Coding

To initialize the callout, I wrote the BlInitialize function. General algorithm
creating a callout and adding a filter is like this:

1. FWPMENGINEOPEN0 opens a session;
2. FWPMTRANSACTIONBEGIN0- start of operation with WFP;
3. FWPSCALLOUTREGISTER0- creating a new callout;
4. FWPMCALLOUTADD0- adding a callout object to the system;
5. FWPMFILTERADD0- adding a new filter(s);
6. FWPMTRANSACTIONCOMMIT0- saving changes (added
   filters).

Note that functions end in 0. In Windows 7, some of these
functions were changed, for example, FwpsCalloutRegister1 appeared (with
saved by FwpsCalloutRegister0). They differ in arguments and, as a consequence,
prototypes of classifying functions, but for us this is not important now - 0-functions
universal.

FwpmEngineOpen0 and FwpmTransactionBegin0 are not particularly interesting to us - these are
preparatory stage. The fun begins with the function
FwpsCalloutRegister0:

FwpsCalloutRegister0 prototype

NTSTATUS NTAPI FwpsCalloutRegister0
__inout void *deviceObject,
__in const FWPS_CALLOUT0 *callout,
__out_opt UINT32 *calloutId
);

I already said that callout is a set of functions, now it's time
tell us more about this. The FWPS_CALLOUT0 structure contains pointers to three
functions - classifying (classifyFn) and two notifying (about
adding/removing a filter (notifyFn) and closing the processed flow (flowDeleteFn)).
The first two functions are mandatory, the last is needed only if
you want to monitor the packets themselves, not just the connections. Also in the structure
contains a unique identifier, callout GUID (calloutKey).

Callout registration code

FWPS_CALLOUT sCallout = (0);
sCallout.calloutKey = *calloutKey;
sCallout.classifyFn = BlClassify;
// classifying function
sCallout.notifyFn = (FWPS_CALLOUT_NOTIFY_FN0)BlNotify;
// function notifying about adding/removing a filter
// create a new callout
status = FwpsCalloutRegister(deviceObject, &sCallout, calloutId);

DWORD WINAPI FwpmCalloutAdd0(
__in HANDLE engineHandle,
__in const FWPM_CALLOUT0 *callout,
__in_opt PSECURITY_DESCRIPTOR sd,
__out_opt UINT32 *id
);
typedef struct FWPM_CALLOUT0_ (
GUID calloutKey;
FWPM_DISPLAY_DATA0 displayData; // callout description
UINT32 flags;
GUID *providerKey;
FWP_BYTE_BLOB providerData;
GUID applicableLayer;
UINT32 calloutId;
) FWPM_CALLOUT0;

In the FWPM_CALLOUT0 structure we are interested in the applicableLayer field - unique
ID of the level to which the callout is added. In our case it is
FWPM_LAYER_ALE_AUTH_CONNECT_V4. "v4" in the identifier name means version
Ipv4 protocol, there is also FWPM_LAYER_ALE_AUTH_CONNECT_V6 for Ipv6. Considering
low prevalence of IPv6 at the moment, we will only work with
IPv4. CONNECT in the name means that we only control the installation
connections, there is no talk of packets incoming or outgoing to this address! At all
There are many levels besides the one we used - they are declared in the header file
fwpmk.h from WDK.

Adding a callout object to the system

// callout name
displayData.name = L"Blocker Callout";
displayData.description = L"Blocker Callout";
mCallout.calloutKey = *calloutKey;
mCallout.displayData = displayData;
// callout description
//FWPM_LAYER_ALE_AUTH_CONNECT_V4
mCallout.applicableLayer = *layerKey;
status = FwpmCalloutAdd(gEngineHandle, &mCallout, NULL, NULL);

So, after the callout has been successfully added to the system, you need to create
filter, that is, indicate in what cases our callout will be called, namely
- its classifying function. A new filter is created by the FwpmFilterAdd0 function,
which passes the FWPM_FILTER0 structure as an argument.

FWPM_FILTER0 has one or more FWPM_FILTER_CONDITION0 structures (their
the number is determined by the numFilterConditions field). The layerKey field is filled with a GUID
the layer we want to join. In this case we indicate
FWPM_LAYER_ALE_AUTH_CONNECT_V4.

Now let's take a closer look at filling FWPM_FILTER_CONDITION0. Firstly, in
fieldKey must be explicitly specified as to what we want to control - port, address,
app or something else. In this case, WPM_CONDITION_IP_REMOTE_ADDRESS
indicates to the system that we are interested in the IP address. The fieldKey value determines whether
what type of values ​​will be in the FWP_CONDITION_VALUE structure included in
FWPM_FILTER_CONDITION0. In this case, it contains the ipv4 address. Let's go
further. The matchType field determines how the comparison will be made
values ​​in FWP_CONDITION_VALUE with what came over the network. There are many options here:
you can specify FWP_MATCH_EQUAL, which will mean full compliance with the condition, and
you can - FWP_MATCH_NOT_EQUAL, that is, in fact, we can add this
thus excluding filtering (address, the connection to which is not monitored).
There are also options FWP_MATCH_GREATER, FWP_MATCH_LESS and others (see enum
FWP_MATCH_TYPE). In this case, we have FWP_MATCH_EQUAL.

I didn’t bother too much and just wrote a condition for blocking
one selected IP address. In case some application tries
establish a connection with the selected address, the classifier will be called
our callout function. You can look at the code summarizing what has been said at
See the "Adding a Filter to the System" sidebar.

Adding a filter to the system

filter.flags = FWPM_FILTER_FLAG_NONE;
filter.layerKey = *layerKey;
filter.displayData.name = L"Blocker Callout";
filter.displayData.description = L"Blocker Callout";
filter.action.type = FWP_ACTION_CALLOUT_UNKNOWN;
filter.action.calloutKey = *calloutKey;
filter.filterCondition = filterConditions;
// one filter condition
filter.numFilterConditions = 1;
//filter.subLayerKey = FWPM_SUBLAYER_UNIVERSAL;
filter.weight.type = FWP_EMPTY; // auto-weight.
// add a filter to the remote address
filterConditions.fieldKey = FWPM_CONDITION_IP_REMOTE_ADDRESS;
filterConditions.matchType = FWP_MATCH_EQUAL;
filterConditions.conditionValue.type = FWP_UINT32;
filterConditions.conditionValue.uint32 = ntohl(BLOCKED_IP_ADDRESS);
// add a filter
status = FwpmFilterAdd(gEngineHandle, &filter, NULL, NULL);

In general, of course, there can be many filtering conditions. For example, you can
specify blocking of connections to a specific remote or local port (FWPM_CONDITION_IP_REMOTE_PORT
and FWPM_CONDITION_IP_LOCAL_PORT respectively). You can catch all packages
a specific protocol or a specific application. And that's not all! Can,
for example, block a specific user's traffic. In general, there is where
take a walk.

However, let's return to the filter. The classification function in our case is simply
blocks the connection to the specified address (BLOCKED_IP_ADDRESS), returning
FWP_ACTION_BLOCK:

Code of our classify function

void BlClassify(
const FWPS_INCOMING_VALUES* inFixedValues,
const FWPS_INCOMING_METADATA_VALUES* inMetaValues,
VOID* packet,IN const FWPS_FILTER* filter,
UINT64 flowContext,FWPS_CLASSIFY_OUT* classifyOut)
{
// fill the structure FWPS_CLASSIFY_OUT0
if(classifyOut)( // block the packet
classifyOut->actionType =
FWP_ACTION_BLOCK;
// when blocking a package you need
reset FWPS_RIGHT_ACTION_WRITE
classifyOut->rights&=~FWPS_RIGHT_ACTION_WRITE;
}
}

In practice, the classification function may also set FWP_ACTION_PERMIT,
FWP_ACTION_CONTINUE, etc.

And finally, when unloading the driver, you need to remove all installed
callouts (guess what will happen if the system tries to call callout
unloaded driver? That's right, BSOD). There is a function for this
FwpsCalloutUnregisterById. As a parameter it is passed 32-bit
callout identifier returned by the FwpsCalloutRegister function.

Terminating a callout

NTSTATUS BlUninitialize())(
NTSTATUS ns;
if(gEngineHandle)(
FwpmEngineClose(gEngineHandle);

}
if(gBlCalloutIdV4)(
ns =FwpsCalloutUnregisterById(gBlCalloutIdV4);
}
return ns;
}

As you can see, programming a WFP filter is not such a difficult task, since
MS provided us with a very convenient API. By the way, in our case we installed
filter in the driver, but this can also be done from usermod! For example, sample from wdk
msnmntr (MSN Messenger traffic monitor) does just that - this allows you not to
overload the kernel-mode part of the filter.

Your GUID

To register a callout, it needs a unique identifier. In order to
get your GUID (Globally Unique Identifier), use guidgen.exe included
in Visual Studio. The tool is located in (VS_Path)\Common7\Tools. Probability of collision
is very small since the GUID length is 128 bits and there are 2^128 available in total
identifiers.

Debugging the filter

To debug firewood, it is convenient to use the Windbg+VmWare combination. For this you need
configure both the guest system (which is Vista) and the debugger
WinDbg. If in WinXP you had to edit boot.ini for remote debugging, then
For Vista+ there is a console utility called bcdedit. As usual, you need to enable debugging:

BCDedit /dbgsettings SERIAL DEBUGPORT:1 BAUDRATE:115200 BCDedit /debug
ON (or BCDedit /set debug ON)

Now everything is ready! We launch a batch file with the text below:

start windbg -b -k com:pipe,port=\\.\pipe\com_1,resets=0

and see the debugging output in the windbg window (see picture).

Conclusion

As you can see, the scope of WFP is quite wide. It's up to you to decide how
apply this knowledge - for evil or for good :)

The Windows firewall (firewall or firewall) does not inspire respect. Changed slightly from XP to Vista, it does its simple job well, but it lacks the ambition to be the best personal firewall. However, despite the fact that the Windows 7 firewall received several new features, it still did not receive what I expected to see in it.

Hanging out with Homegroup

During installation, Windows 7 prompts you to create a “homegroup”. As other Windows 7 computers are discovered on the network, they are also invited to join the group. And all they need for this is a password to it. However, having one computer running Windows 7, I did not see the process of logging into a group of other computers, although a notification about this would not hurt. However, while any computer running Windows 7 can join a homegroup, computers running Windows 7 Home Basic and Windows 7 Starter cannot create one.

Computers in the same homegroup can share (or, as they say, “share”) printers and specific file libraries. By default, libraries of pictures, music, videos and documents are shared, but the user can limit them at his own discretion. Help in the operating system gives clear explanations of how to exclude a file or folder from sharing, or how to make it read-only, or how to restrict access to it.

In his home network, the user can share his content to other computers and devices, and even to computers that do not run Windows 7 and even to non-computers at all. In particular, Microsoft showed examples of how you can share content on the Xbox 360. However, the company does not offer to connect the Wii to the network. Alas, the company did not qualify the Wii as a streaming media device.

So, how much more secure is your home network in Windows 7? Typically, users who fail to share files and folders begin to disable everything around them, including filewall, antivirus, etc., which, in their opinion, may interfere with this process. At the same time, if you make sharing simple, then turning off everything around you can be avoided.

If Vista divides networks into public (Public) and private (Private), then Windows 7 divides the private network into home (Home) and work (Work). HomeGroup is only available when you select your home network. However, even on a work network, your computer can still see and connect to other devices on it. In turn, on a public network (like a wireless one in an Internet cafe), Windows 7 blocks access to and from you to other devices, for your safety. This is a small but nice opportunity.

Dual-mode firewall

In Vista and XP, managing the firewall is as simple as turning it on and off. At the same time, Windows 7 offers the user various configuration settings for private (home and work) and public networks. At the same time, the user does not need to enter the firewall settings in order to work, say, in a local cafe. All he needs to do is select a public network, and the firewall itself will apply the entire set of restrictive parameters. Most likely, users will configure the public network to block all incoming connections. In Vista, this could not be done without also cutting off all incoming traffic on the user's own network.

Some users do not understand why a firewall is needed. If UAC works, isn't a firewall overkill? In reality, these programs have completely different goals. UAC monitors programs and their operation within the local system. The firewall looks closely at incoming and outgoing data. If you imagine these two programs as two heroes standing back to back and repelling zombie attacks, then, one might say, you can hardly go wrong.

At first, I was intrigued by the new feature “Notify me when Windows Firewall blocks a new program.” Is this a sign that Windows Firewall has gained control over programs and has become a true two-way firewall? I was consumed by the desire to disable this feature. And as a result, Windows Firewall didn't get any more respect than it had.

It's been ten years since ZoneLabs popularized the two-way personal firewall. Her ZoneAlarm program hid all the computer's ports (which Windows Firewall can do) and also allowed you to control programs' access to the Internet (which Windows Firewall still can't do). I do not require intelligent monitoring of program behavior, as, for example, in Norton Internet Security 2010 and other packages. But I hope that by the release of Windows 8, Microsoft will nevertheless introduce a set of capabilities of the ten-year-old ZoneAlarm into its firewall.

Microsoft is well aware that many users install third-party firewalls and security packages and simply disable Windows Firewall. In the past, many third-party security programs automatically disabled Windows Firewall to avoid conflicts. In Windows 7, Microsoft did this themselves. When installing a firewall known to it, the operating system disables its built-in firewall and reports that “the firewall settings are controlled by such and such a program from such and such a manufacturer.”

Whether you use it or not, Windows Firewall is present in every Windows 7, with solid integration with the operating system. So wouldn't it be better if third party security applications could use Windows filewall for their own purposes? This is the idea behind a programming interface called the Windows Filtering Platform. But will developers use it? More on this in the next part.

Windows 7 Security: Windows Filtering Platform

Firewalls must work with Windows 7 at a very low level, which Microsoft programmers absolutely hate. Some Microsoft technologies, such as PatchGuard, present in 64-bit editions of Windows 7 (64-bit Windows 7 have a number of security advantages over 32-bit Windows 7), block attackers and also protect the kernel from access to it. Still, Microsoft does not provide the same level of security as third-party programs. So what to do?

The solution to this problem is the Windows Filtering Platform (WFP). The latter, according to Microsoft, allows third-party firewalls to be based on key features of Windows Firewall - allowing them to add custom capabilities and selectively enable or disable parts of Windows Firewall. As a result, the user can choose a firewall that will coexist with the Windows Firewall.

But how useful is it really for security software developers? Will they use it? I asked a few people and got a ton of responses.

BitDefender LLC

Product development manager Iulian Costache said his company is currently using this platform in Windows 7. However, they have encountered significant memory leaks. The error is on Microsoft's side, which the largest software giant has already confirmed. However, Julian does not know when it will be resolved. In the meantime, they have temporarily replaced the new WFP driver with the old TDI.

Check Point Software Technologies Ltd

Check Point Software Technologies Ltd PR manager Mirka Janus said his company has been using WFP since Vista. They also use the platform under Windows 7. It's a good, supported interface, but any malware or incompatible driver could be dangerous to a security product that relies on it. ZoneAlarm has always relied on two layers - the network connection layers and the packet layer. Starting with Vista, Microsoft offered WFP as a supported way to filter network connections. Starting with Windows 7 SP1, Microsoft must teach WFP to enable packet filtering.

“Using supported APIs means improved stability and fewer BSODs. Many drivers can be registered and each driver developer does not have to worry about compatibility with others. If any driver is, say, blocked, no other registered driver can bypass that blocking. On the other hand, an incompatible driver can become a problem, bypassing all other registered ones. We don't rely on WFP alone for network security.”

F-Secure Corporation

Senior researcher at F-Secure Corporation Mikko Hypponen said that for some reason WFP never became popular among security software developers. At the same time, his company used WFP for quite a long time, and was happy with it.

McAfee, Inc.

In turn, McAfee lead architect Ahmed Sallam said that WFP is a more powerful and flexible network filtering interface than the previous NDIS-based interface. McAfee actively uses WFP in its security products.

At the same time, despite the fact that WFP has positive capabilities, cybercriminals can also take advantage of the platform’s advantages. The platform may allow malware to enter the Windows kernel level network stack. Therefore, 64-bit kernel-level Windows drivers must be digitally signed to protect the kernel from loading malware into it. However, digital signatures are not required on 32-bit versions.

Yes, in theory, digital signatures are a reasonable security mechanism, but in reality, malware authors can still purchase them.

Panda Security

Panda Security spokesman Pedro Bustamante said his company monitors the WFP platform but does not currently use it. The company considers the main disadvantages of WFP to be, firstly, the inability to create a technology that would combine various techniques to maximize protection. Technology is useless if a company can't look at the packets going in and out of the machine. It should also act as a sensor for other security technologies. None of these features are provided by WFP. Secondly, WFP is only supported by Vista and newer operating systems. The platform is not backward compatible. And thirdly, WFP is a fairly new platform, and the company prefers to rely on older and proven technologies.

Symantec Corp.

Dan Nadir, director of consumer product management at Symantec, said that WFP is not yet used in their products due to its relative novelty. However, over time the company plans to migrate to it, because... the old interfaces they currently rely on will not be able to provide the full functionality they require. They consider WFP a good platform because... it was specifically designed to provide interoperability between a variety of third party programs. In principle, the platform should have even fewer compatibility problems in the future. WFP is also great because it is integrated with the Microsoft Network Diagnostic Framework. This is extremely useful because... greatly facilitates the search for specific programs that are an obstacle to network traffic. Finally, WFP should lead to improved operating system performance and stability because... The platform avoids emulation and problems with driver conflicts or stability.

However, on the other hand, according to Nadir, WFP can create certain problems that exist in any structure - developers relying on WFP cannot close vulnerabilities within WFP itself, nor can they expand the specific capabilities offered by WFP. Also, if many programs rely on WFP, malware creators could theoretically try to attack WFP itself.

Trend Micro Inc.

Director of Research at Trend Micro Inc. Dale Liao said that the biggest advantage of the platform is its compatibility with the operating system. Also, a standard firewall has now become useful. So now they can focus on what really matters to the user. The bad thing about WFP is that when an error is discovered in the platform, the company has to wait for it to be fixed by Microsoft.

WFP: Conclusion

As a result, most of the security developers I interviewed already use WFP. True, some in parallel with other technologies. They like interoperability, like the documentation and formality of the platform, and also the perceived stability of its operation. On the other hand, if all developers rely on WFP, then the platform could potentially become a weak point for everyone. And they'll have to rely on Microsoft to fix it. Additionally, the platform does not yet offer packet level filtering.

Another big disadvantage of WFP is that it is not available in Windows XP. Therefore, developers who want to support XP will have to run two parallel projects. However, as XP leaves the market, I think WFP will become more popular among developers.