• @foggy@lemmy.world
    link
    fedilink
    English
    421 year ago

    Setup Fail2ban

    Login only with SSH keys. MFA on SSH login. Use SSH proto 2.

    Disable passwords, x11 forwarding, root logins

    Reduce Idle timeout interval

    Limit users’ SSH access

    That should be more than enough for the average use case.

    • @taladar@sh.itjust.works
      link
      fedilink
      English
      91 year ago

      Regular updates are definitely necessary too. Also, if you do limit SSH users to a chroot make sure you limit TCP (port) forwarding too.

      • @foggy@lemmy.world
        link
        fedilink
        English
        11 year ago

        Yep. Use SSH keys, not just protocol.

        On connection, it’ll ask for your SSH password (this is different from the users password).

        After that with something like authelia in place, you’ll be asked for a 2fa code.

        • MaggiWuerze
          link
          fedilink
          English
          01 year ago

          So, no. SSH can’t do 2FA? I would need to set up Authelia and connect through that? I already use ssh keys instead of passwords to connect to my server

          • lemmyreader
            link
            fedilink
            English
            11 year ago

            It is possible to have 2FA with a security key and ssh. Been on my to do list for some time to try it.

          • @foggy@lemmy.world
            link
            fedilink
            English
            11 year ago

            Yes it can. I literally have it set up right now.

            When I connect to my vps I am promoted for the password for my SSH key. Only works on a machine that has the ssh key.

            Then I need to use 2fa.

            • MaggiWuerze
              link
              fedilink
              English
              11 year ago

              Ah, so it the asks for the TOTP provided by Authelia? I misunderstood, sorry. That’s pretty cool. Do you maybe still have the guide you used to set that up?

  • @catloaf@lemm.ee
    link
    fedilink
    English
    25
    edit-2
    1 year ago

    Don’t expose anything to the Internet that you don’t absolutely have to. If you can, put everything behind a VPN gateway.

    Make backups. Follow the 3-2-1 rule.

    • ChaoticNeutralCzech
      link
      fedilink
      English
      31 year ago

      That’s why “availability” is a core tenet of security (according to some cybersecurity course I took). It is easy to prevent unauthorized access to data if you have no requirements on authorized access.

  • @h3ndrik@feddit.de
    link
    fedilink
    English
    15
    edit-2
    1 year ago
    • fail2ban / brute forcing prevention
    • quick, frequent updates(!)
    • containerization / virtualization
    • secure passwords, better keys
    • firewall
    • a hardened operating system (distribution)
    • SELinux / Apparmor / … / OpenBSD
    • not installing unnecessary stuff
    • An admin who is an expert and knows what they do.
    • Midnight Wolf
      link
      fedilink
      English
      31 year ago

      Me, two+ decades into tinkering and still a dumbass: “look at me, I’m the expert admin now”

    • @perishthethought@lemm.ee
      link
      fedilink
      English
      141 year ago

      … is an intrusion prevention software framework. Written in the Python programming language, it is designed to prevent brute-force attacks. It is able to run on POSIX systems that have an interface to a packet-control system or firewall installed locally, such as iptables or TCP Wrapper.

  • Pyrosis
    link
    fedilink
    English
    51 year ago

    Firewall and deciding on an entry point for system administration is a big consideration.

    Generating a strong unique password helps immensely. A password manager can help with this.

    If this is hosting services reducing open ports with something like Nginx Proxy Manager or equivalent. Tailscale and equivalent(wire guard, wireguard-easy, headscale, net bird, and net maker) are also options.

    Getting https right. It’s not such a big deal if all the services are internal. However, it’s not hard to create an internal certificate authority and create certs for services.

    If you have server on a VPS. Firewall is again your primary defense. However, if you expose something like ssh fail2ban can help ban ips that make repeated attempts to login to your system. This isn’t some drop in replacement for proper ssh configuration. You should be using key login and secure your ssh configuration away from password logins.

    It also helps if you are using something like a proxy for services to setup a filter list. NPM for example allows you to outright deny connection attempts from specific IP ranges. Or just deny everything and allow specific public IPs.

    Also, if you are using something like proxmox. Remember to configure your services for least privileges. Basically the idea being just giving a service what it needs to operate and no more. This can encompass service user/group names for file access ect.

    All these steps add up to pretty good security if you constantly assess.

    Even basic steps in here like turning on the firewall and only opening ports your services need help immensely.

  • lemmyreader
    link
    fedilink
    English
    41 year ago

    Ask yourself a few questions first before following the massive amount of suggestions and then locking yourself out and so on.

    • What are you worried about ?
    • How important is your stuff ?
    • Make backups and check them

    Still worried ? Then there’s the easy way out : Hire some security auditor to help you find holes you left.

  • @LordOfTheChia@lemmy.world
    link
    fedilink
    31 year ago

    Do a search for you server OS + STIG

    Then, for each service you’re hosting on that server, do a search for:

    Service/Program name + STIG/Benchmark

    There’s tons of work already done by the vendors in conjunction with the DoD (and CIS) to create lists of potential vulnerable settings that can be corrected before deploying the server.

    Along with this, you can usually find scripts and/or Ansible playbooks that will do most of the hardening for you. Though it’s a good Idea to understand what you do and do not need done.

  • slazer2au
    link
    fedilink
    English
    -41 year ago

    Move services away from known ports and don’t use ports that end with well known port numbers (22,80,443).

    Moving ssh from 22 to 2222 or 443 to 10443 does nothing. You have ~65000 ports. Pick something random like 6744 or 2458