Live data from Hacker News

My First 10 Minutes on a Server

codelitt.com

251–260 of 298 posts

Re: My First 10 Minutes on a Server

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

I wrote a tool the other day to help create a Table of Contents https://github.com/kaihendry/toc

Re: My First 10 Minutes on a Server

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

Check out the arch linux wiki.

Re: My First 10 Minutes on a Server

#253
post #190

Earlier quoted context omitted.

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

It's also easy to do this with Tarsnap. You can split out your host keys with tarsnap-keymgmt into separate read, write, and delete keys. Just take your delete key off of the host and store it somewhere secure.

Or better yet, create the key somewhere else and only upload the keys you want to have on the server. Otherwise there's a chance that the original tarsnap key is left in an unallocated block.

Re: My First 10 Minutes on a Server

#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.rocks/blog/monit-configuration-with-slack/

Re: My First 10 Minutes on a Server

#255

Why do people install fail2ban then disable password based authentication entirely? I legitimately don't understand the purpose. Also, they complain about log spam (from failed SSH attempts) this is one reason to move SSH to a different port. It does NOT increase security, but it DOES reduce log spam from bots trying for easy targets.

I always change the ssh port to something other than 22. It has always seemed to work well for me for most automated attacks. Perhaps this is not advisable for some reason?

From experience, running ssh on non-default port have mostly reduced automated login attempts to 0, year after year.

Re: My First 10 Minutes on a Server

#256
post #77
post #45

I'm finding that another important step is this one: apt-get install etckeeper && cd /etc && etckeeper init Keeps your /etc under version control so you know what kinds of configuration changes you've perpetrated.

I used to use this, but I found that it's significantly less useful than a git repo with my server-specific Chef cookbook in it. Manually modifying servers was never a good idea; it's worse now, even with tools like this.

I suppose that's true, but in the field where I work (social science), servers are mostly spun up to scratch an immediate and idiosyncratic itch, so configuration tends to happen organically.

I agree that's probably not a good idea, and learning Pupchefsible is well worth the effort. In the meantime, though, there's at least some degree of reproducibility with etckeeper.

Re: My First 10 Minutes on a Server

#257

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

Re: My First 10 Minutes on a Server

#258
post #73

I don't mean to sound flippant but why can't these "lock down your new box" tutorials just be a bash script? Shouldn't they be?

They could be, or you could take the route you won't regret later and use a configuration management system. Deutsche Telekom has open-sourced system-hardening cookbooks for Chef, Puppet, and Ansible.

Good to know. I did some searching and found them here: http://dev-sec.io/

Re: My First 10 Minutes on a Server

#259
post #238

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

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

True. But compare the effort required for, say, solving an accidentally misconfigured /etc/sudoers on a database server. You could argue that would never happen with proper testing, but shit happens and and having a particularly long root password in Keepass is a small price to pay to save that sort of headache.

Re: My First 10 Minutes on a Server

#260

Earlier quoted context omitted.

Why must they be PULLED?

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.

Plus, if you're super paranoid, pulling doesn't require leaving any ports open and software listening on the repository.
Post reply on HN