Easy security hardening tips and tricks thread

[jubjub]

Thread for short and easy tips and tricks for security hardening. Sometimes it's the small things that make the biggest difference.

I'll start it off with something really easy but valuable for everyone and not just corporate environments: 

When gaming services tell you to port forward ports 1-65535 don't do that. Try and find what ports the specific game you're using actually uses and only forward those. You'll probably find the result on Reddit for most games.

Easy tips from various different environments and setups are welcome whether it's something as simple as mine or a valuable config option for an enterprise firewall.

[Florian]

Do not turn off windows firewall. 

In case you have fear to turn it on, turn it on in allow mode and log your traffic, analyze it and then fix your firewall and put it in blockmode

[MalwareTech]

Use non standard ports for service. A lot of people consider it security through obscurity, but you cut down on background noise from internet scanners and may also be saved from mass exploitation in the event of a vulnerability. 

[jubjub]

6 minutes ago, MalwareTech said:

Use non standard ports for service. A lot of people consider it security through obscurity, but you cut down on background noise from internet scanners and may also be saved from mass exploitation in the event of a vulnerability. 

Hard vouch this. Obviously don't rely on it to stop anything but it's a neat trick to have even just to thin out your logs.

[clarkee]

17 minutes ago, MalwareTech said:

Use non standard ports for service. A lot of people consider it security through obscurity, but you cut down on background noise from internet scanners and may also be saved from mass exploitation in the event of a vulnerability. 

i'm a supporter of this - ssh on tcp/22 produces very noisy logs; moving it to something high and random almost cuts that noise to 0.

still use ssh keys, still deny remote login as root, have a sensible sudo policy, consider ip whitelisting or perhaps dont' even expose your ssh to the internet to start with :P

[j91321]

1 hour ago, MalwareTech said:

Use non standard ports for service. A lot of people consider it security through obscurity, but you cut down on background noise from internet scanners and may also be saved from mass exploitation in the event of a vulnerability. 

I'd say use non standard ports only on services exposed to the Internet. I've seen people do this this inside the network where it adds overhead if you do any form of monitoring. Sure you can have your own set of rules of what runs where, but that will soon become a nightmare to maintain.

[doctor_tran]

1 hour ago, MalwareTech said:

Use non standard ports for service. A lot of people consider it security through obscurity, but you cut down on background noise from internet scanners and may also be saved from mass exploitation in the event of a vulnerability. 

I did this back in the day when my personal infrastructure was small and easy to manage. I even automated the block of IPs that attempt to log into admin tools via the standard port. 
However, in an enterprise environment, trying to manage custom ports is bigger headache than what it's worth. 

[Zer0Risk]

Restrict Admin Authentication tries in Windows AD environment: https://support.microsoft.com/en-us/topic/kb5020282-account-lockout-available-for-built-in-local-administrators-bce45c4d-f28d-43ad-b6fe-70156cb2dc00

Useful against brute Force/dictionary attacks.

Edited November 5, 2022 by Zer0Risk

[sancla]

Disable services you dont need, such as the print spooler on Windows servers 😉

[Elched]

In a corporate environment, if you cannot avoid using generic accounts on some systems, use a password manager that provides folder sharing capability to make passwords securely available among teams.

This will help mitigate (somehow) password reuse, easy-to-guess generic passwords and passwords stored in clear text 🙂

Edited November 5, 2022 by Elched

[sianemo]

This is really basic, but befits the thread: in a corporate environment you should enforce MFA on your users, and if policy allows, prohibit the use of SMS based MFA.

Also, in 365 specifically disallow Windows Hello face authentication. Windows Hello face authentication has been fooled before by security researchers ( https://www.engadget.com/cyber-ark-microsoft-windows-hello-trick-173547832.html ) and, in my experience, has a high failure rate on legitimate attempts.

[Fry]

For Windows i would say don't use admin accounts for your daily stuff and Linux disable ssh password authentication (where possible). Both is still very popular in many corporate environments, sadly.

[rx13]

Considering cloud;

• Use MFA for user accounts, and tie them to a central authentication provider. Do not use IAM (service accounts) for user access. No exceptions.
• Create IAM (Service) accounts for service(s) access, and do not reuse them between disparate services.
  • this makes isolating exposed keys much easier, and potentially assists with investigation/remediation efforts down the line
• Don't keep secrets in files. Load them from secure storage solutions like Secrets Manager(s) at runtime 
  • Hashicorp Vault or LastPass APIs for self-hosting/alternative options to cloud services
  • this also helps with rotating secrets down the line

Considering containers;

• Do not expose your docker or kubernetes administrative interface to public networks, even if authenticated.
• Execute container runtimes as an unprivileged user when creating new containers, unless necessary to perform the core tasks of the container
• When running untrusted containers from docker hub, remove potentially sensitive environment variables
  • If running in AWS, use IMDSv2 and set the number of allowed hops to 1 (host) if containers have no need to access instance metadata
• Exercise caution when mounting system resources into containers; documented vulnerabilities regarding types of volumes and mount points are well documented.

Considering servers/hosts;

• Use iptables(firewalld/ufw) and Windows Firewall where (as pointed out elsewhere) to limit the potential for accidental service exposure (in cloud, use Security Groups similarly)
• don't put any remote desktop protocol on public, even if authenticated (put it behind a VPN)
• SSH on public is likely fine if paired with SSH keys (encrypted) or very strong password policies
  • use fail2ban or non-standard ports to diminish probe activity, if that bothers you
• Regarding ssh;
  • DIsallow X11, agent, and port forwarding on bastion services if your environment has no need.
  • If you're _really_ paranoid, consider a chroot ssh option on bastions
• Run and consider outputs from *Lynis*, which will often highlight a number of hardening options on linux environments
• Terminate TLS/public on a reverse proxy (httpd/nginx), and pass only necessary headers to the backend service (whether self-hosted, cloudflare, cloudfront, etc, etc)
  • not only does this normalize termination points for your public HTTP, but it also allows you to enforce blanket TLS policies easier, or even implement mutualTLS, minimizing attack surface to pass through your proxy provider
• Run all backend/exposed services as non-privileged users. There is very seldom a reason to run a service as a user with any _sudo_ / administrator capability

[mle]

3 hours ago, MalwareTech said:

Use non standard ports for service. A lot of people consider it security through obscurity, but you cut down on background noise from internet scanners and may also be saved from mass exploitation in the event of a vulnerability. 

I understand the intent of this–cutting down on noise, avoiding lazy, widespread exploitation attempts by scanners that are only looking at default ports. But I think it can be dangerous to recommend as an actual security measure, because while it may save you from some of the annoying noise or driveby exploitation, it won't really stop someone who's mapping your org's external footprint.

Edited November 5, 2022 by mle

[MalwareTech]

Just now, mle said:

I understand the intent of this–cutting down on noise, avoiding lazy, widespread exploitation attempts by scanners that are only looking at default ports. But I think it can be dangerous to recommend as an actual security measure, because while it may save you from some of the annoying noise or driveby exploitation, it won't really stop someone who's mapping your org's external footprint.

This is true, but typically most attacks are indiscriminate rather than targeted. Raising the bar is always good!  

[michel_cryptadamus]

get an AWS Credentials canary token from Thinkst (AKA "a fake set of AWS credentials that sends you an email if anyone ever uses them") and put it in ~/.aws/credentials.

alternatively if yr a journalist (and not a technically inclined one) get the word document canary token instead of the AWS one and put it in a file called ~/Documents/hunter_bidens_laptop.doc.

[SabreWolfy]

Use ssh keys for login authentication instead of passwords.

Edited November 5, 2022 by SabreWolfy

[swankyatomic]

On Windows learn how to use and apply group policies.

For example if you know you do not need Powershell, disabling it via a group policy will prevent a large amount of post exploit payloads from firing.

[rx13]

1 hour ago, michel_cryptadamus said:

get an AWS Credentials canary token from Thinkst (AKA "a fake set of AWS credentials that sends you an email if anyone ever uses them") and put it in ~/.aws/credentials.

alternatively if yr a journalist (and not a technically inclined one) get the word document canary token instead of the AWS one and put it in a file called ~/Documents/hunter_bidens_laptop.doc.

+1 to canary tokens. These are easy to implement and valuable for insights even outside of the AWS and doc formats. (Seed internal-only repositories with "accidental commit" tokens to see who's poking around)

[cowjuice]

For AWS use something like aws-vault to generate temporary credentials, with a short TTL,  rather than using your actual access id/secret. This means if you accidentally expose the credentials there is a limited time window in which they are useful.

[habitual]

I think people discount how much cutting down noise helps when it comes to security monitoring. It's way easier to dig for actual bad in logs if you're not have to ignore every cred stuffing attempt.

[Name_Too_Long]

Remap executable file types (e.g. .js, .vbs, etc.) to open in a text editor by default.

Unless there is a specific reason something needs to be directly accessible from the general internet, it should not be directly accessible from the general internet.  VPNs can hide many sins.

[andrew]

I still see these in most SME environments beyond the most common stuff which is also usually in a mixed state of disrepair.

• Enable ASR (Attack Surface Reduction) rules in via Group Policy.
  • Audit mode is great to assess effort required to enable or where it's safe to enable
• If you have Microsoft Secure Score, review the recommendations, but always assess context.
  • It's easy to have 85%+ on the score and still be completely vulnerable. My preference is to never expose this metric to leadership as they'll hyper focus on it as some security panacea all while ignoring things like the security of backups.
• Run Pingcastle in every forest. It's free and doesn't require elevation. If you're a consultant or auditor, pay for it and support the developer.
  • Automate it. It's easy to parse the XML and do diffs to see what changed.
• Regularly audit sysvol and netlogon for weak permissions (e.g. editable/writable directories and files).
• Document your DSRM passwords
• LAPS
• Disable Office Macros and Office OLE
• Delete calc.exe
• Enable bitlocker on everything. Even Windows Home supports it. But it's rarely enabled on office workstations.
• Disable all the crap you're not using. WPAD, LLMNR, Browser Service, Net Session Enumeration, NetBIOS (DHCP+NICs), wdigest, WSH (and redirect extensions), HTA (New Group Policy in Oct. I believe), smbv1, PowerShell 2.0, etc.
  • In general, audit what you're using and disable legacy protocols.
• Configure LDAPs, Lanman Auth, NTLM Session Security, etc.

[arcsinx]

7 minutes ago, andrew said:

• Enable bitlocker on everything. Even Windows Home supports it.

Oh really? Is there some trick to this or did I miss some news? Last I heard it still required the Pro upgrade.

[andrew]

4 minutes ago, arcsinx said:

Oh really? Is there some trick to this or did I miss some news? Last I heard it still required the Pro upgrade.

https://learn.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-device-encryption-overview-windows-10

Edited November 6, 2022 by andrew
urlify