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

111–120 of 143 posts

Re: Securing a Linux Server

#111

Post by kbaker »

tgeek wrote: post #83

There seems to be a lot of wasted breath in these comments about IPv6. Given that its unlikely that your provider even supports IPv6 on their networks, and that globally the traffic via IPv6 is nearly non-existent, I wouldn't spend too too much time caring about it. Less than 2% of traffic to Google is IPv6: http://www.google.com/ipv6/statistics.html Even the attacks CloudFlare sees are mostly DDOS: http://blog.cloud…

Their breath is not wasted! This is an article about securing a Linux server, and explicitly talks about adding a firewall with iptables. If it will only defend against IPv4-enabled attackers, then the server operator is at risk of leaving the system open to compromise.

Learning about ip6tables or turning off ipv6 entirely if not needed would be a better discussion topic, but people here are right to care about a major oversight in the security notes presented.

Re: Securing a Linux Server

#114

Post by lutusp »

sepbot wrote: post #113

The .ssh folder and the files inside it should be given the lowest permissions possible.

Just to avoid confusion, I would have said "most restrictive", not "lowest". At first glance, "lowest" might be taken to mean most permissive.

Re: Securing a Linux Server

#115

Post by nl »

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?

That's a good compromise.

I just thought of enabling 2 factor authentication instead of plain password auth, which I think is probably reasonable too

Re: Securing a Linux Server

#116

Post by makomk »

It's usually also worth checking whether you need to generate new SSH host keys - a lot of VPS providers use the same host keys on all their deployed instances, which isn't secure, and the longer you leave it the more of a pain it'll be to change. If "ls -lh /etc/ssh/" shows that the host keys predate when your system was provisioned, change them:

    rm /etc/ssh/ssh_host_*
    dpkg-reconfigure openssh-server
Also, on some VPS solutions I've come across you can't use passwd to change the root password permanently; management software outside of the VM changes it back on the next restart.

Re: Securing a Linux Server

#118

Post by e12e »

agwa wrote: post #105
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…

Your concerns are not an issue with a distro like Debian where the only upgrades are for backported security fixes (or, when an announced point release comes around, critical bug fixes). I worked for several years at a shop with dozens of Debian servers, and nightly unattended upgrades very rarely caused issues, and never caused anything truly serious.

Debian is very stable. I recommend running "safe-upgrade" nightly -- and keeping an eye out for when you need a "dist-upgrade" (typically new kernel images -- and other stuff that should be tested (eg: test that the server actually boots -- not to mention do a reboot to use the new kernel).

I'm not sure how good the Ubuntu LTS relases are, but Debian has always been great at both keeping a stable system up, and keeping the upgrade to new version as painless as possible.

Re: Securing a Linux Server

#119

Post by readme »

jlkinsel wrote: post #29
sturadnidge wrote: post #16

I've never understood the compulsion to restrict outbound traffic on an internet facing server that you do not intend to be used by other (untrusted) people. If someone is good enough to own you with everything else locked down, they can change any firewall rules completely if they need to, or just tunnel out over an allowed port. Creating a non-root user then giving them carte blanche sudo rights is similarly odd to…

I've seen more compromised boxes than one can shake a stick at. There's all sorts of reasons that blocking egress is a great idea. Compromises are usually automated bots, and no, they're not smart enough to bring down iptables. Even if it's a human that's pwned you, it's frequently a stupid human, or a lazy human. It's just good practice to practice security in depth.

Or a non-privileged account is accessed and the kiddie just wanted to run an eggdrop bot. Plot foiled.

Re: Securing a Linux Server

#120

Post by e12e »

marcosdumay wrote: post #92
chmike wrote: post #66

Earlier quoted context omitted.

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.

It might have been true if it wasn't possible to get a copy of the plaintext key (eg: from ssh-agent).

Actual two-factor authentication would be requiring proof of access to the secret key and a diffrent login password.

Post reply on HN