-
@girish I learnt my lesson about open registrations with Kutt !
As far as I am aware, I don't have any apps which have easy open login or self-registration.
Apps which are publicly accessible are things like websites.The more I think about it, the more I think my recent problem was a Wordpress instance. I don't know if the user loaded anything, I just killed it immediately without asking, and it seemed to solve the problem.
-
@timconsidine said in Cloudron Instance Platform Check App(s):
@girish I learnt my lesson about open registrations with Kutt !
We have been brainstorming locally on what we can do to help admins not forget. Maybe a post install checklist that has to be checked off in the UI. Until then, it will show some warning indicator saying "xx tasks pending to be completed" .
-
@girish said in Cloudron Instance Platform Check App(s):
Usually, these systems have to be built outside Cloudron.
Understood.
I didn't mean to suggest that they are "in Cloudron", just that the Cloudron deployment installs e.g. virus/malware checker.
Is it ok if I investigate adding one "alongside" Cloudron ?
Normally that is against advice.
But I struggle to justify e.g. to my hosting company "sorry, I can't check for malware"I have had 3 abuse reports over time, one was because Kutt was open registration (solved), and the other 2 both seem to be about netscans (probably Syncthing and Wordpress : solved by uninstalling). Is it possible to install something which prevents outbound netscans ?
EDIT : I think Cloudron uses iptables : what is the feeling about using something like FirewallD or Shorewall to manage the iptables config ? Still investigating them.
-
Perhaps something like NetData could be baked into Cloudron?
-
@girish said in Cloudron Instance Platform Check App(s):
We can safely assume that SSH is not unsafe unless the user set a weak password or something.
I think by default there should be a bruteforce protection for SSH. I see no reason why it's not installed by default if it's suggested (same with having phpmyadmin enabled by default for LAMP setups if it's suggested to have it only active if you need to).
Is there any log for failed log-ins towards Cloudron UI? I found nothing and I tried 10+ trials. Still the specific account is not locked nor the IP address banned.
@girish said in Cloudron Instance Platform Check App(s):
Which then leads us to apps. If app is "hacked", a hacker can damage the app. Most apps are basically locked and can't do much since they run on readonly file system (it's the whole reason we have this, you can't run random scripts if your compromise the app).
This is not given for LAMP apps in general so I think there should be an improvement for that part (same issue as for WP instances).
@girish said in Cloudron Instance Platform Check App(s):
I guess we see this as a major feature
If apps aren't public, most people won't use Cloudron since data won't be accessible easily.It can be public but not by default. I don't see a reason why specific apps should be public by default especially if the default settings aren't hardened or default passwords being used. An admin must decide actively which should be public. If he/she set it to public with bad practices, it's a self-made issue (although Cloudron advertises itself as a security by default solution where I have a few doubts like outlined).
-
@warg said in Cloudron Instance Platform Check App(s):
I think by default there should be a bruteforce protection for SSH. I see no reason why it's not installed by default if it's suggested
Are you referring to something like fail2ban here? I know people are "bothered" by ssh logins but if you have a proper key login and password login disabled, there's nothing the attacker can do -https://blog.codinghorror.com/brute-force-key-attacks-are-for-dummies/ . The logs are in
journalctl -u sshif you want to inspect those anyway. If you really want to save on network traffic best bet is to do this at the network level in your VPS provider's firewall.(same with having phpmyadmin enabled by default for LAMP setups if it's suggested to have it only active if you need to).
true, I will disable it in the next package update by default.
It can be public but not by default.
Are you thinking of some wireguard/openvpn kind of setup here? How would I connect to apps?
-
@girish said in Cloudron Instance Platform Check App(s):
Are you referring to something like fail2ban here?
I think @warg is possibly referring to the changing port stuff mentioned here:
-
@jdaviescoates Ah , you mean move ssh to port 202 by default for all installations ? Oof, that won't be a popular decision
I remember we put some basic password restrictions in the initial Cloudron releases years ago and we were basically "strong armed" into removing any restrictions wrt setting password length or characters etc!
-
@girish said in Cloudron Instance Platform Check App(s):
@jdaviescoates Ah , you mean move ssh to port 202 by default for all installations ?
I'm guessing that is perhaps what @warg meant, yes.
-
I'd add email sending rate limiting defaults to the protections wishes:
- https://forum.cloudron.io/topic/4006/add-a-setting-for-sendmail-limits-per-mailbox-per-day
- https://forum.cloudron.io/topic/8792/basic-outbound-email-limits-per-email-account-at-smtp-level-for-ip-protection
- https://forum.cloudron.io/topic/4691/email-improvement-ability-to-rate-limit-outgoing-messages-from-the-server-cap-messages-sent-per-domain-in-a-given-timeframe
-
@girish said in Cloudron Instance Platform Check App(s):
Are you thinking of some wireguard/openvpn kind of setup here? How would I connect to apps?
htaccess protection, ldap or similar, etc. Just anything so that apps without log-in by default are protected.
@jdaviescoates said in Cloudron Instance Platform Check App(s):
I think @warg is possibly referring to the changing port stuff mentioned here:
Nope, changing the port by default would be weird although it reduces the attacks on the port. I refered to https://docs.cloudron.io/security/#fail2ban which is fine to use and makes sense but isn't active by default. So as long as pubkey auth isn't default, fail2ban should be default.
-
TBH I'd like to see the my.controlpanel.domain all Apps behind a VPN by default, with something like Firezone:
So you launch them all privately, and set to be public if or when desired. Harder to hack what you don't know exists.
-
@girish said in Cloudron Instance Platform Check App(s):
@jdaviescoates Ah , you mean move ssh to port 202 by default for all installations ? Oof, that won't be a popular decision
I remember we put some basic password restrictions in the initial Cloudron releases years ago and we were basically "strong armed" into removing any restrictions wrt setting password length or characters etc!
Though, as you mentioned it, with proper key login and disabling password there's no reason for not sleeping at night, let alone to move ssh to port 202 or else.
-
Thank you all, for this wonderful conversation. I really enjoyed reading that. What I take from it, is there is many things you can do, but the question remains: what should be done, also in terms of the product Cloudron itself.
Since I've been confronted with a bunch of abuse-report myself that started yesterday, I checked all the apps and their stats, respectively for an abnormal behavior. The traffic had surged to roughly 1gb per hour, which could be seen in the providers traffic-reports, but the system itself incl. every single app I checked, the network-io for the past 7 days was totally normal (read: low to non-existent).
That way, I was NOT able to find the app in question. Also, I missed a feature, where I could overlay ALL active apps in one graph to sort out, which one of them is the most active or verbose one, in regard of network-traffic. So that would be a nice addition to the admin-panel, e.g. the System-Info page, where it shows some graphs, even lists all apps and their corresponding disk-usage, but a networking information would be helpful here, I guess.
Out of despair, I allowed myself to install nethogs and bmon via apt as root on the server, against the advise but figured it would not hinder or hurt the installation, as it usually is not creating any conflicts. Please advise, if I'm wrong on that for any reason.
But the traffic that occurred was not captured on the cloudron network-io graph for reasons that I can not explain. What I found was a compromised Wordpress-installation that had malicious scripts on them. I de-activated the app in question and wonder if that fixes the issue.
The traffic has been not constant up, but 3-4 hours at 1-2 GB / hour and then nothing again, for another 3-5 hours. So it is harder to track and needs some monitoring and observation.
Additional information: I had a provider-based firewall active, so only ICMP was allowed, as well as port 80/443. ssh was blocked (I turn it on, when I need it). All outgoing connections are allowed, obviously. All Email functionality is set to outbound only, with the logs not showing any weird behavior as well.
tldr - open questions:
- How can the network graph not show the traffic, that was generated (if it was the Wordpress in question, that is still unclear)
- Please add a multi-app network monitoring graph (or even more stats) to compare apps with another and find those, that take more resources
- Is there a way to monitor network-usage of the system itself, that are not from the apps?
- How much impact can be expected, if little monitoring helpers are installed via apt (as root) on a Cloudron that could hurt future maintenance?
Thank you so much for your attention.
-
There is a new HTTPS/2 DDoS attack that is cheap to use. It doesn't affect apps since it only goes as far as the Nginx reverse proxy for which we have no stats from Cloudron.
Since your WP instance was compromised, it could have been the one that leaked your IP/subdomain to the botnet which then tried to use it unsuccessfully.
-
@robi Thanks for your explanation. Based on the abuse-mails and the information they shared, I'd assume it was a script trying to login to various sites/platforms, especially their Wordpress-instances. So I assume it is a worm, that tries to spread that way: But in the end: Yes: could be, that the traffic being generated then happened like this.
That is, why I asked for a more general monitoring solution, for network-activity, as this is the most obvious one.
I also found out about netdata, and think about installing it on our machine, as @imc67 and @fbartels already suggested. Not sure, though which way to use for the installation.
