New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
@TheLinuxBug just out of curiosity, did you seriously try to correct me on "phishing" vs "fishing"
I'm sure it's fishing. That's what most people do. It's all legit.
after the flaws with the zpanel cp , i have shifted from zpanel to vesta CP , till now this is just awesome.
i'm actually not sure what the issue here is anymore?
First, i hope everyone has backups - Backups are important, simple as that and simple to set up if you have a VPS anyway.
The server was clearly hacked in a way that allowed the attacked to install a C&C - If you Google your IP you will easily see what type of bot it is (well, now probably not anymore, but for a few days after suspension/reinstall).
Depending on the service we have no ability to give you a backup (KVM).
On OVZ/VRS we can zip the archive of the VPS, but this takes long (very small files, a lot of them), costs much ressources and takes time which is why it is more likely a value-added service than included in the VPS itself and a cost that (imo) should not be paid by other users as general higher-priced service.
and...
Those two statements also apply to providers who knowingly put insecure billing/server management scripts with a long history of vulnerabilities on their sites and then are hacked (sometimes more than once) and customers' data is compromised. I've seen several providers who were hacked try to place 100% of the blame when they're hacked on software developers like SolusVM and the provider claims it's not their fault even though they were the ones who put an insecure script on their sites. (ChicagoVPS is a perfect example of this). If the coding on the script looks like it was written by a slow learning baboon and the script has a history of problems you shouldn't use it and should find an alternative (or write your own script).
The problem with that is that your own script is likely to have vulnerabilities too, perhaps even more than those of old products.
Besides, those producers look like they learned something and are trying to deliver a safer product.
If they kept going on saying there is nothing wrong with their products and those were isolated incidents like others do, or even say it never happened, ok, there was time to switch, but as things go now, I think it is probably safer to stick with the devil you know and has been checked by many others too, than the one in the woods.
I don't want to argue with you, but, I will ask just a question: are there any proofs that current version of Zpanel has problems? At least I, don't have any. I am not a programmer, I'm not involved in any way with the developers or the project, I don't know them nor do I am active on their forums. But, if anybody gets conclusions from what something was in the past, then, nobody should use vere again solus or whcms or kloxo or any other platform that was insecure or bad coded sometime...
@concerto49 pasted an old thread in LET (May) with a very interesting discussion about zpanel vulnerabilities. But this is old and for an old version, witch now has been almost completely rewritten (according to the developers). @ska also posted an open google groups discussion about any problems that being discovered in this panel. In this google group, the developers are very active and answer / seem to resolve quickly any problems the users mention. This is a good behavior from a company that produce software, isn't it? What I want to tell is that although we (I, sure) all have to be vary careful about any code or software we install in our boxes, especially if there were critical issues in the past, we cannot condemn anything without real facts, just because sometime was hacked or in the past developers denied to admin there were issues, especially if their behavior has changed...
A last thing: A million things can happen that can lead to a hacked vps, not just the panel or a single software that was installed. And, as long as we cannot get the logs of the hacked server, the actual files or code of c&c, the directory the code was hidden and the time hackers got in, we (I) cannot know for sure what really happened and who's fault was that...
That saying, I'm going to observe carefully my couple of testing - non critical installations of this panel, reading the logs, see if will be hacked, watch the load and the stability. At least for now, my critical - public projects will be hosted in virtyalmin/webmin...
@jvnadr I hope you would check this out if you're still using zPanel http://forums.zpanelcp.com/thread-9884.html
That's one weak entry point.
Reading through the rage in this thread hurts my eyes and brain at this hour of the night, so I'm just going to drop in some common policy (or at least how we handle this type of issue; as a budget KVM VPS provider.)
We will suspend the container, leaving the files intact but shutting down the system to prevent further contamination inside the container, as well as sever any connections the C&C host may have (as well as stop any damage currently underway.)
We send you an email (suspension notification) with all the details we have, including a copy of the abuse report and firewall logs for your records; so you know exactly what happened.
Our standard policy then (assuming you responded to the email or opened a Support Ticket to get your service back up and running) is to:
Unsuspend your service with no NIC attached, to prevent the C&C host from communicating with your infected container; and so you can run rtk and malware detection software, backup your clean files, etc.
We will then provide you the option of either restoring your NIC (if you feel the VPS has been cleansed), or building a new container for you and helping you get it back up and running (restored files, re-installed software, etc.)
I feel that this is what any sane provider should do, regardless of support level; as C&C is a pain for everyone (as was mentioned already in this thread.)
I understand the reasons behind the request of getting information what happend to the vps.
But it is an unmanaged service and therefore remote console or investigation on site of Edis is out of scope.
@vRozenSch00n
Yes you are able to see the output of the daemon. And you can run it as often as you want. No harm, no security issue. Only the ability to see some paths (that you can guess if you know how zpanel works.
zPanel gets some heavy disliking here. Just out of the reason that one single member of this board did not get the red carpet and the purple heart from the devs.
A bruised ego is not a good guide for anything.
Back to topic.
Just think about how this would run if you are one of your neighbors.
I think you would cry out loud if you are not able to send any emails because someone else got banned a second time through spamhaus.
If Edis did not react that way a lot of other customers would get quite upset.
Spam is one thing - bot nets are another league.
The couse of the "infection" might be zPanel but ensure that the other php scripts are save too.
A bruised ego is not a good guide for anything.
Agreed. zPanel has a good and easy to use interface I can confirm that.
Another possibility is the "patient zero" is the zPanel source. http://forums.zpanelcp.com/thread-8604.html
No direct proof, but I am dealing daily with compromised sites and I often get the answer: "that is not possible I was only running kloxo/zpanel to host a small blog of mine". Lately zpanel is the bulk with more than 3/4 (not audited numbers out of the top of my head).
Ask freek how he installed an open proxy without knowing with zpanel, for example.
No I do not follow lists of security advisories regarding zpanel and I will probably not do it in the future, however, I do recommend all the hacked people using it (and kloxo old version) to switch to another panel.
In the end ZPanel is as "good" as Joomla regarding vulnerabilities.
Not really, Joomla doesn't use root privileges.