This issue I’d like to talk more about firewalls. This all stems form a few Telegram chats I’ve had with some of you. Let me start with how to see existing firewall rules. Usually, when working with firewall rules, you need to be root. So remember to use sudo (see image bottom left). sudo iptables -L You should see an INPUT, a FORWARD and an OUTPUT. What you are seeing is the default filter, so it would be the same as typing: sudo iptables -t filter -L (see image bottom right). I am not showing you guys the whole thing, as I have docker installed and that adds another section and I do not want to confuse you, so you do yours and we work from there.

Dans ce numéro, j’aimerais continuer ma discussion sur les pare-feux. Tout cela vient de quelques conversations que j’ai eues sur Telegram avec quelques-uns d’entre vous. Je vais démarrer en vous expliquant comment voir les règles existantes d'un pare-feu. Généralement, quand on travaille avec les règles du pare-feu, il faut être root ; il faut donc se souvenir d'utiliser sudo (voir l'image en bas à gauche).

sudo iptables -L

Vous devriez voir un INPUT un FORWARD et un OUTPUT. Ce que vous voyez est le filtre par défaut et ce serait donc la même chose que si vous aviez tapé : sudo iptables -t filter -L (voir l'image en bas à droite).

Je ne vous en montre pas le tout, car, chez moi, docker est installé et cela ajoute une autre section. Je ne veux pas vous embrouiller, alors faites le vôtre et nous continuerons à partir de cela.

Because I’m in a virtual machine here, I use NAT, network address translation. We can look at that table too. It differs in that you should see the standard INPUT, FORWARD and OUTPUT, as well as PREROUTING and POSTROUTING. I’ve shown you how to check a table name (we checked the table named filter), so please go ahead and check the table named nat. Well done if you did it! In my book you are no longer a total newbie. If you did not manage to figure it out, take the previous command and substitute the word “filter” for “nat”. If you had set up port forwarding, you would see PREROUTING containing some address and port. I do not have anything like that set up. If you are a gamer, chances are you do (see image above). We are not doing an in-depth look here, I just want newbies to recognise the patterns. When you look up the man page for iptables, you may notice a few more tables listed. Go ahead and try out these tables and see what you end up with and if you can make any sense of it. Trust me on this, doing is best. Use your VM so you don’t break anything by accident.

Puisque j’utilise une machine virtuelle ici, j’utilise NAT, network address translation (« traduction d’adresse réseau »). Nous pouvons regarder cette table-là aussi. Elle est différente, car en plus des standards INPUT, FORWARD et OUTPUT, il y a PREROUTING et POSTROUTING. Je vous ai déjà montré comment vérifier un nom de table (nous avons vérifié la table appelée « filter »), alors veuillez vérifier la table nommée nat. Bravo, si vous l’avez fait ! Pour moi, vous n’êtes plus un débutant total. Si vous n’avez pas compris comment le faire, prenez la commande précédente et y mettez « nat » à la place de « filter ». Si vous avez configuré le transfert de port, vous verrez que PREROUTING contient une adresse et un port. Je n’ai rien configuré de tel chez moi, mais, si vous êtes joueur, il y a des chances que vous l’ayez fait (voir l'image ci-dessus).

Nous n’approfondissons pas les choses ici, je veux tout simplement que les débutants reconnaissent l’organisation des choses. Quand vous allez à la page man pour iptables, vous pourriez remarquer que quelques autres tables sont listées. Allez-y et essayez ces tables-là, regardez les résultats et essayez de les comprendre. Faites-moi confiance, faire les choses vous-même, c’est ce qu’il y a de mieux. Utilisez votre VM pour ne rien casser accidentellement.

I trust that you noticed that each of these has (policy ACCEPT) in parenthesis. This means that if a rule is not in our list, this is the elif. In other words, a fallback. Now a lot of the time, when newbies do not understand firewall rules, they start with (policy DROP). Don’t do that unless you are an advanced Linux user. Something I often see if I scroll through the command history is: sudo iptables -A INPUT -p tcp - -dport 22 j DROP What this usually means, is that someone new to firewalling, has read up on Fail2ban or some such and copied commands without understanding what they mean.

J'ose penser que vous avez remarqué que chacun comporte entre parenthèses « (policy ACCEPT) ». Cela veut dire que, si une règle ne se trouve pas dans notre liste, il s’agit du elif. En d’autres termes, une position de repli. Il se trouve que, quand les bleus ne comprennent pas les règles du pare-feu, ils commencent par (policy DROP). Ne le faites pas à moins d’être un utilisateur avancé de Linux. Ce que je vois souvent quand je parcours l’historique des commandes est : sudo iptables -A INPUT -p tcp – dport 22 j DROP

Ce que cela signifie la plupart du temps, c'est que quelqu’un qui ne connaît pas les pare-feux a lu un truc sur Fail2ban ou autre et a copié des commandes sans les comprendre.

Let’s quickly dissect that line, shall we? The sudo iptables is a given, the -A is for adding a rule, the -p is for the protocol, in this case, tcp and dashdash (Office packages and two dashes are not friends )dport is for destination port, in this case 22, then the j is for jump to and the action is DROP. This means that all tcp traffic on port 22 will now be dropped, but not udp traffic. This means that you may now notice that you can no longer transfer files via sctp. It may all be good, until 5 months down the line, you need to transfer a file and now you cannot. (Now comes the swearing like you saw in the previous issue. This is why companies have change requests that need to be signed off and documented, as you can see how this can become a huge problem, when multiple people are involved.) As we have demonstrated and you hopefully mimicked, you have realised that it is not hard to understand the syntax, and it is not hard to add rules, but you also need to understand what the rule you just implemented does or what it affects.

Analysons cette ligne-là rapidement, voulez-vous ? Le « sudo iptables » est attendu, le -A est pour l’ajout d’une règle, le -p est pour le protocole, dans ce cas, tcp, et le tiret tiret (les paquets d’Office et le « deux tirets » ne sont pas amis) dport est pour le port de destination, dans ce cas 22, puis le j est pour « jump to » (sauter vers) et l’action est DROP. Cela signifie que tout le trafic tcp sur le port 22 sera maintenant abandonné, mais pas le trafic udp. Ce qui signifie que vous pourriez remarquer maintenant que vous ne pouvez plus transférer des fichiers via stcp. Tout peut sembler comme il faut, jusqu’à ce que, 5 mois plus tard, vous deviez transférer un fichier et vous n’y arriviez pas. (Maintenant pour les gros mots comme ceux que vous avez vu le mois dernier. C’est pourquoi les entreprises ont des requêtes de changement qui doivent être documentées et approuvées. En effet, vous pouvez comprendre comment le problème pourra grossir énormément quand plusieurs personnes sont impliquées.)

Comme nous l'avons montré et, je l’espère, que vous l'avez imité, vous vous êtes rendu compte qu’il n’est pas difficile de comprendre la syntaxe et qu’il n’est pas difficile d’ajouter des règles, mais il faut également comprendre ce que fait la règle que vous venez d’implémenter ou sur quoi elle agit.

On the other side of the coin, if you set your default policy to DROP, and you work on allow lists, all it takes, is someone to accidentally flush your rules. It is as simple as: sudo iptables -F. Though this clears all the rules, it does not reset the defaults back to the original defaults. This is another issue I have come across with novices, hence why I said not to start with DENY unless you understand 100% what you are doing. This is really, really important when working with remote machines, that you do not have physical access to. I have had to drive like an hour to the data centre enough times to know not to do this. Making an appointment to see your own server with blood and urine samples is not fun at all, specially if someone else did this. Victor, if you ever read this, know I’m referring to you… . If all of this was not scary enough as it is, realise that there are dynamic ports and you will have to check RELATED traffic as well, but that is a topic for another day. Internalise this chunk we talked about, it isn’t much, but without training your eyes and your brain, you will miss the small things and firewall configurations are all about the small things.

En revanche, si vous réglez DROP comme défaut et que vous travaillez sur des listes de choses permises, il suffit que quelqu’un « flush » (supprime) vos règles par accident. C’est aussi simple que : sudo iptables -F. Bien que cela supprime toutes les règles, ça ne remet pas les défauts aux défauts d’origine. C’est un autre problème que j’ai rencontré chez les novices, ce qui explique pourquoi j’ai dit de ne pas démarrer avec DENY à moins de comprendre ce que vous faites à 100 %. Cela est vraiment, vraiment important quand vous travaillez avec des machines à distance, auxquelles vous n’avez pas un accès physique. J'ai dû conduire pendant à peu près une heure jusqu'au centre des données suffisamment de fois pour savoir qu'il ne faut pas le faire. Prendre rendez-vous pour voir votre propre serveur avec des échantillons de sang et d’urine n’est pas amusant du tout, surtout si quelqu’un d’autre est le coupable. Victor, si jamais tu lis ceci, sache que je parle de toi… . Si tout cela ne fait pas assez peur tel quel, rendez-vous compte qu’il y a des ports dynamiques et que vous devrez également vérifier le trafic RELATED, mais c’est un sujet pour un autre jour. Interiorisez ce gros bloc dont nous venons de parler, ce n’est pas grand’chose, mais, sans entraîner vos yeux et votre cerveau, vous manquerez les petites choses et les configurations de pare-feu concernent surtout ces petites choses.

TIP: If you are learning, my advice to you is, play on a virtual machine on your system first and do whatever you need to and test if you can access it remotely, before mirroring your changes on a remote server. Set your history to 1000 lines, if you accidentally flush your rules, you can add them from history. Train your eye to look for DENY default rules. Remember that a server serves, it cannot do that if you deny all traffic. Sure, the intruders cannot get in, but neither can your clients. (if you would like to see this in action, look at the Digital Ocean forums, where devs have locked themselves out of their VPS’s, every other day!) If you think we helped you wrong, misc@fullcirclemagazine.org Ref: man iptables Suggested reading https://www.geeksforgeeks.org/50-common-ports-you-should-know/

ASTUCE : Si vous êtes en train d’apprendre tout ceci, je vous conseille de bricoler d’abord sur une machine virtuelle sur votre système ; faites le nécessaire et essayez d'y accéder à distance avant de réfléchir vos changements sur un serveur à distance. Réglez votre historique à 1 000 lignes, car, si vous supprimez vos règles par accident, vous pouvez les rajouter à partir de l’historique. Entraînez votre œil à chercher les règles DENY par défaut. Rappelez-vous qu'un serveur sert des choses et qu’il ne peut pas le faire si vous refusez tout le trafic. Bien sûr, les intrus ne peuvent pas y entrer, mais vos clients non plus. (Si vous voulez voir cela pour de vrai, regardez les forums de Digital Ocean, où des développeurs ne peuvent pas entrer dans leur VPS parce qu’ils les ont verrouillés, tous les deux jours !)

Si vous pensez que nous vous avez été mal aidé, misc@fullcirclemagazine.org

Réf : man iptables

Suggestion de lecture :

https://www.geeksforgeeks.org/50-common-ports-you-should-know/