In Part 4 of this series, I talked about how to set up access control lists (ACLs) and the impact of the size of ACL entries on uptime availability as specified in a service-level agreement (SLA) guarantee. I also explained how you can centralize security administration to better control the ACLs for multiple Web services and their associated applications in the Service-Oriented Architecture (SOA).
I mentioned ACLs as one of the Web services features that should be tested before a service is made public in "Use SLAs in a Web services context, Part 1: Guarantee your Web service with a SLA". I add firewalling as another feature to be tested. Not all users in the ACLs are also firewall users or administrators. I focus on the issues of multiple firewalls for Web services interacting with other applications in the SOA as they impact uptime availability guarantees in a SLA.
A firewall inspects the source and destination address of each message that crosses its path. It also logs on traffic that is rejected, detoured or stopped, and traffic that is permitted or redirected. On one side, the firewall lets intranet ACL users access permitted resources from the outside Internet. On the other side, it protects and hides a cluster of computers from cracking attempts and Denial of Service (DoS) from the Internet.
To suit specific requirements, you can add, delete, or even rearrange the order of the bricks in a firewall. When you do so, test the firewall to ensure the uptime availability guarantee maintains at a level agreed upon in the SLA.
To get a better idea of how firewalls interact with one another, let's develop a hierarchy of firewall administrators. As shown in Figure 1, the enterprise firewall administrator is the conductor of an orchestra of super firewall administrators, local administrators, and proxy users in hierarchical order. The enterprise administrator sets a policy for managing traffic flow among multiple firewalls for Web services, non-Web services, and Enterprise Application Integration (EAI) applications for all administrator levels.
Figure 1. Hierarchy of firewall administrators

You can adapt the hierarchy approach, for instance, to allow the enterprise firewall administrator to communicate directly with a proxy user bypassing the super and local administrators. This means the enterprise administrator can assume the duties of these super and local administrators when dealing directly with the proxy user.
In another instance as shown in Figure 2, the super administrator B gets permission from the enterprise administrator to communicate directly with the proxy user, normally accountable to local administrator A and then super administrator A. The enterprise administrator sends the report of the super administrator B's actions to super administrator A.
Figure 2. Communicate directly with a proxy user

Define firewall administrators
Unlike firewall administrators, proxy users do not have access to a firewall machine. While local firewall administrators can create and modify definitions of proxy users, each cannot do so for other local firewall administrators. Local administrators cannot perform local log ons to an operating system -- Windows or Linux. While super administrators can do both, they cannot create and modify definitions for other super firewall administrators. Only the enterprise administrator can exercise this privilege.
You need a user account policy to spell out the general responsibilities of each firewall administrator. The policy needs to include additional duties that the local and super administrators must perform to suit unique departmental requirements. The policy should also include the privileges that allow the enterprise administrator to directly communicate with the local administrator to meet the uptime availability guarantees.
Also important are the security policies that vary from one application to another and one operating system to another. According to IBM® SecureWay Firewall for Window NT (see Resources), you as the authorized administrator need the configuration client to define a security policy (and define network objects and log on to the firewall). For example, you can get the administrator to enable the following policies at a minimum: Also important are the security policies that vary from one application to another and one operating system to another. According to IBM SecureWay Firewall for Microsoft® Windows NT (see Resources), you as the authorized administrator need the configuration client to define a security policy and network objects and log on to the firewall. For example, you can get the administrator to enable the following policies at a minimum:
- Permit Domain Name System (DNS) queries
- Deny broadcast message to nonsecure interface
- Deny socks to nonsecure adapters
In Windows XP Service Pack 2, you need to set up a security policy in a separate Control Panel component (firewall). When you use Linux, you need iptables (see Resources) to define a policy of responding to an incoming packet by accepting, dropping, or rejecting it. You must adequately define all security policies to ensure uptime availability guarantees with little or no interruption thresholds.
You should be working with the enterprise administrator. The primary reason is that many Web services -- long-running and short-running applications -- interact with other services and EAI applications in the SOA across the firewalls. Some Web services behind multiple firewalls must access authorized Internet resources that might be needed to complete the tasks of an activity or a set of activities. You should recommend where necessary to the enterprise administrator to include in the hierarchy a new type of firewall administrator that a Web service under development needs.
The enterprise administrator must establish a filtering criteria policy for all administrative levels of the hierarchy on controlling and monitoring traffic from many address sources and destinations. One example is to specify rules on which inbound packets to:
- Accept
- Drop
- Reject
- Masquerade
- Forward
- Redirect
The enterprise administrator must also filter which ports or programs to open or close. Another example is to set rules on determining what traffic passes across the firewall based on Internet Protocol (IP) session for each Web service and other SOA services. Some rules by default take precedence over others. By setting or changing the priority, you can control the order in which rules are used and applied.
Under Linux, all filtering criteria and the use of Internet Control Message Protocol (ICMP) are available as command lines using iptables (see Resources). In Windows XP Service Pack 2, you use the graphical user interface (GUI) dialog screens to add programs, ports, and even an individual connection for a Web service to the list of firewall exceptions. While adding some programs makes them work better, they might increase security risk.
Part of the firewall contains three applications: Transmission Control Protocol/Internet Protocol (TCP/IP), User Datagram Protocol (UDP), and ICMP. The proxy server uses one of the TCP/IP applications (for example, FTP and HTTPS) when it is contacted by a proxy user. This server, in turn, makes a connection with the remote host on behalf of the user while hiding the network structure from other users external to the firewall.
In contrast, User Datagram Protocol/Internet Protocol (UDP/IP) applications send stateless data without establishing a connection. To get computers on a network to share error, status, and redirect information, you can use ICMP applications, such as Personal Internet Gate (PING), to handle administrative functions.
Interruption thresholds in log files
A standard logging file shows dropped packets and successful inbound and outbound connections. To determine whether the packet losses are significant or insignificant, interruption thresholds need to be developed as explained in my article, "Part 3: Integrate Web services into EAI with a SLA guarantee". I suggest modifying the format of a log file to include a column on recording significant interruption thresholds automatically calculated every time packet losses occur and another column to alert the administrators of impending problems of impacting uptime availability guarantees in a SLA.
Since interruption thresholds might be impacted by an inadequate load balancing scheme, the enterprise administrator could use the log files as tools to determine how the load should be better distributed across multiple IBM firewalls without users being aware which firewall is currently servicing their requests. This means that local administrator A accountable to super administrator A does not have to know about the server load at the firewall that super administrator B can access.
Firewalling Web services in a heterogeneous SOA is not an easy task. The most important thing to keep in mind is to test the effectiveness of the firewalled Web services before releasing them to public. You can accomplish this by direct communication between yourself and the firewall administrators, particularly on the issues of interruption thresholds due to dropped packets and other negative factors.
- Get information on how to use SLAs in a Web services context from the other papers in this series:
- "Guarantee your Web service with a SLA" (developerWorks, April 2002)
- "Guarantee second-generation Web services applications with a SLA" (developerWorks, August 2004)
- "Integrate Web services into EAI with a SLA guarantee" (developerWorks, October 2004)
- "Secure multiple Web services with a SLA guarantee" (developerWorks, November 2004)
- "Localize Web services with a SLA guarantee" (developerWorks, January 2005)
- "Mitigate risk for vulnerability with a SLA guarantee" (developerWorks, January 2005)
- Learn more about iptables on setting up Linux firewall rules and policies in a tutorial.
- Get more information on "Building a Linux Firewall with IPTABLES" on how to use the configuration client to set up the firewall.
- Go the IBM way with its SecureWay Firewall for Windows NT.
- Read Judith M. Myerson's The Complete Book of Middleware, which focuses on the essential principles and priorities of system design and emphasizes the new requirements brought forward by the rise of e-commerce and distributed integrated systems.
- Get the business insight and the technical know-how to ensure successful systems integration by reading Enterprise Systems Integration, Second Edition.
- Publish your Web service or application in IBM's UDDI version 2 registry, which features a graphical user interface and conformant APIs for public use. IBM's UDDI version 3 beta registry.
- Go into the nuts and bolts of developing a service-level agreement in this IBM Redbook for Domino administrators.
- Browse for books on these and other technical topics.
- Want more? The developerWorks SOA and Web services zone hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.
Judith M. Myerson is a systems architect and engineer. Her areas of interest include middleware technologies, enterprise-wide systems, database technologies, application development, network management, security, and project management. You can contact her at jmyerson@bellatlantic.net.
Comments (Undergoing maintenance)





