SO MANY SECURITY ISSUES!! Sentora needs serious updates!

[aaronlroberts]

So, I've just had the plugged pulled by Braintree because apparently my server configuration doesn't meet the PCI (Payment Card Industry) standards.

MOST of this is due to outdated services running Sentora.. For example, here's one of the reasons.. which I DO NOT understand a word of.

ISC BIND 9 < 9.9.10-P2 / 9.9.10-S3 / 9.10.5-P2 / 9.10.5-S3 / 9.11.1-P2 Multiple Vulnerabilities

Synopsis:
The remote name server is affected by multiple vulnerabilities.

Impact:
According to its self-reported version, the instance of ISC BIND 9 running on the remote name server is 9.9.x prior to 9.9.10-P2 or 9.9.10-S3, 9.10.x prior to 9.10.5-P2 or 9.10.5-S3, or 9.11.x prior to 9.11.1-P2. It is, therefore, affected by multiple vulnerabilities : - A flaw exists in the Transaction Signature (TSIG) authentication implementation when handling received messages. An unauthenticated, remote attacker can exploit this, via a specially crafted request packet, to circumvent TSIG authentication of AXFR requests. Note that to exploit this issue the attacker must be able to send and receive messages to an authoritative DNS server and have knowledge of a valid TSIG key name. (CVE-2017-3142) - A flaw exists in the Transaction Signature (TSIG) authentication implementation when handling messages. An unauthenticated, remote attacker can exploit this to manipulate BIND into accepting an unauthorized dynamic update. Note that to exploit this issue the attacker must be able to send and receive messages to an authoritative DNS server and have knowledge of a valid TSIG key name for the zone and service being targeted. (CVE- 2017-3143) Note that SecurityMetrics has not tested for these issues but has instead relied only on the application's self-reported version number. See also : https://kb.isc.org/article/AA-01503 https://kb.isc.org/article/AA-01504 https://kb.isc.org/article/AA-01505 https://kb.isc.org/article/AA-01506 https://kb.isc.org/article/AA-01507 https://kb.isc.org/article/AA-01508 https://kb.isc.org/article/AA-01509

Resolution:
Upgrade to ISC BIND version 9.9.10-P2 / 9.9.10-S3 / 9.10.5-P2 / 9.10.5- S3 / 9.11.1-P2 or later.

Data Received: Installed version : 9.9.5-3ubuntu0.18-Ubuntu Fixed version : 9.9.10-P2 / 9.9.10-S3 / 9.10.5-P2 / 9.10.5-S3 / 9.11.1-P2

or what about this:

ProFTPD < 1.3.5b / 1.3.6x < 1.3.6rc2 weak Diffie-Hellman key

Synopsis:

The remote FTP server is affected by a Denial of Service vulnerability.

Impact:
The remote host is using ProFTPD, a free FTP server for Unix and Linux. According to its banner, the version of ProFTPD installed on the remote host is prior to 1.3.5b or 1.3.6x prior to 1.3.6rc2 and is affected by an issue in the mod_tls module, which might cause a weaker than intended Diffie-Hellman key to be used. See also : http://bugs.proftpd.org/show_bug.cgi?id=4230

Resolution:
Upgrade to ProFTPD version 1.3.5b / 1.3.6rc2 or later.

Data Received:
Version source : 220 ProFTPD 1.3.5rc3 Server (Sentora FTP Server) [::ffff:162.212.158.34] Installed version : 1.3.5rc3 Fixed version : 1.3.5b / 1.3.6rc2

Here's another example:

FTP Supports Cleartext Authentication

Synopsis:

Authentication credentials might be intercepted.

Impact:
The remote FTP server allows the user's name and password to be transmitted in cleartext, which could be intercepted by a network sniffer or a man-in-the-middle attack.

Resolution:
Switch to SFTP (part of the SSH suite) or FTPS (FTP over SSL/TLS). In the latter case, configure the server so that control connections are encrypted.

Data Received:
This FTP server does not support 'AUTH TLS'.

The results of this security scan provided by "Security Metrics" totalled a 41 page PDF file with TOO many vulnerabilities so they blocked my ability to make any transactions using my website(s).

You guys at Sentora seem so caught up in this issue with Suhosin, to the point where you're happy enough to just let us sit on an old OS with multiple out of date issues with no updates or support for years... what's going on guys? Are you even working on getting this service up and running again or not?

I need an answer, I cannot waste time waiting for this damn suhosin to get compiled which is CLEARLY is not going to happen, just sounds like an excuse to me.

If a "developer" from here wants the PDF let me know.. but you guys need to get this together, otherwise it's just a insecure, messy platform.

[fearworks]

So, I've just had the plugged pulled by Braintree because apparently my server configuration doesn't meet the PCI (Payment Card Industry) standards.

MOST of this is due to outdated services running Sentora.. For example, here's one of the reasons.. which I DO NOT understand a word of.




or what about this:

Here's another example:


The results of this security scan provided by "Security Metrics" totalled a 41 page PDF file with TOO many vulnerabilities so they blocked my ability to make any transactions using my website(s).

You guys at Sentora seem so caught up in this issue with Suhosin, to the point where you're happy enough to just let us sit on an old OS with multiple out of date issues with no updates or support for years... what's going on guys? Are you even working on getting this service up and running again or not?

I need an answer, I cannot waste time waiting for this damn suhosin to get compiled which is CLEARLY is not going to happen, just sounds like an excuse to me.

If a "developer" from here wants the PDF let me know.. but you guys need to get this together, otherwise it's just a insecure, messy platform.

Don't you think your post is a tad rude?

No one is making you use Sentora, and I'm pretty certain that no one has ever claimed it is PCI compliant (if they have I'd like to see it). Also, you do realise you are making use of something that is free?

"You guys at Sentora" only appears to be two people at the moment (I'm not one of them) and I think they both have far greater priorities than Sentora.

If you're post said something like "Please, can anyone help me make my Sentora installation PCI complaint", you'd probably get someone helping you. Hell, I might even have bothered to assist, and there are a couple of other active people on here who I am pretty sure would help you out.

But because of your tone I decided to spend my time on other posts. Well, apart from typing this message.

Good luck with your issue.

PS. That darn Suhosin... I know, spending all that time on something that helps keep your server secure. Fancy that! Maybe if you squeeze us hard enough we'll be able to just pop out an update and get on with it?

[Me.B]

1. We rely on most packages on OS maintainer. When you do a yum update / apt upgrade you will get the latester and fixes.

2. On centos you might see some warning/error BUT they are using redhat mainbase wich will back port fixes without changing the releases. You will notice they are still maintaining PHP 5.4 while it's EOL and updating it.

3. Some of the packages send warning and il will depend how you use it.

But all input for security is WELCOME

[republicus]

If a "developer" from here wants the PDF let me know.. but you guys need to get this together, otherwise it's just a insecure, messy platform.

I would like to see your report.

Each service may need addressed according to the concerns of your report.
For instance after installing Sentora I configured Postfix to use StartTLS for handling mail. Likewise configuring proFTPD itself to be more secure would likely correct your concerns.

We can address those issues.


Something that I think needs some attention:

FTP account passwords are shown in plain text in Sentora panel. "Show Passwords" and "Hide Passwords" are useless, as they are always shown.

I would rather Sentora treat FTP accounts the same as client/mailbox accounts where passwords are never visible, but can be updated.

[nibaldo]

Sentora will be updated soon????

[fearworks]

I would like to see your report.

Each service may need addressed according to the concerns of your report.
For instance after installing Sentora I configured Postfix to use StartTLS for handling mail. Likewise configuring proFTPD itself to be more secure would likely correct your concerns.

We can address those issues.


Something that I think needs some attention:

FTP account passwords are shown in plain text in Sentora panel. "Show Passwords" and "Hide Passwords" are useless, as they are always shown.

I would rather Sentora treat FTP accounts the same as client/mailbox accounts where passwords are never visible, but can be updated.

The show/hide password issue is a simple Javascript issue. If you download the latest version of the module.zpm file for the FTP Management module from the Github master repository, it should work:

https://raw.githubusercontent.com/sentor...module.zpm

I did tweak two lines for it to work how I wanted on my servers:

Code:

$('#btn_sh').innerHTML = 'Hide passwords';
$('#btn_sh').innerHTML = 'Show passwords';

changed to:

Code:

$('#btn_sh').html('Hide passwords');
$('#btn_sh').html('Show passwords');

Give it a try and see if it now works.

Keith.

[republicus]

The show/hide password issue is a simple Javascript issue. If you download the latest version of the module.zpm file for the FTP Management module from the Github master repository, it should work:

https://raw.githubusercontent.com/sentor...module.zpm

I did tweak two lines for it to work how I wanted on my servers:

Code:

$('#btn_sh').innerHTML = 'Hide passwords';
$('#btn_sh').innerHTML = 'Show passwords';

changed to:

Code:

$('#btn_sh').html('Hide passwords');
$('#btn_sh').html('Show passwords');

Give it a try and see if it now works.

Keith.

That's good, Keith. Thanks!

Both changes were necessary. First updating the module from github did make the passwords show and hide.  However, the button always said "Show passwords". The code change you provided corrected the text to say "Hide passwords" when appropriate.

[aaronlroberts]

Sorry if the post came across rude, but it seems that Sentora has been dead in the water for a while. The problem is that if there are indeed only two people working on it, then efforts need to be made to recruit / locate additional people to offer assistance.

Security is important, and I run the apt-get update / apt-get upgrade commands weekly, there are no new updates which will affect the mentioned security issues.

I'm a little hesitant to upload my security report directly here, as it could possibly be used to exploit the problem mentioned as there URLS and Directories listed in the report.

My point is, Sentora is way behind, it's not even acceptable to request users to use the old versions of PHP and Sentora should be updated to include the latest version of PHP (or at least the ability to choose), an up-to-date OS with the latest security and background processes as well as upgradability as time goes on.

I really love this panel, I've used plenty more, including a new service called CyberPanel, but honestly, I just prefer Sentora's feel and the fact I know my way around the back end enough to make the necessary changes.

[fearworks]

Sorry if the post came across rude, but it seems that Sentora has been dead in the water for a while. The problem is that if there are indeed only two people working on it, then efforts need to be made to recruit / locate additional people to offer assistance.

Security is important, and I run the apt-get update / apt-get upgrade commands weekly, there are no new updates which will affect the mentioned security issues.

I'm a little hesitant to upload my security report directly here, as it could possibly be used to exploit the problem mentioned as there URLS and Directories listed in the report.

My point is, Sentora is way behind, it's not even acceptable to request users to use the old versions of PHP and Sentora should be updated to include the latest version of PHP (or at least the ability to choose), an up-to-date OS with the latest security and background processes as well as upgradability as time goes on.

I really love this panel, I've used plenty more, including a new service called CyberPanel, but honestly, I just prefer Sentora's feel and the fact I know my way around the back end enough to make the necessary changes.

I agree that it seems to have become stagnant, but I think there are two main reasons for this. The first, the main "lead" developer stopped working on the project two or three years ago, which I think "dropped a few people in it" in terms of looking after the code and adding new features. I am not bashing them or their reasons for doing this at all. They were creating something that was freely available to anyone, so they have every right to stop working on it whenever they want to for whatever reason. I think there was initially a larger group of people supporting the project even after the lead developer decided to leave, but over the years since that the numbers have slowly dwindled to just two or three active people (that I can see) who maintain the project.

I think the second reason is largely the fault of Suhosin not receiving updates. There's nothing wrong with updating the packages yourself, and in my case, when I install a Sentora server, the installation script grabs the most recent versions of things like Apache and PHP5 at the time of install anyway. Also, I have fixed or patched most (maybe all?) glaring bugs/errors in the code for my own installs. But the jump from PHP5 to PHP7 is quite a major one, and moving from 5 to 7 would mean currently having nothing "plugged in" to PHP to protect your server from people running "abusive" functions etc. because Suhosin is not available in a production version that works with PHP 7. There's an early alpha version of Suhosin for PHP7, but it does not work properly and has itself been stagnant for a long time. Something to replace Suhosin might be around the corner, but we then come back to the first issue...

Implementing a major PHP update (and therefore, an update to the security package) currently relies on either the two or three people who are left to manage the project knowing enough to be able to implement it, and then also having enough time to try it, test it, write about it, and update the code to make use of it. Like a lot of people, these people probably have families and lives outside of Sentora... and Sentora is probably not high on their list of priorities. They were, after all, "dropped in it" and maybe Sentora isn't their "baby" like it once was to the lead developer.

So I guess that means the project will only stay alive if we can be nice to these two or three people and not be abusive towards them and the efforts that they do make, and it also means that we have to be proactive about moving Sentora forward ourselves, as users. That means learning about the code, running our own development snapshots to test things out on, and if we're willing to do so, telling anyone who is interested about what we find on this forum.

I have been working on implementing the best replacement for Suhosin that I can find, with PHP7.3 on Sentora. This is currently a Release Candidate version of PHP but I believe is due to be released in the next few weeks. The replacement is called Snuffleupagus, and it advertises itself as a modern Suhosin replacement. It has been a bit tricky to implement in a virtual hosting environment but I think I might have that cracked now, so hope to post about it soon. And when I say soon, this isn't a commitment to post about it within a week, or by the end of the month... I will do this just whenever I get the time and feel motivated to do it. And I imagine that's how most people on here work when they're working for free...

Keith

[siulian]

First of all i want to say thanks for all contributors and developers of Zpanel/Sentora till now.

Regarding the security part mentioned by aaronlroberts i can see that those have nothing to do with Sentora after all. Sentora is a "PHP program" that interacts with services developed by other groups/individuals/community(ex: bind, proftpd, apache, php, etc) in order to make your life easier when you configure your server. It is not Sentora fault that you dind't update your services accordingly.
I agree that incompatibilities may appear between that Sentora is writing in config file of those daemon and the upgrade of the daemons and those should be address further to sentora but blaming sentora for vulnerabilities which are not inside his core is not ok.

If i would like to see security improvements i will want most probably things like two-way auth