There are literally hundreds of ways to secure & solidify a Nginx server after an attack.
But, what does it REALLY need to be cleaned and secure? What are the essential changes you have to make to feel secure again?
To answer that question, we’ll have to investigate what the most widely recognized security issues that affect a Nginx server. These are the security issues most often seen:
- Malware transfer and spamming
- Botnet assaults
- Brute Force Attacks
- Basic vulnerabilities in server programming (SSL, Nginx, and so forth)
- Spam from Comments
As should be obvious, you should probably confront a site vulnerability or hack and treat it as a high-seriousness event.
That is the reason why we suggest securing your Nginx server, especially if your site was hacked recently.
If possible, give more thought about the changes you can make to a framework that will help to avoid site vulnerabilities. Right away, here are the best tips you can take to secure Nginx server after a hack.
1 – Secure the application that was attacked. Audit and fix errors in your web application
Being proactive is always better than being reactive. That is the reason we suggest that after a hack you fix all web applications on your Nginx installation when a vulnerability is uncovered.
Especially if your NGinx installation has been hacked, you should continuously scan all updates to the web apps installed and used on your server, and compare those versions installed with the latest releases on the net, and apply patches if the version is found to be old or is not insecure.
2 – Change Nginx settings for security
Nginx, of course, is meant to execute a task or application and is not inherently secure.
The most common settings you can change are:
- Disable all requests with the exception of GET, POST, and HEAD
- Put a restriction on the request & buffer size to limit buffer overflow attacks.
- Disable all NGinx features & modules that you don’t need or don’t use.
- Limit the number of connections from a single IP address to 10.
- Remove Nginx headers & PHP header info, so hackers can’t get info about the server.
- Enable security headers that will block common attacks, such as “X-XSS-Protection.”
You can add extra settings depending on how your application was hacked, or what vulnerability was used to exploit Nginx.
3 – Use a secure SSL certificate with a secure cypher
A great way to recover after a hack is by installing an SSL. One option would be OpenSSL, and while it is free, it has gotten a great deal of unfavorable criticism in the ongoing years in light of wave after wave of security vulnerabilities.
A considerable portion of these issues happened on the grounds that individuals continued utilizing old and powerless Ciphers and Protocols. Which is the reason you should make it a point to audit the SSL Cipher and Protocol list that are being used on your Nginx installation at least once every month.
You should make it a point to expel old and insecure Ciphers/Protocols, for example, RC4, SSLv2, SSLv3, and so on and use just those that are turned out to be stable. Furthermore, we suggest that HSTS (HTTP Strict Transport Security ) is used in eCommerce settings to ensure phishing is minimized.
Finally, we recommend that you set up auto-renewal for all authentications introduced in the server with the goal that the server stay secure in the event that you forget to renew your SSL. Forgetting to update your credit card should never be a reason for the security to lapse on your website.
4 – Install server patch fixes as soon as they are available
You have to set up a consistent monitoring against new sorts of assaults coming into the great beyond. You also have to be vigilant, and if possible, you should let security specialists monitor your servers 24/7 for security issues, hacks, & pending security updates.
On the off chance that another weakness is uncovered that doesn’t have an official fix yet, security & programming experts can set up a “hot-fix” for the vulnerability so it can’t be abused until the point when an official fix turns out.
5 – Stop basic attacks with a Web Application Firewall
The web is hit with many new web application vulnerabilities each day. Be that as it may, every one of these vulnerabilities utilizes well-known assault strategies that have seen before, for example, Cross-site Scripting, Remote File Inclusion, Path Traversal, SQL Injection, and so forth.
What’s more, especially if your Nginx installation has been hacked recently, you need to look into Web Application Firewalls. (WAFs) identify all sort of malicious conduct incoming to your server so it can be blocked. You can expect great outcomes in utilizing open source firewalls, for example, Mod Security and NAXSI.
Be that as it may, the vital thing to remember is, your firewall is only as good as the settings and configurations it has. We suggest that depending on how your site was hacked, that you or your team compose your very own custom principles in the event that we feel that none of the guidelines satisfactorily secure our client servers against another risk.
Nowadays, a wide range of server hacks & malware infections are completed utilizing automated devices. What’s more, these attacks depend on constant “brute force” techniques that experiment with different passwords or try to break a login screen.
Such examples can be effectively identified by any well-designed firewall system. If you are using Nginx, you can use special firewalls and set up additional settings, for example, CSF to ensure a wide range of malicious conduct, for example, port scanning, brute force, and others. are detected and blocked before they are even passed on to the Nginx service
There are a hundred different ways to solidify a Nginx server after an attack, yet what are the essential ones? Today we’ve taken a gander at the best security dangers tips for fixing a hacked Nginx server, and what we do to harden it from hackers and malware after an attack.
*** This is a Security Bloggers Network syndicated blog from Web Security Blog – Acunetix authored by Samuel Bocetta. Read the original post at: http://feedproxy.google.com/~r/acunetixwebapplicationsecurityblog/~3/8JZDqAd1a-8/