Now that that our Linux VM is built, we must add security for better server protection; this will be accomplished by using the Linux firewall capabilities. Afterwards, we will install a web server and set up additional security on the web server.

Maintenant que notre machine virtuelle Linux est construite, nous devons augmenter la sécurité pour améliorer la protection du serveur ; ce sera fait en utilisant les capacités du pare-feu Linux. Après cela, on installera un serveur Internet et on y implantera des sécurités additionnelles.

Today we will focus on the Linux firewall. We will use iptables, standard Linux firewall functionality. A Firewall is basically a set of rules. As best practice, we'll use the “deny access” default rule – this means that unless specified otherwise, an incoming network packet will be dropped.

Aujourd'hui nous allons nous concentrer sur le pare-feu Linux. Nous allons utiliser iptables, une interface standard du pare-feu de Linux.

Un pare-feu est essentiellement un ensemble de règles. Nous allons utiliser par défaut la règle « accès refusé » (deny access), c'est-à-dire que, à moins que ce ne soit précisé par ailleurs, un paquet provenant du réseau sera détruit.

External access to our server will be allowed under: • SSH - for remote control • HTTP -server web pages (our website) Right now, anybody can try connecting to our server via SSH. Obviously, that will not be possible without the private key; however, we'd like to limit who can even try to connect to our server – this is just best practice and limits access to any additional potential hacks.

L'accès depuis l'extérieur sur notre serveur sera autorisé sous : • SSH - pour un contrôle à distance. • HTTP - pour les pages Web du serveur (notre site Internet).

En ce moment, n'importe qui peut essayer de se connecter à notre serveur via SSH. Évidemment, ce ne sera pas possible sans la clé privée ; toutefois, nous souhaiterions limiter ceux qui peuvent tout simplement essayer de se connecter à notre serveur ; il ne s'agit que de bonnes pratiques et cela limite les attaques potentielles.

For example – let's suppose you live in the US – it's probably a good idea to allow SSH connections only from the US (any SSH connection attempt from outside the US is not legitimate – it's not you!!! - so it should be banished).

Par exemple, supposons que vous habitiez aux États-Unis – il est probablement judicieux de ne permettre des connections SSH qu'en provenance des États-Unis (toute connexion SSH provenant de l'extérieur des US est douteuse – ce n'est pas vous !!! - elle doit donc être bloquée).

In addition, we may decide we will not do business with specific countries – we will block any web access (HTTP) from these countries. In my example, I will choose Canada (note here – this is only an example, there is absolutely nothing wrong with Canada what.so.ever – I am just choosing a country which is a Democracy, this way, I know I won't get into trouble!!!).

De plus, il se peut que vous décidiez de ne pas faire d'affaires avec des pays précis ; nous allons donc bloquer tout accès internet (HTTP) depuis ces pays. Dans mon exemple j'ai choisi le Canada (notez bien, il s'agit seulement d'un exemple, il n'y a aucun problème d'aucune sorte avec le Canada - j'ai juste choisi un pays démocratique, car je sais ainsi que je n'aurai pas d'ennuis !!!).

Please note that checking the incoming country is not foolproof – the source connection can spoof the IP address (or just VPN into a server from an unblocked country). Anyway – this is good protection against automatic bot scanners and will definitely help keep hackers away. Without getting into too much detail, the firewall rules can be set for incoming, outgoing, and forward connections.

Notez cependant que le contrôle du pays de provenance n'est pas absolument sûr. La connexion initiale peut utiliser une fausse adresse IP (ou passer par VPN dans un serveur situé dans un pays autorisé). Néanmoins, c'est une bonne protection contre les robots scanneurs et cela aidera de toute façon à éloigner les pirates.

Sans aller trop dans le détail, les règles du pare-feu peuvent être établies pour les connexions entrantes, sortantes et les transferts de connexion.

Since we are not forwarding anything, we will just set rules for incoming (most important), outgoing (more later on why) and ignore forwarding (by default forwarding is disabled in the kernel anyway).

Comme nous ne transférons rien, nous allons juste établir des règles pour le trafic entrant (le plus important) et le trafic sortant (j'expliquerai tout à l'heure pourquoi) et nous ignorerons le transfert (par défaut le transfert est désactivé dans le noyau de toute façon).

Step by step now Quick reminder: only sudo (or root) can set up firewall rules. To switch to root, I recommend typing: sudo su

Étape par étape maintenant :

Petit rappel : seul sudo (ou root, l'administrateur) peut établir les règles du pare-feu. Pour passer en root, je recommande de taper :

sudo su

1 – Reset any firewall rule and DROP any incoming connections: Most distributions come with some type of firewall rules set up by default. (Centos & Suse do for sure – not totally sure about Ubuntu). We will reset any rules so we can start from scratch: iptables -F iptables -X And by default DROP any incoming connections: iptables -P INPUT DROP

1 – réinitialiser le pare-feu et bloquer TOUT le trafic entrant :

La plupart des distributions sont livrées par défaut avec quelques règles de pare-feu (certainement pour ce qui concerne CentOS et Suse, j'en suis moins sûr pour Ubuntu).

Nous allons effacer toutes les règles pour pouvoir repartir de zéro :

iptables -F

iptables -X

Et par défaut nous allons bloquer (drop) tout trafic entrant :

iptables -P INPUT DROP

2 – Allow local connections (to localhost):

2 – Nous allons autoriser les connexions locales (à localhost) :

iptables -A INPUT -i lo -p all -j ACCEPT

iptables -A INPUT -m state –state RELATED,ESTABLISHED -j ACCEPT

3 – Block incoming connection if it originates from a specific country: There are several ways to check the country-of-origin of an incoming connection: • iptables geoip • loading country blocks into ipset iptables with geoip is based on xtables-addons, which is an extension of iptables. This works pretty well. However, it's not really a “standard” - meaning xtables is not delivered with some distributions (requires compile from sources & install). For example, I was unable to make this work with Arch Linux on ARM architecture (not saying it is not working, just saying I was unable to make it work – big difference!).

3 – Bloquer le trafic entrant s'il provient d'un pays donné.

Il y a plusieurs manières de vérifier le pays d'origine d'un trafic entrant :

• iptables geoip, • charger les blocs d'identification de pays dans ipset.

iptables avec geoip est basé sur xtables-addons qui est une extension de iptables. Cela fonctionne assez bien. Toutefois ce n'est pas vraiment « standard », je veux dire par là que xtables n'est pas fournie avec toutes les distributions (il faut, dans certains cas, compiler les sources et l'installer). Par exemple, j'étais incapable de faire ce travail avec Arch Linux sur des architectures ARM (je ne veux pas dire que ça ne fonctionne pas, mais juste que je n'étais pas capable de le faire fonctionner, grosse différence !).

ipset is a companion application to iptables – it can load in-memory ranges of IP addresses, and iptables can leverage ipset to test if an IP is within this range. As geo-localization, I will choose ipset – which seems to be available as a packaged install to any distribution I have tried so far.

ipset est une application qui fonctionne avec iptables – elle peut charger en mémoire des plages d'adresses IP et iptables peut charger ipset de vérifier si une adresse IP est à l'intérieur de cette plage.

Donc, pour géo-localiser, j'utiliserais ipset - qui semble disponible dans toutes les distributions que j'ai essayées jusqu'ici.

sudo apt-get install ipset

Let's summarize what we want to achieve here: • Get the IP range block we want to forbid (country based). • Load that range into ipset. • Add an iptable rule which checks if source is within that range (Canada in our example). • If yes, block. • If not: • • Allow if target is HTTP (a web page). • • If target is SSH, we must also check country of origin is USA (same as above – with ipset). I hope you follow me here!!!

Résumons ce que nous cherchons à faire :

• Obtenir les plages d'adresses IP que nous voudrions interdire (basées sur les pays). • Charger ces plages dans ipset. • Ajouter une règle iptable qui vérifie que le pays d'origine est à l'intérieur de cette plage (le Canada dans notre exemple). • Si oui, bloquer. • Sinon : • • Permettre si la cible est HTTP (une page Internet). • • Si la cible est SSH, on doit alors aussi vérifier que le pays d'origine est USA (de la même façon que ci-dessus, avec ipset).

J'espère que vous me suivez jusque-là !!!

IP blocks by country can be found here: http://www.ipdeny.com/ipblocks/data/aggregated We'll get the blocks of US and Canada – either download the file or use wget: wget http://www.ipdeny.com/ipblocks/data/aggregated/ca-aggregated.zone wget http://www.ipdeny.com/ipblocks/data/aggregated/ca-aggregated.zone Now load the blocks into ipset's memory: Create an ipset bucket called myset_CANADA: ipset create myset_CANADA hash:net

Les blocs d'adresse IP par pays se trouvent ici :

http://www.ipdeny.com/ipblocks/data/aggregated

On obtiendra les blocs des USA et du Canada soit en téléchargeant le fichier, soit en utilisant wget :

wget http://www.ipdeny.com/ipblocks/data/aggregated/us-aggregated.zone

wget http://www.ipdeny.com/ipblocks/data/aggregated/ca-aggregated.zone

Maintenant, chargeons ces blocs dans la mémoire d'ipset :

Créons une variable ipset appelée myset_CANADA :

ipset create myset_CANADA hash:net

Load the blocks corresponding to Canada into myset_CANADA: for i in (cat ca-aggregated.zone); do ipset add myset_CANADA $i; done Same for US block range: ipset create myset_US hash:net for i in (cat us-aggregated.zone); do ipset add myset_USA $i; done

Chargeons les blocs correspondant au Canada dans myset_CANADA :

for i in (cat ca-aggregated.zone); do ipset add myset_CANADA $i; done

idem pour les USA :

ipset create myset_US hash:net

for i in (cat us-aggregated.zone); do ipset add myset_USA $i; done

Now we'll block anything coming from Canada (conjunction of iptables & ipset): iptables -A INPUT -m set –match-set myset_CANADA src -j DROP If the rule above is hit, the connection is dropped (-j DROP does that) and we exit the firewall.

Maintenant nous allons bloquer tout ce qui vient du Canada (croisement de iptables et ipset) :

iptables -A INPUT -m set –match-set myset_CANADA src -j DROP

Si la règle ci-dessus est satisfaite, nous bloquons le trafic entrant (c'est le rôle de -j DROP) et nous sortons du pare-feu.

4 – If we get up to here in the firewall chain We can accept any HTTP incoming connections: iptables -A INPUT -p tcp –dport 80 -j ACCEPT If rule above is hit (meaning “true”), the request is accepted (-j ACCEPT) and we exit the firewall.

4 – Si nous arrivons jusque-là dans l'exécution du pare-feu

Nous pouvons accepter toute requête entrante HTTP :

iptables -A INPUT -p tcp –dport 80 -j ACCEPT

Si la règle ci-dessus est satisfaite, la requête est acceptée (-j ACCEPT) et nous sortons du pare-feu.

5 – If we get to here The source is not coming from Canada and it’s not an HTTP request. If the request in not SSH, drop the request and exit the firewall: iptables -A INPUT -p tcp ! –dport 22 -j DROP

5 – Si nous arrivons jusqu'ici

La source ne vient pas du Canada et ce n'est pas une requête de type HTTP. Si la requête n'est pas du type SSH, il faut la bloquer et sortir du pare-feu :

iptables -A INPUT -p tcp ! –dport 22 -j DROP

6 – If we've got this far It is a SSH request (and not from Canada). Let's check if the source country is allowed (USA in our example). Before accepting, let's write into the system log that access to port 22 has been granted. We will log this information into /var/log/messages (default system log file). Logging is important for security reasons – by running statistics on /var/log/messages you will find out who tried to access your system. Note that we do not track who has connected but who tried to connect: iptables -A INPUT -j LOG –log-prefix “Accepted SSH ” –log-level 7 iptables -A INPUT -m set –match-set myset_USA src -j ACCEPT

6 – Si nous sommes arrivés jusque-là

C'est une requête de type SSH (qui ne vient pas du Canada). Vérifions que le pays d'origine soit autorisé (USA dans notre cas).

Avant de l'accepter, écrivons dans le system log (le journal système) qu'un accès a été autorisé sur le port 22. Nous allons enregistrer cet événement dans /var/log/messages (le fichier par défaut de l'enregistrement des événements système). L'enregistrement est important pour des raisons de sécurité. En faisant des statistiques sur /var/log/messages, on verra qui a essayé d'accéder au système. Notons que nous ne suivons pas qui s'est connecté au système, mais qui a essayé de se connecter :

iptables -A INPUT -j LOG –log-prefix “Accepted SSH ” –log-level 7

iptables -A INPUT -m set –match-set myset_USA src -j ACCEPT

Just in case we missed anything, any connection arriving to the command above will be dropped (remember – we drop everything by default unless specified otherwise): iptables -A INPUT -j DROP

Au cas où nous aurions raté quelque chose, chaque connexion arrivant sur la commande ci-dessus sera bloquée (rappelez-vous : nous bloquons tout par défaut à moins que ce ne soit spécifiquement mentionné).

iptables -A INPUT -j DROP

It’s not mandatory – but we can add some additional security to the above rules. Let's imagine that somebody really wants to hack your system by trying every combination of RSA key possible – that is called a brute-force-attack. No worries – with a 10K RSA key, it is probably not possible (note the word probably – when talking security, you cannot ever be sure!). There is something we can do about that – if a specific IP tries to connect more than x times (let's make it 5) to our server on port 22, we can temporarily ban that IP address for a few minutes – let's make it 5 (300 seconds). So this means that an attacker can potentially try 5 combinations every 5 minutes. As you probably understand, brute force will not work at this pace!!!

Ce n'est pas obligatoire, mais nous pouvons ajouter quelques sécurités additionnelles aux règles ci-dessus.

Imaginons que quelqu'un veuille attaquer notre système en essayant toutes les combinaisons possibles de clés RSA – cela s'appelle une attaque par force brute. Pas de problème. Avec une clé RSA de 10 K, c'est très improbable (remarquez le mot probable, en termes de sécurité on ne peut jamais être sûr !)

On peut faire quelque chose contre cela : si une adresse IP spécifique essaie de se connecter plus de x fois (disons 5) à notre serveur sur le port 22, nous pouvons temporairement interdire cette adresse IP pendant quelques minutes, disons 5 (300 secondes). Ça veut donc dire pratiquement qu'un attaquant peut essayer 5 combinaisons toutes les 5 minutes. Comme vous le comprendrez certainement, la force brute sera inopérante à ce rythme !!!

Below, we're telling iptables to keep track of connections to port 22 for 300 seconds. If a (failed) hit count gets to 5, the connection is denied for the next 5 minutes: iptables -A INPUT -p tcp -m tcp –dport 22 -m state –state NEW -m recent –set –name DEFAULT –rsource iptables -A INPUT -p tcp -m tcp –dport 22 -m state –state NEW -m recent –update –seconds 300 –hitcount 5 –name DEFAULT –rsource -j DROP

Ci-dessous, nous disons à iptables de conserver une trace des connexions sur le port 22 pendant 300 secondes. Si le nombre de requêtes (qui n'ont pas abouti) arrive à 5, alors le trafic [Ndt : pour cette IP] est rejeté pendant 5 minutes :

iptables -A INPUT -p tcp -m tcp –dport 22 -m state –state NEW -m recent –set –name DEFAULT –rsource

iptables -A INPUT -p tcp -m tcp –dport 22 -m state –state NEW -m recent –update –seconds 300 –hitcount 5 –name DEFAULT –rsource -j DROP

Then, follow these with the same block-rules as before: iptables -A INPUT -j LOG –log-prefix “Accepted SSH ” –log-level 7 iptables -A INPUT -m set –match-set myset_USA src -j ACCEPT iptables -A INPUT -j DROP Careful – this rule also applies to yourself!

On fait suivre cela du même ensemble de règles que précédemment :

iptables -A INPUT -j LOG –log-prefix “Accepted SSH ” –log-level 7

iptables -A INPUT -m set –match-set myset_USA src -j ACCEPT

iptables -A INPUT -j DROP

Attention : cette règle s'applique aussi à vous !

More about logging and checking who tried to access the system… This command will display any SSH connection attempt to your system: cat /var/log/messages | grep “Accepted SSH” You will quickly get a hefty output (“quickly” means minutes of server up-time), which will not be easy to read.

Allons plus loin dans la liste et la vérification de ceux qui ont cherché à se connecter au système…

Cette commande va afficher toutes les tentatives de connexion à votre système :

cat /var/log/messages | grep “Accepted SSH”

Cela vous donnera très rapidement (« rapidement » voulant dire après quelques minutes d'utilisation du serveur) une très longue liste qui ne sera pas facile à lire.

This revised version is probably more useful and will give the list of unique IP attempts – sorted by number of connection attempts: cat /var/log/messages | grep “Accepted SSH” | awk -FSRC= '{print $2}' | awk '{print $1}' | sort | uniq -c | sort -n A quick explanation of above command: • It outputs the content of the file /var/log/messages. • It keeps only lines where the keywords “Accepted SSH” exist. • It grabs the text following the keyword SRC= (IP address of incoming connection). • It sorts the list. • It gets only the unique IPs, but counts the number of occurrences of each unique IP. • It sorts descending as numbers (sort -n).

Cette version modifiée est certainement plus utile et vous donnera la liste des adresses IP qui ont tenté de se connecter, classée par nombre de tentatives de connexion :

cat /var/log/messages | grep “Accepted SSH” | awk -FSRC= '{print $2}' | awk '{print $1}' | sort | uniq -c | sort -n

Une rapide explication de cette commande :

• Elle affiche le contenu du fichier /var/log/messages.
• Elle ne conserve que les lignes où les mots clés « Accepted SSH » existent.
• Elle récupère le texte qui suit le mot clé « SRC= » (adresse IP de la connexion entrante).
• Elle ordonne la liste.
• Elle ne conserve que les adresses IP uniques, mais compte le nombre d’occurrences de chaque IP.
• Elle classe les nombres par ordre décroissant (sort -n).

The goal of this article is firewall and security. However, I strongly believe that security and scripting go hand-in-hand. Logging intrusion attempts is great but not using the data is useless. As you can see, a quick shell command was able to provide very useful information – extremely quickly. I can now, for example, ban the topmost 10 IPs who tried to log in to my system.

Le sujet de cet article est le pare-feu et la sécurité. Toutefois, je crois fermement que la sécurité et l'écriture de scripts vont de pair. Identifier les tentatives d'intrusion est parfait, mais le faire sans utiliser les données correspondantes ne sert à rien. Comme vous l'avez constaté, une commande shell rapide a pu nous fournir des informations extrêmement intéressantes, très rapidement. Je peux maintenant, par exemple, bloquer les 10 adresses IP qui ont essayé de s'introduire dans mon système le plus fréquemment.

The following command will ban the IP 10.10.10.10 by inserting the rule on top of all rules (-I INPUT 1): iptables -I INPUT 1 -s 10.10.10.10 -j DROP Have fun and please make sure not to ban… yourself!

La commande suivante va interdire l'adresse IP 10.10.10.10 en insérant cette règle en haut de la liste de toutes les autres.

iptables -I INPUT 1 -s 10.10.10.10 -j DROP

Amusez-vous et surtout faites attention de ne pas interdire… votre propre adresse !

7 – Output rules: Many times, firewalls will enforce rules only for incoming connections – meaning they’ll allow wide-open output traffic. This is not a good practice – imagine that a hacker gets to your computer and is able to install server software which could then create a tunnel via a random port to the attacker's server and therefore provide full access to the attacker. We will also close this loophole. Basically we will allow outgoing access to: • SSH (for our remote access), this is TCP port 22. • HTTP and HTTPS (for web pages), these are ports 80 and 443. • DNS (so our requests can be resolved!), this is port 53.

7 – Règles concernant le trafic sortant

Très souvent, les pare-feu ne mettent en place des règles que pour le trafic entrant – ce qui signifie qu'ils ouvrent grandes les portes du trafic sortant. Ce n'est pas une bonne façon de faire ; imaginez qu'un pirate s'introduise dans votre ordinateur et arrive à installer un logiciel serveur qui pourra alors créer un tunnel, via un port aléatoire, jusqu'au serveur de l'attaquant et lui fournir ainsi l'accès complet à votre système.

Nous allons donc combler cette lacune aussi. Nous allons principalement donner accès au trafic sortant à :

• SSH (pour notre accès à distance), c'est le port TCP 22.
• HTTP et HTTPS (pour les pages Internet), ce sont les ports 80 et 443.
• DNS (pour que nos requêtes puissent aboutir !), c'est le port 53.

You probably got the point: • By default, DROP any output connections, unless we specifically tell otherwise. • Allow connection to localhost (the server itself). • Allow SSH, DNS, HTTP & HTTPS.

Vous avez probablement déjà compris :

• Par défaut, bloquer tout trafic sortant, à moins que nous ne l'autorisions spécifiquement.
• Permettre des connexions à l'hôte local (le serveur lui même).
• Permettre SSH, DNS, HTTP et HTTPS.

iptables -P OUTPUT DROP

iptables -A OUTPUT -o lo -p all -j ACCEPT

iptables -A OUTPUT -m state –state RELATED,ESTABLISHED -j ACCEPT

iptables -A OUTPUT -p tcp –dport 22 -j ACCEPT

iptables -A OUTPUT -p udp –dport 53 -j ACCEPT

iptables -A OUTPUT -p tcp –dport 53 -j ACCEPT

iptables -A OUTPUT -p tcp –match multiport –dports 80,443 -j ACCEPT

iptables -A OUTPUT -j DROP

Let's put all this together… First build the block of IP addresses. Run all below as root (or sudo):

Passons à la pratique…

D'abord construisons le bloc d'adresses IP. Il faut tout exécuter en tant qu'administrateur (root ou sudo) :

apt-get install ipset

wget http://www.ipdeny.com/ipblocks/data/aggregated/ca-aggregated.zone

wget http://www.ipdeny.com/ipblocks/data/aggregated/us-aggregated.zone

Now let's clean all firewall rules:

Maintenant il faut nettoyer toutes les règles existantes du pare-feu :

iptables -X

And make sure all rules were really deleted – you should see this:

Et s'assurer que toutes les règles ont bien été effacées. Vous devez voir cela :

Then add the firewall rules in a text file (see box on next page). In order to test this out, I would recommend the following: • Use wget to get the blocks of IPs, and keep the files. • Copy / paste the code above to a shell file (text file with extension .sh and make it executable with chmod +x [filename]). • Run the file. For my example, I'll call this file /usr/local/sbin/firewall.sh

Vous devez alors écrire toutes les règles du pare-feu dans un fichier texte (voir l'encadré page suivante).

De façon à tester tout ceci, je recommanderais les choses suivantes : • Utilisez wget pour obtenir les blocs d'IP et conservez les fichiers. • Copiez/collez les codes ci-dessus dans un fichier shell (un fichier texte portant l'extension .sh et rendez-le exécutable avec l'instruction chmod +x [nom du fichier]). • Exécutez le fichier. Dans mon exemple, je l'ai appelé /usr/local/sbin/firewall.sh

You should now have the firewall fully loaded and operational. IMPORTANT – iptables -F resets the firewall and locks your ssh session out! When you run the file, your terminal will be “locked”. This is because we reset the firewall by blocking all rules by default. Just try connecting again to iceberg from another terminal. If it works – you should be all set, but, if you cannot, stop and restart the VM from the Digital Ocean panel. After the restart, the rules are not loaded, so you can fix that problem: For example, I allowed the US IP blocks because I live in the US, did you load the right blocks of IPs from where you live?

Maintenant le pare-feu doit être entièrement chargé et opérationnel.

IMPORTANT – iptables -F remet le pare-feu à zéro et ferme votre session SSH !

Quand vous lancez le fichier, votre terminal sera « verrouillé ». Cela est dû à la ré-initialisation du pare-feu en bloquant toutes les règles par défaut. Essayez juste de vous reconnecter à Iceberg depuis un autre terminal. Si cela fonctionne, vous devriez être opérationnel, mais, si vous n'y arrivez pas, arrêtez et redémarrez la machine virtuelle (VM) à partir du panneau de Digital Ocean. Après le redémarrage, les règles ne sont pas chargées et vous pouvez donc résoudre le problème : par exemple, j'ai permis le bloc d'adresses IP des USA parce que j'habite aux USA, mais vous, avez-vous bien chargé le bloc d'adresses IP de l'endroit où vous vivez ?

I will now suppose everything worked well – we will then set both scripts to run at startup. In ubuntu 14.04, edit and add both files to /etc/rc.local (shown below).

Je vais maintenant supposer que tout s'est bien passé. Nous allons ensuite mettre en place les deux scripts qui doivent s'exécuter au démarrage.

Dans Ubuntu 14.04, éditez et ajoutez les deux fichiers à /etc/rc.local (voir plus bas).

Note the sleep 10 – we're telling iceberg to wait 10 seconds before running our scripts – this is to ensure that the network is up & running before we set up the firewall. I know a few of you may find the sleep 10 not optimal and would rather use upstart's dependencies rules. I personally think it is too much trouble and safe enough (even if somebody connects in those 10 seconds, he'd be locked by the iptables -F) – not to mention that upstart seems to be end-of-life software (even Canonical decided to switch to systemd in newer Ubuntu versions – this doesn't mean I support or not systemd, I am just noting Canonical’s decision).

Notez l'instruction sleep 10 : nous disons à Iceberg d'attendre 10 secondes avant de lancer nos scripts, c'est pour s'assurer que le réseau est en place et fonctionne avant que nous ne paramétrions le pare-feu.

Je sais qu'un certain nombre d'entre vous n'apprécieront pas le sleep 10 et préféreront utiliser les règles des dépendances de l'upstart. Personnellement ça me semble trop compliqué et le sleep 10 est suffisamment sûr (même si quelqu'un se connecte durant ces 10 secondes, il sera bloqué par le iptables -F) – il est à noter aussi que le logiciel upstart semble être en fin de vie (même Canonical a décidé de basculer sur systemd dans les nouvelles versions d'Ubuntu – ce qui ne signifie pas que je suis partisan ou non de systemd, je précise juste que c'est la décision de Canonical).

Anyway, during your next reboot, you should be automatically all set, with a system pretty well protected against intrusions. If you'd like to confirm the scripts have been properly executed at startup, as root run this: iptables -L and you should get the firewall rules displayed on the screen. Next month, we will install Apache (Web server) and secure Apache.

De toute façon, lors de votre prochain démarrage, vous devriez être automatiquement bien réglé avec un système plutôt bien protégé contre les intrusions.

Si vous voulez vous assurer que les scripts on été correctement exécutés, lancez cette instruction comme administrateur (root) :

iptables -L

Et vous devriez voir les règles du pare-feu apparaître à l'écran.

Le mois prochain, nous installerons Apache (le serveur Internet) et nous le sécuriserons.