I recently attended a Windows Vista security session at Microsoft, presented by Steve Lamb. Windows Vista security is too broad to cover in a single presentation (or even in a single blog post!) but some of the key points that Steve concentrated on were around the Windows firewall and IPsec. This post picks up on the main points from Steve’s presentation.

The Windows XP firewall was criticised by some because it only inspected inbound traffic. Microsoft responded to customer demands and, in Windows Vista, the firewall also inspects outbound traffic; however it should be noted that a compromised machine can have its firewall disabled, so the presence of the firewall is not a reason to feel complacent; indeed Steve Lamb used the term security theatre (http://en.wikipedia.org/wiki/Security_theatre) to highlight security products that promise much and offer little.

Consider the following process:

I wrote about this problem a while back, but in short, outbound control can only be relied upon where the computer is not compromised and the user cares about security – i.e. not on those machines where it is needed (compromised computers where the users don’t care about security)! It can be useful for restricting known software from communicating; however in such cases, prompting should be disabled.

Trying to find a balance between ease of use/flexibility and security, the default actions for the Windows firewall are:

• Inbound – block most traffic, with a few exceptions.
• Outbound – allow all interactive traffic but restrict services.

Allow/block rules can be configured for programs, services, users, computers, protocols or ports.

The Windows Vista firewall feature list is extended in other ways too:

The Windows filtering platform (WFP) is a series of APIs, designed to allow developers to hook into the network stack without requiring kernel changes. WFP provides authenticated communication, dynamic firewall configuration, a foundation for the Windows firewall and IPsec, works with encrypted traffic, and because it is fully documented there is little risk that a service pack release will break third-party applications. Architecturally, this also provides improvements with synchronous API calls, exposure of the user context for auditing policy changes, access control lists on API calls (no longer using registry ACLs and escaltion of privilege) and incremental policy updates.

Firewall configuration is still available from the Control Panel (with a few minor presentation differences); however a new Windows Firewall with Advanced Security MMC snap-in is provided which can also be used to assign settings to remote computers and to apply IPsec configuration. The new MMC snap-in is complemented with a new netsh advfirewall command line interface.

When merging and evaluating rules, the following order is applied, from highest priority to lowest:

• Service restrictions (restricting connections that can be established by services – operating system services are configured appropriately by default).
• Connection rules (restricting connections from particular computers using IPsec for authentication and authorisation).
• Authenticated bypass (allowing specified computers to bypass other rules).
• Block rules (explicitly blocking incoming or outgoing traffic).
• Allow rules (explicitly allowing incoming or outgoing traffic).
• Default rules (the default behaviour for a connection).

It should be noted that these rules are stored in the registry; however editing them directly is unsupported.

Firewall exceptions are also more flexible, including the ability to filter based on:

• Active Directory user accounts and groups.
• Source/destination IP addresses/range.
• Source/destination TCP/UDP ports.
• Comma-delimited list of ports.
• IP protocol number.
• Interface type.
• ICMP type and code.
• Services.

Support is also provided for multiple network profiles:

• Domain – domain joined and connected to the domain (i.e. able to authenticate).
• Private – connected to a defined private network (home or work).
• Public – all other networks.

Network location awareness (NLA) detects networking changes and assigns each connection a GUID, whereby the network profile service (NPS) creates a profile upon connection and notifies the firewall whenever NLA detects a change. Local administrator privileges are required in order to define that a network is private and the computer defines the category when multiple interfaces are in use based on the logic in the accompanying diagram.

Windows Firewall group policy processing is also enhanced. Previously, computer policies were applied on operating system boot and user policies at logon, with a periodic refresh. Windows Vista extends this to apply computer and user policies when establishing a VPN connection or when resuming from hibernation/standby. Of course, firewall policies are set at the computer level, although they can be further restricted with per-user settings as previously described.

Windows Vista enhanced IPsec capabilities are integrated with the Windows Firewall, eliminating confusion with overlapping rules and allowing firewall rules to be IPsec-aware. IPsec configuration has been simplified in Windows Vista but it is still a complex subject, worthy of a separate post; however there are a couple of points worth noting:

• Authenticated headers (AH) traffic is not compatible with network address translation (NAT) as it cannot be routed – an alternative is to use encapsulated payload (ESP) with 0-bit encryption to effectively provide the same function.
• Shared secrets are stored as plain text in the registry so should not be used in production scenarios – certificates or Kerberos should be used instead for authentication.

In summary, Microsoft has made significant improvements to the Windows Firewall in Vista and anyone who is not using a third party product (and I would question the need for the use of third party firewalls in Vista) should turn it on right away, otherwise they are asking for trouble.

There’s been a lot written about Windows Vista’s user account control (UAC) and personally I can’t see what the criticsm is about (Mac OS X and Linux both have similar mechanisms, although the implementation is slightly different); however it was interesting to hear Steve Lamb mention at a recent event that commands launched from a command shell (cmd.exe) running as administrator will not invoke UAC.

Of course it goes without saying that, just as when running a root shell in Linux, the use of such sessions should be limited and I’ve written previously about how the shortcut to run cmd.exe as an administrator can be modified to make it very obvious that elevated permissions are in use.

Steve also pointed out that, if developers wrote less code that requires privileged execution, then UAC would not appear so frequently. Although UAC behaviour can be modified in group policy, it is not recommended.