ASP.NET2theMax
Traditional firewalls are are having a hard time facing new types of attacks. Attacks now tend to look like legitimate traffic to firewalls that only inspect the outer envelope of the packet where the headers are stored. Firewalls are the first line of defense against attacks. Features like packet filtering, stateful inspection, and intrusion detection are standard on firewalls, but most of today's attacks occur at the application layer. Examples are viruses like Code Red, Sasser, Blaster. To be effective, firewalls needs to examine traffic at the application layer. New generation software like Microsoft Internet Security and Acceleration Server 2004 (ISA) begins looking beyond the header and into the actual payload to determine the intent of the communications. ISA Server 2004 in particular does content inspection for many popular Internet protocols including HTTP, SMTP, and RPC.
Web services are Web applications that users reach over a variety of protocols, the most popular of which is certainly HTTP. Web services can be secured at the application layer with sophisticated authentication/authorization mechanisms. However, most of the threats can be blocked at the gate by using a smart, and Web services-aware type of firewall. ISA Server 2004 implements an extensible plug-in model for third-party vendors to build application filters that monitor packets on a certain protocol.
An example of what the open architecture of ISA Server 2004 means is the Forum XWall firewall for Web services. Forum XWall installs in the ISA user interface and lets you perform three key tasks. First, define WSDL policies; second, virtualize the WSDL of a Web service; third, ensure that the WSDL loaded into the firewall be conform to the WS-I Basic Profile standard. The WS-I Basic Profile is the standard that promotes interoperability across multiple implementations of Web services. Since Web Services standards are sometimes loosely defined and differently implemented by vendors, WS-I Basic Profile tightens the interpretation of those standards through a predefined set of rules which every vendor has to fulfill.
A WSDL policy consists of a bunch of Intrusion Detection and Prevention (IDP) rules. Each rule defines a constraint on the intercepted SOAP packet. For example, the user interface of Forum XWall allows to set a maximum length for the packet. Aimed at blocking malicious packets, the WSDL policy editor gets you to set an upper bound to the number of nested elements, attributes, node count in the SOAP block. This static validation form a barrier that will keep badly formed and suspicious packets off the door.
Each Web service behind the firewall can be given an access control list to associate Web methods and users or groups of users. In this way, you can map the WSDL public operations to users based on rules. When a user that lacks the authorization to execute a given method issues a call, XWall block it and the request never reaches the Web service. Of course, for this mechanism to work the Web service must have chosen a Windows or Active Directory authentication.
Installed on a machine equipped with ISA Server 2004, XWall makes a Web service inherently more secure because of the increased ability to intercept bad SOAP calls. XWall doesn't replace a full understanding of Web service security, the WS-* standards, best practices, and available toolkits like WSE 2.0. Once you have secured the application layer of the Web service using code, you can build an higher defense perimeter around by filtering and blocking suspicious calls at the gate.
