Wireless security and secure remote access

Posted on By Mark Wilson
This content is 19 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Last night, I attended Steve Lamb‘s Microsoft TechNet UK briefing on wireless security and secure remote access. I won’t repeat the entire content here, because Steve has an article in the November/December issue of Microsoft TechNet magazine, entitled improve your web security with encryption and firewall technologies, which, when combined with Kathryn Tewson and Steve Riley’s security watch: a guide to wireless security article, just about covers the content of the event. Having said that, there were a few more snippets that came out during the presentation, which I’ve plagiarised (and extended) in the rest of this post…

Wireless Security

Anyone who needs to secure a Wireless network at home should check out Steve Lamb’s blogcast on securing a wireless router and Windows XP and, although I’ve already linked it above, I’ll repeat that Kathryn Tewson and Steve Riley’s security watch: a guide to wireless security article is also worth a read. Further information is also available on the Microsoft website.

Some additional notes that I took during Steve’s presentation were that:

  • Wireless network keys can be stored on a USB token.
  • Wired equivalent privacy (WEP) is often considered insecure but consider the name – the equivalency part indicates that it offers the same level of security as a wired network. Yes, it can be broken into, but so can a wired network with public access to the building). Wi-Fi Protected Access (WPA) (or preferably WPA2) is better and dynamic WEP is a half-way house, but whatever security is employed, the wireless network still needs to be easy to use.
  • There are sites on the ‘net that will show you how to break a wireless (or other) connection (if you think it’s irresponsible of me to link that site, you could also find it using a search engine, so I figure that it’s better that the methods are well known, than only being known by the bad guys).
  • Contrary to popular belief, there is no point in securing the SSID for a network as it is transmitted unencrypted (even on a network secured with WPA or WPA2). Ditto for media access control (MAC) addresses, which are easily spoofed.
  • Even WPA doesn’t do anything to prevent a denial of service (DoS) attack and WPA2 (802.11i) doesn’t stop all DoS attacks.
  • 802.1x is port-based authentication and applies equally to both wired and wireless networks. It does have weaknesses, including that it will only authenticate the initial connection. In a wireless configuration, man-in-the-middle (MitM) attacks can be guarded against by requiring the WAP to identify itself using certificates (using a group policy object).
  • WEP requires Windows XP. WPA requires Windows XP SP1, WPA2 requires Windows XP SP2 and a hotfix (see Microsoft knowledge base article 893357).
  • The Windows 2000 Internet authentication service (IAS) can be used as the RADIUS server component in a secure wireless deployment; however Windows Server 2003 supports auto-enrolment (which when used for computer and user certificates will make life much easier).
  • Windows XP will (by default) allow access to its nearest access point, even if it is not secure.

Very importantly – if (like I did), you think that your wireless network (e.g. at home) doesn’t need to be secured because there’s no data of value to be had and anyway, you have bandwidth to spare which you don’t mind your neighbours using, consider the implications of someone using your wireless network to access the Internet and perform illegal activities, which your ISP can trace back to you via your IP address. Having thought about that, I’ll be buying a new wireless access point very soon.

Secure Remote Access

Microsoft are positioning virtual private networking (VPN) technology as no longer the best solution for providing corporate remote access and I tend to agree. The idea of giving an untrusted computer an IP address from the internal network fills me with fear (unless some quarantining is in place). VPNs “blur” the network edge and anyway, do remote users need full network access? I’ve often accidentally printed a document in the office whilst working at home and then had to ask a colleague to retrieve and dispose of it for me (wasting paper, printer resources and somebody else’s time). Some solutions will use VLAN technology to limit the network access for VPN users – there are other methods too, especially when considering that 90% of VPN users only really want to read their e-mail. For example, Outlook Web Access, whilst having improved it’s interface capabilities dramatically with each new release, is still not really a great solution for access from outside the corporate firewall (it’s good for allowing users to access mail without setting up a MAPI profile, but is heavily reliant on ActiveX controls, which may not be allowed in an Internet cafe, and is also a risk if the remote client has a keylogger installed) – full client Outlook using HTTPS over RPC on a notebook/tablet PC is a far better option – totally transparent from an end user perspective (although still a problem if access is required if an e-mail links back to internal resources to retrieve a document).

Steve Lamb’s TechNet magazine article (and my previous post on securing the network using Microsoft ISA Server 2004) elaborate on the need for application layer firewalling rather than blindly allowing HTTP and HTTPS traffic through the firewalls. Other measures employed include pre-authentication and URL scanning.

SSL VPNs are another method of providing remote access (even though they are not really VPNs, but are actually just remote desktops in a browser). Windows Terminal Services can provide basic SSL VPN functionality, which can also be extended with products from Citrix.

Operating over the remote desktop protocol (RDP), which is based on the International Telecommunications Union (ITU) T.120 protocol family and is therefore independent of network and transport protocols, these solutions use compression and caching to reduce bandwidth requirements and support network load balancing. Windows Server 2003 brings a number of terminal services enhancements (over Windows 2000) including:

  • Connection to the console session (in remote administration mode).
  • Control of RDP options via group policy.
  • WMI provider for scripted terminal services configuration.
  • ADSI provider for access to per-user terminal services profiles.
  • Improvements to the terminal server manager MMC snap-in (reduced automatic server enumeration).
  • Ability to limit users to a single session.
  • Improved security:
    • Remote Desktop Users security group (which can be used in place of the Everyone group to fine tune access control.
    • 128-bit RC4 encryption.

Securing terminal services comes back to the well-known principle of defence in depth:

  • A physically secure terminal services server.
  • A secure operating system configuration.
  • A secure terminal services configuration.
  • Network path security.
  • Using the registry to fine-tune control over terminal server sessions (probably overkill, but using group policy to control access is a similar principle).

Using the remote desktop web connection ActiveX control, terminal services can be provided across the web (and optionally secured using HTTPS). The initial client contact is to http(s)://servername/tsweb/ and the ActiveX control is downloaded over HTTP (TCP port 80) or HTTPS (TCP port 443). Once the browser has the ActiveX control installed, the user can connect to the terminal server over TCP port 3389.

If full VPN access is still required (and hopefully the methods above will avoid the requirement for this), then VPN server placement must be carefully considered. Running an encrypted PPTP or L2TP+IPSec VPN connection through a standard packet filtering firewall effectively bypasses the firewall as the VPN port will be open on internal and external firewalls and the traffic inside the connection will not be inspected.

Most network administrators will be alarmed if you propose the installation of ISA Server as the corporate firewall even though ISA Server 2004 has now achieved common criteria evaluation assurance level 4+. ISA Server 2004 is a perfectly good firewall (assuming that the underlying Windows platform is also well-managed), but it will probably be easier to justify to network administrators by using ISA as an additional server in the DMZ, or as the inner firewall (between the DMZ and the internal network). This way, the encrypted connection can be terminated at the ISA server and the firewall can inspect the inbound traffic.

Finally, if a VPN connection must be used to extend the corporate network to remote clients, then network quarantine controls should also be put in place. Full network access protection (NAP) is expected with the next version of Windows Server (codenamed Longhorn) but even now, Windows Server 2003 SP1 routing and remote access service (RRAS) allows for the provision of network access quarantine control for remote clients. The current Microsoft implementation involves using the connection manager administration kit (CMAK) to construct a custom RRAS client which includes a number of post-connection actions. Until these are passed, then vendor-specific options remain in place which prevent the remote VPN client from accessing the network. Unfortunately it is also possible for a technically able user to spoof the message which allows the vendor-specific attributes to be removed, but in reality this is a small risk. Microsoft’s NAP and Cisco’s network access control (NAC) will make this far more effective, extending the scope of control to include wired and wireless clients (as well as VPN clients).

Introduction to password cracking

Posted on By Mark Wilson
This content is 19 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I just read a very interesting article on password cracking techniques on the IBM website. It doesn’t contain any information that isn’t already well known, but it’s still a useful summary of some of the issues which an administrator should be prepared for and how to prevent them.

A plea for user-friendly firewall messages

Posted on By Mark Wilson
This content is 19 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I consider myself to be reasonably technical, but even I struggle with firewall messages like this one:

Example firewall messageThis is a real screenshot from my company-supplied notebook PC. I don’t know what an integrity personal policy alert is, although I can hazard a guess. I certainly don’t know what triggag.exe is, but I can see it is trying a DNS lookup. Should I allow that? I don’t know, but I need to get on with whatever I did that launched that dialog so I click Yes (and probably tell it to remember the answer too).

According to file.net, triggag.exe is part of CA Unicenter Software Delivery but to an end user, this dialog might as well say “to carry on working you must make this dialog go away. Do you want to make this dialog go away?”

As long as the IT industry produces software which outputs messages as cryptic as this (and as long as administrators keep deploying that software), we will never get users to take security seriously.

Here endeth the lesson.

Get safe online

Posted on By Mark Wilson
This content is 19 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I was at Microsoft’s UK campus last night where, since last week, lots of plastic cubes (just like the logo below) and even stickers on the mirrors in the washrooms have appeared displaying the message “Get Safe Online”.

Get Safe Online

No-one from Microsoft was allowed to say what it’s all about yet, but some quick googling turned up the National High Tech Crime Unit (NHTCU)’s Internet safety campaign – Get Safe Online (Project Endurance), which is a joint government and private sector initiative aimed at helping consumers and small businesses to use the Internet safely (due to be launched at the end of October) with partner organisations including the UK Government, BT, Dell, eBay, HSBC, LloydsTSB, MessageLabs, Microsoft UK, the NHTCU, Securetrading and Yell.

So far GetSafeOnline is just a single page, but I’m sure more will follow.

Other Internet safety sites include the United States GetNetWise initiative.

The Symantec Internet security threat report

Posted on By Mark Wilson
This content is 19 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Earlier today, I downloaded the Eighth Edition of the Symantec Internet Security Threat Report. Published twice a year, this report highlights trends in the Internet security space and the following list highlights some of the key findings (according to Symantec).

Vulnerability trend highlights:

  • Symantec documented 1,862 new vulnerabilities, the highest number since Symantec started tracking vulnerabilities in six-month increments.
  • The time between the disclosure of a vulnerability and the release of an associated exploit was 6.0 days.
  • The average patch-release time for the past 6 months was 54 days. This means that, on average, 48 days elapsed between the release of an exploit and the release of an associated patch.
  • 97% of vulnerabilities were either moderately or highly severe.
  • 73% of reported vulnerabilities this period were classified as easily exploitable.
  • 59% of vulnerabilities were associated with web application technologies.
  • 25 vulnerabilities were disclosed for Mozilla browsers and 13 for Microsoft Internet Explorer.

Attack trend highlights:

  • For the fourth consecutive reporting period, the Microsoft SQL Server Resolution Service Stack Overflow Attack was the most common attack, accounting for 33% of all attacks.
  • Symantec sensors detected an average of 57 attacks per day.
  • TCP port 445, commonly implemented for Microsoft file and printer sharing, was the most frequently targeted port.
  • Symantec identified an average of 10,352 bots per day, up from 4,348 in December 2004.
  • On average, the number of denial of service (DoS) attacks grew from 119 to 927 per day, an increase of 679% over the previous reporting period.
  • 33% of Internet attacks originated in the United States, up from 30% last period.
  • Between January 1 and June 30, 2005, education was the most frequently targeted industry followed by small business.

Malicious code trend highlights:

  • Symantec documented more than 10, 866 new Win32 virus and worm variants, a 48% increase over the second half of 2004 and a 142% increase of the first half of 2004.
  • For the second straight period, Netsky.P was the most reported malicious code sample. Gaobot and Spybot were the second and third most reported, respectively.
  • Malicious code that exposes confidential information represented 74% of the top 50 malicious code samples received by Symantec.
  • Bot-related malicious code reported to Symantec made up 14% of the top 50 reports.
  • 6,361 new variants of Spybot were reported to Symantec, a 48% increase over the 4,288 new variants documented in the second half of 2004.

Additional security risks:

  • Adware made up 8% of the top 50 reported programs, up from 5% in the previous reporting period.
  • Eight of the top ten adware programs were installed through web browsers.
  • Six of the top ten spyware programs were bundled with other programs and six were installed through web browsers.
  • Of the top ten adware programs reported in the first six months of 2005, five hijacked browsers.
  • Messages that constitute phishing attempts increased from an average of 2.99 million per day to approximately 5.70 million messages.
  • Spam made up 61% of all email traffic.
  • 51% of all spam received worldwide originated in the United States.

Some interesting (and some frankly frightening) statistics there. Definitely worth a read for any network administrator or IT manager.

The Spread Firefox community site got hacked – but how many others don’t we know about?

Posted on By Mark Wilson
This content is 19 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

The Spread Firefox community marketing site has been compromised twice in the last few months. Lots of the comments on the web criticise the site administrators for a) letting this happen, and b) their choice of technology to run the website but I think it’s interesting (and commendable, if a touch worrying) that they came clean and told registered users that their details may have been compromised.

I wonder how many sites have been compromised and users haven’t been notified that their details are now in someone else’s possession…

An introduction to IPSec

Posted on By Mark Wilson
This content is 19 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I’ve been meaning to write something about Internet protocol security (IPSec) ever since I heard Steve Lamb talk about it a few months back but Owen Cutajar blogged about Steve Friedl’s Illustrated Guide to IPSec a few days back which gives a much better description than I ever will! Steve’s site has a whole load of useful technical tips, but as his URL might give away, he comes at things from a UNIX perspective.

For Windows users who are interested in implementing IPSec, I recommend that you read both Steve Lamb’s blog and Steve Friedl’s Illustrated Guide to IPSec, but what follows is a brief description of some high-level concepts which might help to put it all into context.

Although it sounds complex, symmetric key cryptography is a very basic method of encrypting messages (e.g. DES or AES/Rijndael) using a shared secret. The plain text input is encrypted to produce cipher text which is transmitted to the intended recipient, who can then decrypt it to produce plain text output. An example of such a mechanism is the Caesar shift, whereby characters are shifted by a known number of places (the shared secret), so that for example if the shared secret is 3, A becomes D, B becomes E, and so on. Symmetric key cryptography is simple, and fast, but relies on some form of mechanism for exchanging keys (shared secrets).

Symmetric key cryptography

Public key cryptography is an asymmetric encryption mechanism, whereby knowledge of the encryption key doesn’t provide the methods to decrypt the message. The recipient of the message generates a pair of keys (using a certificate authority) and publishes the public key in a directory so that anyone can send them encrypted messages that only they can read. This pair of keys is actually a single key split mathematically using a one-way algorithm (i.e. one which current mathematics does not allow to be reversed). When sending a message, it is encrypted with the recipient’s public key and they can decrypt it (using their private key). Unfortunately even this method has its weaknesses as it is slow, subject to what is known as a “known ciphertext” attack and requires the public key to be trusted (i.e. to be from a known certificate authority).

Asymmetric key cryptography

The real-world answer is often a hybrid encryption process whereby a symmetric session key is encrypted using the recipient’s public key and then, once this key has been decrypted by the recipient (using their private key), they can read messages encrypted using the session key. The session key is transmitted with the encrypted message as a digital envelope. Once the message exchange is complete (whether that is literally the transfer of a message, or a communication session) the session key is disregarded (i.e. its life is finite – dictated by the length of the session).

IPSec is used to authenticate and/or encrypt TCP/IP communications, securing either specific ports or all IP traffic and is obligatory for IPv6.

In an Active Directory environment, IPSec is generally configured via group policy and both the client and the server must be configured. No reply is issued to rejected packets – they are simply dropped. Installing a certificate authority (CA) is a simple process (although because a lot of the configuration is wizard-based, it can be difficult to appreciate exactly what has been done). Windows Server 2003 Certificate Services allows a hierarchy of CAs to be implemented (generally with the root CA kept offline once the hierarchy is established) as well as adhering to public key standards from RSA, Entrust and Verisign (licensed by Microsoft to avoid any per-certificate cost issues). Once a certificate has been issued the client no longer needs to communicate with the CA. Of course, internal CAs are only suitable for internal use of IPSec (a trusted CA needs to be used for securing traffic across the Internet).

One of the advantages of IPSec is that, because it works at the network layer, it can be used to provide secure data transfer without affecting applications; however the downside is that architects (or administrators) should carefully consider the impact that encrypting all traffic would cause as some security software (e.g. intrusion detection systems) will no longer function.

Kerberos authentication explained

Posted on By Mark Wilson
This content is 20 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Authentication and authorisation are often thought of as a single process but the two are actually distinct operations that may even use separate storage locations for the authentication and authorisation data.

Authentication is about verifying identity, based on one or more factors, for example something that someone knows (e.g. a password), something that someone holds (e.g. a smart card), something that someone is (e.g. biometric information). Obviously the use of multiple-factor identification increases security.

Authorisation is about controlling access to a resource based on access control lists and other policies; however secure authorisation is dependant on authentication in order to ensure that the security principle requesting access is who they say they are.

Kerberos is the industry standard for authentication (not authorisation), featuring mutual authentication (cf. NTLM, which uses one-way authentication), faster connection times (session tickets are effectively pre-authentication) and delegation (e.g. one server accessing resources on another server on behalf of the original request).

For some reason, Kerberos has always seemed complicated to me, but over the last couple of months I’ve attended two events where the speakers (John Howard from Microsoft, and John Craddock from Kimberry Associates) gave excellent explanations of the Kerberos authentication process, which I have attempted to repeat here for the benefit of others.

Even though it is not a Microsoft standard, Kerberos is the default authentication protocol in Windows 2000, XP and Server 2003, although these all support NTLM for legacy clients. RFC 1510, which defines the Kerberos network authentication service (version 5) actually specifies six messages (five mandatory and one optional), grouped into three pairs of sub-protocols:

  • The authentication service (AS) exchange.
    • KRB_AS_REQ.
    • KRB_AS_REP.
  • The ticket granting service (TGS) exchange.
    • KRB_TGS_REQ.
    • KRB_TGS_REP.
  • The client/server (AP) exchange.
    • KRB_AP_REQ.
    • (KRB_AP_REP).

Central to the Kerberos process is the key distribution center (KDC), which in a Windows implementation is installed on all domain controllers. All parties within the Kerberos transaction are said to be part of the same realm, which really means that they have a common shared secret in order to communicate with trust. All messages are encrypted using keys (symmetric – not PKI). A user key is generated from the logon password, a host key is generated when the computer joins the realm and the KDC is effectively a database of security principles.

The AS exchange takes place at logon and is concerned with giving clients the right to request tickets to access resources (avoiding the need to hold logon factors). In this process, the client sends an KRB_AS_REQ request to the KDC and, if approved, the KDC will generate a ticket granting ticket (TGT) which is returned to the client as part of the KRB_AS_REP reply. The TGT allows the client to request service tickets and is analogous to a passport – i.e. it is valid for a certain period after which it expires; however once the TGT has been issued, there is no further use of passwords or other logon factors.

When the client requires access to a resource, the TGS exchange will commence, whereby the client sends a KRB_TGS_REQ service ticket (ST) request to the KDC with the name of the service to which access is required. The KDC will validate the authentication token within the TGT and if permitted, will return a service ticket which is valid for the requested service as part of the KRB_TGS_REP reply; however at this stage the client is still not authenticated. The service ticket is only valid between the user and the service but provides mutual authentication and speeds up connection times by eliminating the need for the service to perform authentication.

Only after the client has sent a KRB_AP_REQ request to the service server and there is mutual authentication, will the client be authenticated and allowed access to the requested resource. The service server may, or may not, send a KRB_AP_REP reply.

At all stages, only the KDC can read the TGT and only the service can read the ST.

Kerberos

Looking in further detail at the AS exchange, the KRB_AS_REQ includes:

  • Client principal name.
  • Timestamp.
  • Kerberos target principle name (realm).
  • Requested lifetime.

The KDC checks for the existence of the user and constructs an encrypted reply, based on the user’s password-based key so that only the real user will be able to decrypt it. This KRB_AS_REP is in two portions:

  • The first part is encrypted using the user’s key, containing:
    • User-TGS key (generated by the KDC).
    • Kerberos target principle name (realm).
    • Ticket lifetime.
  • The second part is the TGT, which is encrypted using a TGS key generated by the KDC so that only the server can open it (even though it is stored by the client for use during further transactions), containing:
    • User-TGS key (which is not retained by the KDC, but its presence within the TGT means it is available when required).
    • Client principal name.
    • Ticket lifetime.
    • KDC timestamp.
    • Client IP address (taken from the initial KRB_AS_REQ).

Because the KRB_AS_REQ is sent in clear text, pre-authentication may be required to stop spoofing of KRB_AS_REQs – this can be controlled on a per-user basis but is automatically enabled on Windows 2000/2003 KDCs. Pre-authentication encrypts the KRB_AS_REQ with the user’s password-based key and avoids offline dictionary and brute force attacks because the timestamp within the KRB_AS_REQ must match the current time (within an allowed skew, which is 5 minutes by default).

Moving on to the TGS exchange, the service ticket request (KRB_TGS_REQ) contains:

  • Service principal name.
  • Requested lifetime.
  • TGT (still encrypted with the TGS key).
  • Authenticator (encrypted with the user-TGS key and containing a client timestamp)

The authenticator guarantees that the request originated from the client.

The KRB_TGS_REP service ticket reply is again in two parts:

  • Part one is encrypted with the user-TGS key (taken from the TGT by the KDC) and contains:
    • Service principal name.
    • Ticket lifetime.
    • User service key (encrypted with a user-TGS session key, generated by the KDC).
  • Part two is the service ticket, encrypted using the service-TGS key and contains:
    • User service key (encrypted with a user-TGS session key, generated by the KDC)..
    • Client principal name.
    • Ticket lifetime.
    • KDC timestamp.
    • Client IP address.

Finally, when the client requires access to the service, the AP exchange KRB_AP_REQ contains the service ticket (still encrypted using the service-TGS key) and an authenticator (encrypted with the user-service key). Kerberos does not define an encryption protocol for the service request.

A client can forward its credentials to a service, forwarding a copy of its TGT so that the service can transparently authenticate on the user’s behalf.

So that’s how Kerberos works. The key points to remember are that:

  • AS exchange occurs at logon, providing the client with a TGT.
  • The TGT allows the client to enter the TGS exchange (which authenticates the client), returning an ST.
  • The ST identifies the authenticated client to a service following which the service will provide access (but only if the client passes the service’s own authorisation criteria).
  • Because messages are encrypted, only the KDC can read the TGT and only the service can read the ST.

No NAP until Longhorn

Posted on By Mark Wilson
This content is 20 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Last year I commented that network access protection (NAP) had slipped from a planned feature pack for ISA Server 2004 to Windows Server 2003 Release 2 (R2). Well, it seems that has changed. Confirming what I wrote last March, when I blogged about the need for network segmentation and remediation, Steve Lamb commented at last week’s Microsoft Technical Roadshow that NAP will be a feature of the next version of Windows Server (codenamed Longhorn) and not in the R2 release scheduled for later this year.

Apparently the reasons for this are that NAP will require kernel mode changes (and there will be no kernel mode changes in R2) and the extra time will allow Microsoft and Cisco to ensure that NAP (Microsoft) and NAC (Cisco) play nicely together.

Until then we will have to make do with the network access quarantine controls (originally part of the Windows Server 2003 resource kit and productionised as part of the release of Windows Server 2003 service pack 1). The main differences are that network access quarantine control allows quarantining of inbound connections via the Windows routing and remote access service, but NAP will will support quarantine for wired and wireless LAN connections too.

Anyone worried about running Microsoft ISA Server as a firewall?

Posted on By Mark Wilson
This content is 20 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

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.