My First 10 Minutes on a Server • Hacker News Board

Re: My First 10 Minutes on a Server

#261

Post by brobinson » Thu, Jun 16, 2016, 9:10 AM UTC

hueving wrote: post #170

brobinson wrote: post #160

Earlier quoted context omitted.

>2048 bit RSA keys Github recommends 4096 now, for what it's worth. [1] >Pushing database backups offsite This is a really bad idea and a good way to get owned. Database backups must be PULLED from the server, not pushed from it. Separately, you also need to test that you can restore from your backups periodically. There were a couple other things I disagree with, but they're in the realm of personal preference. It's…

>This is a really bad idea and a good way to get owned. Database backups must be PULLED Just make sure your database server doesn't have permission to delete backups (e.g. Have it POST a backup via HTTPS). There is nothing wrong with db server initiated backups.

This is still open to abuse in the form of your legitimate backup script being disabled and replaced by one uploading false backups. You wouldn't know anything has happened until you go to restore from one.

Of course, this is an edge case, but I believe setting up a pull-based backup system is still going to be less work than a write-only push system.

Re: My First 10 Minutes on a Server

#262

Post by kingosticks » Thu, Jun 16, 2016, 9:14 AM UTC

p8donald wrote: post #254

Since I changed the default SSH port of 22 to something else (like 4422), I no longer get any of these drive-by attacks and don't need fail2ban anymore. I also like to set up a simple Monit configuration to alert me about high cpu usage or when the disk space is about to run out. Instead of emailing me these alerts (and also weekly reports) I've configured Monit to post them to my Slack team of 1. https://peteris.roc…

You should still use fail2ban.

https://news.ycombinator.com/item?id=11854576

Re: My First 10 Minutes on a Server

#263

Post by [deleted] » Thu, Jun 16, 2016, 9:22 AM UTC

stqism wrote: post #257

babuskov wrote: post #122

> First we'll want to make sure that we are supporting IPv6 How does that help security?

That comment was in regards to ufw as it doesn't support adding IPv6 rules by default in commands in older Ubuntu. If you don't enable IPv6 and the server supports it (odds are it does) all of the benefits of using ufw at all are totally ignored on IPv6.

[deleted]

Re: My First 10 Minutes on a Server

#264

Post by viraptor » Thu, Jun 16, 2016, 9:36 AM UTC

peterwwillis wrote: post #131

atonse wrote: post #9

Earlier quoted context omitted.

My worry here is that, in posting what seems to be a book, people just won't even do it because we don't have time to do it, unless this is a primary part of their jobs. If a 10 minute guide gets users 90% of the way, then they're more likely to do it. And that's good enough to cover a majority of automated attacks. Update: I take it back – they've provided scripts to run this stuff. I will explore these. Thanks for…

Back in the day, The Linux Documentation Project had a trove of hundreds of HOWTOs covering every facet of using Linux. By today's standards they seem like "books", but in reality they were step-by-step instructions for anything you could ever want to do in Linux. No digging through forums, no combing through man pages, no following broken outdated blog posts that didn't explain what you were doing. I find it sad tha…

I feel like arch wiki is that thing today. It's a bit disorganised and things get outdated while nobody's looking, but there's almost anything you'd every want in there.

Re: My First 10 Minutes on a Server

#265

Post by codelitt » Thu, Jun 16, 2016, 10:06 AM UTC

taneq wrote: post #238

jldugger wrote: post #19

> We don't even have a password for our root user. We'll want to select something random and complex. So you're taking something secure by default -- no password means no login allowed, and making it less secure. And if you have hundreds of these servers, you'll need to rotate them whenever someone on the team leaves. This is painful. Simple solution: leave root password blank, don't forget your sudo password. If you…

This part struck me as odd, too, especially when you consider the justification: That if you lose access to your sudo account/password, you must have some other way to get into the system. Backups should include everything required to rebuild every server in the company. No server should be 'too critical' to wipe and start again if required. So maybe I'm being too much of an armchair warrior here, but the reason I do…

You still can't login to the system. Root login is disabled as well as password authentication. The root password is just in case you lose your sudo password but it doesn't provide you a way to login if you don't have your key, passphrase to your key, access to the static IP/VPN and device with 2FA.

Re: My First 10 Minutes on a Server

#266

Post by jjnoakes » Thu, Jun 16, 2016, 11:49 AM UTC

brobinson wrote: post #226

brokenwren wrote: post #178

Earlier quoted context omitted.

I agree that pulling does appear to be more secure, but if someone breaches any of your servers undetected, you're pretty much hosed regardless. Plus, the Inversoft guide specifically states that backups must be encrypted. I could put my backup ZIPs on a public Github repository and no one would be able to access the user data stored inside it. Therefore, it really doesn't matted if they are pushed or pulled.

If a script or cronjob or whatever on the server has write access to the repo, so does the hypothetical attacker. I remember seeing a "hacking" website get wiped along with all of its backups about 15 years ago and it left a very strong impression on me regarding this issue.

If it is write access but not delete access (nor overwrite access) then there is no issue.

It is sometimes more secure to push because it requires no inbound connections or authorizations the live machine.

Re: My First 10 Minutes on a Server

#267

Post by Swannie » Thu, Jun 16, 2016, 12:43 PM UTC

wandering2 wrote: post #192

peterwwillis wrote: post #131

Earlier quoted context omitted.

Back in the day, The Linux Documentation Project had a trove of hundreds of HOWTOs covering every facet of using Linux. By today's standards they seem like "books", but in reality they were step-by-step instructions for anything you could ever want to do in Linux. No digging through forums, no combing through man pages, no following broken outdated blog posts that didn't explain what you were doing. I find it sad tha…

So are they outdated now?

A lot of the commands they documented have become obsolete or out of fashion.

E.g. Apache 1, BIND, sendmail, cgi-bin, ifconfig, etc.

Re: My First 10 Minutes on a Server

#268

Post by codelitt » Thu, Jun 16, 2016, 12:52 PM UTC

plusbryan wrote: post #244

What was wrong with 5 minutes? :-)

Nothing! (Except I doubt I can manually get it all done in 5 minutes =) ) Thanks for your great article.

We just ended up adapting your approach with a couple modifications (like 2FA) and extending it to be more of a primer and explain the steps a bit more so that the younger engineers understood what each step performed was doing. I found myself pointing them to your article, but then having to explain what was being performed and it's purpose (not a bad thing - just different audience).

As has been mentioned, in the real world, an Ansible Playbook should be performing these, but teach a man to fish, etc...

Re: My First 10 Minutes on a Server

#269

Post by codelitt » Thu, Jun 16, 2016, 1:03 PM UTC

raimue wrote: post #85

Be aware fail2ban does not handle IPv6 at all with its default configuration on Debian/Ubuntu. https://github.com/fail2ban/fail2ban/issues/1123

You're right. Took mwpmaybe's suggestion for the time being and only will accept IPv4 from ssh for now till that's fixed.

Re: My First 10 Minutes on a Server

#270

Post by wglb » Thu, Jun 16, 2016, 1:31 PM UTC

brokenwren wrote: post #173

kderbe wrote: post #145

Earlier quoted context omitted.

I don't know enough about server security to critique most of that guide, but the Password Security section is clearly behind the times: > Passwords should always be hashed using a strong, one-way hash algorithm. [...] hashed with an algorithm like SHA-256 7 times. If they had simply written "just use bcrypt" they'd be much closer to 2016-era security practices.

BCrypt works fine, but I wouldn't say it is "2016-era security practices". It was written in 1999 and hasn't had as much scrutiny as SHA or Blowfish (although it is based on Blowfish). Regardless, using a salted, multi-pass algorithm will keep everything nicely secured using nearly any hashing algorithm. Remember the goal is not to crack one user's password using a brute force lookup table, it is to crack everyone's…

It is in fact a 2016-era good security practice.

And it is designed to prevent what your last sentence says.