Healthix Security Report - Server Hardening

The Core security for the Web Server needs to be looked at from an offensive and defensive point of view.

Below are some of the guidelines to take into consideration when hardening the server

User Accounts:

Default accounts such as root user should be disabled, and different groups created to accommodate various levels of authentication with permissions set for activities.

User accounts created for running services should have permissions disabled for logging in such as SSH

Privilege Access Management:

Having a Privilege Access Management will also be key if there are a few trusted issues among the DevTeam.

We have seen in the past where Devs make changes and no can tell who came in to perform what. Thycotic will be the best to use but if you want to go the opensource way, I have written a script 5 years ago which still working to make commands being typed on the system immutable https://github.com/triclorne/Immutable-Command-History-Logging

Default Ports and services

The core default ports and services on any server has to be changed due to the fact that botnets will use it for malicious activities such as publicly available exploits and also Denial of Service.

Service and ports to change include:

Apache, SSH, FTP

Guide to get disable or change these ports can be found in the link below

https://ostechnix.com/how-to-change-apache-ftp-and-ssh-default-port-to-a-custom-port-part-1/

Server Signature Changes

Giving the least information of a server makes it very difficult for hackers and botnets to scan or compromise a server. One technique to use is to hide information such as the type of OS, services and packages installed. Changing the server signature confuses scanners and limits exploitations

Web Application Security:

There are a number of open-source Web Application firewalls that assist so stop attacks even if they have exploited a vulnerability. An example is SQL Injection being exploited on a server can prevent the attacker from dumping the Database or even enumerating the vulnerable points.

The most commonly used security solution will be MODSECURITY.

Installation for this can be found in the links below

https://github.com/pymodsecurity/django-pymodsecurityOther popular solutions include NAXSI or WEBKNIGHT as open source

For proprietary solutions, the most recommended will be proxy through Cloudflare but that has to be tested thoroughly to make sure it doesn’t affect your Performance.

DDOS Protection:

Apart from a commercial firewall, the most recommended solutions to prevent hackers from scanning a server will be to lock them out on various attempts.

Fail2Ban is one of the best OpenSource Web Application firewalls but needs careful installation.

An alternative to Fail2Ban that can be used is Artillery which you can get from https://github.com/BinaryDefense/artillery

Mutual Authentication:

Mutual authentication is a two-way authentication mechanism that ensures that two entities authenticate each other before an actual authentication occurs.

This is needed to be set up between the various servers as well as third party integrators to ensure strict communications.

HSTS

These days there is no reason not to deploy your entire website behind HTTPS. Otherwise, a hacker could sniff authentication credentials, API keys, or really any information transferred between the client and server. There are a number of settings to enable full SSL support in a Django project.

SECURE_SSL_REDIRECT automatically redirects requests over HTTP to HTTPS. It should be set to True.

HTTP Strict Transport Security (HSTS) is a security policy that lets our server enforce that web browsers should only interact via HTTPS by adding a Strict-Transport-Security header. There are three implicit HSTS configurations in a settings.py file that need to be updated for production:

• SECURE_HSTS_SECONDS = 0

• SECURE_HSTS_INCLUDE_SUBDOMAINS = False

• SECURE_HSTS_PRELOAD = False

The SECURE_HSTS_SECONDS setting is set to 0 by default but the greater the better for security purposes. A good default is to set it to one month, 2,592,000 seconds, instead. SECURE_HSTS_INCLUDE_SUBDOMAINS forces subdomains to also exclusively use SSL so it should be set to True in production. And SECURE_HSTS_PRELOAD only has an effect when there is a non-zero value for SECURE_HSTS_SECONDS, but since we just set one, it will need to be set to True.

Extra Security measures to make Django secure can be found in the link below:

https://opensource.com/article/18/1/10-tips-making-django-admin-more-secure