Live data from Hacker News

How I spend my first 5 minutes on a server

plusbryan.com

241–250 of 355 posts

Re: How I spend my first 5 minutes on a server

#241

The premise of this thing is not good advice. 1) Your first couple minutes on a server should be used to install a configuration management client, if your bootstrap policies somehow don't already install one. 2) Everything else listed in this document should be configured by a configuration management system. 3) "User account sync tools" should have no place in a modern infrastructure, you should use your configurat…

> This stuff isn't hard. It's worth doing right.

Can you provide an article as equally succinct as the OP's that provides this information? Your list is painfully devoid of anything of true value. Since it's not hard, and worth doing right, I imagine something should already be written.

Re: How I spend my first 5 minutes on a server

#242
post #129

Earlier quoted context omitted.

I, also, trust SSH more than any other software. But it is still worth adding an additional layer of security in front of SSH to help protect from exploits. Let's say that, hypothetically, a 0-day exploit was discovered in SSH which allowed remote code execution. A script kiddie begins trawling the internet for publicly accessible SSH servers to attack. Your servers allow SSH from anywhere on the internet, and are ev…

This is just faulty logic. openssh is one of the most secure projects. It's developed by the security obsessed (and I mean it in a kind way) folks at OpenBSD. I, for one, am ready to place for more trust in openssh than in any VPN daemon. The most commonly used ones are propitiatory. What if there is a 0-day vuln (not exploit) for these VPN daemons? That far more likely. "Securing" ssh with a VPN is just one step bey…

> "Securing" ssh with a VPN is just one step beyond of security by obscurity.

You're not securing ssh with a vpn. You're adding another layer. ssh is still secured by all of ssh's existing protection.

ssh behind a vpn requires that someone both compromise the vpn _and_ compromise the ssh service to gain that access that, without a vpn, would require them to only compromise the ssh service.

Re: How I spend my first 5 minutes on a server

#243

Earlier quoted context omitted.

Is there a free and recommended configuration management system that does all this?

On linode, which he is using, there is one built in - they allow shell scripts to run on first boot which could replay his commands as they are without many changes: http://www.linode.com/stackscripts/

Yes, stackscripts are a great way to take advantage of automation. :-)

Re: How I spend my first 5 minutes on a server

#245

Earlier quoted context omitted.

I love etckeeper, but the use of a configuration management system (puppet/chef/salt...) tends to reduce its usefulness.

On the contrary - it is useful exactly to figure out when and what manual changes were made outside of the automated system.

I'm not sure I get your "on the contrary". Any configuration change on a managed configuration file is transient and bound to overwritten next time state is restored. This makes etckeeper absolutely less useful compared to a system where there is no way to restore state and an unfortunate "rm /etc/passwd" has little remedy. It does not make it "useless", but it's definitely less needed.

Re: How I spend my first 5 minutes on a server

#246

The premise of this thing is not good advice. 1) Your first couple minutes on a server should be used to install a configuration management client, if your bootstrap policies somehow don't already install one. 2) Everything else listed in this document should be configured by a configuration management system. 3) "User account sync tools" should have no place in a modern infrastructure, you should use your configurat…

You are right, this is a better path But sometimes, and especially for servers that will be delivered to the customer afterwards, it's not practical to use a configuration management tool. Also, millions of servers were deployed before Chef/Puppet appeared. You can't tell they did wrong. Also, Chef/Puppet type solutions may be overkill for some tasks, fabric takes care of the easier cases for example.

Also, millions of servers were deployed before Chef/Puppet appeared. You can't tell they did wrong.

This line of thinking represents a logical fallacy - no one claimed that anything other than Chef or Puppet is "doing it wrong".

Re: How I spend my first 5 minutes on a server

#247

I'd propose using OSSEC over logwatch & fail2ban. Ossec seems to be a bit of an obscure tool, but a thoroughly functional one at that. Logwatch gives a bit too much info at once to interpret properly, while OSSEC will only alert you when something is actually up. Ossec provides (among some other things): * Log file monitoring, with severity levels, occurence counting, time-based rules and auto-response. This means (f…

I have heard good words about OSSEC but never tried it because of it's perception being: - heavyweight; - not actively developed. Are my perceptions right? If no, how would you recommend to start using it? Any good tutorials or other pointers?

Last version dates from 2012-11-19, not the fastest of releases - but seems ok. Trend Micro is involved (and offers commercial support).

It doesn't feel heavyweight to me. It does start a bunch of daemons for all of its processing and it has the client->server bit built right in. That may make it feel heavyweight, I guess. But, you don't have to use the client->server stuff if you don't want to. It'll still do all of its magic for you.

Ossec will do a lot out of the box. So, I suggest installing it with the default ruleset and the active-response stuff turned off (the installer will ask you). Then dive into the rules and ossec.conf (knowledge of regex is required).

Documentation @ http://www.ossec.net/doc/index.html

Re: How I spend my first 5 minutes on a server

#248
post #187

Earlier quoted context omitted.

The problem is that most of the recommendations are bad. Having an up-to-date system and only accepting security updates is a good policy. Fail2ban is a good tool (but it's a starting point; you should be doing other things to detect suspicious behavior). The rest is just bad advice. Having everyone log in using a single user account is a terrible idea. You can't audit who did what, ever. You have to remember to remo…

You are assuming that they have several developers. I bet it's one or two If you're dealing with more, let's say, 5, your suggestions became relevant Also you are assuming this servers are staying with the company, which may not be the case "User account management is a pain, so that's why we have things like LDAP" Which is a bag of hurt in itself.

If you only have one or two developers, then you have all the more reason to automate the boring and mundane tasks, since the time savings are even greater as a percentage of total time available!

Re: How I spend my first 5 minutes on a server

#249

Earlier quoted context omitted.

I love etckeeper, but the use of a configuration management system (puppet/chef/salt...) tends to reduce its usefulness.

On the contrary - it is useful exactly to figure out when and what manual changes were made outside of the automated system.

Isn't the point of Chef/Puppet that you never do that, and if you do, they get reverted automatically?
Post reply on HN