Ubuntu-fr

UbNeBe

Règles iptables trop imperméable

Bonjour,

Je débute avec Ubuntu parce que je voulais quitter Windows pour améliorer ma sécurité.

J'ai choisi d'installer la version 14.04 LTS.

Avec les galères du débutant je pense avoir compris que dans le monde de linux, contrairement à celui de windows, il y a plein de gens qui ont mis en commun un grand nombre d'articles cherchant à aider ceux qui en ont besoin. Donc j'en profite allègrement mais pour ce coup ci j'ai du mal, je m'explique.

Actuellement j'essaye de configurer Netfilter avec iptables.

J'ai lu quelques pages web à ce sujet dont notamment:
     - http://doc.ubuntu-fr.org/iptables
     - http://olivieraj.free.fr/fr/linux/infor … ewall.html

J'ai tenté de garder la philosophie de l'auteur du dernier site cité en créant mes règles et bien sûr ça n'a pas marché et ça m'a paru normal.

J'ai donc tout bonnement tenté d'adopter les règles issus de la documentation de ce formidable site sur lequel nous sommes et là ça ne marche toujours pas non plus.

les voici : https://doc.ubuntu-fr.org/_export/code/ … deblock=16

C'est pour ça que je vous demande de l'aide pour arriver à comprendre où je me suis planté.

nam1962

Re : Règles iptables trop imperméable

Si tu es derrière une box en routeur ça ne sert pas à grand chose.
Pour te rassurer tu peux juste installer gufw et activer ufw avec ses réglages par défaut, mais ça n'a pas grande utilité : tu es déjà assez protégé comme çà.

Dernière modification par nam1962 (Le 06/09/2014, à 17:17)

---

[ Modéré ]

UbNeBe

Re : Règles iptables trop imperméable

En fait même si ça ne me servira pas à grand chose j'aime bien comprendre là où je me plante.

Ça m'apportera peut-être d'autres réflexes qui me serviront par la suite.

J'essaye de continuer à creuser et afin de diagnostiquer mes problèmes j'ai différencié les logs avec ulogd2.

Mais là aussi iptables me les mets de côté (2938o pour l'OUTPUT) mais je ne les retrouve pas.

Chain OUTPUT (policy DROP 24 packets, 2938 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    8   608 ACCEPT     all  --  *      lo      0.0.0.0/0            0.0.0.0/0           
    4   282 ACCEPT     all  --  *      eth0    192.168.1.10         192.168.1.0/24      
    0     0 ACCEPT     tcp  --  *      eth0    0.0.0.0/0            0.0.0.0/0            tcp spt:80
    0     0 ACCEPT     tcp  --  *      eth0    0.0.0.0/0            0.0.0.0/0            tcp spt:443
   24  2938 ULOG       all  --  *      *       0.0.0.0/0            0.0.0.0/0            ULOG copy_range 0 nlgroup 1 prefix "Out : " queue_threshold 1

Voici mon ulogd.conf :

plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_output_LOGEMU.so"

[LOGEMU]
file="/var/log/ulog/syslogemu.log"
sync=1

Je ne sais pas si ce démon est lancé automatiquement au démarrage.

Je ne sais pas le démarrer, l'option start ne marche pas comme avec les autres.

Dans ce cas aussi j'aimerais bien de l'aide.

nam1962

Re : Règles iptables trop imperméable

Je passe la main.

---

[ Modéré ]

fruitsecrases

Re : Règles iptables trop imperméable

Salut UbNeBe, les règles que tu donnes me sembles brouillon. Je travaille avec celle-ci et par contre, elles fonctionnent parfaitement :

iptables -t filter -F
iptables -t filter -X
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -A INPUT -p all -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t filter -A INPUT -i lo -j ACCEPT

Je n'ai pas de règle pour OUTPUT pour la simple et bonne raison que je suis le seul utilisateur sur ce PC à avoir les droits Root (donc à pouvoir allumer le PC, me logguer, et me mettre en Root quand je veux, pour installer des logiciels etc...). Du coup, comme je maîtrise ma machine, je sais ce qui sort (en gros, mais je sais que ce n'est pas dangereux), je n'ai donc pas besoin de filtrer ce qui sort, car je fais confiance à Cannonical, et à ma pomme. Commencer à mettre OUTPUT en DROP (comme dans les règles que tu nous donnes) c'est le début des soucis. J'avais bloqué un tas de logiciels en mettant OUTPUT en DROP, mais avec les règles que je donne au dessus tout fonctionne, et je n'ai jamais rencontré aucun soucis. Par contre, comme je n'ai pas de règle pour OUTPUT (enfin si j'en ai une, car par défaut elle est sur ACCEPT, et je la laisse tel quel), alors quand je veux filtrer un port de sorti sur un logiciel, là je n'ai aucun soucis. Par exemple j'utilise le logiciel Folding@Home et je ne voulais pas que l'interface de configuration et de gestion de celui-ci soit constemment connectée. Alors, du fait que je laisse tout sortir (tout OUTPUT en ACCEPT), il m'est alors beaucoup plus facile de bloquer ce que je ne veux pas laisser sortir mais au cas par cas ! (ce qui est plus logique pour moi).

Mais comme dit au dessus, faire le contraire* est très difficile (comme j'avais tout bloqué en OUTPUT, j'ai essayé de laisser sortir ce que je voulais (en indiquant les ports logiciels etc...) mais en fait cela m'a été impossible, je m'y suis cassé les dents, et de toutes façons c'était contre productif pour ce que je voulais faire vraiment, c'est à dire, utiliser IPTABLES simplement !! ).

Et pour terminer, pour bloquer l'interface de configuration et de gestion de Folding@Home je n'ai eu qu'à en bloquer ses ports de sortie, comme ceci :

iptables -t filter -A OUTPUT -p tcp -m multiport --sports 7396,36330 -j DROP
iptables -t filter -A OUTPUT -p udp -m multiport --sports 7396,36330 -j DROP

Et voilà, plus de problème.

@ plus, et si tu as des questions on est là (notamment par exemple, si tu veux des infos de comparaison entre ton script précédent et mes règles (concernant précisément les filtres qui bloquaient les scans XMAS et NULL, dans ton script précédent donc, et donc pourquoi je n'ai pas ça dans mes règles (bien que je ne sois pas une fille, j'ai mes règles aussi de temps en temps lol, un peu comme Tiramiseb et Bruno, Pires57 etc...).

* quand je dis "faire le contraire" c'est à dire mettre ta politque de "sortie" (OUTPUT) en DROP à la base et ensuite laisser sortir les logiciels par les ports qu'ils utilisent en créant pour chacun des règles IPTABLES en ACCEPT, ça je n'ai eu que des soucis, voilà.

Dernière modification par fruitsecrases (Le 09/09/2014, à 12:20)

UbNeBe

Re : Règles iptables trop imperméable

En continuant à creuser j'ai réussi à faire passer ça :

#!/bin/sh 
#
IP_A_MOI=192.168.0.2
IP_RESEAU_LOCAL=192.168.0.0/24
echo "# Vidage des tables et des règles personnelles"
iptables -t filter -F
iptables -t filter -X
echo "# Interdire toutes connexions entrantes et sortantes"
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT DROP
echo "# Traitement interface local"
iptables -A INPUT  -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
echo "# Traitement réseau local"
iptables -t filter -A OUTPUT -o eth0 -s $IP_A_MOI -d $IP_RESEAU_LOCAL -p all -j ACCEPT
iptables -t filter -A INPUT  -i eth0 -s $IP_RESEAU_LOCAL -d $IP_A_MOI -p all -j ACCEPT
echo "# Autoriser HTTP et HTTPS"
iptables -t filter -A OUTPUT -o eth0 -p tcp -s $IP_A_MOI --dport 80  -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
iptables -t filter -A OUTPUT -o eth0 -p tcp -s $IP_A_MOI --dport 443 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
iptables -t filter -A INPUT  -i eth0 -p tcp -d $IP_A_MOI --sport 80  -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t filter -A INPUT  -i eth0 -p tcp -d $IP_A_MOI --sport 443 -m state --state RELATED,ESTABLISHED -j ACCEPT
echo "# On drop les scans XMAS et NULL."
iptables -t filter -A INPUT  -i eth0 -p tcp -d $IP_A_MOI --tcp-flags FIN,URG,PSH FIN,URG,PSH -j DROP
iptables -t filter -A INPUT  -i eth0 -p tcp -d $IP_A_MOI --tcp-flags ALL ALL -j DROP
iptables -t filter -A INPUT  -i eth0 -p tcp -d $IP_A_MOI --tcp-flags ALL NONE -j DROP
iptables -t filter -A INPUT  -i eth0 -p tcp -d $IP_A_MOI --tcp-flags SYN,RST SYN,RST -j DROP
echo "# On log ce qui ne passe pas"
iptables -t filter -A OUTPUT -j LOG --log-prefix "Out : "
iptables -t filter -A INPUT  -j LOG --log-prefix "In : "

Je récupère les logs avec tous les paquets bloqués dans /var/log/syslog et je les copie dans LibreOffice Calc qui me remet tout ça en forme pour une meilleure lisibilité.

J'ai pu voir ce qui cloché quand ça fait pas ce que je veux. Je pense utiliser cette manière pour les autres règles que j'apporterai (pour les mails, skype, ...)

Dans ce fichier de log c'est un peu brouillon, je me suis tourné vers ulogd 2 mais je n'arrive pas à le mettre en œuvre.

Voici mon ulogd.conf :

plugin="/usr/lib/x86_64-linux-gnu/ulogd/ulogd_output_LOGEMU.so"
 
[LOGEMU]
file="/var/log/ulog/syslogemu.log"
sync=1

Mais je ne sais pas lancé ce démon même en manuel.

Tout aide sera la bienvenue.

fruitsecrases

Re : Règles iptables trop imperméable

Je fais évoluer aussi mes règles Iptables, en passant je t'annonce toujours que tes filtres XMAS et NULL sont toujours illogiques, et je peux t'expliquer très vite pourquoi avec Iptables dans cette configuration (ton script, mais le mien aussi) il n'est absolument pas logique de les y insérer, et ceci se trouve dans la doc d'Iptables, si tu veux des infos de dessus n'hésite pas

Je mets donc mes règles rectifiées à la suite, car vu que Iptables insère les règles par défaut dans la table "-t filter", il n'est pas nécessaire de lui indiquer lorsqu'on veut attenidre la table "filter", elle est utilisée par défaut par le logiciel Sur cette même base de logique de conception d'Iptables, je peux donc t'expliquer très clairement pourquoi tes XMAS et NULL ne servent à rien (mais ne servent à rien dans ton système de script, ils serviraient parfaitement dans une autre configuration, d'ailleurs ils sont fait pour une autre configuration), là c'est un peu comme si tu mettais les feux stop à l'avant d'une voiture, donc je reste là pour cette info, c'est le principe du forum, s'apprendre des choses mutuellement. Mes rèlges revues :

iptables -F
iptables -X
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -p all -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -p tcp -m multiport --sports 7396,36330 -j DROP
iptables -A OUTPUT -p udp -m multiport --sports 7396,36330 -j DROP

Pour l'information personnelle de chacun, ce que je dis sur la table filter vient de mon étude perso d'Iptables justement, et je l'ai trouvé ici :

https://www.frozentux.net/iptables-tuto … x1779.html

À ce lien au dessus il y est dit en début de paragraphe : L'option -t précise la table à utiliser. Par défaut, il s'agit de la table filter.

D'où la non utilité de préciser cette table filter dans ton script ou dans mes règles. Le sommaire du lien au dessus, est ici : https://www.frozentux.net/iptables-tuto … book1.html

Il est annoncé pour correspondre avec la version d'Iptables 1.2, et par défaut sur Ubuntu Desktop 12.04 LTS c'est la version 1.4.12-1 qui est utilisée, à savoir également que je n'ai pas encore trouvé quelle était la commande donnée par ces pages de manuel Iptables 1.2 qui ne correspondait pas avec la version 1.4.12-1, salut !

Dernière modification par fruitsecrases (Le 10/09/2014, à 11:54)

UbNeBe

Re : Règles iptables trop imperméable

Tu as tout à fait raison ce n'est pas utile de mettre "-t filter"

Pour ce qui est des règles XMAS et NULL, je ne sais pas du tout si c'est utile derrière une box donc dans le doute si ça ne m'empêche pas d'accéder à mes pages web je les laisse en attendant.

Tu me proposait des informations à ce sujet : je suis preneur

Par contre mettre un DROP après des ACCEPT je trouve ça nul, ça pourrait laisser des paquets passés qui aurait pu être bloqués si l'ordre avait été mieux établi.

Voici les règles actuellement sur mon PC :

#!/bin/sh 
#
IP_A_MOI=192.168.0.2
IP_BOX=192.168.0.1
echo "# Vidage des tables et des règles personnelles"
iptables -F
iptables -X
echo "# Interdire toutes connexions entrantes et sortantes"
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP
echo "# On drop les scans XMAS et NULL."
iptables -A INPUT  -i eth0 -p tcp -d $IP_A_MOI --tcp-flags FIN,URG,PSH FIN,URG,PSH -j DROP
iptables -A INPUT  -i eth0 -p tcp -d $IP_A_MOI --tcp-flags ALL ALL -j DROP
iptables -A INPUT  -i eth0 -p tcp -d $IP_A_MOI --tcp-flags ALL NONE -j DROP
iptables -A INPUT  -i eth0 -p tcp -d $IP_A_MOI --tcp-flags SYN,RST SYN,RST -j DROP
echo "# Traitement interface local"
iptables -A INPUT  -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
echo "# Accéder à la Box"
iptables -A OUTPUT -o eth0 -p tcp -s $IP_A_MOI -d $IP_BOX --dport 53 -j ACCEPT
iptables -A OUTPUT -o eth0 -p udp -s $IP_A_MOI -d $IP_BOX --dport 53 -j ACCEPT
iptables -A INPUT  -i eth0 -p tcp -s $IP_BOX -d $IP_A_MOI --sport 53 -j ACCEPT
iptables -A INPUT  -i eth0 -p udp -s $IP_BOX -d $IP_A_MOI --sport 53 -j ACCEPT
echo "# Autoriser HTTP et HTTPS"
iptables -A OUTPUT -o eth0 -p tcp -s $IP_A_MOI --dport 80  -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp -s $IP_A_MOI --dport 443 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT  -i eth0 -p tcp -d $IP_A_MOI --sport 80  -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT  -i eth0 -p tcp -d $IP_A_MOI --sport 443 -m state --state ESTABLISHED -j ACCEPT
echo "# Autoriser Mail"
iptables -A OUTPUT -o eth0 -p tcp -s $IP_A_MOI --dport 993 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp -s $IP_A_MOI --dport 465 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT  -i eth0 -p tcp -d $IP_A_MOI --sport 993 -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT  -i eth0 -p tcp -d $IP_A_MOI --sport 465 -m state --state ESTABLISHED -j ACCEPT
echo "# On log ce qui ne passe pas"
iptables -A OUTPUT -j LOG --log-prefix "Out : "
iptables -A INPUT  -j LOG --log-prefix "In : "

J'ai toujours des problèmes avec ulog, si quelqu'un pouvait m'éclairer.

fruitsecrases

Re : Règles iptables trop imperméable

Oh excellent !! Pile-poil comme à mes débuts, en te lisant je comprends tout de suite que tu n'as pas assimilé la logique du logiciel iptables, c'est flagrant. Une fois comprise ça ira mieux, mais ce n'est pas si compliqué que cela, nous le voyons ensemble tout de suite :

Ici tu nous dis :

Par contre mettre un DROP après des ACCEPT je trouve ça nul, ça pourrait laisser des paquets passés qui aurait pu être bloqués si l'ordre avait été mieux établi.

Donc tu affirmes cela, et c'est donc ce que tu penses actuellement, et je te remercie de le faire partager car nous pouvons réctifier cela tout de suite, avec les explications qui suivent :

Dans ton script tu as cette partie au début :

echo "# Interdire toutes connexions entrantes et sortantes"
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

Donc là tu mets tout en DROP et après ton script fait quoi ? Il met des ACCEPT, pile-poil ce que tu dis trouver nul Il met des ACCEPT avec ceci par exemple (si tu l'analyses mieux, il en met beaucoup plus dans la totalité de ton script, et heureusement, sinon si tu laisses toutes tes politiques en DROP (INPUT,FORWARD,OUTPUT), alors rien ne sort, rien ne rentre, là par contre ce serait bête, il faut donc mettre des ACCEPT pour autoriser le surf et compagnie ! Je pense que tu vois déjà un peu mieux ce qui se passe, et si ce n'est pas encore le cas, les explications plus en détails suivent :

Au début de ton message tu nous dit ça :

Pour ce qui est des règles XMAS et NULL, je ne sais pas du tout si c'est utile derrière une box donc dans le doute si ça ne m'empêche pas d'accéder à mes pages web je les laisse en attendant.

Là aussi tu n'as pas bien compris la règle de ton script qui est celle-ci, ce qui est normal, je suis passé par là aussi je le répète lol, mon mot d'ordre étant toujours "méfiance à ce que nous balance les internautes lol" :

iptables -P INPUT DROP

Cette règle là DROP sert à bloquer absolument tout le trafique entrant, donc par définition les XMAS et NULL.    (Voilà comment ça fonctionne IPTABLES).

Donc en gros, tu peux tout à fait laisser ton INPUT en DROP, mais comme le montre ton script ou bien mes règles, il te faudra automatiquement, des ACCEPT pour tes DROP sinon rien ne passera jamais. Et puis ton script montre aussi que la personne qui l'a fait n'avait pas bien saisi la fonction DROP sur la Politique INPUT.

Pour aller plus loin et mieux comprendre cette ligne tu peux la découper :

iptables -P INPUT DROP

Elle est composé de

iptables qui sert à parler à Iptables.

Ensuite de :

-P  qui veut dire POLICY (en anglais dans le logiciel iptables mais en français on peut le traduire par "politique", ce qui veut dire que quand tu indiques ce -P après le mot iptables (toujours dans cette commande), alors iptables comprend tout de suite que ce qui va suivre dans cette commande sera à appliquer à la Politique complète de l'ordinateur (mais encore faut-il indiquer à Iptables sur quelle chaine tu veux faire appliquer ton "ordre" (j'appelle "ordre" ces paramètres "ACCEPT" ou par exemple "DROP" pour rester dans ce que l'on analyse en ce moment).

Ensuite tu as la chaîne :

INPUT  Là iptables comprends que tu lui donne un ordre pour INPUT.

Et ensuite

DROP    ça c'est ce qu'on a en toute fin de commande, iptables comprends donc qu'il doit mettre la politique DROP à la totalité de chaîne INPUT, d'où les filtres XMAS et NULL supperflus malheureusement pour iptables, car par définition, tant que tu ne mets pas un accept, absolument tout sera DROPÉ ! Tu te rends compte de la puissance de cette commande :

iptables -P INPUT DROP

Elle bloque tout et "tout de suite", pour évidemment faciliter les architectes réseaux dans leurs règles sur iptables, ensuite ils mettent du ACCEPT pour autoriser ce qu'ils veulent. Il faudra donc mettre du ACCEPT pour XMAS et NULL pour les autoriser à se faire depuis l'extérieur, vu que l'on est en ce moment en train de bosser sur la chaîne INPUT (INPUT tu l'auras compris est donc ce qui vient de l'extérieur... Voili voilou, je suis nul en ulog, je sais même pas ce que c'est désolé.

@ toute

Le gros Post Scriptum d'aujourd'hui ce sera de dire (de ma part) :

Que je n'avais pas compris ta phrase de départ pffff, j'ai expliqué tout ça pour rien, désolé, j'ai du te faire perdre ton temps, mais bon, la commande Netstat associée à Wireshark et d'autres trucs encore peuvent t'aider à savoir si des trucs "fuitent" quand tu laisses une politique en ACCEPT et que tu lui colles des DROP, je fonctionne comme ce que tu n'aimes pas faire, et je n'ai jamais eu aucun soucis, au contraire, que des facilités. Par exemple peux-tu nous dire si ton logiciel Transmission est utilisable avec ton script stp ? Si tu veux télécharger en P2P via le réseau Bitorrent une bonne grosse image Debian énorme(ou bien si tu veux violer la loi pour récupérer un film ou un album avec Transmission, mais là le forum déclinera toutes résponsabilités !), ça passe sans problème stp ?

Dernière modification par fruitsecrases (Le 10/09/2014, à 16:04)

fruitsecrases

Re : Règles iptables trop imperméable

Par contre mettre un DROP après des ACCEPT je trouve ça nul, ça pourrait laisser des paquets passés qui aurait pu être bloqués si l'ordre avait été mieux établi.

Je viens de donner le lien dans une autre discussion, mais il pourrait aussi t'intéresser car les réglages de pare-feu Iptables qu'il applique sont celles que tu aimes, tout en DROP et ensuite des trucs en ACCEPT, à plus :

http://irp.nain-t.net/doku.php/130netfi … 0_iptables

Pator75

Re : Règles iptables trop imperméable

Par contre mettre un DROP après des ACCEPT je trouve ça nul, ça pourrait laisser des paquets passés qui aurait pu être bloqués si l'ordre avait été mieux établi.

Je viens de donner le lien dans une autre discussion, mais il pourrait aussi t'intéresser car les réglages de pare-feu Iptables qu'il applique sont celles que tu aimes, tout en DROP et ensuite des trucs en ACCEPT, à plus :
http://irp.nain-t.net/doku.php/130netfi … 0_iptables

Salut,

Pas tout suivi, surtout qu'Iptables ne m'intéresse pas trop pour l'instant, mais à propos de "Par contre mettre un DROP après des ACCEPT je trouve ça nul", je pense qu'il faut aussi expliquer, et ce n'est pas uniquement propre à Iptables, qu'il y a un sens dans les règles, en général c'est de haut en bas, donc la première est acceptée si ACCEPT, les suivantes dans le même cas aussi, et une dernière règle bloque tout le reste, ça me semble important à comprendre, et surtout plus sûr, mettre les DROP en premier il faut être sûr de ne rien oublier.

Pour les règles XMAS, je pense que tu veux parler du scan TCP FIN, etc... qui allume NMAP comme un sapin de Noël, fais ta règle, mais l'ayant testé sous Ubuntu avec GUFW où j'ai remarqué du filtrage de drapeaux, ça passe quand même (Google, Amazon), par contre sous Windows j'ai eu hier une attaque de ce type bloquée par mon pare feu, peut être une petite faiblesse de Linux à ce niveau, mentionnée d'ailleurs chez NMAP dans la rubrique "scan de ports".

Dernière modification par Pator75 (Le 11/09/2014, à 19:38)

pires57

Re : Règles iptables trop imperméable

Il y a deux possibilités pour tes règles Iptables:
-> On bloque tout et on ouvre ce dont on a besoin.
-> On ouvre tout et on bloque ce que l'on ne veut pas.
Personnellement je conseille la première.

Si tu te trouve derrière une box, la mise en place d'iptable et inutile cependant si c'est pour simplement apprendre alors oui cela peut être intéressant.

---

Utilisateur d'Archlinux, Ubuntu et Kali Linux
Administrateur système et réseau spécialisé Linux.
LinkedIn

fruitsecrases

Re : Règles iptables trop imperméable

Salut,

Pas tout suivi, surtout qu'Iptables ne m'intéresse pas trop pour l'instant, mais à propos de "Par contre mettre un DROP après des ACCEPT je trouve ça nul", je pense qu'il faut aussi expliquer, et ce n'est pas uniquement propre à Iptables, qu'il y a un sens dans les règles, en général c'est de haut en bas, donc la première est acceptée si ACCEPT, les suivantes dans le même cas aussi, et une dernière règle bloque tout le reste, ça me semble important à comprendre, et surtout plus sûr, mettre les DROP en premier il faut être sûr de ne rien oublier.

Non pas forcément, tu affirmes cela pour quelle chaine par exemple avec des réglages fait avec Iptables stp ?

Pour les règles XMAS, je pense que tu veux parler du scan TCP FIN, etc... qui allume NMAP comme un sapin de Noël, fais ta règle, mais l'ayant testé sous Ubuntu avec GUFW où j'ai remarqué du filtrage de drapeaux, ça passe quand même (Google, Amazon), par contre sous Windows j'ai eu hier une attaque de ce type bloquée par mon pare feu, peut être une petite faiblesse de Linux à ce niveau, mentionnée d'ailleurs chez NMAP dans la rubrique "scan de ports".

Là non plus, je n'ai jamais fait mes tests avec des réglages faits via GUFW (comme tu précises que toi "oui" par contre, car tu as utilisé GUFW...)  mais par contre j'ai toujours fait mes tests avec mes règles Iptables seulement. Tu peux développer ce qui s'est passé chez toi avec GUFW et dire précisément les réglages que tu avais fait dessus et ce que tu avais remarqué, et comment tu l'avais remarqué stp ? Que je puisse le reproduire chez moi stp, ou pour que n'importe qui qui lit cette discussion puisse le rerpoduire chez lui stp ? Merci

Dernière modification par fruitsecrases (Le 11/09/2014, à 20:12)

fruitsecrases

Re : Règles iptables trop imperméable

Si tu te trouve derrière une box, la mise en place d'iptable et inutile cependant si c'est pour simplement apprendre alors oui cela peut être intéressant.

Merci de dire ce que Tiramiseb refuse de comprendre... J'ajoute quand même, que même derrière une box, je me sers d'Iptables, car je me protège de mon propre réseau Local qui a des machines sous Windows dont je ne peux me passer car le danger peut venir de là aussi, et on sait tous à quel point Windows peut-être très rapidement corrompu comparer à Linux... Et j'ai expliqué pour quel problème exactement dans l'autre discussion "chaud bouillante" en évoquant ce que Misc à mis au jour avec le danger des Helpers (à lire à partir d'ici : http://forum.ubuntu-fr.org/viewtopic.ph … #p17954581 ). Et je m'en sers (en plus de ces mesures de sécurité), à filtrer ce qui sort de certaines de mes applications qui tournent sous ubuntu, donc de toute façon, il faut  demander aux gens ce qu'ils veulent faire exactement avec.

Dernière modification par fruitsecrases (Le 11/09/2014, à 20:17)

fruitsecrases

Re : Règles iptables trop imperméable

Il y a deux possibilités pour tes règles Iptables:
-> On bloque tout et on ouvre ce dont on a besoin.
-> On ouvre tout et on bloque ce que l'on ne veut pas.
Personnellement je conseille la première.

Là ça dépend vraiment de ce que tu veux faire avec le pare-feu, moi c'est le contraire, je laisse tout sortir, sauf ce que je ne veux pas, il faut demander aux gens ce qu'ils veulent faire exactement, et dans mon cas, c'est 10 000 fois plus facile de laisser OUTPUT en ACCEPT et de lui coller les DROP que je veux, mais je pense ne pas être le seul être humain sur terre utilisant cette façon de faire avec Iptables sur Ubuntu...

Pator75

Re : Règles iptables trop imperméable

Fruits,

Sur le premier point, c'est valable pour toutes les chaines ou firewalls, si tu oublies un DROP, et s'il n'y a pas une règle finale bloquante en dernier, ça passe...

Concernant GUFW sous Ubuntu, j'avais mis le journal complet, après avoir fait un iptables -L, il ne me semble pas me rappeler que du blocage de XMAS ou autre était visible, pourtant le filtrage de drapeaux existe on le voit dans le journal (règles cachées probablement), et donc à force d'éplucher le journal, j'ai parfois vu du TCP FIN sans demande de connexion ACK préalable apparaître plusieurs fois, et Ubuntu a répondu par un RESET, donc le résultat idéal pour ce type de scan, un peu gênant.

Alors qu'hier, j'ai failli me faire avoir comme un bleu, sous Windows je télécharge Steam sans trop faire gaffe, je trouve l'exécutable un peu bizarre mais je dis oui à l'UAC, pan! alerte sur une IP publique, là je me réveille.. et bloque, je consulte le journal, 10 ou 12 lignes TCP FIN bloquées par la détection d'attaques, ouf! pour l'instant je ne joue pas sur Debian... on verra ça plus tard.

pires57

Re : Règles iptables trop imperméable

Non Pator75 tout dépend de ta manière de le configurer, si tu mets un drop au début suivit d'un accept sur le port 80 il n'y auras que ce port d'autorisé.

---

Utilisateur d'Archlinux, Ubuntu et Kali Linux
Administrateur système et réseau spécialisé Linux.
LinkedIn

fruitsecrases

Re : Règles iptables trop imperméable

Fruits,

Sur le premier point, c'est valable pour toutes les chaines ou firewalls, si tu oublies un DROP, et s'il n'y a pas une règle finale bloquante en dernier, ça passe...

Je ne parlais pas du sens DROP dans ce sens là, et d'ailleurs l'initiateur de ce topic non plus, mais tu t'es fait piégé comme moi, car sa phrase porte à confusion, il ne voulait pas dire ça :

"Je n'aime pas mettre tout en ACCEPT et ensuite faire mes règles avec des DROP"

Mais il voulait dire ça :

"J'aime mettre tout en DROP et ensuite mettre des ACCEPT".

Du coup on comprend vite que dans ce cas là, il est difficile d'oublier un DROP, il n'y en a que 3 à mettre, un sur chaque politique de chaînes, donc un sur INPUT, un sur FORWARD et un sur OUTPUT.

Concernant GUFW sous Ubuntu, j'avais mis le journal complet, après avoir fait un iptables -L, il ne me semble pas me rappeler que du blocage de XMAS ou autre était visible, pourtant le filtrage de drapeaux existe on le voit dans le journal (règles cachées probablement), et donc à force d'éplucher le journal, j'ai parfois vu du TCP FIN sans demande de connexion ACK préalable apparaître plusieurs fois, et Ubuntu a répondu par un RESET, donc le résultat idéal pour ce type de scan, un peu gênant.

Quelles étaient tes règles exactes avec GUFW stp ? Que chacun puisse le reproduire chez lui merci, merci aussi d'indiquer comment tu avais mis le "journal complet" comme tu l'appelles. Car je n'ai jamais remarqué cela avec mes règles brutes via iptables, je le répète.

Dernière modification par fruitsecrases (Le 11/09/2014, à 22:24)

pires57

Re : Règles iptables trop imperméable

personnellement les règles GUFW ne m’intéresse pas, je ne commenterais donc pas la dessus, Je ne configure que via iptables (et j'ai fait peut être une 10 aines d'heure sur shorewall , en gros un temps négligeable)

---

Utilisateur d'Archlinux, Ubuntu et Kali Linux
Administrateur système et réseau spécialisé Linux.
LinkedIn

fruitsecrases

Re : Règles iptables trop imperméable

Je ne pars aussi que sur Iptables (tout le temps), je n'aime pas GUFW, mais je ne connais pas bien Shorewall, que j'aimerai beaucoup apprendre... Bonne soirée.

nam1962

Re : Règles iptables trop imperméable

@pires, pour un serveur je comprends, mais pour un desktop ?

---

[ Modéré ]

pires57

Re : Règles iptables trop imperméable

de quel post tu parles nam? je suppose de mon premier sur ce topic? si c'est pour apprendre cela peut toujours être intéressant bien qu'il n'y aura aucune utilité étant donnée que la box intégre déja son firewall, on est tout a fait d'accord

---

Utilisateur d'Archlinux, Ubuntu et Kali Linux
Administrateur système et réseau spécialisé Linux.
LinkedIn

Pator75

Re : Règles iptables trop imperméable

Non Pator75 tout dépend de ta manière de le configurer, si tu mets un drop au début suivit d'un accept sur le port 80 il n'y auras que ce port d'autorisé.

Salut,

Un DROP suivi d'un ACCEPT et plus rien ne passe? il me manque des infos là, ça me semble clairement une erreur de conception, tous les firewalls non Iptables ne fonctionnent pas comme ça.

Pator75

Re : Règles iptables trop imperméable

"J'aime mettre tout en DROP et ensuite mettre des ACCEPT".

Je ne comprends pas le sens des règles d'Iptables, pourtant le nouveau GUFW permet de modifier son ordre, peut être que le sens est de bas en haut pour la priorité.

"Quelles étaient tes règles exactes avec GUFW stp ? Que chacun puisse le reproduire chez lui merci, merci aussi d'indiquer comment tu avais mis le "journal complet" comme tu l'appelles. Car je n'ai jamais remarqué cela avec mes règles brutes via iptables, je le répète."

GUFW je ne modifie que les règles ICMP, je ne garde que "destination inaccessible", pour le journal tu vas (de mémoire) dans édition > préférences.

Dernière modification par Pator75 (Le 12/09/2014, à 08:10)

pires57

Re : Règles iptables trop imperméable

Si tu drop tout les port mais que tu viens mettre une règle accept sur le port 80 seul ce port sera autorisé, c'est pas compliqué a comprendre

---

Utilisateur d'Archlinux, Ubuntu et Kali Linux
Administrateur système et réseau spécialisé Linux.
LinkedIn