Live data from Hacker News

My First 10 Minutes on a Server

codelitt.com

131–140 of 298 posts

Re: My First 10 Minutes on a Server

#131
post #9

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.

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 that these are seen as detrimental today.

Re: My First 10 Minutes on a Server

#132
post #84
post #2

echo "set background=dark" > /etc/vim/vimrc.local

All users in your team are forced to use dark terminal backgrounds?

You can actually autodetect whether the terminal background is light or dark. For any xterm-compatible terminal, write '\x1b]11;?\x07' to the terminal, and it'll write back a string telling you the foreground color (for instance, '\x1b]11;rgb:0000/0000/0000\x07', which if written back would set the foreground color). If the color matches 'rgb/RRRR/GGGG/BBBB', compute the luminance of that color, and assume a dark background if <0.5 and light otherwise.

Re: My First 10 Minutes on a Server

#133
Not sure if others feel this way but adding this line to sudo never felt right to me...

deploy ALL=(ALL) ALL

I usually instead limit the deploy user to a smaller subset of commands e.g. the init.d script to control a service.

obviously if someone gained access to deploy user we're probably sol anyway... but it just makes it seem safer... we have a to login as an ops user to install or update things on the boxes.

Re: My First 10 Minutes on a Server

#134
I guess I'm a pretty big noob, but why do people recommend so strongly on password protecting your private key? Losing it pretty much dooms you whether or not it's password protected. It might get you a few hours or so to react and invalidate the public key, I guess...

Re: My First 10 Minutes on a Server

#135

I guess I'm a pretty big noob, but why do people recommend so strongly on password protecting your private key? Losing it pretty much dooms you whether or not it's password protected. It might get you a few hours or so to react and invalidate the public key, I guess...

If you've got a good password on your key, then nobody will be able to use it in years. It most certainly helps.

Re: My First 10 Minutes on a Server

#136
post #69

Earlier quoted context omitted.

I agree that fail2ban for ssh seems unnecessary. But, it also provides monitoring for other services like http and common exploits. I'd be interested in learning from the community if fail2ban adds much value. As I've looked into the service, it seems like simply running the latest security patches obviates the need for fail2ban.

I run a web server with some 50+ Wordpress installs on it. You better believe Fail2Ban is necessary. Without it all resources would be consumed by brute force attacks. If someone knows of a better way I would like to hear about it.

In my experience, better to let a webserver handle stopping bad traffic by whitelisting WordPress endpoints.

Parsing a url and returning 404 from nginx is cheap and scalable, and allows through legitimate traffic that may be sharing an IP (such as TOR).

Re: My First 10 Minutes on a Server

#137
post #84

Earlier quoted context omitted.

All users in your team are forced to use dark terminal backgrounds?

You can actually autodetect whether the terminal background is light or dark. For any xterm-compatible terminal, write '\x1b]11;?\x07' to the terminal, and it'll write back a string telling you the foreground color (for instance, '\x1b]11;rgb:0000/0000/0000\x07', which if written back would set the foreground color). If the color matches 'rgb/RRRR/GGGG/BBBB', compute the luminance of that color, and assume a dark bac…

I didn't know about this, but from now on, when writing CLIs that use color, I'm going to take this into account!

Re: My First 10 Minutes on a Server

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

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.

HTML version now has a TOC as well!

Re: My First 10 Minutes on a Server

#140

I guess I'm a pretty big noob, but why do people recommend so strongly on password protecting your private key? Losing it pretty much dooms you whether or not it's password protected. It might get you a few hours or so to react and invalidate the public key, I guess...

If you've got a good password on your key, then nobody will be able to use it in years. It most certainly helps.

Years? How long a password would you need to make GPU cracking take years?
Post reply on HN