I also always change the SSH port to 9922. I haven't seen any failed login attempts so far.
Securing a Linux Server
31–40 of 143 posts
Re: Securing a Linux Server
#32Can I haz an Ansible playbook with good things?
If you allow some self-promotion: you can take a look at the ansible playbook repo I've been putting up (including some documentation and background in the doc directory): https://github.com/pjan/the-ansibles
In all honesty; the steps in the TO's article are only providing basic security. Pointing the ansible playbooks to your server will further enhance it.
You should also consider changing the SSH port, but that's up to you (in which case you also need to change the firewall settings!)
Re: Securing a Linux Server
#33This 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.
Follow by review the services started "even before starting nothing".
Review what is accessible in the system to "anybody".
Review what is accessible in the system to each "user". Many times a "user" is going to be listening to the hostile network in a port.
Review what the system is going to do across the time, what is scheduled, which resources are assigned to which users (and their processes), what is going to be registered.
4) Does not limit or scrub any traffic
It's not that we forget about IPv6
It's that such iptables, on any 1 core VPS, is vulnerable to DoS from a single IP (you don't need any distributed attack to put down that). A syn attack to the port 22 could be enough.
In resume:
When giving general security advisories, lets try that people build a secure system if they follow our tips. Not let open things like ping broadcast from our host, or IPv6
Re: Securing a Linux Server
#34Amazed that "Install grsecurity" isn't one of the key things listed here. Sure, you have to compile your own kernel, but the enhanced memory protections and many other hardening features make it an excellent addition to your security arsenal.
Re: Securing a Linux Server
#35I'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 syst…
> It's to easy to exploit as denial-of-service attack and can be used to lock out legitimate users. Could you explain what's the "easy" way to DoS using fail2ban(or equivalent system)?
There's still a lot of ISPs that don't follow BCP-38 so source address IP spoofing is easy enough
Re: Securing a Linux Server
#36Amazed that "Install grsecurity" isn't one of the key things listed here. Sure, you have to compile your own kernel, but the enhanced memory protections and many other hardening features make it an excellent addition to your security arsenal. http://grsecurity.net
The article absolutely forgets about parametrize the kernel space.
Re: Securing a Linux Server
#37I'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…
Not all automated scripts, or all the available scripts used in automated ways, can flush your rules before send things outside.
You're not going to be 24/7 at the keyboard of the system, there are going to be 0days, or unreleased vulnerabilities, etc.
Re: Securing a Linux Server
#38This is a good start, netstat -an to see what ports are open, to shut down things that open ports. Turn of xinetd if it is on, etc. There was a much more complete best practices document that came through here earlier.
And then realize you left all ipv6 traffic open (?)
Re: Securing a Linux Server
#39Amazed that "Install grsecurity" isn't one of the key things listed here. Sure, you have to compile your own kernel, but the enhanced memory protections and many other hardening features make it an excellent addition to your security arsenal. http://grsecurity.net
install pax would be more accurate.
anyhow the article tells nothing special.
fail2ban doesnt do anything to secure you, also
Re: Securing a Linux Server
#40What's wrong with passwords ? The info is in your head and in a physical booklet secured at home for backup. Its only weakness is is keylogger.
A secret key protected by password doesn't provide you more security. You can only connect from the computers having a copy of the key. If that computer is inaccessible or dead, or the private key is erased you can't log in. It also is exposed to keylogger.
So I stay with password for now. It should be a secure password of course. Maybe use private keys and a password for backup recovery only.