Directadmin 1.39.0 - Release Candidate 1

Wunk said:
Yes please :)

We're getting overwhelmed with paranoid customers that suddenly think their server is being hacked.
Click to expand...
Can I second that motion for disabling this ridiculous feature?

I just got called out of a nice warm bed after updating DA last night because our notification mailbox suddenly was filled to the brim with 'brute force attacks', which turns out to be simply a lot of expired and removed mail accounts that are still being popped every 1 to 5 minutes from somewhere on this world.

If a feature generates 100% false positives every half hour on a regular server - please do not suddenly enable it by default.

[edit]
Same goes for that email counting feature a few updates back by the way. I propose that if DA introduces a new feature on an existing server which may cause a lot of unexpected extra warnings we get a single message from the patcher saying that feature X is now available but disabled by default because it might need some tuning first.
 
Last edited:
I'm not opposed to disabling it by default, however I'll throw out one last suggestion before doing so.

What if the default count were a very high value. This would probably skip over the false positive cases (pending how high we go) but still have the logging active.

Or set it up such that you can set a limit value of 0 (default) which would mean that no notices are sent out, but the logging is still done.

I'm also adding a brute_force_notice_pre.sh, which would let you manually have exceptions.

John
 
I am only speaking for myself of course, but I do not need the feature and do not want the feature. I am using CSF/LFD, and don't see any reason to have the brute force monitor feature enabled. I have disabled it, and will be happy as long as you let us have the option to disable it completely.
 
I think that for new supplemental behaviours such as the brute-force scanner and the mails-per-day counter the following behaviour is best:

- When freshly installed enable the feature with sensible defaults. Once you see an alert you can handle it properly by either changing settings or disabling it consciously, because you know it affects a recent change.

- When updating an existing server, disable it, but send a message to the admin explaining what the feature does, and where to enable it with sensible defaults. Explain that enabling the feature might suddenly uncover a lot of issues that simply went unnoticed before.

I think the brute force scanner is a good addition to DA, I'm just a tad pissed that I got called out of bed for it and had to calm some panicked non-techie colleagues over it. You shouldn't want to cause that ;)

In my specific case, I would've updated DA before I went to bed, saw the upgrade message when checking if it went ok, and postponed playing with the new feature until morning knowing what to possibly expect. I think (hope?) most sysadmins update their servers after midnight so I doubt I'm alone in this :p
 
Last edited:
DirectAdmin Support said:
I'm not opposed to disabling it by default, however I'll throw out one last suggestion before doing so.

What if the default count were a very high value. This would probably skip over the false positive cases (pending how high we go) but still have the logging active.

Or set it up such that you can set a limit value of 0 (default) which would mean that no notices are sent out, but the logging is still done.

John
Click to expand...

Unless you tie this feature in with something like blockhosts.py (which pretty much does the same, plus it's firewalling IP's for a specified amount of time), I don't see a lot of use for it.

The people that care about these brute forces already have measures in place to block them based on the ftp/ssh/mail logs. For the rest it's just causing a lot of e-mails with lots of IP's that are useless to block by hand. Tomorrow it's 20 new IP's, the day after 25 other new IP's.
 
Hi,

Is it normal that after update, my file /var/www/html/phpMyAdmin-3.4.3-all-languages/config.inc.php is overwritten ?

So my configs are now :

Code: 
/* User used to manipulate with storage */
// $cfg['Servers'][$i]['controluser'] = 'pma';
// $cfg['Servers'][$i]['controlpass'] = 'pmapass';

/* Storage database and tables */
// $cfg['Servers'][$i]['pmadb'] = 'phpmyadmin';
// $cfg['Servers'][$i]['bookmarktable'] = 'pma_bookmark';
// $cfg['Servers'][$i]['relation'] = 'pma_relation';
// $cfg['Servers'][$i]['table_info'] = 'pma_table_info';
// $cfg['Servers'][$i]['table_coords'] = 'pma_table_coords';
// $cfg['Servers'][$i]['pdf_pages'] = 'pma_pdf_pages';
// $cfg['Servers'][$i]['column_info'] = 'pma_column_info';
// $cfg['Servers'][$i]['history'] = 'pma_history';
// $cfg['Servers'][$i]['tracking'] = 'pma_tracking';
// $cfg['Servers'][$i]['designer_coords'] = 'pma_designer_coords';
// $cfg['Servers'][$i]['userconfig'] = 'pma_userconfig';
/* Contrib / Swekey authentication */
// $cfg['Servers'][$i]['auth_swekey_config'] = '/etc/swekey-pma.conf';
 
Wunk said:
The people that care about these brute forces already have measures in place to block them based on the ftp/ssh/mail logs. For the rest it's just causing a lot of e-mails with lots of IP's that are useless to block by hand. Tomorrow it's 20 new IP's, the day after 25 other new IP's.
Click to expand...

Also, what worries me a bit is the fact this feature is marked as beta but enabled per default. This should not be the case IMO.

Aside of this all, I don't think DirectAdmin as a control panel should be involved in this type of security.
 
Thanks sloop.

I miss this post.

But I think this is not "logical" that configuration can be erased by default.
 
I added brute_force_log_scanner=0 to the directadmin.conf and restarted DirectAdmin. And we still receive brute-force tickets/e-mails. Does anyone know why it still happens?

Thanks in advance.
 
Ywa said:
I added brute_force_log_scanner=0 to the directadmin.conf and restarted DirectAdmin. And we still receive brute-force tickets/e-mails. Does anyone know why it still happens?

Thanks in advance.
Click to expand...
The disable option is in CMD_ADMIN_SETTINGS in the control panel.
 
You must log in or register to reply here.
Back
Top