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.
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.
1 oriented or procedure-oriented information [2].
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].
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 web-
services access control, either for a whole service or
for specific operations. Moreover, some web services
firewalls accept WSDL2 files or Schema for SOAP-
envelope 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
2
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 document-
3
XACML defines policies for information-access over the Internet
[2].
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
Parser
Packet Queue
Packet Payload
SOAP packets
Soap Filter
Port 80 traffic Set Verdict
Packet from Client
IP Tables
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
Validation Unit 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.
Request verdict
Once all the packets of the request are completely
received and queued by the firewall, the packets are
Valid SOAP
extracted from the queue, parsed by the parser
Packet Forger subsystem, which is a simple XML parser, and sent to
SOAP
packets
the validation subsystem.
The validation subsystem represents the core of this
Non-SOAP Packets
to Server
Server 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
administrator to define more rules related to his web
services profiles.
4. Achievements and Current Status
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
service and a totally different list for another. Further
extensions to this module can incorporate XML
authorization methods, such as the XACML.
4.2 Caching
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 auto-
creation 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
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.
4.6 Testing
SOAP Valid
Request Request
SOAP SOAP
Response Response
Nedgty
Client
Web Server
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. 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.
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
time, in order to re-load the data from the repository. community with a free and effective product that can
Another capability is to trigger cache expiry after data be further developed and easily customized to be
has been modified in the repository. integrated with the existing layer two firewalls.

5.4 Distributed Architecture 7. References

Nedgty is a centralized web services firewall that [1] H.F. Nielsen, J.J. Moreau, M. Gudgin, M. Hadley and N.
secures the gateway to a pool of servers hosting a Mendelsohn, eds. “SOAP Version 1.2 Part 1: Messaging
number of web services. A different approach could be Framework,” W3C Recommendation, 24 Jun. 2004;
followed by turning Nedgty into a distributed web http://www.w3.org/TR/soap12-part1/
services firewall that protects each server on its own
[2] Menno, Holtkamp. “The Role of XML Firewalls for Web
rather than just protecting a gateway. The distributed Services,” First Twente Student Conference on IT 2004.
architecture should have a centralized policy maker, http://wwwhome.cs.utwente.nl/~referaat/documents/
where the user can set all of his security policies and 2004_01_B-Enterprise_Application_Integration/
policy enforcement nodes that secure each server on its 2004_01_B_M.Holtkamp-
own, rather than the centralized approach where both The_role_of_XML_Firewalls_for_Web_services.pdf
the policy maker and the enforcement modules reside
at the gateway to a secure zone. This distributed [3] E. Christensen, F. Curbera, G. Meredith and S.
approach has the advantage of reducing the traffic Weerawarana. “Web Services Description Language
bottlenecks that might reside at the gateway, in (WSDL) 1.1,” W3C Recommendation, 15 Mar. 2001;
http://www.w3.org/TR/wsdl
addition to providing additional security for each
server against attacks that could have occurred from [4] L. M. Vittie and J. Forristal. “Enemy at the Gateway,”
within the secured zone. Nedgty’s object oriented Network computing, 16 Oct. 2003;
design helps to easily change it from a centralized http://www.nwc.com/showitem.
firewall to a distributed one, since only a new jhtml?articleID=15201897&pgno=1
interfacing subsystem needs to be developed, without
the need to redevelop the policy enforcement modules. [5] “Forum XWall,” ForumSystems;
http://forumsys.com/products_xwall.htm
6. Conclusion [6] “XS40 XML Security Gateway,” DataPower;
http://www.datapower.com/products/xs40.html
Web Services are now being increasingly
employed, as their standards enable the integration of [7] “OASIS eXtensible Access Control Markup Language
loosely-coupled applications over networks. However (XACML) TC,” OASIS; http://www.oasis-
due to the newly introduced attacks that accompanied open.org/committees/tc_home.php?wg_abbrev=xacml
the use of web services, the need for web services
firewalls has arisen. Nedgty comes in as free open [8] “WebServices – Axis,” Apache;
http://ws.apache.org/axis/
source solution for the protection of web services,
against several of the currently persisting attacks. The [9] M. S. Mimoso. “XML complexity introduces security
main target of Nedgty was to experiment a solution to risks,” SearchSecurity, 23 Nov. 2004;
the new threats introduced by the introduction of web http://searchsecurity.techtarget.com/originalContent/
services. It is also aimed at providing the open source 0,289142,sid14_gci1028001,00.htm