More on WPAD

Last week I blogged about configuring WPAD for Internet Explorer clients. Since then I’ve come across some more information that might be useful:

Configuring web proxy auto discovery for Internet Explorer clients

Over the last few weeks, I’ve been looking at using web proxy auto discovery (WPAD) to let a client’s PCs automatically discover the location of their Microsoft ISA Server 2000 web proxy servers through the Internet Explorer client. Note that WPAD is used by web proxy clients and firewall clients use winsock proxy auto detection (WSPAD).

Microsoft knowledge base article 296591 gives background information on WPAD (for WSPAD see Microsoft knowledge base article 260210) but basically, what is involved is:

  • A properly configured web proxy client (i.e one which has automatically detect settings checked in the Internet Explorer LAN connection settings) queries the DHCP server for option 252, which identifies an HTTP address for a file called wpad.dat which is ISA Server’s dynamically generated proxy auto configuration (PAC) file.
  • If a DHCP server does not respond with option 252, the web proxy client attempts to access http://wpad.domainsuffix:80/wpad.dat (or http://wpad.domainsuffix:80/wspad.dat for the firewall client). To locate this URL, the remote client queries its configured DNS servers for wpad.domainsuffix – obviously issues with incorrectly configured domain suffixes will prevent automatic discovery from working. Microsoft knowledge base article 307502 also indicates that the WPAD address is case sensitive.

It should be noted that WPAD is not supported for clients that connect to the LAN with any type of dial-up connection.

To set up WPAD, three steps are involved, as detailed in Microsoft knowledge base article 309814 (Windows 2000) and Microsoft knowledge base article 816320 (Windows Server 2003):

  • The web proxy servers must publish automatic discovery information (which might require the web proxy service to be restarted).
  • DHCP (and optionally, DNS) needs to be configured to send the WPAD URL to the web proxy client (as detailed in Microsoft knowledge base article 252898).
  • Finally, the clients need to be set to automatically detect settings.
  • We planned to roll out WPAD on a site-by-site basis, using DHCP (adding a DNS entry would affect all clients) and everything looked good using DHCP alone (no DNS installed) in my test environment; however the existing route used for production clients to access the Internet is direct via the firewall, and so the clients failed to use the DHCP-assigned WPAD information as the direct path was working (that’s the theory – it is difficult to diagnose the DHCP traffic to that level of certainty, other than using a network monitor and examining packets).

    One possibility for the failure is described in Microsoft knowledge base article 312864 but I could not replicate this behaviour in testing and as it is only linked from the Windows Server 2003 version of the knowledge base article describing configuration of firewall and web proxy client auto discovery, I am not convinced that the article applies to clients using Windows 2000 DHCP servers.

    The current plan is to use a group policy object, filtered by group membership, to manipulate client proxy settings and use http://proxyarray.domainname.suffix/wpad.dat as an automatic configuration script. This has the advantage that we can control who can access the Internet (take a user out of the group to remove their proxy access – once the direct path has been removed), but does not use WPAD at all.

    One comment which my client made was that the wpad.dat file which ISA Server uses looks complex compared to the .PAC files used by the parent company’s web proxy servers. We could have used a simple .PAC file, but the major advantage of wpad.dat is that it is updated dynamically to reflect changes in the proxy server configuration.

    Allowing ISA Server 2000 web proxy clients to use non-standard ports for HTTPS

    I spent most of today trying to get some ISA Server 2000 web proxy clients to access a web application using HTTPS on a non-standard port (4443). The issue was further complicated by the fact that the application server needed to be accessed using an upstream proxy server. Once the network manager had verified that the upstream proxy could access HTTPS requests on 4443 (and I had tested using my browser and the upstream proxy settings), it took me a while to work out why ISA Server wasn’t forwarding the requests. Instead, my proxy logs were showing some strange results:

    sourceip anonymous Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) 2005-07-15 15:13:13 isaservernametargetserver – 4443 – 212 2855 SSL-tunnel CONNECT – – 407
    sourceip anonymous Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) 2005-07-15 15:13:13 isaservernametargetserver – 4443 – 316 537 SSL-tunnel CONNECT – – 407
    sourceip domainname\username Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) 2005-07-15 15:13:13 isaservernametargetserver – 4443 – – – SSL-tunnel – targetserver:4443 Inet 12204

    Because the logs suggested that the ISA server was forwarding requests to the Internet, I thought that I needed to set up another destination set for the application server and a separate routing rule for access to this server using the non-standard port number. That turned out to be completely wrong (and I’ve since removed both the new destination set and the routing rule). I still don’t know why the 407 errors occur (HTTP client error 407 means proxy authentication required) but the 12204 error led me to the answer, which is contained in Microsoft knowledge base article 283284.

    “With secure socket layer (SSL) tunneling, a client can establish a tunnel through ISA Server directly to the web server by using the requested HTTPS object. Whenever a client browser requests an HTTPS object through ISA Server, it uses SSL tunneling. SSL tunneling works by default for outgoing client requests to ports 443 and 563.”

    The article also includes the VBScript code to add a port to the ISA Server’s tunnel port range. Depending on the version of ISA Server in use, this information is stored in a different location:

    • For ISA Server 2000 Standard Edition, ISA Server 2000 Enterprise Edition (standalone mode), and ISA Server 2004 Standard Edition: ISA storage is maintained in the registry.
    • For ISA Server 2000 Enterprise Edition (array mode): ISA Storage is maintained in Active Directory.
    • For ISA Server 2004 Enterprise Edition: ISA Storage is maintained in the Active Directory application mode (ADAM) configuration storage server).

    Although the code to do this is contained within the Microsoft article, Jim Harrison has made the script available for download from his ISA Server tools repository. Once I had edited the script to change the port number to 4443, I ran it on one of the array members and force refreshed the settings by selecting the array in the ISA Management console and pressing F5. What none of the newsgroup information I found on this topic told me (although to be fair the Microsoft article says that a restart of the Microsoft ISA Server Control service is required) is that it also didn’t take effect until I restarted the web proxy service on my ISA Servers. Another item to note from the Microsoft article is that the script does not produce any output if it succeeds and if it is run again, it will produce an error because the range being set already exists.

    Once I had restarted the web proxy service, my clients could access the web application using port 4443 and the ISA Server logs showed a successful connection via the upstream proxy server:

    sourceip domainname\username Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) 2005-07-15 16:56:01 isaservernameupstreamproxyname upstreamproxyip upstreamproxyport – 726 2258 SSL-tunnel – targetserver:4443 Upstream 995

    Chaining proxy servers

    I spent some time yesterday chaining two ISA Server 2000 proxy arrays. As there doesn’t seem to be a lot of information about on the subject, I thought I’d provide some here (most of what can be found easily is about using proxy chaining for anonymity, and mostly reads as if it’s intended for nefarious purposes).

    Both Microsoft Proxy Server and Microsoft Internet Security and Acceleration (ISA) Server can be configured in a chain to distribute the web cache, forming hierarchical configurations with other proxy servers. One example of where this might be useful is for networks with geographically separated segments, such as branch offices. The proxy chain allows servers to query an upstream server’s cache before accessing resources on the Internet. Using this type of configuration, the clients in the branch office benefit from a local cache as well as the cache at the main office.

    Proxy chaining is also known as proxy cascading or hierarchical caching and it is primarily used to improve cache performance and balance the caching load by placing information closer to proxy clients (note that only client requests for the web proxy service can be routed upstream because only the web proxy service uses caching).

    My client’s scenario was slightly different. They have two proxy arrays – one for the Americas and another for Europe, the Middle East and Africa (EMEA) but they also need to access resources in their parent company using that company’s proxy server (accessed across the private network). Using this configuration, any requests that are not cached in the local proxy will require Internet access, unless the domain name matches the internal domain name for the parent company in which case they need to be forwarded to the parent company’s proxy servers.

    This is fairly straightforward to configure but it is important to check first that the proxy server(s) can perform a DNS lookup for the upstream proxy server(s) and access the appropriate network. When I originally configured the proxy array, I had secured the network interfaces and added a static route to the organisation’s internal network using the route -p add networkaddress mask subnetmask gatewayaddress command but I also had to add a route to the parent company’s network, otherwise all requests that didn’t match the internal network were routed via the external (Internet-facing) default gateway. Once I could both resolve the upstream proxy server names in DNS and ping them I was ready to configure the routes in ISA Server.

    I already had a destination set for the internal domain, based on the IP address range for the internal network (, so I added another one for the parent company’s internal DNS domain name (*.companyname.countrycode). Once this was complete, I could establish a new routing rule in the ISA Server network configuration. Leaving the default rule in place as the last to be applied (routing all destinations directly to the specified destination), I added another rule with a higher rank order which applied to my new destination set and routed them to a specified upstream server (i.e. the parent company’s proxy server), with no caching in this case. Verifying the configuration was as simple as accessing the sites from a browser and reviewing the access logs, where access requests for the parent company’s internal sites were shown with an s-object-source of “upstream”.

    Anyone worried about running Microsoft ISA Server as a firewall?

    Over the last few years just about every network administrator I’ve worked with has laughed at the idea of a Microsoft firewall in an enterprise environment (at least as a front line of defence – many organisations use Microsoft ISA Server behind another firewall). When forced by the American parent company to run Check Point FireWall-1 on a Windows platform instead of a Nokia appliance server, one of my ex-colleagues in the European subsidiary of a major fashion design, marketing and retail company was disgusted; but in all honesty, a well-patched and well-managed Windows system can just as secure as a well-patched Linux one (and conversely badly patched systems are badly patched, whoever the operating system vendor).

    The Common Criteria Evaluation and Certification Scheme (CCS) is an independent third party evaluation and certification service for measuring the trustworthiness of IT security products, recognised by governments in Canada, the United States, United Kingdom, Netherlands, Germany and France.

    Windows 2000 Professional, Server, and Advanced Server with service pack 3 and the hotfix described in Microsoft knowledge base article 326886 has been certified for common criteria evaluation assurance level (EAL) 4+; and ISA Server 2000 with service pack 1 and feature pack 1 (in firewall mode) has EAL 2 certification. According to Microsoft, Windows XP with service pack 2, Windows Server 2003 with service pack 1 and ISA Server 2004 are all undergoing EAL 4+ certification at present.

    In addition, ICSA Labs tests firewall products against a standard yet evolving set of criteria and Microsoft ISA Server 2000 with service pack 1 running on Windows server 2000 with service pack 4 has been certified by ICSA. As a side note, for anyone looking at the area of firewalls, the ICSA firewall buyer’s guide is worth a read.

    So it seems that a Windows server can be secure enough to run a firewall; and that Microsoft’s firewall product is also pretty secure. EAL 2 might not be the highest certification level, but if ISA Server 2004 achieves EAL 4+, then maybe all of those network administrators’ minds can be put to rest.

    Installing and verifying the configuration of an ISA Server 2000 array

    Just over a year ago, I posted a blog entry which gives a 10,000 feet view of Microsoft ISA Server 2000. I haven’t done anything with ISA Server since then but over the last few days, I’ve been installing an new ISA Server 2000 array into an existing enterprise for a client.

    Nothing too complicated about that – once I had secured the network interfaces and installed the ISA servers, there were just a few extra settings to configure (see getting started with ISA Server) to ensure that the new array would allow outbound traffic, but I did start to doubt myself when my test clients were receiving error 10060 connection timeouts (although the logs from the upstream firewall reported that it was letting the outbound requests pass). It transpired that there was an issue with the ISP’s network, but as anyone who has ever been in that situation will know, convincing an ISP that there is a problem their end is not always easy, and I also asked two of my colleagues to check my configuration (just in case!).

    Although I installed in integrated mode (for future flexibility), my client only needed the caching functionality, so I stopped and disabled the Microsoft Firewall service. Everything seemed fine as the clients were connecting okay via HTTP, HTTPS or FTP and the upstream firewall logs reported all the client requests as coming from my proxy servers; but I wanted to be sure that the array servers were co-operating and that the cache was being populated as my test clients hit the new array.

    Understanding how the client requests are processed is straightforward – by default, ISA Server maintains a log file in %programfiles%\Microsoft ISA Server\ISALogs\, which for the Microsoft Web Proxy service is named webextdyyyymmdd.txt. This file contains a whole host of information about requests received and how they were answered, including a useful field called s-object-source, which shows where the request was retrieved from (e.g. “member” for another member of the array, “inet” for the Internet or “cache” for the ISA Server cache – full details can be found in the Microsoft Internet Security and Acceleration Server Enterprise Edition product documentation). From looking at the ISA Server logs, I was confident that both servers were working, and resolving requests between one another using the cache array routing protocol (CARP) but I still wanted to check that the caches on both of the ISA Servers in the array were being populated.

    Microsoft provides a useful utility with ISA Server 2000 – the ISA Server Cache Directory Tool (cachedir.exe), found on the ISA Server CD in the \support\tools\troubleshooting\ folder. Once copied to the ISA Server folder (by default, %programfiles%\Microsoft ISA Server\), this can be used to view the contents of the cache. I could see some entries in the cache on one server, but not the most recent requests, and running the tool on the other server returned an empty cache. Then I remembered that ISA server caches in memory first (by default 50% of available RAM), and only uses (slow) disk cache when the (fast) memory cache is full. The different results on each server were because I had restarted the Microsoft Web Proxy service on one server but not on the other. Once I restarted the Microsoft Web Proxy service on the second server, I could see all of the expected cache entries on disk as the memory cache is flushed to disk when the Web Proxy service is stopped. For reference, the ISA Server documentation gives an explanation of the ISA cache files.

    All in all, it has been a successful implementation, if slightly protracted by the ISP issues and my stupidity around cache contents. Now I can put those issues down to experience, but I thought posting them into the blogosphere might help out some other poor soul with an ISA server to configure in a hurry.

    Securing the network using Microsoft ISA Server 2004

    Several months ago, I attended a Microsoft TechNet UK event where the topic was ISA Server 2004 network design/troubleshooting and inside application layer firewalling and filtering. It’s taken me a while to get around to writing up the notes, but finally, here they are, with some additional information that I found in other some similar presentations added for good measure.

    The need for network security

    The Internet is built on internetworking protocol (IP) version 4 – which was not designed with security in mind. In the early days of the Internet, security clearance was required for access – i.e. physical access was restricted – so there was no requirement for protocol security. At that time (at the height of the cold war), resistance to nuclear attack was more important than protecting traffic and everyone on the network was trusted. The same networking technologies used to create the Internet (the TCP/IP protocol suite) are now used for internal networks and for TCP/IP, security was an afterthought.

    Security should never be seen as a separate element of a solution – it should all pervasive. At the heart of the process should be a strategy of defence in depth – not just securing the perimeter or deploying some access controls internally, but placing security throughout the network so there are several layers to thwart malware or a hacker. Ideally, an administrator’s security strategy toolbox should include:

    • Perimeter defences (packet filtering, stateful packet inspection, intrusion detection).
    • Network defences (VLAN access control lists, internal firewall, auditing, intrusion detection).
    • Host defences (server hardening, host intrusion detection, IPSec filtering, auditing, active directory).
    • Application defences (anti-virus, content scanning, URL switching source, secure IIS, secure Exchange).
    • Data and resource defences (ACLs, EFS, anti-virus, active directory).

    Each layer of defence should be designed on the assumption that all prior layers have failed.

    With users becoming ever more mobile, defining the edge of the network is becoming ever more difficult. Firewalls are no panacea, but properly configured firewalls and border routers are the cornerstone of perimeter security. The Internet and mobility have increased security risks, with virtual private networks (VPNs) softening the perimeter and wireless networks further eroding the traditional concept of the network perimeter.

    A firewall alone is not enough

    Some administrators take the view that “we’ve got a firewall, so everything is fine”, but standard (layer 3/4) firewalls check only basic packet information and treat the data segment of the packet as a black box. This is analogous to looking at the number and destination displayed on the front of a bus, but not being concerned with the passengers on board. Performance is often cited as a the reason for not implementing application layer (layer 7) firewalls, which inspect the data segment (e.g. for mail attachment checking, HTTP syntax, DNS syntax, correct SSL termination, URL blocking and redirection, RPC awareness, LDAP, SQL, etc.). However, Microsoft claim to have tested Internet Security and Acceleration (ISA) Server 2004 up to 1.9Gbps throughput on a single server with application filters in place (at a time when most corporates are dealing with 2-10Mbps).

    Consider the standard security pitch, which has two elements:

    1. The sky is falling (i.e. we’re all doomed).
    2. Our product will fix it (i.e. buy our product).

    In truth, no system is 100% effective and the firewall needs to be supplemented with countermeasures at various depths (intrusion detection systems, etc.). If there was a 100% secure system it would be incredibly expensive – in addition, threats and vulnerabilities are constantly evolving, which leaves systems vulnerable until a new attack is known and a new signature created and distributed. Heuristical systems must be supplemented with behavioural systems, and some intelligence.

    Just because 100% security is not achievable, it doesn’t mean that it is any less worthwhile as a goal. We still lock our car doors and install immobilisers, even though a good car thief can defeat them eventually. The point is that we stop the casual attacker, buying time. Taking another analogy, bank safes are sold on how long it will take a safe cracker to break them.

    Whatever solution is implemented, a firewall cannot protect against:

    • Malicious traffic passed on open ports and not inspected at the application layer by the firewall.
    • Any traffic that passes through an encrypted tunnel or session.
    • Attacks on a network that has already been penetrated from within.
    • Traffic that appears legitimate.
    • Users and administrators who intentionally or accidentally install viruses or other malware.Administrators who use weak passwords.

    HTTP is the universal firewall bypass and avoidance protocol

    In the late 1990s, as business use of the Internet exploded, we became to rely ever more on HTTP, which has earned itself a nickname – UFBAP – the universal firewall bypass and avoidance protocol.

    Firewall administrators are obsessed with port blocking and so all non-essential firewall ports are closed; but we generally assume that HTTP is good and so TCP port 80 (the default port for HTTP) is left open. Because it’s so difficult to get an administrator to open a port, developers avoid such restrictions by writing applications that tunnel over port 80. We even have a name for it (web services) and some of our corporate applications make use of it (e.g. RPC over HTTP for Outlook connecting to Exchange Server 2003).

    This tunnelling approach is risky. When someone encapsulates one form of data inside another packet, we tend to allow it, without worrying about what the real purpose of the traffic is. There are even websites which exploit this (e.g. HTTP-Tunnel), allowing blocked traffic such terminal server traffic using the remote desktop protocol (RDP) to be sent to the required server via TCP port 80, for a few dollars a month.

    In short, organisations, tend to be more concerned with blocking undesirable sites (by destination) than checking that the content is valid (by deep inspection).

    Using web services such as RPC over HTTP to access Exchange Server 2003 is not always bad – 90% of VPN users just want to get to their e-mail and so offering an HTTP-based solution can eliminate many of the VPNs that are vulnerable network entry points – what is required is to examine the data inside the HTTP tunnel and only allowing it to be used under certain scenarios. Taking the Exchange Server 2003 example further, without using RPC over HTTP, the following ports may need to be opened for access:

    • TCP 25: SMTP.
    • TCP/UDP 53: DNS.
    • TCP 80: HTTP.
    • TCP/UDP 88: Kerberos.
    • TCP 110: POP3.
    • TCP 135: RPC endpoint mapper.
    • TCP 143: IMAP4.
    • TCP/UDP 389: LDAP (to directory service).
    • TCP 691: Link state algorithm routing protocol.
    • TCP 1024+: RPC service ports (unless DC and Exchange restricted).
    • TCP 3268: LDAP (to global catalog).

    Using HTTP over RPC, this is reduced to one port – TCP 80.

    Application layer filtering

    Inspection at the application layer still has some limitations and the real issue is understanding the purpose of the traffic to be filtered and blocking non-consistent traffic.

    Microsoft ISA Server 2004 is typically deployed in one of three scenarios:

    • Inbound access control and VPN server.
    • Outbound access control and filtration (together with URL-based real time lists from third parties).
    • Distributed caching (proxy server), leading to reduced bandwidth usage.

    As part of its access control capabilities, ISA Server has a number of application filters included:

    • HTTP (syntax analysis and signature blocking).
    • OWA (forms based authentication).
    • SMTP (command and message filtering).
    • RPC (interface blocking).
    • FTP (read only support).
    • DNS (intrusion detection).
    • POP3 (intrusion detection).
    • H.323 (allows H.323 traffic).
    • MMS (enabled Microsoft media streaming).

    All of these filters validate protocols for RFC compliance and enable network address translation (NAT) traversal. In addition, ISA Server can work with third party filters to avoid the need for a proliferation of dedicated appliance servers (and even for appliance consolidation). Examples of third-party filter add-ons include:

    • Instant messaging (Akonix).
    • SOCKS5 (CornerPost Software).
    • SOAP/raw XML (Forum Systems).
    • Antivirus (McAfee, GFI, Panda).
    • URL Filtering (SurfControl, Futuresoft, FilterLogix, Cerberian, Wavecrest).
    • Intrusion detection (ISS, GFI).

    But appliance firewalls are more secure – aren’t they?

    Contrary to popular belief, appliance firewalls are not necessarily more secure – just more convenient – for those who prefer to use appliances, ISA Server is available in an appliance server format and such an appliance may well be cheaper than an equivalent server, plus Windows Server 2003 and ISA Server 2004 licenses.

    Whilst looking at the security of the solution itself, ISA Server has been tested against the common certification criteria at level EAL4+ (for 9 streams). Totally rewritten since ISA Server 2000, Microsoft claim that ISA Server 2004 uses a code base which is 400% more efficient. It may run on a Windows platform, but Windows Server 2003 can (and should) also be hardened, and a well-configured ISA Server can be extremely secure.

    Some firewall challenges: remote procedure calls (RPCs)

    RPC CommunicationsRPCs present their own challenge to a standard (layer 3/4) firewall in terms of the sheer number of potentially available ports:

    1. On service startup, the RPC server grabs random high port numbers and maintains a table, mapping UUIDs to port numbers.
    2. Clients know the UUID of the required service and connect to the server’s port mapper using TCP port 135, requesting the number of the port associated with the UUID.
    3. The server looks up the port number of the given UUID.
    4. The server responds with the port number, closing the TCP connection on port 135.
    5. From this point on the client accesses the application using the allocated port number.

    Due to the number of potential ports, this is not feasible using a traditional firewall (it would require 64512 high ports plus 135 to be open); however, a layer 7 firewall could utilise an RPC filter to learn the protocol and use its features to improved security, such that the firewall would only allow access to specific UUIDs (e.g. domain controller replication, or Exchange/Outlook RPC communications) denying access to all other RPC requests. Instead of tunnelling within HTTP (prevented by an HTTP syntax check), native RPC access can be provided across the firewall.

    Some firewall challenges: secure sockets layer (SSL)

    Protecting HTTPS - traditional firewallHackers will always attack the low-hanging fruit (i.e. easy targets) and as such, SSL attacks are generally too complex, but as our systems become more secure (i.e. we remove the low-hanging fruit), SSL attacks will become more likely.

    HTTPS (which uses SSL) prompts a user for authentication and any user on the Internet can access the authentication prompt. SSL tunnels through traditional firewalls because it is encrypted, in turn, allowing viruses and worms to pass through undetected and infect internal servers.

    Using ISA Server 2004 with an HTTP filter, authentication can be delegated. In this way, ISA Server pre-authenticates users, eliminating multiple authentication dialogs and only allowing valid traffic through. This means that the SSL connection is from the client to the firewall only, and that ISA Server can decrypt and inspect SSL traffic. Onward traffic to the internal server can be re-encrypted using SSL, or sent as clear HTTP. In this way, URLScan for ISA Server can stop web attacks at the network edge, even over an encrypted inbound SSL connection.

    Protecting HTTPS - web publishingPre-authentication means that without a valid layer 7 password, there is no access to any internal systems (potential attackers drop from the entire Internet to just the number of people with credentials for the network). ISA Server 2000 can also perform this using RSA securID for HTTP (although not for RPC over HTTP with securID) and cookie pre-authentication for Outlook Web Access 2003 is also available.

    Some firewall challenges: protecting HTTP(S)

    Protecting HTTP (and HTTPS) requires an understanding the protocol – how it works, what its rules are and what to expect. Inbound HTTPS termination is easy (as the certificate is controlled by the organisation whose network is being protected). For outbound HTTPS and HTTP, administrators need to learn how to filter port 80/443. It may be worth considering whether global access is really required, or whether there are a set of specific sites that are required for use by the business.

    ISA Server allows web publishing of HTTP (as well as other protocols such as SMTP). Web publishing protects servers through two main defences:

    • Worms rarely work by FQDN – tending to favour IP or network range. Publishing by FQDN prevents any traffic from getting in unless it asks for the exact URL and not just
    • Using HTTP filter verbs (signature strings and method blocking) to eliminate whole classes of attack at the protocol level.

    Some examples of protecting a web server using web publishing and HTTP filtration are:

    • Limit header length, query and URL length.
    • Verify normalisation – is not allowed.
    • Allow only specified methods (GET, HEAD, POST, etc.).
    • Block specified extensions (.EXE, .BAT, .CMD, .COM, .HTW, .IDA, .IDQ, .HTR, .IDC, .SHTM, .SHTML, .STM, .PRINTER, .INI, .LOG, .POL, .DAT, etc.)
    • Block content containing URL requests with certain signatures (.., ./, \, :, % and &)
    • Change/remove headers to provide disinformation – putting ISA Server in front of an Apache server is a great way to prevent UNIX attacks by making hackers think they are attacking a Windows server.
    • Block applications based on the header.

    Some headers to look for include:

    • Request headers:
      • MSN Messenger: HTTP header=User-Agent; Signature=MSN Messenger
      • Windows Messenger: HTTP header=User-Agent; Signature=MSMSGS
      • AOL Messenger (and Gecko browsers): HTTP header=User-Agent; Signature=Gecko/
      • Yahoo Messenger: HTTP header=Host;
      • Kazaa: HTTP header=P2P-Agent; Signature=Kazaa, Kazaaclient
      • Kazaa: HTTP header=User-Agent; Signature=Kazaa Client
      • Kazaa: HTTP header=X-Kazaa-Network; Signature=KaZaA
      • Gnutella: HTTP header=User-Agent; Signature=Gnutella
      • Gnutella: HTTP header=User-Agent; Signature=Gnucleus
      • Edonkey: HTTP header=User-Agent; Signature=e2dk
    • Response header:
      • Morpheus: HTTP header=Server; Signature=Morpheus

    Some firewall challenges: protecting DNS

    Whilst some DNS protection is available by filtering TCP/UDP ports 53, ISA Server filters can examine traffic for DNS host name overflows, length overflows, zone transfer from privileged ports (1-1023), zone transfer from high ports (1024 and above).

    Some firewall challenges: protecting SMTP

    When it comes to mail protection, anti-spam and anti-virus vendors cover SMTP relays but ISA server filters can examine protocol usage, i.e.:

    • Checking that TCP port 25 traffic really is SMTP.
    • Checking for a buffer overflow to the RCPT: command.
    • Blocking someone using the VRFY command.
    • Stripping an attachment or block a user.

    Using such a solution adds to the defence in depth strategy, using the firewall to add another layer of defence to the mail system.

    Some firewall challenges: encapsulated traffic

    Encapsulated traffic can cause some concerns for a network administrator as IPSec (AH and ESP), PPTP, etc. cannot be scanned at the ISA Server if they are published or otherwise allowed through. Tunnelling traffic will be logged, but not scanned as ISA cannot look inside the tunnel unless it is terminating the VPN. The administrator is faced with a choice – open more ports and uses application filters – or tunnel traffic without inspection. NAT also has some implications.

    ISA Server can, however, perform intra-tunnel VPN inspection, so VPN traffic can be inspected at the application layer. VPN client traffic is treated as a dedicated network so destinations can be controlled, along with the use of application filter rules.

    VPN clients must be hardened. If not, then hackers can attack clients and ride the VPN into the corporate network. Client based intrusion detection systems and firewalls can help but the ideal solution is VPN quarantine (e.g. Windows Server 2003 network access quarantine control) as the most common entry to the network for malware is from mobile devices either VPNing into the network, or returning to the network after being infected whilst away from the network (perhaps connected to other networks, including the Internet).

    Alternatives to a VPN that should be considered are:

    • E-mail: RPC over HTTP, or Outlook Web Access (OWA). POP3 and IMAP4 should be avoided as they are not fully featured.
    • Web-enabled extranet applications: SSL.
    • Other applications: RPC filtration with ISA Server.

    Don’t forget the internal network

    Internal network defences are another factor to be considered. Networks are generally one large TCP/IP space, segmented by firewalls to the Internet. Trust is implicit throughout the organisation but this cannot be relied upon and network segmentation is critical (cf. a bank, where entering a branch does not gain access to the vault). Internal users are dangerous too.

    • The windows firewall in Windows XP SP2 (internet connection firewall in Windows Server 2003 and earlier versions of Windows XP) is a vital tool in preventing network-based attacks, by blocking unsolicited inbound traffic. Ports can be opened for services running on the computer, and enterprise administration facilitated through group policy. Microsoft recommend that use of the Windows Firewall is combined with network access quarantine control; however it does not have any egress filters (i.e. controls over outbound traffic).
    • Virtual LANs (VLANs) can be used to isolate like services from one another. Switch ACLs are used to control traffic flow between VLANs at layer 3. Layer 2 VLANS may be used where no routing is desired. By using internal firewalls, port level access can be controlled to internal VLANs.
    • IPSec is a method of securing internal IP traffic, mutually authenticating end points. It is used to ensure encrypted and authenticated communications at the IP layer, providing a transport layer security that is independent of applications or application layer protocols. It prevents against spoofing, tampering in the wire and information disclosure. Mutual device authentication can be provided using certificates, kerberos (or pre-shared key – but this is only recommended for testing scenarios). Authentication headers (AH) should be used to provide packet integrity, but this does not encrypt, allowing for network intrusion detection. Encapsulation security payload (ESP) provides packet integrity and confidentiality, but its encryption prevents packet inspection. Consequently, careful planning is required to determine which traffic should be secured.

    One use of IPSec is to allow domain replication to pass through firewalls, creating an IPSec policy on each domain controller to secure traffic to its replication partners. ESP 3DES should be used for encryption and the firewall should be configured to allow UDP port 500 for internet key exchange (IKE) and IP protocol 50 for ESP.

    Potential issues around wireless network security are well publicised. The two most common security configurations each have their own limitations:

    • Wired equivalency privacy (WEP), relies on static WEP keys which are not dynamically changed and are therefore vulnerable to attack. There is no standard method for provisioning static WEP keys to clients and the principle of static keys does not scale well, with a compromised key exposing everyone.
    • MAC address filtering, is also limited by the potential for an attacker to spoof an allowed MAC address.

    Possible solutions include password-based layer 2 authentication (IEEE 802.1x with PEAP/MS CHAP v2) and certificate-based layer 2 authentication (IEEE 802.1x EAP-TLS). Other options include:

    • VPN connectivity using L2TP/IPSec (preferred) or PPTP. This does not allow for roaming but is useful when accessing public wireless hot spots; however there is no computer authentication, or processing of computer group policy settings.
    • IPSec, but this has some interoperability issues.
    Security type Security level Ease of deployment Ease of integration
    Static WEP Low High High
    IEEE 802.1x (PEAP) High Medium High
    IEEE 802.1x (TLS) High Low High
    VPN (L2TP/IPSec) High Medium Low
    IPSec High Low Low


    In summary, firewalls are placed in different locations for different reasons. These must be understood and filtered accordingly. Core functionality can be extended with protocol filters to cover a specific scenario but no one device is a silver bullet. Solutions are more important than devices and firewall configuration is more than a networking decision – it also requires application awareness.


    Microsoft ISA Server
    ISA Server Community
    Zebedee (a simple, secure TCP and UDP tunnel program)

    10,000 feet view of Microsoft Exchange Server 2003

    For anyone who is new to Exchange Server 2003, here’s a brief overview that may be of use.

    Microsoft Exchange Server 4.0 was launched in 1996, as a replacement for Microsoft Mail 3.x. It was Microsoft’s first groupware product, competing directly with Novell GroupWise and Lotus Notes. Later versions (v5.0, v5.5) added functionality and improved the scalability of the solution, with Exchange Server 5.5 being the version which really took a hold on the market. Exchange 2000 (v6.0) was a major rewrite, leaving behind its own directory service and using Active Directory instead (which is based on the Exchange Directory technology), and featuring a new system of storage groups supporting multiple mailbox and private stores (for improved database backup and restoration times). Exchange 2000 also switched its internal message transport protocol from X.400 to SMTP, making use of (and extending) the SMTP features in Microsoft Internet Information Services (IIS). Microsoft Exchange Server 2003 (v6.5) builds on the scalability, reliability, performance and manageability of Exchange Server 2000 and is the current version, albeit without conferencing, instant messaging and chat features, which have been replaced by the Microsoft Office Live Communications Server product.

    Exchange Overview

    The Exchange environment is known as an organization. Within an organization, Exchange Server 4.0-5.5 divides the infrastructure into one or more sites (similar to the Active Directory site concept), linked by connectors of varying types (e.g. RPC, X.400). Exchange Server 2000 and 2003 use routing groups instead of sites, and also introduce the concept of administrative groups for organisations where administration is undertaken by different groups of staff (e.g. in a global organisation with separate teams for Americas, EMEA and Asia-Pacific).

    Exchange servers may be configured for a variety of specialist purposes:

    • A bridgehead, is a server dedicated to routing e-mail for a routing group.
    • Front end (protocol) servers act as concentrators for client connections, where protocol conversion would be an overhead (e.g. HTTP connections using Outlook Web Access).
    • Back end (storage) servers could be mailbox servers, public folders servers, or a combination of the two.
    • There may also be other servers dedicated to providing services such as fax connections, mail archival and retrieval (near-line storage), or instant messaging.

    Because Exchange Server 2000 and 2003 use Active Directory, Exchange servers require a global catalog server to be placed nearby. Other products, such as Microsoft ISA Server 2004 may also be used to increase security, for example filtering inbound e-mail, or publishing an Outlook Web Access (OWA) server.


    Microsoft Exchange Server
    Microsoft Exchange Server resource site

    No feature pack for ISA Server 2004

    Last week I was at a Microsoft TechNet evening where the speaker indicated that there may not be a feature pack for ISA Server 2004 and instead any new features will be held over for ISA Server 2006 (codenamed Wolverine). This includes network access protection (NAP) and all of the other filters, tools, etc. that did not make it into ISA Server 2004.

    The issue of NAP is an interesting one as the Microsoft website indicates that this will be incorporated into Windows Server 2003 release 2.

    10,000 feet view of Microsoft ISA Server 2000

    Microsoft Internet Security and Acceleration (ISA) Server 2000 is Microsoft’s firewall and proxy server product, replacing Microsoft Proxy Server.

    ISA Server 2000 operates in one of three modes:

    • Firewall – security server.
    • Caching (i.e. proxy) – acceleration server.
    • Integrated – firewall and caching.

    As a firewall, ISA Server’s filtering capabilities include:

    • Packet filtering (layer 3) capabilities – filtering based on the source and destination IP addresses along with their respective port numbers.
    • Circuit (TCP) and stateful inspection (UDP) filtering – filtering bases on a sequence of packets (e.g. to guard against denial of service attacks).
    • Application filtering (layer 7) – actually inspecting the data segment of the packet.

    (layer numbers refer to the open system interconnection 7 layer network model).

    The product can be used as an internal or external firewall and ISA Server 2000 achieved certification for Common Criteria Evaluation Assurance Level 2 (EAL 2) in September 2003.

    ISA Server’s basic caching (proxy) process is as follows:

    ISA Server 2000 - caching

    1. Client requests access to an external website. Because the DNS suffix address is not local, it knows to contact the proxy server.
    2. ISA Server receives the request and checks its cache, which by default is split between 50% of the ISA server’s available memory (fast) and disk (slower).
    3. If there is no match in the cache, then space is reserved in cache and the request is forwarded to the Internet, using network address translation (NAT).
    4. The external web server replies with the requested page.
    5. The reply is cached with a time to live (TTL) (default 24 hours) and is forwarded to the requesting client.

    Other caching features include:

    • Active caching – as the TTL for a cached resource expires, ISA server proactively fetches the latest copy of the resource from the Internet, storing it in the cache and accelerating future requests by keeping the latest versions of the most popular sites in the cache.
    • Scheduled download – caching defined URLs on a schedule, e.g. caching a partner’s website each day for local access. This is most useful in a business to business (B2B) extranet scenario, where the content expiry can be predicted.

    ISA server also supports VPN access (available in Windows 2000, XP and Windows Server 2003, but enhanced with ISA Server) and reverse publishing (allowing access to internal resources from the Internet). Reverse publishing using ISA Server is more secure than simply hosting a web server in a demilitarised zone (DMZ) as there is a firewall with NAT between the Internet and the DMZ, as well as between the DMZ and any internal resources.

    Standard 3-pronged firewall with web server in DMZ:

    3 pronged firewall

    Reverse publishing using ISA Server:

    ISA Server 2000 - reverse publishing

    The configuration of ISA Server 2000 is controlled using policy elements, which are bundled together to create rules.

    ISA Server 2000 Enterprise Edition allows the formulation of arrays of ISA servers, providing greater scalability.


    Microsoft ISA Server
    Microsoft ISA Server firewall and cache resource site