Linux Security Hardening and Other Tweaks
vez.mrsk.me
vez.mrsk.me
Similarly, many of the L1TF-style mitigations make very little sense on a single-user computer. They make sense on shared tenancy servers / VM hosts where you want to prevent lateral movement, but there is close to no lateral movement to be had on your random Linux laptop. The mitigations that do help are mostly those at the web browser level, since this is for almost all users the only place where they run sandboxed untrusted code.
As a networking person, some of those bits also stand out as meaningless to me. rp_filter doesn't do anything on hosts, it really only affects routers. And DNSCrypt doesn't get you anywhere since your configured recursive resolver likely doesn't support it. And the ICMP settings mostly just affect your local network behavior...
There should be a password for the boot configuration (BIOS), Encrypted boot partition, and user login. Adding a second password check in grub would add additional security, but that seems excessive since you can't access grub without unlocking the boot partition. As for unlocking root, you can create a keyfile that is accessible on the boot partition and have it verified during boot. Be sure to set the perms on it and it's always good to keep a hash of the keyfile to detect changes.
Also, firejail is notoriously weak with it's default settings. Even configured, bwrap is more secure but you have to specify specific variables that many may not understand. But there are plenty of tuts on it and a script to open a bwrap shell in it's repo.
It should be authenticated. You can sorta get there with encrypting boot and keep a boot loader off the main computer, if you don't have secure boot. But the better option is to always setup secure boot and sign all entires.
Using a unified kernel image you would end up protecting the initramfs, microcode and the kernel with secure boot.
https://wiki.archlinux.org/index.php/Systemd-boot#Preparing_...
Not that getting root is too interesting for malware running on your personal machines that runs all the interesting code as uid1000. https://xkcd.com/1200/
this sentence also doesnt mesh with my understanding. i thought debian stable was highly secure, is it not? "Debian especially, users are often left with kernels full of known holes for months at a time".
Industry wants Long Term Support, but rolling release (or for increased stability 'short' (< 1 year) release cycles) are the way to go when it comes to security.
That's why Fedora minimal exists, and I wouldn't be surprised to know that there's something similar for Mint as well.
sudo ufw deny out to any port 80
sudo ufw deny out to any port 53
This ensures no plaintext http can be sniffed, nor plaintext DNS queries. Then you can just configure DoH in your browser to get DNS functionality back, (in encrypted form usually over port 443).
Doing that depends on your threat model though.
BTW: You can nuke NTP requests by doing:
sudo ufw deny out to any port 123But he does trust cloudflare for his DNS requests.
Cloudflare run NTP, so just use their server.
The only threat I can see is if someone intercepts his NTP traffic, but they could intercept the DNS traffic too and see his SYNs (and indeed pass them on with you not even noticing)
His concern seems to be more about the IP leaking rather than the NTP result being incorrect, however in the latter case then yes, NTP isn't signed, so it's possible for someone to skew your clock by a few seconds if they were to intercept your traffic to all your NTP servers.
It does not. It blocks all outgoing connections to TCP/UDP 53 and 80. There's no such thing as port 80 UDP HTTP traffic (there is QUIC, which uses TLS by default; your rules would block it by default), and HTTP traffic can be received over a different port than 80 TCP. Your example of NTP is also wrong, as it uses 123 UDP; not TCP. Furthermore, if someone were to skew the clock too much, your average NTP client does not accept such.
This stops only very archaic malware. I guess a poor man's NIDS.