136
submitted 6 months ago by SomeBoyo@feddit.de to c/selfhosted@lemmy.world
top 50 comments
sorted by: hot top controversial new old
[-] foggy@lemmy.world 53 points 6 months 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 12 points 6 months 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.

[-] possiblylinux127@lemmy.zip 4 points 6 months ago

Containers can help lock services down if you do it right.

[-] MaggiWuerze@feddit.de 3 points 6 months ago
load more comments (5 replies)
[-] catloaf@lemm.ee 34 points 6 months ago* (last edited 6 months 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.

[-] SomeBoyo@feddit.de 5 points 6 months ago

Will a wireguard docker image work for getting ssh access to my server?

[-] taaz@biglemmowski.win 10 points 6 months ago* (last edited 6 months ago)

I wouldn't recommend putting ssh behind any vpn connection unles you have a secondary access to the machine (for example virtual tty/terminal from your provider or local network ssh). At best, ssh should be the only publicly accessible service (unless hosting other services that need to be public accessible).

I usually move the ssh port to some higher number just to get rid of the basic scanners/skiddies.

Also disable password login (only keys) and no root login.

And for extra hardening, explicitly allow ssh for only users that need it (in sshd config).

[-] Poutinetown@lemmy.ca 8 points 6 months ago

Ssh behind a wire guard VPN server is technically more secure if you don't have a key-only login, but a pain if the container goes down or if you need to access the server without access to wireguards VPN client on your device.

[-] Lem453@lemmy.ca 10 points 6 months ago* (last edited 6 months ago)

Highly recommend getting a router that can accept wireguard connections. If the router goes down you're not accessing anything anyways.

Then always put ssh behind the wireguard connections.

For a homelab, there is rarely a need to expose ssh directly so best practice will always be to have multi layered security when possible.

[-] Poutinetown@lemmy.ca 4 points 6 months ago

Yeah it's good to have a system separate from the main server. It's always so frustrating having to debug wireguard issues cause there's some problem with docker

load more comments (1 replies)
[-] h3ndrik@feddit.de 21 points 6 months ago* (last edited 6 months 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.
[-] wreckedcarzz@lemmy.world 3 points 6 months ago

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

[-] Harbinger01173430@lemmy.world 19 points 6 months ago

Don't turn it on is the ultimate technique

[-] ChaoticNeutralCzech@feddit.de 3 points 6 months 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.

[-] A_Random_Idiot@lemmy.world 1 points 6 months ago

barring that, unplug the ethernet.

[-] Deckweiss@lemmy.world 15 points 6 months ago
[-] perishthethought@lemm.ee 19 points 6 months 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.

[-] SirMaple_@lemmy.sirmaple.ca 12 points 6 months ago
  • crowdsec
  • SSH - change port, disable root login, disable password login, setup SSH keys using SK(YubiKey in my case)
  • nftables - I use https://github.com/etkaar/nftm to keep things quick and simple. I like the fact if will convert DNS entries to IPs. I then just use dynamic DNS update clients on all my endpoints
  • WireGuard for access to services other than SSH(in some cases port 443 will be open if its a web server or proxy)
  • rsyslog to forward auth logs to my central syslog server
[-] ShortN0te@lemmy.ml 3 points 6 months ago

disable root login

That does not do much in practice. When a user is compromised a simple alias put in the .bashrc can compromise the sudo password.

Explicitly limit the user accounts that can login so that accidentally no test or service account with temporary credentials can login via ssh is the better recommendation.

[-] drkt@lemmy.dbzer0.com 8 points 6 months ago

I think the point is that root is a universal user found on all linux systems where as users have all kinds of names. It narrows down the variables to brute-force, so simply removing the ability to use it means they have to guess a username and a password.

[-] ShortN0te@lemmy.ml 3 points 6 months ago

guess a username and a password.

Security by obscurity is no security. Use something like fail2ban to prevent brute force. When you use a secure password and or key this also does not matter much.

[-] wreckedcarzz@lemmy.world 2 points 6 months ago

Something something don't let 'good' be the enemy of 'perfect'

[-] possiblylinux127@lemmy.zip 8 points 6 months ago

Check out online resources such as the Nist cyber stuff.

Basic things include disabling unnecessary services, disabling password authentication, setting up and verifying the firewall, configuring selinux and so on.

[-] dallen@programming.dev 6 points 6 months ago

I like to require access to 22 via IP whitelist and all services on SSL behind a reverse proxy. Doesn’t leave much surface to attack.

[-] phoenixz@lemmy.ca 5 points 6 months ago

Also, move ssh to a different, higher port. Since ssh isn't exactly for noobs, changing the port is easy enough to work with and that alone already reduces port scans and what not

[-] nik282000@lemmy.ca 2 points 6 months ago

I recently setup Guacamole (Web based VNC/RDP/SSH) with totp and was able to close external SSH access. Now everything I run can sit behind a single reverse proxy, no extra ports.

[-] pyrosis@lemmy.world 6 points 6 months 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.

[-] possiblylinux127@lemmy.zip 3 points 6 months ago

The biggest thing is to change the defaults and to limit access. Unless your are the target of a nation state the attacks against your network will be automated.

[-] lemmyreader@lemmy.ml 6 points 6 months 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.

[-] chyi@fasheng.ing 5 points 6 months ago

Minimize installation and keep it streamlined. Update promptly. Choose applications that are still supported or have an active community.

[-] LordOfTheChia@lemmy.world 4 points 6 months 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.

[-] TheDarkBanana87@lemmy.world 3 points 6 months ago

Stumbled uppon this guide

https://github.com/imthenachoman/How-To-Secure-A-Linux-Server

I think its a good place to start

[-] Decronym@lemmy.decronym.xyz 3 points 6 months ago* (last edited 4 months ago)

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:

Fewer Letters More Letters
DNS Domain Name Service/System
IP Internet Protocol
SSH Secure Shell for remote terminal access
SSL Secure Sockets Layer, for transparent encryption
TCP Transmission Control Protocol, most often over IP
VNC Virtual Network Computing for remote desktop access
VPN Virtual Private Network
VPS Virtual Private Server (opposed to shared hosting)

[Thread #693 for this sub, first seen 20th Apr 2024, 15:55] [FAQ] [Full list] [Contact] [Source code]

[-] Reaper948@lemmy.world 3 points 6 months ago

Air gapping

/s

[-] ___@lemm.ee 2 points 6 months ago

Run SCAP tool with a STIG baseline.

[-] rimu@piefed.social 2 points 6 months ago

Ubuntu has a set of scripts you can run to harden a new server (not advisable on a server that has already been configured for something). You need an Ubuntu Pro subscription to access them but you can get a free trial and then cancel it after you've finished.

More info at https://ubuntu.com/security/cis.

I did this process for a customer recently and it was pretty straightforward and much much more thorough (over 100 configuration changes) than just tweaking SSH and fail2ban.

I expect other commercially-oriented distros offer something similar.

[-] tills13@lemmy.world 3 points 6 months ago

Leak the scripts?

load more comments (1 replies)
load more comments
view more: next ›
this post was submitted on 20 Apr 2024
136 points (98.6% liked)

Selfhosted

39937 readers
406 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 1 year ago
MODERATORS