This document is aimed at teams of systems administrators who use Linux workstations to access and manage your project’s IT infrastructure.
If your systems administrators are remote workers, you may use this set of guidelines to help ensure that their workstations pass core security requirements in order to reduce the risk that they become attack vectors against the rest of your IT infrastructure.
Even if your systems administrators are not remote workers, chances are that they perform a lot of their work either from a portable laptop in a work environment, or set up their home systems to access the work infrastructure for after-hours/emergency support. In either case, you can adapt this set of recommendations to suit your environment.
And so I remembered something I’ve considered many times before regarding root and security in Linux (but also other operating systems): I actually don’t care about root access.
Sure, it would be annoying to reinstall my system if a program were to mess with the system files. But the only thing I really care about are my personal files. And ANY program I run could read all my files (privacy, and other secrets) and encrypt or simply destroy them all. That is what I care about – and there is no security for this at all – but instead I’m being pestered about root access, which really doesn’t matter to me. I might also care about access to my camera, or what programs are talking to the internet, etc.
Some people are, rather falsely, under the impression that just because they use Linux they don’t need to worry about security. Sure, Linux doesn’t suffer from the same types of security issues and prevalent malware that Windows does, but that doesn’t mean that Linux users can neglect their systems and expect to be secure.
These five tools are absolutely essential for Linux desktop users. If you’re running a server, there are more. This guide doesn’t present them in any particular order because they all serve different and arguably equally important functions. Plus, they are all free and open-source software. So if you aren’t using any of these on your Linux desktop, start now.
The Linux operating system is known for security. From the bottom up, Linux was designed to be a platform to be trusted. There is, however, one weak link in the chain. This weakness didn’t just appear, nor is it considered a security bug on any given radar. What I’m talking about is the antiquated X11 Window server still found in use on most Linux distributions.
For those that don’t know, X was originally designed and released in 1985 and X11 in 1987. X.org replaced X11 and was originally released April 6, 2004. When X was originally conceived, the computing world was in a completely different state. Both X and X.org lack a few very important security features that are critical for modern era usage and hardware:
- All X applications have access to everything on your screen
- All X applications can register to receive every keystroke, regardless of which window said keystrokes are typed within
- Applications such as browsers can be remotely controlled such that keystrokes can be forged as if the user were typing them
- The xhost + option can completely disable any security on the display
There is no question that the web browser will be the piece of software with the largest and the most exposed attack surface on your Linux workstation. It is a tool written specifically to download and execute untrusted, frequently hostile code.
It attempts to shield you from this danger by employing multiple mechanisms such as sandboxes and code sanitization, but they have all been previously defeated on multiple occasions. System administrators should learn to approach browsing websites as the most insecure activity you’ll engage in on any given day.
There are several ways you can reduce the impact of a compromised browser, but the truly effective ways will require significant changes in the way you operate your workstation. more
[…] To me, the most prominent information to draw from this little experiment is that similar iptables and nftables setups are comparable in performance. Yes, nftables is usually a bit behind, but given that development focus at this point is still on functionality rather than performance, I’m sure this is subject to change in the near future.
Regarding scalability, ipset is a blessing to any iptables set up. Nftables follow the path with their native implementation of sets and take the concept to a higher level by extending the list of supported data types and allowing it to be used in further applications using (verdict) maps. more