ASM blocks clients that don't accept cookies

Hi Mike, thank you for your input, it's very much appreciated.

 

 

Cookies are sent to the browser by (what we term as) the front-end application, and ASM. For clarity, our environment is LTM>ASM>IIS-front-end>IIS-back-end>DB.

 

 

I'm nervous of logging all traffic as this is a high use application. I might try this out-of-hours.

 

 

It looks like the web scraping settings caused this issue:

 

I put the whole ASM policy into transparent mode and the application started working again for clients that don't support cookies. After some digging in the ASM logs (straight off the unit, not through the GUI) I could see my testing machine being blocked for web scraping. After setting ASM back into blocking mode but with scraping set to alarm only, again the application works.

 

 

So that's got to be scraping, right?

 

 

Scraping is set-up as follows:

 

Grace interval = 200

 

Unsafe interval = 1000

 

Safe interval = 2000

 

White-list = all-my-subnets

 

 

What's strange is that I was getting blocked immediately, i.e. not after 200 requests whilst ASM figures out whether or not I'm human. I guess that means ASM knows pretty instantly that I'm not human because I didn't even accept the cookie? ASM also seemed to ignore the white-list of our subnets.

 

 

It is a problem for us if we immediately block people who don't allow cookies. My understanding of the grace interval was that it'd allow 200 requests as a kind of free pass *before* it blocks, the ASM config guide states:

 

"The grace interval is how many requests the system reviews while trying to detect whether the client is human. During the grace interval, requests are not blocked or reported. What occurs next depends..."

 

 

 

So, two questions:

 

 

Is the grace interval a free pass or just the most requests that ASM will allow until it decides human/robot?

 

 

and

 

 

Why did ASM ignore my white-list?

 

 

Thanks, Steve