Wish List (Please post your wishes here)

Free Modsecurity rules - Comodo Web Application Fi
41

Is this something you can implement as a rule:
http://www.incapsula.com/blog/semalt-botnet-spam.html ?

42

I found some good rules for blocking semalt and buttons plus more here:

In particular, copy from the rules folder flameeyes_30_refererspam.conf and flameeyes_bad_referrers.data

Be careful what else you copy over. I first put everything in my modsecurity.d directory and it ended up giving everyone a 403 when viewing sites on my server. Not sure yet which rule did it.

It would be great if similar rules could be included here!

43

Plugin for http://centos-webpanel.com/ :P0l

44

Hi,
I want a webmin plugin. Allright. I can see there is a directory called webmin. I copied the content in the plugin path of webmin and renewed the available modules information, but nothing changed.

So I think the module is not working yet. But in the near future?

Mike

45

Hi Mike

We have done some Webmin research but it’s not active in current plugin version.
Webmin plugin will be fully functional in nearest release (2.9) scheduled on next Tuesday.

Best regards, Oleg

46

Hi Mike

Webmin plugin is released :slight_smile:
Please check here.

Regards, Oleg

47

It would be great for directadmin if you can add:

  1. statistics page
  2. user level extension so users can see what problems do they have on their web page
  3. user level and admin level should have the option to block certain countries (china,etc…)
48

By the way customers can add country-based protection right now using custom rules.
Here is instructions:
https://forums.comodo.com/free-modsecurity-rules-comodo-web-application-firewall/how-to-block-access-to-your-site-from-certain-country-t112172.0.html

Regards, Oleg

49

G’day Team,

This was raised quite a while ago and TDmitry replied at…

https://forums.comodo.com/free-modsecurity-rules-comodo-web-application-firewall/configuring-a-global-modsecurity-message-t111927.0.html;msg812601#msg812601

…but it’s still a very needed unavailable feature…

Could we please have a simple and single location within CWAF where a generic message can be configured to advise the user that a modsecurity rule has blocked their access?

Can secdefaultaction specify a default redirect for example which will apply to all filter actions?

Best regards,

LBJ

50

Since CWAF rules generates 403 error code in most cases so the simplest solution would be to modify your default 403 webpage with an your generic message.

51

Yes, but a 403 is raised for a lot more than just modsec. However, a global redirect from SecDefaultAction allows a message to be provided for just CWAF blocking.

52

I’m getting brute-force attacks on wp-login.php that use the same username, but don’t use the same IP address more than once or twice, so they get by the IP-based brute-force attack rule currently in Comodo WAF.

I would like to see Comodo include a rule that would block brute-force attacks on wp-login.php based on username, independent of IP address.

Thanks!

53

As I understand wide spreaded bruteforce attack could be detected but protection would lead to numerous false positives because we can’t know who from legitimate users and from where willing to login. In this case better to use any captcha or whitelisting mechanism.

54

can you give us exactly what do you have in mind as a rule? Few use cases would allow us to understand if this will cause too many false positives or not.
thanks

55

I was thinking that after a set number of failed logins using the same user name, additional logins using that user name would be dropped for a set time period. Sort of the same as your brute force protection based on IP address, but using the user name instead of the IP. I’ve seen this sample for a Rails application, but I wanted one specifically for WordPress/wp-login.php:


# Username-based blocking.
<LocationMatch /sessions>
        # Retrieve the username
        SecAction phase:2,nolog,pass,initcol:USER=%{ARGS.username}

        # Enforce an existing username block
        SecRule USER:bf_block "@eq 1" \
                "phase:2,deny,\
                msg:'Username \"%{ARGS.username}\" blocked because of suspected brute-force attack'"

        # Check that this is a POST
        SecRule REQUEST_METHOD "@streq POST" "phase:5,chain,t:none,nolog,pass"
                # AND Check for authentication failure and increment counters
                # NOTE this is for a Rails application, you probably need to customize this
                SecRule RESPONSE_STATUS "^200" \
                        "setvar:IP.bf_counter=+1"

        # Check for too many failures for a single username
        SecRule USER:bf_counter "@ge 3" \
                "phase:5,t:none,pass,\
                setvar:USER.bf_block,\
                setvar:!USER.bf_counter,\
                expirevar:USER.bf_block=600"
</LocationMatch>
56

What you were asking about false positives finally registered, and I realized how impractical blocking by user name would be. What I’ve been seeing is a bunch of login attempts with user names we don’t even have registered brute forced from a variety of different IPs. Blocking them wouldn’t be an issue because they aren’t real users, but if we had a rule to do so, it could be used to intentionally or unintentionally block legitimate users. I can’t think of a way around that using ModSecurity; it would probably have to be done at the application level or with a whitelist of IPs, and too many users don’t have dedicated IPs, or access sites from a variety of them. Sorry about the confusion.

57

Any update about this wish? :slight_smile:

58

Unfortunately, we don’t develop plug-in for ISPConfig.

59

Is it in the planning road, at least?

60

No, it doesn’t