As you know, cyberattacks are part of our daily lives as sysadmins and developers.
You only have to look at the latest news in the newspapers, they are becoming more and more violent.
Today we're going to look at some best practices to prevent and protect against malicious attacks.
Never forget that zero risk does not exist, and that we are never safe from an attack.
Place services and servers behind a firewall
Although the servers have the option to have an active firewall on them, it is not recommended to put them directly with a public IP directly on the internet.
Built-in firewalls are often basic, or require a lot of complex configuration that can become cumbersome to manage over time.
It is advisable to put these servers in a DMZ network subnet, and forward ports only necessary for using the service
Dedicate a DMZ network subnet
By definition, a DMZ is a "Demilitarized Zone", this means that this subnet must be isolated from the rest of the network.
This allows if a server is compromised, it does not infect the entire network, or is limited to only the machines in that network
Of course, the DMZ(s) must not be able to access other networks, but can be reached via other subnets (for example for management, or for monitoring services).
It may also be worthwhile not allowing servers in the DMZ to initiate connections with external servers. This limits the risk of data extraction from the server.
Allow only necessary inter-VLAN traffic
VLANs are used to segment your network, but are also used to set up filtering rules.
Indeed, let's imagine that a segment contains web servers, it is advisable to only allow ports 80 and 443 to pass towards this segment.
This way, if a machine gets infected in another segment, the chances of the infection spreading in that VLAN are limited.
Of course, the ports must be adapted according to the services available in the VLANs in question.
Protect yourself from brute force
One of the techniques to enter a system is to try all login and password possibilities.
It is very difficult to detect this type of attack among other legitimate accesses, and therefore the only way to block this type of attack is to implement an IP address block after several failed attempts.
Personally, I set an expiration time for blocks, otherwise if customers enter their password incorrectly several times, manual action is necessary to unlock their access.
Set up a GeoIP restriction
If your services and servers are only intended for one or more countries, it is advisable to block access to only certain IPs that are linked to the desired countries.
Many online services catalog and provide lists of public IP addresses associated with different countries.
Therefore, there remains a risk that the information provided is incorrect (even if checks are carried out)
Keep your systems up to date
Servers and network equipment must be kept up to date to patch discovered vulnerabilities and gain new features.
A routine should be put in place to ensure that systems are always up to date.
If this is not implemented, there is a risk that updates will not be made, because we too easily say to ourselves "I'll do it later"
Establish a bastion for management
Rather than allowing everyone to access server management, it is advisable to set up a hyper-protected and monitored management (or bastion) server.
The idea is that only people responsible for managing the infrastructure have access, and that a different login and password is used for each person.
Of course, this bastion will have to be restored first in the event of a DRP in order to orchestrate everything.
Grant only the necessary rights
This point is especially relevant for file servers where CryptoLocker can quickly cause damage.
In fact, the more network resources a machine has access to through a user, the more damage it will do once infected.
Additionally, if a user group only needs to view a certain folder, it is not necessary to give them write permissions, only read permissions.
Change the default login and password, and set strong ones
It's no secret that attackers first try default logins and passwords on systems. That's why it's important to change your password, and the default login if possible.
Best practice is to disable the default admin account, and create another account with administrator rights (known to very few people).
Other administrators and users will use named logins to access the various services and systems.
Avoid generic accounts as much as possible, as it is more complicated to track access, and restrict if necessary.
Additionally, if someone leaves the company, it will be more complicated to change the password and pass it on to everyone rather than deactivating an account.
The last word... or not
The points below are just a small part of what can be done to secure your infrastructure.
Other measures are possible, and often make sense.
