I just found out that attackers get an Apache 2 Test Page, instead of being shunned for 10 minutes. I just tested it myself by throwing an sql injection string at one of my sites. I got the test page, and i was immediately after that able to visit the site in the regular way. I did notice my IP (and a lot of others) being listed in the ASL block list, but it seems this block list is not really doing anything at all. This means that an attacker can retry and refine his attack attempts immediately. And as i have observed in the logs, this is happening a lot for sql injection attackers, virtual just in time patch, and spammers.

In the ASL log i also see the response being "HTTP/1.1 403 Forbidden", but that does not really correlate with the Apache 2 Test Page i receive.

Another issue is that the time for the blocks are 1 hour off. For example, if i do an injection at 4am, it is listed in ASL as 3am.

take a look at your firewall: iptables -v -n -L | less

At the top you should see the IPs in the blocklist being blocked, plus some links to the ASL-* tables.

If those aren't there---are you using an additional firewall (e.g. apf)?

I'm not sure what's happening with the Apache default page. That's interesting. What's your OS and ASL version?

The clock thing is a known issue. You just need to add a timezone to the asl php.ini. If you do a search on the forum you should find a reference somewhere. I'm sure the guys will resolve it soon.

It sounds like firewall rules might be setup or loaded wrong, can you run asl in scan and fix mode to set your rules right? Just run this command as root:

asl -s -f

The -s flag in asl -s -f fixed it. The DROP rule was missing in:

Chain ASL-ACTIVE-RESPONSE (22 references)
target prot opt source destination
DROP all -- anywhere anywhere

The apache 2 test page still displays when an attacker does the sql injection the first time. Is that normal? In the old situation he would get a 403 status code.

As it seems (since i just got iptabled from here for using a spam word by accident), that the apache 2 test page is not what should be displayed right before a shun is set, as the response from your server when i post somethig with a spam word, is a regular 403 response.

Not only that, on my server spammers do not seem to get shunned, which is fine by me, because shunning on single spam words would result in a large number of false positives, but an apache 2 test page gives the wrong response to those users as well, suggesting there is nothing on that website anymore.

On the other hand, i do have one domain on this server where spammers are constantly hammering that website (several 100s per hour), so it would be nice if a responsetype (block, or 10 minute shun) could be set on a per domain basis per rule.

What apache send for a 403 is controlled by your apache config, not the WAF. The embedded WAF does not control what apache sends (unless you use the redirect option, in which case the WAF sends the user to a page of your choosing). The WAF just sends a 403 to apache, and as you may know, apache then sends whatever its configured to send - and in your case it sounds like that may be the test page.

If you use redirect, then you can send your users to anything you like. It sounds like you may want to use redirect, or change your apache config to send them to a 403 page. I believe if a 403 page is not defined, then apache falls back to the default page, which may be the test page. Perhaps thats whats happening in your case?

If you use redirect, then you can just dispense with all apache config issues, and send your users to a page of your own choosing, and you can pass in variables as well so the page could dynamically reflect the type of event that was triggered (spam, attacks, etc.).

If you do not use redirect, then the WAF send a "403" (or whatever is appropriate for the rule, some are 404, some are 5xx, etc.) and then its apache that sends whatever its configured to send for that error code.

ASL always displayed the "Forbidden" page before, and when i go to any directory on any of my sites where the directory exists, but there is no index page, those do come up with a 403 Forbidden message. So apache knows what to display, just not for ASL responses it seems.

Also, i don't know why i get shunned at atomicorp.com for posting a spam word, but when i do the same thing on my sites, it does not shun me eventhough active response is on.

EDIT: I have added a note to the ticket with 2 urls so that you can test ths yourself.

ASL does not control what apache sends in the response. The modsecurity module in apache sends the error code to apache in that phase, and apache does what it wants with the error code.



What are you iptables rules? Perhaps you have an allow rule that is bypassing the shuns?

Also, if you run the command "asl -s -f" ASL will try to fix your rules so this is not the case, what happens after you run "asl -s -f" are your shun rules working? And if not, please post your iptables rules (iptables -L -n -v).

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.

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.



Do you want an output of iptables -L ?



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.

EDIT: I found that the issue for the apache 2 test page was the apache welcome.conf file in conf.d which directs to noindex.html. So it seems the 403 that ASL sends out, is handled differently by apache than a regular 403. So that issue has been taken care of now The other issue of not all rules with active response on resulting in a 10 minute iptable shun is still in effect.

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.



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.



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.



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.

300061 is set to level 7, just like most other rules such as 300079. The difference is that hits on the first one do not get shunned for 10 minutes, while hits on the last one do. My ip is not whitelisted. It was before i started testing this earlier today. I also can't find a setting to globally set the shun threshold. There is an option called "HIDS_EMAIL_ALERT_LEVEL" which is set to 7, but that is probably not what you are referring to.

Now, i don't mind that hits on 300061 are not shunned due to a large number of false positives (for hits on a single spam word), but this is probably not the only rule where this is different. So i'd like to understand what causes a rule to fire a shun or not, especially since the levels are the same.



I found the cause for the test page: I found that the issue for the apache 2 test page was the apache welcome.conf file in conf.d which directs to noindex.html. So it seems the 403 that ASL sends out, is handled differently by apache than a regular 403. So that issue has been taken care of now

Redirect may be an idea, but the redirect setting in the ASL config is set to the default "https://%{server_name}:30000/blocked.php?eventid", and since redirects go to a 403 page, i assume that setting only works if T-WAF is enabled, which it isnt due to me having plesk on a non standard port for security reasons. I read on this forum, when T-WAF just came out a couple of months back, that it doesnt work if Plesk is on a non standard port.

Oh the redirect actually does work with T-WAF disabled, i think i was confused with the Plesk WAF that didn't work with the alternative plesk port. There is one issue with the redirect though, and that is that the redirect url seems to require port 30000 and SSL, which i can't seem to change (the change is in the config window, but not reflected in action). And the variables also don't seem to be included in the url string, so the url that should be https://server/blocked.php?eventid=id ends up being https://server:30000/blocked.php?eventid . The thing with SSL, if you have no browser-recognised SSL cert, is that the browser will ask the user for accepting the page to be loaded (and for an exception to be added), and by the time the user has accepted it, the iptables ban has already been set, so the page would never really show up. I'll go back to simply denying access and no redirection.

Anyway, most of the issues in this thread seem to be solved now, which is good enough The banning on rule 300061 seems to be intermittent, so 90% of the times it doesnt set a ban, and 10% of the times it does, from what ive seen through testing it the past few hours. Not sure what is going on there, but as long as more important rules do result in a shun, i'm okay with it.

Thanks for your help in this thread Mike Shinn

Which version of asl-web do you have installed?

rpm -qa | grep asl-web

Please let us know when this is in operation as I would like an out of the box option that will be a good foundation that can be built on.