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

151–160 of 298 posts

Re: My First 10 Minutes on a Server

#151

Post by hrez »

VLM wrote: post #37
JoshTriplett wrote: post #28

Earlier quoted context omitted.

> And how exactly did you lock yourself out of every account with sudo? A single typo in /etc/sudoers or any /etc/sudoers.d file will lock you out of all sudo usage. visudo helps with that, but a single mistake (including in a sudoers.d file installed by a configuration management system or package) will lock you out.

Yes sir, and that's why the paranoid sysadmin ssh's in, sudo su's up, THEN runs ansible and tests that it works before unleashing the ansible (or puppet) across the entire network. Also if you do the "group auth" thing in sudoers then you edit that file approximately once per employment and never touch sudoers again. Of course that abstracts the problem into "I deleted the wheel (or sudo, or ...) group on the ldap se…

I prefer lazy sysadmin that avoids all that manual ssh/sudo by making puppet/etc validate sudoers before updating it. You can syntax check with visudo -c.

Re: My First 10 Minutes on a Server

#152

Post by pnathan »

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

Suppose someone gets access to the box. They shouldn't be able to curlbash http://evilscript.sh into the system.

So you really want to lock all outgoing and all incoming except for very specific channels and protocols to controlled endpoints.

Re: My First 10 Minutes on a Server

#153

Post by JoshTriplett »

moosingin3space wrote: post #137
JoshTriplett wrote: post #132

Earlier quoted context omitted.

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!

Awesome; more tools should do that. Some caveats, though:

* You might not get a response from every terminal, so limit how long you wait.

* If you don't already have echo turned off, turn if off before sending the sequence, because otherwise it'll be visible as though the user typed it.

* You don't know that the color will use the "rgb:RRRR/GGGG/BBBB" format (a terminal can return anything XParseColor can understand); just read the string from the escape to the terminator, look for 'rgb:', and ignore formats you don't understand.

* To calculate whether a color is "light" or "dark", see https://en.wikipedia.org/wiki/Luma_%28video%29:

    dark = (0.299*red + 0.587*green + 0.114*blue)

Re: My First 10 Minutes on a Server

#155

Post by codelitt »

taf2 wrote: post #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.

Someone on /r/netsec rightly pointed out that you shouldn't ever add a user directly to sudoers anyways. You should add them to the sudo or wheel group. I've since updated the article.

What I've described is a more of a base, but according the Principle of Least Privilege you could go even one step further and do what you're suggesting. You'd probably want to have a couple of users though. An admin user, a deploy user, and a maintain user all with different privileges.

Re: My First 10 Minutes on a Server

#157

Post by thatusertwo »

I have a VPS, when I first got it, it had an additional user setup for some unknown reason. I didn't know it was there until my server was hacked by a bot. I'd suggest adding one step of checking the /home directory or other places to make sure no 'unknown' accounts have been set up.

Re: My First 10 Minutes on a Server

#158

Post by MichaelGG »

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

That only works if you have an outbound firewall. Which is very onerous - you'd either have to whitelist destinations (package repos, but what if you want to validate arbitrary certificate's CRLs?) or whitelist applications (but not wget etc.)

Re: My First 10 Minutes on a Server

#159

Post by MichaelGG »

amelius wrote: post #22

For protecting against brute-force login attempts, I use sshguard [1] I really think this should be installed by default on distros like Ubuntu. [1] http://www.sshguard.net/

I can't see any benefit, what am I missing? Put SSH on a port that's not 22 and done, no more mass scanning. The only thing SSHGuard has ever done for me is to lock me out when I was accidentally using the wrong key.

Re: My First 10 Minutes on a Server

#160

Post by brobinson »

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

[2] https://www.google.com/#q=linode+hack

Post reply on HN