The Top Ten Hardcore F5 Security Features in BIG-IP 11.6
There are 32 main features in the 11.6 release of the BIG-IP family of products and 29 of those are security features. That’s right; 91% of the features in the 11.6 release are security-related. Many of them are hardcore, infrastructure doodads that go unmentioned in press releases. This is the blog where I’ll try to give these hardcore doodads some public attention. The selection criteria is somewhat subjective because there’s no IEEE standard for hardcore. The real difficulty with this blog entry is choosing among the 29 features to select only the Top Ten Hardcore Security Features of 11.6. Number 10: DNS Firewall Services The 11.6.0 version of GTM includes two DNS security knobs for DNS firewall services. The first is Rapid Response Mode, which instructs GTM to respond more quickly in zones for which it is authoritative and then to drop the rest. The second knob is Response Policy Zones which allows for customized handling of the resolution of domain names. With RPZ, you can filter DNS queries for domains that are known to be malicious and returns custom responses that direct those queries away from the malicious domain. Brian McHenry, one of F5’s Security Solution Architects says this about the DNS Firewall services: “The world's only wire-rate application layer DNS Firewall now integrates seamlessly with an industry standard. Add to it improvements in DNS flood protection, and the fastest DNS firewall just got faster.” To read more about the RPZ, see Jonathan George’s blog here. GTM, The Global Traffic Manager, is F5’s most senior module. It is responsible for global server load-balancing and DNS services Number 9: Hardware DDoS Integration for vCMP Guests When vCMP was first developed, each virtual instance was given a slice of access to the underlying cryptographic offload and compression hardware. This feature continues the tradition by giving each virtual instance access to the underlying network DDoS hardware. Not all platforms have the chips that do this. If you want to know which platforms have it, leave a comment and one of my lovely assistants will post a follow-up. vCMP is the virtual clustered multi-processor technology and is already about as hardcore as it gets. vCMP is F5’s answer to everyone who wants the flexibility of virtualization but the performance of F5 hardware. Number 8: Geo-location-based anomaly mitigation Imagine this conversation in the war room. “Sir, we’re being attacked by Elbonia.” “Ensign, have you blocked all the traffic coming from Elbonia?” “Um, no, sir.” “Well, make it so!” That’s a conversation that need not happen with this new feature. You can now tell ASM to automatically mitigate DDoS or brute-force anomalies by the geographic location of the source. How cool is that? The Application Security Manager (ASM) is F5’s web application firewall. This is where advanced application security happens–protection against the hackers, the OWASP Top Ten, brute force, web scraping and application DDoS. Number 7: Per-request Access Policies People who have used APM know about its power to effect clientless single-signon (SSO) for web applications. But many applications perform more than one check for authorization or authentication as you navigate further. In versions prior to 11.6, APM relied on the application code and third-party IAM solutions to enforce so-called "step-up authentication." However, with v11.6, APM is now able to make multiple interrogations of the end-user in a single session, making APM a much more powerful piece of an IAM strategy. The Access Policy Manager (APM) is F5’s combo of Identity and Access Management and SSL VPN. Everything that involves authenticating users, federating their credentials and authorization of their usage belongs to the APM module. Number 6: Identity is the Perimeter Firewall Capabilities For years, everyone has been talking about how the security perimeter is changing. One of the best security models now is to define the security perimeter around the users themselves. The new User Identity firewall feature in AFM helps you do exactly that. Now you can make firewall rules specific to users or groups of users: Source user match Source user-group match Destination user match Destination user-group match An example of when you might use this would be to create a “source user-group to IP address” to allow access to your accounting servers, but only for members of the Finance group when they are coming in from the VPN or corporate LAN. The Advanced Firewall Manager (AFM) is F5’s network firewall module. It is used in enterprises, service providers and anywhere that an ADC and network firewall consolidation make sense. AFM already leads the firewall industry in network DDoS awareness and mitigation thanks to the diligence of the AFM team, which is quietly adding power features such as these: Number 5: Generic UDP Flood Vector UDP floods are tricky. The stateless nature of UDP makes it difficult to determine if any particular packet is legitimate. Sometimes a UDP attack will have a certain signature; for example, the payload will be filled with the letter ‘A’ (so unoriginal!), but sometimes a UDP attack won’t be so easy to spot. One way to detect it is to watch for a massive spike in UDP packets. That’s the job of AFM’s new UDP Flood vector. When it detects a spike in UDP traffic at a port level, it can automatically apply mitigation. That’s not the end of the story, though. One of the heaviest users of UDP is the DNS protocol, and DNS packets have to travel all through the network. When DNS gets blocked, it appears as an outage of some kind, and the IT department starts getting calls from frustrated redditors copyeditors and other cube denizens. The UDP Flood vector can whitelist DNS traffic and allow it through, even while mitigating a UDP flood around it. The "single endpoint" sweep DoS vector can be used to rate limit DNS responders that are sending too many responses back (useful for when BIG-IP itself is the target of a reflection attack). Number 4: Flow Table Sweeper Enhancements Many denial-of-service attacks target flow-tables throughout the network. For example, one of the oldest attacks, the TCP connection flood, will overwhelm the TCP stack of a firewall or host. These days, it’s not a matter of if your table will overflow, it’s when. And what should be done about it? F5’s TMOS and other defensive systems will trigger an algorithm called a sweeper to clean out (or evict) different table entries when the table starts to get full. But how should it choose? The oldest? The least busy? The slowest? This hardcore AFM feature lets you define the methods that the flow table sweeper algorithm will employ when choosing which connections to kick out when the table approaches full. Like many of the other AFM anti-DDoS features, this one should be set based on the parameters of a current attack. If your site is getting hit with a slow-and-low attack, then let the Bias:Bytes method close all those slow connections. If you are getting weird connections from all over the globe, let the Low Priority:Geos method close connections originating from low-priority regions. The flow table eviction policies can be applied on a per-virtual-server basis. This means that each virtual server can have its own max concurrent flow quota and can have a different behavior when that quota is approached. Number 3: SSL Session Mirroring Full SSL handshakes are computationally expensive. This is one of the reasons that enterprises use F5’s LTM as SSL decryption mechanisms. Suppose you are lucky enough to have a site with a lot of SSL traffic. What if something happens and your primary ADC stops receiving traffic and the secondary has to pick up all those active connections? You want the secondary to perform cheap resumption handshakes (based off a shared session ID cache) with all the clients instead of full handshakes. You can now share SSL session ID caches across traffic groups so that failovers won’t cause massive spikes in full SSL handshakes. The Local Traffic Manager (LTM) is the base module that does all the fundamental application delivery. It also hosts all the SSL decryption code, which makes it the strategic point of control in SSL for the majority of F5 customers. Number 2: OCSP Stapling The Achilles’ heel of the public key infrastructure has always been revocation, i.e. how can the system reject certificates that have been compromised? The Online Certificate Status Protocol (OCSP) was developed to solve this problem. Interested parties can query a special OCSP server for the real-time status of a certificate. Unfortunately, as Google’s Adam Langley explains in his blog, OCSP can work for private networks, but it is suboptimal at best for a global Internet solution. OCSP Stapling is the tweak that might save the integrity of the system. LTM can now staple the certificate status into each SSL connection that it serves so that interested parties can assure themselves that the a certificate is still good. Okay, we’ve covered 9 different hardcore features so far. I know you’re thinking how could there be anything more hardcore than OCSP Stapling? Before we reveal the number one most hardcore feature, let’s have a look back at those first nine: The Top Ten Hardcore F5 Security Features in 11.6 GTM 10 DNS Firewall Services vCMP 9 Hardware DDoS integration for vCMP Guests ASM 8 Geo-location-based anomaly detection and mitigation APM 7 Per-Request Access Policies AFM 6 User-Identity firewall capabilities 5 Generic UDP Flood Vector 4 Flow Table Sweeper Enhancements LTM 3 SSL Session Monitoring 2 OCP Stapling 1 External Crypto Offloading And the number one hardcore security feature of 11.6 is… Number One: External Crypto Offloading We don’t normally trash-talk competitors (we don’t have to). But Cloudflare’s recent “invention” of what they call “Keyless SSL” had a lot of us security professionals scratching our heads. F5 had been offloading crypto to external devices such as nCipher and Thales for almost two years already. So had Amazon. Everyone who really does global SSL already knew about this technology. Maybe they are out of touch over there at Cloudflare and just doing their own thing. That’s fine. I hope they don’t try to patent that stuff, because nCipher and Thales probably got there first, years and years ago. So Cloudflare, welcome to the party. The concept is pretty simple: have one device, either on-premises or elsewhere, perform most SSL operations such as bulk decryption, but offload the private-key operations to another device. That other device can be a nCipher or Thales network-attached hardware security module (NetHSM devices) or it could be an F5 physical appliance stuffed with high-performance cryptographic chips. You can now spin up cheap, fully-virtualized services that direct traffic but don’t need possession of a high-security key. Brian McHenry would also put this feature near the top of his list. He says that external crypto offloading is “…incredibly innovative…. The applications for this technology are incredibly powerful for emerging hybrid architectures. It could enable a whole new wave of micro-architectures where SSL was previously a non-starter due to management and performance issues." Honorable Mentions Several of the features almost made the Top Ten and deserve at least an honorable mention. WAF CAPTCHA (ASM) – The World’s Best Web Application Firewall can now throw back a user challenge in the form of a CAPTCHA if it suspects that user of trying to brute force or Dos a service. TLS Extension support for NPN and ALPN (LTM) – These two critical SSL/TLS extensions are now supported. Next Protocol Negotiation (NPN) and the Application Layer Protocol Negotiation (ALPN) help support Google’s SPDY protocol. Conclusion So there we are: a dozen hardcore security features in 11.6. If you feel inspired and want to learn more, download 11.6 today and start playing with it. See the 11.6 Release Notes for the complete list of security (and other) features and of course, stay hardcore.
BIG-IQ Grows UP [End of Life]
The F5 and Cisco APIC integration based on the device package and iWorkflow is End Of Life. The latest integration is based on the Cisco AppCenter named ‘F5 ACI ServiceCenter’. Visit https://f5.com/cisco for updated information on the integration. Today F5 is announcing a new F5® BIG-IQ™ 4.5. This release includes a new BIG-IQ component – BIG-IQ ADC. Why is 4.5 a big deal? This release introduces a critical new BIG-IQ component, BIG-IQ ADC. With ADC management, BIG-IQ can finally control basic local traffic management (LTM) policies for all your BIG-IP devices from a single pane of glass. Better still, BIG-IQ’s ADC function has been designed with the concept of “roles” deeply ingrained. In practice, this means that BIG-IQ offers application teams a “self-serve portal” through which they can manage load balancing of just the objects they are “authorized” to access and update. Their changes can be staged so that they don’t go live until the network team has approved the changes. We will post follow up blogs that dive into the new functions in more detail. In truth, there are a few caveats around this release. Namely, BIG-IQ requires our customer’s to be using BIG-IP 11.4.1 or above. Many functions require 11.5 or above. Customers with older TMOS version still require F5’s legacy central management solution, Enterprise Manager. BIG-IQ still can’t do some of the functions Enterprise Manager provides, such as iHealth integration and advanced analytics. And BIG-IQ can’t yet manage some advanced LTM options. Never-the-less, this release will an essential component of many F5 deployments. And since BIG-IQ is a rapidly growing platform, the feature gaps will be filled before you know it. Better still, we have big plans for adding additional components to the BIG-IQ framework over the coming year. In short, it’s time to take a long hard look at BIG-IQ. What else is new? There are hundreds of new or modified features in this release. Let me list a few of the highlights by component: 1. BIG-IQ ADC - Role-based central Management of ADC functions across the network · Centralized basic management of LTM configurations · Monitoring of LTM objects · Provide high availability and clustering support of BIG-IP devices and application centric manageability services · Pool member management (enable/disable) · Centralized iRules Management (though not editing) · Role-based management · Staging and manual of deployments 2. BIG-IQ Cloud - Enhanced Connectivity and Partner Integration · Expand orchestration and management of cloud platforms via 3rd party developers · Connector for VMware NSX and (early access) connector for Cisco ACI · Improve customer experience via work flows and integrations · Improve tenant isolation on device and deployment 3. BIG-IQ Device - Manage physical and virtual BIG-IP devices from a single pane of glass · Support for VE volume licensing · Management of basic device configuration & templates · UCS backup scheduling · Enhanced upgrade advisor checks 4. BIG-IQ Security - Centralizes security policy deployment, administration, and management · Centralized feature support for BIG-IP AFM · Centralized policy support for BIG-IP ASM · Consolidated DDoS and logging profiles for AFM/ASM · Enhanced visibility and notifications · API documentation for ASM · UI enhancements for AFM policy management My next blog will include a video demonstrating the new BIG-IQ ADC component and showing how it enhances collaboration between the networking and application teams with fine grained RBAC.Monitoring BIG-IP on Microsoft’s System Center with the Comtrade Management Pack for F5 BIG-IQ
Comtrade has released a Management Pack (MP) for Microsoft Systems Center (SCOM ) that uses F5’s BIG-IQ to monitor F5 BIG-IP devices and the applications they are helping deliver. The MP allows users to view all BIG-IP objects and see key information about their performance and health. This management pack will be of great interest to all customers using Microsoft Systems Center. What are the requirements for this solution? Microsoft System Center Operations Manager 2012 or Microsoft System Center Operations Manager 2012 SP1 or Microsoft System Center Operations Manager 2012 R2 F5 BIG-IQ 4.3.0 or BIG-IQ 4.4.0 Comtrade F5 BIG-IQ MP requires .NET Framework version 3.5 SP1 installed TCP 443 opened to the BIG-IQ devices Administrator account in BIG-IQ What is available in the MP? Discovery, visualization and dynamic update of F5 BIG-IQ appliances topology Discovery of F5 BIG-IQ appliance objects BIG-IQ Tenants Catalogs – Applications Virtual Servers BIG-IP Devices Cloud Connectors Nodes CPU Memory Disk Partitions SSL Certificates What will the MP Monitor? BIG-IQ (Availability, CPU utilization, Disk partition available space, Disk partition utilization, memory utilization) BIG-IP (Availability, CPU utilization, Disk partition available space, Disk partition utilization, memory utilization) Cloud Connectors (Cloud connector availability) Tenants iApp Catalogs – Applications (Application availability status, application’s active member count) Virtual Servers (Virtual server availability, server-side connection number for virtual server, client-side connection number for virtual server) Nodes (Availability of tenant nodes, server-side number of connections on nodes for port 80, server-side number of connections on nodes for port general, total number of connections on nodes) BIG-IQ SSL certificates (Availability and validity) Statistics BIG-IQ (CPU utilization, memory utilization, disk partition free space and utilization) BIG-IP (CPU utilization, memory utilization, disk partition free space and utilization) Tenants Catalogs – Applications (application availability and active members) Virtual Servers (server-side connection number on virtual servers, client-side connection number on virtual servers) Nodes (server-side connection number on node port 80, server-side connection number on node port general, server-side in-packets on node port general, server-side out-packets on node port general, server-side bits-in on node port general, server-side bits-out on node port general) Views (Diagram, Alert, State and Dashboard) How it works – main steps? 1. Comtrade F5 BIG-IQ is installed on one SCOM Management Server. The installation provides the MP and Comtrade MPBIG-IQ Agent. The agent is used for communicating with the REST API of F5 BIG-IQ. 2. Comtrade MPBIG-IQ Agent is installed on every SCOM Management server that will participate in the BIG-IQ monitoring. SCOM Management Servers are designated trough Resource Pool in SCOM. 3. Create an SNMP based Network device discovery and include the BIG-IQ IP address. Create a new SCOM Resource Pool. Assign the discovery to the Resource Pool. 4. Create Run As account and enter the account with administrator rights for the BIG-IQ device/s. For distribution choose more secure and add the resource pool. 5. Assign the run as account to F5 BIG-IQ Appliance Action Account profile. With these easy steps you are ready for monitoring. Here are some screenshots to give you more detailed view for the solution: Figure 1: Diagram View (Topology) of BIG-IQ infrastructure Figure 2: BIG-IP appliance and its components being monitored Figure 3: Tenants & Applications dashboard view Figure 4: View of all active alerts for BIG-IQ Figure 5: Alert details offers additional information about the issue Figure 6: On demand monitoring – Health recalculation Figure 7: Administration View Here is also a good video that shows the installation and configuration steps as well as overview: Product video: http://www.youtube.com/embed/yAhBk8cSPn0 Product page: www.comtradeproducts.com/f5 Microsoft Blog about the MP for F5: http://www.systemcentercentral.com/sneak-peak-at-comtrade-management-pack-for-f5-big-iq/
Software Defined Transformation - Management and Orchestration with F5 Synthesis
In this article we will look at how F5 continues to deliver the Management and Orchestration solutions for deploying Application Delivery Controller (ADC) platform services. We will begin with explaining how F5 approached Management solutions and how rapidly it developed to prepare for the Software Defined transformation within customer datacenters. Having interacted with over 100 major accounts in 2014 (global Enterprises and Service Providers), I've had the privilege of sharing these ideas and validate with their feedback. As an F5 customer, this article will benefit you in understanding why Management and Orchestration is a critical pillar of the F5 Synthesis architecture. Application deployments and datacenter architectures are also rapidly evolving to a point where F5 Synthesis can help you compare the value F5 offers. As a solution delivery partner, you can learn more about how F5 integrates with OpenStack, Cisco, Vmware, and Microsoft technologies to help you deliver Software Defined Networking (SDN) and Network Function Virtualization (NFV) projects for your clients. Back in the days... F5 launched its Synthesis architecture framework for application delivery services in early 2014. It marked an important milestone for the vision defined over a decade ago. Early on, F5 focused on the application delivery services Management solution as a combination of tools aligned with the target audience. Most network administrators preferred command line interface (CLI) tools, and so F5 developed a shell interface called TMSH. Some administrators preferred a graphical user interface (GUI), and so F5 developed the Enterprise Manager solution. F5 also offered the iControl APIs for administrators not afraid to write some code to programmatically configure and deploy application delivery services. Customers have used all these tools and developed their ADC operations manual and automation scripts. I was delighted to discover how widely these tools are being used. Some customers have even built their own management interfaces (GUI) using TMSH commands and iControl APIs. Customers with scripting and development skills available within IT teams preferred using iControl and TMSH. Customers with a smaller devices footprint preferred using the Enterprise Manager solution. With this backdrop, let us now look at how our next generation Management and Orchestration platform, F5 BIG-IQ, helps our customers prepare for the Software Defined transformation within their datacenters. Fundamental shifts underway... As recent as 3 years ago, network device management platforms were considered as monolithic vendor solutions for managing their software and hardware platforms. IT teams were expected to purchase the relevant vendor management products, resulting in over 2-dozen tools deployed for managing a complex infrastructure. This is true even today, but something started to change with the talk of programmable infrastructure services. The first shift was the popularity of REST APIs. With the rise of AWS and developers being able to provision infrastructure services via APIs, IT began to research similar capabilities for existing products and solutions deployed in-house. API driven orchestration started to gain interest. As a result, IT now looks at Management as not just a pretty GUI, but a comprehensive set of REST APIs as well. In every customer meeting, I was often asked “Do you have a REST API for that?” The second shift happened when IT decided to separate the task of provisioning and managing – i.e. separating the rollout out of new infrastructure services via orchestration from performing day to day management functions. Automation and Orchestration using REST APIs is rapidly becoming the norm. Many of the customers I visited have recruited software engineers to build their next-generation automation and orchestration toolbox. They are not only using the packaged cloud management platforms (of course, with API access), but also adopting platforms like Puppet, Chef, Ansible, and sometimes developing Python and Perl based scripts. In 2012 and 2013 most of the IT conversations about SDN and NFV were focused on protocol standardization and vendor support. It was primarily a white-board discussion and getting to an architectural blueprint was not yet possible. Beginning of 2014 saw some of that change. I was asked about F5's support for OpenStack Neutron, Cisco APIC, VMware NSX and most recently, Microsoft HNV. Customers were beginning to draw the blueprints and wanted to evaluate where F5 fits. Financial budgets were being committed and IT teams were preparing to embrace SDN/NFV for bringing programmability to infrastructure services deployment. The discussion changed from protocol support to the availability of REST APIs. It seemed like IT Networking professionals were converging on choosing APIs over protocols. This fitted nicely with how F5 has approached network services programmability. F5 is committed to supporting relevant standard protocols and while they evolve, F5 will provide REST APIs to enable programming of the ADC services. I have witnessed these shifts inside most of F5’s major accounts. Their F5 BIG-IP footprints have grown significantly. With rising highly available deployments (active-standby and active-active clusters), customers are now looking for more programmatic control over the entire BIG-IP fleet for lifecycle management and rapid provisioning of services. This is different than just scripting iControl APIs based on device-by-device configuration changes. Customers are now looking to have a central control point (i.e. central authority), with orchestrated provisioning of services. Customers with large-scale global datacenter footprints also expect distributed intelligence versus centralized intelligence (more on that in a future post). Orchestration becoming mainstream... Building on the iControl API approach, F5 baked the vision for BIG-IQ Management and Orchestration to address the shifts described above. With BIG-IQ, F5 plans to transform the monolithic management product approach to a programmable platform with target audience specific components (called Modules). The unique aspect of this vision is to provide API parity for everything that an IT administrator can do in the GUI. As a result, IT can get trained on the GUI and as complexity evolves, automate tasks using the APIs. By having access to APIs, IT can also enforce separation of duties (who does what and audit actions) and implement governance policies in line with business and regulatory requirements. Trying to capture the complexity of this in Management GUIs, without APIs, is akin to fighting a losing battle. F5 knows that APIs help win the complexity war, and hence focused on providing REST APIs for everything. Furthermore, REST APIs are the key to unlock the benefits of the Software Defined transformation within datacenters. Orchestration on top of device and software provisioning helps IT transform their datacenter to a programmable infrastructure. By providing REST APIs and iApps based configuration templates, F5 enables this transformation. Further, by focusing on integrations with third party platforms like OpenStack Neutron, Cisco APIC, VMWare NSX, and Microsoft SCVMM/HNV - F5 continues to offer a flexible solution that will work with whatever SDN/NFV approach the customer chooses. It is important to highlight this aspect of F5's thinking, which separates F5 from how others think about automation and orchestration. Your key takeaway is this: F5 is committed to providing control of BIG-IP configuration and policy definitions using device specific and centralized REST APIs, enabling the kind of flexibility required for rolling out software defined application services. With BIG-IQ iControl APIs, F5 helps customers get started on automating common tasks and redeem the time spent on manual operational tasks performed week after week. With the SDN/NFV integrations for OpenStack, Cisco, Vmware, and Microsoft – F5 will continue to enable choice in how to adopt Software Defined architectures for datacenter transformation. Management under rapid development... Customers expect F5 to deliver robust management capabilities that enable ease of use for all of their BIG-IP software modules. With centralized management focus in BIG-IQ, F5 is on track to deliver on that expectation. In 2014, F5 delivered the management functions for BIG-IP device lifecycle, licensing, device monitoring, firewall policies, and configuration backup/restore capabilities. The recently launched BIG-IQ 4.5 release begins to deliver object level management for BIG-IP traffic management capabilities and better control over BIG-IP security policies. In addition to robust configuration management, customers also expect a comprehensive role based access control (RBAC) framework for implementing IT governance. With BIG-IQ RBAC, customers can begin to satisfy some of these needs. Starting today, customers can use BIG-IQ to leverage the network administrator role to create configuration objects for the entire deployment, and allow the application administrator role to control their piece of the configuration. Network administrators can also view all their BIG-IP iRules from a central location and attach/detach iRules for configuration changes. Application administrators can now control the lifecycle of their BIG-IP virtual servers, virtual IP addresses, pools, and monitor the health of those services. Security administrators can also delegate control over the firewall rules and enable visibility into how the rules are enforced. With focus on simplifying BIG-IP policy changes using iApps, BIG-IQ also helps customers catalog and deploy iApps. Customers using iApps report significant savings in provisioning and configuration rollouts across multiple BIG-IPs. Customers also expect a single pane of glass interface for their entire BIG-IP deployment across multiple datacenters. They want to see the inventory of all their BIG-IP instances (physical and virtual) and view the health monitors. F5 BIG-IQ enables that with visibility into active-standby and an active-active clusters for BIG-IP traffic management functions. BIG-IQ itself can also be deployed in a high-availability configuration using active-active and active-standby modes (depending on the BIG-IP modules being managed). F5 BIG-IQ is our long term strategic investment and the roadmap is packed with capabilities that will address established and emerging ADC services deployment scenarios. Call to action… I thank our customers for helping us jointly define and begin delivering solutions that address critical pain points. While we continue to develop BIG-IQ, you can continue to use the Enterprise Manager, TMSH, and iControl based solutions per your needs. If you need information on when to use Enterprise Manager and when to use BIG-IQ, please contact your regional sales account manager to start the conversation. We’re ready to support you in deploying BIG-IQ for addressing some of the Management and Orchestration scenarios described in this article. Please share your questions on this forum or reach out to your regional sales account manager and field services engineer. We’d love to hear from you on how we can enhance our BIG-IQ solution per your needs.Implementing Lightweight East-West Firewalls with F5
In 2005, perpetual diva Miss Piggy portrayed all four of the directional witches (North, South, East and West) in Jim Henson’s Muppet’s Wizard of Oz. Despite a vigorous and, occasionally violent, performance, she was snubbed at the Academy Awards, ultimately losing out to Reese Witherspoon (Walk the Line). Maybe the Academy Awards voters understood this key principle that escaped our porcine starlet: East and West are fundamentally different from North and South. This is certainly true for the modern enterprise datacenter architecture. When you look at an architectural diagram of a single datacenter, the Internet is at the top (North) and users at the bottom (South). In between are the DMZ and services. These services are applications, virtualized servers and databases and they communicate with each other laterally (often portrayed west to east). N-S networking is considered the traditional perimeter and the conventional home of giant firewalls. E-W is the home of virtualized services, and sometimes N-S security teams don’t get invited to play in the sandboxes. So E-W traffic can be left unguarded. But it shouldn’t be that way; network policy can be implemented quickly with the F5 load-balancers already in place. Let’s take a look at an example E-W layout. Security in an East-West Network Security Traffic is flowing from the web servers east-ward through a middleware cluster and ultimately to the database cluster at the east end. All good. There should never be traffic going from the web servers to the development network, right? Web servers are a huge threat surface: when they get hacked we don’t want the attackers to be able to get into the intellectual property in development. The same goes for the middleware network, it should only talk to the database cluster network. And connections from the database cluster should never go into the development network either. Let’s redraw the diagram with the red lines to indicate connections that we want to prevent. So how can we implement this in a way that doesn’t disrupt everything or require new hardware? Lightweight Firewall Rule for Web Apps Cluster via F5 In the example above, there is an F5 application delivery controller (ADC) in between the web applications and middleware and another in front of the database cluster. Suppose the ADCs are providing simple load balancing for the application traffic running west to east. The web servers are the most interesting section of the architecture. They accept traffic from the Internet (via the ADC) and are typically configured to use the ADC as their default gateway. About the default gateway: historically,the ADC has always passed the original client IP address to the web server for logging purposes. The web server then has to use the ADC as the default gateway when it replies back the client (otherwise the traffic would go around the ADC, and that doesn’t work for proxy and cache services). On the F5 we’ll create three VLANs and virtual server objects to represent the three types of flows that we’re looking for. web-app1 : inbound traffic to web application. middleware : eastbound requests into middleware web-gw : default gateway traffic (mostly traffic from web-pool) The web-app1 virtual server defines a single public address for inbound web traffic to our application. net vlan internet { } ltm virtual web-app1 { description "internet to web app" destination 71.237.39.99:http pool web-pool profiles { http { } tcp { } } vlans { internet } } Because the web servers are accepting routable IP addresses (see sidebar), they have their default gateways set to a wildcard virtual server at the F5. The return traffic will be matched to the incoming flows. net vlan web { } ltm virtual web-gw { description "gateway to middleware" destination 0.0.0.0:any fw-enforced-policy web-gw profiles { fastL4 { } } source 192.168.2.0/24 translate-address disabled translate-port disabled vlans { web } } Web Servers: 192.168.2.0/24 Middleware: 10. 0.0.0/8 Development: 20.0.0.0/8 Database Cluster:172.16.0.0/16 Notice the destination 0.0.0.0:any. This is necessary to allow the webservers to communicate to the outside world. But suppose that an attacker got a shell on the web-server. He could then use the wildcard server to tunnel through to the development network (20.0.0.0). Not what we want. So we define a lightweight firewall rule (fw-enforced-policy web-gw) to prevent packets from getting into the development network. security firewall policy web-gw { rules { w-to-m { action reject description "Disallow development" log yes destination { addresses { 20.0.0.0/8 { } } } } } } Here’s what that rule looks like in the GUI. We’re not specifying the source network because this is only enabled on the “web” VLAN anyway (and therefore wouldn’t be acting on other traffic). Lightweight Firewall Rule for Middleware Cluster via F5 The middleware virtual server defines a single address for the web servers to communicate to a pool of middleware servers. ltm virtual middleware { description "webapp to middleware" source 192.168.2.0/24 destination 192.168.2.202:7001 pool mid-pool profiles { tcp { } } vlans { web } } The middleware virtual server has a source network specification which will act as a firewall rule all by itself. Only traffic originating from the web network will be able to pass through to the middleware cluster. It doesn’t get much more lightweight than this. If we want to prevent connections originating from the middleware tier cluster westward to the web app cluster, we can define a global firewall rule to handle this. Note that we leave a “hole” for development to push to the web app cluster. Lightweight Firewall Rule for Database Cluster via F5 The right-hand F5 ADC will very similar to the left-hand ADC. For our simple example, we have a virtual server balancing to a single pool of database servers and they should only be accessed from the middleware. Just as we did for the web app cluster, we can use the source and destination attributes of the virtual server to create an east-bound flow. ltm virtual mid-to-db { description "middleware to database" source 10.0.0.0/8 destination 10.10.10.10:3306 pool db-pool profiles { tcp { } } vlans { middleware } } We’ll also add a global firewall rule to prevent connections originating from the database cluster back toward the middleware or development. Add one exception: every Saturday night from 8PM to midnight the database clusters will be allowed to access the Internet to pull down updates. Is that Lightweight enough for you Miss Piggy? “Hiiii-yaaah!” See how easy and lightweight that was? Much of the security enforcement is already bound into the definitions of the virtual server objects themselves, leaving us with just handful of global firewall rules. Full disclosure here: I simplified this configuration a little bit for clarity. The full configuration is larger and you’d probably have a SNAT pool in between the clusters where default gateways are used. But hopefully you get the gist that it is possible, with relatively little effort, to attach lightweight firewall rules to manage the east-west traffic in your datacenter.
Hourly Licensing Model – F5 delivers in AWS Marketplace
#cloud #SDAS #AWS And you can try it out for free... June 30, 2014 (The Internet) Today F5 Networks, which delivers solutions for an application world, announced it had completed jumping through the hoops necessary to offer an hourly (utility) billing model for its BIG-IP VE (Virtual Edition) in the Amazon Web Services (AWS) cloud. Not only has F5 announced availability of the industry's leading application delivery services for deployment in AWS with a utility billing model, but the offering includes a variety of options which organizations can take advantage of: Three sizes of BIG-IP VE including 25 Mbps, 200 Mbps and 1Gbps. Two BYOL (Bring Your Own License) options as well as a modular option A free 30 day trial offering with Best licensing and 200 Mbps of throughput BIG-IP VE for AWS includes not only the industry's most trusted load balancing service but also the following capabilities and Software Defined Application Services (SDAS) designed to protect and enhance application security and performance: An integrated WAF (Web Application Firewall) DDoS Protection Caching, compression and acceleration Advanced Load Balancing Algorithms including least connections and weighted round robin. Additionally, BIG-IP VE for AWS supports the use of iApps for rapid provisioning in the cloud or on-premise. iApps are application-driven service templates that encapsulate best practice configurations as determined by lengthy partnerships with leading application providers as well as hundreds of thousands of real deployments across a broad set of verticals including 94% of the Fortune 50. The availability of BIG-IP VE for AWS further supports F5 Synthesis' vision to leave no application behind, regardless of location or service requirements. Through Synthesis' Intelligent Service Orchestration, organizations can enjoy seamless licensing, deployment and management of F5 services across on-premise and cloud-based environments. The availability of BIG-IP VE for AWS extends F5 service fabric into the most popular cloud environment today, and gives organizations the ability to migrate applications to the cloud without compromising on security or performance requirements. To celebrate this most momentous occasion you can try out BIG-IP in the AWS marketplace for free (for 30 days) or receive $100 credit from AWS by activating participating products between July 1 and July 31, 2014: These offers apply to the F5 BIG-IP Virtual Edition for AWS 200Mbps Hourly (Best) through AWS Marketplace: 30 Day Free Trial Available The BIG-IP Virtual Edition is an application delivery services platform for the Amazon Web Services cloud. From traffic management and service offloading to acceleration and security, the BIG-IP Virtual Edition delivers agility - and ensures your applications are fast, secure, and available. Options include: - BIG-IP Local Traffic Manager, Global Traffic Manager, Application Acceleration Manager, Advanced Firewall Manager, Access Policy Manager, Application Security Manager, SDN Services and Advanced Routing, including support for AWS CloudHSM for cryptographic operations and key storage. AWS – Offer (Credit) Customers who activate a free trial for any participating product (that includes F5 BIG-IP) between July 1 and July 31, 2014 and use the product for a minimum of 120 hours before August 31, 2014 , will receive a $100 AWS Promotional Credit. Limit two, $100 AWS Promotional Credits per customer; one per participating software seller. . For more information: F5 Synthesis F5 Solutions Available in the AWS Marketplace F5 BIP-IP Virtual EditionsFull Stack Security
When talking to someone who’s spent a lot of time around F5 technology, two words always come up: full-proxy and platform. BIG-IP is the platform of services offered by a full, dual-stack proxy. The proxy yields unmatched visibility and control at every layer of the connection stack, beginning at the network level to the TCP stack, the SSL stack, and then the application layer. When architecting solutions with BIG-IP Advanced Firewall Manager (AFM), this dual-stack full-proxy design differentiates itself among other security solutions. Since AFM is fully-integrated into TMOS, the performance overhead for the DDoS and other layers 3 & 4 is very low. Unlike flow-based network firewalls, BIG-IP AFM is able to fully inspect and control the client-side TCP handshake before reassembling the request and establishing the server-side TCP connection. In this way, AFM protects not only the server-side network, but the rest of the BIG-IP platform. So far, it’s becoming clear what makes BIG-IP a full-proxy security solution, but what makes it a platform? In technology, a platform is able to provide multiple services and capabilities in a well-integrated fashion. Where AFM provides layer 3 & 4 security services, the layer 7 services fall mostly elsewhere in the BIG-IP platform. For our purposes today, we’ll focus on BIG-IP Application Security Manager (ASM) and the ability to augment the DoS-mitigation functions of AFM with greater DoS and other L7 security for HTTP-based application traffic. Almost all HTTP applications will be encrypted via TLS before too long, so let’s first take note of the SSL stack on BIG-IP. The topic of configuring SSL profiles on BIG-IP for better SSL Labs scores and stronger encryption has been covered at length on DevCentral in recent years. Since the proprietary SSL stack on BIG-IP is easy to configure to enforce good, strong encryption, any vulnerable or obsolete TLS settings on the application server environment is effectively protected. The BIG-IP crypto stack is not only hardened with the latest cryptographic standards, but it is also highly optimized for performance whether accelerated by specialized chips on BIG-IP or VIPRION hardware or virtualized on your hypervisor of choice. This provides effective protection for scaled attacks, such as SSL floods. As with all things BIG-IP, the extensibility and adaptability of iRules applies to SSL, as well. (Jason Rahm will be covering iRules extensibility for AFM later this week). Once the SSL handshake has been validated, thenext stop along the full stack is the HTTP protocol inspection. Within Local Traffic Manager (LTM), there are various HTTP profile settings for inspecting each HTTP request. Security features such as header sanitization, cookie encryption, and size/length enforcement are all available before visiting more advanced HTTP inspection and enforcement capabilities found in both AFM and ASM. Protocol level enforcement of HTTP traffic is available in AFM, providing protection such as evasion technique detection, RFC compliance checks, and more advanced blocking and alarming for different HTTP attack conditions than is found the LTM HTTP profile. These HTTP protocol security enforcements are also present in ASM, but whether they are licensed or configured via AFM or ASM, the same high performance protocol enforcement engine built into the TMOS is employed. Many of these protocol security settings are useful in environments where the a full-blown WAF policy may not be applicable, whether because the application team isn’t participating in more comprehensive policy creation or because some application flows are less-sensitive or lower priority. If more advanced L7 inspection is required, then ASM is prescribed. The inspection engine in ASM is able to evaluate each HTTP request for matching attack signatures in the entire request, including the headers, URL, parameters, and data payload. There are multiple ways to configure WAF policy on ASM, including vulnerability assessment import, automated Policy Builder, and pre-loaded policy templates. Application Security Manager is no mere WAF, though. ASM also includes an array of advanced bot detection techniques, covered on DevCentral in the past by John Wagnon. Bots can’t be effectively detected and mitigated by IP address blacklisting alone, and only a full-proxy can effectively inject the various JavaScript and other countermeasures employed by ASM. In v12 of TMOS, bot detection is further enhanced with what’s known as Proactive Bot Defense, which enables more advanced fingerprinting of potential bots. Bot detection and mitigation is vital to L7 DoS defense, as almost all L7 DoS attacks are highly-automated by attackers. When Full Stack Securityis required, the BIG-IP full-proxy security platform is uniquely positioned to provide that security with great depth of control as well as massive scale. The platform-level integration provides the scale and integration for policy to be discretely configurable at each layer, from Layer 3 all the way to Layer 7. Each layer of policy, in turn, protects the platform itself, demonstrating the efficiency of the integration found on BIG-IP.실제 DDoS 스토리들: SSL 커넥션 플러드
Adapted from David Holmes' "True DDoS Stories: SSL Connection Flood" 서버에서의 SSL 터미네이션 어떤 유명기업의 중요 사이트가 매우 심각한 DDoS 공격을 받아 수 주 동안 다운되는 사태가 발생했는데, 아래 그림은 그 기업의 네트워크 레이아웃을 나타낸 것이다. 경쟁업체들과는 다르게 이 기업은 SSL 트래픽이 그대로 데이터센터 내부에까지 도달해, 애플리케이션 서버에서 터미네이트 되는 구조를 가지고 있었다. 우리는 SSL 트래픽이 ADC에서 터미네이트 되도록 해야지 안전하고 바람직하다는 점을 누차 계속해서 주장해왔지만 여기서는 그 점에 대해서는 다시 설명하지 않겠다. 이 사이트의 경우, 클라이언트(고객)에 의해 발생된 SSL 연결은 사라지기 전에 (timeout 과정에 들어가기 전에) 일정 시간 동안 액티브(active) 상태로 남아 있어야 한다는 것이 서비스 제공업체와의 서비스계약에 명시되어 있었다. 공격 공격자의 신원은 아직도 밝혀지지 않았지만, 공격을 당한 이 기업은 어나니머스 (Anonymous)를 범인으로 의심하고 있다. 공격자가 누구든 간에 이들은 수 천 개의 합법적인 SSL 연결을 열면서 공격을 시작했다. 이 연결들은 DDoS 방지 시스템을 통과해 로드밸런서에 도달했고, 그리고 방화벽과 IPS를 통과해 애플리케이션 서버들에 도달한 후, 세션을 설정하고 그제서야 (길게 설정된) 타임아웃 과정이 시작되었다. 이 SSL 세션들은 그 안에 Payload (실제 화물, 여기서는 연결 세션 안에 포함된 정보 비트들을 의미함)를 포함하지 않고 있었으며, 클라이언트 사이드에서 종료되지 않았다. 이것은 커넥션 플러드 공격의 전형인데, 단지 합법적으로 구축된 SSL 세션 내에서 발생했다는 점이 다를 뿐이다. 애플리케이션 서버군은 부하를 충분히 감당할 수 있도록 구축되어 있었기에, 속이 빈 SSL 세션의 수는 수백만 개까지 늘어났다. SSL이 뒷 단의 애플리케이션 서버에서 터미네이트 되는 구조이기 때문에, 앞 단의 디바이스들 중에서 동시에 처리할 수 있는 접속의 개수가 가장 적은 디바이스가 먼저 다운될 것이고, 이 경우에는 로드밸런서가 그런 디바이스였다. (참고로 F5의 경쟁업체 중 하나가 제공한 제품인데, 여기서 그 경쟁업체의 이름은 밝히지 않겠다.) 다른 많은 디바이스들처럼 이 로드밸런서는 자신이 처리할 수 있는 동시 연결의 최대치에 도달하자 완전히 작동을 멈추고 트래픽 처리를 중지했다. 보통의 경우 로드밸런서는 공격하는 트래픽 부하를 액티브 서버들에 나누어 분산을 하기 때문에 DDoS 공격을 완화시키는 기능을 하지만, 그것은 규모가 작은 공격일 경우의 얘기이고 이 경우에는 로드밸런서가 가장 약한 부위가 되어버린 것이다. 대개의 경우는 방화벽이 가장 먼저 문제를 일으키는 것이 보통이다. 공격은 수 주일간 계속되었고 이 DDoS 공격이 멈추기 전까지 서비스는 재개되지 못했다. 바람직하지 못한 방어전략 #1 – (한 지점만 해결하는) 포인트 솔루션들 Arbor, Prolexic, 그리고 (이제는 단종된) 예전의 Cisco Guard 제품 등 DDoS 방어 솔루션을 제공한다고 주장하는 업체들이 몇몇 있다. 위 고객이 어떤 업체의 솔루션을 사용하고 있었는지 밝히지는 않겠지만, 어쨌거나 중요한 점은 도움이 되지 못했다는 것이다. 위에서 말한 어떤 솔루션도 SSL을 터미네이트 하지 않기 때문에 SSL 커넥션 플러드 공격에는 장님이나 마찬가지이다. SSL을 애플리케이션 서버에서 터미네이트하는 아키텍처를 고집하겠다면, 한 시간당 6,000 달러를 서비스제공업체에 지불하고 클라우드-기반 스크러빙을 이용할 수 있지만 도움이 되지 않을 것이다. 설혹 클라우드-기반 서비스가 SSL을 터미네이트 하더라도 금융기관들은 이 서비스를 사용할 수 없는데, 이 방법은 암호화되지 않은 트래픽을 다른 회사의 클라우드로 전송하는 것을 의미하기 때문이다. 대부분의 금융회사들은 이런 것을 금지하는 내부정책을 가지고 있다. 바람직하지 못한 방어전략 #2 – 더 많은 수의 약한 링크들 고객들과 통합된 보안솔루션에 대해 얘기를 해보면, 종종 듣는 공통된 반론 중 하나가 “우리는 모든 달걀을 한 바구니에 담기를 원치 않기 때문에 단일 벤더를 신뢰할 수 없다”는 것이다. 이 논리야말로 이 전략이 가지고 있는 위험성을 잘 보여주는 예이다. 문제는 모든 달걀이 한 바구니에 담겨있다는 점이 아니고, “어디가 가장 약한 링크인가?”이다. 수많은 달걀 중에 하나가 부서지는 것은 그리 큰 문제가 아니나 길게 연결된 사슬에서 고리 하나가 부러지면 사슬 전체가 소용없게 되어버린다는 것이 문제이다. 아키텍처 상의 이점으로 디바이스들이 널리 퍼져 있는 형태를 원한다면, 이 사슬 상에 있는 모든 디바이스들이 공격을 견뎌낼 수 있도록 확실히 해야만 한다. 더 많은 수의 디바이스가 있다는 것은 더 많은 수의 취약한 링크가 있다는 것과 동일한 것이다. 적절한 방어전략 – 풀-프록시 (Full Proxy) 만약 위 회사가 유휴 연결을 제거하는 Dynamic Reaping 기능을 가진 풀-프록시 아키텍처를 채용하고 있었다면 이런 공격을 충분히 방어할 수 있었다. SSL 터미네이션 기능이 있는 지능적인 풀-프록시 ADC는 (대개의 경우 HTTP 데이터인) 애플리케이션 페이로드(payload - 부하, 정보 비트)를 기다렸다가 이것이 도착한 후에야 백엔드 서버에 연결을 설정한다. 그 이유는 로드-밸런싱을 위한 쿠키나 기타 다른 HTTP 헤더들을 삽입하기 위한 것이다. ADC 연결 테이블이 가득 차면 다이내믹 리핑이 현재 사용 중이 아닌 (non-active) 연결들을 종료해서 진정한 SSL 연결들을 위한 새로운 연결자원을 만들어낸다. 풀-프록시 ADC (Application Delivery Controller)에서 SSL을 종료시키면 또 다른 이점들이 있다. 어떤 회사들은 SSL을 풀-프록시 ADC에서 종료시키고, 그 후에 그 뒤 단에서 DDoS 스크러빙 서비스를 시작하는데, 그 이유는 이런 서비스들이 이제는 암호화가 풀린 페이로드를 볼 수 있기 때문이다. 그러나 금융기관들에서는 종종 트래픽이 ADC를 떠날 때 다시 암호화를 하도록 요구되는데, 이런 곳에서는 ADC야말로 SSL 공격에 대응할 수 있는 ‘유일한’ 디바이스이다. 끝으로, ADC는 하드웨어로 보호된 FIPS 140 레벨 3 주요 서비스들의 위치를 찾아내기에 이상적인 디바이스이다. 이런 기능을 하는 디바이스들은 대체로 매우 비싸므로, 수십 대의 서버로부터 오는 이 서비스들을 한두 대의 ADC에 통합시키는 것은 매우 합리적인 선택이다. 고객들을 만나러 다니다 보면 공격을 받았을 때 방화벽이 실패했다는 얘기를 매우 자주 듣게 된다. 자신의 인프라를 보호하기 위해 방화벽을 구매, 설치하는데 막상 공격을 받았을 때는 방화벽이 바로 가장 취약한 링크가 된다는 것은 매우 아이러니컬 하다. SSL 공격을 받았을 때 SSL 인프라가 제 기능을 못하게 되는 것도 이와 마찬가지이다. SSL은 선의의 데이터를 보호하기 위한 기술이고 보호를 할 것으로 기대가 되는 기술이지만, 잘못된 방식으로 구축이 되면 해를 입도록 만드는 요소가 될 수 있다는 점을 명심해야 한다.
Continuing the DDoS Arms Race
Denial-of-Service (DoS) attacks are some of the oldest Internet threats and continue to be one of the top risks that companies are focusing their security strategy on. Banks and online gaming companies tend to lead the pack in building out the recommended dynamic, multilayered security infrastructure to detect and mitigate what has grown into Distributed-Denial-of-Service (DDoS) attacks with various large scale enterprises and online-retailers to follow. However, no one is immune to the mayhem – midsized retailers and even our favorite pizza shops have been impacted. As stated in an article by Peter parish on League of Legends DDOS attack, “Defending against DDOS attacks is an arms race that [one must] always be engaged in, and committed to reducing the [resulting] pain as swiftly as possible when the service is being impacted by malicious attacks”, and no matter who you are or what measures are in place one must remain vigilant. Today’s DDoS attacks have become more sophisticated and powerful, and have even moved up the stack to pound the application. According to one report that I am not calling out at this time, the number of 20 Gbps DDoS attacks doubled in Q1 of 2014 well over that reported for all of in 2013, and there was increase in the number of attacks above 100 Gbps in this same period. I can believe this just skimming through highlights on the internet which reveal similar findings. I am certain that you may have read about a number of DDoS attacks reported by media as large as 300Gbps. These cases tend to be more rare, but viable and growing. Although many attackers do not have such capacity to execute on a high-volume attack that large in their “volunteer’ botnets (where many people are downloading the same attack tool and directing it at the same target), don’t under estimate the potential for such an attack on your organization. Botnets are now being created anonymously, where attackers are installing tools on internet connected devices or servers unbeknownst to owners to drive larger DDoS attacks, host or visit websites and execute intense application level attacks. The was certainly seen with one recent headless browser attack that employed 180,000 IP addresses generating some 700 million hits per day. The easy availability of bots/botnets for hire (at a price of course – they are not free) and simple distributed crowd-sourced attack tools that utilize multiple technologies have made L2-L7 DDoS attacks more stealthy, resilient, innovative and successful at exploits that jeopardize applications, and consume resources, bandwidth and connections -- leaving organizations of all sizes and types at risk and out of service. So what are you doing now to strengthen your defense? Knowledge is power when protecting against DDoS attacks. The more you know about the types of traffic and volumes your network can handle, the better you can respond with the right protective measures before services can be interrupted. Understand in detail the source/origin of traffic, how it enters the network, what it is composed of and how much volume there should be at any given time. Also, be aware of any changes in the norm of the traffic patterns. This is generally an indication of an attack or should suspicious activity. Most importantly be able easily assess and relate the state of traffic and suspicious activity at every level in the OSI attack. This may require more advanced forensics and SIEM systems in addition to combined information from an ADC, firewalls and other security device/solutions. We’ve improved visibility for you with F5 Advanced Firewall Manager (AFM ) v11.6 by centralizing information flow for network and HTTP DoS reports (combining reports from F5 Application Security Manager (ASM) and AFM) and providing greater intelligence about stateful attacks. For ASM we’ve added a unique dashboard that consolidates multiple reports into a single-pane view, providing insight about app server health, historical trend data and current state of attacks all with query and analysis capabilities and links to in-depth details about events, threats techniques, response time, traffic and more. Stay aware of DDOS trends. Understanding the attack trends globally and adapting protection measures accordingly will keep your severity strategy effective. For instance, UDP attacks have increased in use, so you may want to look closely at the types of policies and FW rules you have in place to filter out UDP traffic, to advert a potential service outage caused when the victimized system is forced to send many ICMP packets. Also, with the increase in frequency and volume of DDoS attacks firewall performance and scalability becomes a factor – spinning up additional devices (or VEs) and gaining more granular controls that unburden firewalls of suspicious traffic becomes essential. Sources for trending information include reports commonly published by reputable sources like vendors, consortiums/organization and security media and analysts. Improve upon and protect against automated attacks. With the increase in attacks at the application level you will want to improve upon how you distinguish automated traffic from real human traffic. Although there is some need for automated traffic, you want to identify any unauthorized scrapping or scanning of your proprietary information and the sooner the better. In ASM v11.6 we have added an additional layer to bot protections which provide always-on proactive bot defense that identifies automated application attacks before attacks commence, stopping attackers upon first attempting to access the application. This functionality greatly compliments capabilities that already mitigate attacks in progress (reactive protections). Call in the experts when you are under attack. It is important to know who in your organization can step in to take action when you are under attack or feel an attack may take place. Also be aware of service providers and security partners (like F5) who may help in assessing or stopping the treat and providing expertise in creating custom rules to mitigate threats. Keep this information at hand and visible for all. Use the most up-to-date DDoS security products. Security requires a multi-layered approach to mitigating attacks by combining multiple security controls to protect resources and data. Make certain tools you rely on for a layered defense offer protection as the scheme of attacks change. As your partner in security F5 recently enhanced the capabilities of our firewall solutions to help ensure our customers have the most effective protections for guarding against sophisticated DDoS attacks. These updates are part of the large scheme of BIG-IP 11.6 release which geared towards providing better orchestration, visibility, stronger DDoS protections with improved performance. Below are a few highlights, but check out the version 11.6 release notes for ASM, AFM and the BIG-IP line of products for more details on what is new in version 11.6. Taking up arms against DDoS with F5 Lastly, I just want to mention that with the release of BIG-IP 11.6 we have added functionality that strengthens existing DDoS capabilities to allow you to apply a stronger defense against sophisticated attacks. AFM provides over 100 attack signatures with more HW based vectors than any other vendor and more granularity in preventing layer 3-5 DDoS attacks, especially where there is concern for IGMP floods, and SIP and DNS UDP attacks. Additionally this release extends existing protections for capacity attacks on the flow/transaction state tracking structures to include a richer set of parameters and algorithms for more effective policies that enable Flow-Table limits with greater granularity. We’ve also enabled traffic sampling for AFM under fast L4 to provide high speed sampling and scrubbing, allowing you to more effectively capture live traffic samples to examine DoS traffic patterns and create more effective rules. BIG-IP systems can now process some or all of the Layer 4 traffic passing through the system to unburden the firewall, and increase performance. iRules interaction has also been extended to leverage IP Intelligence services, enable statistical traffic subsampling, and detect stateful attacks on flowtables –protecting not only the data center but the BIG-IP AFM and the applications behind it. BIG-IP 11.6 also delivers enhancements to our Web application firewall (ASM) to enable stream-lined Captcha-based security, more effective blocking of attacks from high-risk global regions and more immediacy in detecting and patching application vulnerabilities. Take time to read the release notes for a complete picture of what’s inside of BIG-IP 11.6 and the datasheets for ASM, AFM and BIG-IP itself. Contact your F5 rep for more details. Also, stay tuned for blogs touching on protections against automated and brute force attacks, headless browser attacks, more effectively discerning against false positives and negatives with ASM. Until next time, I look forward to hearing from you. More Information ASM: Datasheet / 11.6 Release Notes / Product Page AFM: Datasheet / 11.6 Release Notes / Product PageSize doesn’t matter: Australian businesses not spared immunity from cyber attacks
We have all heard or read about, at least one cyber attack that has taken place in the last three months. Most recently in August, we witnessed the widely reported nude celebrity photo leak that not only raised concerns for privacy, but also the security risks involved in downloading content from the Internet. Reportedly, malware from distributed denial of service (DDoS) attacks on those computers that accessed the photographs, took down the entire IT infrastructure in New Zealand alone. This example goes to show that ANZ is not immune to cyber attacks and breaches.In fact, a growing number of these types of incidents originate in ANZ and are much more common than what is disclosed. Threats posed by DDoS attacks in particular, are growing more rapidly. We are seeing an increase in high profile and high impact international DDoS attacks carried out on major Australian institutions and government organisations. Some examples that come to mind include the Australian Federal Police (AFP) and the Reserve Bank of Australia, which were both breached late last year. These attacks show that even the largest, most secure institutions in Australia are faced with the challenge to protect themselves against highly sophisticated cyber threats. Size doesn’t matter In addition, it is important to note that a few years ago it was typically only high profile brands that were subjected to DDoS attacks. Take for example large US-based corporations such as JP Morgan Chase and the New York Times whose websites remained on the radar for attackers and were eventually attacked. Recent trends show however, that smaller companies are not immune to the threat of cyber attacks either. Attackers seeking intellectual property and economic data have shifted their focus to the smaller players and suppliers of larger firms. In fact, the threat of launching a DDoS attack, in return for a paid ransom, is not uncommon to corporations who do not want to deal with the hassle of answering to its stakeholders. When a company is found to have loopholes in its security infrastructure, they not only stand to lose data, they also stand to lose customer confidence and in turn have to manage their brand reputation delicately. As a result, these types of cases go unreported and there will be no sight of these payoffs, in hopes to sweep the issue under the carpet. In addition to DDoS attacks, malware has emerged as one of the most powerful tools for targeted data exfiltration, used particularly when an attacker wants to steal intellectual property or currency. According to the Australian Communications and Media Authority (ACMA), an average of 16,500 cases of malware have been reported to Australian Internet service providers every day last year. Moreover, the head of Australia’s corporate regulator has warned that Australian businesses are not taking the risk of cyber crime seriously enough. According to Aon Financial Specialties, cybercrime in Australia costs an estimated AUD4.5 billion annually. We all know that security is a global issue and isn’t going away anytime soon. In addition, the uptake of the Internet of Things is only going to make security an even bigger consideration for businesses. So what can organisations in Australia do to protect themselves more effectively? Predicting a DDoS attack is difficult, and the results can be disastrous: loss of revenue-generating applications as well as reputational damage can negatively impact a business for years. Protecting against an attack however, may be less difficult. There are ways a company can keep their applications, services and even their entire network online, without stopping legitimate traffic. F5 Networks’ BIG-IP Advanced Firewall Manager, Application Security Manager and Local Traffic Manager provide the combination needed to mitigate DDoS attacks, from blocking attack traffic to re-routing legitimate requests to ensure uptime. At the same time, understanding who is attacking the business, as well as how and why, can help prevent an attack from causing too much damage and can help protect against future attacks.
