Pare feu ou pas ?

pires57 · Le 22/05/2013, à 23:22

bonsoir a tous,
@svi_binette :

pour tenter de contrer tant bien que mal certaines attaques, comme deni de services

je te conseille de regarder du coté de fail2ban

svi_binette · Le 22/05/2013, à 23:46

Bonsoir,

Merci, effectivement Fail2ban a l'air vraiment intéressant en complément de iptables!! J'avais entendu parler de Nessus, mais là, c'est un cran au dessus je trouve, on pourrait bannir une adresse ip pendant un laps de temps si le dans un log il y a de multiples erreurs d'authentifications, de façon automatique et souple...
Bon me voilà avec beaucoup de pistes à "creuser", c'est à dire tenter de comprendre vraiment pour ne pas trop faire de bêtise avec...
Merci infiniment à tous pour l'apprentissage.

pires57 · Le 23/05/2013, à 00:05

oui ou faire plusieur niveau.
je m'explique :
je rentre 3 fois (exemple) un mauvais mot de passe pour l'acces ssh, je me fait ban 5 minute. puis je me fait encore ban 2 autre fois dans un intervalle de 2h et donc le ban sera de 24h ...
bien sur toute les valeurs sont fausse, c'est simplement des exemples ...

Haleth · Le 23/05/2013, à 10:44

Je pense notamment au partage CIFS sous Windows, qui est rarement désactivé : si un utilisateur partage un répertoire sans le protéger, même temporairement, il sera alors accessible à la terre entière...

Bah, deux faits sont acquis:
1) les dos-users AIMENT faire tourner des softs inutiles. Parcque consommer plus d'énergie est bon, parcqu'acheter un PC puissant pour rien est bon
2) les dos-users AIMENT saboter leurs softs. Parcque se mettre des limites est bon

Du coup, ca ne gène pas outre mesure.

NB: si j'comprend bien, la dernière version de dos gère l'ipv6 ? bonne nouvelle ! :troll:

compte supprimé · Le 23/05/2013, à 12:49

Salut

J'ai lu beaucoup de choses et certaines s'avèrent, à mon sens, inexactes.

Si vous êtes derrière une box, effectivement, configurer un pare-feu n'est pas utile... Sauf si vous avez une utilisation nomade de votre pc (3G, wifi public)
Le pare-feu fait partit de la sécurisation d'une machine, c'est un des piliers... Bien entendu les distribs Linux ne sont pas codées avec les pieds, donc les ports sont fermés, nonobstant ce n'est pas si sécurisé que cela... Cela veut juste dire qu'aucun service ou processus ne tourne!

Pour répondre directement à la question pare-feu ou pas? Je dis oui! Sa fonction est de séparer par un mur votre réseau local du réseau internet... Mais ce mur est intelligent, on peut lui dire de laisser sortir vos requêtes (http mail etc) sans pour autant accepter les requêtes en provenance d'internet, c'est la configuration par défaut de UFW et cela me semble être le bon emploi pour une station de travail.
Faîtes donc sudo ufw enable et vous verrez que rien ne change pour votre connexion, en revanche votre pc devient invisible aux yeux des méchants. Bien entendu, si vous réalisez un partage de fichier à domicile ou d'imprimante avec samba, un simple ufw allow samba ouvrira les ports adéquates pour que votre partage continu à être accessible, on peut même lui dire de masquer ce partage du réseau internet et le montrer qu'en réseau local.

Le fonctionnement d'un pare-feu est complexe pour une gestion d'un serveur, on peut lui dire par exemple de laisser l’accès à votre serveur ftp que pour certaines ips ou hosts... Concrètement, on peut dire, s'il te plaît gentil pare feu, interdit toutes les ip mais laisse l'accès à mon serveur ftp pour mon ami qui à l'ip xxx.xxx.xxx.xxx pour... c'est modulable à souhait!
Fail2ban est un excellent complément pour contrer les attaques par "brute force", tout comme il existe le fichier Htaccess de apache qui lui aussi est capable de réaliser plein de chose... J'adore Snort, c'est un sniffer que je lance en IDS, les logs sont révélateurs... Comme vous le comprenez, la sécurité d'un serveur est un ensemble d'outil qui conjointement permettent une certaine sérénité!

Quelques tests valent mieux qu'un long discourt

Une debian prête à l'emploi (comme votre Ubuntu, je n'ai pas fait d'install minimum pour que tout soit comparable) sans parefeu directement sur internet (modem sans routeur, wifi public, 3G):

Verdict, machine potentiellement hackable.

La même Debian avec sudo ufw enable

C'est un peu mieux non?

Ce post est dédié à mon modo préféré

Dernière modification par Ignus (Le 23/05/2013, à 12:51)

tiramiseb · Le 23/05/2013, à 13:07

Salut Ignus,

Je ne suis pas d'accord avec toi.

Tu indiques qu'une machine qui a des ports fermés et non filtrés est "potentiellement hackable" : peux-tu expliquer comment un attaquant pourrait pénétrer une telle machine, si les ports concernés sont fermés ?
Pour toi, quelle est la différence entre un port fermé et un port filtré (appelé « masqué » dans l'outil Zebulon-fr que tu as utilisé), du point de vue d'une potentielle faille ?

Le pare-feu fait partit de la sécurisation d'une machine, c'est un des piliers...

Oui pour un pare-feu de réseau (donc pour la sécurité d'un réseau), non pour un pare-feu local (donc pour la sécurité d'une machine seule).

tout comme il existe le fichier Htaccess de apache qui lui aussi est capable de réaliser plein de chose

Le fichier .htaccess est à éviter autant que possible pour des questions de performance.
Donc dès qu'on a la main sur la configuration d'Apache, on désactive htaccess.

Haleth · Le 23/05/2013, à 13:09

Verdict, machine potentiellement hackable.

Verdict erroné: les ports sont fermés, donc personne ne peut les utiliser, personne ne les utilise, personne ne peut les utiliser, ils sont donc clairement non-hackable;

compte supprimé · Le 23/05/2013, à 13:17

@ tiramiseb

tiramiseb a écrit :

Oui pour un pare-feu de réseau (donc pour la sécurité d'un réseau), non pour un pare-feu local (donc pour la sécurité d'une machine seule).

Je ne crois pas que les devs de Iptables aient conçu un truc inutile. Étant utilisateur de BSD également, installe une pcbsd par exemple (très userfriendly), le pare feu est activé et paramétré par défaut pour une utilisation bureautique... Tâtonne du Freebsd ou du openbsd, c'est des prisons par défaut... Je veux un serveur chez moi qui soit accessible sur le net, je dois faire confiance à ma box ou à Iptables via UFw selon toi?
Pour héberger son propre serveur, il faut le mettre en DMZ pour qu'il soit accessible sur le web donc le pare feu de ma box ne filtre plus rien... À notre que le pare feu de la livebox est iptables
Désactiver le htaccess, c'est te priver de plein de bonne chose, ce n'est en tout cas pas le choix de OVH et 1 AND 1 pour ne citer que les deux hébergeurs de mes sites

Exemple de possibilité : http://openweb.eu.org/articles/le-fichier-htaccess

@ Haleth, quand tu fermes la porte de ta maison à clé, tu ne peux pas te faire cambrioler?

Dernière modification par Ignus (Le 23/05/2013, à 13:27)

tiramiseb · Le 23/05/2013, à 13:48

Ignus a écrit :

Je ne crois pas que les devs de Iptables aient conçu un truc inutile.

Je n'ai jamais dit que c'est inutile. Cela ne veut pas dire qu'il faut s'en servir tout le temps inconditionnellement.

Ignus a écrit :

installe une pcbsd par exemple (très userfriendly), le pare feu est activé et paramétré par défaut pour une utilisation bureautique... Tâtonne du Freebsd ou du openbsd, c'est des prisons par défaut...

Il existe également des distributions Linux qui sont "verrouillées" comme ça.
Cela ne veut pas dire que c'est indispensable.

Ignus a écrit :

Je veux un serveur chez moi qui soit accessible sur le net, je dois faire confiance à ma box ou à Iptables via UFw selon toi?

Si tu mets un serveur dispo derrière une box, tu fais une redirection d'un seul port. Il n'y a alors aucun intérêt à mettre un pare-feu, vu que le seul port accessible est le port que tu as besoin de rendre accessible.

Ignus a écrit :

Pour héberger son propre serveur, il faut le mettre en DMZ

Oui, il faut le mettre en DMZ.
Et le filtrage des communications entre Internet et la DMZ, c'est le pare-feu de réseau (passerelle) qui s'en charge.
Voir http://fr.wikipedia.org/wiki/Pare-feu_% … matique%29

Ignus a écrit :

le pare feu de ma box ne filtre plus rien...

Les box ne permettent pas de mettre en place une DMZ. La fonctionnalité appelée "DMZ" des box n'a rien à voir avec une DMZ, je déplore l'utilisation de ce terme dans ce cadre.

Une DMZ, c'est une zone totalement isolée du réseau interne.
La fonctionnalité des box, ce n'est pas une DMZ, c'est un open-bar : on donne accès à tous les ports d'une machine interne, sans la séparer du reste du réseau. La pire des choses à faire en matière de sécurité informatique d'un réseau.

Ignus a écrit :

Désactiver le htaccess, c'est te priver de plein de bonne chose

Bien sûr que non.

Le .htaccess, ça permet uniquement de modifier la configuration locale d'Apache lorsque l'on n'a pas accès aux fichiers de configuration d'Apache.
Toutes les directives utilisables dans un fichier .htaccess sont utilisables dans les fichiers de configuration d'Apache, cette dernière méthode est à préférer.

Les fichiers .htaccess induisent une surcharge du serveur.

ce n'est en tout cas pas le choix de OVH et 1 AND 1 pour ne citer que les deux hébergeurs de mes sites

L'hébergement mutualisé est le cas où le ".htaccess" peut être utile, car tu n'as pas toi-même accès aux fichiers de configuration d'Apache.

Ignus a écrit :

Exemple de possibilité : http://openweb.eu.org/articles/le-fichier-htaccess

Tu me donnes un document de référence, je vais t'en donner un autre :

GNU/Linux Magazine Hors Série n°66, titré "Apache", sorti il y a moins d'un mois, actuellement encore en kiosques. Celui-ci explique en quoi le fichier .htaccess est à éviter lorsque l'on le peut.
Oups, c'est moi qui l'ai écrit...

Ignus a écrit :

@ Haleth, quand tu fermes la porte de ta maison à clé, tu ne peux pas te faire cambrioler?

L'analogie du mur de la maison est une mauvaise analogie pour un pare-feu.

Le pare-feu, c'est le verrou qu'on met sur la porte ; une porte étant alors un port ouvert.
Un port fermé, c'est un mur.

Quand la maison n'est constituée que de portes murées (ports fermés) alors il n'est pas nécessaire de mettre un verrou dessus.

Dernière modification par tiramiseb (Le 23/05/2013, à 13:49)

compte supprimé · Le 23/05/2013, à 14:10

tiramiseb a écrit :

Je n'ai jamais dit que c'est inutile. Cela ne veut pas dire qu'il faut s'en servir tout le temps inconditionnellement.

Honnêtement, en 2013, l'utiliser est simplisme pour une Ubuntu. UFW enable et cela ne change rien pour M et Mme Michu qui peut utiliser son pc portable au MacDo ou ailleur... Qui plus est, ses connexions réseaux (sauf partage local) ne sont modifiés, ils masquent juste leur machine quand ils sont sur internet... Dès lors je ne comprends pas trop ce débat... Pourquoi s'en priver ?

tiramiseb a écrit :

Les box ne permettent pas de mettre en place une DMZ. La fonctionnalité appelée "DMZ" des box n'a rien à voir avec une DMZ, je déplore l'utilisation de ce terme dans ce cadre.
Une DMZ, c'est une zone totalement isolée du réseau interne.
La fonctionnalité des box, ce n'est pas une DMZ, c'est un open-bar : on donne accès à tous les ports d'une machine interne, sans la séparer du reste du réseau. La pire des choses à faire en matière de sécurité informatique d'un réseau.

Bin écoute, pour ma livebox, je me sers de cette Doc

tiramiseb a écrit :

Le pare-feu, c'est le verrou qu'on met sur la porte ; une porte étant alors un port ouvert.
Un port fermé, c'est un mur.

Je me permets simplement de te répondre à cette déclaration, ta perception du pare-feu est erronée... Par défaut les portes sont fermées sur une Gnu/Linux, cela ne veut pas dire que l'on ne peux pas entrer (par effraction). Mettre un pare-feu en amont, c'est simplement ne pas montrer à un attaquant potentiel que la porte existe et qu'elle est fermée par défaut.

Autrement dit : je joue les gros bras ou je me la joue discret?

Pour conclure mon message, je n'ai plus de noyaux Linux sur mes machines, je n'ai que du BSD avec les outils GNU de Debian (Debian Kfreebsd) et une Freebsd. C'est incomparable aux distros Linux userfriendly... J'ai beaucoup appris avec la communauté de Debian et la communauté BSD, je partage simplement mes expériences, je ne prétends pas quelles sont "vérités absolues".

À tous les nouveaux arrivants, n'oubliez pas de faire sudo ufw enable sur votre Ubuntu.

Je vous laisse.

Tschüssss!

Dernière modification par Ignus (Le 23/05/2013, à 14:11)

tiramiseb · Le 23/05/2013, à 14:26

Ignus a écrit :

Honnêtement, en 2013, l'utiliser est simplisme pour une Ubuntu. UFW enable et cela ne change rien pour M et Mme Michu qui peut utiliser son pc portable au MacDo ou ailleur... Qui plus est, ses connexions réseaux (sauf partage local) ne sont modifiés, ils masquent juste leur machine quand ils sont sur internet... Dès lors je ne comprends pas trop ce débat... Pourquoi s'en priver ?

Parce que c'est inutile, peut-être ?

En 2013, Un ordinateur sous Ubuntu n'écoute sur aucun port à part le client DHCP si nécessaire et le protocole Zeroconf.
Un pare-feu sur une machine qui n'a rien en écoute, c'est parfaitement inutile.

Par contre, un simple "ufw enable" va empêcher le protocole zeroconf, seul protocole en écoute par défaut, de fonctionner...
Et ça bloquera également les connexions CIFS entrantes lorsqu'un utilisateur partage un dossier sur le réseau : il devra alors en plus ouvrir un port.

Je vais donc tourner ta phrase dans l'autre sens : pourquoi s'en encombrer ?

Ignus a écrit :

Bin écoute, pour ma livebox, je me sers de cette Doc

Oui ben c'est ce que je dis, ce qui est décrit là n'est pas une DMZ. Encore une fois, je déplore l'utilisation de ce terme dans ce cadre.

Pour ma part, lorsque je pense à une DMZ, je me sers de mes cours de réseau et de sécurité ainsi que des plus de dix ans d'expérience professionnelle qui ont suivi...

Ignus a écrit :

Je me permets simplement de te répondre à cette déclaration, ta perception du pare-feu est erronée...

Sérieusement ? J'écris des articles sur les systèmes et la sécurité dans le magazine "Linux" leader en France, j'ai plus de 10 ans d'expérience dans le domaine, des centaines de clients contents... et ma perception est erronée ?

Ignus a écrit :

Par défaut les portes sont fermées sur une Gnu/Linux, cela ne veut pas dire que l'on ne peux pas entrer (par effraction).

Je vais donc reformuler la question à laquelle tu n'as pas répondu : comment on peut entrer par effraction par un port fermé ?
La réponse intéressera probablement ceux qui se demande comment on entre par effraction dans un système.
Et si tu arrives à donner une réponse sensée et étayée à cette question, peut-être que ma perception sera remise en question...

Ignus a écrit :

Mettre un pare-feu en amont, c'est simplement ne pas montrer à un attaquant potentiel que la porte existe et qu'elle est fermée par défaut.

Je vais te faire une confidence : les 65535 ports TCP et les 65535 ports UDP existent sur n'importe quel système qui dessert ces protocoles.
Un pirate n'est pas con (quoique, parfois on se demande ), un pirate sait comment le protocole marche, un pirate sait que tous ces ports existent.

Mais vu que tu parles de portes, c'est une analogie avec une maison. Ton analogie est erronée.
Un port fermé, ce n'est pas une porte fermée. Un port fermé, c'est un mur.
Un port filtré par un firewall, par contre, c'est une porte fermée.

Ignus a écrit :

Autrement dit : je joue les gros bras ou je me la joue discret?

gros bras = je mets un pare-feu pour montrer "héhé regarde, je filtre les ports" - le pirate y verra alors un challenge
discret = je ne mets pas de pare-feu, le pirate verra que les ports sont fermés et qu'il ne peut rien faire

Pour reprendre l'analogie de la maison :

sans pare-feu : lorsque l'on regarde ma maison, on voit plein de murs, aucune fenêtre et aucune porte : aucune chance de passer
avec pare-feu : lorsque l'on regarde ma maison, on voit 65535 portes cadenassées et on ne sait pas si derrière c'est muré : ça vaut peut-être le coup d'aller voir.

Ignus a écrit :

À tous les nouveaux arrivants, n'oubliez pas de faire sudo ufw enable sur votre Ubuntu.

À tous les nouveaux arrivants, ne prenez pas pour argent comptant une phrase dite comme ça sur un forum, renseignez-vous.
Cela ne veut pas dire qu'il faut prendre mes propos pour argent comptant ; faites marcher votre cerveau.

Dernière modification par tiramiseb (Le 23/05/2013, à 14:43)

compte supprimé · Le 23/05/2013, à 17:41

tiramiseb

Mes propos ne font que traduire mon expérience technique acquise auprès de plusieurs communautés (Debian et BSD), en aucun cas je suis apte à juger de tes qualiltés professionnelles ou celles du magazine que tu mentionnes, je partage seulement ma vision, je reste dans l'échange technique, c'est tout. Et pour ton info, je suis aussi admin réseau dans ma boite, cette fonction requière des formations régulières... :-)

tiramiseb a écrit :

Parce que c'est inutile, peut-être ?

Rhôôô comme tu y vas, lol : Gaffe quand même au nouveaux arrivants ;-)

tiramiseb a écrit :

gros bras = je mets un pare-feu pour montrer "héhé regarde, je filtre les ports" - le pirate y verra alors un challenge
discret = je ne mets pas de pare-feu, le pirate verra que les ports sont fermés et qu'il ne peut rien faire

Je le vois plutôt comme ça:

Tu mets un pare-feu pour que tes ports soient masqués, autrement dit, le vilain pas bô ne verra pas (avec un scanner par exemple) qu'il y a des portes fermées et ne sera pas tenté d'approfondir pour voir si les serrures tiennent le choc... Si pas de pare-feu, le scanner verra des portes fermées... Comme je l'ai écris plus haut, le pare-feu est un outil pour sécuriser avec d'autres logiciels, la sécurité est un état d'esprit global, donc ce genre de logiciel est complémentaire...

J'ai quitté les forums Linux car l'arrogance du Linuxien avancé empêche bien souvent les échanges (attend je sais faire ca alors si je te le dis c'est que c'est vrai)! Pour M et Mme Michu, un sudo ufw enable ne changera rien à ses connexions pour ses besoins internet (sauf partage local), alors pourquoi s'en priver surtout s'il est nomade? J'ai bien compris ta vision technique mais elle n'est pas mienne

Pour ta dernière interrogation:

tiramiseb a écrit :

Je vais donc reformuler la question à laquelle tu n'as pas répondu : comment on peut entrer par effraction par un port fermé ?
La réponse intéressera probablement ceux qui se demande comment on entre par effraction dans un système.
Et si tu arrives à donner une réponse sensée et étayée à cette question, peut-être que ma perception sera remise en question...

C'est abordé dans les formations d'admin réseau ou "certains forums spécialisés" ... . Savais tu que ce forum d'entre aide "Linux" est motorisé par du BSD? (Koala Web Server/2.4.0 (FreeBSD 6.2) Server at forum.ubuntu-fr.org Port 80). Pourquoi? Quels en sont les raisons...? Performance? Sécurité? Ils savaient pas installer une distrib "Linux"? Si je puis me permettre, les choix natifs sont différents. Avec Linux, c'est open bar par défaut et tu construis ton truc comme tu veux, avec BSD, c'est sécurisé par défaut... Je ne suis pas apte à juger si l'un vaut mieux que l'autre mais j'ai choisis BSD car je le trouve plus en cohérence avec mes formations...

Voilà mon ami, rien de personnel, juste un partage qui vaut ce qui vaut... Et comme je ne détiens pas la vérité, je me remets en cause pour progresser encore un peu plus dans les connaissances qu'offrent le logiciel libre à ses utilisateurs. ;-)

Hasta luego.

[Édit] Puisque tu es un user avancé, installe Snort sur ton pc et observe bien les logs... Moi ça me fait flipper *¿*

Dernière modification par Ignus (Le 23/05/2013, à 18:15)

tiramiseb · Le 23/05/2013, à 18:16

Ignus a écrit :

Je le vois plutôt comme ça:
Tu mets un pare-feu pour que tes ports soient masqués, autrement dit, le vilain pas bô ne verra pas (avec un scanner par exemple) qu'il y a des portes fermées et ne sera pas tenté d'approfondir pour voir si les serrures tiennent le choc... Si pas de pare-feu, le scanner verra des portes fermées... Comme je l'ai écris plus haut, le pare-feu est un outil pour sécuriser avec d'autres logiciels, la sécurité est un état d'esprit global, donc ce genre de logiciel est complémentaire...

Récapitulons le fonctionnement des ports TCP :

Un port ouvert, c'est un port sur lequel un processus est en écoute. Quand on essaie de s'y connecter, la connexion est acceptée et le port répond. Un pirate peut donc tenter d'exploiter une éventuelle faille du processus en écoute.

Un port fermé, c'est un port sur lequel rien n'est en écoute. Quand on essaie de s'y connecter, la connexion est explicitement refusée : on sait qu'il n'y a rien en écoute sur ce port, qu'on ne pourra pas s'y connecter, qu'il n'y a rien à exploiter (*). Un pirate se dira donc que ce n'est pas un moyen d'entrer.

Un port masqué (ou "stealth"), c'est un port sur lequel le pare-feu fait en sorte qu'il n'y ait jamais aucune réponse ; le seul moyen de "masquer" un port c'est par le pare-feu. Quand on essaie de s'y connecter, on a un timeout au bout d'un moment, aucune réponse : on ne sait donc pas si derrière il y a quelque chose en écoute, si le port est ouvert ou fermé (**). Un pirate se dira donc qu'il doit bien y avoir une raison pour "cacher" ce port, que c'est un truc à garder sous le coude pour essayer de l'exploiter d'une manière détourner ; « on ne sait jamais ».

Pour reprendre et recorriger ta mauvaise analogie avec la maison et les portes :

Avec le pare-feu (donc avec des cadenas partout), le vilain pas bô ne verra pas s'il y a une porte ouverte ou un mur derrière ; il sera donc tenté de creuser pour voir s'il peut faire sauter les serrures d'une manière détournée (***).
Sans pare-feu (donc avec des murs partout), le vilain pas bô verra qu'il n'a aucune chance de passer, il pourra laisser tomber.

(*) c'est là que je ne comprends pas ton propos et que j'ai réellement besoin d'une explication de ta part : un port fermé, c'est un port fermé, il n'y a aucun moyen de l'exploiter. Quel moyen d'exploiter un tel port vois-tu ?
(**) c'est expliqué ici : http://fr.wikipedia.org/wiki/Balayage_de_port
(***) la manière détournée, ça peut être une prise de contrôle d'un truc secondaire mal sécurisé, qui ne donne pas nécessairement un accès shell ou root, mais qui permet de se connecter sur des portes qui sont bloqués par le pare-feu en ce qui concerne les accès de l'extérieur ; ça peut aussi (et souvent) inclure du social engineering (****)
(****) eh ouais, la plupart des vraies attaques exploitent énormément le social engineering : PEBKAC dans la beaucoup de cas.

Ignus a écrit :

J'ai quitté les forums Linux car l'arrogance du Linuxien avancé empêche bien souvent les échanges

Quel est l'intérêt de mentionner cela ici ?

Pour M et Mme Michu, un sudo ufw enable ne changera rien à ses connexions pour ses besoins internet (sauf partage local), alors pourquoi s'en priver surtout s'il est nomade?

Parce que c'est inutile.

Ignus a écrit :

tiramiseb a écrit :
Je vais donc reformuler la question à laquelle tu n'as pas répondu : comment on peut entrer par effraction par un port fermé ?
La réponse intéressera probablement ceux qui se demande comment on entre par effraction dans un système.
Et si tu arrives à donner une réponse sensée et étayée à cette question, peut-être que ma perception sera remise en question...
C'est abordé dans les formations d'admin réseau ou "certains forums spécialisés" ...

Donc, aucune réponse étayée ? Un exemple ? Quelque chose ? Parce que non, je ne connais aucune formation où on parle de possibles attaques sur des ports fermés.
Là, sincèrement, je ne vois pas de quelle manière on peut vouloir pénétrer un serveur par un port fermé... Une explication de ta part serait utile.
(c'est une vraie requête, hein)

Ignus a écrit :

Savais tu que ce forum d'entre aide "Linux" est motorisé par du BSD? (Koala Web Server/2.4.0 (FreeBSD 6.2) Server at forum.ubuntu-fr.org Port 80). Pourquoi? Quels en sont les raisons...?

Peut-être parce qu'il est gracieusement hébergé par l'université de Nantes et que c'est l'administrateur système de l'université de Nantes qui fait son choix, indépendamment des préférences des administrateurs web et webmasters du site hébergé ?

Dernière modification par tiramiseb (Le 23/05/2013, à 18:24)

tiramiseb · Le 23/05/2013, à 18:19

Ignus a écrit :

[Édit] Puisque tu es un user avancé, installe Snort sur ton pc et observe bien les logs... Moi ça me fait flipper *¿*

Je connais Snort. Et je sais qu'il y a souvent des tentatives d'attaques.
Même pas besoin de Snort pour s'en rendre compte, on trouve des traces de ce genre de tentatives à plein d'endroits : logs de SSH, logs du serveur web, etc.

Mais il n'y a pas de raison de flipper : un port fermé c'est un port fermé et aucune attaque ne pourra réussir sur un tel port.
Il faut par contre rester vigilant sur les ports ouverts : les serveurs doivent être à jour, correctement sécurisées, etc. Et pour ça, le pare-feu n'est d'aucun secours.

Dernière modification par tiramiseb (Le 23/05/2013, à 18:25)

compte supprimé · Le 23/05/2013, à 19:00

:-)

tiramiseb a écrit :

(*) c'est là que je ne comprends pas ton propos et que j'ai réellement besoin d'une explication de ta part : un port fermé, c'est un port fermé, il n'y a aucun moyen de l'exploiter. Quel moyen d'exploiter un tel port vois-tu ?

Issue de la doc de Nmap

fermé (closed)
Un port fermé est accessible (il reçoit et répond aux paquets émis par Nmap), mais il n'y a pas d'application en écoute. Ceci peut s'avérer utile pour montrer qu'un hôte est actif (découverte d'hôtes ou scan ping), ou pour la détection de l'OS. Comme un port fermé est accessible, il peut être intéressant de le scanner de nouveau plus tard au cas où il s'ouvrirait. Les administrateurs pourraient désirer bloquer de tels ports avec un pare-feu, mais ils apparaîtraient alors dans l'état filtré décrit dans la section suivante.
filtré (filtered)
Nmap ne peut pas toujours déterminer si un port est ouvert car les dispositifs de filtrage des paquets empêchent les paquets de tests (probes) d'atteindre leur port cible. Le dispositif de filtrage peut être un pare-feu dédié, des règles de routeurs filtrants ou un pare-feu logiciel. Ces ports ennuient les attaquants car ils ne fournissent que très peu d'informations. Quelques fois ils répondent avec un message d'erreur ICMP de type 3 code 13 (« destination unreachable: communication administratively prohibited »), mais les dispositifs de filtrage qui rejettent les paquets sans rien répondre sont bien plus courants. Ceci oblige Nmap à essayer plusieurs fois au cas où ces paquets de tests seraient rejetés à cause d'une surcharge du réseau et pas du filtrage. Ceci ralenti terriblement les choses.

Donc tu dis vrai un port fermé n'est pas forcément attaquable mais il peut fournir des informations précieuses voir même un peu plus. Nikto est très performant sur la détection des OS, logiciels etc, dès lors si une faille logiciel apparait (exploit), tu la trouveras vite fait avec gout gueule des informations plus précises

Bref, un port fermé est donc inaccessible, mais visible. Un pirate peut dans ce cas tenter une attaque sur la machine qu’il voit, en cherchant une autre vulnérabilité. Si les ports sont masqués, cela signifie que le port est invisible. Si tous les ports sont masqués, le PC est invisible (le cas de M et Mme Michu avec UFW enable).

D'ou ma question, pourquoi s'en priver?
:-)

Dernière modification par Ignus (Le 23/05/2013, à 19:11)

compte supprimé · Le 23/05/2013, à 19:21

tiramiseb a écrit :

Il faut par contre rester vigilant sur les ports ouverts : les serveurs doivent être à jour, correctement sécurisées, etc. Et pour ça, le pare-feu n'est d'aucun secours.

Ok que si, avec un pare-feu, tu peux controler qui accedera à ton serveur ssh pour administrer ta machine. tu peux dire au pare-feu, s'il te plaît mon mignon, laisse passer tel host ou tel ip, les autres tu les interdis! C'est un bon complément avec un bon mot de passe pour ton serveur SSH, un ssh.conf au petit oignon, fail2ban et changement du mot de passe régulier

Comme je le dis, un pare feu est complémentaire... Tu as raison quant à utiliser un serveur à jour!

:-)

tiramiseb · Le 23/05/2013, à 19:45

Donc tu dis vrai un port fermé n'est pas forcément attaquable mais il peut fournir des informations précieuses voir même un peu plus.

La façon qu'a le système d'exploitation de répondre lorsqu'un port est fermé permet de deviner quel est le système d'exploitation, en effet. Chacun a sa "signature". Mais s"appuyer là-dessus pour « sécuriser » son serveur, ça ce n'est rien d'autre que de la sécurité par l'obscurité. http://fr.wikipedia.org/wiki/S%C3%A9cur … urit%C3%A9

dès lors si une faille logiciel apparait (exploit)

Une faille logicielle ne peut pas apparaître vu qu'il n'y a pas de logiciel en écoute.
Il peut éventuellement y avoir une faille du noyau, ça s'est déjà vu, mais c'est rare. Et une telle faille serait valable sur n'importe quel port.

Si les ports sont masqués, cela signifie que le port est invisible

Je ne comprends pas ce concept de "invisible". Un port n'est pas visible ou invisible. Un port est toujours là. Un port ne disparaît pas. Dans tous les cas tu donnes une information au pirate. Le mur d'une maison n'est pas invisible, le cadenas non plus. Tu montres de toute manière quelque chose. Ne pas envoyer de réponse, c'est déjà une information.

Si tous les ports sont masqués, le PC est invisible (le cas de M et Mme Michu avec UFW enable).

Non car il y aura toujours soit des traces d'activité du PC, soit une réponse au ping, soit d'autres choses...
Un PC totalement furtif, c'est une utopie.

avec un pare-feu, tu peux controler qui accedera à ton serveur ssh pour administrer ta machine

Oui, c'est ce que j'ai déjà évoqué plus haut, tu peux faire un filtrage par adresse IP source. J'ai même indiqué que c'est un des cas où effectivement un pare-feu peut être utile. Mais là tu parlais de l'activation systématique d'un pare-feu chez madame Michu.

un bon mot de passe pour ton serveur SSH, un ssh.conf au petit oignon, fail2ban et changement du mot de passe régulier

fail2ban n'est pas indispensable.
la configuration par défaut de ssh de certaines distributions (Ubuntu, Debian notamment) est satisfaisante.
Pour une vraie sécurité, les mots de passe sont à bannir. Rien ne vaut les clés SSH.
Et le changement régulier de mot de passe, c'est un miroir aux alouettes.
Le changement régulier de mot de passe induit une simplification des mots de passe, c'est humain : personne ne souhaite et peu de monde est capable de régulièrement se souvenir d'un nouveau mot de passe.

Tiens, en matière de sécurité de mot de passe, je ne résiste pas à citer XKCD : http://xkcd.com/936/

svi_binette · Le 23/05/2013, à 22:09

Bonsoir,

Je me permets d'intervenir en tant que représentante des Mme Michu.
Pour ma part le message précédent de Tirmiseb est pour moi vraiment convaincant et je partage aussi son point de vue que trop se camoufler peut attirer l'attention, mais ça je pense que c'est subjectif.

En tant que mme Michu, je vois tout de même un avantage au pare-feu comme iptable sur la machine derrière une box : celui que mme Michu vit souvent en famille et qu'une box se partage. Ce qui est moins le cas du pare-feu sur la machine.
Je peux témoigner du fait qu'il est assez difficile de refuser longtemps de donner l'accès au mot de passe de l'administration de la box à ses enfants ados qui jouent, invitent des copains qui se connectent en wifi, montent des serveurs de jeux etc.. sans savoir le faire correctement. Qui peuvent créer une règle sur le mauvais pc et en refaire une autre car la première ne marche pas.
Du controle ok bien sûr mais je pense qu'il est un peu illusoire de vouloir tout contrôler (à moins d'être un expert)
Un erreur est si vite arrivée.

Mme Michu comme tout le monde commet l'erreur très fréquente de ne pas se méfier assez des dangers qui viennent de l'intérieur, encore moins s'il s'agit de ses enfants.

compte supprimé · Le 23/05/2013, à 23:05

tiramiseb a écrit :

Donc tu dis vrai un port fermé n'est pas forcément attaquable mais il peut fournir des informations précieuses voir même un peu plus.
La façon qu'a le système d'exploitation de répondre lorsqu'un port est fermé permet de deviner quel est le système d'exploitation, en effet. Chacun a sa "signature". Mais s"appuyer là-dessus pour « sécuriser » son serveur, ça ce n'est rien d'autre que de la sécurité par l'obscurité. http://fr.wikipedia.org/wiki/S%C3%A9cur … urit%C3%A9
Oui si tu veux, c'est ton droit de penser cela
dès lors si une faille logiciel apparait (exploit)
Une faille logicielle ne peut pas apparaître vu qu'il n'y a pas de logiciel en écoute.
Il peut éventuellement y avoir une faille du noyau, ça s'est déjà vu, mais c'est rare. Et une telle faille serait valable sur n'importe quel port.
Oui pour n'importe quel port mais relis bien mes posts (Bref, un port fermé est donc inaccessible, mais visible. Un pirate peut dans ce cas tenter une attaque sur la machine qu’il voit, en cherchant une autre vulnérabilité)

Si les ports sont masqués, cela signifie que le port est invisible
Je ne comprends pas ce concept de "invisible". Un port n'est pas visible ou invisible. Un port est toujours là. Un port ne disparaît pas. Dans tous les cas tu donnes une information au pirate. Le mur d'une maison n'est pas invisible, le cadenas non plus. Tu montres de toute manière quelque chose. Ne pas envoyer de réponse, c'est déjà une information.
Je te renvoie sur la doc de Nmap ou sur le guide de OVH :-)
On a en fait deux choix ou niveau de cette règle. Soit on droppe les paquets, c'est-à-dire que si un paquet arrive et qu'il n'est pas accepté on l'efface. Le client attendra de son côté une réponse en vain, jusqu'au timeout. La deuxième solution est de rejeter les paquets (REJECT au lieu de DROP). Si un paquet non solicité arrive, on renvoie au client une erreur et il n'attend plus car il a une réponse négative. Rejeter les paquets est plus propre mais les jeter est plus securisé. En effet, imaginons quelqu'un qui vous envoie des paquets à répétition sur un mauvais port, votre serveur ne les traîtera pas, alors qu'avec la regle reject, il prendra le temps de répondre.
À vous de voir --> http://guide.ovh.com/fireWall

Si tous les ports sont masqués, le PC est invisible (le cas de M et Mme Michu avec UFW enable).
Non car il y aura toujours soit des traces d'activité du PC, soit une réponse au ping, soit d'autres choses...
Un PC totalement furtif, c'est une utopie
Bah regarde un exemple avec mon test chez zebulon ou test ton pc avec Nmap, l'un renvoi quelque chose et l'autre non (tu peux désactiver le ping avec Iptables si tu n'es pas joueur)
avec un pare-feu, tu peux controler qui accedera à ton serveur ssh pour administrer ta machine
Oui, c'est ce que j'ai déjà évoqué plus haut, tu peux faire un filtrage par adresse IP source. J'ai même indiqué que c'est un des cas où effectivement un pare-feu peut être utile. Mais là tu parlais de l'activation systématique d'un pare-feu chez madame Michu.
Pour M et Mme Michu, l'option d'un pare-feu est tout aussi envisageable pour une utilisation familiale et cerise, cela les amènera à comprendre un peu mieux ce qu'est un firewall, j'y vois un aspect pédagogique.
un bon mot de passe pour ton serveur SSH, un ssh.conf au petit oignon, fail2ban et changement du mot de passe régulier
fail2ban n'est pas indispensable. --> oui mais j'aime bien les truc inutiles, c'est mon héritage de BSD
la configuration par défaut de ssh de certaines distributions (Ubuntu, Debian notamment) est satisfaisante. --> Arf, de mémoire la config de SSH permet par defaut un acces root avec le login sur une Debian Squeeze, ce n'est pas très sécure!--> PermitRootLogin yes
Pour une vraie sécurité, les mots de passe sont à bannir. Rien ne vaut les clés SSH. --> j'avais oublier de citer ce procéder, merci d'y avoir pensé
Et le changement régulier de mot de passe, c'est un miroir aux alouettes.
Le changement régulier de mot de passe induit une simplification des mots de passe, c'est humain : personne ne souhaite et peu de monde est capable de régulièrement se souvenir d'un nouveau mot de passe.
Tiens, en matière de sécurité de mot de passe, je ne résiste pas à citer XKCD : http://xkcd.com/936/--> Merci pour le lien
Pour résumer on peut penser qu'un pare-feu est facultatif puisque Linux est fermés par défaut mais on peut penser qu'un pare-feu est utile pour masquer son pc, chacun y trouvera sa définition.
Nonobstant, puisque ce genre de logiciel participe à la sécurisation avec d'autres logiciels et stratégies, pourquoi s'en priver? En plus cela permet d'apprendre pour un néophyte, moi j'y vois que du bonus...! Pour moi, ne pas envoyer de réponse, c'est escompter que le vilain pas bô passera son chemin et cherchera dans les logs de son scanner une ip qui donne une réponse... Même négative!
J'en conviens, un pare-feu n'est pas infaillible, tu peux le contourner par dessus via un appel de CreateRemoteThread et par le dessous via une bibliothèque adaptée (pcap)... Penser qu el'on risque rien parce que les ports sont fermés, c'est déjà un trou de sécurité...
Voili voilou, chacun fait comme il veut
Mes amitiés.
Ignus.

Dernière modification par Ignus (Le 23/05/2013, à 23:11)

Haleth · Le 23/05/2013, à 23:55

Je ne crois pas que les devs de Iptables aient conçu un truc inutile

Parcque tu penses que iptables est fait pour drop des paquets, alors que ce n'est qu'une partie ridiculeusement minime du potentiel de l'outil;

@ Haleth, quand tu fermes la porte de ta maison à clé, tu ne peux pas te faire cambrioler?

Je peux, mais mettre un cadenas sur la serrure ne change rien. De même que mettre un écriteau "ne pas cambrioler, merci";

Par défaut les portes sont fermées sur une Gnu/Linux, cela ne veut pas dire que l'on ne peux pas entrer (par effraction)

Ben si, c'est exactement ce que cela veux dire. Ou alors, tu n'as pas confiance dans le noyau Linux, tu penses que ce dernier est buggé et à un comportement non fiable. Dans ce cas, ce baser sur iptables pour "rationnaliser" ce comportement est étrange (iptables = netfilter = Linux); D'ailleurs, utiliser un noyau que tu sais "être buggé" n'est pas vraiment logique;

Ok que si, avec un pare-feu, tu peux controler qui accedera à ton serveur ssh pour administrer ta machine. tu peux dire au pare-feu, s'il te plaît mon mignon, laisse passer tel host ou tel ip, les autres tu les interdis! C'est un bon complément avec un bon mot de passe pour ton serveur SSH, un ssh.conf au petit oignon, fail2ban et changement du mot de passe régulier

Hmpf, ouais, c'est une raison valable
Personnelement, j'aime pas ce genre de pratique (autorisé ssh juste pour certaines IP), parcque t'es chiant
Ca m'empêche d'aller sur la machine, indépendament de ma localisation géographique et de ma connexion
M'enfin, pourquoi pas
(en fait, j'trouve que c'est le même genre d'idée que de faire tourner ssh sur un autre port .. à part faire chier, y'a pas de bénéfices)

http://xkcd.com/936/

:love:

Je te renvoie sur la doc de Nmap ou sur le guide de OVH :-)

nmap: c'est ca raison d'être, pour beaucoup
OVH: si c'est écrit par des "experts".. (j'allais écrire: comme toi, mais j'me retiens :troll)

En effet, imaginons quelqu'un qui vous envoie des paquets à répétition sur un mauvais port, votre serveur ne les traîtera pas, alors qu'avec la regle reject, il prendra le temps de répondre.

Pff, mouais, mais franchement ?
Si le but est d'arriver à ce niveau d'économie, le best est de nullrouter les IP;

la configuration par défaut de ssh de certaines distributions (Ubuntu, Debian notamment) est satisfaisante. --> Arf, de mémoire la config de SSH permet par defaut un acces root avec le login sur une Debian Squeeze, ce n'est pas très sécure!--> PermitRootLogin yes

Franchement !
En quoi c'est pas sécurisé ? En quoi sudo est plus sécurisé ?
Ou alors, c'est parcque le fait de rajouter les 10char du login augmente considérablement le temps de brute-force ?
Bénéfice: illusoire
Réalité: casse-couille de switch continuellement entre user machin et root (via sudo ? via su - & co ?); Et pour faire des scp etc, ca doit être pratique tien

Enfin bref, j'ai l'impression de voir un clone du java, orienté system & réseau.
Un argumentaire basé sur de potentiels supputations et des architectures obèses, juste pour faire plaisir à certains.

tiramiseb · Le 24/05/2013, à 09:23

svi_binette a écrit :

l'erreur très fréquente de ne pas se méfier assez des dangers qui viennent de l'intérieur

C'est quelque chose qu'il faut garder en tête également : dans énormément de cas (piratages etc), la source du danger est à l'intérieur...

Ignus : ta manière de répondre en #44 est assez pénible à lire, c'est dommage : tu as tout mis dans un bloc citation, avec tes commentaires en italique au sein de mon message cité et tu termines même par une partie qui n'est pas en italique ; quelqu'un qui lit ça pour la première fois peut penser que tu en fais que citer mes propos, c'est un peu ennuyeux. Cela étant dit, retournons à notre petite discussion

Ignus a écrit :

un port fermé est donc inaccessible, mais visible. Un pirate peut dans ce cas tenter une attaque sur la machine qu’il voit, en cherchant une autre vulnérabilité

Pour moi, ne pas envoyer de réponse, c'est escompter que le vilain pas bô passera son chemin et cherchera dans les logs de son scanner une ip qui donne une réponse...

Ok, avec tout ça, je vois un peu plus clair dans ta réflexion. Ce que tu dis, c'est qu'un port non "masqué" fait qu'un pirate sait qu'"on est là". Tu te places dans le cas où le pirate tente de se connecter "au petit bonheur la chance", en faisant des scans de ports sur un nombre important d'adresses. Dans ce cas, en effet, si on ne répond pas au ping et que tous les ports sont masqués, le pirate ne verra pas la machine et passera à une autre qui sera, peut-être, plus facile à "pirater". Mais ce n'est qu'un seul et unique cas d'attaque possible, c'est d'ailleurs bien plus l'apanage des script kiddies et des spammeurs (etc) qui ne cherchent qu'à pénétrer "'n'importe quoi", soit pour s'amuser (script kiddie) soit pour exploiter la machine à distance (spammeur, etc).
Bien sûr, à partir du moment où un seul port est ouvert c'est mort, on n'est plus "furtif" et on sera vu par le pirate en question.

Mais ni le script kiddie ni le spammer n'a envie de se creuser les méninges pour pénétrer une machine : après un test sommaire pour voir s'il y a une faille connue, l'un comme l'autre ira voir ailleurs s'il ne peut pas pénétrer, car la machine en question n'est pas directement ciblée par l'attaque, et il y a tellement de machines non sécurisées qu'il est plus rentable de trouver une autre machine non sécurisée. Cela même si les ports sont fermés au lieu d'être "masqués".

Il faut aussi prendre en compte les nombreux cas où l'attaque est ciblée, les cas où le pirate sait qui il veut pirater (espionnage industriel, etc) et qu'il fera tout pour pénétrer une machine. Un pare-feu "masquant" les ports ne sera d'aucun secours (en tout cas, ça ne protégera pas plus que des ports fermés) car le pirate tentera de toute façon de pénétrer, au moins par un moyen détourné.

Comme l'indique le guide d'OVH dont tu parles, il y a en effet également la question du DoS : si on DROP les paquets, alors le noyau mettra moins de temps à les traiter que s'il devait envoyer une réponse à chacun. On est donc moins sensibles aux DoS. Mais il y a bien d'autres manières (plus dynamiques) de se protéger des DoS, fail2ban en étant une (*).

(*): fail2ban, comme de nombreux autres outils, exploite les fonctionnalités de Netfilter, bien sûr : encore une fois, je ne dis pas que Netfilter est inutile. Mais recadrons encore une fois la discussion : toi tu sembles militer pour l'activation du filtrage (notamment avec UFW) systématiquement, chez tout le monde. C'est cela que je trouve inutile, et non l'existence même des firewalls (qui sont bien sûr utiles dans de nombreux cas).

Bah regarde un exemple avec mon test chez zebulon ou test ton pc avec Nmap, l'un renvoi quelque chose et l'autre non (tu peux désactiver le ping avec Iptables si tu n'es pas joueur)

Le test de base de nmap que le test sur zebulon-fr sont tous les deux très réduits, ils ne testent qu'un certain nombre de ports et un peu d'ICMP (**).
Ce n'est pas parce que la configuration standard de nmap ou le site zebulon-fr ne trouvent rien qu'un pirate aguerri ne trouvera rien.

(**): un vrai test, effectué par un pirate motivé, sur une machine bien ciblée, ça peut prendre des heures, voire des jours. Et pas quelques secondes comme le test de zebulon-fr, qui n'est qu'un petit test limité.

de mémoire la config de SSH permet par defaut un acces root avec le login sur une Debian Squeeze, ce n'est pas très sécure!--> PermitRootLogin yes

En quoi n'est-ce pas très "secure" ? Ce qui n'est pas secure, c'est d'utiliser un mot de passe faillible.

Autoriser la connexion en SSH en root sur une machine ne diminue pas sa sécurité. Désactiver ce paramètre dans un but "sécuritaire", c'est un miroir aux alouettes.
D'ailleurs, dans l'inconscient de l'administrateur, il se dira "personne ne peut accéder au compte root, je peux baisser la sécurité du mot de passe" : baisse de la sécurité, c'est l'inverse de l'effet recherché.

on peut penser qu'un pare-feu est utile pour masquer son pc

On peut le penser.
D'une part, pour le seul cas où je vois que cela aurait une quelconque utilisé, en fait masqué ou non l'attaquant s'en fiche car il abandonnera bien vite s'il ne trouve pas de faille évidente.
D'autre part, si l'attaque est ciblée, aucune technique ne pourra réellement masquer le PC, à part le débrancher...

puisque ce genre de logiciel participe à la sécurisation avec d'autres logiciels et stratégies, pourquoi s'en priver?

Parce qu'un logiciel mal utilisé peut avoir des effets de bord qui ne sont pas nécessairement bénéfiques.
Parce qu'un logiciel de plus, ça fait des possibilités de faille en plus.
Parce qu'un pare-feu, ça se gère ou ça ne s'utilise pas.

Penser qu el'on risque rien parce que les ports sont fermés, c'est déjà un trou de sécurité...

Lorsque tous les ports sont fermés, on ne risque aucune attaque par le biais de ces ports. C'est un fait.

Tant qu'on est connecté à un réseau, penser que l'on ne risque rien (quelle que soit la sécurisation qu'on a mise en place) c'est déjà un trou de sécurité... Malheureusement beaucoup croient que "ah voilà, le pare-feu est activé, je ne risque rien" après avoir lu des argumentaires comme le tien... Pour ma part j'explique en quoi le pare-feu sur la machine Ubuntu de madame Michu ne lui apporte rien et dans quelles situations ça peut en effet l'aider.

compte supprimé · Le 24/05/2013, à 10:52

En tout cas, merci à vous deux (et aux autres), pour cette file très instructive !

compte supprimé · Le 24/05/2013, à 11:11

Excusez moi, j'ai merdouillé dans mon post #44

tiramiseb a écrit :

Malheureusement beaucoup croient que "ah voilà, le pare-feu est activé, je ne risque rien" après avoir lu des argumentaires comme le tien...

Non si tu relis mes posts, j'ai écris que c'était une sécurité supplémentaire, le "ah voilà, le pare-feu est activé, je ne risque rien" est ton interprétation, pas la mienne.
Pour moi, un sudo UFW enable ne changera rien pour les connexions internet de M et Mme Michu, si ce n'est qu'ils devront ouvrir le port de leur partage réseau s'ils en ont un... Et puis comme écrit plus haut, ça mange pas de pain

haleth a écrit :

Franchement !
En quoi c'est pas sécurisé ? En quoi sudo est plus sécurisé ?
Ou alors, c'est parcque le fait de rajouter les 10char du login augmente considérablement le temps de brute-force ?
Bénéfice: illusoire
Réalité: casse-couille de switch continuellement entre user machin et root (via sudo ? via su - & co ?); Et pour faire des scp etc, ca doit être pratique tien
Enfin bref, j'ai l'impression de voir un clone du java, orienté system & réseau.
Un argumentaire basé sur de potentiels supputations et des architectures obèses, juste pour faire plaisir à certains.

tiramiseb a écrit :

En quoi n'est-ce pas très "secure" ? Ce qui n'est pas secure, c'est d'utiliser un mot de passe faillible.
Autoriser la connexion en SSH en root sur une machine ne diminue pas sa sécurité. Désactiver ce paramètre dans un but "sécuritaire", c'est un miroir aux alouettes.
D'ailleurs, dans l'inconscient de l'administrateur, il se dira "personne ne peut accéder au compte root, je peux baisser la sécurité du mot de passe" : baisse de la sécurité, c'est l'inverse de l'effet recherché.

Concernant SSH, voici un exemple de doc --> Debian et la sécurité Pour PermitRootLogin yes, faut le mettre à no. Ne pas autoriser de connexion en tant que root. Si quelqu'un veut devenir root via ssh, deux logins sont maintenant nécessaires et le mot de passe root ne peut être attaqué par la force brute via SSH:

On peut aussi changer le port d'écoute, ainsi l'intrus ne peut être complètement sûr de l'exécution d'un démon sshd (soyez prévenus, c'est de la sécurité par l'obscurité) dans le sshd.conf
Aïe, tiramiseb va me tomber dessus

Pour récapituler, aucune sécurité est parfaite et chaque admin réseau à sa technique pour sécuriser... Moi je préfère l'approche Debian et surtout celle de BSD maintenant vous avez votre propre approche et c'est bien légitime. Encore une fois je ne juge rien mais si un lecteur parcours ce thread, nos échanges lui permettront sans doute de faire un Mix et c'est le plus important non?

Allez zou, je passe à autre chose.

Yep!

Dernière modification par Ignus (Le 24/05/2013, à 12:02)

Haleth · Le 24/05/2013, à 13:15

Du coup, j'ai essayé snort, c'est franchement décevant

En une paire d'heure de temps, il m'a craché plein d'annonce "danger", parcque je ping une autre machine .. à chaque ping, hop une alerte (et à chaque ICMP reply également)

Le danger du truc est vraiment contestable ..

Après, il m'a alerté sur le fait que certain paquet ont la même source/dest (priorité 2, high)
Bon, c'est cool, le protocole DHCP est un danger .. (0.0.0.0:68 -> 255.255.255.255:67)

Bref, outil très décevant, à mes yeux
Beaucoup d'alerte pour rien, beaucoup de bruits pour rien (Sheakspeare!)

J'me demande si, un jour, il peut me donner des trucs intéressants. Mais si, pour obtenir ces infos, je dois parser des millions de lignes sans intérêt, non, merci

tiramiseb · Le 24/05/2013, à 14:42

Ignus a écrit :

Concernant SSH, voici un exemple de doc --> Debian et la sécurité Pour PermitRootLogin yes, faut le mettre à no. Ne pas autoriser de connexion en tant que root. Si quelqu'un veut devenir root via ssh, deux logins sont maintenant nécessaires et le mot de passe root ne peut être attaqué par la force brute via SSH:

Et en quoi ça apporte plus de sécurité ? Ça apport plus de contrainte, oui, mais pas plus de sécurité.

Concernant l'attaque par force brute du mot de passe, pour ma part je suis totalement immunisé vu que le mot de passe du compte root est verrouillé (avec la commande "passwd -l" notamment) : seule l'authentification par clé est possible.
Et j'estime que tous ceux qui s'occupent de la sécurité de leurs serveurs devraient faire comme ça, avant même de penser au pare-feu.

Ignus a écrit :

On peut aussi changer le port d'écoute, ainsi l'intrus ne peut être complètement sûr de l'exécution d'un démon sshd (soyez prévenus, c'est de la sécurité par l'obscurité)

Ben oui c'est clairement de la sécurité par l'obscurité, vu qu'il suffit de scanner les ports et de se connecter à tous les ports ouverts pour savoir ce qu'ils répondent :

sebastien@cao:~$ telnet <serveur> 22
Trying 88.191.185.95...
Connected to <serveur>
Escape character is '^]'.
SSH-2.0-OpenSSH_6.0p1 Debian-4

Là c'est sur le port 22, mais le comportement serait le même
Une telle "protection", ça ne tient pas deux minutes face à un pirate qui a vraiment l'intention de rentrer sur une machine particulière

Par contre, il y a beaucoup de tentatives de connexion SSH automatiques, généralement de la part de script kiddies : celles-ci tentent les combinaisons utilisateur / mot de passe courantes... En mettant SSH sur un autre port, on peut les éviter (car ces tentatives sont particulièrement bêtes et se concentrent sur le port standard ; rappelons-le, l'intérêt pour l'attaquant n'est pas de rentrer sur une machine précise mais de rentrer sur un maximum de machines, en exploitant les paramètres par défaut ou très utilisés : si on change le port de 22 à 222, par exemple, le couple user/mot de passe n'est probablement pas "admin/admin" : on est au niveau au-dessus
Avec fail2ban on peut également facilement bloquer ce genre d'attaques.

aucune sécurité est parfaite et chaque admin réseau à sa technique pour sécuriser...

Tout à fait d'accord. La sécurité d'un système réside surtout dans le fait qu'il doit être géré, maintenu, mis à jour, supervisé, etc...

je préfère l'approche Debian

Je croyais que tu n'aimais pas la configuration par défaut d'OpenSSH sur Debian ...

Et puis sur Debian, il n'y a pas de pare-feu par défaut...

si un lecteur parcours ce thread, nos échanges lui permettront sans doute de faire un Mix et c'est le plus important non?

C'est clairement un grand intérêt de ce genre de discussions, oui.

Je pense que rifix, svi_binette et sogyam confirmeront

Dernière modification par tiramiseb (Le 24/05/2013, à 14:59)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 22/05/2013, à 23:22

Re : Pare feu ou pas ?

#27 Le 22/05/2013, à 23:46

Re : Pare feu ou pas ?

#28 Le 23/05/2013, à 00:05

Re : Pare feu ou pas ?

#29 Le 23/05/2013, à 10:44

Re : Pare feu ou pas ?

#30 Le 23/05/2013, à 12:49

Re : Pare feu ou pas ?

#31 Le 23/05/2013, à 13:07

Re : Pare feu ou pas ?

#32 Le 23/05/2013, à 13:09

Re : Pare feu ou pas ?

#33 Le 23/05/2013, à 13:17

Re : Pare feu ou pas ?

#34 Le 23/05/2013, à 13:48

Re : Pare feu ou pas ?

#35 Le 23/05/2013, à 14:10

Re : Pare feu ou pas ?

#36 Le 23/05/2013, à 14:26

Re : Pare feu ou pas ?

#37 Le 23/05/2013, à 17:41

Re : Pare feu ou pas ?

#38 Le 23/05/2013, à 18:16

Re : Pare feu ou pas ?

#39 Le 23/05/2013, à 18:19

Re : Pare feu ou pas ?

#40 Le 23/05/2013, à 19:00

Re : Pare feu ou pas ?

#41 Le 23/05/2013, à 19:21

Re : Pare feu ou pas ?

#42 Le 23/05/2013, à 19:45

Re : Pare feu ou pas ?

#43 Le 23/05/2013, à 22:09

Re : Pare feu ou pas ?

#44 Le 23/05/2013, à 23:05

Re : Pare feu ou pas ?

#45 Le 23/05/2013, à 23:55

Re : Pare feu ou pas ?

#46 Le 24/05/2013, à 09:23

Re : Pare feu ou pas ?

#47 Le 24/05/2013, à 10:52

Re : Pare feu ou pas ?

#48 Le 24/05/2013, à 11:11

Re : Pare feu ou pas ?

#49 Le 24/05/2013, à 13:15

Re : Pare feu ou pas ?

#50 Le 24/05/2013, à 14:42

Re : Pare feu ou pas ?

Pied de page des forums