Don’t know where to start with your servers and application security? Need to know if you’ve plugged all the gaps? We’ve chopped down your essential systems security concerns into bite sized pieces so that you can implement them with ease.
Your application *is* your business. Without it, you’re going to be dead in the water. Avoid downtimes, data theft, and scrambled systems by making sure it’s Fort Knox up in there.
Secure your servers and application at the network, architecture, and application levels by applying these 19 methods to beef up your protection at every opportunity - and keep the bad guys at bay.
Network
Network attacks are fairly common these days! Here’s how to keep your data secure when it’s traveling across public and private networks - and keep the bad guys out of your networks!
1. Send traffic over HTTPS (including images, assets, and files)
Using HTTPS (SSL) at all times instead of HTTP means that all traffic sent over the network connection between you and a recipient is encrypted, so no data can be intercepted and read in transit.
2. Use encrypted communication between your application and databases
Application and database live in separate spots on the network? Prevent unauthorized listening by encrypting the connection - much the same as you’d use HTTPS over external internet connections.
3. Keep application servers and databases outside of public networks
Ensure access to the application is only via proxies and access to instances is only via bastions. A bastion is a server the inside network that a user has to connect to in order to get access to other servers inside the network.
4. Use [ModSecurity](https://github.com/SpiderLabs/ModSecurity) firewall with [pre-defined rules](http://www.modsecurity.org/rules.html) to prevent typical attacks
From Trustwave’s SpiderLabs, ModSecurity is configurable firewall that makes network monitoring with custom rules super specific and effective.
Underlying architecture
Prevent access to your underlying data, and make darn sure that if someone gets to it they can’t read it anyway! Here’s how to secure at the machine level.
5. Encrypt as many files as possible
The more you encrypt, the more secure all your data is. This means logs, database snapshots, underlying storage… if its there then encrypt it!
6. Encrypt sensitive data within the database
Your customers (and your business’s!) details are extremely important to keep secure. Make sure to encrypt all bank accounts, social security numbers, etc.
7. Decrypt data through a centralized service like [AWS KMS](https://aws.amazon.com/kms/)
The AWS KMS service provides key management separate from your own systems, and this prevents anyone running out with sensitive data. Even if a hacker gets a decrypted database dump, they won’t be able to decrypt the sensitive data within it, because they were encrypted separately via AWS KMS.
8. Use HIDS systems (i.e. OSSEC) to monitor servers for suspicious behavior
Use an Open Source Host-Based Intrusion Detection System to deal with security threats inside host machines, by developing rules like "on USB insertion" and responses like "deny all file transfers". Make sure to check out our tutorial "Automating OSSEC HIDS Deployment on Modern Infrastructure Pipelines for Security at a Touch", available for free download ☺️
9. Keep your sever and libraries up to date with the latest patches and fixes
Servers and libraries should be kept up to date, as oftentimes updates contain fixes for security issues which need to be patched to prevent intrusion attempts.
Application
Don’t let your system crash from DDOS and brute force attacks. Protect it at the application level with these measures in place.
10. Limit the number of simultaneous sessions per account
You don’t want your application flooded with connections. Make sure that each account is only allowed a limited number of sessions at once to reduce application exposure on account compromise.
11. Rate-limit incoming HTTP requests
Limit an overload of automated attacks from bot networks by imposing a rate-limit on how many HTTP requests you receive per unit of time. There are numerous helpers about, such as Rack-attack for Ruby apps, which blocks and throttles requests with ease.
12. Add all HTTP headers related to security to prevent different types of attacks
Learn to know your header fields! There are numerous headers that can help to avoid security exploits such as cross site scripting. There are a number of helpers you can try out for automatic header security setting, such as Helmet if you’re using Express for Node.js or secureheaders if you are using Ruby.
13. Avoid exposing sequential IDs (98, 99, 100…) in data and urls - always use non-deterministic IDs (eg. UUIDs) instead
Want to know why auto-incrementing IDs is a bad idea? Check out the top answer under this Quora question - "Is exposing database auto increment id considered a bad practice?". Not only can it make you look dumb, but it can cost your business money or disclose data you didn’t want to!
14. Check your application’s code and external libraries for security vulnerabilities periodically and keep all tools and libraries up to date
While we all get annoyed with constant requests to update our apps and operating systems, the most common reason you need to update is for bug fixes and security updates. Do like the pros do and make sure you keep your app, tools, and libraries up to date (and roll out changes) to ensure security.
15. Add Two-factor Authentication (2FA)
Sure, someone might be able to steal or guess a user’s (or root’s!) password, but are they going to be confirm their identity via SMS? Enable 2FA for extra login security.
16. User authentication with additional rules
Because there’s probably someone out there still using "password123" or "*dognamebirthyear*", implement password rules, that you’ve probably heard ad nauseam by now…
- enforce a minimum password length policy
- use account confirmation via email
- lock accounts after a specified number of failed sign-in attempts
- don’t allow repeating passwords
- ensure password is a combination of letters in upper and lower case, numbers, and symbols
17. Expire authentication tokens (for the API clients) or sessions after specific period of time
Let’s not allow tokens or sessions to be hijacked by man in the middle attacks. By putting a time limit on authentication tokens and/or sessions you limit the opportunity.
18. Validate files before processing
Protect yourself from injection attacks. Check incidentals such as file size, file extension, and acceptable media types before processing files.
19. Reject archives such as ZIP, RAR, and GZ
The danger with archived files is that you don’t really know what’s in them. Let’s just knock them out completely - don’t allow them altogether. If file sizes are an issue, then look for other options.
We know server and application security. If you’d like a security check on your systems, or need any help with implementing security measures, then iRonin is here to help. Drop us a line and get the ball rolling today.
