BlockCracking 1.3

[DirectAdmin Support]

Removed 2 lines from the script.denied_paths.default.txt, as they were blocking things they shouldn't have:

[COLOR=#333333]^.*/wp-content/themes.*[/COLOR]
[COLOR=#333333]^.*/wp-includes.*

Related thread:
[/COLOR]http://forum.directadmin.com/showthread.php?t=51323&p=264827#post264827

John

 

[LawsHosting]

Maybe we need to re-think about how this is implemented?

I understand the WP theme directory shouldn't use any mail scripts - I only installed the Exim 4.3.3 system yesterday, and a few hours later received an email (see other thread) about a script being used in the theme directory. I'm not that clued up with Wordpress. FYI, the theme that this client using is http://themeforest.net/item/bridge-creative-multipurpose-wordpress-theme/7315054 if it helps

 

[DirectAdmin Support]

BC 1.3 removes the themes directory from the block.

John

 

[SeLLeRoNe]

I'm not that sure that a Theme folder should send email, specially not using SMTP Auth.. Honestly i would prefer to keep the themes folder as blocked.

John, there is a way to have custom paths? So everyone can decide to add/remove specific paths, would be better i suppose

Regards

 

[Richard G]

I agree with Sellerone. Themes should use the default options where mail is expected and not have mail systems in them.
Since opinions differ, an option with custom paths would be nice.

 

[DirectAdmin Support]

Note that this has no control over SMTP-Auth to localhost port 25. Exim cannot determine which script/path is doing the socket connection via smtp-auth.
As for the themes folder, I'm happy to put it back, but just need to know exactly if it should actually be there or not. If the previous poster had a "bad" plugin that shouldn't have been sending via themes (and should have called the php-mailer), then let me know.

Custom: Yes, I know better than to not give you custom options
Create copy the file to:

/etc/exim.blockcracking/script.denied_paths.custom.txt

and then do the

./build exim_conf

The script.denied_paths.custom.txt overrides the /etc/exim.blockcracking/script.denied_paths.default.txt, and CB creates /etc/exim.blockcracking/script.denied_paths.txt, which is used.

John

 

[LawsHosting]

If the previous poster had a "bad" plugin that shouldn't have been sending via themes (and should have called the php-mailer), then let me know.

If that was to me, then its calling the /includes/class-phpmailer.php, from /public_html/wp/wp-content/themes/bridge/includes/ajax_mail.php. This is the script: http://pastebin.com/qVtCHbMd looks genuine to me.

 

[SeLLeRoNe]

Well probably there are some good script that would use to send email from theme folder, i dont doubt that, but mostly of the mail script on hacked wp are using theme folder and include folder aswell.

I use to tell my customers to always use smtp auth, so this can prevent every problem keeping blocking those folders

So, another maybe working thing sould have a whitelist path file, where to set specifically full paths that are able to send mail as for example /home/USER/domains/DOMAIN/public_html/wp/wp-content/themes/bridge/includes/ajax_mail.php

Should be that a working solution?

Regards

 

[ClayRabbit]

In my opinion, it wold be better to exclude local_domains from script.recipients verification, since it can block legitimate script if it sends lot of mail to some local address which suddenly become unavailable (suspended domain, over quota, catch-all set to :fail:, etc). Yet the conception of script BlockCracking is mainly based on counting remote addresses, not local ones?

Oh. I just thinked the best solution will be to add /unique=$acl_arg1 option to script ratelimit (and also use per_addr instead of per_rcpt in auth.conf)

 

[LawsHosting]

So, another maybe working thing sould have a whitelist path file, where to set specifically full paths that are able to send mail as for example /home/USER/domains/DOMAIN/public_html/wp/wp-content/themes/bridge/includes/ajax_mail.php
Should be that a working solution?

Going back to this. It'll be a pain in the butt for us (and to the client) needing to add paths to a file manually every time a client complains their mails aren't being sent.

Heck, wordpress hasn't a native way to send email via SMTP without a plugin!

 

[ClayRabbit]

It seem's there is a bug in BlockCracking - actual number required for script blocking is up to 2xBC_LIM, since we have 2 ratelimit directives with different keys: one inside script.recipients.conf with key "script-$acl_m_script_path", and one inside script.conf with key "user-$acl_m_script_path"
And both ratelimits have to bee exceeded for blocking command to be executed.
Strange combination of per_cmd ratelimit followed by per_rcpt ratelimit makes actual number of bad addresses needed for blocking not so predictable.
I think "ratelimit = BC_LIM / BC_PERIOD / per_rcpt / user-$acl_m_script_path" should be removed from script.conf