Suspicous request left one of my cloudron instances
-
So I just ran a check on check.spamhaus.org and fount that one of my cloudron instances made a tcp connection to a suspicious ip address, that is part of a dns sinkhole. Therefore it got on a list of probably exploited machines. I checked logs on the server, mail logs, and so on, but could not trace down the application, from which the connection was made.
How can i get more insight in these kind of issues?
-
So I just ran a check on check.spamhaus.org and fount that one of my cloudron instances made a tcp connection to a suspicious ip address, that is part of a dns sinkhole. Therefore it got on a list of probably exploited machines. I checked logs on the server, mail logs, and so on, but could not trace down the application, from which the connection was made.
How can i get more insight in these kind of issues?
@opensourced
spamhaus will just check your ip/domain if it's listed on their database, this means that your server or the owner of that IP before you is using it for spamming or malicious activity.A good way to understand what's happening in your server is to lock down SSH port to just an SSH key (check if you find another ssh key that is not one of yours) and check if there is any process that you don't recognize or any docker container that shouldn't be there.
-
In case of dns sinkholes, spamhaus even tells you date & time when the server tried to establish a tcp connection to the sinkholed domain (incl IP). Therefore i know that it is not the previous owner, but my cloudron instance, which apparently made that request.
SSH has never been accessible from wan (furthermore only ssh pub key authentication is set and root login is disabled.
So my question is: I know, that my running cloudron instance (or some app within) is the source of tcp connections targeting sinkhole domains. -> Do I have a possibility within cloudron (, docker or nginx generally) to filter (not block) traffic for certain IPs? I need to find the compromised container.
Traffic analysis on firewall level wont give me the container, therefore it is not really useful.
-
Maybe you have some corrupted apps installed? Wordpress and every app that comes with standard logins (which you then did not change) are good candidates.
That was the reason in 100% of all cases I had with a Cloudron instance beeing blacklisted by a hosting provider or DNSBL.
-
@opensourced Maybe that could help quickly. According to my own experience and how you describe how it's happening and how the attempts to connect is made, I'd bet you have WordPress instances on that Cloudron instance. And one, or several, of them are running corrupted hidden codes which are mostly found in plugins from doubtful sources. I'm not implying that it's you or anything else, I'm just pointing you in a direction that is very likely the case of what's happening on your Cloudron instance that triggers RBLs. So, you might want to check the source of the plugins if they're all from the original author, if not then you might want to look in the direction of the plugins 'borrowed' from, or distributed by some other sources than the originator.
-
in addition to what @micmc said, Wordfence can detect any changes to the Wordpress core files and email you with any security warnings that come up in the scheduled scans.
