Posts by fulltilt

it's an ip-set blacklist which make use of some major BL too f.ex. Spamhaus ... attacking IP addresses are set to reject and in this case the letsencrypt verification server was blocked. It's not a plugin issue but maybe this information helps when using external blacklists or fail2ban RBL rejects too.

yep, the letsencrypt IP address is blacklisted (Spamhaus SBL-XBL Combined Block List) ... if anyone uses ip-set blacklists you should whitelist 64.78.149.164

http://multirbl.valli.org/lookup/64.78.149.164.html

I use some exernal blacklist scripts (github etc) and it seems that someone (an idiot) added a few letsencrypt IP addresses to the blacklists ... however I have already found one and now it start to work when requesting a new cert.

thanks for reply!

- IMSCP: 1.5.3

- Distribution: Debian 9

- Proftpd

- PHP FPM

- MariaDB 10.1

- Dovecot

- Roundcube

- Web2FTP

- Plugins:

PMA Captcha, RoundCubePlugins, SpamAssassin , LetsEncrypt, PHPswitcher

I have to hide LetsEncrypt for the customers, because there is a malfunction somewhere atm.

There are no indications of errors in the debugger and I can not find anything in the logs, maybe Fail2ban, UFW or IP_set blocked the IP addresses of Letsencrypt servers or something else is broken.

Is there's a way to hide the Letsencrypt menu entry for the customers, so they are no longer able to create new certs? (cronjobs for cert renewals should stay).

An incorrectly created certificate crashes my PHPswitcher (PHP Versions) at least 2 times a day and I have to delete and recreate it and all related customers settings. again & again ...

For now I see no other option so I need to hide the menu entry currently I can not perform a reinstallation or upgrade due to illness.

if anyone finds such tunxxx.socks files in /tmp, this is caused by a thirdparty PrestaShop database bridge.php which is trying to setup virtual proxy connections to their local computer accounting software, which also leads to a high system load. In MC you can set display info/details to the right side and then the respective vuXXXX owner are shown..

OK, I have found the owner and creator of these .sock files and blocked their websites ... there are about 4 prestashops installed .... but I guess the webuser should not be able to generate TUN.SOCK files inside /tmp and it looks like hacked or outdated PHP scripts causing this - right?

thanks, I thought the same ... or "maybe" caused by a module (letsencrypt)

so it seems created by a PHP script, something like tun2socks or typo3 SOCKS5 scripts etc.

https://superuser.com/question…erface-from-a-socks-proxy

I have already scanned the complete system but did not find anything extraordinary or malware ...

so I guess typo3 SOCKS5 scripts etc. could possibly cause this tmp files.

- IMSCP: 1.5.1

- Distribution: Debian GNU/Linux 8.11 (jessie)

- Proftpd

- PHP FCGID

- MariaDB 10.0

- Courier

- Roundcube

- Web2FTP

- Plugins:

PMA Captcha, RoundCubePlugins, SpamAssassin , LetsEncrypt, WHMCS

I found strange .sock files in / tmp (=tun7262.sock) with a filesize of 0, is this something I have to be worry about?

How can I determine from which user these were generated?

I know this installation is a little older will be migrated to a new server ASAP

After the New Year party and a 3-day recovery period I was able to install (migrate) everything successfully in a VM!

This time I have cleared the web_software tables and it worked without any problems ...

I have created a few own software packages for the imscp installer, could it be that the previous upgrade error was related to it?

at the weekend I will try again the upgrade with the real system.