It seems some ASL rules (like rule 300079), block the request and add the IP address to the block list for a 10 minute shun, while other ASL rules (like rule 300061) block the request, but don't add it to the firewall for a 10 minute shun. Both have active response turned on.
What level do you have 300061 set to? If the level is less that the minimum level you have configured globally to shun, the rule will not shun even if you set active response to yes.
Also, if your IP is on your systems whitelist, you will get blocked, but not shunned. Check to make sure the IP you are testing from is not whitelisted.
The first case, where the ip is added to the block list for a 10 minute shun, does result in a shun since i ran asl -s -f earlier today.
So shunning is working. If shunning works for some rules, and not others, that means either the rule is configured at a level lower than your global minimum to shun, shunning is disabled for the rule, or the IP or network is on your whitelist.
Do you want an output of iptables -L ?
Dont need it now, shunning is working for some of your rules, so its not likely your firewall rules, it may be just a configuration issue. See the previous questions. Lets see if thats the issue.
See the response i added to ticket 16659, where i added two urls for you to check. One is an existing directory without an index page, which results in a real 403 Forbidden page. The other is the same domain, but a spam uri attached to it, which is handled by ASL, and results in an apache 2 test page. So, how can apache respond differently to the exact same 403 code, on the same domain/site? The only thing i can think of, is that when ASL handles the response, the 403 that ASL produces is not going through the webhosting account that holds that site, but is routed through a different path by apache... eventhough it does show up in the access_log for that domain? It used to not show the test page upto a month or 2 ago i think when i got shunned last.
So I hope this long explanation helps. The short answer is: Use the redirect option. Redirect always works, Apache = painful to setup correctly for this kind of stuff and can be overridden by lots of stuff (so its hard to debug too).https://www.atomicorp.com/wiki/index.ph ... DIRECT_URL
Long answer. Lots of things control how apache responds to error codes. They are codes, and apache must be configured what to send when it gets the error code. For example, the test page you mentioned is configured somewhere on your system to respond to certain error codes, it may be the fall back page if there isnt an otherwise defined code. ASL does not configure or control any of this. Its 100% at the mercy of Apache. Whatever Apache is configured to do, Apache does. ASL does not control or override that (for embedded mode, if the T-WAF is protecting an apache instance, then ASL does whatever it wants because it controls the response).
These responses can be changed anywhere in the process with Apache, they can be changed in an htaccess file, in the global config, in document directives, in LocationMatch directives, in mod_rewrite rules, in an application itself, the vhost config or even just the phase at which the rule is triggering and how apache handles error codes in that phase. Its hard to say for your system and unique configuration.
And theres a reason we dont bother to try to control that, aside from all the other ways people can change that behavior with or without your knowledge (.htaccess for example, and we dont want to try to manage .htaccess files), its also not a very powerful system. Its all error code based, and thats very limiting.
So we have an option in ASL that lets you send whatever you want to your client, however you want. Its call "redirect". If you want ASL to control the response, then you need to use the redirect option in ASL. ASL controls that completely. If you dont use redirect, then its a mad house of whatever apache, the domain, .htaccess files, apps, etc. are configured to do, and as you can see Apache does odd things. This is one of the reasons the redirect option exists.
The other is power. Redirect is WAY more powerful that the apache Document directives. You can fine tune it and send back anything you want to the client, you can use variables in the redirect, you can send the redirect to a different port if you want, a different server, a different (or the same) domain, whatever you want. Its very powerful. Did I mention its powerful?
Heres some things you can do with redirect:
1. Unlike apache error code pages, you can generate highly customized and specific responses to users, for example, you could say for a given IP, a given time of day, for a given spam rule ("Sorry the word "foobar" is not allowed, please try your post again"), for a given username, etc. they get a unique response
2) You could look up the rule, temporarily whitelist an IP with a password.
3) you could disable a rule for a domain
4) You could send an attacker to a honeypot
5) You could send an administrator to the ASL gui to change a rule.
6) You could give a user a CAPTCHA, and if they passed it send them a cookie and disable a rule
7) You could send attackers to a different page than spam rule violators
The skys the limit. Whatever you want to do.
In the future, we are going to include a redirect PHP application that will give you a nice template and some powerful code you can use out of the box to do these things (so you dont have to code this yourself). The point is, the redirect options lets you send a user anywhere you want, including your own apps to respond to ASL events anyway you want, and display anything you want for the client and even allow them to interact with ASL (if you want them to). You can do all sorts of neat things with redirect.
As the person that started out over 10 years ago writing mod_security rules and trying to get apache to return different results for different events I can tell you that the apache error code route is painful, time consuming, very limited and ultimately not very rewarding. redirect is a snap, you can do whatever you want consistently.
I hope this helps you to understand what you are seeing. My advice, use redirect. Thats what its there for, it puts you in control and will bypass anything someone does in apache anyway you want. If you want use the apache error code stuff, then unfortunately you'll have to go thru your apache configs and do some debugging. My guess is that its falling back to some default "I dunno what to do!" page, hence the test page.