Forum Discussion
BlackBolt_22590
Nimbostratus
NimbostratusSome questions about ASM module from a beginner
Hello Everyone,
My company recently bought some ASM licences for our F5 Big IP and i'm in charge of defining the security policies but I have no experience in it so far and a read only accoun...
BlackBolt_22590Nimbostratus
NimbostratusHello all,
So I finally was able to perform some tests on a lab on VMWare Workstation on a lab with Hack-it-yourself PHP. I reproduced one attack to see the behavior of both policy construction (automatic and manual): . Here are the scenario for both construction mod after creation :
Manual:
Signature stagging : enabled
Renforcement Mod: Blocking
Learn Alarm Block checked for 3
ERP: 7 Days
Automatic:
Signature stagging : enabled
Renforcement Mod: Blocking
Learn Alarm Block checked for 3.
Policy Builder Enabled
ERP: 7 Days
Policy mod : Comprehensive
When I uncheck "signature stagging" on manual policy, the script is blocked right away but when i do it with the automatic policy, it doesn't block it and i can't figure out what prevent me to block it. My guess is the policy builder but when i disable it, it still doesnt block my script request so someone can explain to me the behaviour of a automatic policy, the policy builder and the policy mod. this is the kind of log i have with automatic policy:
https://puu.sh/vMtRL/0ba67eb302.png
Also where do you decide if this specific request is a false positive?
If I understand it correctly, this is where you decide if a signature is a false positive (screenshot below) but where do you precise request and request coming from a specific IP is safe?
https://puu.sh/vMu3R/aa50bc2da4.png
Another "strange" behaviour i have, as you can see i have signature stagging enabled and my policy in blocking mod. Doesnt the security policy suppose to not block the traffic that triggered some signature and just report them where i decide afterward if i block them or not? I'm asking you that because my policy still keep blocking the traffic that triggers the signature :
https://puu.sh/vMubP/996be50a7e.png
Leonardo_SouzaCirrocumulus
Answering the first question, you have to enforce the entities learned by the policy builder. Answering the second question, you can decide what to do with the learn suggestions, include ignoring. Answering the third question, in the ip address exceptions. Answering the last question, blocking mode in the policy is the general behavior, a signature can still been in staging or have been removed already from staging. That setting is just to say if you do stage signatures or not, but does not tell if a signature still in stage or not.
- BlackBolt_22590
Thanks Leonardo for your answer. One more thing (maybe the last :)), it's about ressources and deployement. I have about 400 VS to protect with ASM. Some Nodes and pools that are used multiple times. I am planning to deploy a policy by pool (if Pool A is used in VS 1,2,3 & 4 i'm going to deploy a policy for VS 1 to 4), do you think the ressources are enough to deploy this way knowing i'll create about 20-30 policies?
Regards,
- Leonardo_Souza
You can assign the same policy to more than one virtual server. The main reason people normally have one policy per virtual server, is because a policy is basically a mapping of the application. If the applications are different that requires a different virtual server per application, they should have a policy for each virtual server.
That said, if they share the same application in the backend server, they could have the same policy, but in that case why you have multiple virtual servers for the same application?
About sizing, I can't tell you if you will break the box with that ASM configuration. There are many things to check on that, as I think it will be difficult for you to calculate that, I suggest that you add one policy each time and check the resources for a couple days. Don't forget that there is a lot of work that occur initially to map the application, but after is just analyzing traffic and blocking things.