Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Securing a Linux Server

spenserj.com

Post reply on HN
Print view View original

91–100 of 143 posts

Re: Securing a Linux Server

#91

Post by marcosdumay »

larrys wrote: post #86
nl wrote: post #60

Earlier quoted context omitted.

I agree that key-for-each-device is probably best practice. It just doesn't work for me though. I frequently need to log onto servers from new client computers, and the workflow of connect from trusted device, generate new key for new device then use new device just isn't practical. I've spent a lot of time thinking about this. I think the biggest threat to security on my servers is brute forcing of ssh passwords. Th…

"I frequently need to log onto servers from new client computers, and the workflow of connect from trusted device, generate new key for new device then use new device just isn't practical." Agree. But wouldn't it make sense then to generate unique keys for all of your devices (still) and then have a key which is your "travel" key and change that periodically?

I'll second that.

I keep my travel key in a pen drive, and in practice I change it shortly after every usage. But that's because I don't use it a lot, you'll probably want to change it every few weeks.

Also, if you don't trust the machines you are using to connect, no time frame is small enough. If you really need to connect from them, use a VM (best) or a guest account (not as good) with access to just the stuff you need.

Re: Securing a Linux Server

#92

Post by marcosdumay »

chmike wrote: post #66
spindritf wrote: post #47

Earlier quoted context omitted.

> A secret key protected by password doesn't provide you more security. It does. You can encrypt the key and then you have two-factor authentication. You need to have the key and know the password to use it.

I don't want to be picky but this isn't two factor authentication in its usual sense. Two factor authentication uses two independent means/media to authenticate. Protecting the private key with a password is required to protect it of beeing exposed when stolen. But if it's stolen then brute force password guessing is for free. Brute force attack against a login password can be detected and impaired, not with stolen p…

You must have the key, and know the password. Two factors.

Re: Securing a Linux Server

#95

Post by fsniper »

spindritf wrote: post #50

This falls a bit short. You shouldn't just update, you should update regularly or better yet set up unattended upgrades[1]. Especially for your hobby projects or personal server because odds are that you won't always have the time to act on every security advisory. (Subscribe here[2] to at least hear about them.) Also, if something breaks once in a blue moon, it's not that big a deal. Fail2ban is fairly heavy and onl…

As a seasoned system administrator, I strongly advise you against unattended or automatic upgrades. In a Linux or FLOSS eco system components are very strongly coupled but loosely developed. Say glibc is base of nearly every server application but it is and server apps are not regres tested for each other. Which will or may lead to incompatibilities, down times or performance issues even on edge cases data loss. So please don't.

Re: Securing a Linux Server

#96

Post by oelmekki »

gambler wrote: post #78
oelmekki wrote: post #45

Earlier quoted context omitted.

Password authentication is prone to bruteforce. With public key auth, even if someone has your passphrase, he also needs the private key to break into your server. Indeed, there's always the risk to lose your private key. That's why it's useful to have several : I have one on my desktop, one on my laptop and one on my mobile. If any get compromised, I only have to delete one public key in authorized keys and generate…

I have one on my desktop, one on my laptop and one on my mobile. If any get compromised, I only have to delete one public key in authorized keys and generate a new one. Personally, I still don't like SSH keys. Yes, they are "more secure" in the sense of preventing others from breaking into your servers. But they are less reliable in a sense that they increase your probability of being completely locked out when shit…

Well, maybe you live in some place especially prone to natural catastrophes :) I live in France, and I certainly have lesser chances to loose all devices at once than to have a single one compromised.

Re: Securing a Linux Server

#97

Post by dotBen »

fsniper wrote: post #95
spindritf wrote: post #50

This falls a bit short. You shouldn't just update, you should update regularly or better yet set up unattended upgrades[1]. Especially for your hobby projects or personal server because odds are that you won't always have the time to act on every security advisory. (Subscribe here[2] to at least hear about them.) Also, if something breaks once in a blue moon, it's not that big a deal. Fail2ban is fairly heavy and onl…

As a seasoned system administrator, I strongly advise you against unattended or automatic upgrades. In a Linux or FLOSS eco system components are very strongly coupled but loosely developed. Say glibc is base of nearly every server application but it is and server apps are not regres tested for each other. Which will or may lead to incompatibilities, down times or performance issues even on edge cases data loss. So p…

While you are absolutely correct, no one is regression testing the updates potentially coming into their project box/gameserver/etc, even if they perform the apt-get upgrade manually.

Might as well set it automatically and stay protected

Re: Securing a Linux Server

#98

Post by modoc »

Hello71 wrote: post #84
rmk2 wrote: post #73

Earlier quoted context omitted.

Another really nifty way to achieve pretty much the same is to use iptables' built-in limit module like so: -A INPUT -p tcp -m tcp --dport 22 -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m limit --limit 3/min --limit-burst 4 -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j DROP Limit-bursts allows that many packages through before any limit counter starts, if an…

Awesome, now I can DoS your SSH with only 3 requests per minute.

You can DOS your own IP from being allowed in..... But not mine.

Re: Securing a Linux Server

#99

Post by dotBen »

jlkinsel wrote: post #30

sudo, ssh certs, egress firewalling. Congrats - you've covered about 4 pages from the NSA's 200 page hardening benchmark. Off to a good start! http://www.nsa.gov/ia/mitigation_guidance/security_configura...

I doubt there's suddenly much appetite for the NSA-authored security guides anymore.

Re: Securing a Linux Server

#100

Post by SpenserJ »

dotBen wrote: post #97
fsniper wrote: post #95

Earlier quoted context omitted.

As a seasoned system administrator, I strongly advise you against unattended or automatic upgrades. In a Linux or FLOSS eco system components are very strongly coupled but loosely developed. Say glibc is base of nearly every server application but it is and server apps are not regres tested for each other. Which will or may lead to incompatibilities, down times or performance issues even on edge cases data loss. So p…

While you are absolutely correct, no one is regression testing the updates potentially coming into their project box/gameserver/etc, even if they perform the apt-get upgrade manually. Might as well set it automatically and stay protected

I prefer to be actively administrating my server, so that I know if something does go awry. If I'm asleep, it may be a few hours before I realize that an update broke something. On top of that, I clone my servers and test upgrades in a development environment as much as possible, before allowing an update to go live. As long as you're on top of the updates, a few days between automatic and manual shouldn't have much effect.
Post reply on HN