• 0 Posts
  • 44 Comments
Joined 3 years ago
cake
Cake day: June 26th, 2023

help-circle



  • By default your OS is secure. You only have to think about what you expose and how can it be broken in. Disable SSH password authentication. Don’t run software that is provided by hobbyists who have no enough security expertise (i. e. random github projects with 1 or 2 contributors and any software that recommends install method curl <something> | sudo bash). Read how to harden the services you run, if it is not described in the documentation — avoid such services. Ensure that services you installed are not running under root. Better use containerized software, but don’t run anything as root even inside containers. Whenever possible, prefer software from your distro official repos because maintainers likely take care about safe setup even if upstream developers don’t. Automate installing security updates at the day they released.

    What doesn’t help:

    • Security through obscurity. Changing SSH port etc. Anyone can scan open ports and find where SSH is listening.
    • Antivirus. It is simply unable to detect each of numerous malicious scripts that appears every day. It just eats your system resources.The best it can do is to detect that your host is compromised, but not prevent this. It is not security, just marketing.
    • Making different rules for public internet and DMZ. Consider there’s no DMZ. Assume that your host can be accessed by crackers from anywhere.






  • bizdelnick@lemmy.mltoSelfhosted@lemmy.worldDocker security
    link
    fedilink
    English
    arrow-up
    18
    arrow-down
    1
    ·
    4 months ago

    I’ve read the article you pointed to. What is written there and what you wrote here are absolutely different things. Docker does integrate with firewalld and creates a zone. Have you tried configuring filters for that zone? Ufw is just too dumb because it is suited for workstations that do not forward packets at all, so it cannot be integrated with docker by design.






  • You will need many iterations of trial and error. No way.

    You can speed up testing your playbook by using molecule or something similar. Don’t touch your working VMs until you get a service set up correctly in your test environment. If you need to set up multiple services in a single VM, you can automate their deployment sequentially, of course.

    P. S. I don’t like Ansible and won’t recommend it because it is full of bugs and non-obvious behavior. However I didn’t investigate alternatives and can’t suggest a better one.



  • Just checked one more time that emails from my server are accepted by Gmail. What am I doing wrong?

    the list of the daemons running in docker-mailserver

    Awful. Who heeds both rspamd and spamassassin simultaneously? fetchmail and getmail6? More than a half of these components are not required to get a working mail server. But I agree that setting up the another half is rather complicated. So I’m planning to give a try to mox when I’ll need to set up a new mail server.