Assign an existing Security Policy through Python SDK
Can I assign to an Existing Virtual Server an existing Security Policy? Not a local Traffic Policy, I have already created a Automatic Security Policy through the Deployment Wizard but I would like to automate the process through a Python Script. Thanks in advance.Activate a Policy through F5 Common Python
I tried to activate a policy, which is inactive once is created this way: policy.modify(active=True) Obviously it is worng as I have guessed from the answer, which is this one: '{"code":401,"message":"Policy must be applied and/or activated by a Task" What are the tasks and I how can I have a code to do this? Thanks in advanceF5 ASM Policy Backup
Hi gents, I would like to know, if i can duplicate a ASM policy with all its learnings like parameters etc? Because we are now in Production for some application and in the near future we would like to develop a following version of this Application. But how can i maintain this ASM policy with versions, so in case i need to rollback all the changes made to the policy. What i want now is that the current version of ASM policy will be 1.0, with all the learnings/parameters/URL's etc, i want to develop the v2.0 to new patterns learned for the new apllication. And when we go live with the 2.0 of the Application, i want to have the ASM policy 2.0 pushed to the Production, with learnings of 1.0 and 2.0.
Full 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.
La transition vers HTTP/2, l'envisager, s'y préparer, la réaliser
HTTP/2 est désormais un standard avec son support intégré dans les browsers modernes. Les serveurs Web, proposent aussi dans leurs dernières versions, la compatiliblité avec cette évolution. Ce qu'il faut retenir est qu'HTTP/2 vient accéler le transport du contenu Web en maintenant la confidentialité à travers SSL. Un des bénéfices pour les developpeurs et fournisseurs de contenu est la capacité à se rendre compte des apports de ce protocole sans remettre en cause toute son infrastructure. Les démonstrations montrent bien les gains à travers un browser sur un ordinateur portable, choses encore plus appréciables sur les plateformes mobiles. La version 12.0 de TMOS permet de se comporter comme un serveur HTTP/2 vis à vis des clients tout en continuant à solliciter le contenu en HTTP/1.0 et HTTP/1.1 auprès des serveurs. Pour trouver des raisons de s'interesser à ce protocole, plusieurs sources d'information peuvent y aider : Making the journey to HTTP/2 HTTP/2 home
