7 ms·

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-security https://www.

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

atonse 10y ago
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 the link.
- robotdan 10y ago
  Agreed - it is a bit long. But if you want to set something up from top to bottom it may be worth it. Cool - I saw the link to Github as well, looks like there is code to do much of what the article outlines. Awesome.
  - brokenwren 10y ago
    The hackthis application that is referenced in the guide is also in Github here: https://github.com/inversoft/passport-js-example https://github.com/inversoft/passport-js-example It uses Ember, Node.js, Express, Sequelize, MySQL and Passport User Database (https://www.inversoft.com/products/user-database-sso https://www.inversoft.com/products/user-database-sso).
- throwanem 10y ago
  The problem isn't that it's long; the problem is that it's not navigable - there needs to be a table of contents. There's great stuff in here, but it's hard to sort out what I already know how to do from what I can actually use.
  - JdeBP 10y ago
    There is a table of contents in the PDF version.
    - throwanem 10y ago
      Yeah, but it's a PDF. Anyway, why can't you generate a TOC into the HTML version from whatever format you're actually authoring in? Good tooling support should make this not hard. EDIT: And now the HTML version has a TOC, too! Talk about immediate gratification -- kudos to whoever did that!
  - brokenwren 10y ago
    HTML version now has a TOC as well!
  - hendry 10y ago
    I wrote a tool the other day to help create a Table of Contents https://github.com/kaihendry/toc https://github.com/kaihendry/toc
- deleted 10y ago
  [deleted]
- peterwwillis 10y ago
  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 that these are seen as detrimental today.
  - wandering2 10y ago
    So are they outdated now?
    - Swannie 10y ago
      A lot of the commands they documented have become obsolete or out of fashion. E.g. Apache 1, BIND, sendmail, cgi-bin, ifconfig, etc.
  - thrkw123456789 10y ago
    Check out the arch linux wiki.
  - viraptor 10y ago
    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.
    - peterwwillis 10y ago
      It seems like there a bunch of articles there but they're more like notes on how to use a tool specifically with Arch, rather than a guide for everyone. Compare this page http://www.tldp.org/HOWTO/Quota.html http://www.tldp.org/HOWTO/Quota.html to this page https://wiki.archlinux.org/index.php/Disk_quota https://wiki.archlinux.org/index.php/Disk_quota . TLDP organized HOWTOs like mini-books; tables of content, multiple authors, versioned releases, and of course, you could download them all and search through them by category. And they didn't assume things like the distribution setting up a bunch of the tools and system for you, so you learned how the tools actually worked.
codelitt 10y ago
Yes. We originally just put this together just as a primer for younger engineers to understand the basic steps. The guide you posted looks really good though. It looks like it covers some of the application side of things as well.
- robotdan 10y ago
  So many people get some of the most basic security wrong. It is great to see people trying to educate instead of just pointing out issues. Thanks for this work.
- brokenwren 10y ago
  I love the fail2ban part of your guide! I totally need to try that.
0xmohit 10y ago
Another not so long guide: https://www.digitalocean.com/community/tutorials/7-security-measures-to-protect-your-servers https://www.digitalocean.com/community/tutorials/7-security-...
mkagenius 10y ago
We are preparing one focussing on application development: https://github.com/FallibleInc/security-guide-for-developers#the-security-checklist https://github.com/FallibleInc/security-guide-for-developers... (work in progress)
- abglassman 10y ago
  Great checklist.
tempVariable 10y ago
That is great as well. Quite extensive.
kderbe 10y ago
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.
- brokenwren 10y ago
  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.
  - hyperpape 10y ago
    BCrypt is apparently just fine in 2016: https://news.ycombinator.com/item?id=11120528 https://news.ycombinator.com/item?id=11120528.
  - wglb 10y ago
    It is in fact a 2016-era good security practice. And it is designed to prevent what your last sentence says.
brobinson 10y ago
>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 also interesting that this guide uses Linode which is a hosting company known to have had quite egregious security issues in the past. [2] [1] https://help.github.com/articles/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent/ https://help.github.com/articles/generating-a-new-ssh-key-an... [2] https://www.google.com/#q=linode+hack https://www.google.com/#q=linode+hack
- nnutter 10y ago
  Why must they be PULLED?
  - deleted 10y ago
    [deleted]
  - mastorrent 10y ago
    If a server can push backups, it must necessarily have credentials for and write access to that backup repository. If the server is compromised, that write access could be used to attack the backup repository as well. Pulling backups from a server removes the need for credentials or access to the backup repository.
    - pfg 10y ago
      That is one valid way of solving this problem. Another option is to have a permission system that allows you specify that the server can only append new data, but not delete or overwrite existing files. This is useful if you don't want the added complexity of having a separate "backup management" service, which could easily become a bottleneck if you are backing up a lot of data from multiple servers. One way to do this is with S3, for example, is to use an IAM role with only the "PutObject" permission, and enable object versioning for the bucket to prevent a compromised server from being able to delete data by overwriting existing files.
obitech 10y ago
Great guide!

atonse 10y ago

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 the link.

robotdan 10y ago
Agreed - it is a bit long. But if you want to set something up from top to bottom it may be worth it. Cool - I saw the link to Github as well, looks like there is code to do much of what the article outlines. Awesome.
- brokenwren 10y ago
  The hackthis application that is referenced in the guide is also in Github here: https://github.com/inversoft/passport-js-example https://github.com/inversoft/passport-js-example It uses Ember, Node.js, Express, Sequelize, MySQL and Passport User Database (https://www.inversoft.com/products/user-database-sso https://www.inversoft.com/products/user-database-sso).
throwanem 10y ago
The problem isn't that it's long; the problem is that it's not navigable - there needs to be a table of contents. There's great stuff in here, but it's hard to sort out what I already know how to do from what I can actually use.
- JdeBP 10y ago
  There is a table of contents in the PDF version.
  - throwanem 10y ago
    Yeah, but it's a PDF. Anyway, why can't you generate a TOC into the HTML version from whatever format you're actually authoring in? Good tooling support should make this not hard. EDIT: And now the HTML version has a TOC, too! Talk about immediate gratification -- kudos to whoever did that!
- brokenwren 10y ago
  HTML version now has a TOC as well!
- hendry 10y ago
  I wrote a tool the other day to help create a Table of Contents https://github.com/kaihendry/toc https://github.com/kaihendry/toc
deleted 10y ago
[deleted]
peterwwillis 10y ago
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 that these are seen as detrimental today.
- wandering2 10y ago
  So are they outdated now?
  - Swannie 10y ago
    A lot of the commands they documented have become obsolete or out of fashion. E.g. Apache 1, BIND, sendmail, cgi-bin, ifconfig, etc.
- thrkw123456789 10y ago
  Check out the arch linux wiki.
- viraptor 10y ago
  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.
  - peterwwillis 10y ago
    It seems like there a bunch of articles there but they're more like notes on how to use a tool specifically with Arch, rather than a guide for everyone. Compare this page http://www.tldp.org/HOWTO/Quota.html http://www.tldp.org/HOWTO/Quota.html to this page https://wiki.archlinux.org/index.php/Disk_quota https://wiki.archlinux.org/index.php/Disk_quota . TLDP organized HOWTOs like mini-books; tables of content, multiple authors, versioned releases, and of course, you could download them all and search through them by category. And they didn't assume things like the distribution setting up a bunch of the tools and system for you, so you learned how the tools actually worked.

codelitt 10y ago

Yes. We originally just put this together just as a primer for younger engineers to understand the basic steps. The guide you posted looks really good though. It looks like it covers some of the application side of things as well.

robotdan 10y ago
So many people get some of the most basic security wrong. It is great to see people trying to educate instead of just pointing out issues. Thanks for this work.
brokenwren 10y ago
I love the fail2ban part of your guide! I totally need to try that.

0xmohit 10y ago

Another not so long guide: https://www.digitalocean.com/community/tutorials/7-security-measures-to-protect-your-servers https://www.digitalocean.com/community/tutorials/7-security-...

mkagenius 10y ago

We are preparing one focussing on application development: https://github.com/FallibleInc/security-guide-for-developers#the-security-checklist https://github.com/FallibleInc/security-guide-for-developers... (work in progress)

abglassman 10y ago
Great checklist.

tempVariable 10y ago

That is great as well. Quite extensive.

kderbe 10y ago

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.

brokenwren 10y ago
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.
- hyperpape 10y ago
  BCrypt is apparently just fine in 2016: https://news.ycombinator.com/item?id=11120528 https://news.ycombinator.com/item?id=11120528.
- wglb 10y ago
  It is in fact a 2016-era good security practice. And it is designed to prevent what your last sentence says.

brobinson 10y ago

>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 also interesting that this guide uses Linode which is a hosting company known to have had quite egregious security issues in the past. [2] [1] https://help.github.com/articles/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent/ https://help.github.com/articles/generating-a-new-ssh-key-an... [2] https://www.google.com/#q=linode+hack https://www.google.com/#q=linode+hack

nnutter 10y ago
Why must they be PULLED?
- deleted 10y ago
  [deleted]
- mastorrent 10y ago
  If a server can push backups, it must necessarily have credentials for and write access to that backup repository. If the server is compromised, that write access could be used to attack the backup repository as well. Pulling backups from a server removes the need for credentials or access to the backup repository.
  - pfg 10y ago
    That is one valid way of solving this problem. Another option is to have a permission system that allows you specify that the server can only append new data, but not delete or overwrite existing files. This is useful if you don't want the added complexity of having a separate "backup management" service, which could easily become a bottleneck if you are backing up a lot of data from multiple servers. One way to do this is with S3, for example, is to use an IAM role with only the "PutObject" permission, and enable object versioning for the bucket to prevent a compromised server from being able to delete data by overwriting existing files.

obitech 10y ago

Great guide!