Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#151 Le 27/12/2014, à 02:24

Nathaly01

Re : Configuration d'iptables

Je tiens à préciser que ce que j'ai dis avant n'est aucunement contre tiramiseb, personne qui m'apporte une grande aide et que je remercie de tout mon cœur ......

Hors ligne

#152 Le 27/12/2014, à 03:07

Nathaly01

Re : Configuration d'iptables

Tu es sur un site d'entre aide et nous ne sommes pas à ton service au sens service commerciale, Canonical offre ce genre de contrat. on fait du mieux que l'on peut. Avec un ton plus condescendant, je pourrais tout simplement te répondre que le man est ton ami, tu as tout ce qu'il faut pour réussir seule

Avec se genre de réponse, c'est à se demander pourquoi il existe ce genre de forum ????
Après tout, il y a des man pour tout ...
Donc selon tes dires, chacun n'a qu'a se démerder avec ce qu'il veut faire, tant pis si il comprend rien, il a qu'à apprendre l'Anglais informatique, et à 50 ans, retourner en fac pour apprendre l'informatique ????
Belle contribution de ta part !!! très intelligente !!!

Désolée, je suis énervée ce soir ....

Hors ligne

#153 Le 27/12/2014, à 10:10

Lanzpaul

Re : Configuration d'iptables

« tiramiseb a écrit : mais dès qu'il y a écoute non voulue et non désactivable, je préfère bloquer avec le pare-feu. »

Une grande découverte... j'ajouterais « … et absence de volonté de désactiver quoi que soit par manque de compétence ou négligence » ceci étant le cas de beaucoup de gens.
Déconseiller un pare feu est dangereux, ce n'est pas la panacée mais ça ferme les ports, sous Ubuntu ou ailleurs, au fur et à mesure de l'usage d'un PC, l'utilisateur peut faire des erreurs, tout le monde n'est pas un geek constamment aux aguets.
Ne pas compter uniquement sur le pare feu du routeur, il est à jour ? Le pare feu est activé ? Les mots de passe c'est quoi ? Si rien ne va, avec votre IP on peut peut être accéder à la configuration…

Si les pentesteurs de ce site vérifient assidument l'existence de failles connues sur les systèmes, peut être plus par habitude qu'en comprenant dans le détail ce qu'ils font, il y a des gens qui le savent parfaitement et recherchent de nouvelles failles…
Avec un port ouvert vous pouvez faire beaucoup de choses , trouver le service, la version et son numéro, l'OS, le protocole, le nom, l'OS, beaucoup de choses qui intéressent les hackers, ne les aidez pas, fermez les avec un firewall.

Je pense que les conseils de sécurité de certains membres ici sont motivés surtout par la volonté de promotion des moyens de défense de Linux, ou la leur, mais en peu de temps il y a eu Bash...Turla… Grinch… NTP... un peu de modestie devrait s'imposer normalement dans un esprit sain.

Dernière modification par Lanzpaul (Le 27/12/2014, à 10:11)

Hors ligne

#154 Le 27/12/2014, à 11:34

tiramiseb

Re : Configuration d'iptables

Nathaly01, je n'ai jamais vu personne ici avoir un traitement plus "méchant" envers une femme qu'envers un homme. Au contraire, en général on est plus bienveillant avec les femmes (c'est tellement rare, une femme qui s'intéresse à l'informatique - ouais, faut pas croire, les informaticiens aussi sont des obsédés du cul, alors si on peut obtenir un peu d'intérêt de la gent féminine......... lol).
Plus sérieusement, là je dois reconnaître que ta réaction ne donne pas envie de t'aider ; je ne vais pas entrer dans le détails des propos (que ce soient ceux d'Ignus, les tiens ou ceux d'autres gens), ça ne sert à rien. Mais là, la discussion s'est tellement compliquée que je ne sais même plus ce que tu attends comme aide. Alors je te propose de recentrer la chose sur tes demandes et de nous dire ce que tu voudrais comme aide.

-----

Mon prochain message sera une réponse à Lanzpaul, qui apporte des arguments techniques, j'estime qu'on n'est plus dans une digression / guerre de chapelles mais bien dans un échange qui porte sur des aspects techniques : ne pas voir mon prochain message comme une digression...
Mais si toi, Nathaly01, tu estimes que la discussion en question (les arguments pour et contre la mise en place systématique d'un pare-feu) ne concerne pas ta demande, n'hésite pas à nous dire d'arrêter de parler de ça : c'est ton fil de discussion, tu peux très bien demander aux gens d'aller discuter ailleurs si le sujet ne t'intéresse pas (pas sûr que tout le monde suive ta demande, mais elle serait légitime vu que c'est ton fil).

Hors ligne

#155 Le 27/12/2014, à 13:12

tiramiseb

Re : Configuration d'iptables

Lanzpaul : ah ben voilà, on a dépassé le stade des "DH2" et "DH3" ! lol je suis content qu'on se recentre sur une vraie discussion technique et non une attaque sans fondement. Alors allons-y, j'entends tout à fait tes arguments et ton point de vue - je ne suis pas entièrement d'accord avec toi (je pense que tout le monde l'a déjà compris) et ci-dessous j'explique pourquoi.

Attention, mon argumentaire est long. Je sais bien que ce n'est pas facile à lire, mais on ne peut pas être précis sans être détaillé.
Voici cependant en une phrase l'esprit de mon message :
oui, bloquer tous les ports permet d'empêcher une quelconque pénétration, mais quand on a un port ouvert c'est qu'on le veut, alors on enlève le blocage ; sinon installer un serveur est inutile. il y a bien d'autres conseils à donner que de mettre en place un pare-feu.

-----

D'un point de vue purement technique, bien sûr ton raisonnement se tient : si on ferme tous les ports avec le pare-feu, alors il peut y avoir n'importe quoi en écoute sur le système, personne ne pourra y accéder. Mais c'est une vision trop simpliste, qui ne tient pas compte de la réalité des faits et des inconvénients du pare-feu (car il n'y a pas que des avantages). J'avais précisément la même approche il y a de nombreuses années, mais avec l'expérience et les exemple s'accumulant, mon point de vue a évolué et c'est pour cela que je déconseille la mise en place systématique d'un pare-feu.

Avec un port ouvert vous pouvez faire beaucoup de choses , trouver le service, la version et son numéro, l'OS, le protocole, le nom, l'OS [...]

Oui, tu as raison, tout port ouvert permet d'obtenir des informations sur le système, même s'il n'y a pas de faille. Cela étant dit, à quoi serviront ces informations à un pirate ? Cela permet d'approfondir les méthodes d'attaque, de mieux cibler... des actions qui prennent beaucoup de temps. Mais une attaque ciblée n'est jamais effectuée envers un particulier "lambda".

Rappelons cependant qu'il ne faut pas confondre "port ouvert" et "faille" : ce n'est pas parce qu'un port est ouvert qu'il y a une faille ! Si un port est ouvert, c'est pour desservir une fonctionnalité, pour offrir un service. Ce n'est que lorsque le logiciel utilisé a une faille (faille logicielle ou faiblesse de configuration) qu'il peut y avoir piratage. Et cela ne veut pas dire qu'il y a automatiquement piratage : il faut que quelqu'un vienne exploiter la faille en question.

Concernant les attaques, on peut mettre en exergue deux approches :
- les attaques ciblées, où un pirate chevronné cible un système en particulier pour y pénétrer, c'est là qu'il faut éviter toute fuite d'information car elles peuvent être exploitables de différentes manières, par exemple par de l'ingénierie sociale - en général, en tant qu'individu lambda on n'est pas sujets à de telles attaques ;
- les attaques automatisées, les plus courantes, qui tentent d'exploiter surtout les faiblesses des mots de passe et un peu les failles connues des logiciels.

Comme tu l'as toi-même indiqué à demi-mot, installer un pare-feu inconditionnel est un palliatif.
Dans ce cadre, revenons sur les cas de figure qui peuvent être rencontrés :
- l'utilisateur lamba, qui n'installe pas de serveur (voire qui n'installe jamais rien), qui utilise un système classique par défaut et qui accepte les mises à jour : d'une part aucun port inutile n'est ouvert sur son ordinateur, le pare-feu est donc inutile (c'est le paramétrage par défaut d'Ubuntu, sa sécurité est bonne), d'autre part les logiciels sont à jour, non exploitables [exemples : mon père, ma femme] ;
- l'utilisateur "bidouilleur de base", qui installe différents serveurs sans trop savoir les utiliser : il utilise alors la configuration par défaut, dont la sécurité est également plutôt bonne, grâce au travail des mainteneurs d'Ubuntu [exemples : les très nombreuses personnes qui viennent demander de l'aide ici après avoir installé Apache] - notons également que, dans le cas de ces utilisateurs, le port en question doit bel et bien être ouvert : s'il bloque le port 80, alors Apache n'est plus accessible et ce n'est pas ce qu'il veut ;
- l'utilisateur "tête en l'air" qui installe n'importe quoi et qui oublie ensuite : il a alors la configuration de base, suffisamment sécurisée - même si de très nombreux ports sont ouverts, aucune faille n'est utilisable... tant qu'il met à jour son système [je n'ai pas d'exemple sous la main] ;
- l'utilisateur "intéressé", qui essaie de configurer les logiciels en plus de les installer : il sait à peu près ce qu'il fait même s'il ne sait pas comment faire, il sait qu'il a ouvert un port et il commence à comprendre les implications [je n'ai pas d'exemple précis sous la main, mais sur ce forum il y en a beaucoup, il suffit de trainer un peu par là], s'il a ouvert un port c'est qu'il le voulait, c'est pour desservir un truc (site web, etc) ;
- l'utilisateur chevronné, qui sait ce qu'il fait : là, rien à dire, c'est Ignus, c'est pires57, c'est Haleth, c'est moi... bah voilà, on sait ce qu'on fait, on sait pourquoi ouvrir des ports et on sait comment protéger.

Ajoutons à cela que, bien souvent, on est dans un réseau privé, derrière un routeur ou une box : la machine n'est donc pas directement accessible d'Internet et un pirate ne pourra y accéder que s'il a d'abord réussi à pirater le routeur ; on est alors complètement dans le cas d'une attaque ciblée, rare et pour laquelle l'utilisateur de base n'est jamais une cible (ce n'est pas intéressant pour un pirate de passer des heures, des jours, des semaines à pirater n'importe qui sans but précis).

-----

Depuis des années, tout le monde dit tellement qu'un pare-feu est la base de la sécurité que le grand public croit qu'un pare-feu sert à protéger un ordinateur. Des phrases comme « j'ai un pare-feu, je suis en sécurité », j'en entend très souvent...

Voilà pourquoi je dis que conseiller un pare-feu inconditionnellement est néfaste : les gens croient qu'avec un pare-feu ils sont en sécurité, mais ils ne savent pas réellement à quoi sert un pare-feu ; ils ne savent pas que c'est une protection bien faible et un principe très basique. Ils baissent leur vigilance, ils oublient des mises à jour, ils utilisent des mots de passe faibles... et là, c'est le drame : ils se font pirater alors qu'ils croyaient être en sécurité. Non, il est préférable d'expliquer aux gens trois principes de base :
- ne pas installer n'importe quoi ;
- appliquer les mises à jour du système ;
- utiliser des mots de passe forts.

Avec ces trois principes simples à comprendre, n'importe qui sera bien plus en sécurité qu'avec n'importe quel pare-feu.

-----

Des cas où un pare-feu est en place et pose problème, on en a bien souvent rencontré sur ce forum, et ça continuera : des questions du genre « j'ai installé Apache mais mon site marche pas », « pourquoi j'ai un "low id" sur Emule », « je n'arrive pas à faire un ping sur mon serveur » ou encore « mon serveur est mort, SSH ne répond plus ». Tout ça, c'est à cause d'un pare-feu excessif.

-----

Enfin, revenons sur les cas où un pare-feu est utile :
- une passerelle, où on met un pare-feu de réseau pour gérer les flux traversants : c'est le cas de Nathaly01 ;
- les logiciels qu'on ne peut pas configurer pour n'être en écoute que sur certains ports, là Samba me déçoit à cause de nmbd qui écoute toujours partout : c'est également le cas de Nathaly01.

Et là on a un vrai usage intelligent et ciblé du pare-feu, pas un blocage inconditionnel de tous les ports. Dans ce cadre-là, j'aide avec plaisir ceux qui ont vraiment besoin d'un pare-feu. C'est le cas ici.

PS : houla c'est déjà long, j'avais l'intention d'écrire beaucoup plus et avec énormément de détails, mais je ne veux pas rendre mon message trop indigeste... c'est déjà assez ardu comme ça.

Hors ligne

#156 Le 27/12/2014, à 13:29

Compte supprimé

Re : Configuration d'iptables

Tiramiseb, rien à redire, je te rejoins dans ton dernier post wink

Depuis des années, tout le monde dit tellement qu'un pare-feu est la base de la sécurité que le grand public croit qu'un pare-feu sert à protéger un ordinateur. Des phrases comme « j'ai un pare-feu, je suis en sécurité », j'en entend très souvent...

J'ajoute que c'est ici qu'est la faille de raisonnement et que beaucoup applique aveuglément, c'est du pain béni pour les pirates, voir pour des organisations gouvernementales. Un pare-feu ne sécurise rien du tout, il ferme/masque des ports et des services, point. Pour autant la machine n'est pas sécurisée si un service extérieur web est actif  smile
Sur une station de travail, la question ne se pose plus (c'est déjà ça big_smile)

Dernière modification par ignus (Le 27/12/2014, à 13:33)

#157 Le 27/12/2014, à 13:47

robindesbois

Re : Configuration d'iptables

Bonjour la room.


En tant que personne en relation contante avec des professionnels, il y a un autre cas où le parefeu est à conseiller de façon complètement inconditionnelle, et à toutes et tous, c'est le cas où l'on veut assurer ses arrières lorsque l'on est utilisateur de VPN et que celui-ci "tombe". J'entends par là, lorsque le VPN se coupe pour de multiples raisons, et que votre trafic se retrouve balancé sur la toile à qui veut le voir...(FAI et touti couenti...). Quand on est pros, je pense qu'on la rajoute à sa liste, cette option. Ça fait alors, un paquet de personnes potentiellement concernées, ici, ou ailleurs, et donc intéressées par le "filet de sécurité" incontestable que présente Iptables dans ce cas là, car avec les règles qu'il faut, vos données seront bloquées nettes par Iptables, dès que votre VPN tombera, ce qui est en soi, ultra intéressant.

Pour info, la distribution Tails, basée sur la sécurité (entre autre), et basée sur Debian, possède d'origine ses propres règles Iptables (en haut au centre la date de ma copie d'écran). Cela dit je les ai découvertes hier, donc pas encore analysées plus amplement, pour être tout à fait transparent.

141227124818938925.png

Dernière modification par robindesbois (Le 27/12/2014, à 13:49)

Hors ligne

#158 Le 27/12/2014, à 14:00

Lanzpaul

Re : Configuration d'iptables

« L’ICS-CERT rappelle les mesures nécessaires pour se protéger contre les cyberattaques :
toujours utiliser un pare-feu lorsqu'on se connecte sur internet ;
mettre hors réseau tous les appareils et systèmes qui n’ont pas besoin d’une connexion internet pour fonctionner ;
mettre fréquemment à jour son système, son navigateur et les outils utilisés ;
toujours utiliser - dans la mesure du possible - des méthodes/protocoles de connexion sécurisées (ex : HTTPS, SSL, VPN).

Il ne faudra pas oublier non plus que ces méthodes et protocoles peuvent eux même être vulnérables »


Je n'ai aucunement besoin des justifications de certains, ceux ci comme le l'ai déjà dit devraient être écartés de la profession.

Hors ligne

#159 Le 27/12/2014, à 14:03

tiramiseb

Re : Configuration d'iptables

J'entends par là, lorsque le VPN se coupe pour de multiples raisons, et que votre trafic se retrouve balancé sur la toile à qui veut le voir

1er cas : un VPN de réseau pour connexion d'une succursale à un siège
Oui mais non. Bien sûr, mettre en place un pare-feu bloquera ces flux, ça fonctionnera. Mais là encore le pare-feu est un palliatif.
C'est un palliatif à une mauvaise configuration du routage. Quand le VPN tombe, le trafic doit simplement être bloqué, il ne doit pas être envoyé en direct sur Internet. Quand le trafic a pour objectif d'être uniquement transmis au travers du VPN, le routeur ne doit pas avoir de route par défaut vers Internet : la seule chose avec une route vers Internet, ça doit justement être la connexion au serveur VPN.

2me cas : un VPN sur poste de travail pour connexion distante
Si on met un filtrage inconditionnel sur les sorties par Internet, eh bien le PC ne sera plus utilisable sans VPN. Si c'est ce que l'on veut, alors le 1er cas s'applique. Sinon, eh bien il n'y a pas vraiment de solution : il faut bien laisser passer les flux pour pouvoir aller sur Internet quand on n'a pas le VPN, non ?

Hors ligne

#160 Le 27/12/2014, à 14:11

tiramiseb

Re : Configuration d'iptables

Lanzpaul: c'est justement à cause de ce genre de généralités faites par des organismes de ce genre que ça pose problème : le pare-feu est présenté comme la première chose à faire quand on accède sur Internet, sans aucune explication, alors qu'en réalité un tel usage n'est qu'un palliatif. D'autant plus que, sous Windows, beaucoup de logiciels se présentent comme des pare-feux mais ils cumulent en réalité plusieurs rôles.

Hors ligne

#161 Le 27/12/2014, à 15:09

robindesbois

Re : Configuration d'iptables

tiramiseb a écrit :

J'entends par là, lorsque le VPN se coupe pour de multiples raisons, et que votre trafic se retrouve balancé sur la toile à qui veut le voir

1er cas : un VPN de réseau pour connexion d'une succursale à un siège
Oui mais non. Bien sûr, mettre en place un pare-feu bloquera ces flux, ça fonctionnera. Mais là encore le pare-feu est un palliatif.
C'est un palliatif à une mauvaise configuration du routage. Quand le VPN tombe, le trafic doit simplement être bloqué, il ne doit pas être envoyé en direct sur Internet. Quand le trafic a pour objectif d'être uniquement transmis au travers du VPN, le routeur ne doit pas avoir de route par défaut vers Internet : la seule chose avec une route vers Internet, ça doit justement être la connexion au serveur VPN.

2me cas : un VPN sur poste de travail pour connexion distante
Si on met un filtrage inconditionnel sur les sorties par Internet, eh bien le PC ne sera plus utilisable sans VPN. Si c'est ce que l'on veut, alors le 1er cas s'applique. Sinon, eh bien il n'y a pas vraiment de solution : il faut bien laisser passer les flux pour pouvoir aller sur Internet quand on n'a pas le VPN, non ?


Pour ma façon de faire, il me faut le paquet "iptables-persistent", c'est un paquet que je trouve dans les dépôts officiels d'Ubuntu via Synaptic.

En fait, j'ai deux jeux de règles, que l'on peut changer facilement, à travers deux scripts par exemple, ou à la barbare, en copiant collant les deux fichiers de règles d'Iptables que l'on a dans le dossier : /etc/iptables/ (il y a encore d'autres façons de faire sûrement).


141227021830916273.png


Sur la copie d'écran qui précède on voit les deux fichiers de règles connus par le paquet iptables-persistent, car c'est ce dossier qu'iptables-persistent utilise, (je rentrerai dans les détails des règles si ça intéresse quelqu'un), mais en gros, je fais un copié-collé de mes règles assurant mon VPN s'il tombe quand je veux me servir de mon VPN de façon sécurisé, soit 99,99% de mon temps de surf. Je copie-colle à l'invers, mes règles permissives quand je veux que mon PC ait un accès au net alors que je n'ai pas prévu d'utiliser mon VPN, donc, cette opération, vu le pourcentage que j'annonce, n'arrive quasiment jamais sur un trimestre. Mes deux fichiers appelés "rules.v4" et "rules.v6" sont dans des dossiers séparés, nommés comme il se doit, suivant qu'ils autorisent un accès au net non filtré, ou suivant qu'ils assurent un VPN qui tombe.

Cela rend alors le passage des unes aux autres de façons très simple (pour moi, il y a d'autres façons, que je veux bien apprendre si vous les maîtrisez, mais cette façon me convient pour le moment). À noter que je lance Nautilus en Root pour faire mon copié-collé de 15 secondes et et que je coupe cet accès Root à Nautilus tout de suite derrière. Et comme dit à l'instant, on doit pouvoir faire encore plus simplement qu'un copié-collé de la façon dont je le fais, et je veux bien apprendre comment faire, je n'ai encore jamais utilisé ni confectionné de script.


Donc en fait comme tu le dis Tiramiseb, dans le cas où l'on utilise des règles Iptables de blocage de l'internet en cas de VPN qui tombe, il faut quand même bien que notre PC ai un accès au serveur de notre VPN pour pouvoir se connecter via OpenVPN (par exemple), mais dans ce cas là, pas besoin de plus que....la seule et unique adresse IP du serveur OpenVPN de notre abonnement (ou du gratuit). Du coup, le seul accès à un internet "classique" est l'accès à cette unique IP de notre serveur VPN. Mais ce n'est pas tout, comme une Interface va se créer lorsque notre serveur VPN va accepter nos "identiant et mot de passe VPN", il faut indiquer à Iptables que le Net sur notre machine maintenant ne passera que par cette nouvelle Interface (en général l'interface tun0, donc on paramètre Iptables sur ce point avant bien sûr). Alors si ton VPN tombe, cette Interface VPN (tun0) tombe aussi, et Iptables ne la connaissant plus et sachant qu'il n'a le droit que de diffuser tous tes paquets destinné au NET via celle-ci, arrête immédiatement de balancer tous paquets, et plus rien ne sort de votre machine d'une seconde à l'autre.


Merci le filet de sécurité founri par Iptables pour les particuliers j'ai envie de dire...

J'ai donc autre chose à faire que de renseigner mon FAI sur ce que je fais sur mon réseau, c'est personnel, et je ne cherche pas à l'inverse, à savoir ce que eux font sur leur réseau, c'est personnel aussi. Voilà en gros, je me suis basé sur ce site pour établir mes règles, et bien sûr sur les doc d'Iptables, notamment concernant le suivi de connexion du module IP_CONNTRACK qui transforme votre Iptables en véritable parefeu SPI (Stateful Packet Inspection), j'applique aussi grâce à une règle Iptables, un filtre antispoofing, qui est ma foi fort efficace, il bloque ce tyep de paquet chaque jour (que je vois dans mes logs). Voilà pourquoi je dis et prouve, qu'Iptables, même pour un particulier est bel est bien conçu AUSSI pour la sécurité informatique de n'importe lequel d'entre nous, ici sur ce forum et qui veut assurer de façon efficace, ses données transitant par son VPN.

Et je pense sincèrement que le cas que je viens de décrire, qui ne faisait pas parti à la base de votre liste des cas où Iptables sera utile pour la sécurité du réseau des particuliers j'entends, aurait toute son humble et vailalnte place dans votre liste, car c'est un cas qui peut concerner énormément de particuliers utilisant un VPN, comme on vient de l'éclaircir.

Dernière modification par robindesbois (Le 27/12/2014, à 16:26)

Hors ligne

#162 Le 27/12/2014, à 15:13

tiramiseb

Re : Configuration d'iptables

Alors si ton VPN tombe, cette Interface VPN (tun0) tombe aussi, et Iptables ne la connaissant plus et sachant qu'il n'a le droit que de diffuser tous tes paquets destinné au NET via celle-ci, arrête immédiatement de balancer tous paquets

C'est sur ces aspects-là que tu es dans l'erreur.
Ce n'est ipas iptables qui connait (ou pas) les interfaces et qui balance (ou pas) les paquets.
C'est une question de table de routages (voire commandes "route -n" ou alors la plus récente "ip route"). Si les routes sont bien configurées, alors le pare-feu est inutile. C'est en cela que le pare-feu est un palliatif : il bloque des paquets qui n'auraient déjà jamais dû passer par là en premier lieu.

Hors ligne

#163 Le 27/12/2014, à 15:27

robindesbois

Re : Configuration d'iptables

tiramiseb a écrit :

Alors si ton VPN tombe, cette Interface VPN (tun0) tombe aussi, et Iptables ne la connaissant plus et sachant qu'il n'a le droit que de diffuser tous tes paquets destinné au NET via celle-ci, arrête immédiatement de balancer tous paquets

C'est sur ces aspects-là que tu es dans l'erreur.
Ce n'est ipas iptables qui connait (ou pas) les interfaces et qui balance (ou pas) les paquets.
C'est une question de table de routages (voire commandes "route -n" ou alors la plus récente "ip route"). Si les routes sont bien configurées, alors le pare-feu est inutile. C'est en cela que le pare-feu est un palliatif : il bloque des paquets qui n'auraient déjà jamais dû passer par là en premier lieu.


Iptables le fait aussi parfaitement, avec en plus ses excellentes propriétés de par-feu SPI, voir ici pour la définition et l'historique. Ici on parlait déjà il y a longtemps des fonctions SPI d'Iptables : http://www.zeroshell.net/fr/firewalldetails/  En plus donc de la fonction antispoofing (suivant la règle qui va bien) qu'il me procure (et dont j'avais oublié de parler dans mon message précédent).

Dernière modification par robindesbois (Le 27/12/2014, à 16:36)

Hors ligne

#164 Le 27/12/2014, à 15:37

tiramiseb

Re : Configuration d'iptables

Bien sûr qu'iptables bloque parfaitement les paquets. Et ça fait bien son boulot.

Mais ce que tu lui demandes, il ne devrait pas avoir à le faire.
En fait, tu as choisi de mettre en place du filtrage avec le pare-feu au lieu de mettre en place les bonnes règles de routage.
Ça n'en fait pas moins un usage à titre palliatif : si tes routes étaient bien configurées, tes paquets ne sortiraient pas par là où ils ne doivent pas sortir.

Hors ligne

#165 Le 27/12/2014, à 16:07

tiramiseb

Re : Configuration d'iptables

non pas pour filtrer un service en écoute, mais pour rendre inaccessible ceux qui n'ont pas à communiquer avec l'extérieur

Et encore une fois du palliatif ! Mais quand allez-vous comprendre, vous qui ne jurez que par les pare-feux ?
Un service qui n'a pas à communiquer avec l'extérieur ne doit pas écouter sur un port externe ! Il faut configurer le service pour qu'il n'écoute que là où il doit écouter.

Laisser le logiciel écouter sur une interface puis mettre un pare-feu pour bloquer les paquets, c'est une configuration palliative.

Un système n'est jamais infaillible à l'instant t, et cela serait imprudent que de prétendre le contraire, et bien souvent les mises à jour de sécurité ne sont pas instantanées

Là on a clairement le début des réflexions dangereuses !
Avec un pare-feu...
... soit tu fermes le port pour rendre un service inaccessible (auquel cas la bonne solution est plutôt de configurer ou désactiver le service en question)
... soit tu laisses ouvert car le service est nécessaire
En quoi un pare-feu corrigerait des failles de sécurité ?

Dire qu'un pare-feu est utile contre des failles non corrigées, c'est une énormité sans nom.

Un pare-feu n'est pas magique, ce n'est qu'un outil à la portée très limitée, que beaucoup utilisent à titre palliatif sans vraiment comprendre tout cela, aveuglés par la croyance qu'un pare-feu est essentiel (voire suffisant) à la sécurité d'une machine.

Dernière modification par tiramiseb (Le 27/12/2014, à 16:11)

Hors ligne

#166 Le 27/12/2014, à 16:25

robindesbois

Re : Configuration d'iptables

tiramiseb a écrit :

Un pare-feu n'est pas magique, ce n'est qu'un outil à la portée très limitée, que beaucoup utilisent à titre palliatif sans vraiment comprendre tout cela, aveuglés par la croyance qu'un pare-feu est essentiel (voire suffisant) à la sécurité d'une machine.


On se rejoint sur le point qu eut cites et qui dit "voir suffisant", non Iptables n'est pas suffisant, et tu nous donnes sur cette discussion d'autres points à vérifier, dans le désordres :

_ne pas installer n'importe quoi
_faire ses mises à jour (de sécurité ou pas)
(et j'en oublie, tu corrigeras pour rappel si tu veux).

Mais écarter complètement Iptables n'est pas non plus la solution ultime aux problèmes de sécurité (autant que l'invers est vrai aussi), utiliser un système de freinage simple sur une voiture ça suffisait avant, mais met l'option ABS sur une voiture (sans l'activer) il y a de grande chance qu'un jour elle aurait servi en cas de freinage qui aurait demandé son couconrs. En revenant à la sécurité informatique, on le pense surout quand on suit l'actualité de l'ingénérie des pirates informatiques au quotidien, et là on n'apprendra rien à personne en l'affirmant. J'ai oublié que j'applique aussi grâce à Iptables, un filtre antispoofing (je vais corriger ce point dans mon message précédent), c'est un règle aussi spéciale à Iptables, qu eje trouve fort utile.

Donc pour moi, Iptables fait office d'antispoofing, de parefeu SPI (Stateful Packet Inspection, comme on l'a vu au dessus), et de filet de sécurité quand mon VPN tombe, et il tombe plusieurs fois par an, et je log aussi les tentatives de spoofing, quasiment tous les jours... Et quasiment tous les jours Iptables les bloque. Donc bon, pour moi, Iptables, je ne ferai plus jamais sans, et je continuerai a en étudier tous les aspects, comme je le fais chaque jour. Parce que pour moi, c'est une brique de plus dans la sécurité informatique, et je ne vais pas enlever cette brique de mon réseau, elle est trop importante... Et je ne pense pas que l'utilisation que je fasse d'iptables soit inadapté, il fait tout ça parfaitement, il est conçu pour ça.

Dernière modification par robindesbois (Le 27/12/2014, à 19:20)

Hors ligne

#167 Le 27/12/2014, à 16:25

tiramiseb

Re : Configuration d'iptables

je dors beaucoup mieux de savoir qu'en cas de faille le service ne sera pas accessible depuis tous azimuts

Oui, donc si tu veux faire propre tu configures le service pour n'écouter que là où il doit écouter.

Toi, avec ton discours, tu prône le palliatif, tu proposes de laisser le service écouter là où il ne devrait pas, pour ensuite bloquer les paquets avec un pare-feu.

Hors ligne

#168 Le 27/12/2014, à 16:59

Compte supprimé

Re : Configuration d'iptables

tiramiseb a écrit :

Alors si ton VPN tombe, cette Interface VPN (tun0) tombe aussi, et Iptables ne la connaissant plus et sachant qu'il n'a le droit que de diffuser tous tes paquets destinné au NET via celle-ci, arrête immédiatement de balancer tous paquets

C'est sur ces aspects-là que tu es dans l'erreur.
Ce n'est ipas iptables qui connait (ou pas) les interfaces et qui balance (ou pas) les paquets.
C'est une question de table de routages (voire commandes "route -n" ou alors la plus récente "ip route"). Si les routes sont bien configurées, alors le pare-feu est inutile. C'est en cela que le pare-feu est un palliatif : il bloque des paquets qui n'auraient déjà jamais dû passer par là en premier lieu.

+1000 big_smile wink

robindesbois a écrit :

Donc pour moi, Iptables fait office d'antispoofing,

C'est en effet l'un des rares cas ou Iptables peut rendre service, tout comme pour un NAT ou PAT...

sirius007 a écrit :
ignus a écrit :
sirius007 a écrit :

...en frontal, j'utilise toujours iptables pour limiter les services accessibles, d'ailleurs j'en ai besoin aussi pour les autre tables (nat mangle raw) c'est pourtant pas compliqué à comprendre, qu'est ce que vous avez tous contre iptables ??

Rien du tout. Donne moi un accès à un service public de ton serveur et  ton Iptables, tu peux t'assoir dessus, il ne sert à rien big_smile Un pare-feu ne sécurise rien du tout, il masque des ports ou des services, point. Un port en écoute pour proposer un service, c'est une porte d'entrée. On s'occupe de sécuriser sa machine ou on pense que le pare-feu nous protège. Autrement dit, file moi un accès apache mal configuré (un site web en http quoi) et masque tout avec ton Iptables (sauf le 80 http), je te dis: Merci !

ÉDIT:

AH OUI, Fail2ban bannit les adresses IP ayant provoqué des erreur dans les journaux. Ce qui implique que quelqu'un en face à découvert un port et une faille et qu'il tente quelque chose. Si Fail2ban lance une action sur un autre port que celui-ci par défaut du SSH (22), c'est que portsentry c'est laissé faire et à laissé un scan de ports qu'il aurait dû bloquer !

réponse complètement hors sujet et incohérente à ce que j'ai évoqué bref charabia infecte à lire.
tous les professionnels intelligibles utilisent un parefeu avec une machine qui travaille directement en frontal à l'internet, non pas pour filtrer un service en écoute, mais pour rendre inaccessible ceux qui n'ont pas à communiquer avec l'extérieur.  c'est grave de faire cela docteur ? m'enfin quoi, c'est vous qui êtes dangereux de ne pas vouloir l'admettre.
Un système n'est jamais infaillible à l'instant t, et cela serait imprudent que de prétendre le contraire, et bien souvent les mises à jour de sécurité ne sont pas instantanées, mais après qu'un faille a été de-celée par les développeurs, je maintiens alors avec conviction que la mise en oeuvre d'un parefeu n'est pas de l'ignorance comme on voudrais le faire croire...

Si tu veux, je suis dangereux. Il y a de bonnes lectures sur la sécurisation des serveurs Gnu/Linux... Le chroot est plus efficace qu'un pare-feu sur les PEBKAC ou failles logicielles.
Mais fais comme tu veux, je me sers d'Iptables pour rerouter des paquets, vérifier des paquets mais jamais pour sécuriser mes serveurs. Et n'oublie jamais d'activer cette directive dans le noyau Linux via le /etc/sysctl.conf, sinon... big_smile

Dernière modification par ignus (Le 27/12/2014, à 17:07)

#169 Le 28/12/2014, à 11:22

tiramiseb

Re : Configuration d'iptables

parceque tu n'en a pas des discours, propos bien présomptueux

Je donne des détails techniques, des informations précis, des explications poussées.
Ce n'est pas un discours, c'est un argumentaire.

parfois

tiramiseb a écrit :

    mais dès qu'il y a écoute non voulue et non désactivable, je préfère bloquer avec le pare-feu.

et maintenant c'est le contraire

Tu as mal lu. Compilons mes arguments, encore une fois :
=> quand on logiciel écoute là où il ne devrait pas, on le configure (s'il doit écouter ailleurs) ou on l'enlève (s'il ne doit écouter nulle part) : dans ce cas, le pare-feu est un palliatif au manque de travail de l'administrateur ;
=> quand on ne peut pas le configurer pour qu'il n'écoute que sur une interface, alors je préfère mettre un pare-feu plutôt que de le laisser en écoute : dans ce cas, le pare-feu est un palliatif au comportement du logiciel.

respecte un peu la façon de faire de chacun

Ai-je montré une quelconque marque d'irrespect. Je subis des flopées d'attaques ad hominem, j'essaie de garder mon calme et de rester sur une argumentation technique... et c'est moi qui ne respecte pas !? C'est la meilleure !

une personne veut des informations concernant iptables et toi tu lui réponds <<c'est pas bien>>

Euh non, pas du tout. La question ne portait pas sur des informations concernant iptables, elle portait sur la protection que cela apportait.
Précisément, la question initiale était « J'aurai besoin de l'avis de la communauté pour savoir si mes règles d'iptables me protège vraiment ?? ». Et ma réponse restera toujours la même : Non, des règles iptables ne protègent pas : le pare-feu utilisé comme ça, c'est un palliatif, pas une sécurisation propre.

faut arrêter un peu avec cette espèce de  "despotisme"  <<monsieur qui sait tout mieux que tout le monde>>, et ben non tu n'as pas le monopole du savoir.

Quel despotisme ? Où ai-je dit que je sais tout mieux que tout le monde ? C'est parce que j'argumente mon point de vue que tu réagis comme ça ? C'est parce que j'essaie de n'être que factuel ? C'est parce que j'offre des heures et des heures de mon temps de travail au forum Ubuntu-fr ? Je devrais utiliser des attaques ad hominem et dire que vous êtes tous des cons, pour me mettre à votre niveau ? Non, désolé, je ne suis pas là pour ce genre d'attaques puériles : je suis là pour aider les gens et partager mes connaissances.

Je ne demande qu'à être contredit, avec des arguments techniques, des vraies raisons du pourquoi mon approche ne serait pas bonne. Si tu n'es pas d'accord, alors argumente et présente en quoi ce que j'explique ne te semble pas valable, plutôt que de me traiter de despote !

Je reviens donc sur l'argumentaire technique et te demanderai alors de préciser en quoi ta solution est meilleure. Je formule donc la question suivante :
Quand on ne souhaite pas qu'un logiciel soit joignable :
=> je préconise de dire aux logiciels de ne pas écouter, le pare-feu devenant alors inutile
=> tu préconises de ne pas configurer les logiciels, de les laisser en écoute et de mettre un pare-feu
En quoi la seconde solution est meilleure que la première ?

Dernière modification par tiramiseb (Le 28/12/2014, à 11:25)

Hors ligne

#170 Le 28/12/2014, à 12:04

tiramiseb

Re : Configuration d'iptables

oui le  parefeu est inutile si l'utilisation est lambda derrière un routeur (non précisé), nous somme bien d'accord.

Non, je ne parle pas d'un cas où l'utilisateur est derrière un routeur. Je parle bel et bien de la machine en elle-même.

mais notre discussion, (pour être clair) s'est porté pour une machine  directement en frontal à l'internet avec des services qui doivent restés local

Oui, on est bien d'accord et c'est de cela que je parle.

, et c'est bien la première fois que je lis qu'un parefeu est inutile (tous professionnels et entreprises confondus)

Pourtant on est plusieurs plusieurs, sur ce forum, à avoir cet avis...

bien sûr, bien souvent il est possible de configurer un service pour qu'il n'écoute que sur le lan ou localhost

C'est exactement ce que je préconise de faire. Chose que personne d'autre que moi n'a évoquée jusqu'ici.

en quoi iptables devient t'il gênant

Soyons clairs là aussi : bloquer un port particulier avec iptables, lorsque celui-ci n'est pas en écoute, ce n'est pas gênant, c'est juste inutile (c'est bien le mot que tu as utilisé plus, haut, quand tu as écrit « c'est bien la première fois que je lis qu'un parefeu est inutile »).

Ce qui me gêne énormément, c'est la tendance globale actuelle à préconiser systématiquement la mise en place d'un pare-feu, donnant aux utilisateurs un sentiment de sécurité qu'ils ne devraient pas avoir.
Ce n'est pas l'idée de mettre en place un pare-feu en elle-même, c'est ce que ça induit dans les esprits des gens. Malheureusement, énormément de gens ne pensent qu'aux aspects techniques et pas aux implications dans la vie réelle. As-tu pensé ce que pense la personne à qui tu dis « mets un pare-feu sur ton PC pour être en sécurité » ? Il faut "penser large", réfléchir aux interactions techniques, logiques ou psychologiques entre les différentes choses que l'on préconise.

Ce qui est également gênant pour l'utilisateur final, c'est qu'il n'a pas compris les implications et j'ai maintes fois dû aider des gens chez qui telle ou telle chose ne fonctionnait pas, pour finalement devoir expliquer comment fonctionne un pare-feu et pourquoi un serveur n'est pas joignable quand on a  bloqué tous les ports. Bien souvent, un pare-feu est une complication plutôt qu'une solution. Et en sécurité, tout le monde le sait : plus c'est compliqué, plus il y a de risques.

Enfin, tu peux relire tous mes messages, jamais je n'ai écrit « je préconise de ne pas mettre de pare-feu », je n'écrirai jamais ça. Par contre, j'ai écrit et je continuerai à écrire « un pare-feu est inutile » quand on parle d'un système où rien n'est en écoute (système Ubuntu de base, utilisé par un utilisateur lambda non bidouilleur) ou « un pare-feu est un palliatif » quand on parle de bloquer des ports en écoute (autant supprimer ou configurer le logiciel pour ne pas écouter lorsque c'est possible - c'est là que je dis que Samba me déçoit vu que pour nmbd on n'a pas le choix).

Dernière modification par tiramiseb (Le 28/12/2014, à 12:10)

Hors ligne

#171 Le 28/12/2014, à 13:32

Compte supprimé

Re : Configuration d'iptables

c'est là que je dis que Samba me déçoit vu que pour nmbd on n'a pas le choix

Le service smbd fournit des services de partage de fichiers et d'impression aux clients Windows. En outre, il est responsable de l'authentification des utilisateurs, du verrouillage des ressources et du partage des données par le biais du protocole SMB.
Le service nmbd comprend et répond à toutes les requêtes de service de nom NetBIOS telles que celles produites par SMB/CIFS dans des systèmes basés sur Windows.
Mais dans tous les cas, nmbd est contrôlé par le service smb. Seule solution efficace, virer les machines Windows du réseau est utiliser NFS big_smile
ÉDIT:
Ah bin, on peut faire du NFS avec Windows --> http://technet.microsoft.com/fr-fr/libr … 70569.aspx

Dernière modification par ignus (Le 28/12/2014, à 13:37)

#172 Le 29/12/2014, à 13:46

robindesbois

Re : Configuration d'iptables

ignus a écrit :
robindesbois a écrit :

Donc pour moi, Iptables fait office d'antispoofing,

C'est en effet l'un des rares cas ou Iptables peut rendre service, tout comme pour un NAT ou PAT...


Bonjour Ignus,

rien que sur la demie journée d'hier sur cette machine, 4 paquets DROPÉ sur la table raw directement, l'antispoffing est bien actif et on le voit utile, sur ce poste.

Copie écran :

141229124507972893.png

Hors ligne

#173 Le 29/12/2014, à 14:17

tiramiseb

Re : Configuration d'iptables

rien que sur la demie journée d'hier sur cette machine, 4 paquets DROPÉ sur la table raw directement

Oui, des paquets ont été bloqués, et alors ? Si ces paquets n'avaient pas été bloqués, que se serait-il passé ?
Il faut arrêter de faire croire qu'un paquet bloqué correspond à une attaque qui aurait réussi sans pare-feu.

Sans ce filtrage, il ne se serait probablement rien passé, ces paquets auraient été "perdus" tout simplement.
Si je donne des longs détails techniques on va encore me traiter de despote alors je ne détaillerai pas...

Hors ligne

#174 Le 29/12/2014, à 14:41

Haleth

Re : Configuration d'iptables

robindesbois a écrit :
ignus a écrit :
robindesbois a écrit :

Donc pour moi, Iptables fait office d'antispoofing,

C'est en effet l'un des rares cas ou Iptables peut rendre service, tout comme pour un NAT ou PAT...


Bonjour Ignus,

rien que sur la demie journée d'hier sur cette machine, 4 paquets DROPÉ sur la table raw directement, l'antispoffing est bien actif et on le voit utile, sur ce poste.

Copie écran :

http://nsa33.casimages.com/img/2014/12/29/141229124507972893.png


De quel "antispoofing" parles-tu, exactement ?
Est-ce que tu as un cas concret à proposer ?


Ubuntu is an ancien African word which means "I can't configure Debian"

Because accessor & mutator are against encapsulation (one of OOP principles), good OOP-programmers do not use them. Obviously, procedural-devs do not. In fact, only ugly-devs are still using them.

Hors ligne

#175 Le 29/12/2014, à 14:46

robindesbois

Re : Configuration d'iptables

Je sais ce que je fais avec Iptables, qui reste une brique de plus à la sécurité informatique prévue sous Ubuntu (mais pas activé comme vous le savez). Tor n'est pas inclu d'origine non plus, Thunderbird n'est pas paramétré d'origine non plus pour passer par ce Tor qui est manquant d'origine, et GNUPG est souvent absent aussi des distributions Linux. Une personne avertie des dangers potentiels,va utiliser ces derniers afin de chiffrer ses échanges avec ses proches et ainsi sécuriser leurs contenus, et sécuriser le protocole (en passant par Tor, qui est un protocol), de ce fait, les adresses IP sources de nos emails sont bien plus difficiles à trouver grâce à Tor, donc on ne pas pas laisser facilement n'importe quel quidam nous retrouver et ainsi tracer notre vie privée, et on ne pas las laisser n'importe quel quidam, avoir accès à l'intégralité de nos échanges car nos emaisl sont chiffrées. Au même titre qu'Iptables, Tor n'est pa sinstallé, Thunderbird n'est pas configuré pour passer par Tor, et pourtant ilsjouent un rôle essentiel au maintient de notre vie privée sur les réseaux, et notre sécurité (difficilement traçable via tor, et eamil illisibles grâce au chiffrement GNUPG).

Toujours est-il que cela ne reste que votre point de vue, vous qualifiez Ignus d'utilisateur confirmé au même niveau que vous (ici sur cette discussion), je le suis aussi, les personnes professionnelles qui me forment aussi, mais là, vous n'êtes plus d'accord avec lui, pourtant, je ne fait pas qu'affirmer des choses, je les prouve, et je donne un agrumentaire très détaillé de ce que les professionnels que l'ont trouve en dehors d'ici, savent au même titre qu'Ignus. Quand à savoir ce qu'il se serait probablement passé, si les tentatives de spoofing avaient abouti hier, j'aime mieux ne pas le savoir, et m'en prémunir à la source (table raw sur Iptables), qui est donc la table qui précède toutes les règles de la table -filter. Mais je pense que vous savez de quoi je parle.

Voilà, la sécurité, en informatique, ce n'est pas "ne pas utiliser" les fonctions de sécurité d'une machine informatique (ici le parefeu Iptables et Ubuntu), mais au contraire, les utiliser de façons éclairées, j'ai choisi la lumière comme vous le voyez et je donne toutes les infos aux gens. Je ne désire pas continuer sur cette discussion de Nathaly01, je m'en servirai pour faire un rappel de mon argumentaire lorsque le sujet sera réabordé sur d'autres discussions, je vous sohaite uen bonne journée et vous remercie encore de votre aide l'autre jour sur la commande Netstat, c'était très important pour moi, merci beaucoup pour cela.

Hors ligne