Nedgty: Web Services Firewall
Ramy Bebawy, Hesham Sabry, Sherif El-Kassas, Youssef Hanna, Youssef Youssef Department of Computer Science American University in Cairo, Egypt {ramy1982,hesh84,sherif,youssefh,youssefy}@aucegypt.edu

Abstract
This paper describes the research conducted to develop Nedgty, the open source Web Services Firewall. Nedgty secures web services by applying business specific rules in a centralized manner. It has the ability to secure Web Services against Denial of Service, Buffer Overflow, and XML Denial of Service attacks; as well as having an authorization mechanism.

2. Overview of Related Work
The concept of web services firewalls has been only recently developed, which accounts for the limited number of products available in the market [4]. Most of the available products are defined by a set of common features. One of those features is XML content inspection also known as deep packet inspection (DPI), which allows for the inspection of the XML content embedded in the SOAP requests coming to the web services. Another feature is webservices access control, either for a whole service or for specific operations. Moreover, some web services firewalls accept WSDL2 files or Schema for SOAPenvelope validation purposes. Two of the most successful products in the market are the ForumSystems XWALL [5] and the DataPower XS40 XML security gateway [6]. They both help the user to define his/her own policies either through a GUI as in XWALL, the definition of eXtensible Stylesheet Language Transformation (XSLT) files that do content inspection against the SOAP requests as in the XS40 or the usage of predefined WSDL files to perform the necessary validations. They also help providing data level authorization through the usage of HTTP username/password and SSL X.509 Certificates as in XWALL and the usage of the OASIS XML Access Control Markup Language (XACML)3 [7] as in the XS40. Both firewalls allow for encrypting data up to the level of a single data element in the SOAP response document. In addition to the previously mentioned functionalities both products provide XML intrusion prevention by protecting against vulnerabilities associated with XML parsers, and protecting against buffer overflows, denial of service attacks and much more. The platforms through which these firewalls
Stands for Web Services Description Language. It is an XML based technology for describing network services as a set of endpoints operating on messages containing either documentoriented or procedure-oriented information [2]. 3 XACML defines policies for information-access over the Internet [2].
2

1. Introduction
As with many new emerging technologies, the introduction of web services has introduced new security threats. Traditional layer 2-4 firewalls and even application level firewalls are no longer viewed as an effective way for providing a solution to those threats. The use of web services over HTTP makes it hard to use traditional layer 2-4 firewalls to block malicious web services traffic. Moreover, the SOAP1 envelopes carrying the eXtensible Markup Language (XML) content from and to web servers renders the current application level firewalls useless. This is due to their inability to inspect this XML content for any malicious data [3]. The web services firewall is introduced as a security application capable of inspecting and understanding the XML content provided inside the SOAP envelopes. This is done to make sure that they do not contain any harmful data. In order to experiment a solution to these problems we developed Nedgty, which is an open source web services firewall that secures web services by intercepting packets going to the server, determining the web services specific packets, and checking them for any malicious content. In addition, Nedgty filters out unauthorized requests that originate from IP addresses that are not allowed to consume the provided web services.

Stands for Simple Object Access Protocol. It is the communication protocol used for communication between web-service applications. SOAP is designed to send messages via the Internet [1].

1

Proceedings of the IEEE International Conference on Web Services (ICWS’05)
0-7695-2409-5/05 $20.00 IEEE

exist tend to vary from separate hardware appliances, to installable software, and even a plug-in to Microsoft Internet Security and Acceleration (ISA) Server as in the XWALL. Although an ultimate security product does not exist, both of the available products provide the necessary protection that should be present for web services and represent a promising example of the newly introduced concept of web services firewalls.

3. System Architecture
Nedgty has been developed with some features in mind, such as its ability to be integrated with existing firewalls and its ability to be easily customized and used. Figure 1 briefly describes the main components of our system.

Write Rules

Repository

Rules

Interface
Logs Existing Rules Parsed XML Parsed XML

Validation Unit

Parser
Packet Payload

Packet Queue
SOAP packets

Request verdict Valid SOAP

Soap Filter
Port 80 traffic Set Verdict

Packet Forger
SOAP packets

Packet from Client

IP Tables

Non-SOAP Packets to Server

Server

Figure 1. Nedgty System Architecture The target operating system for Nedgty is the Linux OS. Nedgty functions at the application level as a stand-alone application and its design is a hybrid of a fully fledged proxy. As evident in the above diagram, Nedgty communicates with the IPTables, a Linux layer 2 firewall. Nedgty makes use of the QUEUE target, an IPTables module that forwards any desired packets to the user-space, to intercept the web services specific packets validate them and forward or drop them accordingly. An interface is responsible for setting the security policies and committing them to a persistent storage, referred to as the Repository. For requests to pass the firewall, the administrator needs to register the web services that should be published and defines the control policies for each web service. Using the interface, the administrator is allowed to add, edit and delete web services profiles. In each profile, the administrator specifies the web service operations, where the web service is located, and the accepted SOAP message formats. He has the option of doing

that by uploading the WSDL file of his web service or by manually setting the fields that define the structure of his SOAP file, such as the method names exposed by his web service and their SOAP actions. Other control data related to the types of threats that Nedgty protects against are requested from the administrator, such as the rate of SOAP requests allowed for each web service to prevent DoS attacks. The administrator gets to choose the rules to apply on any of his web services, which gives him more control on the type of protection he wants to enforce. Once a web service profile is completed, it is committed to the repository in the form of XML. The stored profiles allow the validation subsystem, to retrieve the validation rules for the incoming web services requests. The SOAP filter is the subsystem used to separate the SOAP packets from the incoming HTTP traffic. Upon encountering non-SOAP packets, a verdict of “accept” is returned to IPTables to allow these packets to continue normal path to the server. On the other hand, the SOAP packets are captured for further analysis and a verdict is returned to the IPTables to drop them silently. The silently dropped packets are stored in a list of queues, each containing one request. Once all the packets of the request are completely received and queued by the firewall, the packets are extracted from the queue, parsed by the parser subsystem, which is a simple XML parser, and sent to the validation subsystem. The validation subsystem represents the core of this project. It does its XML related checks on the parsed tree of the incoming SOAP request. In addition, it has the ability to do web services checks that do not depend on the incoming SOAP content. For example, a module for IP authorization has been included in the validation subsystem to protect web services against invalid IP’s. In both of the above mentioned checks the validations are done against the rules defined in the web services profiles for each kind of attack. To make Nedgty transparent to both the client and the server, the silently dropped packets belonging to the incoming SOAP requests are forged by Nedgty’s packet forger and re-sent to the server, who - due to packet forging - assumes that his client was the original sender of it. Nedgty’s system architecture and object oriented design allows for the extensibility of its security features. To add any new security check, its related module is just added to the validation subsystem. This allows the newly added module to gain access to the parsed SOAP request, the HTTP header that accompanied it and the rules stored in the web services profiles. Further extensions can be achieved by adding new modules in the interfacing subsystem to allow the

Proceedings of the IEEE International Conference on Web Services (ICWS’05)
0-7695-2409-5/05 $20.00 IEEE

administrator to define more rules related to his web services profiles.

service and a totally different list for another. Further extensions to this module can incorporate XML authorization methods, such as the XACML.

4. Achievements and Current Status
4.2 Caching 4.1 Validation Rules
Nedgty’s prototype supports four types of checking performed by separate modules in the validation subsystem. The first two modules check against SOAP related threats, such as buffer overflow and XDoS. The buffer overflow module does validation checks against the SOAP version of the buffer overflow attack. Currently it checks the SOAP requests for the type and length of the sent parameters, in order to see if they conform to the predefined types that are defined in the web service profile and the maximum allowed length as specified by the administrator. An example would be sending strings longer than what the buffer can handle or inconsistent data types, such as a character to a method that was defined in its WSDL file to accept integers. Further extensions to this module can include preventing unauthorized characters that might lead to application specific threats, such as SQL injection. The XDoS module checks the parsed XML content of the SOAP file to prevent anything that might crash XML parser at the server side. This is done by validating the syntax of the XML content of the SOAP requests and by checking to see if the SOAP message conforms to its stored format in the stored web service profile. As an example, a SOAP request to an un-existing method or having incorrect XML syntax as a missing closing tag is dropped. The remaining two modules provided by the validation subsystem check for non-SOAP related threats that affect web services. The first protects against DoS attack targeting web services. It keeps count of the rate of SOAP requests coming to each web service and validates it against the predefined rates by the administrator. Any rate of request exceeding the predefined one results in dropping the incoming requests till the rate is returned to normal. The reason why such an attack was not classified as a SOAP related threat is that SOAP requests can be identified from their related HTTP headers, however it is still a web service specific threat since it is caused by the rate of SOAP requests and not the rate of normal web traffic. The second module that does non SOAP related checks is the authorization module. Currently this module does IP authorization, which validates the IP’s requesting the web services against a predefined list of IP’s. This feature is available on separate basis for each web service, which allows for defining a list for a web Nedgty caches the XML file containing the validation rules of the requested web service in the form of a tree. Each time the validation unit receives a new SOAP request, it searches for the profile of the requested web service in the cache. If the profile is not found it is loaded from the XML files in the repository and cached. This is done to reduce the frequency of the I/O operations and the reparsing of the XML files that affect the performance of real time applications like Nedgty.

4.3 Queue SOAP Requests
To accommodate the need for protecting more than one web service, Nedgty has to have the ability to handle multiple incoming requests. Since each request might be divided into multiple packets, Nedgty queues all the packets belonging to the same request together. Taking into consideration that the packets belonging to the same request may not come in correct sequence, they are sorted by the queuing module as soon as they are all received.

4.4 Forge the Packets
In order to keep receiving packets from the QUEUE target in IPTables, a verdict has to be set on each packet. Since at this stage it is too early to set a target for the packet without receiving the complete request, Nedgty stores copies of the incoming packets as mentioned in section 4.3 and signals the IPTables firewall to silently drop them. After complete requests are received and validated, they need to be resent to the server. Nedgty forges those packets with the original sender’s TCP and IP headers and resends them to the server, so that the web service firewall becomes transparent to both the client and the server.

4.5 Logging and Reporting
Nedgty provides its users with logging abilities. On daily basis, the first received request triggers the autocreation of a new log file named according to the date of the day. During the day, all the validation results corresponding to the received requests are saved in the day’s log file. Upon the administrator’s request, the logs are used to create reports listing the requests received on a specific day. These reports show details

Proceedings of the IEEE International Conference on Web Services (ICWS’05)
0-7695-2409-5/05 $20.00 IEEE

such as the source IP, source port, destination IP, destination port, packet payload and the reason for the denial of a request if it exists. All the generated reports are in the form of XML files linked to a style sheet that makes them easily viewed using a web browser.

5. Remaining Areas of Concern and Future Enhancements
5.1 Other Types of Attacks
Currently, Nedgty protects web services against DoS, XDoS, and Buffer Overflow attacks. Additionally, it prohibits the users trying to access the web services through requests coming from IP’s that are not allowed. However, there are still other attacks that Nedgty is not protecting against. Future enhancements include: o Adding an intrusion detection mechanism: Since Nedgty collects a lot of data in its log files tracking its day to day activities, an intrusion detection and prevention mechanism can be a good addition that utilizes the existing logged data to prevent future security breaches. o Protecting against encrypted data: In some cases, data in the SOAP envelope is encrypted. Malicious encrypted content may go through the firewall undetected. A future enhancement in this area can protect the web services against attacks that depend on encrypted SOAP envelope content by providing Nedgty with the ability to decrypt any incoming encrypted data. However some may see this as a negative point since the current system is centralized and enabling it to decrypt messages will break the link between the service requestor and the service provider. o Enforcing standardized protocols: Currently, the project only enforces business specific protocols. A future enhancement may include enforcing standardized protocols such as XML Signature, Security Assertion Markup Language (SAML), XACML, etc.

4.6 Testing
SOAP Request SOAP Response Nedgty Valid Request SOAP Response Web Server

Client

Figure 2. Testing Network Every subcomponent of the Nedgty prototype was tested separately using customized test cases during the development phase to ensure that it functions properly. After the integration of all the subcomponents of our system, the system as a whole was tested on the testing network in Figure 2. The testing network is composed of a client application, a web server and a PC hosting Nedgty, interconnected by a direct connection. The client hosted applications were used to invoke the web service hosted by the web server. Client applications were implemented using ASP.Net and Java. Nedgty was hosted on a Linux OS that had the IPtables stored firewall installed on it, and used static route to redirect the traffic from the client to the server. The web services hosted on the web server were implemented using C# and hosted on an IIS server and java hosted on an Apache Axis server [8]. The testing network traffic was monitored using a special SOAP proxy, to monitor the SOAP traffic coming from the client. XDoS and Buffer Overflow attacks were simulated by intercepting and editing the client’s valid SOAP requests to include invalid content. In our test cases Nedgty was successful in intercepting and dropping the invalid requests. IP authorization was tested by allowing certain IP’s to use the hosted web services and sending requests from clients with a range of authorized and unauthorized IP’s. Nedgty was successful in intercepting the unauthorized IP’s and allowing the authorized ones. DoS was tested by setting a threshold in Nedgty and sending requests at a rate exceeding that threshold. Only requests within the allowed threshold reached the server. In all the above test cases Nedgty logged all the transactions in its logging sub system. The logs were checked for the valid and invalid cases and were consistent with the used test cases.

5.2 Multi-Threading for validation process
The validation process is currently working on only one thread. However, better performance could be achieved if the validation process is done by creating a thread for checking each request, since more requests can be simultaneously handled.

5.3 Smarter Caching
Currently, the caching is loaded on demand. If the user wants to modify any web service profile while the program is running, Nedgty has to be restarted in order to load the cache with the new data. A solution to this problem is to provide smart caching mechanism. The smart cache should expire after a specific period of

Proceedings of the IEEE International Conference on Web Services (ICWS’05)
0-7695-2409-5/05 $20.00 IEEE

time, in order to re-load the data from the repository. Another capability is to trigger cache expiry after data has been modified in the repository.

community with a free and effective product that can be further developed and easily customized to be integrated with the existing layer two firewalls.

5.4 Distributed Architecture
Nedgty is a centralized web services firewall that secures the gateway to a pool of servers hosting a number of web services. A different approach could be followed by turning Nedgty into a distributed web services firewall that protects each server on its own rather than just protecting a gateway. The distributed architecture should have a centralized policy maker, where the user can set all of his security policies and policy enforcement nodes that secure each server on its own, rather than the centralized approach where both the policy maker and the enforcement modules reside at the gateway to a secure zone. This distributed approach has the advantage of reducing the traffic bottlenecks that might reside at the gateway, in addition to providing additional security for each server against attacks that could have occurred from within the secured zone. Nedgty’s object oriented design helps to easily change it from a centralized firewall to a distributed one, since only a new interfacing subsystem needs to be developed, without the need to redevelop the policy enforcement modules.

7. References
[1] H.F. Nielsen, J.J. Moreau, M. Gudgin, M. Hadley and N. Mendelsohn, eds. “SOAP Version 1.2 Part 1: Messaging Framework,” W3C Recommendation, 24 Jun. 2004; http://www.w3.org/TR/soap12-part1/ [2] Menno, Holtkamp. “The Role of XML Firewalls for Web Services,” First Twente Student Conference on IT 2004. http://wwwhome.cs.utwente.nl/~referaat/documents/ 2004_01_B-Enterprise_Application_Integration/ 2004_01_B_M.HoltkampThe_role_of_XML_Firewalls_for_Web_services.pdf [3] E. Christensen, F. Curbera, G. Meredith and S. Weerawarana. “Web Services Description Language (WSDL) 1.1,” W3C Recommendation, 15 Mar. 2001; http://www.w3.org/TR/wsdl [4] L. M. Vittie and J. Forristal. “Enemy at the Gateway,” Network computing, 16 Oct. 2003; http://www.nwc.com/showitem. jhtml?articleID=15201897&pgno=1 [5] “Forum XWall,” http://forumsys.com/products_xwall.htm ForumSystems;

6. Conclusion
Web Services are now being increasingly employed, as their standards enable the integration of loosely-coupled applications over networks. However due to the newly introduced attacks that accompanied the use of web services, the need for web services firewalls has arisen. Nedgty comes in as free open source solution for the protection of web services, against several of the currently persisting attacks. The main target of Nedgty was to experiment a solution to the new threats introduced by the introduction of web services. It is also aimed at providing the open source

[6] “XS40 XML Security Gateway,” DataPower; http://www.datapower.com/products/xs40.html [7] “OASIS eXtensible Access Control Markup Language (XACML) TC,” OASIS; http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=xacml [8] “WebServices http://ws.apache.org/axis/ – Axis,” Apache;

[9] M. S. Mimoso. “XML complexity introduces security risks,” SearchSecurity, 23 Nov. 2004; http://searchsecurity.techtarget.com/originalContent/ 0,289142,sid14_gci1028001,00.htm

Proceedings of the IEEE International Conference on Web Services (ICWS’05)
0-7695-2409-5/05 $20.00 IEEE