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
  • 1
  • There are some good tips http://serverfault.com/questions/5942/linux-hardening-web-servers and http://serverfault.com/questions/212269/tips-for-securing-a-lamp-server http://serverfault.com/questions/222499/best-practices-for-hardening-locking-down-windows-server-2008-r2-for-use-as-web-s although it depeneds on server roles. – tombull89 Sep 13 '11 at 08:34

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,957
  • 19
  • 68
  • 100
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
  • 2
  • 8
Khaled
  • 36,533
  • 8
  • 72
  • 99
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
  • 8
  • 15
  • Is there any decent tool for creating good outgoing rules? – Nils Sep 13 '11 at 20:06
  • @Nils - Deny everything to start, and then only allow what you actually need for the application to work. – mfinni Sep 13 '11 at 20:20
  • This might be a lot of things you don`t think of - including ldap, nis, dns, ntp, ... which are all outgoing requests that need to work for proper server and thus proper application workability. – Nils Sep 13 '11 at 20:55
  • It depends extremely on your demands. closing and than opening is the best way like mfinni said. i know it sounds like a lot of work, but that's needed for a real hardened server. first of all start with pen and paper (or digital equivalent ;-) and take some time writing down what services are needed for the server to do his job. after that, take a coffee break... take your sheet again and overthink your writings. did you forget some? is everything on this list really needed or can you strip down some? building a good firewall is at least half the time planing it. – Mose Sep 14 '11 at 09:38
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
  • 2
  • 8
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,695
  • 3
  • 34
  • 73