Security is not optional on public Facing Sites

Today I saw an interesting statistic on slashdot: Over 200000 database servers with no authentication, over one petabyte of data access. Earlier this year, there was a post about how many people accidentally post their aws keys to github without realizing they've just opened themselves to potential charges with automated network scanners. 

An increasing number of people put their servers online without any security and put passwords/keys online. A lot of hacks are a result of careless mistakes/ skipping security altogether.

Some would argue that the data on some servers is less confidential than others or a cloud server that will be up for a short time is not as much of an issue but as technology evolves, there are more and more money incentives to hacking systems, one should expect more intrusions and more sophisticated attacks.

Further, security is as strong as the weakest link in the chain and a compromise on an unimportant server that may seem harmless may end up costing much more than expected. For example, I have seen servers that were never meant to be online may end up opening wide open a whole secured network. Sometimes, temporary solutions end up lasting much longer than initially planned. As a result, since security was overlooked because the solution was never meant to last, the whole network is wide open.

Obviously, there can be no guarantees that a zero day exploit will expose a network to malicious attacks but if there is no security, it is even worse and consequences are potentially catastrophical.

Many guides to securing servers exist and this is obviously not meant as an depth security manual. As a matter of fact, the advice below should be common sense and already be in place but I have seen these basic rules ignored too many times, so here are things you should already be doing:

• Keep your server up to date - that includes os updates and software updates. This should be obvious but way too many times, I have seen servers that have not been updated for over a year for no good reason whatsoever
• Make sure authentication is turned on wherever it needs to be - that includes databases servers, smtp servers, no default users, restrict users to only the permissions they need (For example, if you have a wordpress website, there is no reason for it to use the root mysql credentials. A mongodb admin account that can be accessed from anywhere without a password is obviously a big no no as well)
• if a service is not necessary, don't have it on by default - The less services you have available, the smaller the network footprint and the less likely one of the services will be vulnerable - either because it is misconfigured or because of a zero day vulnerability.
• Make sure api key, credentials and sensitive information is not available publically on sites like github.  With many search engines crawling the web automatically on a daily basis, putting them on any directory that can be indexed is looking for trouble as well
• Make sure you have a backup of your data and do not hesitate to bring the server offline/ reinstall if necessary - if a server is compromised, simply changing the password and putting the server back online is not going to cut it. 
• Have sensible firewall rules - multiple times, I have seen firewalls disabled during development time and never turned back on.
• In any application, trust no input. This can avoid the most common vectors of attacks - sql injection, css injection, buffer overflows and abuses due to invalid input. This includes validating the input both in the backend and the frontend.
• If you are using linux, SELinux is your friend. Too many times, I have seen SELinux disabled just to save a little time in configuration. This will help mitigate damage even if a hacker gets in.
• Change passwords regularly and they should not be easily guessed. With brute force tools commonly available, many attacks start with a weak password.
• Have sensible monitoring of both your services and your logs. If you only have one server, then you could get by with manually auditing things but with multiple servers you'll need either a log ingestion engine or some way to automatically parse/filter relevant information

As I said earlier, there are plenty of more complete guides on securing servers but this is more of a reminder of what you should be already doing.