-
@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.
