Is there a simple way to change/rebrand the "You found a Cloudron out in the wild!" page that displays from time to time when different things happen?
If not, perhaps this could be moved to the suggestions forum - as it feels like a good addition to the "Basic Branding" feature set.
@girish said in Elasticsearch:
Indeed, current plan is to implement Elastic search as an addon and not as an app.
Hey Grish - this sounds good, and exciting! I noticed that Elasticsearch has been on the roadmap for some time and am wondering if this is something we're likely to see in the Cloudron 6.x series, or if it's much further down the road yet?
When I set up my app, I chose the LAMP app that just said "LAMP" and not one that specified the version - and am now realizing that I should have chosen 7.3 specifically.
So, I'm wondering if there's an easy way to update the PHP in that app without needing to create a new app (with new database information, new redis information, etc.).
Hey @girish - is this still on the roadmap for some time in the future? If so, do you have an idea of when it's likely to be set up?
@makemrproper yes, I think this method isn't going to work for me. Especially if it still refers to the old app's database. (Though, if that's the case, I'm not sure why it continually fails due to a MySQL disconnection error) I'll just transfer the files and the database myself. Seems like way less headache!
@jdaviescoates Yes - which also occurs if you add new domains/subdomains to an app while the app goes down to reassociate everything with itself. This meant that my live site was displaying this message briefly yesterday (the more domains/subdomains you have connected to the same app for legacy reasons the longer it takes that process to complete...)
Hey @girish - is this still on the roadmap for some time in the future? If so, do you have an idea of when it's likely to be set up?
@jdaviescoates Yes - which also occurs if you add new domains/subdomains to an app while the app goes down to reassociate everything with itself. This meant that my live site was displaying this message briefly yesterday (the more domains/subdomains you have connected to the same app for legacy reasons the longer it takes that process to complete...)
Is there a simple way to change/rebrand the "You found a Cloudron out in the wild!" page that displays from time to time when different things happen?
If not, perhaps this could be moved to the suggestions forum - as it feels like a good addition to the "Basic Branding" feature set.
@marcusquinn Thanks for this. I deactivated even the add-ons that felt trustworthy and moved to a default theme (since that wordpress is really more of an archive than an active site). I also ran the scan you suggested and found that one add-on that I deactivated, and a theme, were both had scripts in them with known issues.
I wonder if a suggestion for the cloudron managed wordpress package is rate limiting external calls?
@iamthefij Thanks - it seems to be have been one of the wordpress instances (this memory spike corresponds to the same times the CPU spiked for the attack). 
However, it's a Managed wordpress instance and so autoupdates are disabled (as cloudron does these updates) - I have no plugins installed on it.
@mehdi Have two wordpress apps, a webmail app, and two LAMP apps running Xenforo.
@nebulon Thanks for the quick reply!
They provided logs (which I'll leave at the end of this reply), but they don't seem to give enough information if it's a host system compromise or an app.
/root/.ssh does not have any authorized keys listed (which I take as a good sign).
we detected a DOS attack from your network.
Below the logs.
172.105.104.122 - - [23/Nov/2020:15:43:33 +0100] "GET /wp-login.php HTTP/1.0" 200 1296 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 172.105.104.122 - - [23/Nov/2020:15:43:35 +0100] "POST /wp-login.php HTTP/1.0" 200 1659 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 172.105.104.122 - - [23/Nov/2020:15:43:36 +0100] "GET /wp-login.php HTTP/1.0" 200 1296 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 172.105.104.122 - - [23/Nov/2020:15:43:37 +0100] "POST /wp-login.php HTTP/1.0" 200 1669 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 172.105.104.122 - - [23/Nov/2020:15:43:38 +0100] "POST /xmlrpc.php HTTP/1.0" 403 212 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 172.105.104.122 - - [23/Nov/2020:16:10:33 +0100] "GET /wp-login.php HTTP/1.0" 200 4386 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 172.105.104.122 - - [23/Nov/2020:16:10:34 +0100] "POST /wp-login.php HTTP/1.0" 200 4386 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 172.105.104.122 - - [23/Nov/2020:16:10:35 +0100] "GET /wp-login.php HTTP/1.0" 200 4386 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 172.105.104.122 - - [23/Nov/2020:16:10:36 +0100] "POST /wp-login.php HTTP/1.0" 200 4386 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 172.105.104.122 - - [23/Nov/2020:16:10:37 +0100] "GET /wp-login.php HTTP/1.0" 200 4386 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 172.105.104.122 - - [23/Nov/2020:16:10:37 +0100] "POST /wp-login.php HTTP/1.0" 200 4386 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 172.105.104.122 - - [23/Nov/2020:16:10:38 +0100] "GET /wp-login.php HTTP/1.0" 200 4386 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 172.105.104.122 - - [23/Nov/2020:16:10:39 +0100] "POST /wp-login.php HTTP/1.0" 200 4386 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 172.105.104.122 - - [23/Nov/2020:16:10:39 +0100] "GET /wp-login.php HTTP/1.0" 200 4386 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 172.105.104.122 - - [23/Nov/2020:16:10:40 +0100] "POST /wp-login.php HTTP/1.0" 200 4386 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 172.105.104.122 - - [23/Nov/2020:16:10:41 +0100] "GET /wp-login.php HTTP/1.0" 200 4386 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 172.105.104.122 - - [23/Nov/2020:16:10:41 +0100] "POST /wp-login.php HTTP/1.0" 200 4386 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 172.105.104.122 - - [23/Nov/2020:16:10:42 +0100] "GET /wp-login.php HTTP/1.0" 200 4386 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 172.105.104.122 - - [23/Nov/2020:16:10:43 +0100] "POST /wp-login.php HTTP/1.0" 200 4386 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0" 172.105.104.122 - - [23/Nov/2020:16:10:44 +0100] "POST /xmlrpc.php HTTP/1.0" 403 212 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0"
Please take action as soon as possible. The destination IP of the attack from your network is: web.mercurio.vhosting-it.com
Hello,
I use Cloudron in part because managing a VPS is outside of my usual comfort zone. I was gravely concerned when I received an email today from Linode suggesting my VPS had been used to attempt some sort of brute force/DoS attack targeted at another site. I rely on Cloudron to ensure the general security of the VPS, and my root password is quite secure (generated from a password manager and only saved there). I've changed the root password, but am not sure of what next steps I should take, or how I can prevent this in the future.
@girish said in Elasticsearch:
Indeed, current plan is to implement Elastic search as an addon and not as an app.
Hey Grish - this sounds good, and exciting! I noticed that Elasticsearch has been on the roadmap for some time and am wondering if this is something we're likely to see in the Cloudron 6.x series, or if it's much further down the road yet?
Perhaps my understanding is erroneous, but I was under the impression that apps in containers aren't able to interact with each other on the server and so these things would have to be in the same container to engage with each other appropriately.
However, as I review the documentation using Elasticsearch with the forum software I'd be attaching to it, I realize that as long as the container is able to access the port necessary it should be fine - in which case, I guess I'll just wait patiently for an Elasticsearch app to be available!