Operating in Untrusted Environments

"Shields Up Mode", this setting alone will prevent services that may have installed their own firewall allow-rules from lowering the security of your system. This is a generally recommended setting for workstations, even in enterprise environments. Apply it to all network profiles, and you'll be covered as far as firewall rules go no matter what network you're on.

Localhost, Virtual Machine (WSL, Windows Sandbox, and Hyper-V) all still function just fine with this enabled.

Enforce DNS over HTTPS, and prevent falling back to insecure DNS settings.

This can include hardening measures to the OS, the browser, services, and more. These guides stand out.

• HotCakeX/Harden-Windows-Security, a Windows hardening guide that only uses methods and features native and officially supported by Microsoft. No third-party dependencies required.
• Disassembler0/Win10-Initial-Setup-Script, now archived, but a great reference for dealing with registry adjustments without needing Active Directory. My version of this is here.
• Microsoft Edge Policies, complete list of registry keys for Edge, my version automating this is here.
• All of my own resources and scripts are published under straysheep-dev/windows-configs.

Generally you want to account for:

• Prevent unauthorized behavior on the lock screen, e.g. changing network settings or shutting down the machine.
• Enforce all of the ASR policies, few should really prevent any normal use.
• Use Windows Sandbox for untrusted files or browsing; keep in mind it also needs a configuration file.
• Ensure auto-mount, auto-run, and auto-play behavior is disabled or limited as much as the GPOs allow.

If on Debian-based Linux, you're using ufw:

sudo ufw reset --force
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw default deny routed
sudo ufw enable --force
sudo ufw status verbose

You can also comment out the lines in /etc/ufw/before.rules and /etc/ufw/before6.rules to prevent UPnP and mDNS from being allowed in.

sudo sed -i -E '/^-A .*--dport (5353|1900) -j ACCEPT/ s/^/#/' /etc/ufw/before.rules
sudo sed -i -E '/^-A .*--dport (5353|1900) -j ACCEPT/ s/^/#/' /etc/ufw/before6.rules
sudo ufw reload
sudo grep -E "5353|1900" /etc/ufw/before.rules /etc/ufw/before6.rules

If on Fedora-based Linux, you're using firewalld:

sudo systemctl enable --now firewalld
sudo firewall-cmd --set-default-zone=drop
sudo firewall-cmd --reload
sudo firewall-cmd --get-default-zone
sudo firewall-cmd --zone=drop --list-all

This can feel more complicated than it is, just know that generally on desktop environments, NetworkManager and by extension, nmcli, govern networking, while servers tend to simply use systemd-networkd. If you're using cloud-init, keep in mind it can overwrite certain configuration options on boot unless you undo those settings. Check /etc/cloud/cloud.cfg.d/ if you're finding some settings don't persist after reboot.

Keep in mind netplan has limitations compared to NetworkManager with configuration writing. Some specific settings require passing through NetworkManager properties outside of the default schema.

NetworkManager

See my references for using NetworkManager.

If your network renderer is NetworkManager, you should use nmcli. I have templates published for both.

This allows you to:

• Ignore DHCP-provided DNS
• Ignore DHCP-provided routes, easily set your own after looking at the network
• Randomize your MAC
• Ignore LLMNR and mDNS

netplan

If your network renderer is systemd-networkd (like it would be on Ubuntu Server), you'll want to use netplan (that link is the full configuration reference).

I have my own configuration reference published here.

In Linux /etc/nsswitch.conf generally determines what handles name resolution, and uses /etc/resolv.conf in nearly every case. Otherwise, your DNS is either governed by a DNS daemon like systemd-resolved, bind, stubby, or unbound, or even your web browser. Check with the following:

# See what's configured.
cat /etc/nsswitch.conf

# See what's actually listening locally, if nsswitch.conf doesn't clarify this.
sudo ss -tulnp | grep -E ':53\b|:853\b'

I have templates for all of these here (except web browsers, those are configured separately). Each has their own configuration syntax, but the idea is always the same:

• Ignore any DNS from the local subnet
• Enforce your own, with DNS over TLS or HTTPS, and no plaintext fallback
• Optionally log all queries

Enforcing the use of a trusted NTP server prevents crypto from breaking. Things like MFA codes won't generate or be accepted on machines without properly synced time.

I have templates for systemd-timesyncd here.

USBGuard

Two things help here. First, USBGuard will prevent any unapproved USB device from functioning on your system. Be careful installing this; the way it works is at install time on Ubuntu and Kali, it will allow all currently connected devices on the ports they're connected to, but nothing else. You'll need to add devices manually after.

sudo apt update; sudo apt install -y usbguard

Polkit

Next, polkit can modify the lockscreen behavior. I have a policy file template here with comments that can be modified as needed.

MFA

You can also use a Yubikey or the libpam-google-authenticator package to setup MFA for your login. This reduces the effectiveness of shoulder surfing, as anyone would need MFA to also login to the machine if they have your password.

sudo apt update; sudo apt install -y libpam-google-authenticator

# Walk through the prompts and save the QR code / seed.
google-authenticator

Sysctl

Numerous kernel params exist that can be hardened. I maintain an Ansible role that's fully commented, and applies everything possible without impacting normal functionality.

Lockdown Mode

Additionally whether you have secure boot enforced or not, you can manually set the Kernel's lockdown mode to confidentiality. Lockdown prevents unsigned kmods from loading, and confidentiality mode prevents even root from dumping certain process details. See Kernel Lockdown for full details.

Always encrypt the full disk. This does two things; prevents use of your data in the event of a theft (remove hard drive, read it on another machine to gather data) is a signal if someone power cycles the device while you're away, and you left your device locked (and even asleep).

Failing to encrypt the full disk means determined attackers can still remove the disk, modify system files, and reinstall the disk. Effectively backdooring the system with trivial tools like system services or rootkits that are hidden from the OS or EDR. If you're following all pieces of this guide, the physical security and OPSEC considerations should alert you to this.

Ideally you use UEFI and not BIOS. Additionally if possible, set a boot password on your machine. This way if someone tries to power cycle or otherwise tamper with the device (e.g. booting from a removeable USB) they cannot proceed after powering on without a password.

Some firmware also supports chassis intrusion detection and remote wipe. This varies in firmware and actual effectiveness. Test it before you rely on it.

This is broad, but two practical points taken from Dr Duh's guide for macOS and the SANS ISC podcast:

• Use biometrics or MFA for login to mitigate shoulder surfing, or store half your login password on a Yubikey and the other half in your head
• Use paint or nail polish on the chassis screw heads to detect tampering

Wazuh is a great choice if you want to roll your own EDR.

I have extensive notes published on deploying and maintaining Wazuh for reference.