I've found CSF is a great tool for securing a server if you aren't an IPTables expert: http://configserver.com/cp/csf.html
Securing a Linux Server
101–110 of 143 posts
Re: Securing a Linux Server
#102This 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…
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…
Both limit and spindritf's suggestion will mitigate the attack, but they won't notify you about it. In most circumstances, I'd prefer to skip on the thousands of notifications per day, however I sometimes like to know about every detail on a server, and Fail2ban gives me that level of control, without the need to tail a log file.
Re: Securing a Linux Server
#103I 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..
On Windows I use KeePass 2 [1] with the KeeAgent [2] plugin. The keys will be protected by your master password, and it will act like pageant so most tools will automatically recognize and use the keys. You can configure it to automatically let all applications use the keys, or first prompt you before providing the key to the user. You can keep the database file on an USB stick or even something like dropbox or owncl…
I do the same, and have found it works beautifully. You need my master password, SSH Key, and my SSH Key's password before you can log into my server. And if you somehow manage to get all of that, you need my account password in order to modify any non-user files.
Re: Securing a Linux Server
#104Re: Securing a Linux Server
#105This 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…
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.
Re: Securing a Linux Server
#106sudo, 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...
This isn't intended as a be-all-end-all guide to security, like the NSA aims for. Instead, view it as a quickstart guide for those first five minutes on a new server, or as a starting point for beginners that have no idea where to even look.
Re: Securing a Linux Server
#107This 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.
Re: Securing a Linux Server
#108Hmm, no mention of SELinux? It's a pain to get into though. Many just turn it off to make its errors go away, while they should actually configure their machine. But it is very convoluted and hard to get really into. IRC helped a lot here. Another suggestion I miss is just setting the SSH port to something different than 22, while many will correctly notice that this comes close to security through obscurity, it does…
I've been tweaking a post on building a solid LEMP stack, that I hope to publish soon that covers your last three points. While security through obscurity isn't a solution, it does help thwart a large portion of the attacks, although it causes more headache than benefits in some cases (heavily restricted work networks for instance). When it comes to webservers, you don't encounter issues like that, and the less information you provide, the better.
Re: Securing a Linux Server
#109This article is okay, nothing against the author but the topic of securing a host depends on many factors and it's so extensive at so many levels that this post doesn't even scratch the surface. Why is it in frontpage?
Because most developers have ~0 such knowledge...
Re: Securing a Linux Server
#110Hmm, no mention of SELinux? It's a pain to get into though. Many just turn it off to make its errors go away, while they should actually configure their machine. But it is very convoluted and hard to get really into. IRC helped a lot here. Another suggestion I miss is just setting the SSH port to something different than 22, while many will correctly notice that this comes close to security through obscurity, it does…
No mention for SELinux because it's more than painful to get into it. No, I will actually say it: Documentation is shit about SELinux.
I actually wanted to do some kind of "frontend"* to SELinux to facilitate it's usage, but I got every time frustrated when going back to it that it never got above the idea point.
* something more like gitflow is to git; than SELinux Troubleshooting is to selinux