Vous êtes sur la page 1sur 5

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 2. Overview of Related Work


This paper describes the research conducted to The concept of web services firewalls has been only
develop Nedgty, the open source Web Services recently developed, which accounts for the limited
Firewall. Nedgty secures web services by applying number of products available in the market [4]. Most
business specific rules in a centralized manner. It has of the available products are defined by a set of
the ability to secure Web Services against Denial of common features. One of those features is XML
Service, Buffer Overflow, and XML Denial of Service content inspection also known as deep packet
attacks; as well as having an authorization mechanism. inspection (DPI), which allows for the inspection of
the XML content embedded in the SOAP requests
1. Introduction coming to the web services. Another feature is web-
services access control, either for a whole service or
As with many new emerging technologies, the for specific operations. Moreover, some web services
introduction of web services has introduced new firewalls accept WSDL2 files or Schema for SOAP-
security threats. Traditional layer 2-4 firewalls and envelope validation purposes. Two of the most
even application level firewalls are no longer viewed successful products in the market are the
as an effective way for providing a solution to those ForumSystems XWALL [5] and the DataPower XS40
threats. The use of web services over HTTP makes it XML security gateway [6]. They both help the user to
hard to use traditional layer 2-4 firewalls to block define his/her own policies either through a GUI as in
malicious web services traffic. Moreover, the SOAP1 XWALL, the definition of eXtensible Stylesheet
envelopes carrying the eXtensible Markup Language Language Transformation (XSLT) files that do content
(XML) content from and to web servers renders the inspection against the SOAP requests as in the XS40 or
current application level firewalls useless. This is due the usage of predefined WSDL files to perform the
to their inability to inspect this XML content for any necessary validations. They also help providing data
malicious data [3]. The web services firewall is level authorization through the usage of HTTP
introduced as a security application capable of username/password and SSL X.509 Certificates as in
inspecting and understanding the XML content XWALL and the usage of the OASIS XML Access
provided inside the SOAP envelopes. This is done to Control Markup Language (XACML)3 [7] as in the
make sure that they do not contain any harmful data. In XS40. Both firewalls allow for encrypting data up to
order to experiment a solution to these problems we the level of a single data element in the SOAP response
developed Nedgty, which is an open source web document. In addition to the previously mentioned
services firewall that secures web services by functionalities both products provide XML intrusion
intercepting packets going to the server, determining prevention by protecting against vulnerabilities
the web services specific packets, and checking them associated with XML parsers, and protecting against
for any malicious content. In addition, Nedgty filters buffer overflows, denial of service attacks and much
out unauthorized requests that originate from IP more. The platforms through which these firewalls
addresses that are not allowed to consume the provided
web services. 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-
1 oriented or procedure-oriented information [2].
Stands for Simple Object Access Protocol. It is the communication
3
protocol used for communication between web-service applications. XACML defines policies for information-access over the Internet
SOAP is designed to send messages via the Internet [1]. [2].
exist tend to vary from separate hardware appliances, that by uploading the WSDL file of his web service or
to installable software, and even a plug-in to Microsoft by manually setting the fields that define the structure
Internet Security and Acceleration (ISA) Server as in of his SOAP file, such as the method names exposed
the XWALL. by his web service and their SOAP actions. Other
Although an ultimate security product does not control data related to the types of threats that Nedgty
exist, both of the available products provide the protects against are requested from the administrator,
necessary protection that should be present for web such as the rate of SOAP requests allowed for each
services and represent a promising example of the web service to prevent DoS attacks. The administrator
newly introduced concept of web services firewalls. gets to choose the rules to apply on any of his web
services, which gives him more control on the type of
3. System Architecture protection he wants to enforce. Once a web service
profile is completed, it is committed to the repository
Nedgty has been developed with some features in in the form of XML. The stored profiles allow the
mind, such as its ability to be integrated with existing validation subsystem, to retrieve the validation rules
firewalls and its ability to be easily customized and for the incoming web services requests.
used. Figure 1 briefly describes the main components The SOAP filter is the subsystem used to separate
of our system. 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
Write to continue normal path to the server. On the other
Rules Repository Rules hand, the SOAP packets are captured for further
Interface
Logs
Validation Unit analysis and a verdict is returned to the IPTables to
Existing
Rules drop them silently. The silently dropped packets are
Parsed XML stored in a list of queues, each containing one request.
Request verdict
Once all the packets of the request are completely
Parsed XML
Parser
Packet Queue
received and queued by the firewall, the packets are
Packet Payload
SOAP packets
Valid SOAP
extracted from the queue, parsed by the parser
Soap Filter Packet Forger subsystem, which is a simple XML parser, and sent to
Port 80 traffic Set Verdict
SOAP
packets
the validation subsystem.
The validation subsystem represents the core of this
Packet from Client Non-SOAP Packets
IP Tables to Server
Server project. It does its XML related checks on the parsed
tree of the incoming SOAP request. In addition, it has
Figure 1. Nedgty System Architecture
the ability to do web services checks that do not
depend on the incoming SOAP content. For example, a
The target operating system for Nedgty is the Linux
module for IP authorization has been included in the
OS. Nedgty functions at the application level as a
validation subsystem to protect web services against
stand-alone application and its design is a hybrid of a
invalid IP’s. In both of the above mentioned checks the
fully fledged proxy. As evident in the above diagram,
validations are done against the rules defined in the
Nedgty communicates with the IPTables, a Linux layer
web services profiles for each kind of attack.
2 firewall. Nedgty makes use of the QUEUE target, an
To make Nedgty transparent to both the client and
IPTables module that forwards any desired packets to
the server, the silently dropped packets belonging to
the user-space, to intercept the web services specific
the incoming SOAP requests are forged by Nedgty’s
packets validate them and forward or drop them
packet forger and re-sent to the server, who - due to
accordingly.
packet forging - assumes that his client was the original
An interface is responsible for setting the security
sender of it.
policies and committing them to a persistent storage,
Nedgty’s system architecture and object oriented
referred to as the Repository. For requests to pass the
design allows for the extensibility of its security
firewall, the administrator needs to register the web
features. To add any new security check, its related
services that should be published and defines the
module is just added to the validation subsystem. This
control policies for each web service. Using the
allows the newly added module to gain access to the
interface, the administrator is allowed to add, edit and
parsed SOAP request, the HTTP header that
delete web services profiles. In each profile, the
accompanied it and the rules stored in the web services
administrator specifies the web service operations,
profiles. Further extensions can be achieved by adding
where the web service is located, and the accepted
new modules in the interfacing subsystem to allow the
SOAP message formats. He has the option of doing
administrator to define more rules related to his web service and a totally different list for another. Further
services profiles. 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 caches the XML file containing the
Nedgty’s prototype supports four types of checking validation rules of the requested web service in the
performed by separate modules in the validation form of a tree. Each time the validation unit receives a
subsystem. new SOAP request, it searches for the profile of the
The first two modules check against SOAP related requested web service in the cache. If the profile is not
threats, such as buffer overflow and XDoS. The buffer found it is loaded from the XML files in the repository
overflow module does validation checks against the and cached. This is done to reduce the frequency of the
SOAP version of the buffer overflow attack. Currently I/O operations and the reparsing of the XML files that
it checks the SOAP requests for the type and length of affect the performance of real time applications like
the sent parameters, in order to see if they conform to Nedgty.
the predefined types that are defined in the web service
profile and the maximum allowed length as specified 4.3 Queue SOAP Requests
by the administrator. An example would be sending
strings longer than what the buffer can handle or To accommodate the need for protecting more than
inconsistent data types, such as a character to a method one web service, Nedgty has to have the ability to
that was defined in its WSDL file to accept integers. handle multiple incoming requests. Since each request
Further extensions to this module can include might be divided into multiple packets, Nedgty queues
preventing unauthorized characters that might lead to all the packets belonging to the same request together.
application specific threats, such as SQL injection. The Taking into consideration that the packets belonging to
XDoS module checks the parsed XML content of the the same request may not come in correct sequence,
SOAP file to prevent anything that might crash XML they are sorted by the queuing module as soon as they
parser at the server side. This is done by validating the are all received.
syntax of the XML content of the SOAP requests and
by checking to see if the SOAP message conforms to 4.4 Forge the Packets
its stored format in the stored web service profile. As
an example, a SOAP request to an un-existing method In order to keep receiving packets from the QUEUE
or having incorrect XML syntax as a missing closing target in IPTables, a verdict has to be set on each
tag is dropped. packet. Since at this stage it is too early to set a target
The remaining two modules provided by the for the packet without receiving the complete request,
validation subsystem check for non-SOAP related Nedgty stores copies of the incoming packets as
threats that affect web services. The first protects mentioned in section 4.3 and signals the IPTables
against DoS attack targeting web services. It keeps firewall to silently drop them. After complete requests
count of the rate of SOAP requests coming to each web are received and validated, they need to be resent to the
service and validates it against the predefined rates by server. Nedgty forges those packets with the original
the administrator. Any rate of request exceeding the sender’s TCP and IP headers and resends them to the
predefined one results in dropping the incoming server, so that the web service firewall becomes
requests till the rate is returned to normal. The reason transparent to both the client and the server.
why such an attack was not classified as a SOAP
related threat is that SOAP requests can be identified 4.5 Logging and Reporting
from their related HTTP headers, however it is still a
web service specific threat since it is caused by the rate Nedgty provides its users with logging abilities. On
of SOAP requests and not the rate of normal web daily basis, the first received request triggers the auto-
traffic. The second module that does non SOAP related creation of a new log file named according to the date
checks is the authorization module. Currently this of the day. During the day, all the validation results
module does IP authorization, which validates the IP’s corresponding to the received requests are saved in the
requesting the web services against a predefined list of day’s log file. Upon the administrator’s request, the
IP’s. This feature is available on separate basis for each logs are used to create reports listing the requests
web service, which allows for defining a list for a web 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 5. Remaining Areas of Concern and Future
denial of a request if it exists. All the generated reports Enhancements
are in the form of XML files linked to a style sheet that
makes them easily viewed using a web browser.
5.1 Other Types of Attacks
4.6 Testing Currently, Nedgty protects web services against
DoS, XDoS, and Buffer Overflow attacks.
Additionally, it prohibits the users trying to access the
SOAP Valid
Request Request web services through requests coming from IP’s that
are not allowed. However, there are still other attacks
SOAP SOAP that Nedgty is not protecting against. Future
Response Response
Nedgty
enhancements include:
Client
Web Server o Adding an intrusion detection mechanism:
Figure 2. Testing Network Since Nedgty collects a lot of data in its log files
tracking its day to day activities, an intrusion detection
Every subcomponent of the Nedgty prototype was and prevention mechanism can be a good addition that
tested separately using customized test cases during the utilizes the existing logged data to prevent future
development phase to ensure that it functions properly. security breaches.
After the integration of all the subcomponents of our o Protecting against encrypted data:
system, the system as a whole was tested on the testing In some cases, data in the SOAP envelope is
network in Figure 2. The testing network is composed encrypted. Malicious encrypted content may go
of a client application, a web server and a PC hosting through the firewall undetected. A future enhancement
Nedgty, interconnected by a direct connection. The in this area can protect the web services against attacks
client hosted applications were used to invoke the web that depend on encrypted SOAP envelope content by
service hosted by the web server. Client applications providing Nedgty with the ability to decrypt any
were implemented using ASP.Net and Java. incoming encrypted data. However some may see this
Nedgty was hosted on a Linux OS that had the as a negative point since the current system is
IPtables stored firewall installed on it, and used static centralized and enabling it to decrypt messages will
route to redirect the traffic from the client to the server. break the link between the service requestor and the
The web services hosted on the web server were service provider.
implemented using C# and hosted on an IIS server and o Enforcing standardized protocols:
java hosted on an Apache Axis server [8]. Currently, the project only enforces business
The testing network traffic was monitored using a specific protocols. A future enhancement may include
special SOAP proxy, to monitor the SOAP traffic enforcing standardized protocols such as XML
coming from the client. XDoS and Buffer Overflow Signature, Security Assertion Markup Language
attacks were simulated by intercepting and editing the (SAML), XACML, etc.
client’s valid SOAP requests to include invalid content.
In our test cases Nedgty was successful in intercepting 5.2 Multi-Threading for validation process
and dropping the invalid requests.
IP authorization was tested by allowing certain IP’s The validation process is currently working on only
to use the hosted web services and sending requests one thread. However, better performance could be
from clients with a range of authorized and achieved if the validation process is done by creating a
unauthorized IP’s. Nedgty was successful in thread for checking each request, since more requests
intercepting the unauthorized IP’s and allowing the can be simultaneously handled.
authorized ones.
DoS was tested by setting a threshold in Nedgty and 5.3 Smarter Caching
sending requests at a rate exceeding that threshold.
Only requests within the allowed threshold reached the Currently, the caching is loaded on demand. If the
server. user wants to modify any web service profile while the
In all the above test cases Nedgty logged all the program is running, Nedgty has to be restarted in order
transactions in its logging sub system. The logs were to load the cache with the new data. A solution to this
checked for the valid and invalid cases and were problem is to provide smart caching mechanism. The
consistent with the used test cases. 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