Forum Discussion
negin_297580
Nimbostratus
NimbostratusAsm methods
What are the methods of deploying in asm?
Hi Negin:
Your question is a bit vague in terms of deployment modes. A few different ways to intrepret.
If you are referring to how can ASM be inserted into a network topology. It can be inserted in one of two ways:
1. Reverse Proxy mode, attached to a virtual server object. In most environments this is the simplest and most effective approach.
2. L2 transparent bridge mode. This is for environments where ASM needs to be inserted with no other network changes allowed. More information can be found here: An
** You may find this document useful in this discussion: Key Considerations in Choosing a Web Application Firewall
If you are referring to whether ASM can be deployed in blocking/transparent/learn mode. ASM on a per-policy basis can be configured as blocking or transparent. Then again, for individual policy elements you can determine whether you want ASM to Learn, Log, or Block.
Finally, if you are referring to ways to build and deploy an ASM policy. ASM can be configured to build security policies in the following ways:
1. Automatically, where ASM learns policy elements and automatically configures.
2. Manually, you will manually define policy elements or use pre-existing templates to import. Note, even when building manually you can still configure ASM to learn these elements, and then manually deploy them to the security policy.
3. Create a policy for XML or web services
4. Import results from a 3rd party vulnerability scanning tool to build the security policy.
** The following devcentral article might be helpful BIG-IP ASM Part 2: Policy Building
Hi Negin:
Your question is a bit vague in terms of deployment modes. A few different ways to intrepret.
If you are referring to how can ASM be inserted into a network topology. It can be inserted in one of two ways:
1. Reverse Proxy mode, attached to a virtual server object. In most environments this is the simplest and most effective approach.
2. L2 transparent bridge mode. This is for environments where ASM needs to be inserted with no other network changes allowed. More information can be found here: An
** You may find this document useful in this discussion: Key Considerations in Choosing a Web Application Firewall
If you are referring to whether ASM can be deployed in blocking/transparent/learn mode. ASM on a per-policy basis can be configured as blocking or transparent. Then again, for individual policy elements you can determine whether you want ASM to Learn, Log, or Block.
Finally, if you are referring to ways to build and deploy an ASM policy. ASM can be configured to build security policies in the following ways:
1. Automatically, where ASM learns policy elements and automatically configures.
2. Manually, you will manually define policy elements or use pre-existing templates to import. Note, even when building manually you can still configure ASM to learn these elements, and then manually deploy them to the security policy.
3. Create a policy for XML or web services
4. Import results from a 3rd party vulnerability scanning tool to build the security policy.
** The following devcentral article might be helpful BIG-IP ASM Part 2: Policy Building
negin_297580Hi dear Michael Everett . I really thank you for your complete answer ,it was very useful ,you even answered my unasked questions. one remaining question is about advantages and disadvantages of one-arm reverse proxy and two arm reverse proxy,if you had an article or a great answer like the one you gave me last time,i'd be thankful if you share .
Hi Negin.
 
Probably lots of folks have varying opinions on this, however, from my view it really comes down to your network environment and application team requirements. Often, folks go with two-arm approach when the application servers response already comes back through ASM (e.g. use ASM as server default gateway), and the application team needs to see clients IP address in a L3 header (not X-forwarded-for header). In this case, they do not want ASM to perform SRC NAT (SNAT) on connection before sending to server. Also, even when they want to SNAT, some folks like completely separating the client side and server-side flows in terms of IP addressing, so they will use VIP net for incoming client traffic, and also give ASM an interface on server subnets and SNAT towards server using one of these addresses.
 
In case of 1-arm, sometimes folks just want a simple deployment, and they drop ASM/LTM in on new VIP subnet, and then just SNAT with an address of this subnet. This can be done w/o much change to network, but requires SNAT. Also, customers will sometimes use 1-arm if the backend server environment is large, and servers are scattered across the DC. So, they can steer all traffic into ASM via VIP network, but do not want to have ASM with an interface in all the server segments. In this case, they might just SNAT from same VIP net.
 
All in all, there are lot of different scenarios that might come up, and each environment is different. You might have many paths through a network, and may need to accomodate different requirements as time goes along. One thing to keep in mind, this does not necessarily have to be an all or nothing approach. You can have some apps that you deploy as single arm, and others than are deployed in two arm manner. Also, it is not at all uncommon to have customers deploy internal ASM/LTM deployments in single arm, and then for DMZ/external environments use a 2-arm design.
 
Here is a DC thread with customers/F5ers discussing the pro's/con's: https://devcentral.f5.com/s/feed/0D51T00006i7TnkSAE
 
HTH