Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My First 10 Minutes on a Server

codelitt.com

Post reply on HN
Print view View original

171–180 of 298 posts

Re: My First 10 Minutes on a Server

#171

Post by codelitt »

pnathan wrote: post #149
larrywright wrote: post #101

Earlier quoted context omitted.

Hardening (along with any other server setup/configuration) should be implemented using some idempotent configuration management software (Chef, Puppet, Ansible, etc). It's 2016, there's no need to configure servers manually.

Right, I was thinking myself... why not have a chef recipe do this, and walk through the systems as you do that. Ideally the server comes up and applies chef, doing the needful to secure it. Hand-cooking a server is extremely painful.

I mention Ansible and other tools in the article. The idea, as others have mentioned, is to teach a man to fish. You're much better off with having an automated way to perform this, but you shouldn't ever run anything automated that you don't understand.

We'll release an Ansible Playbook over the next week or so that follows these steps.

Re: My First 10 Minutes on a Server

#172

Post by windsurfer »

chrisseaton wrote: post #169
windsurfer wrote: post #140

Earlier quoted context omitted.

Years? How long a password would you need to make GPU cracking take years?

You're already given your own concrete time estimate - 'hours' - how did you work that out?

An old article I read about password cracking using EC2 while back... let me look it up.

Re: My First 10 Minutes on a Server

#173

Post by brokenwren »

kderbe wrote: post #145
brokenwren wrote: post #7

This one is pretty decent but if you want the ultimate guide check out this one: https://www.inversoft.com/guides/2016-guide-to-user-data-sec... It covers 10x what all the other guides cover in terms of server and application security. It was posted a few weeks ago on HN but didn't make the front-page.

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 password.

Re: My First 10 Minutes on a Server

#174

Post by chrisseaton »

ryanlol wrote: post #166
windsurfer wrote: post #140

Earlier quoted context omitted.

Years? How long a password would you need to make GPU cracking take years?

A very short one. Reasonable 10+ character passwords should remain out of reach for years. Also, AFAIK there doesn't currently exist any very effective GPU cracking software for SSH passphrases.

I went to lookup the algorithm GPG uses to encrypt private keys, to help answer the original question, but couldn't seem to find that information anywhere. Do you know what it is?

Re: My First 10 Minutes on a Server

#175

Post by codelitt »

Theodores wrote: post #117

I would be annoyed with a cryptic Audi password. I would prefer 'BatteryHorseStaple' passwords. Anything I can't remember gets written on a post it note and put next to my screen with what it is for. This is my behaviour and the problem with cryptic passwords is that there are others like me, willing to keep a good password secret and not willing to be so secret about a clumsy, easy to crack by machine but impossible…

Get a PW manager instead. No passwords should be stored in your head (because every one should be different) and they should be stored behind encryption -- definitely not plain text nor sticky notes.

http://keepass.info/download.html

Re: My First 10 Minutes on a Server

#176

Post by belorn »

raesene6 wrote: post #99
adrianmsmith wrote: post #95

What's the reason for using a firewall? Assuming that services which shouldn't be accessible to the outside only listen to localhost not the network (e.g. MySQL on a LAMP stack), isn't that sufficient? (Honest question, I don't have much experience with syadmin.)

So there's a couple of reasons to add a firewall. 1. If an attacker gets unprivileged access it can slow them down (if properly configured) in getting new tools onto the system or adding a shell. 2. If a configuration error results in a service being started on a network accessible interface by accident the firewall gives you a bit of defence in depth protection against unauthorised connections to that server. 3. you…

1) An attacker getting access will only be slowed down/detected if your firewall filters outgoing traffic, which practically no one does because of the inconvenience and maintenance costs. You also need to lock down outgoing traffic to port 80/443, which is how many intrusions download their payloads and calls home for instruction. If you however accept the cost and do use a outgoing filter, it's quite effecting in detecting and stopping attacks, and it is something I recommend for defending assets with high security demands or high risk.

2) As for configuration errors, it depends on what kind of practices you use as a sysadmin. Do you download and run random scripts found on blogs, use experimental versions, and do not spend time reading manuals? Or are you someone who will only run a Debian stable, has verbose settings in aptitude and reads patch notes? It's been a long time (i.e., almost 20 years) since the last time I saw a program that allowed vulnerable interfaces to be accessible on the network without significant warnings in the manual, comments in the config file and readme. Projects and package maintainers have significantly stepped up their security practices, that by the time something reaches stable it should be matured enough that shooting yourself by accident is difficult.

Re: My First 10 Minutes on a Server

#178

Post by brokenwren »

brobinson wrote: post #160
brokenwren wrote: post #7

This one is pretty decent but if you want the ultimate guide check out this one: https://www.inversoft.com/guides/2016-guide-to-user-data-sec... It covers 10x what all the other guides cover in terms of server and application security. It was posted a few weeks ago on HN but didn't make the front-page.

>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…

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.

Re: My First 10 Minutes on a Server

#180

Post by archon810 »

My biggest concern with being on a VPS like Linode, once you're all done securing yourself and binding services to the local LAN IP, is an attack from within the network. The VPS you own is also accessible by others on the same subnet, contrary to what you might assume.

I'd love to see a ufw guide for whitelisting only your own internal IPs to be allowed access to any services for ultimate security.

Post reply on HN