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

231–240 of 298 posts

Re: My First 10 Minutes on a Server

#231

Post by KB1JWQ »

walrus01 wrote: post #229

For those saying "why fail2ban?", fail2ban can be used for a great deal more than just watching the sshd log. You can activate fail2ban rules for apache and nginx which help significantly with small DDoS, turning spurious traffic/login attempts into iptables DROP rules. And a lot of other daemons.

At least one log parsing tool I've seen in years past was vulnerable to log injection attacks. Hilarious proof of concept to own a box by way of PTR record.

I haven't checked to see whether fail2ban suffers from this model or not.

Re: My First 10 Minutes on a Server

#233

Post by ropable »

devishard wrote: post #227
larrywright wrote: post #101

Earlier quoted context omitted.

Hardening (along with any other server setup/configuration) should be implemented using some idempotent configuration management software (Chef, Puppet, Ansible, etc). It's 2016, there's no need to configure servers manually.

It depends. I'm a security guy, so it would be embarrassing and possibly bad for my career if any of my servers got hacked, but I actually don't set up servers that often--it's not part of my job. These Web 2.0 configuration management solutions change pretty fast and don't care about reverse compatibility. So between my infrequent setups my configuration scripts pretty much always break. Contrast this with bash, whi…

Would be very interested to review server hardening Bash scripts. Have you published anything on Github or elsewhere?

Re: My First 10 Minutes on a Server

#234

Post by oofabz »

MichaelGG wrote: post #215
oofabz wrote: post #197

Earlier quoted context omitted.

If SSH is on a non-standard port, it is still possible to brute-force access to the server. You will see fewer automated attempts but you are still vulnerable to a motivated attacker who port scans you and finds the SSH port. Such an attacker is less common than automated scans but is more of a threat. With Sshguard, you are no longer vulnerable to this type of attack at all, no matter which port you run SSH on.

But brute forcing any reasonable password or key is so far-fetched as to not be something to even consider.

If you can make hundreds of login attempts per second, and you can keep at it for days/weeks/years, you can get through some pretty big password dictionaries with lots of variants (e.g. password/p4ssword/passw0rd/p4ssw0rd/etc.).

Re: My First 10 Minutes on a Server

#235

Post by tikwidd »

ec109685 wrote: post #15

It would be useful to discuss what prevents the server from being rooted without a trace during the 10 minutes it takes to execute these steps.

I was going to ask the same thing. How do you stop someone from owning a new Linode between the time you start the server and the time you disable password authentication?

Re: My First 10 Minutes on a Server

#236

Post by taneq »

pfg wrote: post #190
mastorrent wrote: post #165

Earlier quoted context omitted.

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.

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…

Not an expert here, but this seems to me to be stripping away one layer of security. Kind of like saying that you can leave a key to your house lying around as long as the pantry door is locked - if your database server gets owned, they now have some kind of login to your backup server as opposed to no kind of login.

Maybe the extra layer doesn't add much security, but if it's a simple config change and it does add something, wouldn't it be worth doing?

Re: My First 10 Minutes on a Server

#237

Post by mwpmaybe »

mordechai9000 wrote: post #141
mwpmaybe wrote: post #113

Earlier quoted context omitted.

I too am curious to know what the consensus is. People seem to fall into one of two camps: 1. it's unnecessary if you disable password login or 2. it's an easy thing to add as yet another safety net on top of sane service configuration and firewall rules. I've taken some flak here for being in the #2 camp so I'm loathe to expose myself once again, but my thinking is that even with password authentication disabled, ss…

If all you're worried about is keeping the low-level noise out of your logs and discouraging waste of resources on brute-force attacks (which won't work because of course password auth is disabled), I think it's sufficient to use the built-in iptables rate-limit feature on SYN packets. UFW has a feature that will implement this with a limit of 6 SYN packets in 30 seconds from individual IPs. ufw limit ssh/tcp This ma…

This is a much better answer than, "If you're using fail2ban for that reason, you don't know what you're doing," as someone said to me recently, so thank you. :-) I'll explore replacing fail2ban with this mechanism.

Re: My First 10 Minutes on a Server

#238

Post by taneq »

jldugger wrote: post #19

> 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 don't like this one is less about the actual security implications, and more because of what it says about the fragility of the overall setup.

Post reply on HN