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

11–20 of 143 posts

Re: Securing a Linux Server

#11

Post by contingencies »

This is very lightweight.

There are many more steps used in more serious situations... chiefly, these come to mind: Validating installation media. Validating/upgrading firmware. Installing a minimalist kernel. Securing BIOS and IPMI. Taking an inventory of part numbers and identities to detect tampering at later stages. Locking down network access on the switch to the appropriate MAC address. Determining administrative access methodology and distributing appropriate keys or credentials. Testing.

Probably most servers today are automatically set up, and live in large scale server farms. They probably boot via PXE, using custom auto-provisioning code. Other than physically taking delivery of the unit and inspecting it and logging its presence in inventory, such machines are literally just plugged in and boot up. Probably most of them are preconfigured to PXE boot by the vendor. A strong setup will also override BIOS settings automatically upon boot, ensuring further boots have 100% pretested/tuned configurations.

Re: Securing a Linux Server

#13

Post by Qantourisc »

nl wrote: post #12

I find https://wiki.ubuntu.com/UncomplicatedFirewall to be much friendlier to use when setting up firewalls. The big problem I have is securing my private keys. I use multiple devices, and haven't found a secure and convenient way to share the keys across devices securely. I'd love ideas..

The answer is don't: use an unique key for each device.

But this doesn't solve the problem you have to connect to each host to reject the lost key. (But you have the same problem with 1 key, so no worse.)

Re: Securing a Linux Server

#15

Post by [deleted] »

ruttiger wrote: post #10

I made the mistake of accidentally setting the firewall too strict on a remote server, killing my ability to SSH. A neat little trick I found was to setup a scheduled task to kill the firewall in 5 minutes, and then restart it. If it's too restrictive and locks you out, wait 5 minutes. If you did it right, then kill the scheduled task.

[deleted]

Re: Securing a Linux Server

#16

Post by sturadnidge »

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 me. I'd rather just use root and /etc/nologin (assuming no one else needed a login shell to run).

EDIT: Added paragraph about non-root users.

Re: Securing a Linux Server

#17

Post by saraid216 »

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…

While I agree with your reasoning (and personally wouldn't bother with such a restriction), there is a good reason and it's that while they're likely good enough to get root, they might not be or simply can't for some reason. And if they can't, then that extra measure could be worth its cost in time and effort.

Re: Securing a Linux Server

#18

Post by FooBarWidget »

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…

Or maybe there's a vulnerability in your web app that grants people shell access. In that case you'll still want to lock down their limited normal-user privileges.

Re: Securing a Linux Server

#19

Post by tobithiel »

ruttiger wrote: post #10

I made the mistake of accidentally setting the firewall too strict on a remote server, killing my ability to SSH. A neat little trick I found was to setup a scheduled task to kill the firewall in 5 minutes, and then restart it. If it's too restrictive and locks you out, wait 5 minutes. If you did it right, then kill the scheduled task.

You can just use iptables-apply. It achieves the same thing and is built-in. If you don't confirm the changes after they are applied, because you locked yourself out, they will be rolled back.

Re: Securing a Linux Server

#20

Post by np422 »

I've never been a fan of shunning/blocking ip-addresses based on number of wrong passwords. It's to easy to exploit as denial-of-service attack and can be used to lock out legitimate users.

Possibly use a non-standard ssh port, make sure you disable ssh v1 and apply a password policy, allow password logins only for white listed users. Now you should be reasonably safe against brute force attacks and still have a system that is accessible.

If/when you disable root logins through ssh, try to have another way to login as root - maybe a console/kvm switch, prefferably with remote access through a secure network.

Post reply on HN