
Linux Security Hardening and Other Tweaks - thefalconcalls
https://vez.mrsk.me/linux-hardening.html
======
delroth
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.

~~~
eqvinox
+1

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...

------
canada_dry
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.

[i] [https://github.com/CISOfy/lynis](https://github.com/CISOfy/lynis)

------
trop1x
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.

~~~
Foxboron
>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.

[https://wiki.archlinux.org/index.php/Systemd-
boot#Preparing_...](https://wiki.archlinux.org/index.php/Systemd-
boot#Preparing_a_unified_kernel_image)

------
kart23
If you're actually concerned about keyloggers and unsafe sudo, use 2 factor
auth. You can set it up with hardware keys or something like duo.

~~~
delroth
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/](https://xkcd.com/1200/)

~~~
kart23
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.

~~~
delroth
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.

------
modzu
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".

~~~
artistsvoid
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.

~~~
modzu
thanks. found this, many takes on the subject:
[https://www.infoworld.com/article/3118898/is-debian-the-
gold...](https://www.infoworld.com/article/3118898/is-debian-the-gold-
standard-for-linux-security.html)

------
RMPR
> 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.

------
ffeiek
Since v4.10 kernel, tcp timestamp offset is randomized so
net.ipv4.tcp_timestamps should not need to be from the default 1 to 0, in my
opinion.
[https://github.com/torvalds/linux/commit/95a22caee396cef0bb2...](https://github.com/torvalds/linux/commit/95a22caee396cef0bb2ca8fafdd82966a49367bb)

------
thatcat
Anyone else notice the use of Aphex Twin's logo as the tab icon?

------
kyuudou
Throw away your Linux media and install OpenBSD

------
diablo1
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/](https://time.is/) and configure
my clock manually.

~~~
iso1631
And DNS doesn't?

~~~
diablo1
Well since we're on the topic of hardening Linux, there are people who do this
with UFW[0]:

    
    
        sudo ufw deny out to any port 80
        sudo ufw deny out to any port 53
    

[0]
[https://help.ubuntu.com/community/UFW](https://help.ubuntu.com/community/UFW)

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.

~~~
AnonC
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.

~~~
diablo1
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 :/

BTW: You can nuke NTP requests by doing:

    
    
            sudo ufw deny out to any port 123

~~~
viraptor
What is it that your worried about there? And how is it different from likely
sending the same information over in SNI a moment later?

~~~
iso1631
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.

