4

As a software developer I am very used to installing my typical stack (java, mysql and tomcat/apache) on my development machine. But setting up and securing a production machine is not something I would feel confident doing. Is there a A-Z guide for dummies for setting up and securing a production server? Is the process very different depending on platform (Windows or Linux)? Are there some general rules that can be applied across different platforms (and application stacks)?

Dan MacBean
  • 141

5 Answers5

3

Is there a A-Z guide for dummies for setting up and securing a production server?

No. There's just too many possible combinations of software, code, platform, hardware, etc. for this to be possible. If you break up your stack, however, you'll find good bits of information for each level (i.e. hardening your OS, Web application security best practices, etc).

Is the process very different depending on platform (Windows or Linux)?

The process of hardening is the same, but the implementation details are not.

Are there some general rules that can be applied across different platforms (and application stacks)?

Yes. You should create a configuration profile of your application: document your application's dependencies (any services that are required to be running; any network ports/protocols that need to be open (in and out); any third-party libraries/components) to establish a baseline of requirements for your application to work. Systematically remove/disable any services, applications, and ports you don't need; run services and applications with least privileges required. Test each step of the way; you will break something.

Invest in a proper firewall and enable egress filtering (if your box gets owned, don't let it establish direct TCP connections); use a whitelisted proxy to only permit outbound HTTP to required updates (windowsupdate.com et al, Linux repositories). Setup alerting and proper logging: alert on failed login attempts, services starting/stopping, being installed, privilege escalation, etc. Patch management is important; design a maintenance window that makes sense and stick to it. Don't let updates accumulate for too long.

If this is a Web application, look at your entry points, your HTTP verbs-to-URI mappings and whitelist your POST or GET parameters, scrub your forms (don't trust any inputs), escape your SQL (or use a 3rd-party library that does this for you), log all your SQL queries, and so on.

gravyface
  • 13,987
1

There are many general rules that apply to all types of servers like:

  1. Remove the unused software and shutdown the unused ports/services. They are wasting resources and they are a possible vulnerability.

  2. Apply patches and upgrades continuously especially when finding some bug or weakness.

  3. Change all default passwords and/or disable guest/default account(s) whenever possible.

  4. Use strong passwords.

  5. Use SSL to secure your transactions whenever applicable and appropriate.

Also, each specific service can have some tips for securing it.

Paperjam
  • 139
Khaled
  • 37,789
1

use a firewall like iptables and put some time in planing what connections to the machine should be possible and needed. limit incomming AND EVEN outgoing traffic.

Mose
  • 654
0

In addition to Khaled's answer:

  • Change default account names including:

    • sa account name in SQL Server or MySQL
    • administrator account name in Windows
    • any default admin account name in any other remotely-accessible product (Plesk, Wordpress, etc.)

  • In the case of SQL Server or any other DB server, disable remote connections unless needed, and if they are needed, consider blocking off the ports that server uses and white-listing the allowed IPs.

Community
  • 1
Paperjam
  • 139
0

A special tip for tomcat: bind its ports to localhost and use a proper webserver (e.g. apache httpd) as frontend. Many of the latest tomcat weaknesses could only be exploited if you had access to the manager application.

So if your application is up and running it is a good idea to get rid of the manager application as well. Disable auto-deploy.

Make full use of different roles - the webserver httpd does not need any access on os-level to the files that tomcat provides and vice versa. So if someone exploits a httpd weakness and gets down to the command line make sure he can not write anything important.

Have a look at ISO 27001 - there is also a stack-exchange forum that specializes on security.

Community
  • 1
Nils
  • 7,815