The BIG-IP Application Security Manager Part 5: XML Security
This is the fifth article in a 10-part series on the BIG-IP Application Security Manager (ASM). The first four articles in this series are: What is the BIG-IP ASM? Policy Building The Importance of File Types, Parameters, and URLs Attack Signatures This fifth article in the series will discuss the basic concepts of XML and how the BIG-IP ASM provides security for XML. XML Concepts The Extensible Markup Language (XML) provides a common syntax for data transfer between similar systems. XML doesn't specify how to display data (HTML is used for that), but rather it is concerned with describing data that can be manipulated and presented using other languages. XML documents are built on a core set of basic nested structures, and developers can decide how tags are named and organized. XML is used extensively in web applications today, so it's important to have a basic understanding as well as a strong defense for this critical technology. The XML specification (described in this W3C publication) defines an XML document to be well-formed when it satisfies a list of syntax rules provided in the specification. If an XML processor encounters a violation of these rules, it is required to stop processing the file and report the error. A valid XML document is defined as a well-formed document that also conforms to the rules of a schema like the Document Type Definition (DTD) or the newer and more powerful XML Schema Definition (XSD). It's important to have valid XML documents when implementing and using web services. Web Service A web service is any service that is available over a network and that uses standardized XML syntaxes. You've heard of the "... as a Service" right? Well, this is the stuff we're talking about, and XML plays a big role. On a somewhat tangential note, it seems like there are too many "as a Service" acronyms flying around right now...I really need to make up a hilarious one just for the heck of it. I'll let you know how that goes... Anyway, back to reality...a web service architecture consists of a service provider, a service requestor, and a service registry. The service provider implements the service and publishes the service to the service registry using Universal Description, Discovery, and Integration (UDDI) which is an XML-based registry that allows users to register and locate web service applications. The service registry centralizes the services published by the service provider. The service requestor finds the service using UDDI and retrieves the Web Services Definition Language (WSDL) file, which consists of an XML-based interface used for describing the functionality offered by the web service. The service requestor is able to consume the service based on all the goodness found in the WSDL using the UDDI. Then, the service requestor can send messages to the service provider using a service transport like the Simple Object Access Protocol (SOAP). SOAP is a protocol specification for exchanging structured information when implementing web services...it relies on XML for its message format. Now you can see why XML is so closely tied to Web Services. All this craziness is shown in the diagram below. I know what you're thinking...it's difficult to find anything more exciting than this topic! (Picture copied from Wikipedia) Because XML is used for data transfer in the web services architecture, it's important to inspect, validate, and protect XML transactions. Fortunately, the BIG-IP ASM can protect several applications including: Web services that use HTTP as a transport layer for XML data Web services that use encryption and decryption in HTTP requests Web services that require verification and signing using digital signatures Web applications that use XML for client-server data communications (i.e. Microsoft Outlook Web Access) ASM Configuration Before you can begin protecting your XML content, you have to create a security policy using the "XML and Web Services" option. After you create the security policy, you create an XML profile and associate it with the XML security policy. You can read more about creating policies in the Policy Building article in this series. To create an XML profile, you navigate to Application Security >> Content Profiles >> XML Profiles. When all this is done, the XML profile will protect XML applications in the following ways: Validate XML formatting Mask sensitive data Enforce compliance with XML schema files or WSDL documents Provide information leakage protection Offer XML encryption and XML signatures Offer XML content based routing and XML switching Offer XML parser protection against DoS attacks Encrypt and decrypt parts of SOAP web services Validation resources provide the ASM with critical information about the XML data or web services application that the XML profile is protecting. As discussed earlier, many XML applications have a schema file for validation (i.e. DTD or XSD) or WSDL file that describes the language used to communicate with remote users. The XML profile is used to validate whether the incoming traffic complies with the predefined schemas or WSDL files. The following screenshot shows the configuration of the XML profile in the ASM. Notice all the different features it provides. You can download the all-important configuration files (WSDL), you can associate attack signatures to the profile (protects against things like XML parser attacks -- XML Bombs or External Entity Attacks), you can allow/disallow meta characters, and you can configure sensitive data protection for a specific namespace and a specific element or attribute. Another really cool thing is that most of these features are turned on/off using simple checkboxes. This is really cool and powerful stuff! I won't bore you with all the details of each setting, but suffice it to say, this thing let's you do tons of great things in order to protect your XML data. Well, that does it for this ASM article. I hope this sheds some light on how to protect your XML data. And, if you're one of the users who implements anything "as a Service" make sure you protect all that data by turning on the BIG-IP ASM. The next time someone throws an XML bomb your way, you'll be glad you did! Update: Now that the article series is complete, I wanted to share the links to each article. If I add any more in the future, I'll update this list. What is the BIG-IP ASM? Policy Building The Importance of File Types, Parameters, and URLs Attack Signatures XML Security IP Address Intelligence and Whitelisting Geolocation Data Guard Username and Session Awareness Tracking Event Logging
Layer 7 Switching + Load Balancing = Layer 7 Load Balancing
Modern load balancers (application delivery controllers) blend traditional load-balancing capabilities with advanced, application aware layer 7 switching to support the design of a highly scalable, optimized application delivery network. Here's the difference between the two technologies, and the benefits of combining the two into a single application delivery controller. LOAD BALANCING Load balancing is the process of balancing load (application requests) across a number of servers. The load balancer presents to the outside world a "virtual server" that accepts requests on behalf of a pool (also called a cluster or farm) of servers and distributes those requests across all servers based on a load-balancing algorithm. All servers in the pool must contain the same content. Load balancers generally use one of several industry standard algorithms to distribute request. Some of the most common standard load balancing algorithms are: round-robin weighted round-robin least connections weighted least connections Load balancers are used to increase the capacity of a web site or application, ensure availability through failover capabilities, and to improve application performance. LAYER 7 SWITCHING Layer 7 switching takes its name from the OSI model, indicating that the device switches requests based on layer 7 (application) data. Layer 7 switching is also known as "request switching", "application switching", and "content based routing". A layer 7 switch presents to the outside world a "virtual server" that accepts requests on behalf of a number of servers and distributes those requests based on policies that use application data to determine which server should service which request. This allows for the application infrastructure to be specifically tuned/optimized to serve specific types of content. For example, one server can be tuned to serve only images, another for execution of server-side scripting languages like PHP and ASP, and another for static content such as HTML , CSS , and JavaScript. Unlike load balancing, layer 7 switching does not require that all servers in the pool (farm/cluster) have the same content. In fact, layer 7 switching expects that servers will have different content, thus the need to more deeply inspect requests before determining where they should be directed. Layer 7 switches are capable of directing requests based on URI, host, HTTP headers, and anything in the application message. The latter capability is what gives layer 7 switches the ability to perform content based routing for ESBs and XML/SOAP services. LAYER 7 LOAD BALANCING By combining load balancing with layer 7 switching, we arrive at layer 7 load balancing, a core capability of all modern load balancers (a.k.a. application delivery controllers). Layer 7 load balancing combines the standard load balancing features of a load balancing to provide failover and improved capacity for specific types of content. This allows the architect to design an application delivery network that is highly optimized to serve specific types of content but is also highly available. Layer 7 load balancing allows for additional features offered by application delivery controllers to be applied based on content type, which further improves performance by executing only those policies that are applicable to the content. For example, data security in the form of data scrubbing is likely not necessary on JPG or GIF images, so it need only be applied to HTML and PHP. Layer 7 load balancing also allows for increased efficiency of the application infrastructure. For example, only two highly tuned image servers may be required to meet application performance and user concurrency needs, while three or four optimized servers may be necessary to meet the same requirements for PHP or ASP scripting services. Being able to separate out content based on type, URI, or data allows for better allocation of physical resources in the application infrastructure.BigIP ASM Problems with FileUploads with SOAP
Hi there, actually my ASM Policy is blocking a file upload for one application with the error message: HTTP protocol compliance failed Chunks number exceeds request chunks limit: 1000 I raised the chunks limit blindly from 1000 to 1500 with no success. Where I can see the actually number of chunks without capturing the traffic? After disabling the funktion "Unparsable request content" Upload went through without a problem. But from the notice I would stick this on? Note that disabling this check can result in losing many enforcement features in the ASM. Sametime I get the following syslogs: ASM out of memory error: event code X242 Exceeded maximum memory assigned for XML/JSON processing Cannot allocate 27415074 more bytes for XML parser. current memory size 837505174 (in bytes) As you can see I raised the available memory for XML request from 450MB (default) to nearly the double.
Load Balancing as an ESB Service
Most people, upon hearing the term "load balancing" immediately think of web and application servers deployed at the edge of the network. After all, that's where load balancing is most often used - to ensure that a public facing web site is always as available and fast as possible. What many architects don't consider, however, is that in the process of deploying a SOA (Service Oriented Architecture) those same web and application servers end up residing deeper in the data center, away from the edge of the network. These web and application servers are hosting the services that make up a public facing application or site, but aren't necessarily afforded the same consideration in terms of availability as the initial entry point into that application. This situation is compounded by the fact that there may be an ESB (Enterprise Service Bus) orchestrating that application, and that services critical to the application are not afforded the same measure of reliability as those closer to the edge of the network. While most ESBs are capable of load balancing these critical services, this capability is often limited and lacking the more robust and dynamic features offered by application delivery controllers (ADC). Consider a public facing service that takes advantage of an ESB: The Compliance and Shipping Services are critical to the public facing service, as are the other services provided by theESB. And yet in a typical implementation only the public facing service (the Order Management Service) will be afforded the reliability and optimization provided by an application delivery controller. It may be the case that the ESB is load balancing the Compliance and Shipping services, as simple load balancing capabilities are provided by most ESBs. While you might find the load balancing capabilities adequate, consider that most ESBs lack the health monitoring capabilities of application delivery controllers in addition to being unable to balance the load based on real-time factors such as number of connections and response time, making it difficult to optimize your SOA. The lesson learned by application delivery vendors in the past have not yet been incorporated into ESBs. Just because a server responds to an ICMP ping or can successfully open a TCP socket does not mean the application - or service - is actually running and returning valid responses. An ADC is capable of monitoring services at the application level, ensuring that not only is the service running but that it's also returning valid responses. This is something most ESBs are not capable of providing, which reduces the effectiveness of such health checks and can result in a service being treated as available even if it's malfunctioning. When it's really important, i.e. when services are critical to a critical application - such as a customer/public facing application - then it's likely you should ensure that those back-end services are always available and optimized. An application delivery controller isn't limited to hanging out in the DMZ or on the edge of the network. In fact, an ADC can just as easily slide into your SOA and provide the same high availability, optimization, and failover services as it does for public facing applications. By integrating an application delivery controller into the depths of the data center you can let the ESB do what it's best at doing: transformation, message enrichment, and reliable messaging and remove the burden of performing tasks that are better suited to an ADC than an ESB such as load balancing, protocol optimization, and health monitoring. The addition of an ADC to assist the ESB and ensure reliability also provides a layer of abstraction that fits nicely into your SOA and aligns with one of SOA's primary goals: agility. SOA implementations are by their nature distributed. Composing applications from distributed services achieves agility and reuse, but introduces potential show-stopping problems usuallyexperiencedat the edge of the network into the heart of thedata center. It is important to consider the impact of failure of a service on the application(s) that may be using that service, and if that application is critical, then its dependent services should also be treated as critical and worthy of the protection of an application delivery controller. Imbibing: Orange Juice Technorati tags: MacVittie, F5, ESB, SOA, application delivery, service oriented application delivery, load balancing
Perl Ltm Config To Xml/Excel (version 3.1)
Problem this snippet solves: This code is an improvement of "Perl Ltm Config To Xml (version 2)" published on previous DevCentral (https://devcentral.f5.com/s/articles/perl-ltm-config-to-xml-version-2-1009) queries the components of a virtual servers configuration and prints it out in an XML format. Is recursive through partitions and prints the following data: VS_name VS_IP: IP and port RD (route domain) VS_state: status (ex. green) and state (ex. enabled) Profiles: name, type, context. If SSL profile aditional info: certificate, chain, key, cipher list Persistence iRules: order and name Pool_name LB-method: method, minimum active members Member: name, IP, port, ratio, priority, status and state Monitors: name, interval, timeout. If HTTP/HTTPS monitors additional info: Send and Receive strings SNAT_name SNAT_members Has a new option "-s" or "-simplified" which outputs multiple values like the profile list or pool members into a unique XML field. Purpose of simplified mode is to be able to have one Virtual Server per row on Excel, with lists showing on a single cell. This code has been tested on BIG-IP version 12.1 and 14.1. How to use this snippet: Default mode: ./LTM-to-XML.pl bigip uid pwd > result.xml Example for simplified mode and removal of partition information: ./LTM-to-XML.pl -s 127.0.0.1 uid pwd | sed "s/\/.*app\///g" | sed "s/\/Common\///g" > result.xml The XML can be dragged and dropped on MS Excel and opened as an XML table. Code : (see ZIP file) Tested this on version: 12.1, 14.1The Stealthy Ascendancy of JSON
While everyone was focused on cloud, JSON has slowly but surely been taking over the application development world It looks like the debate between XML and JSON may be coming to a close with JSON poised to take the title of preferred format for web applications. If you don’t consider these statistics to be impressive, consider that ProgrammableWeb indicated that its “own statistics on ProgrammableWeb show a significant increase in the number of JSON APIs over 2009/2010. During 2009 there were only 191 JSON APIs registered. So far in 2010 [August] there are already 223!” Today there are 1262 JSON APIs registered, which means a growth rate of 565% in the past eight months, nearly catching up to XML which currently lists 2162 APIs. At this rate, JSON will likely overtake XML as the preferred format by the end of 2011. This is significant to both infrastructure vendors and cloud computing providers alike, because it indicates a preference for a programmatic model that must be accounted for when developing services, particularly those in the PaaS (Platform as a Service) domain. PaaS has yet to grab developers mindshare and it may be that support for JSON will be one of the ways in which that mindshare is attracted. Consider the results of the “State of Web Development 2010” survey from Web Directions in which developers were asked about their cloud computing usage; only 22% responded in the affirmative to utilizing cloud computing. But of those 22% that do leverage cloud computing, the providers they use are telling: PaaS represents a mere 7.35% of developers use of cloud computing, with storage (Amazon S3) and IaaS (Infrastructure as a Service) garnering 26.89% of responses. Google App Engine is the dominant PaaS platform at the moment, most likely owing to the fact that it is primarily focused on JavaScript, UI, and other utility-style services as opposed to Azure’s middle-ware and definitely more enterprise-class focused services. SaaS, too, is failing to recognize the demand from developers and the growing ascendancy of JSON. Consider this exchange on the Salesforce.com forums regarding JSON. Come on salesforce lets get this done. We need to integrate, we need this [JSON]. If JSON continues its steady rise into ascendancy, PaaS and SaaS providers alike should be ready to support JSON-style integration as its growth pattern indicates it is not going away, but is instead picking up steam. Providers able to support JSON for PaaS and SaaS will have a competitive advantage over those that do not, especially as they vie for the hearts and minds of developers which are, after all, their core constituency. THE IMPACT What the steady rise of JSON should trigger for providers and vendors alike is a need to support JSON as the means by which services are integrated, invoked, and data exchanged. Application delivery, service-providers and Infrastructure 2.0 focused solutions need to provide APIs that are JSON compatible and which are capable of handling the format to provide core infrastructure services such as firewalling and data scrubbing duties. The increasing use of JSON-based APIs to integrate with external, third-party services continues to grow and the demand for enterprise-class service to support JSON as well will continue to rise. There are drawbacks, and this steady movement toward JSON has in some cases a profound impact on the infrastructure and architectural choices made by IT organizations, especially in terms of providing for consistency of services across what is likely a very mixed-format environment. Identity and access management and security services may not be prepared to handle JSON APIs nor provide the same services as it has for XML, which through long established usage and efforts comes with its own set of standards. Including social networking “streams” in applications and web-sites is now as common as including images, but changes to APIs may make basic security chores difficult. Consider that Twitter – very quietly – has moved to supporting JSON only for its Streaming API. Organizations that were, as well they should, scrubbing such streams to prevent both embarrassing as well as malicious code from being integrated unknowingly into their sites, may have suddenly found that infrastructure providing such services no longer worked: API providers and developers are making their choice quite clear when it comes to choosing between XML and JSON. A nearly unanimous choice seems to be JSON. Several API providers, including Twitter, have either stopped supporting the XML format or are even introducing newer versions of their API with only JSON support. In our ProgrammableWeb API directory, JSON seems to be the winner. A couple of items are of interest this week in the XML versus JSON debate. We had earlier reported that come early December, Twitter plans to stop support for XML in its Streaming API. --JSON Continues its Winning Streak Over XML, ProgrammableWeb (Dec 2010) Similarly, caching and acceleration services may be confused by a change from XML to JSON; from a format that was well-understood and for which solutions were enabled with parsing capabilities to one that is not. IT’S THE DATA, NOT the API The fight between JSON and XML is one we continue to see in a general sense. See, it isn’t necessarily the API that matters, in the end, but the data format (the semantics) used to exchange that data which matters. XML is considered unstructured, though in practice it’s far more structured than JSON in the sense that there are meta-data standards for XML that constrain security, identity, and even application formats. JSON, however, although having been included natively in ECMA v5 (JSON data interchange format gets ECMA standards blessing) has very few standards aside from those imposed by frameworks and toolkits such as JQuery. This will make it challenging for infrastructure vendors to support services targeting application data – data scrubbing, web application firewall, IDS, IPS, caching, advanced routing – to continue to effectively deliver such applications without recognizing JSON as an option. The API has become little more than a set of URIs and nearly all infrastructure directly related to application delivery is more than capable of handling them. It is the data, however, that presents a challenge and which makes the developers’ choice of formats so important in the big picture. It isn’t just the application and integration that is impacted, it’s the entire infrastructure and architecture that must adapt to support the data format. The World Doesn’t Care About APIs – but it does care about the data, about the model. Right now, it appears that model is more than likely going to be presented in a JSON-encoded format. JSON data interchange format gets ECMA standards blessing JSON Continues its Winning Streak Over XML JSON versus XML: Your Choice Matters More Than You Think I am in your HTTP headers, attacking your application The Web 2.0 API: From collaborating to compromised Would you risk $31,000 for milliseconds of application response time? Stop brute force listing of HTTP OPTIONS with network-side scripting The New Distribution of The 3-Tiered Architecture Changes Everything Are You Scrubbing the Twitter Stream on Your Web Site?
Perl Ltm Config To Xml (version 2)
Problem this snippet solves: This example is based on "Perl Ltm Config To Xml" by Joe Pruitt: queries the components of a virtual servers configuration and prints it out in an XML format for further processing. Now with a few more data retrieved (SNAT, object status) and does recursively on partitions, this way listing configuration generated by iApps on separate partitions. How to use this snippet: ./LTM-to-XML.pl bigip user pass Code : #!/usr/bin/perl #---------------------------------------------------------------------------- # The contents of this file are subject to the iControl Public License # Version 4.5 (the "License"); you may not use this file except in # compliance with the License. You may obtain a copy of the License at # http://www.f5.com/. # # Software distributed under the License is distributed on an "AS IS" # basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See # the License for the specific language governing rights and limitations # under the License. # # The Original Code is iControl Code and related documentation # distributed by F5. # # The Initial Developer of the Original Code is F5 Networks, # Inc. Seattle, WA, USA. Portions created by F5 are Copyright (C) 1996-2003 F5 Networks, # Inc. All Rights Reserved. iControl (TM) is a registered trademark of F5 Networks, Inc. # # Alternatively, the contents of this file may be used under the terms # of the GNU General Public License (the "GPL"), in which case the # provisions of GPL are applicable instead of those above. If you wish # to allow use of your version of this file only under the terms of the # GPL and not to allow others to use your version of this file under the # License, indicate your decision by deleting the provisions above and # replace them with the notice and other provisions required by the GPL. # If you do not delete the provisions above, a recipient may use your # version of this file under either the License or the GPL. #---------------------------------------------------------------------------- #use SOAP::Lite + trace => qw(method debug); use SOAP::Lite; #---------------------------------------------------------------------------- # Validate Arguments #---------------------------------------------------------------------------- my $BIGIP = $ARGV[0]; my $User = $ARGV[1]; my $Pass = $ARGV[2]; sub usage() { die ("Usage: LtmConfigToXml.pl host uid pwd\n"); } if ( ($BIGIP eq "") or ($User eq "") or ($Pass eq "") ) { usage(); } #---------------------------------------------------------------------------- # Transport Information #---------------------------------------------------------------------------- sub SOAP::Transport::HTTP::Client::get_basic_credentials { return "$User" => "$Pass"; } $urnMap = { "{urn:iControl}LocalLB.LBMethod" => 1, "{urn:iControl}LocalLB.MonitorRuleType" => 1, "{urn:iControl}LocalLB.ProfileContextType" => 1, "{urn:iControl}LocalLB.ProfileType" => 1, "{urn:iControl}LocalLB.VirtualServer.VirtualServerType" => 1, "{urn:iControl}LocalLB.AvailabilityStatus" => 1, "{urn:iControl}LocalLB.MonitorStatus" => 1, "{urn:iControl}LocalLB.EnabledStatus" => 1, "{urn:iControl}Common.EnabledState" => 1, "{urn:iControl}Common.VLANFilterList" => 1, }; sub SOAP::Deserializer::typecast { my ($self, $value, $name, $attrs, $children, $type) = @_; my $retval = undef; if ( 1 == $urnMap->{$type} ) { $retval = $value; } return $retval; } sub GetInterface() { my ($module, $name) = @_; $interface = SOAP::Lite -> uri("urn:iControl:$module/$name") -> readable(1) -> proxy("https://$BIGIP/iControl/iControlPortal.cgi"); eval { $interface->transport->http_request->header ( 'Authorization' => 'Basic ' . MIME::Base64::encode("$User:$Pass", '') ); }; return $interface; } sub FixEmptyEntries() { my @list1 = @_; my @list2; my $valid_item = ""; for $i (0 .. $#list1) { $item = @list1[$i]; if ( $item ne "" ) { $valid_item = $item; break; } } for $i (0 .. $#list1) { $item = @list1[$i]; if ( $item ne "" ) { push @list2, $item; } else { push @list2, $valid_item; } } return @list2; } # Status conversion my $MONITOR_STATUS_MAP = { "MONITOR_STATUS_UNCHECKED" => "UNCHECKED", "MONITOR_STATUS_CHECKING" => "CHECKING", "MONITOR_STATUS_UP" => "UP", "MONITOR_STATUS_DOWN" => "DOWN", "MONITOR_STATUS_FORCED_DOWN" => "FORCED_DOWN", "MONITOR_STATUS_MAINT" => "MAINT", "MONITOR_STATUS_ADDRESS_DOWN" => "ADDRESS_DOWN", }; my $ENABLED_STATUS_MAP = { "ENABLED_STATUS_NONE" => "NONE", "ENABLED_STATUS_ENABLED" => "ENABLED", "ENABLED_STATUS_DISABLED" => "DISABLED", "ENABLED_STATUS_DISABLED_BY_PARENT" => "DISABLED_BY_PARENT", }; # Get config sub GetConfigXML() { # Enable Recursive Partition/Folder lookup and set /Common as active folder $SystemSession = &GetInterface("System", "Session"); $soapResponse = $SystemSession->set_recursive_query_state( SOAP::Data->name(state => "STATE_ENABLED") ); &checkResponse($soapResponse); $soapResponse = $SystemSession->set_active_folder( SOAP::Data->name(folder => "/") ); # Get data $LocalLBVirtualServer = &GetInterface("LocalLB", "VirtualServer"); $LocalLBPool = &GetInterface("LocalLB", "Pool"); $LocalLBPoolMember = &GetInterface("LocalLB", "PoolMember"); $LocalLBSNATPool = &GetInterface("LocalLB", "SNATPool"); # VS List $soapResponse = $LocalLBVirtualServer->get_list(); &checkResponse($soapResponse); @vs_list = @{$soapResponse->result}; # Destination $soapResponse = $LocalLBVirtualServer->get_destination_v2( SOAP::Data->name (virtual_servers => [@vs_list]) ); &checkResponse($soapResponse); @destination_list = @{$soapResponse->result}; # Type $soapResponse = $LocalLBVirtualServer->get_type( SOAP::Data->name (virtual_servers => [@vs_list]) ); &checkResponse($soapResponse); @vstype_list = @{$soapResponse->result}; # iRules $soapResponse = $LocalLBVirtualServer->get_rule( SOAP::Data->name (virtual_servers => [@vs_list]) ); &checkResponse($soapResponse); @rule_listA = @{$soapResponse->result}; # Profiles $soapResponse = $LocalLBVirtualServer->get_profile( SOAP::Data->name(virtual_servers => [@vs_list]) ); &checkResponse($soapResponse); @profile_listA = @{$soapResponse->result}; $soapResponse = $LocalLBVirtualServer->get_persistence_profile( SOAP::Data->name(virtual_servers => [@vs_list]) ); &checkResponse($soapResponse); @persistenceprofile_listA = @{$soapResponse->result}; # SNAT $soapResponse = $LocalLBVirtualServer->get_source_address_translation_snat_pool( SOAP::Data->name(virtual_servers => [@vs_list]) ); &checkResponse($soapResponse); @snat_list = @{$soapResponse->result}; # ensure we don't pass empty entries to the following methods. @snat_list2 = &FixEmptyEntries(@snat_list); # SNAT Pool Members $soapResponse = $LocalLBSNATPool->get_member_v2( SOAP::Data->name(snat_pools => [@snat_list2]) ); &checkResponse($soapResponse); @snatmember_listA = @{$soapResponse->result}; # State $soapResponse = $LocalLBVirtualServer->get_enabled_state( SOAP::Data->name(virtual_servers => [@vs_list]) ); &checkResponse($soapResponse); @state_list = @{$soapResponse->result}; # Pools $soapResponse = $LocalLBVirtualServer->get_default_pool_name( SOAP::Data->name (virtual_servers => [@vs_list]) ); &checkResponse($soapResponse); @pool_list = @{$soapResponse->result}; # ensure we don't pass empty entries to the following methods. @pool_list2 = &FixEmptyEntries(@pool_list); # Pool Members $soapResponse = $LocalLBPool->get_member_v2( SOAP::Data->name(pool_names => [@pool_list2]) ); &checkResponse($soapResponse); @member_listA = @{$soapResponse->result}; # Member/Monitor Status $soapResponse = $LocalLBPoolMember->get_monitor_status( SOAP::Data->name(pool_names => [@pool_list2]) ); &checkResponse($soapResponse); @monitor_statusA = @{$soapResponse->result}; $soapResponse = $LocalLBPoolMember->get_object_status( SOAP::Data->name(pool_names => [@pool_list2]) ); &checkResponse($soapResponse); @object_statusA = @{$soapResponse->result}; # LB Method $soapResponse = $LocalLBPool->get_lb_method( SOAP::Data->name(pool_names => [@pool_list2]) ); &checkResponse($soapResponse); @lbmethod_list = @{$soapResponse->result}; $soapResponse = $LocalLBPool->get_monitor_association( SOAP::Data->name(pool_names => [@pool_list2]) ); &checkResponse($soapResponse); @monitor_list = @{$soapResponse->result}; # print XML print "\n"; print " \n"; print " \n"; for $i (0 .. $#vs_list) { # vip $vip = @vs_list[$i]; $pool = @pool_list[$i]; $destination = @destination_list[$i]; $vstype = @vstype_list[$i]; $snat = @snat_list[$i]; $state = @state_list[$i]; @rule_list = @{$rule_listA[$i]}; @profile_list = @{$profile_listA[$i]}; @persistenceprofile_list = @{$persistenceprofile_listA[$i]}; # pool @member_list = @{$member_listA[$i]}; @monitor_status = @{$monitor_statusA[$i]}; @object_status = @{$object_statusA[$i]}; $monitorassociations = @monitor_list[$i]; $monitor_rule = $monitorassociations->{"monitor_rule"}; $lb_method = $lbmethod_list[$i]; # SNAT @snatmember_list = @{$snatmember_listA[$i]}; $daddr = $destination->{"address"}; $dport = $destination->{"port"}; print " \n"; for $j (0 .. $#rule_list) { $rule = @rule_list[$j]; $name = $rule->{"rule_name"}; $priority = $rule->{"priority"}; print " \n"; } for $j (0 .. $#profile_list) { $profile = @profile_list[$j]; $name = $profile->{"profile_name"}; $type = $profile->{"profile_type"}; $context = $profile->{"profile_context"}; $default = $pprofile->{"default_profile"}; print " \n"; } for $j (0 .. $#persistenceprofile_list) { $pprofile = @persistenceprofile_list[$j]; $name = $pprofile->{"profile_name"}; $default = $pprofile->{"default_profile"}; print " \n"; } if ( $pool ne "" ) { print " \n"; for $j (0 .. $#member_list) { $member = @member_list[$j]; $address = $member->{"address"}; $port = $member->{"port"}; $monitorS = @monitor_status[$j]->{"monitor_status"}; $objectS = @object_status[$j]->{"object_status"}; $enabledS = $objectS->{"enabled_status"}; $status = "$MONITOR_STATUS_MAP->{$monitorS}-$ENABLED_STATUS_MAP->{$enabledS}"; print " \n"; } $type = $monitor_rule->{"type"}; @templates = @{$monitor_rule->{"monitor_templates"}}; print " \n"; for $j (0 .. $#templates) { $template = @templates[$j]; print " \n"; } print " \n"; print " \n"; } if ( $snat ne "" ) { print " \n"; for $j (0 .. $#snatmember_list) { $snatmember = @snatmember_list[$j]; print " \n"; } print " \n"; } print " \n"; } print " \n"; print " \n"; # Set /Common as active folder $soapResponse = $SystemSession->set_active_folder( SOAP::Data->name(folder => "/") ); &checkResponse($soapResponse); } &GetConfigXML(); #---------------------------------------------------------------------------- # checkResponse #---------------------------------------------------------------------------- sub checkResponse() { my ($soapResponse) = (@_); if ( $soapResponse->fault ) { print $soapResponse->faultcode, " ", $soapResponse->faultstring, "\n"; exit(); } } Tested this on version: 12.0
