[HN Gopher] Ask HN: How do you securely self-host a server?
___________________________________________________________________
Ask HN: How do you securely self-host a server?
Every few weeks or so there is a post on HN pleading with people to
consider self hosting their own services. As enticing as that
sounds, I'm sure I'm not the only one that has no idea how to
secure said services. Spinning up a server is no problem, keeping
it secure on the other hand is a feat I have no idea how to
accomplish.
Author : QuikAccount
Score : 32 points
Date : 2022-03-09 18:57 UTC (4 hours ago)
| Bombthecat wrote:
| Run the cis benchmark tool.
| CKMo wrote:
| Depending on what you're interested in, try this out!
|
| https://discuss.pomerium.com/t/this-little-nas-that-could/80
| undead_bunny wrote:
| Reading this topic has made me realize I don't even have a very
| solid image of what a "server" would be in this case. Is it a
| machine running an OS? A specific program listening on a port?
|
| Does anyone have any recommendations for "Setting up a server
| 101" that could help shed some light on this?
|
| Thanks!
| jiveturkey wrote:
| You have to start with: What is secure?
| VTimofeenko wrote:
| I think "What is secure" is a bit too philosophical of a
| question. Perhaps a more practical approach would be to ask
| "What is your threat model?" and to frame the questions around
| the impact of a breach.
| rank0 wrote:
| It requires lots of knowledge and elbow grease. Your security
| concerns also greatly depend on what services you plan to make
| publicly available.
|
| The most important basic groundwork is proper firewall setup and
| network segmentation. Your personal LAN should not be directly
| routable from your public services. Also ensure that security
| updates are applied ASAP. Start learning about hypervisors and
| proper VM orchestration.
|
| The best way to get started IMO is via a hybrid approach. Use
| cloud resources where appropriate to supplement your local
| infrastructure.
| MitchellCash wrote:
| I prefer to run Ubuntu machines and at least in terms of
| provisioning a new secure server I built an Ansible playbook I
| called 'ANU' (as in A New Ubuntu). I'd expand to other distros,
| but then I'd have to change the name!
|
| https://github.com/MitchellCash/ansible-anu
|
| It is based on the DevSec OS/SSH hardening playbooks, but I lean
| closer towards ease-of-use over security where I think it makes
| sense. For example, I disable forced password rotation and I keep
| the default umask value of '022' instead of the more secure
| '027'.
|
| When I come across something the upstream playbooks change that
| "gets in my way", I will disable it if the security trade off
| makes sense for me. I'm not running highly sensitive systems, so
| these trade-offs make sense for me, and maybe they will for you
| as well!
|
| In terms of ongoing security upkeep, I run the usual `apt update
| && apt dist-upgrade` when I can, but I'll be keeping my eye on
| this thread for additional advice.
| more_corn wrote:
| Look at previous hacks. Un-patched packages and services, bad
| passwords, unexpected privileges.
|
| Only allow in the service port to minimize your attack surface.
| Automatic security updates. WAF if you can. Cloudflare has a free
| tier with WAF. Maybe deploy a SIEM so you can alert on unexpected
| behavior.
| blablabla123 wrote:
| Install only software that you use and prefer minimal
| installations. (Debian has good defaults) Then you can install
| the unattended-upgrades package and when using ssh don't setup a
| password but use ssh keys. Also ufw needs to be enabled and then
| you can use nmap to scan for open tcp and udp ports. (Of course
| it's also possible to filter outgoing connections, by default
| only the package servers need to be accessed)
|
| If you install services like email or http prefer software with a
| small footprint and with few CVEs in the past. Since http
| services are quite common, it's advisable to put a reverse proxy
| in front. Separate users for separate services is also a good
| idea.
|
| Never had any issues with that kind of setup. Of course it's
| possible to add additional hardening like using an ssh jump host
| or a VPN to access ssh. (Probably advisable if you plan to put
| private data on it) Also using SELinux is an option, Fedora has
| it by default.
| nicolaslem wrote:
| - Apply the principle of least privilege everywhere
|
| - Apply security patches regularly
|
| - Setup automated backups of important data
|
| Following these three points puts you ahead of 90% of servers out
| there.
| explaingarlic wrote:
| As far as DDOS protection goes, I'd like some tips there. Also, a
| question - if I have a 1Gbps home connection am I strictly
| screwed if someone is sending a little more than 1Gbps to me UDP-
| wise? It's the kind of question that seems simple but I've never
| been able to make my own simple answer.
| killingtime74 wrote:
| Are you opposed to using Cloudflare or other DDOS providers?
| I'm not sure what can be done on a small budget
| aaaaaaaaata wrote:
| Theoretical max upload is always just below the other side's
| max download.
| khalidx wrote:
| Does anyone have a link to a good server hardening guide that
| they can share here? Specifically and especially when running
| servers locally, or on things like AWS or DigitalOcean.
|
| So many guides online, and the uninitiated can rarely
| differentiate between a good one and an outdated one. I've used a
| good one in the past but can't think of it right now.
| more_corn wrote:
| 1) minimize your attack surface, only service ports allowed,
| use a load balancer if available, your security groups can be
| restricted to your IP address. Better yet you can deploy in a
| private subnet and use tailscale or a bastion host. 2)
| automatic security updates (unattended-upgrades on Debian
| based, yum-cron on rhel based) 3) use ssh keys and named
| accounts. Disable root and default logins (on aws the default
| account is ec2-user on Amazon linux and Ubuntu for Ubuntu
| images) 4) on aws trusted advisor recommends some good account
| hardening steps.
| bob1029 wrote:
| Your security objectives are important if you are hoping to make
| any meaningful progress.
|
| Are you concerned about DDOS? If yes, then don't self-host or use
| CF Tunnels.
|
| Are you concerned about someone hacking your site with a buffer
| overflow? If yes, then make sure you patch frequently.
|
| Are you concerned about someone hacking your site with any
| variant of a 0-day? If yes, then you need to air-gap and/or not
| use a computer at all.
|
| Are you concerned about crappy business logic letting a bad
| session in? If yes, then you are in the wrong rabbit hole. You
| should be fixing your software until it provides the necessary
| degree of confidence. This has nothing to do with the server or
| hosting.
|
| I don't think any of the above are modulated by self-hosting vs
| AWS hosting.
| efortis wrote:
| Broken down into a few topics:
|
| - Basics
|
| https://www.freebsd.org/cgi/man.cgi?security
|
| - Baseline Hardening
|
| https://github.com/uxtely/ops-utils/tree/main/location-serve...
|
| - Networking (Firewall, Jails/Containers)
|
| https://blog.uidrafter.com/freebsd-jails-network-setup
| alophawen wrote:
| How does 3 links to freebsd help op, they didn't even mention
| their OS.
___________________________________________________________________
(page generated 2022-03-09 23:02 UTC)