This is cargo-cult hardening without specifying a threat model. Some of the things in there make no sense in most contexts -- for example, logging in as root on a tty to perform administrative actions because you might have an X11 keylogger protects you from pretty much no real attack vector. Your X11 keylogger still runs as your user, with full access to your data, full access to your browser accounts and passwords, etc.
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...
I'm surprised that lynis [i] isn't mentioned when it's a discussion about linux security hardening. A dead simple tool that covers a wide range of security considerations.
Maybe I missed something, but the boot partition can and should be encrypted as well (depending on the threat level I suppose).
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.
>Maybe I missed something, but the boot partition can and should be encrypted as well (depending on the threat level I suppose).
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.
If you've got persistent malware on the machine (-> keylogger), 2FA with a hardware key will barely help. The malware can just notice your "sudo" call, pass through your password + 2FA token to its own "sudo" invocation, and make your "sudo" invocation say "invalid password" -- which you'll likely interpret as a typo.
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/
Don't have to type anything. If you don't type anything, there's nothing to keylog right? It'll send a notification to the duo app with the command name, and will allow you to verify whatever you're running. If the attacker attempts to sudo, it'll show the command they are trying to run and you can choose not to allow it.
2FA that actually carries a payload to verify like Duo will be much harder to exploit, indeed. As to whether making your life harder for routine system administration tasks will actually make stealing your personal data harder, I still have my doubts.
who is the target audience here? what is the threat model?
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".
Debian (especially the main branch, 'stable') is as the name implies highly stable, secure though? Definitely not! Outdated kernel, outdated libraries, very long release cycle: you can't backport every security fix for 3 years while the rest of the ecosystem is rapidly progressing.
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.
> The base install is relatively minimal compared to a "prebuilt" distro like Fedora or Mint. This lets me focus on adding just what I want, rather than constantly trying to strip out things I don't need.
That's why Fedora minimal exists, and I wouldn't be surprised to know that there's something similar for Mint as well.
I always remove NTP functionality because even though NTP is innocuous, the servers still have a perfect opportunity to see when a box is online and keep logs of that. I just go to https://time.is/ and configure my clock manually.
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).
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.
This reply doesn’t match your comment on time servers tracking you by IP address. Even with encrypted DNS, your DNS servers can track you the same way your time servers can. I don’t understand your points clearly.
Sorry I diverged a bit. You're right: DoH servers can still see when a box is online and possible keep logs/timestamps of requests. I would trust a DoH server more than a standard DNS server simply because it would be catastrophic for a DoH server's reputation if they were found to be handing over logs to third parties. Cloudflare keeps logs for 24 hours then deletes: but there's still that time window of a day to worry about :/
Sounds like he doesn't trust his NTP provider and doesn't want his IP address being sent to the NTP provider, because he wasnt to pretend his IP address is not online.
But 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.
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.