Securing its Debian machine

nl:Beveiligen zijn Debian machine it:Protezione relativa macchina Debian pt:Protegendo sua máquina Debian es:Su máquina Debian fr:Sécuriser sa machine Debian

This article has been created by an automatic translation software. You can view the article source here.

Introduction

Ensure the safety of his machine is an essential point that shor ld No. t be underestimated under penalty of becoming the target of various attacks. The current power of computers today making intrusions as the brute-force attack techniques or bruteforce very simple to implement to gain administrator access to the target in a short time machine.

On this page you will find a non-exhaustive list of tracks in order to secure your Debian server on different points such as the root account, SSH access, firewall, etc...

Warning : Before making any changes to your system always plan a backup of your files in the event of improper handling.
On a production server, be sure to perform these operations during off-peak hours to minimize the impact of your actions.

Prerequisites

One of the prerequisite essential to the security of his server is to maintain its packages in their version the most up to date as possible. A significant number of discovered flaws are quickly corrected by the developers of packages and applications involved, wherever possible should always retain its system to update and thus to avoid security flaws. Keeping your Debian system up-to-date, make sure you have a list of the official repositories to update. You can find a list of the available at Ikoula repositories and installation instructions at this address.

Root access

Allow connections from account root After the first use is generally not a good idea. Indeed the account root ou superuser has full access to your system.
If an attacker comes to gain access to account superuser It will have total control of your machine.

The command sudo

To reduce the risk you can, for example, add a user who, if necessary, will get the rights of our superuser by using the command sudo.

We first need to create a new user

 adduser votre_utilisateur

Next, fill the fields as well as the password which preferably will be made up of lowercase letters, uppercase letters, and numbers.

We will now install sudo

 apt-get install sudo

Now that our user is created and that sudo is installed it will have to be in the sudo group to use the command

 usermod -a -G sudo votre_utilisateur

From now our user may, if necessary, precede the command you want sudo to run with permissions of superuser .
Password will be asked before you run any command.

 sudo cat /etc/password

Prohibit the root login

Now that we have another user we can for example prevent connecting to our system from the account root.

First you need to edit the configuration of the ssh service file

  vi /etc/ssh/sshd_config

Find and edit the following line in your sshd_config file, by changing the Yes by no. Needed to uncomment the line by deleting the symbol #.

  PermitRootLogin no

Remember then save and close the configuration file.

When the SSH service will be restarted your changes will take effect.

 /etc/init.d/ssh restart

Council : It is recommended that you always keep the SSH terminal as root for the duration of the tests. Indeed mishandling would make the connection to your impossible system.
The opening of a second terminal in order to test the connection and use of the changes on the new user is therefore recommended.

SSH access

Thanks to the solutions previously our system is already well secured, but we can still enhance this security by implementing an authentication key file.
Usually the connection and authentication on your system is performed via a login pair /password. We can replace this method which is not infallible by key authentication.
Once the change implementation during each new connection system will watch if the user attempting to connect has a valid key and if this has permission to perform a login for this user.
Although no method is foolproof authentication key file requires the person wanting to get into the system that it has this file. So, we can strengthen the security versus a password that can be guessed by brute force
Several drawbacks, however, are present when this method is selected, it is imperative to have the key file regardless of the location of the connection, for example between computers at work and at home.
You also need to manually added each new key file which will be allowed access to your system, in the case for example of adding a new user or access by a person authorized to your system.

Change the default port

One of the ways the most effective to stop automatic tests launched against servers is change the default SSH port on your machine. To do this edit your file sshd_config

 vi /etc/ssh/sshd_config

Find and edit the next line of the file by changing the value by one chosen

# What ports, IPs and protocols we listen for
Port 22

Restart the SSH service

 /etc/init.d/ssh restart

Note: Now connect to your machine will be specifying the new port SSH : SSH user @IPAddress -p Votre_port

Generate a key pair

Windows

PuTTYgen sous Windows

You can generate your key from PuTTYgen software available for Windows.

Linux

Under linux you can type the following command :

 ssh-keygen

Copy a key pair

When the pair is generated we must now indicate the server what are persons authorized to connect to our new user. To do this each user of our system has a file ssh/authorized_keys present in the local directory.

If you are currently generate the keypair on your Debian system you can use the following command to automatically copy the key into the file.

 ssh-copy-id votre_utilisateur@IP_VotreServeur

Alternatively you can manually add your public key to the authorized persons file

If the .ssh folder does not exist in our user's local folder we create it

mkdir .ssh
chmod 700 .ssh

Now we need to create a file authorized_keys in our .ssh folder

 vi .ssh/authorized_keys

The public key is then added to the file, the result should be similar to this example

 ssh-rsa AAAB3NzaC1yc2EAAAADAQaSdMTJXMy3MtlQhva+j9CgguyVbU3nCKneB+KjKiS/1rggpFmu3HbXBnWSUdf votre_utilisateur@machine.locale

It saves and closes the file.

For security reasons we will restrict access to our file

 chmod 600 .ssh/authorized_keys

From now our user is allowed to connect to the machine.

Firewall

Using a firewall is strongly recommended to secure your system.
The firewall is often the first line of defense of your machine against the outside, it is indeed him who will analyze the traffic that passes between your machine and the outside.
Thanks to the firewall you are able to block or allow access your machine from the outside to certain protocols or ports, thus ensuring the security of your system.

Security policies

In the case of a firewall it is necessary to define a security policy to be implemented. Without an effective definition the choice of blocking or permission of the ports and protocols would be pretty random.
It is therefore necessary to define in advance a clear policy for the security of its computer network or his machine.

The various policies commonly used include policies of whitelist and de the blacklist .

Whitelist

The principle of the policy of the whitelist is to block all traffic entering without exception and allow explicitly only the ports and protocols that we are absolutely sure of their safety. This security policy has many advantages compared to the blacklist . Indeed all traffic not explicitly allowed will be blocked, this will prevent most connection attempts that we wouldn't have necessarily had the reflex to secure.
One of the disadvantages of this policy is the obligation of having to define each ports or protocols used to do not block execution of our services ( for example the Protocol http on port 80 )We must therefore know each port used by the machine and maintain the rules when adding or deleting a service. Concerning outbound in the majority of cases it is not considered as risky to all authorized, indeed you are supposed to know the traffic leaving your machine or network. However, it is recommended to keep a trace of the outbound security.

Blacklist

The principle of the policy of the blacklist is to allow all incoming traffic without exception and to explicitly block only the ports and protocols which we are sure that they pose a risk to security.
This security policy has many drawbacks compared to the whitelist . Indeed allow all traffic entering without any restriction is not recommended, blocking involved only in the case of a port or explicitly established protocol. Concerning outbound in the majority of cases it is not considered as risky to all authorized, indeed you are supposed to know the traffic leaving your machine or network. However, it is recommended to keep a trace of the outbound security.

IPTables

IPTables is surely the best-known software firewall available for Debian.

Here are a few practical commands concerning :

Installation of iptables

 sudo apt-get install iptables

List the currently established rules

 sudo iptables -L

Purge the established rules

sudo iptables -F
sudo iptables -X

Add a rule

# Autoriser les connexions entrantes sur le port ssh(22) tcp depuis l'adresse ip x.x.x.x par exemple
sudo iptables -A INPUT -p tcp --dport ssh -s x.x.x.x -j ACCEPT

Note: Attention in the case of a dynamic IP address, as your IP will be changed you will be unable to log into SSH on your server !
Use caution when assigning an IP address which could be dynamic, for example that of your internet box at home.

Delete a rule

# Supprimer la règle n°2 de la catégorie OUTPUT
sudo iptables -D OUTPUT 2

Sort by date Sort by score

Enable comment auto-refresher

You are not allowed to post comments.