Recently I had to produce some very high-level, general documentation for platform hardening. Boy, there isn’t much out there in terms of content when you start researching this topic out. Yes, there are lots of specific hardening docs for specific platforms but if you are like me and need to write generic “policies” or guidelines you need something that is honestly a bit more vague.

I broke my documentation down into two sections, Ideology and Policies… Here was the result:

General Hardening Ideology:

  • “That which is not explicitly permitted is forbidden.” –
  • Abide by the principle of least privilege – Only allow the bare minimum level of “privilege” that is needed to get the job done.
  • Centrally control your Hardening Standards and when possible, always use automated centralized deployment (i.e. make it a GPO if you are in a MS world or create scripts for linux boxes)
  • Follow Industry Best Practices when they are available – in other words, reference standards from groups like the NIST, US Government, CIS, etc.


  • Only one primary role for each device. For example, a Linux box serving as a firewall shouldn’t also be an SFTP server and a VM host.
  • Only install the software you need to accomplish the tasks associated with the device’s primary role – delete or disable everything else.
  • Remove or disable ALL unnecessary protocols, services, and physical ports.
  • Use secure services options if at all possible. I.E. use SSH instead of telnet or SFTP instead of FTP, etc.
  • Delete or disable all user/admin/service accounts that are not needed.
  • Remove, or at the very least rename, ALL default user/admin/service accounts.
  • If possible, change common service ports if you don’t have a defined need for using the common port.
  • Change ALL default passwords
  • Get rid of any and all sample or example programs, scripts, config files, etc. Also, don’t store potentially sensitive information in the comments of your config files! Document that stuff somewhere else!
  • Figure out what your logging/auditing options are and make sure you turn on the logging options you need in the event of a device compromise
  • Back those logs up to a separate location (a log management device) and if you have a system that can parse and alert on them, by all means USE IT!
  • PATCH, PATCH, and PATCH some more… Make sure at the bare minimum all of your security patches for the OS and all applications are installed before deploying your device!
  • SCAN AND REMEDIATE – This is a big one! – Scan your device using some kind of security or vulnerability scanner and remediate any findings before you deploy your device! Hit your applications internally at first and also use a service or device that can also scan the public facing services your device hosts for the world.
  • TURN ON the extra security features that your device offers if such things exist. Don’t disable security features for convenience. Using SUDO in Ubuntu is a perfect example vs. enabling the root account…
  • If you are running additional core applications (like Apache, PHP, MySQL) be sure to harden those as well! The above ideology section and much of this section would apply in the case of hardening running applications.
  • If you have a hardening standard for your device and you have to put in derivations to meet usage requirements – document those derivations and if possible put in compensating controls to make.
  • Use additional security applications (antivirus) and services (web application firewalls) if at all possible

That is pretty much what I came up with based on what I could find around the web and the consistencies I noted in all of the more focused hardening docs for specific systems and platforms. If you have questions or suggestions, please share them in the comments!

Hope this helps!

This was a pretty good guide for hardening linux hosts:

1 of 1

This post has no comments. Be the first to leave one!

Leave a Reply