Cheap ways to secure your server

Off
Strongback Consulting

Before you read too far, this article is for the average small to medium sized business. Most large organizations have dedicated security staff that likely already knows these tactics, but that’s not to say they may not learn something here or there.

Everyone seems to have a silver bullet for securing your infrastructure. The truth is, there is no such silver bullet. Much like the fabled tonics of the early 20th century, they mostly amount to snake oil. Ultimately, it requires attention and diligence. Most hacking attempts go unnoticed.

1. Use passphrases, not passwords.

Your password scheme sucks. Period. Watch these videos. The first one should scare the hell out of you.

“Stop thinking in terms of passwords, and start thinking of passphrases”

2. Review your firewall rules regularly

You should regularly review your firewall rules and understand what is allowed. You must take a pessimistic approach to traffic. As your business changes, so does your IT needs. Make sure you only have open what is needed. Applications come and go. Sometimes a development team needs an application open for a short time. Make it a policy to review your firewall rules monthly and have solid documentation on what traffic is allowed and where.

3. Front end your application servers with HTTP servers

Application servers, namely Java application servers should never be exposed on the Internet. We work extensively with IBM Websphere App Server, and Liberty Server and it alarms us how often organizations just allow connections to the bare server. An HTTP server acts as a proxy, and thus a layer of protection against various intrusions. This protects the various open ports on the WebSphere App Server that could be potentially compromised, as well as improving overall application performance. Check out our article on using IBM HTTP server for the CLM products:
https://www.strongback.us/2017/12/why-you-need-to-front-end-your-clm-servers-with-an-http-server

4. Keep written records of who has access to what

Unless you are the owner of the business, no one should have access to all the keys. Despite the cliche about eggs and baskets, this also puts dangerous risk on the employees as well should something adverse happen. You should keep records of who is responsible for what server, container, application, OS, or VM. Ensure that the load is well distributed and that no one person can sabotage your entire infrastructure. Use automated auditing tools to keep track of operating system ID’s and LDAP credentials. Use LDAP groups rather than explicit person ID’s will help avoid back door issues.

5. Drop traffic from locations you know you don’t need or want.

This is a favorite of ours. As we do business almost exclusively in the United States, we drop all traffic coming in from most foreign locations. For some servers, we take an even more pessimistic approach and only allow traffic from a small handful of IP addresses.

You can use the following site to generate scripts and configuration files that will drop traffic from certain IP addresses. As most IP address blocks originate from predefined localities, it makes it easy to generate scripts that block such locations in bulk. We use IP2Location for this:
https://www.ip2location.com/free/visitor-blocker

Linux IPTables is a good place to start with this. If you want to know what countries you should be blocking, check out these articles:

https://abcnews.go.com/Technology/photos/top-hacking-countries-19844818/image-19845364

https://www.entrepreneur.com/article/229474

Once you have the list of countries and location to block, go to IP2Location and generate your list, and apply it to your servers.

Comments are closed.

Strongback Consulting