# Presentation: 148682

## Windows IP Security Filters

- October 23, 2002

- Joe Klemencicjklemenc@fnal.govFermilab Business Services

## What are IP Security Filters?

- New feature in Windows 2000, XP & .NET
- Initially created to authenticate and encrypt communications
- Packet Filtering method adopted by Microsoft during Windows 2000 beta testing

**Notes:**
Originally, NT4 contained IP Filters which allowed an administrator to allow or deny generic types of UDP or TCP data destined for their machines. With Windows 2000, Microsoft added IP Security Filters which allow greater definition of the data types and allows for different types of actions to be performed.

## Intended Usage

- Authenticate host connections
- Negotiate encryption schemes
- Filter access to services by host/subnet

- It is important to note that the Authentication schemes are not User based authentication, but Machine based authentication.

**Notes:**
IP Security Filters were originally implemented to provide authentication and/or encryption services for network connections. IP Security Filters also allow for simple packet filtering by implementing Pass or Block filter actions. Authentication mechanisms are machine-based, not user-based. The authentication methods do not interact with the higher-layer applications, but instead authenticate the communication attempts to the actual service port (such as the initial TCP connection).

## Default Defined Policies	

- Client (Respond Only)
- Request Security (Server)
- Require Security (Server)

- Clients attempting to connect to resources that require Authentication and/or Encryption must have an appropriately configured response policy.

**Notes:**
There are 3 default IP Security Policies defined by default. Client (Respond Only) actives a Kerberos default response rule that will answer IPSEC challenges with Kerberos authentication (using the Machine’s Kerberos ticket). Request Security is for inbound service offerings which challenges clients to authenticate (and possible encrypt) if possible. Require Security requires clients to be able to properly authenticate and/or encrypt their communications. Request Security is good for backward compatibility with NT4 and lower operating systems, while Require Security is useful for only Windows 2000 and greater.

## IP Security Policy Creation

- Group Policy Editor (gpedit.msc) MMC Snap-In GUI manager
- Group Policy Editor within an Active Directory OU Properties
- IPSECPOL.EXE command line utility from the W2K Resource Kit (Windows 2000)
- IPSECCMD.EXE command line utility from the Support Tools on the media CD (XP & .NET)
**Proper planning and testing is the key to a successful policy creation and implementation**

**Notes:**
IP Security Policies can be created in a few different ways. The GUI Group Policy Editor is the easiest and defines a Policy for use on the local machine (which can optionally be exported to be imported on other machines). The IPSECPOL.EXE or IPSECCMD.EXE command line utilities allow for creating filters to be implemented on multiple machines via a batch file or via a remote-push. Administrators may also defined IP Security Filters within a Group Policy Object within Active Directory to be applied to all machines contained within that Organizational Unit.

## Anatomy of an IP Security Policy

- An IP Security Policy consists of:
- IP Filters
- Define who, what, where
- Source IP/Network Address
- Destination IP/Network Address
- Protocol/Port/Service
- IP Filter Actions
- Define how
- Permit
- Block
- Negotiate Security (Authenticate/Encrypt)
- Kerberos (Requires W2K Domain)
- PKI
- Shared Key

**Notes:**
Only one IP Security Policy may be active at any given time. Policies are activated by right-clicking on the policy in the Group Policy Editor and selecting ‘Assign’.

## IP Security Filter Modes

- Dynamic Mode
- Adds anonymous rules to the policy agent
- Can co-exist with a DS based policy
- Static Mode
- Creates or modifies the stored policy
- Overwrites current named policy or activates new named policy

**Notes:**
IP Security Filters operate in 2 modes: Dynamic and Static. Dynamic Mode is the default where the filter rules are anonymously appended to the current policy. This is useful if administrators wish to add specific filters to select workstations without disrupting the filters pushed from a GPO within Active Directory. Static Mode will create a new named policy and can de-activate the currently installed policy and active this new policy. This mode of operation is primarily used for stand-alone IP Security Filter implementations.

## IP Filter Evaluation Order

- Rule Evaluation is from Most Granular to Least Specific
- 	1. My IP Address
- 	2. Specific IP Address Defined
- 	3. Specific IP Subnet
- 	4. Any IP Address
- 	A. Specific Protocol/Port combination
- 	B. Specific Protocol/Any Port
- 	C. Any Protocol

**Notes:**
IP Filters are not processed in a top down fashion, but rather from most granular to least specific. Without proper planning and testing, it is very easy to allow undesirable traffic, or deny legitimate traffic.

## IP Filter Evaluation Order (cont)

- Visualize filter rule processing by applying weights
- Source/Destination Addresses:
- 	My IP Address: 3
- 	Specific IP Address: 2
- 	Specific Network: 1
- 	Any Address: 0
- Protocol Used:
- 	Specified (TCP/UDP/ICMP/RAW/...): 1
- 	Any Protocol: 0
- Source/Destination Service Ports:
- 	Specified (23/80/135/137/139/443/445...): 1
- 	Any Port: 0

**Notes:**
This is a theoretical way to help visualize in what order filters defined within a policy will be evaluated. This will be demonstrated in the next slide.

## IP Filter Evaluation Order (cont)

- Source		Src Port	Dest	Dest Port	Protocol	Action
- Any		Any	MyIP	Any	Any	Block
**0****	****	****0****	****3****	****0****	****0****	****=****	****3**
- Any		Any	MyIP	80	TCP	Permit
**0****	****	****0****	****3****	****1****	****1****	****=****	****5**
- 10.1.1.0	Any	MyIP	Any	Any	Permit
**1****	****	****0****	****3****	****0****	****0****	****=****	****4**
- 10.1.1.0	Any	MyIP	139	TCP	Block
**1****	****	****0****	****3****	****1****	****1****	****=****	****6**
- 	In this example, all traffic from the 10.1.1.0 network, except TCP/139 would be allowed. Also allow TCP/80 traffic from anywhere would be allowed. All other traffic will be blocked.

**Notes:**
This slide demonstrates how to apply the weights to determine which rules will be processed first. This helps to determine if you may potentially deny legitimate traffic, or allow undesirable traffic.

## Mirroring vs. Reverse Rules

- The Mirror Rule option is only activated when defining Authentication or Encryption Filter Actions
- When creating simple Permit/Block Packet Filters, always create the reverse rule at the same time to prevent inadvertent denial of legitimate traffic
- BUT.... The reverse rule may inadvertently allow unsolicited connectivity

**Notes:**
The Mirror Rule option checkbox will automatically create the reverse of the rule to allow for 2-way communication. This option is only activated if the Filter Action selected is Request/Require Security. If defining simple Permit/Block Packet Filters, always manually create the reverse of the rule to prevent an accidental denial of legitimate traffic, or an allow of prohibited traffic.

## Reverse Rule

- Consider the following:

- Src      Src-Port       Dst       Dst-Port       Prot       Action
- MyIP   Any            Any       80                TCP      Permit
- Any     80               MyIP     Any             TCP      Permit
- Any     Any            MyIP     Any             Any       Block

- In this ruleset, we are allowing the local machine to surf the Internet while prohibiting all other communication. An attacker could use a port-redirector and still connect to the local machine’s NetBios service as long as they source their connection from TCP/80.

**Notes:**
If an attacker figures out what types of Packet Filters you have defined, they may still be able to connect to your ‘protected’ services by sourcing their connection attempts with a port that is allowed in your Filters. It is important to not solely rely on IP Security Filters, but use them within a Defense In Depth strategy.

## Sample Implementation Scenarios

- Allow Web services from everywhere, but restrict FTP from only certain hosts

**Simple Packet Filtering**

- Src       Src-Port   Dst       Dst-Port   Prot     Action
- Any      Any       MyIP        80         TCP    Permit
- MyIP    80          Any         Any       TCP    Permit
- MyNet  Any       MyIP       21          TCP    Permit
- MyNet  Any       MyIP       20          TCP    Permit
- MyIP    21          MyNet    Any       TCP     Permit
- MyIP    20          MyNet    Any       TCP     Permit
- Any      Any       MyIP       21          TCP    Block
- Any      Any       MyIP       20          TCP    Block

**Notes:**
In this simple case, we want to allow Web (tcp/80) traffic from everywhere, but restrict FTP to certain hosts (MyNet). In this example ruleset, the reverse connection rules are also built to ensure the return data is not accidentally blocked by other rules.

## Sample Implementation Scenarios

**Service Authentication**

- Allow normal traffic from network, but request a Host to Kerberos authenticate from Wireless network

- This authentication is separate from the Application Authentication Mechanism

- Src          Src-Port   Dst       Dst-Port   Prot     Action
- WLAN   Any          MyIP    Any         Any     Kerberos Auth (auto-mirror)

**Notes:**
In this example, only traffic from WLAN will be required to authenticate via Kerberos. To authenticate via Kerberos, both machines must be Windows 2000 or greater, and both must reside in either the same Windows 2000 domain, or trusted Windows 2000 domains. We do not need to define a rule for the uninhibited communications since we are only authenticating data connections from the WLAN network while allowing all other data communications uninhibited. 

## Sample Implementation Scenarios

**Service Encryption**

- Encrypt communications between servers while allowing for unencrypted traffic from workstations. Also, block communications from non-local workstations

- Src          Src-Port    Dst       Dst-Port   Prot     Action
- DC1        Any          MyIP    Any         Any     Kerberos Auth & Encrypt (auto-mirror)
- MyIP      Any          DC1      Any         Any     Kerberos Auth & Encrypt (auto-mirror)
- MyNet    Any          MyIP    Any         Any     Permit
- MyIP      Any          MyNet  Any         Any     Permit
- Any        Any          MyIP     Any         Any    Block

**Notes:**
In this example, we will be encrypting communications between DC1 and our server, while allowing all other communications to proceed uninhibited. We first create the Authentication and Encryption rules between our server and DC1, then the rules to allow uninhibited communications to/from MyNet. Lastly, we block all other communications.

## Usage Caveats

- Certain traffic is not inspected by an IP Policy
- Anything with a source port of 88 (Kerberos)*
- IKE
- Multicast Traffic
- Broadcast Traffic
- RSVP/Quality of Service
- *This behavior may be changed by setting the following value in the Registry:
- 		**HKLM\SYSTEM\CurrentControlSet\Services\IPSEC\NoDefaultExempt  DWORD=1**
- See Microsoft Q253169 article for more information

**Notes:**
Any service that is sourced with port 88 will not be inspected by the IP Security Filters. This mechanism was included to allow administrators to easily create Filters without first having to define a common rule to allow the native Kerberos default response. This default behavior can be overridden with a registry key, but if Kerberos authentication is utilized, the administrator will need to also create the required Kerberos filters.

## Usage Caveats (cont)

- No logging available when using as a Packet Filter
- Because of Rule Evaluation Order, an ill-defined rule may allow traffic intended to be blocked
- Difficult to implement Packet Filtering on General Use Workstations, but optimal for Kiosks and Servers

**Notes:**
Since the IP Security Filters work in conjunction with the network adapter, there is virtually no troubleshooting capabilities available when diagnosing Packet Filters. However, there do exist utilities and audit settings to assist with IPSEC communications. Ensure that you apply the weights you your rules to ensure no unsolicited traffic is permitted by your Filters. Using Packet Filtering on general use workstations is not advised. Due to the simple nature of the packet filtering vs. the dynamic nature of most workstations, it would be next to impossible to use the Filters as a type of ‘Personal Firewall’. However, if you only want to block certain types of traffic or networks, or have a static environment with clearly defined service offerings, such as a File and Print server or a Kiosk, IP Security Filters are a great fit. 

## Further Reading

- Securing W2K with IP Filters: Part 1 (Step-by-Step How-To Guide)
- 	_[http://online.securityfocus.com/infocus/1559](http://online.securityfocus.com/infocus/1559)_
- Securing W2K with IP Filters: Part 2 (Implementing Encryption)
- 	_[http://online.securityfocus.com/infocus/1566](http://online.securityfocus.com/infocus/1566)_
- Using IPSEC to Lock Down a Server
- 	_[http://www.microsoft.com/serviceproviders/columns/using_ipsec.asp](http://www.microsoft.com/serviceproviders/columns/using_ipsec.asp)_
- Active Directory Replication Over Firewalls
- 	_[http://www.microsoft.com/serviceproviders/columns/config_ipsec_P63623.asp](http://www.microsoft.com/serviceproviders/columns/config_ipsec_P63623.asp)_
- Microsoft Q254949 Article: Domain Controller IPSEC Support
- 	_[http://support.microsoft.com/default.aspx?scid=kb;en-us;Q254949](http://support.microsoft.com/default.aspx?scid=kb;en-us;Q254949)_
- How to Enable IPSEC Through a Firewall
- 	_[http://support.microsoft.com/default.aspx?scid=kb;en-us;Q233256](http://support.microsoft.com/default.aspx?scid=kb;en-us;Q233256)_