Pare feu iptable et c’est tout

Tito · 04-07-2018 19:12:39

Jean-Pierre Pinson a écrit :

bendia a écrit :
Par ailleurs, si tu relis le reste de la discussion du dessus, le firewall pour se protéger (de quoi ?) sur le PC de Mamie, en particulier sous Linux, ben ça ne semble pas servir à grand chose

oui sur le PC de Mamie, en particulier sous Linux, ça ne semble pas servir à grand chose, quoi que.....Enfin bref. En revanche Pour celui qui utilisent un serveur ssh (C'est mon cas) Il est sûrement utile, de connaître le fonctionnement du réseau et de iptable etc....Et j'avoue que c'est particulièrement difficile à comprendre pour moi. Je ne sais pas si c'est facile à expliquer de manière simple, et compréhensible, à quelqu'un qui n'a pas forcément beaucoup de connaissances en informatiques, mais en tout cas, je trouve que ça vaudrait le coup d'essayer.

@JPP: Iptables ne protègent pas, il filtre des paquets ! Iptables est un truc pour sysadmin qui comprend un peu se programme, il est très souple et puissant quand tu le maîtrises. C'est pour cela qu'un front-end a vu le jour, il s'appelle ufw et pour les allergiques au terminal, gufw.
La doc est ton meilleur ami : https://www.inetdoc.net/guides/iptables … ering.html
Par ailleurs, je t'invite à regarder les fichiers /etc/hosts.deny et /etc/hosts.allow. Pour ton histoire de serveur ssh, une authentification par clé permet d'être serein ! Exemple: https://www.sylvaindurand.fr/authentifi … -avec-ssh/ . Dans ce cas, fail2ban et Iptables ne servent à rien !

Philou92 · 04-07-2018 21:04:40

Tito a écrit :

. Pour ton histoire de serveur ssh, une authentification par clé permet d'être serein !

Pas vraiment. Il suffit d'attaquer le mot de passe de la machine cliente pour compromettre ensuite le serveur.

L'identification par mot de passe et un fail2ban bien configuré constitue un barrage efficace permet d'être prévenu en cas d'attaque.

Jean-Pierre Pinson · 05-07-2018 10:46:47

Philou92 a écrit :

Pas vraiment. Il suffit d'attaquer le mot de passe de la machine cliente pour compromettre ensuite le serveur.

L'identification par mot de passe et un fail2ban bien configuré constitue un barrage efficace permet d'être prévenu en cas d'attaque.

Bonjour Philou92

J'ai cru comprendre aussi que iptable doit être bien configuré pour que fail2ban fonctionne bien, pourrais-tu apporter un peu de lumière sur tout ça, et pourquoi pas, nous faire un petit tuto qui expliquerai ça de manière assez simple ? Je pense que nous t'en serions tous reconnaissants

celp · 05-07-2018 10:56:49

Fail2ban fait le boulot tout seul à condition que ton firewall bloque en entrée.
Si tu sais pas configurer iptables,

Vaut mieux se tourner sur ufw que mettre un iptables qui sert à rien.

Tito · 05-07-2018 12:04:46

Fail2ban lit les logs et permet de banir une Ip en inscrivant une règle à iptables.
@Philou92: une authentification par clé pour SSH ne demande ni user et mot de passe.
* L'authentification par clé fonctionne grâce à 3 composants :

¹ Une clé publique : elle sera exportée sur chaque hôte sur lequel on souhaite pouvoir se connecter.
² Une clé privée : elle permet de prouver son identité aux serveurs.
³ Une passphrase : Permet de sécuriser la clé privée (notons la subtilité, passphrase et pas password... donc « phrase de passe » et non pas « mot de passe »).
La sécurité est vraiment accrue car la passphrase seule ne sert à rien sans la clé privée, et vice-versa.
(* wiki fédora)

Une fois les clés créées, on désactive dans le sshd_config:

PasswordAuthentication no

PermitRootLogin no

Et on active:

#PubkeyAuthentication yes 

bloc à supprimer si la commande n’affiche rien

bloc à supprimer si la commande n’affiche rien

celp · 05-07-2018 12:07:21

https://korben.info/tuto-ssh-securiser.html

bendia · 05-07-2018 13:07:24

@Jean-Pierre Pinson : déjà, rien que de changer le port par défaut de SSH, tu supprimes quasiment toute les tentatives d'intrusion.

@Philou92 : faut un gros mot de passe, pas facile à mémoriser, donc à écrire quelque part, genre keepass. Est-ce bien différent d'une clé protégée elle aussi par un mot de passe ?

Je ne sais pas si on peut faire une attaque par force brute d'une clé ? Par ailleurs, une clé n'empêche pas de mettre fzil2ban malgré tout

Tito · 05-07-2018 13:24:07

Je ne sais pas si on peut faire une attaque par force brute d'une clé ?

Sauf erreur de ma part, sans user et mot de passe, je ne vois pas trop comment un brut force pourrait forcer quoi que ce soit ! Dans ce cas fail2ban éviterait que tes fichiers logs se remplissent par leurs tentatives infructueuses...
C'est jouer au chat et à la souris de toute façon, les bots sont légions avec donc, une multitude d'IP. Autant leur supprimer le droit de forcer une sécurité standard
------------------------------
Wiki 'buntu

Fail2ban n'est pas a proprement parler un outil de sécurité. L'objectif principal est d'éviter de surcharger les logs du système avec des milliers de tentatives de connexion. Un serveur avec un accès SSH sur le port standard, par exemple, recevra très rapidement des centaines, voire des milliers de tentatives de connexions provenant de différentes machines. Ce sont des attaques par force brute lancées par des robots. Fail2ban en analysant les logs permet de bannir les IP au bout d'un certain nombre de tentatives ce qu limitera le remplissage des logs et l'utilisation de la bande passante. Mais cela n'améliore en rien la sécurité du service concerné. Si l'accès SSH n'est pas suffisamment sécurisé (mot de passe faible par exemple) fail2ban n'empêchera pas un attaquant d'arriver à ses fins.
Autrement dit, utilisez votre temps de travail pour analyser vos configurations et sécuriser vos services plutôt que d''installer et paramétrer des outils d'analyse de logs plus ou moins gourmands en ressources système.

celp · 05-07-2018 13:27:21

De plus que si tu n'a pas une ip publique fixe, je leur souhaite bon courage

Pour ma part,

je dirai
- authentification par clé, les autres sont déactivés.
- fail2ban

Philou92 · 07-07-2018 00:15:30

bendia a écrit :

@Jean-Pierre Pinson : déjà, rien que de changer le port par défaut de SSH, tu supprimes quasiment toute les tentatives d'intrusion.

@Philou92 : faut un gros mot de passe, pas facile à mémoriser, donc à écrire quelque part, genre keepass. Est-ce bien différent d'une clé protégée elle aussi par un mot de passe ?

Je ne sais pas si on peut faire une attaque par force brute d'une clé ? Par ailleurs, une clé n'empêche pas de mettre fzil2ban malgré tout

Exact. Mon propos est de souligner qu'aucune des deux solutions mot de passe ou échange de clefs (même si dans le cas du mot de passe il y a aussi échange de clefs) n'est pas plus sereine l'une que l'autre.

Les deux solutions se valent, la deuxième apportant juste le confort de ne pas avoir à taper un mot de passe. Mais si l'attaquant à accès au(x) client(s), le serveur sera compromis. Les postes clients comme les nôtres (style Michu) étant la plupart du temps moins bien protégés (mots de passe faibles) qu'un serveur, c'est probablement par là qu'un attaquant essayera de passer.

Pour la solution avec mot de passe, comme tu l'indique l'utilisation de keepassx (en graphique) ou pass (en ligne de commande) permet de faciliter la tâche et de changer de mot de passe super fort autant que l'on veut. Fail2ban est un frein efficace pour les attaques de force brute. On peut facilement configurer le nombre d'échecs de connexion (exemple 3) au delà duquel l'IP du client est bannie et le temps pendant lequel cette IP est mise en prison(exemples 10mn, une heure, toujours...). En plus des logs, il est aussi possible d'être averti par mail : des IP bannies, de l'arrêt ou du démarrage du service fai2ban . Ce qui permet de prendre rapidement les mesures qui s'imposent en cas d'attaque avérée (changement du mot de passe, durcissement de la configuration fail2ban etc...).

La méthode par échange de clefs sans mot de passe est bonne si le ou les poste(s) client(s) possède(nt) un mot de passe de connexion fort. Du coup c'est kif kif.

A chacun de choisir la méthode ce qui lui convient le mieux.

Jean-Pierre Pinson · 10-07-2018 23:42:55

Je viens de trouver ce tuto, qui me paraît relativement simple : Sécuriser son serveur linux https://www.remipoignon.fr/9-securiser- … veur-linux

kawer · 11-07-2018 07:01:37

Depuis que j'ai mis openwrt sur mon routeur, avec son interface graphique à iptables, je n'ai plus besoin de m'embêter à mettre un parefeu sur le pc et à le configurer ligne par ligne. /me est bien content.

Un parefeu pour un reseau domestique c'est bien, si on héberge des services, http, samba etc ... sinon je n'en vois pas l'utilité.

celp · 11-07-2018 07:53:36

kawer a écrit :

Depuis que j'ai mis openwrt sur mon routeur, avec son interface graphique à iptables, je n'ai plus besoin de m'embêter à mettre un parefeu sur le pc et à le configurer ligne par ligne. /me est bien content.

Un parefeu pour un reseau domestique c'est bien, si on héberge des services, http, samba etc ... sinon je n'en vois pas l'utilité.

Un parefeu nat suffit également.
Il faut juste relativiser.

si tu as un portable en déplacement, le pâre-feu est important.

kawer · 11-07-2018 08:53:57

si tu as un portable en déplacement, le parefeu est inutile si tu n'héberge pas de services, parcontre pour les hotspots wifi and co il faut un vpn

celp · 11-07-2018 09:47:17

Si tu fais un

netstat -paunt

Tu verra que tu as des ports ouverts meme sans services.
Il est obligatoire d'avoir un firewall.

kawer · 11-07-2018 09:50:00

Des ports ouverts dans une boucle locale, des connections etablished ... je persiste et signe

root@rkn · 11-07-2018 12:54:18

je repasse par là, mais je donne juste une simple réponse concernant le firewall intégré de nos joyeuses boboxes ... il ne sert pas a grand chose, et encore, lorsqu'il fonctionne ...

pour un B.A BA du parefeux, il y a déja qqs articles a droite a gauche:

https://www.commentcamarche.com/content … l-pare-feu
https://www.cisco.com/c/fr_fr/products/ … ewall.html

Debian-facile

#51 04-07-2018 19:12:39

Re : Pare feu iptable et c’est tout

#52 04-07-2018 21:04:40

Re : Pare feu iptable et c’est tout

#53 05-07-2018 10:46:47

Re : Pare feu iptable et c’est tout

#54 05-07-2018 10:56:49

Re : Pare feu iptable et c’est tout

#55 05-07-2018 12:04:46

Re : Pare feu iptable et c’est tout

#56 05-07-2018 12:07:21

Re : Pare feu iptable et c’est tout

#57 05-07-2018 13:07:24

Re : Pare feu iptable et c’est tout

#58 05-07-2018 13:24:07

Re : Pare feu iptable et c’est tout

#59 05-07-2018 13:27:21

Re : Pare feu iptable et c’est tout

#60 07-07-2018 00:15:30

Re : Pare feu iptable et c’est tout

#61 10-07-2018 23:42:55

Re : Pare feu iptable et c’est tout

#62 11-07-2018 07:01:37

Re : Pare feu iptable et c’est tout

#63 11-07-2018 07:53:36

Re : Pare feu iptable et c’est tout

#64 11-07-2018 08:53:57

Re : Pare feu iptable et c’est tout

#65 11-07-2018 09:47:17

Re : Pare feu iptable et c’est tout

#66 11-07-2018 09:50:00

Re : Pare feu iptable et c’est tout

#67 11-07-2018 12:54:18

Re : Pare feu iptable et c’est tout

Pied de page des forums