Mitigate L7 DDoS with BIG-IP ASM
Today, let’s look at a couple ways to mitigate an applicationDDoS attack with BIG-IP ASM. We’ve logged into a BIG-IP ASM and navigated to Security>DDoS Protection>DDoS Profiles. In the General Settings of Application Security, we’ll activate an application DoS iRule event. We’ll click TPS-based Detection to see the temporarily lowered TPS thresholds to easily simulate an attack. Often, there are multiple mitigation methods that are sequentially applied as you can see with the Source IP settings. We can also record traffic packet captures during attacks for post analysis. When the user requests a web application proxied by BIG-IP ASM, ASM will create a unique identifier or a Device ID. ASM will inject JavaScript to register each client device. You can see X-Device-ID: at the bottom. And JavaScript incapable clients never make it through. Now that the unit is ready, let’s enable some packet capture and take a go at that damn vulnerable web application. Path for the log files is /var/log/ or /shared/log/…the PCAP folder is empty so let’s see the action. Attack commence in 3-2-1. Some quick refreshes should do as our thresholds are low. The first mitigation is Client Side Integrity Defense. The system issues a client-side integrity challenge that consumes client computation resources and slows down the attack. Next is Built-in Captcha. The third mitigation is Rate Limiting… ..then if they’re still not listening, you can instantly transform into a Honeypot. The logs below show the IP address and the type of mitigation technique deployed. First Integrity, then Captcha, then Rate Limiting, then Honeypot if they don't stop. The traffic you recorded will be found in the, now populated, PCAP folders. Thanks to F5 SE Artiom Lichtenstein for the demo video. ps Related: Lightboard Lessons: What is DDoS? ASM_DosL7 iRule Code
Shellshock – The SIP Proxy Edition
The recent Shellshock and Heartbleed vulnerabilities have something in common – they both affect very infrastructural services. That is the reason their magnitude is much bigger than any other ol’ vulnerability out there. “Everyone” uses bash, “everyone” uses OpenSSL. Shock the shell However, one of the differences is that bash isn’t a public facing service like OpenSSL. Bash is simply the shell service of the underlying operating system. To be able to get to bash and exploit the vulnerability – one has to find a way to remotely “talk” with and feed it their evil commands via environment variables. Arguably, the most common path to reach bash is through a web server that makes use of the CGI technology. By default, CGI creates user-controlled environment variables, which are then parsed by bash, for every HTTP request the server accepts. This means that exploiting bash on such a system is as easy as sending an HTTP request to a CGI controlled page. However, CGI isn’t the only service that uses bash “behind the scenes”. DHCP services are affected, SSH and Telnet are affected, FTP services are affected. Some SIP proxies are also affected, we will learn why and how to mitigate them. SIP Express Router and friends Popular open source SIP proxies, such as Kamailio, have been found vulnerable to Shellshock. The author of a POC tool called sipshock has written a very clear explanation on the matter: The exec module in Kamailio, Opensips and probably every other SER fork passes the received SIP headers as environment variables to the invoking shell. This makes these SIP proxies vulnerable to CVE-2014-6271 (Bash Shellshock). If a proxy is using any of the exec functions and has the 'setvars' parameter set to the default value '1' then by sending SIP messages containing a specially crafted header we can run arbitrary code on the proxy machine. This means that if you have a public facing SIP proxy running a SIP Express Router implementation, you should patch your bash immediately. If you have an F5 LTM doing load balancing for that SIP server – a simple iRule will save you the headache of patching the operating system, and give you breathing room to do so properly. Mitigate Shellshock SIP with BIG-IP iRules The following iRule will detect SIP requests which contain the Shellshock pattern in one of the headers: when CLIENT_DATA { set sCVEPattern "*: () \{*" set bCVEFound 0 if { [string match $sCVEPattern [UDP::payload]] } { set bCVEFound 1 } } when SIP_REQUEST { if { $bCVEFound } { log local0. "Detected CVE-2014-6271 Shellshock attack! IP: '[IP::client_addr]' From: [SIP::from] To: [SIP::to]" reject } } Create a new iRule and attach it to your SIP proxy virtual server. Make sure the Virtual Server has “UDP” set as protocol, and is assigned with a SIP profile.Bash Shellshock Mitigation Using ASM Signatures
Update: The signature mentioned in this article have been released as part of an Attack Signature Update. You may head to https://downloads.f5.com to download the file manually, or use the automatic update feature in ASM. This week we've seen new vulnerabilities with massive damage potential come to light – CVE-2014-6271,CVE-2014-6277 and CVE-2014-7169 - named quite appropriately "Shellshock". Background You can find details regarding this bash vulnerability on the Red Hat security blog: https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/ In a typical exploit, the payload is sent through a header (typically Cookie, Referrer or User-Agent) and takes advantage of the way the web server saves the data in that request to environment variables. A malicious request will attempt to fool the bash parser by sending a payload that will invoke a system command, for instance: GET /home.php HTTP/1.1 Host: example.com User-Agent: () { :;}; /bin/bash -c "ls" The string "() { :;};" means it is a function declaration. The string is followed by various shell commands – in our case it is execution of the "ls" command. Mitigation using F5 ASM Attack Signatures The following signature will catch attempts to exploit this CVE: headercontent:"() {"; This signature is compatible with all BIG-IP versions. To prevent any other potential exploitation attempts via the URL or a parameter, two additional signatures can be used: uricontent:"() {"; objonly; valuecontent:"() {"; norm; Note: The signatures have been updated to catch exploit attempts in all their variations. It is important to note, that all attempts to exploit this vulnerability via HTTP parameters and several known exploits via the HTTP header are already mitigated using existing "command execution" and "predictable resource location" signatures. Exploits via the Cookie header will encounter the "Cookie not RFC-compliant" violation. You need to make sure they are enabled and are not in staging. To protect your application, create those user-defined signatures and associate them with the relevant security policy. Make sure that the signatures are not in staging.F5 Friday: Goodbye Defense in Depth. Hello Defense in Breadth.
#adcfw #infosec F5 is changing the game on security by unifying it at the application and service delivery layer. Over the past few years we’ve seen firewalls fail repeatedly. We’ve seen business disrupted, security thwarted, and reputations damaged by the failure of the very devices meant to prevent such catastrophes from happening. These failures have been caused by a change in tactics from invaders who seek no longer to find away through or over the walls, but who simply batter it down instead. A combination of traditional attacks – network-layer – and modern attacks – application-layer – have become a force to be reckoned with; one that traditional stateful firewalls are often not equipped to handle. Encrypted traffic flowing into and out of the data center often bypasses security solutions entirely, leaving another potential source of a breach unaddressed. And performance is being impeded by the increasing number of devices that must “crack the packet” as it were and examine it, often times duplicating functionality with varying degrees of success. This is problematic because the resolution to this issue can be as disconcerting as the problem itself: disable security. Seriously. Security functions have been disabled, intentionally, in the name of performance. IT security personnel within large corporations are shutting off critical functionality in security applications to meet network performance demands for business applications. SURVEY: SECURITY SACRIFICED FOR NETWORK PERFORMANCE What the company [NSS Labs] found would likely startle any existing or potential customers: three of the six firewalls failed to stay operational when subjected to stability tests, five out of six didn't handle what is known as the "Sneak ACK attack," that would enable attackers to side-step the firewall itself. Finally, according to NSS Labs, the performance claims presented in the vendor datasheets "are generally grossly overstated." Independent lab tests find firewalls fall down on the job Add in the complexity from the sheer number of devices required to implement all the different layers of security needed, which increases costs while impairing performance, and you’ve got a broken model in need of repair. This is a failure of the defense in depth strategy; the layered, multi-device (silo) approach to operational security. Most importantly, it’s one that’s failing to withstand attacks. What we need is defense in breadth – the height of the stack –to assure availability and security using a more intelligent, unified security strategy. DEFENSE in BREADTH While it’s really not as catchy as “defense in the depth” the concept behind the admittedly awkward sounding phrase is sound: to assure availability and security simultaneously requires a strong security strategy from the bottom to the top of the networking stack, i.e. the application layer. The ability of the F5 BIG-IP platform to provide security up and down the stack has existed for many years, and its capabilities to detect, prevent, and withstand concerted attacks has been appreciated by its customers (quietly) for some time. While basic firewalling functions have been a part of BIG-IP for years, there are certain capabilities required of a firewall – specifically an ICSA certified firewall – that it didn’t have. So we decided to do something about that. The result is the ICSA certification of the BIG-IP platform as a network firewall. Combined with its existing ICSA certification for web application firewall (BIG-IP Application Security Manager) and SSL-TLS VPN 3.0 (BIG-IP Edge Gateway), the BIG-IP platform now supports a full-spectrum security solution in a single, unified system. What is unique about F5’s approach is that the security capabilities noted above can be deployed on BIG-IP Application Delivery Controllers (ADCs)—best known for providing industry-leading intelligent traffic management and optimization capabilities. This firewall solution is part of F5’s comprehensive security architecture that enables customers to apply a unified security strategy. For the first time in the industry, organizations can secure their networks, data, protocols, applications, and users on a single, flexible, and extensible platform: BIG-IP. Combining network-firewall services with the ability to plug the hole in modern security implementations (the application layer) with a platform-based solution provides the opportunity to consolidate security services and leverage a shared infrastructure platform resulting in a more comprehensive, strategic deployment that is not only more secure, but more cost effective. Resources: The Fundamental Problem with Traditional Inbound Protection The Ascendancy of the Application Layer Threat ISCA Certified Network Firewall for Data Centers Mature Security Organizations Align Security with Service Delivery BIG-IP Data Center Firewall Solution – SlideShare Presentation The New Data Center Firewall Paradigm – White Paper Independent lab tests find firewalls fall down on the job SURVEY: SECURITY SACRIFICED FOR NETWORK PERFORMANCE F5 Friday: When Firewalls Fail… Challenging the Firewall Data Center Dogma What We Learned from Anonymous: DDoS is now 3DoS The Many Faces of DDoS: Variations on a Theme or Two F5 Friday: Eliminating the Blind Spot in Your Data Center Security Strategy F5 Friday: Multi-Layer Security for Multi-Layer AttacksF5 BIG-IP Platform Security
When creating any security-enabled network device, development teams must fully investigate security of the device itself to ensure it cannot be compromised. A gate provides no security to a house if the gap between the bars is large enough to drive a truck through. Many highly effective exploits have breached the very software and hardware that are designed to protect against them. If an attacker can breach the guards, then they don’t need to worry about being stealthy, meaning if one can compromise the box, then they probably can compromise the code. F5 BIG-IP Application Delivery Controllers are positioned at strategic points of control to manage an organization’s critical information flow. In the BIG-IP product family and the TMOS operating system, F5 has built and maintained a secure and robust application delivery platform, and has implemented many different checks and counter-checks to ensure a totally secure network environment. Application delivery security includes providing protection to the customer’s Application Delivery Network (ADN), and mandatory and routine checks against the stack source code to provide internal security—and it starts with a secure Application Delivery Controller. The BIG-IP system and TMOS are designed so that the hardware and software work together to provide the highest level of security. While there are many factors in a truly secure system, two of the most important are design and coding. Sound security starts early in the product development process. Before writing a single line of code, F5 Product Development goes through a process called threat modeling. Engineers evaluate each new feature to determine what vulnerabilities it might create or introduce to the system. F5’s rule of thumb is a vulnerability that takes one hour to fix at the design phase, will take ten hours to fix in the coding phase and one thousand hours to fix after the product is shipped—so it’s critical to catch vulnerabilities during the design phase. The sum of all these vulnerabilities is called the threat surface, which F5 strives to minimize. F5, like many companies that develop software, has invested heavily in training internal development staff on writing secure code. Security testing is time-consuming and a huge undertaking; but it’s a critical part of meeting F5’s stringent standards and its commitment to customers. By no means an exhaustive list but the BIG-IP system has a number of features that provide heightened and hardened security: Appliance mode, iApp Templates, FIPS and Secure Vault Appliance Mode Beginning with version 10.2.1-HF3, the BIG-IP system can run in Appliance mode. Appliance mode is designed to meet the needs of customers in industries with especially sensitive data, such as healthcare and financial services, by limiting BIG-IP system administrative access to match that of a typical network appliance rather than a multi-user UNIX device. The optional Appliance mode “hardens” BIG-IP devices by removing advanced shell (Bash) and root-level access. Administrative access is available through the TMSH (TMOS Shell) command-line interface and GUI. When Appliance mode is licensed, any user that previously had access to the Bash shell will now only have access to the TMSH. The root account home directory (/root) file permissions have been tightened for numerous files and directories. By default, new files are now only user readable and writeable and all directories are better secured. iApp Templates Introduced in BIG-IP v11, F5 iApps is a powerful new set of features in the BIG-IP system. It provides a new way to architect application delivery in the data center, and it includes a holistic, application-centric view of how applications are managed and delivered inside, outside, and beyond the data center. iApps provide a framework that application, security, network, systems, and operations personnel can use to unify, simplify, and control the entire ADN with a contextual view and advanced statistics about the application services that support business. iApps are designed to abstract the many individual components required to deliver an application by grouping these resources together in templates associated with applications; this alleviates the need for administrators to manage discrete components on the network. F5’s new NIST 800-53 iApp Template helps organizations become NIST-compliant. F5 has distilled the 240-plus pages of guidance from NIST into a template with the relevant BIG-IP configuration settings—saving organizations hours of management time and resources. Federal Information Processing Standards (FIPS) Developed by the National Institute of Standards and Technology (NIST), Federal Information Processing Standards are used by United States government agencies and government contractors in non-military computer systems. FIPS 140 series are U.S. government computer security standards that define requirements for cryptography modules, including both hardware and software components, for use by departments and agencies of the United States federal government. The requirements cover not only the cryptographic modules themselves but also their documentation. As of December 2006, the current version of the standard is FIPS 140-2. A hardware security module (HSM) is a secure physical device designed to generate, store, and protect digital, high-value cryptographic keys. It is a secure crypto-processor that often comes in the form of a plug-in card (or other hardware) with tamper protection built in. HSMs also provide the infrastructure for finance, government, healthcare, and others to conform to industry-specific regulatory standards. FIPS 140 enforces stronger cryptographic algorithms, provides good physical security, and requires power-on self tests to ensure a device is still in compliance before operating. FIPS 140-2 evaluation is required to sell products implementing cryptography to the federal government, and the financial industry is increasingly specifying FIPS 140-2 as a procurement requirement. The BIG-IP system includes a FIPS cryptographic/SSL accelerator—an HSM option specifically designed for processing SSL traffic in environments that require FIPS 140-1 Level 2–compliant solutions. Many BIG-IP devices are FIPS 140-2 Level 2–compliant. This security rating indicates that once sensitive data is imported into the HSM, it incorporates cryptographic techniques to ensure the data is not extractable in a plain-text format. It provides tamper-evident coatings or seals to deter physical tampering. The BIG-IP system includes the option to install a FIPS HSM (BIG-IP 6900, 8900, 11000, and 11050 devices). BIG-IP devices can be customized to include an integrated FIPS 140-2 Level 2–certified SSL accelerator. Other solutions require a separate system or a FIPS-certified card for each web server; but the BIG-IP system’s unique key management framework enables a highly scalable secure infrastructure that can handle higher traffic levels and to which organizations can easily add new services. Additionally the FIPS cryptographic/SSL accelerator uses smart cards to authenticate administrators, grant access rights, and share administrative responsibilities to provide a flexible and secure means for enforcing key management security. Secure Vault It is generally a good idea to protect SSL private keys with passphrases. With a passphrase, private key files are stored encrypted on non-volatile storage. If an attacker obtains an encrypted private key file, it will be useless without the passphrase. In PKI (public key infrastructure), the public key enables a client to validate the integrity of something signed with the private key, and the hashing enables the client to validate that the content was not tampered with. Since the private key of the public/private key pair could be used to impersonate a valid signer, it is critical to keep those keys secure. Secure Vault, a super-secure SSL-encrypted storage system introduced in BIG-IP version 9.4.5, allows passphrases to be stored in an encrypted form on the file system. In BIG-IP version 11, companies now have the option of securing their cryptographic keys in hardware, such as a FIPS card, rather than encrypted on the BIG-IP hard drive. Secure Vault can also encrypt certificate passwords for enhanced certificate and key protection in environments where FIPS 140-2 hardware support is not required, but additional physical and role-based protection is preferred. In the absence of hardware support like FIPS/SEEPROM (Serial (PC) Electrically Erasable Programmable Read-Only Memory), Secure Vault will be implemented in software. Even if an attacker removed the hard disk from the system and painstakingly searched it, it would be nearly impossible to recover the contents due to Secure Vault AES encryption. Each BIG-IP device comes with a unit key and a master key. Upon first boot, the BIG-IP system automatically creates a master key for the purpose of encrypting, and therefore protecting, key passphrases. The master key encrypts SSL private keys, decrypts SSL key files, and synchronizes certificates between BIG-IP devices. Further increasing security, the master key is also encrypted by the unit key, which is an AES 256 symmetric key. When stored on the system, the master key is always encrypted with a hardware key, and never in the form of plain text. Master keys follow the configuration in an HA (high-availability) configuration so all units would share the same master key but still have their own unit key. The master key gets synchronized using the secure channel established by the CMI Infrastructure as of BIG-IP v11. The master key encrypted passphrases cannot be used on systems other than the units for which the master key was generated. Secure Vault support has also been extended for vCMP guests. vCMP (Virtual Clustered Multiprocessing) enables multiple instances of BIG-IP software to run on one device. Each guest gets their own unit key and master key. The guest unit key is generated and stored at the host, thus enforcing the hardware support, and it’s protected by the host master key, which is in turn protected by the host unit key in hardware. Finally F5 provides Application Delivery Network security to protect the most valuable application assets. To provide organizations with reliable and secure access to corporate applications, F5 must carry the secure application paradigm all the way down to the core elements of the BIG-IP system. It’s not enough to provide security to application transport; the transporting appliance must also provide a secure environment. F5 ensures BIG-IP device security through various features and a rigorous development process. It is a comprehensive process designed to keep customers’ applications and data secure. The BIG-IP system can be run in Appliance mode to lock down configuration within the code itself, limiting access to certain shell functions; Secure Vault secures precious keys from tampering; and optional FIPS cards ensure organizations can meet or exceed particular security requirements. An ADN is only as secure as its weakest link. F5 ensures that BIG-IP Application Delivery Controllers use an extremely secure link in the ADN chain. ps Resources: F5 Security Solutions Security is our Job (Video) F5 BIG-IP Platform Security (Whitepaper) Security, not HSMs, in Droves Sometimes It Is About the Hardware Investing in security versus facing the consequences | Bloor Research White Paper Securing Your Enterprise Applications with the BIG-IP (Whitepaper) TMOS Secure Development and Implementation (Whitepaper) BIG-IP Hardware Updates – SlideShare Presentation Audio White Paper - Application Delivery Hardware A Critical Component F5 Introduces High-Performance Platforms to Help Organizations Optimize Application Delivery and Reduce Costs Technorati Tags: F5, PCI DSS, virtualization, cloud computing, Pete Silva, security, coding, iApp, compliance, FIPS, internet, TMOS, big-ip, vCMPF5 Friday: Mitigating the THC SSL DoS Threat
The THC #SSL #DoS tool exploits the rapid resource consumption nature of the handshake required to establish a secure session using SSL. A new attack tool was announced this week and continues to follow in the footsteps of resource exhaustion as a means to achieve a DoS against target sites. Recent trends in attacks show an increasing interest in maximizing effect while minimizing effort. This means a move away from traditional denial of service attacks that focus on overwhelming sites with traffic and toward attacks that focus on rapidly consuming resources, instead. Both have the same ultimate goal: overwhelming infrastructure, whether server or router or insert infrastructure component of choice>. The latest SSL-based attack falls into the modern category of denial of service attacks in that it’s not an attempt to overwhelm with traffic, but rather to consume resources on servers such that capacity and the ability to respond to legitimate requests is eliminated. The blog post announcing the exploit tools explains: Establishing a secure SSL connection requires 15x more processing power on the server than on the client. THC-SSL-DOS exploits this asymmetric property by overloading the server and knocking it off the Internet. This problem affects all SSL implementations today. The vendors are aware of this problem since 2003 and the topic has been widely discussed. This attack further exploits the SSL secure Renegotiation feature to trigger thousands of renegotiations via single TCP connection. -- THC SSL DOS Tool Released As the blog points out, there is no resolution to this exploit. Common mitigation techniques include the use of an SSL accelerator, i.e. a reverse-proxy capable device with specialized hardware designed to improve the processing capability of SSL and associated cryptographic functions. Modern application delivery controllers like BIG-IP include such hardware by default and make use of its performance and capacity-enhancing abilities to offset the operational costs of supporting SSL-secured communication. BIG-IP MITIGATION There are actually several ways in which BIG-IP can mitigate the potential impact of this kind of attack. First and foremost is simply its higher capacity for connections and processing of SSL / RSA operations. BIG-IP can manage myriad more connections – secure or not – than a typical web server and thus it may be, depending on the hardware platform on which BIG-IP is deployed, that the mitigation rests merely on having a BIG-IP in the path of the attack. In the case that it is not, or if organizations desire a more proactive approach to mitigation, there are two additional options: 1. SSL renegotiation, which is in part the basis for the attack (it’s what allows a relatively few clients to force the server to consume more and more resources), can be disabled in BIG-IP v11 and v10.2.3. This may break some applications and/or clients so this option may want to be left as a “last resort” or the risks carefully weighed before deploying such a configuration. 2. An iRule that drops connections over which a client attempts to renegotiate more than five times in a given 60-second interval can be deployed. As noted by David Holmes and the iRule author, Jason Rahm, “By silently dropping the client connection, the iRule causes the attack tool to stall for long periods of time, fully negating the attack. There should be no false-positives dropped, either, as there are very few valid use cases for renegotiating more than once a minute.” The full details and code for the iRule can be found in the DevCentral article “SSL Renegotiation DOS attack – an iRule Countermeasure” UPDATE 11/1/2011: David Holmes has included an optimized version of the iRule in his latest blog, "The SSL Renegotation Attack is Back." His version uses the normal flow key (instead of a random key), adds a log message, and optimizes memory consumption. Regardless of the mitigating technique used, BIG-IP can provide the operational security necessary to prevent such consumption-leeching attacks from negatively impacting applications by defeating the attack before it reaches application infrastructure. Stay safe!ICSA Certified Network Firewall for Data Centers
The BIG-IP platform is now ICSA Certified as a Network Firewall. Internet threats are widely varied and multi-layered. Although applications and their data are attackers’ primary targets, many attackers gain entry at the network layer. Internet data centers and public-facing web properties are constant targets for large-scale attacks by hacker/hactivist communities and others looking to grab intellectual property or cause a service outage. Organizations must prepare for the normal influx of users, but they also must defend their infrastructure from the daily barrage of malicious users. Security administrators who manage large web properties are struggling with security because traditional firewalls are not meeting their fundamental performance needs. Dynamic and layered attacks that necessitate multiple-box solutions, add to IT distress. Traditional firewalls can be overwhelmed by their limited ability to scale under a DDoS attack while keeping peak connection performance for valid users, which renders not only the firewalls themselves unresponsive, but the web sites they are supposed to protect. Additionally, traditional firewalls’ limited capacity to interpret context means they may be unable to make an intelligent decision about how to deliver the application while also keeping services available for valid requests during a DDoS attack. Traditional firewalls also lack specialized capabilities like SSL offload, which not only helps reduce the load on the web servers, but enables inspection, re-encryption, and certificate storage. Most traditional firewalls lack the agility to react quickly to changes and emerging threats, and many have only limited ability to provide new services such as IP geolocation, traffic redirection, traffic manipulation, content scrubbing, and connection limiting. An organization’s inability to respond to these threats dynamically, and to minimize the exposure window, means the risk to the overall business is massive. There are several point solutions in the market that concentrate on specific problem areas; but this creates security silos that only make management and maintenance more costly, more cumbersome, and less effective. The BIG-IP platform provides a unified view of layer 3 through 7 for both general and ICSA required reporting and alerts, as well as integration with SIEM vendors. BIG-IP Local Traffic Manager offers native, high-performance firewall services to protect the entire infrastructure. BIG-IP LTM is a purpose-built, high-performance Application Delivery Controller designed to protect Internet data centers. In many instances, BIG-IP LTM can replace an existing firewall while also offering scale, performance, and persistence. Performance: BIG-IP LTM manages up to 48 million concurrent connections and 72 Gbps of throughput with various timeout behaviors, buffer sizes, and more when under attack. Protocol security: The BIG-IP system natively decodes IPv4, IPv6, TCP, HTTP, SIP, DNS, SMTP, FTP, Diameter, and RADIUS. Organizations can control almost every element of the protocols they’re deploying. DDoS prevention capabilities: An integrated architecture enables organizations to combine traditional firewall layers 3 and 4 with application layers 5 through 7. DDoS mitigations: The BIG-IP system protects UDP, TCP, SIP, DNS, HTTP, SSL, and other network attack targets while delivering uninterrupted service for legitimate connections. SSL termination: Offload computationally intensive SSL to the BIG-IP system and gain visibility into potentially harmful encrypted payloads. Dynamic threat mitigation: iRules provide a flexible way to enforce protocol functions on both standard and emerging or custom protocols. With iRules, organizations can create a zero day dynamic security context to react to vulnerabilities for which an associated patch has not yet been released. Resource cloaking and content security: Prevent leaks of error codes and sensitive content. F5 BIG-IP LTM has numerous security features so Internet data centers can deliver applications while protecting the infrastructure that supports their clients and, BIG-IP is now ICSA Certified as a Network Firewall. ps Resources: F5’s Certified Firewall Protects Against Large-Scale Cyber Attacks on Public-Facing Websites F5 BIG-IP Data Center Firewall – Overview BIG-IP Data Center Firewall Solution – SlideShare Presentation High Performance Firewall for Data Centers – Solution Profile The New Data Center Firewall Paradigm – White Paper Vulnerability Assessment with Application Security – White Paper Challenging the Firewall Data Center Dogma Technorati Tags: F5, big-ip, virtualization, cloud computing, Pete Silva, security, icsa, iApp, compliance, network firewall, internet, TMOS, big-ip, vCMPThe DevCentral Chronicles June Edition 1(6)
Heading into the summer months is always a nice time of year – school is out, warmer weather, BBQs, beaches, baseball and maybe some vacation time. And hopefully all the Dads had a nice Father’s Day as we dive into our 6 th installment of the DC Chronicles. The Chronicles are intended to keep you updated on DevCentral happenings and highlight some of the cool content you may have missed since the last issue and you can always catch up with the links at the bottom. Welcome! We had 20 new articles published since Volume 1, Issue 5, including 5 new Lightboard Lessons! We really enjoy making these and you, the audience, certainly express your enjoyment in watching. John Wagnon lit some cool security related topics like, Explaining TLS 1.3, What Are AEAD Ciphers? and The TLS 1.3 Handshake while Jason Rahm drew up the F5 software lifecycle and BIG-IP Cloud Edition Overview. Since we’re on Cloud, Chris Zhang also wrote up how to Achieve firewall high-availability in Azure with F5. We also published a bunch of materials about our new BIG-IP Cloud Edition. BIG-IP Cloud Edition is designed to enable easy to use and fast self-serve deployments of application services in private and public clouds and is composed of BIG-IP Per-App VEs and BIG-IQ CM 6.0. To get the scoop, you can check out the BIG-IP Cloud Edition FAQ, Building Applications For The Rest Of Us With BIG-IQ 6 and Skies Never Looked So Good With BIG-IP Cloud Edition. DevCentral’s Chase Abbott lays out the details. Moving from Cloud to Security, several vulnerability mitigations from our SIRT team dropped recently. You got coverage for Remote Code Execution with Spring OAuth Extension (CVE-2018-1260), a New BIG-IP ASM v13 Drupal v8 Ready Template, and a New BIG-IP ASM v13 WordPress v4.9 Ready Template. Also filed under Security, Steve Lyons showed how to Configure Smart Card Authentication to BIG-IP Management Interface. Other highlights include Lori MacVittie’s Three HTTP Routing Patterns You Should Know with Eric Chen’s follow on, SNI Routing with BIG-IP. Chen also gives us Clone Pool Across L3 explaining how you can use the “clone pool” feature to copy traffic to an IDS and/or network monitoring device. Jason continues his Getting started with the Python SDK series covering Working with Statistics and Working with Request Parameters and finally, Jie Gao was DevCentral's Featured Member for June. As always, You can stay engaged with @DevCentral by following us on Twitter, joining our LinkedIn Group or subscribing to our YouTube Channel. Look forward to hearing about your BIG-IP adventures. The Chronicles: Volume 1, Issue 1 Volume 1, Issue 2 Volume 1, Issue 3 Volume 1, Issue 4 Volume 1, Issue 5Surfing the Surveys: Cloud, Security and those Pesky Breaches
While I’m not the biggest fan of taking surveys, I sure love the data/reports that are generated by such creatures. And boy has there been a bunch of recent statistical information released on cloud computing, information security, breaches and general IT. Since this prologue is kinda lame, let’s just get into the sometimes frightening, sometimes encouraging and always interesting results from a variety of sources. 2012 Verizon Data Breach Report: If you haven’t, read Securosis' blog about how to read and digest the report. It’s a great primer on what to expect. An important piece mentioned is that it’s a Breach report, not a cybercrime or attack report. It only includes incidents where data was taken – no data loss, not included. And with that in mind, according to the report, there were 855 incidents with 174 million compromised records, the 2nd highest data loss total since they’ve been tracking (2004). This coming after a record low 4 million lost records last year. The gold record of stolen records. While hacktivism exploded, accounted for 100 million of that 174 mill of stolen records and 58% of all data theft along with untraditional motives; credit cards, intellectual property, classified info and trade secrets were all still hot targets. 81% of the breaches used some sort of hacking with 69% involving malware. 79% were targets of opportunity meaning they had an exploitable vulnerability rather than being ‘on a list.’ 96% of the breaches were not that difficult and 97% could have been avoided using simple to standard protection mechanisms. Unfortunately, organizations typically don’t discover the breach until weeks later. As Securosis points out, don’t be flustered by the massive increase in lost data but focus on the attack and defense trends to help protect against becoming a statistic and as Verizon mentions, ‘this study reminds us that our profession has the necessary tools to get the job done. The challenge for the good guys lies in selecting the right tools for the job at hand and then not letting them get dull and rusty over time. Evidence shows when that happens, the bad guys are quick to take advantage of it.’ BMC Software Survey: Conducted by Forrester Consulting on behalf of BMC, ‘Delivering on High Cloud Expectations’ found that while 81% of the respondents said that a comprehensive cloud strategy is a high priority, they are facing huge challenges in accomplishing that task – mainly complexity. Even with cost reduction as a top IT priority, 43% reported using three or more hypervisor technologies as they try to reduce complexity. CIOs are concerned that cloud technologies offer an avenue for groups to circumvent IT which may hinder IT’s ability to meet overall business expectations. When groups deploy unmanaged public cloud services without IT involvement it can add to the complexity that they are trying to avoid. While 79% of respondents do plan on supporting mission-critical workloads on unmanaged public cloud services over the next two years, only 36% allow this today. No surprise that hybrid-cloud deployments, at 37%, was the most desired deployment. The full study results will be announced on Thursday, April 26, 2012 at 11 a.m. CDT as part of a BMC webinar. CSC Cloud Usage Index: Late last year, Independent research firm TNS surveyed more than 3,500 cloud computing users in eight countries around the world to find answers to cloud usage, expectations, attitudes and other cloud related questions. The survey focused on capturing user information about outcomes and experiences rather than predictions and intentions. In an interesting shift from the typical ‘cost savings’ and ‘business agility’ usually cited as a top motivator, one-third of respondents cite their need to better connect employees who use a multitude of computing devices as the number one reason they adopt cloud. 17% claim agility and only 10% indicate cost savings as a top reason for cloud adoption. 82% of respondents said they saved money on their most recent cloud project but 35% of U.S organizations reported a payback of less that $20,000. In terms of overall IT performance, 93% of respondents say cloud improved their data center efficiency/utilization and 80% see similar improvements within six months of moving to the cloud. Zenoss 100 Best Cloud Stats of 2011: Admittedly, this came out last year but it is still a great statistical overview of Cloud Computing. It starts with data growth stats, like 48 hours of video uploaded to youtube every minute; that 74% of Data Centers have increased their server count over the last three years accounting for 5.75 million new servers every year yet 15% do not have data backup and recovery plans; that, on average, cloud users report saving 21% annually on those applications moved to the cloud; that a delay of 1 second in page load times equals 7% loss of conversions, 11% fewer pages viewed and a 16% decrease in customer satisfaction; that Agility is the top driver for cloud adoption and Scalability the top factor influencing cloud use; that 74% of companies are using some sort of cloud service today yet 79% do not have an IT roadmap for cloud computing and a whole slew of others. All the stats appear to be attributed and run the gamut from storage to cloud to apps. Cloud Industry Forum (CIF) study: As enterprises continue to embrace cloud adoption, it is important for service providers to understand motivators for cloud adoption to ensure those services are being offered. This study, USA Cloud Adoption & Trends 2012 shows that smaller U.S. companies indicate that flexibility as their main driver for cloud adoption while large enterprises cite cost savings as their main reason for cloud deployments. This survey also noted that ‘Cloud’ is no longer a nebulous buzzword with 76% of polled organizations already using some sort of cloud computing for at least one service. Organizations are happy about it also – 98% said they were satisfied with the results of their cloud services with 94% expecting to increase their use in the next 12 months. Data security and data privacy were tagged as the top concerns with 56% and 53% respectively. By no means an exhaustive list of all the recent survey results pertaining to cloud and/or IT security, but they do offer some interesting data points to consider as organizations continue to strive to deliver their available applications as fast and secure as possible. psSelf Serve Security
Education of users has become a hot topic of late. The final keynote at the recent RSA Conference was all about using education to combat cybercrime. This article has statistics showing that, when Small and Mid-Market companies were asked, ‘what would help improve the level of security at their companies,’ 75% (48% for employees & another 25% for senior management) said Security Awareness. And, the recent issue of SC Magazine featured an article where Dan Beard, the Chief Administration Office for the House of Representatives says that organizations must educate end users and that end user education is the weakest link in cyber security. In that same article, Stephen Scharf, CISO at Experian explains: “The human element is the largest security risk in any organization,”…“Most security incidents are the result of human errors and human ignorance and not malicious intent. Therefore, it is critical that significant effort is focused on education and awareness to reduce these occurrences.” The human element has always played a role in security, cyber or otherwise. Growing up in Rhode Island, we used to always leave the keys in the ignition of the vehicles parked in our driveway. We felt safe were we lived – and granted, we lived in a rural area so the main crimes committed were things like stealing eggs from Carpenter’s Farm. Certainly, there are still plenty of areas and towns that have that type cocoon. As I went off to college in Milwaukee, I had to remind myself early on – ‘you’re not in Wakefield anymore,’ since I’d instinctively leave my wallet crammed in the sun visor of my Rabbit Diesel. I had to change my behavior when I moved from a small rural area to a larger city. Internet users must do the same but we are creatures of habit. Similar to leaving a wallet in the car, since that’s what I did most of driving life up to that point, many internet users still behave as if it’s 1995 and they are still on Prodigy. The threats are different and more severe but behavior is the same. Times change but sometimes people don’t, won’t or can’t. As all those articles point out, End User Education is vitally important to any organization and should be a key part of the overall IT security strategy. Users knowing what and what not to do when something seems fishy is an important part of your defense – especially when it’s something your firewalls, WAFs, IDS/IPS and other perimeter mechanisms might have missed. Education needs to be ongoing however and not a one shot deal since, according to Dr. Maxwell Maltz, it takes 21 days to make or break a habit. This has since been deemed a myth and everyone is different but it does bring up a good point. Security education, training and knowledge is not an overnight cram session – any security professional will attest to that. A single afternoon meeting going over ‘corporate policies for end users’ regarding information security will not help those who already have bad habits. It needs to be ongoing, consistent and relevant to their daily lives, including the serious consequences of poor behavior. Help users understand the risks/threats, break the bad habits that might lead to exposure and secure your infrastructure in a way that no piece of hardware/software can. Help users help themselves. While not directly security related, F5 recently started offering Free Web Based Training for our end users. IT admins are end users too, ya know. F5 Networks Web-Based Training (WBT) courses introduce you to basic technology concepts related to F5 technology, recent changes to F5 products and basic configurations for BIG-IP Local Traffic Manager (LTM). These are self-paced and you can access them at any time and as many times as you like. The cool thing is if you complete all of the lectures and labs for the LTM Essentials WBT, you have met the prerequisite requirements for the Advanced Topics, Troubleshooting, and iRules classes. ps Related Items: F5 Networks Web-Based Training It all comes down to YOU - The User Weakest link: End-user education Information security policies upended by untrained end users Update your security lessons for end-users The Hugh Thompson Show (RSA) FREE TRAINING!!! …in case you didn’t know
