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

131–140 of 143 posts

Re: Securing a Linux Server

#131

Post by froyke »

Please do yourself a favor and instead of fail2ban install dome9.com. You'll have your ssh closed as well as all other non public ports, will not rely on funky failed login logic. As a bonus you will have clean logs. Also saw here a recommendation to change ssh port. Man, even kids today use nmap. It takes nothing to find your 'hidden' ssh.

Consider pimping this setup with external WAF such as incapsula.com or CloudFlare.com. Combined with dome9- there will be no entity connecting directly to your server (or even knowing its ip)

Re: Securing a Linux Server

#133

Post by froyke »

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.

Install dome9 to remotely configure the iptables. Never be locked out of your server again

Re: Securing a Linux Server

#134

Post by F30 »

nl wrote: post #115
larrys wrote: post #86

Earlier quoted context omitted.

"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

Was about to suggest 2-factor auth as well. At least for the "first" machine, where the SSH key for the others is.

Re: Securing a Linux Server

#135

Post by txutxu »

SpenserJ wrote: post #107
txutxu wrote: post #33

This article is letting IPv6 without a firewall. A few feedback: 1) Start by the "lower layer" If it's a physical server, start by reviewing all BIOS options, if it's virtual one you control, start by reviewing the host environment for the guest. 2) Follow from the bottom to the top Follow by review and secure the boot process. (Grub password, kernel modules loaded, kernel module options, kernel sysctl options. Follo…

I haven't enabled IPv6 on any of my servers yet, as I can say with 99.9% certainty that my visitors do not know what it is, let alone have it enabled. Additionally, this is intended as a quickstart or beginners guide, and obviously leaves quite a bit out. That being said, it is definitely something you want to consider, and I've added a followup to the post mentioning that.

The problem with IPv6 was not that it could be enabled... it's that it is enabled by default. In all major linux distributions.

That being said, I've read your update, and that is the point that people seeking for "recipes" should get. If they are going to touch ssh or iptables, they need to be ready to explore the documented options (which are many), to validate that the changes are working, to dive into networking, etc.

Re: Securing a Linux Server

#136

Post by bostik »

zokier wrote: post #56
elktea wrote: post #35

Earlier quoted context omitted.

There's still a lot of ISPs that don't follow BCP-38 so source address IP spoofing is easy enough

SSH is TCP based, you need two-way handshake to construct the connection. Source address spoofing gets you only half-way there.

Unless your server's TCP stack has SYN-cookies enabled (and I think most do): http://www.jakoblell.com/blog/2013/08/13/quick-blind-tcp-con...

Law of unintended consequences strikes again.

Re: Securing a Linux Server

#137

Post by marshray »

sippndipp wrote: post #75
blameless wrote: post #31

I also always change the SSH port to 9922. I haven't seen any failed login attempts so far.

I would use a privileged port for ssh (different than 22). In case a hacker owns the process he would need sudo to open another connection if the port is <1024.

I wonder if it's ever happened that a hacker was able to pwn sshd only to be stopped by the lack of a local privilege escalation to root.

Re: Securing a Linux Server

#138

Post by yrro »

INTPenis wrote: post #132
mapleoin wrote: post #130

Is creating a new group really necessary? Doesn't ubuntu have the 'sudo' group for exactly that purpose? And others have 'wheel'.

Yes it does, and Debian has staff.

The group in Debian is also sudo. The staff group is used to manage /usr/local (and is going away in future Debian releases, since it's root-equivalent anyway).

Re: Securing a Linux Server

#139

Post by e12e »

agwa wrote: post #122
e12e wrote: post #118

Earlier quoted context omitted.

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 keepi…

In the typical case, you only need dist-upgrade for upgrading to a new Debian release (which is every 2 years or so and is big enough news you'll probably hear about it). When there's a security update for the kernel, a regular upgrade/safe-upgrade[1] is sufficient to get it. Of course you must schedule a reboot yourself. [1] "upgrade" if using apt-get, "safe-upgrade" if using aptitude

Ah -- I usually use "apt-get safe-upgrade" for scheduled upgrades, and aptitude for all manual work.

So I had the effect right, but the commands mixed up :-)

Re: Securing a Linux Server

#140

Post by lloeki »

jonahx wrote: post #6
lloeki wrote: post #3

Important caveat: fail2ban does not work for IPv6 connections yet (there are patches floating around though)

ty, i didn't know that was the case. are there other alternatives?

There is a quite straightforward patch[0], and since fail2ban is python, you can apply it on the installed package. Not the best for maintenance, so use your best judgement (and a few tricks to keep yourself safe and up to date), but it's certainly better than being exposed.

[0]: http://www.fail2ban.org/wiki/index.php/Fail2ban:Community_Po...

Post reply on HN