Forum Discussion

Michael_Madewel's avatar
Michael_Madewel
Icon for Nimbostratus rankNimbostratus
Sep 09, 2020

F5 ASM: How to prevent site from being used to validate stolen credit card numbers

We have a local government web application that allows citizens to make donations via credit card to a city program, e.g. the animal shelter. Lately there have been a string of suspicious credit card transactions wherein a single "donor" will attempt to make a series of donations, about 30 seconds apart, using a different card number each time, generally in the amount of $1. Most of the transactions are denied with validation errors indicating lost/stolen card, invalid number, etc. Occasionally the transactions will be approved. Our assumption is that this is a bad actor attempting to validate a list of stolen card numbers to determine which can be used for larger transactions elsewhere.

 

Any suggestions on how to leverage the ASM to prevent this?

  • Yes, you can leverage session tracking and Data Guard to mitigate this. Your goal is to configure session tracking to allow clients a fixed amount of incorrect "guesses" per minute. This gives legit clients a chance to correct their mistake--before a sixth wrong guess gets blocked for a duration of your choosing. First go to the learning and blocking settings page, and ensure the violation Data Guard: Information leakage detected is set to block (optionally you can do learn and alarm also.) Then configure the Sessions and Logins violation Access from disallowed User/Session/IP to block. Second, go to your Data Guard settings, enable Data Guard, and then configure a Custom Pattern which matches the failed criteria your application is sending in the response payload--probably a string that says "invalid number" or "try again" or something like that. Third, add the URL you wish to protect (this is the one that is getting repeated hits.) Fourth, go to Session Tracking Configuration, and enable Session Awareness. Fifth, enable the option to Track Violations and Perform Actions, and then define the Violation Detection Period for 60 seconds. Sixth, enable IP Address Threshold for 5 violations and Delay Blocking Period for 3600 seconds. Directly below the Delay Blocking Period settings, you can the list of Associated Violations. Move the Data Guard: Information leakage detected violation from Available to Selected. This allows legit clients to make 5 login mistakes in 60 seconds, and the sixth mistake results in that client getting blocked for an hour. That should make the bad actor move on to some other target. If you like, you can specify that if a client generates 10 Data Guard violations in 60 seconds, then the Block All Period is Infinite--basically that client/session is shut down forever.

  • Yes, you can leverage session tracking and Data Guard to mitigate this. Your goal is to configure session tracking to allow clients a fixed amount of incorrect "guesses" per minute. This gives legit clients a chance to correct their mistake--before a sixth wrong guess gets blocked for a duration of your choosing. First go to the learning and blocking settings page, and ensure the violation Data Guard: Information leakage detected is set to block (optionally you can do learn and alarm also.) Then configure the Sessions and Logins violation Access from disallowed User/Session/IP to block. Second, go to your Data Guard settings, enable Data Guard, and then configure a Custom Pattern which matches the failed criteria your application is sending in the response payload--probably a string that says "invalid number" or "try again" or something like that. Third, add the URL you wish to protect (this is the one that is getting repeated hits.) Fourth, go to Session Tracking Configuration, and enable Session Awareness. Fifth, enable the option to Track Violations and Perform Actions, and then define the Violation Detection Period for 60 seconds. Sixth, enable IP Address Threshold for 5 violations and Delay Blocking Period for 3600 seconds. Directly below the Delay Blocking Period settings, you can the list of Associated Violations. Move the Data Guard: Information leakage detected violation from Available to Selected. This allows legit clients to make 5 login mistakes in 60 seconds, and the sixth mistake results in that client getting blocked for an hour. That should make the bad actor move on to some other target. If you like, you can specify that if a client generates 10 Data Guard violations in 60 seconds, then the Block All Period is Infinite--basically that client/session is shut down forever.

  • Thank you so much for the most detailed response to a forum question that I believe I have ever received. Brilliant!🙏