Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#51 06-12-2012 21:16:40

lorus
Modérateur
Lieu : /var/log/snort/alert
Distrib. : Debian Squeeze/Wheezy/Freebsd amd64
Noyau : 2.6.32 / 3.2/
(G)UI : Gnome 2.30.2 / 3.2.4 / (bsd)2.32.1
Inscription : 25-07-2010

Re : [Résolu] Comprendre : parefeu iptables ufw

Et ce n'est pas les failles qui ouvrent les ports, les failles peuvent permettre d'obtenir un acces root par exemple



Exact je me suis mal exprimé, les failles correspondent à des ports, exemple la faille vnc correspond au port 5900

Il n'a pas besoin de le scanner, une fois qu'il a acces à la machine via un port entrant,


Et pour trouver une machine et un port entrant ouvert et espérer y installer une saloperie, il lui faut bien un scanner de faille non? Ce dernier lui donnera l'ip qui correspond à une machine et le/les port(s) entrant(s) ouvert(s) (correspondant à un/des services, forcément.), à moins que le hackeur sélectionne directement un port précis et donc recherche une faille précise... dans son scanneur.

Le danger se situe principalement sur les services installés sur la machine et donc au niveau du trafic entrant :
Si le pirate ne peut pas entrer, il ne peut rien faire , s'il peut entrer, il aura tout le loisir de tester les ports sortant pour en trouver un ouvert et il commencera surement par le 80..



Oui, tu redis ce que j'ai évoqué avant, mais comme nous sommes malins, nous interdisons tous (entrant et sortant) et nous autorisons que certains ports sortants uniquement, à partir de là je ne comprends plus trop comment est-ce possible big_smile pour transformer ton pc en zombie (via la saloperie qu'il a installer en pénétrant par le port entrant ouvert) pour un reseau de bot (spam, DDOS etc etc).
Évidemment, les admins d'un serveur qui ouvrent le port correspondant à un service (ex : http) soignent leur fichier de configuration de façon à limiter les failles potentielles, font les maj et ils observent leurs logs... Si des ips deviennent génantent, ils les shootent avec le pare feu.

Aucun intêret pour un hackeur que de scanner une liste d'ip sur le port 80 roll.

J'utilise le mot Hackeur car il y a deux catégories, les blacks Hat et les Whites hat big_smile
Tschuss!


Si vous êtes fan du « Si ce n’est pas cassé, ne le corrigez pas » , vous serez un grand fan de BSD. Mais si vous êtes du genre à avoir besoin que tout soit le plus récent possible, vous feriez mieux de migrer vers Linux aussi vite que possible histoire de ne pas être à la traîne.BSD a un système de base comprenant de nombreux outils, ils sont tous développés et packagés ensemble pour être cohésif.

Hors ligne

#52 06-12-2012 22:23:18

Y316
Membre
Distrib. : stretch/sid
Noyau : 4.3.0-1-amd64
Inscription : 15-11-2012

Re : [Résolu] Comprendre : parefeu iptables ufw

Merci pour ce débat très interessant;

big_smile  En attendant c'est l'heure de vérité :  big_smile

zebulon/outils/test a écrit :

Félicitation ! Votre sécurité semble optimale !
La totalité des ports TCP testés sont masqués, votre ordinateur ne donne donc aucune réponse aux tests de ports effectués. Votre machine est donc invisible aux yeux de pirates potentiels.

Ports TCP ouverts
Aucun port détecté

Ports TCP fermés
Aucun port détecté

Ports TCP masqués
.....


S'en suit une longue liste de ports masqués.

Question (le retour lol ) :
j'imagine une différence entre "fermé" et "masqué". Oui mais, laquelle est-ce exactement ... ?
Un port masqué peut-il être "masqué fermé" ou "masqué ouvert" et vice/versa et inversement ?

Dernière modification par Y316 (06-12-2012 22:25:14)


Debian 8.3 (jessie)  + la pire ICC que vous ayez probablement jamais rencontré.

Hors ligne

#53 06-12-2012 22:30:59

lorus
Modérateur
Lieu : /var/log/snort/alert
Distrib. : Debian Squeeze/Wheezy/Freebsd amd64
Noyau : 2.6.32 / 3.2/
(G)UI : Gnome 2.30.2 / 3.2.4 / (bsd)2.32.1
Inscription : 25-07-2010

Re : [Résolu] Comprendre : parefeu iptables ufw

j'imagine une différence entre "fermé" et "masqué". Oui mais, laquelle est-ce exactement ... ?



Fermé : toc-toc, bonjour, ah mince c'est fermé ! On peut essayer de forcer la porte non? ... puisqu'elle existe!

Masqué
- toc-toc- Pas de réponse, il y a quelqu'un? Cette porte existe-t-elle?

smile


Si vous êtes fan du « Si ce n’est pas cassé, ne le corrigez pas » , vous serez un grand fan de BSD. Mais si vous êtes du genre à avoir besoin que tout soit le plus récent possible, vous feriez mieux de migrer vers Linux aussi vite que possible histoire de ne pas être à la traîne.BSD a un système de base comprenant de nombreux outils, ils sont tous développés et packagés ensemble pour être cohésif.

Hors ligne

#54 06-12-2012 22:39:59

Y316
Membre
Distrib. : stretch/sid
Noyau : 4.3.0-1-amd64
Inscription : 15-11-2012

Re : [Résolu] Comprendre : parefeu iptables ufw

big_smile
Voilà une réponse claire concise et totalement assimilable en première lecture !
Merci lorus
big_smile

Debian 8.3 (jessie)  + la pire ICC que vous ayez probablement jamais rencontré.

Hors ligne

#55 07-12-2012 01:26:29

vince06fr
Membre
Distrib. : Debian Sid/experimental
Noyau : Linux 3.7-trunk-amd64
(G)UI : gnome-shell (gnome 3.6)
Inscription : 29-10-2012

Re : [Résolu] Comprendre : parefeu iptables ufw

Bref, j'ai du mal à m'xprimer. Pour faire simple

Ta configuration :
Tout fermé sauf ce que tu as besoin en entrant et en sortant

Ma configuration
Tout ce qui rentre est fermé sauf ce dont j'ai besoin
Tout ce qui sort est ouvert (m’évite d'ouvrir un port à chaque fois que je veux me connecter à un serveur utilisant un port different)

Dernière modification par vince06fr (07-12-2012 02:22:38)

Hors ligne

#56 07-12-2012 01:43:01

lorus
Modérateur
Lieu : /var/log/snort/alert
Distrib. : Debian Squeeze/Wheezy/Freebsd amd64
Noyau : 2.6.32 / 3.2/
(G)UI : Gnome 2.30.2 / 3.2.4 / (bsd)2.32.1
Inscription : 25-07-2010

Re : [Résolu] Comprendre : parefeu iptables ufw

ma configuration est:  tout fermé en entrant et quelques ports autorisés en sortant.

Je n'ai pas ajouter une règle dans ufw qui autorise les connexions entrantes (qui traverse le mur dans le sens web -> client) sur le port 80 :

# ufw allow in 80/tcp



J'ai juste fais

# ufw allow out 80/tcp


(qui traverse le mur client -> web,
par exemple smile

Le résultat n'est pas différent puisque la page web s'affiche et cela prouve bien qu'un serveur web "attend" l'ordre du visiteur. Le html est affiché directement à l'hote, le php est généré sur le serveur.

Lorus.


Si vous êtes fan du « Si ce n’est pas cassé, ne le corrigez pas » , vous serez un grand fan de BSD. Mais si vous êtes du genre à avoir besoin que tout soit le plus récent possible, vous feriez mieux de migrer vers Linux aussi vite que possible histoire de ne pas être à la traîne.BSD a un système de base comprenant de nombreux outils, ils sont tous développés et packagés ensemble pour être cohésif.

Hors ligne

#57 07-12-2012 02:05:49

Y316
Membre
Distrib. : stretch/sid
Noyau : 4.3.0-1-amd64
Inscription : 15-11-2012

Re : [Résolu] Comprendre : parefeu iptables ufw

@vince06fr :
Bref, j'ai du mal à m'xprimer.
non non, vos arguments me sont précieux mais il me faut plus de temps.

la page web s'affiche et cela prouve bien qu'un serveur web "attend" l'ordre du visiteur.

C'est ce que j'avais plus ou moins compris en configurant iptables : la stratégie était de faire rentrer uniquement ce qui était en réponse d'une requète de l'utilisateur.

En toute logique, il est parait préférable de fermer aussi les sorties possibles mais le pirate une fois rentré, peut effectivement sortir comme il veut.
Sur ce choix, je crois que c'est une question de maîtrise de son système.


Debian 8.3 (jessie)  + la pire ICC que vous ayez probablement jamais rencontré.

Hors ligne

#58 07-12-2012 02:17:19

vince06fr
Membre
Distrib. : Debian Sid/experimental
Noyau : Linux 3.7-trunk-amd64
(G)UI : gnome-shell (gnome 3.6)
Inscription : 29-10-2012

Re : [Résolu] Comprendre : parefeu iptables ufw

Désolé pour le post pas finis, j'ai fais une fausse manip lol

Exact je me suis mal exprimé, les failles correspondent à des ports, exemple la faille VNC correspond au port 5900


Faux :
les failles correspondent à des logiciels, exemple une faille VNC serait toujours présente si VNC etait configuré pour utiliser un autre port que le 5900. Une faille correspond à un problème de sécurité (dû en général à une erreur de programmation), qui peut être exploité pour détourner l'usage d'un service ou obtenir un acces root, etc..

Et pour trouver une machine et un port entrant ouvert et espérer y installer une saloperie, il lui faut bien un scanner de faille non? Ce dernier lui donnera l'ip qui correspond à une machine et le/les port(s) entrant(s) ouvert(s) (correspondant à un/des services, forcément.),


Encore faux
Généralement la cible est connu, il est aussi possible de lancer un scan de port sur un range d'ip pour obtenir des adresses ip de machines autorisant le trafic entrant sur des ports ouvert correspondant à des services.
Une fois les services détectés, on peut utiliser un scanner de faille pour détecter des failles dans les logiciels utilisés par ces services.

à moins que le hackeur sélectionne directement un port précis et donc recherche une faille précise... dans son scanneur.


Et non!!
exemple le plus courant, un serveur web sur le port 80. un scanner de faille va detecter les failles sur ce serveur, ces failles seront en rapport avec les logiciels installé : php principalement sur un serveur web. Donc un port precis mais un paquet de failles potentiels...

et nous autorisons que certains ports sortants uniquement, à partir de là je ne comprends plus trop comment est-ce possible  pour transformer ton pc en zombie (via la saloperie qu'il a installer en pénétrant par le port entrant ouvert) pour un reseau de bot (spam, DDOS etc etc).
[...]Aucun intêret pour un hackeur que de scanner une liste d'ip sur le port 80


J'ai jamais dit qu'il scannerait une liste d'ip sur le port 80 hmm
Bon le mieux c'est un exemple :

Soit 2 machines ayant VNC installé et donc le trafic entrant autorisé sur le port 5900/TCP,
la première machine est configuré comme la tienne, aucun autre trafic entrant n'est autorisé, seul quelques ports (dont le 80/tcp) sont autorisés pour le trafic sortant.
La 2eme machine est configurée comme la mienne. Aucun autre trafic entrant n'est autorisé. Le trafic sortant est autorisé dans tout les cas (donc le port 80/tcp est disponible pour le trafic sortant)

Le hacker exploite une faille sur VNC qui lui permet de prendre le contrôle de la machine dans les 2 cas. Une fois le contrôle de la machine obtenu, même sans accès root, pour faire participer la machine compromise à un DDOS, il lui suffit de lancer son attaque vers le serveur web cible en utilisant donc le port 80 en sortie, ce qui est autorisé dans les 2 cas...
Si il peut obtenir un accès root via une faille il peut ensuite bien sûr faire ce qu'il veut..

Les 2 configurations ne sont pas plus secure l'une que l'autre et il est important de se méfier des fausses impressions de sécurité...

Bon ce n'est pas le sujet du post donc pour continuer à debattre sur le sujet, le mieux serait d'ouvrir un autre post wink

Edit :

ma configuration est:  tout fermé en entrant et quelques ports autorisés en sortant.


Parce que tu n'as pas de service installé sur ta machine, j'imagine que si tu devais installer un serveur SSH par exemple, tu autoriserais le trafic entrant sur le port 22/TCP ...

Je n'ai pas ajouter une règle dans ufw qui autorise les connexions entrantes (qui traverse le mur dans le sens web -> client) sur le port 80 :

# ufw allow in 80/tcp

J'ai juste fais

# ufw allow out 80/tcp

(qui traverse le mur client -> web,
par exemple smile

Le résultat n'est pas différent puisque la page web s'affiche et cela prouve bien qu'un serveur web "attend" l'ordre du visiteur.


En fait le résultat est complètement different :

# ufw allow in 80/tcp


est equivalent à

# ufw allow 80/tcp


ou pour apache

# ufw allow httpd


ce qui autorise les connection entrante sur le port 80/TCP et est necessaire uniquement sur un serveur écoutant sur le port 80 (en principe un serveur web).

# ufw allow out 80/tcp


permet à une machine cliente de se connecter à un serveur qui écoute sur le port 80,(habituellement un serveur web) et est utile uniquement si  le trafic sortant est interdit par défaut

Le html est affiché directement à l'hote, le php est généré sur le serveur.


Ça se passe toujours comme ça, les pages web sont servi  (eventuellement généré par php ou autre) par le serveur web et affiché sur la machine cliente. hmm

cependant si tu installes un .deb (sans le code source) et que le programme installe un serveur qui tourne en arrière plan sur un port choisit par un hackeur, la technique du tout filtrant est mieux smile Il utilisera un port bidon pour être discret ex:1024 en tcp. Et là tu ne vois trop rien... pour M et Mme Michu


Premierement, il s'agit encore une fois de trafic entrant (serveur) donc interdit dans les 2 cas et deuxièmement un bon pirate aura profité d'inclure dans le .deb une commande pour ouvrir le port dont il a besoin.

Dernière modification par vince06fr (07-12-2012 10:12:49)

Hors ligne

#59 07-12-2012 16:27:02

lorus
Modérateur
Lieu : /var/log/snort/alert
Distrib. : Debian Squeeze/Wheezy/Freebsd amd64
Noyau : 2.6.32 / 3.2/
(G)UI : Gnome 2.30.2 / 3.2.4 / (bsd)2.32.1
Inscription : 25-07-2010

Re : [Résolu] Comprendre : parefeu iptables ufw

Hop là, ça bavarde dur ici:)
Ayé DF devient le repère du hacking...:cool:

Faux :
les failles correspondent à des logiciels, exemple une faille VNC serait toujours présente si VNC etait configuré pour utiliser un autre port que le 5900. Une faille correspond à un problème de sécurité (dû en général à une erreur de programmation), qui peut être exploité pour détourner l'usage d'un service ou obtenir un acces root, etc..


Cela peut être vrai, tout bon administrateur changera le port d'écoute... Cependant je n'ai jamais réussi à modifier le port d'écoute pour une négociation SSL/TLS avec certificat ssl en 1024 bits d'un serveur ftp, c'est 995, sinon le protocole foire smile ! Si tu as une soluce, je suis preneur.
Une faille correspond à  à un problème de sécurité (dépassement de tampon par exemple) ou à une mauvaise configuration... Le fameux fichier conf.

Encore faux
Généralement la cible est connu, il est aussi possible de lancer un scan de port sur un range d'ip pour obtenir des adresses ip de machines autorisant le trafic entrant sur des ports ouvert correspondant à des services.
Une fois les services détectés, on peut utiliser un scanner de faille pour détecter des failles dans les logiciels utilisés par ces services.


Et bien décidemment j'ai tout faux:)
Cela est vrai pur les serveurs connus comme Google et bien d'autre. Je crois déjà avoir évoquer ce que tu dis, le pas bô lancera un scan d'ip sur un port précis pour trouver une machine moins connue.

Et non!!
exemple le plus courant, un serveur web sur le port 80. un scanner de faille va detecter les failles sur ce serveur, ces failles seront en rapport avec les logiciels installé : php principalement sur un serveur web. Donc un port precis mais un paquet de failles potentiels...


Ah vraiment ? Que de certitudes ! Que fais-tu de Apache, SQL , LDAP,SSH et autres babioles ?:D
Vi, le port précis permet donc de détecter le service, les failles peuvent êtres logiciel ou une mauvaise configuration dudit service en laissant un trou béant:D
Dans le premier cas, une maj régulière prévient ce souci, dans le deuxième, une formation de l'admin les prévient également smile
Tu scannes une faille php sur quel port toi ? Il existe des scanner qui teste les formulaires php présents sur le site, et si la faille est avérée,  le méchant pas bô s'en servira pour faire suer ou récupérer le nom d'utilisateur et les mdp des compte par exemple.... Donc php est bien un script qui est généré sur le serveur. La plus part du temps, c'est le programmeur qui ne sécurise pas assez ses variables dans son script.
Évidemment, le fichier de conf de php (/etc/php5/apache/php.ini sous une deb) peut aussi présenter une faille si mal configuré. Si tu écris http://lesite.fr/php.ini, tu as de forte chance de tombé sur une page erreur 403 (forbidden). C'est que les droits d'accès dudit fichier est bien paramétré et supprime une faille, sinon il peut cracher des informations pertinentes ! Et le pare feu en rie encore:lol:

Soit 2 machines ayant VNC installé et donc le trafic entrant autorisé sur le port 5900/TCP,
la première machine est configuré comme la tienne, aucun autre trafic entrant n'est autorisé, seul quelques ports (dont le 80/tcp) sont autorisés pour le trafic sortant.
La 2eme machine est configurée comme la mienne. Aucun autre trafic entrant n'est autorisé. Le trafic sortant est autorisé dans tout les cas (donc le port 80/tcp est disponible pour le trafic sortant)
Le hacker exploite une faille sur vnc qui lui permet de prendre le controle de la machine dans les 2 cas. Une fois le controle de la machine obtenu, même sans accès root, pour faire participer la machine, il lui suffit de lancer son attaque vers le serveur web de son choix en utilisant donc le port 80 en sortie, ce qui est autorisé dans les 2 cas...
Si il peut obtenir un accès root via une faille il peut ensuite bien sûr faire ce qu'il veut..
Les 2 configurations ne sont pas plus secure l'une que l'autre et il est important de se mefier des fausses impressions de sécurité...


Quel est la machine serveur ? La tienne ou la mienne ? Si c'est la tienne alors tu feras un # ufw allow in 5800/tcp et # ufw allow out 5900/tcp wink Alors la, effectivement mieux vaut que tu es un bon mot de passe (pour les bruts force) big_smile . Pense à le changer très régulièrement
Comme j'essaye de te le faire comprendre, une station de travail n'est pas un serveur:)
Tu n'as aucun intêret à ouvrir un port entrant (sauf si ta machine devient un serveur... FTP, VNC etc etc). J'ouvre jsute le port 5900 en sortant et c'est tout. À partir de là et comme le montre les résultats  d'un scan en ligne de Y316 ou le miens, nos machines sont indétectables smile
Tu noteras également que le résultat du scan est bien un port qui correspond à un service.

Premierement, il s'agit encore une fois de trafic entrant (serveur) donc interdit dans les 2 cas et deuxièmement un bon pirate aura profité d'inclure dans le .deb une commande pour ouvrir le port dont il a besoin


Tu veux dire pour écouter sur le port dont il a besoin ? Donc d'un programme vérolé:D
Imagines que M et Mme Michu installe un logiciel de dessin pour ses enfants qu'ils trouvent sur un site web mais que ce dernier (le logiciel de dessin) soit vérolé. Quand il exécute l'installation du programme, en arrière plan s'installe en même temps un serveur (porte dérobée) qui donnera un accès à la machine de M et Mme Michu sur le port (par exemple 1024) à leur insu ! C'est pour cela que tout bloquer en sortant et n'ouvrir  que les ports essentiels peut les préserver:D
Évidemment, si le script exécute une commande en root pour ouvrir un port iptable, c'est cuît, mais cela est réservé à la cyber criminalité comme le vers stuxnet qui provient d'une organisation importante. Cependant, un pare feu matériel préserve de ces choses, les organisations sensibles ne se suffisent pas de iptable, un cisco n'est jamais loin big_smile

J'ai « tâtonné de l'administration » pendant 3ans sur un serveur (2ans OpenBsd et 1ans sous debian), des marlous j'en ai vu passé. Les mecs scannent des ports précis pour lancer un brut force (attaque par dictionnaire de mot). Par exemple, ils lancent un scan sur le port 1433 ce qui correspond à l'administration de SQL ( cette fonctionnalité est à l'origine prévue pour permettre le contrôle distant des bases de données par les véritables administrateurs... ), X machine seront présentes dans ses résultats. L'affreux tentera de se connecter avec user et mdp... S'il peine, il fera tourné un brute force. Quand il aura le bon user et mdp, il sera admin du serveur SQL sad . Toutefois un bon admin filtrera se port avec iptable (ou ufw) en entrant et ne laissera que quelque ip se connectées, les autres seront éjectées;)

Il conviendra à l'admin de vérifier ses configurations logiciels (de Apache et ses modules), les scripts php avec variables bien sécurisées et les doits d'écritures desdits scripts (ne pas donner les droits root 777 big_smile Et puis quelque bricoles de php comme le safe mode, les sessions, le module apache de php, les limitations!
Dans mon cas, j'avais réalisé un script qui éjectait pendant une heure l'ip qui échouait au bout de 10 tentatives de connexions (suspicion de brut force), si c'était récursif, je le shootais avec un fichier .htaccess qui est une arme de apache.
En revanche, l'acces à mon serveur ftp Ssl/TLS était filtré par le pare feu, je n'autorisais en entrant et sortant que certaines ip, les autres étaient directement rejetées ! Bien entendu, j'avais donné les droits adéquates en lecture et écriture sur mon serveur... Et l'authentification des ip autorisés se faisaient par une base de donnée mysql (user et mdp), chacun y avait un repertoire propre à son identifiant.

Dans le cas d'une station de travail, le pare feu bloqué en flux entrant et sortant avec quelques ports sortant filtrés est un excellent compromit, proche du risque zero, je maintiens !

Pour un serveur, le pare feu n'est qu'un moyen complémentaire de filtrage, la sécurité est  assurée conjointement par les fichiers de configuration et le pare feu. Mais les intrusions proviennent bien souvent d'une mauvaise configuration d'un des module qui constitue un serveur web wink

Voici ma modeste expérience, ce n'est pas une vérité absolue. Je ne suis pas administrateur réseau mais les quelques connaissances que je possède proviennent d'un pro, donc je partage à des fins pédagogiques wink

Amitié.

Lorus.


Si vous êtes fan du « Si ce n’est pas cassé, ne le corrigez pas » , vous serez un grand fan de BSD. Mais si vous êtes du genre à avoir besoin que tout soit le plus récent possible, vous feriez mieux de migrer vers Linux aussi vite que possible histoire de ne pas être à la traîne.BSD a un système de base comprenant de nombreux outils, ils sont tous développés et packagés ensemble pour être cohésif.

Hors ligne

#60 07-12-2012 17:19:16

Y316
Membre
Distrib. : stretch/sid
Noyau : 4.3.0-1-amd64
Inscription : 15-11-2012

Re : [Résolu] Comprendre : parefeu iptables ufw

Vince06fr a écrit :

Bon ce n'est pas le sujet du post donc pour continuer à debattre sur le sujet, le mieux serait d'ouvrir un autre post  wink

Au contraire c'est passionnant : après la technique de base, la stratégie; continuez je vous en prie.
( big_smile  je fournirais le chocolat si modo affamé ...)

Modeste contribution au passage :

lorus a écrit :

Alors la, effectivement mieux vaut que tu es un bon mot de passe (pour les bruts force) big_smile . Pense à le changer très régulièrement

je ne vois pas l'intérêt à changer un mot de passe sauf si l'on a constaté une intrusion ou si on l'a partagé avec quelqu'un.
Face à une attaque "nouvelle", le mot de passe est toujours "nouveau".

Mais j'ai installé fail2ban qui parait être une excellente parade à cette "force brute" qui, si on devait la prendre en compte, nécessiterait de changer son mot de passe aussi vite qu'elle ne les tente.


Debian 8.3 (jessie)  + la pire ICC que vous ayez probablement jamais rencontré.

Hors ligne

#61 07-12-2012 18:31:24

lorus
Modérateur
Lieu : /var/log/snort/alert
Distrib. : Debian Squeeze/Wheezy/Freebsd amd64
Noyau : 2.6.32 / 3.2/
(G)UI : Gnome 2.30.2 / 3.2.4 / (bsd)2.32.1
Inscription : 25-07-2010

Re : [Résolu] Comprendre : parefeu iptables ufw

( big_smile je fournirais le chocolat si modo affamé ...)



Ne te gêne pas, Noël arrive, miam miam smile
J'ai juste précisé que l'utilité d'un pare feu est différente entre une station de travail et un serveur.
Fail2ban lit les logs mais je ne connais pas. J'ai jamais tâtonné la bestiole big_smile Je préfère filtrer (avec ce que je connais: iptable) les ip ou dns entrants et rejeter tout(e)s les autres... Mais fail2ban doit être performant quand on le connait! Fail2ban pourrait faire l'objet d'un nouveau post, n'hésite pas.
Et un mot de passe se change très régulièrement.

Tschusss l'ami.


Si vous êtes fan du « Si ce n’est pas cassé, ne le corrigez pas » , vous serez un grand fan de BSD. Mais si vous êtes du genre à avoir besoin que tout soit le plus récent possible, vous feriez mieux de migrer vers Linux aussi vite que possible histoire de ne pas être à la traîne.BSD a un système de base comprenant de nombreux outils, ils sont tous développés et packagés ensemble pour être cohésif.

Hors ligne

#62 07-12-2012 21:18:42

Y316
Membre
Distrib. : stretch/sid
Noyau : 4.3.0-1-amd64
Inscription : 15-11-2012

Re : [Résolu] Comprendre : parefeu iptables ufw

@lorus :
J'ai bien compris et c'est bien votre stratégie que j'applique puisque je suis loin du stade "serveur".
Le débat éclaire ce qui m'attends smile ....

Fail2ban ne lit pas les logs.
C'est curieux que vous ne connaissiez pas, car je n'ai pas pu trouver cela ailleurs que sur les meilleures pages Debian-Squeeze ou Noyau-Linux.

Fail2ban impose un délai à la demande de connexion quand elle échoue un nombre de fois déterminé.
Ex : tu te gourres 2 fois de Mdp, faut attendre 1 minute avant de retenter le log ...
Selon les concepteurs, la force brute deviendrait ainsi temporellement impossible.
Moi je constate que ça fait aussi travailler la mémoire
  lol parceque ça fait vraiment ch*** de faire une faute de frappe dans ces conditions !

Bon promis,
je vais rassembler les liens que je trouve, pour faire un nouveau fil dédié à la chose et à ce que j'en comprends..
Et j'ai du boulot pour comprendre les posts au dessus ...  lol
@+  Amitiés à tous.

Ps :
cool C'est pour ma femme elle voudrait savoir
dans l'exemple suivant, pourquoi les signes <> à règle et pas à port  ?

Bloquer un port
# ufw deny port
Supprimer une règle
# ufw delete <règle>


Debian 8.3 (jessie)  + la pire ICC que vous ayez probablement jamais rencontré.

Hors ligne

#63 08-12-2012 03:51:28

vince06fr
Membre
Distrib. : Debian Sid/experimental
Noyau : Linux 3.7-trunk-amd64
(G)UI : gnome-shell (gnome 3.6)
Inscription : 29-10-2012

Re : [Résolu] Comprendre : parefeu iptables ufw

Au contraire c'est passionnant : après la technique de base, la stratégie; continuez je vous en prie.


Bon alors ..

Cela peut être vrai, tout bon administrateur changera le port d'écoute... Cependant je n'ai jamais réussi à modifier le port d'écoute pour une négociation SSL/TLS avec certificat ssl en 1024 bits d'un serveur ftp


Je te donne un exemple avec VNC,  tu essaye de prouver que ce que je dis est faux avec FTP. hmm ; mon exemple reste vrai avec un paquet d'autres services (ssh, apache, nginx, serveur pop, etc... ). De plus, mon propos etait juste de te prouver que les failles etaient relatives à un/des logiciels et non à un port.

Tu noteras également que le résultat du scan est bien un port qui correspond à un service.


Je n'ai jamais dit le contraire, mais ces services correspondent à un logiciel ou un ensemble de logiciels et les failles ne correspondent pas aux ports mais à des failles dans le(s) logiciel(s) qui fournit le service.

les failles peuvent êtres logiciel ou une mauvaise configuration dudit service


Le service étant fournis par un(des) logiciel(s), il s'agit donc d'une mauvaise configuration du(des) logiciel(s) wink
exemple d'un serveur utilisant plusieurs logiciel : LAMP

Dans le premier cas, une maj régulière prévient ce souci, dans le deuxième, une formation de l'admin les prévient également


Mefie toi encore des fausses impressions sécurité, que fais tu des failles zero-days et de l'intervalle entre le moment ou une faille est decouverte, rendu publique et patchée?
Qui te dis que ta formation est parfaite, on peut tres bien avoir mal compris un truc, ou bien avoir compris mais faire une erreur d'inattention, le risque 0 n'existe pas.

Ah vraiment ? Que de certitudes ! Que fais-tu de Apache, SQL , LDAP, SSH et autres babioles


Je te rappelle ta phrase :

à moins que le hackeur sélectionne directement un port précis et donc recherche une faille précise... dans son scanneur.


et je maintiens qu'on ne scan pas un port precis à la recherche d'une faille precise, les bestioles dont tu parle sont des logiciels qui peuvent contenir des failles. Quels que soit le port scanné, le/les logiciels ciblés peuvent contenir un paquets de failles.
D'ailleurs un scan de port en principe, c'est la première phase d'une attaque, ce qu'on appelle la détection d'hote, cette phase va pouvoir donner des information sur la/les cibles
On pourra ensuite utiliser ces informations pour réaliser une attaque.
Un scanner de faille automatise la recherche de faille sur un hôte

[ CENSURÉ PAR LES ADMINS ]

Désolé pour ce scan que je n'aurais pas dû faire, mais cibler DF me semblait plus parlant et plus percutant. A des fins d'apprentissage et pour être en conformité avec la loi, je le remplace par un scan d'un de mes serveurs persos sur mon réseau local. Il s'agit d'un serveur virtuel sous ubuntu 12.04 propulsé par apache sans aucune configuration particulière à part l'activation de https (fraîchement installé via apt-get)


Scan de port à l'aide de nmap - phase de detection de decouverte

# nmap -sS -O -F --max-rtt-timeout 250ms --max-retries 1 -PR --system-dns ubapache.lan

Starting Nmap 6.00 ( http://nmap.org ) at 2012-12-10 08:51 CET
Nmap scan report for ubapache;lan (192.168.1.11)
Host is up (0.000057s latency).
Not shown: 97 filtered ports
PORT    STATE SERVICE
22/tcp  open  ssh
80/tcp  open  http
443/tcp open  https
MAC Address: 00:17:4E:3C:EE:00 (Xensource)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose|specialized|WAP|media device|storage-misc|webcam
Running (JUST GUESSING): Linux 2.6.X|3.X (95%), Crestron 2-Series (90%), Netgear embedded (90%), Western Digital embedded (90%), HP embedded (87%), AXIS Linux 2.6.X (87%)
OS CPE: cpe:/o:linux:kernel:2.6 cpe:/o:linux:kernel:3 cpe:/o:crestron:2_series cpe:/o:axis:linux:2.6
Aggressive OS guesses: Linux 2.6.38 - 3.2 (95%), Linux 2.6.32 (93%), Linux 3.0 - 3.1 (93%), Linux 2.6.38 - 3.0 (92%), Linux 2.6.38 (91%), Linux 2.6.39 (91%), Linux 2.6.23 - 2.6.38 (91%), Linux 2.6.32 - 2.6.39 (90%), Crestron XPanel control system (90%), Netgear DG834G WAP or Western Digital WD TV media player (90%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 1 hop

OS detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 5.75 seconds

 

Scan de vulnérabilité avec nikto

# nikto -h ubapache.lan
- Nikto v2.1.4
---------------------------------------------------------------------------
+ Target IP:          192.168.1.11
+ Target Hostname:    ubapache.lan
+ Target Port:        80
+ Start Time:         2012-12-11 08:52:27
---------------------------------------------------------------------------
+ Server: Apache/2.2.22 (Ubuntu)
+ ETag header found on server, inode: 88877590, size: 121, mtime: 0x4c39ab05136e4
+ Allowed HTTP Methods: GET, HEAD, POST, OPTIONS
+ Retrieved x-powered-by header: PHP/5.3.10-1ubuntu3.4
+ OSVDB-3092: /info/: This might be interesting...
+ OSVDB-3092: /mail/: This might be interesting...
+ OSVDB-3268: /src/: Directory indexing found.
+ OSVDB-3268: /tmp/: Directory indexing found.
+ OSVDB-3092: /tmp/: This might be interesting...
+ OSVDB-3092: /mail/adminisist.nsf: This database can be read without authentication, which may reveal sensitive information.
+ OSVDB-3093: /mail/include.html: This might be interesting... has been seen in web logs from an unknown scanner.
+ OSVDB-3093: /mail/settings.html: This might be interesting... has been seen in web logs from an unknown scanner.
+ OSVDB-3093: /mail/src/read_body.php: This might be interesting... has been seen in web logs from an unknown scanner.
+ OSVDB-3233: /info.php: PHP is installed, and a test script which runs phpinfo() was found. This gives a lot of system information.
+ OSVDB-3233: /icons/README: Apache default file found.
+ OSVDB-5292: /info.php?file=http://cirt.net/rfiinc.txt?: RFI from RSnake's list (http://ha.ckers.org/weird/rfi-locations.dat) or from http://osvdb.org/
+ /phpmyadmin/: phpMyAdmin directory found
+ 6456 items checked: 0 error(s) and 16 item(s) reported on remote host
+ End Time:           2012-12-11 08:52:36 (9 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested
 



interessant non?
Vu qu'on a scanné le port 80, on trouve les failles d'apache (puisque c'est ce serveur qui est utilisé)et éventuellement des divers autre logiciels utilisés par le serveur. Comme je le disais, un seul port et plusieurs failles wink
pour info : OSVDB signifie Open Source Vulnerability Database, c'est une base de donnee opensource qui reference les failles de sécurités. On peut constater qu'apache en comprend un paquet lol , bon beaucoup de ces failles ne sont pas tres graves mais elles representent un risque potentiel pour la sécurité en donnant des informations sur le serveur.

Tu scannes une faille php sur quel port toi ?


Effectivement le service correspondant au port 80 est plutôt le serveur web lui-même(apache, par exemple) mais comme celui-ci permet d'utiliser php...
La faille OSVDB-12184 ( (c'est juste un easter-egg) est bien une faille php decelable sur le port 80...
Effectivement, php n'est pas associé au port 80, mais les echange en php entre le client et le serveur à travers les fichiers .php se font bien via le port entrant utilisé par le serveur web et le port sortant utilisé par le client web  (ici, apache sur le port 80). De même pour SQL ou mySQL ou autre DB, même si l'administration de la DB se fait sur un autre port. Une faille dans le logiciel de DB (sql, mySQL, coucheDB, etc...) pourra être trouvé par son utilisation par le serveur web sur le port 80 wink

Donc php est bien un script qui est généré sur le serveur.


Ouille ça pique! roll
php est un langage de programmation orienté web, php est donc un logiciel et non pas un script. Comme tout logiciel php peut avoir des failles
Les script php sont exécuté par php sur le serveur afin de génerer dynamiquement des pages web qui seront lisible par le client.

La plus part du temps, c'est le programmeur qui ne sécurise pas assez ses variables dans son scrip


Tout à fait, je n'ai pas dit le contraire, il s'agit là de faille dans les script php et non pas de failles dans php smile

Il existe des scanner qui teste les formulaires php présents sur le site,


a ton avis ce scan se fait sur quel port? Ben celui utilisé par le serveur web, donc le port 80 en standard ou  443 pour du https. Bien sûr, on peut tres bien configurer apache (ou tout autre serveur pour ecouter sur un autre port..)

Quel est la machine serveur ? La tienne ou la mienne ? Si c'est la tienne alors tu feras un # ufw allow in 5800/tcp et # ufw allow out 5900/tcp


Tu le fait expres??
Dans les 2 cas il s'agissait d'installer un serveur VNC sur les 2 machines et pour un serveur vnc, il n'y a jamais eu besoin d'ouvrir un port sortant, c'est un serveur enfin quoi hmm
xvnc utilise le port 5800 par defaut alors que x11vnc utilise le port 5900 par défaut.
Le port sortant est à ouvrir sur le client et ce uniquement si le trafic sortant n'est pas autorisé

J'ouvre jsute le port 5900 en sortant et c'est tout


pour autoriser la connexion à un serveur VNC, tu ouvres un port sortant toi?
Bon ok les reverse connexion toussa, mais c'est pas le sujet...

u veux dire pour écouter sur le port dont il a besoin ? Donc d'un programme vérolé:D
Imagines que M et Mme Michu installe un logiciel de dessin pour ses enfants qu'ils trouvent sur un site web mais que ce dernier (le logiciel de dessin) soit vérolé. Quand il exécute l'installation du programme, en arrière plan s'installe en même temps un serveur (porte dérobée) qui donnera un accès à la machine de M et Mme Michu sur le port (par exemple 1024) à leur insu ! C'est pour cela que tout bloquer en sortant et n'ouvrir  que les ports essentiels peut les préserver:D


Ta porte dérobée, c'est un serveur et il a donc  besoin d'une connection entrante et non pas d'une connexion sortante en quoi interdire le trafic sortant protegerait M et Mme Michu dans ce cas?
ce qui les protege c'est d'interdire le trafic entrant!!!!

Évidemment, si le script exécute une commande en root pour ouvrir un port iptable, c'est cuît, mais cela est réservé à la cyber criminalité comme le vers stuxnet qui provient d'une organisation importante


Ben non, si le type t'as pondu un .deb, il te faudra passer root pour l'installer, un codeur  pourra sans probleme en profiter pour rajouter une commande iptable au .deb.

Cependant, un pare feu matériel préserve de ces choses


Chez Mr et Mme Michu, le pare-feu de la box fait office de pare-feu materiel. Celui-ci autorise d'ailleurs tout le traffic sortant mais interdit par défaut tout le trafic entrant (comme la config par defaut d'UFW). Cest logique, à priori le poste de Mr et Mme Michu n'est pas un serveur...
C'est d'ailleurs parce que Mr et Mme Michu se trouve derriere cette box que le pare-feu est désactivé par défaut sur Debian. Utiliser conjointement 2 pare-feu ne presente pas beaucoup d'interet pour M et Mme Michu

Comme j'essaye de te le faire comprendre, une station de travail n'est pas un serveur:)
Tu n'as aucun intêret à ouvrir un port entrant (sauf si ta machine devient un serveur... FTP, VNC etc etc)


C'est exactement ce que j'ai dis. Tu n'ouvre un port entrant que si tu en as besoin, ce qui veux dire si tu as installé un serveur hmm
Je te rappelle que ma configuration par défaut est d'interdire tout le trafic entrant !!!
Pour le trafic sortant, tu fais bien comme tu veux, ça n'a pratiquement pas d'incidence sur ta sécurité

J'ouvre jsute le port 5900 en sortant et c'est tout. À partir de là et comme le montre les résultats  d'un scan en ligne de Y316 ou le miens, nos machines sont indétectables


J'obtiens le même résultat en désactivant UFW, normal je ne suis pas en DMZ et le pare-feu de ma Box est configuré pour ne rien laisser rentrer.
J'obtiens aussi le même résultat en mettant ma machine en DMZ et en activant UFW dans sa configuration par défaut, c'est à dire Par défaut : deny (entrant), allow (sortant)
Ton scanner de port ne teste que les ports ouvert dans le sens entrant sur ta machine et c'est logique, il ne teste pas ton trafic sortant 

J'ai « tâtonné de l'administration » pendant 3ans sur un serveur


et tu n'as toujours pas compris la différence entre trafic entrant(serveur => servir du contenu) et trafic sortant (client => telecharger le contenu servi par le (s) serveur(s)/ uploader du contenu sur le(s) serveur(s)) ????
Bon, je n'ai surement pas ton experience, on va dire que je n'ai jamais vraiment taté d'administration de serveur, je bricole juste  2 ou 3 serveurs perso pour l'apprentissage depuis environ 5 ans...

Dans le cas d'une station de travail, le pare feu bloqué en flux entrant et sortant avec quelques ports sortant filtrés est un excellent compromit, proche du risque zero, je maintiens !


Je maintiens que bloquer le flux sortant sur une station de tavail chez un particulier ne présente quasiment aucun interet, à part peut être limiter le risque de participation d'une machine vérolée à un botnet (et encore)..
Interdire tout le trafic entrant, utiliser un mot de passe root fort, faire les mises à jour, ne pas activer de dépôts tiers, ni de dépots contenant des logiciels dont le code source ne peut être étudié (non free), ne pas installer de .deb trouvé sur le net, ne pas cliquer n'importe ou, installer les modules complementaires no-script, coockie monster et adblock
Voila, là, sur un poste client on s'approche un petit peu plus du risque zero et même sans interdire le trafic sortant, mais on n'est quand même pas invulnerable wink


Dans une grosse entreprise avec plusieurs poste en reseau, effectivement c'est une autre histoire. Mais une grosse entreprise à d'autres besoins en matiere de sécurité que Mr et mme Michu.
Dans une grosse entreprise, c'est plutot tout le reseau derriere pare-feu materiel et un proxy, , les services sont sur une DMZ. Tout est fermé en entrant et en sortant sur chaque poste client et on ouvre uniquement ce dont on a besoin.

je ne vois pas l'intérêt à changer un mot de passe sauf si l'on a constaté une intrusion ou si on l'a partagé avec quelqu'un.
Face à une attaque "nouvelle", le mot de passe est toujours "nouveau".


Ce n'est pas parce qu'il n'y a pas eu detection qu'il n'y a pas eu intrusion...

Fail2ban ne lit pas les logs.


Si, Fail2ban lit les logs
http://www.fail2ban.org/wiki/index.php/FAQ_french

dans l'exemple suivant, pourquoi les signes <> à règle et pas à port  ?

Bloquer un port
# ufw deny port
Supprimer une règle
# ufw delete <règle>



C'est assez evident, tu ne peux pas supprimer les port, qu'il soit ouvert ou fermé, ils existent, ce que tu peux faire c'est supprimer la regle ufw qui ouvre ou ferme le port wink

Amitiés à tous, maintenant on passe au chocolat

Dernière modification par vince06fr (10-12-2012 13:36:19)

Hors ligne

#64 08-12-2012 08:15:14

smolski
administrateur quasi...modo
Lieu : AIN
Distrib. : 8 (jessie) 64 bits + backports
Noyau : 4.6.0-0.bpo.1-amd64
(G)UI : gnome 3.14.1
Inscription : 21-10-2008

Re : [Résolu] Comprendre : parefeu iptables ufw

Merci de la continuité de ce fil intéressant et ludique. C'est tout dans la ligne df, impec ! smile
Je crois que le partage des connaissances va effectivement jusqu'à informer librement et au plus près des méthodes d'intrusions utilisées sans en réserver les arcanes aux personnes qui les utilisent abusivement, elles, et les partagent en catimini entre leurs petits egos d'imbéciles.

Je viens d'être informé que de prendre le site df ou un autre en cible de scan n'est pas responsable, nous avons retiré le paragraphe le concernant.

Il est certain qu'au bout du bout un tuto pourra être réalisé.
Comme vous êtes plusieurs à l'animer, pour le chocolat, on va tirer au sort, genre :
pouf pouf pouf... c'est pas toi qui l'aura ! Et ainsi de suite...
Ou bien le morceller entre tous ?
...
Ou bien scrongnon gnon... Bande de morfales, l'premier qui s'approche de la boîte, y va voir !

J'hésite ! lol

Dernière modification par smolski (09-12-2012 23:55:48)


"Définition d'eric besson : S'il fallait en chier des tonnes pour devenir ministre, il aurait 2 trous du cul." - JP Douillon
"L'utopie ne signifie pas l'irréalisable, mais l'irréalisée." - T Monod (source :  La zone de Siné)
"Je peux rire de tout mais pas avec n'importe qui." - P Desproges
"saque eud dun" (patois chtimi : fonce dedans)

Hors ligne

#65 08-12-2012 11:51:21

lorus
Modérateur
Lieu : /var/log/snort/alert
Distrib. : Debian Squeeze/Wheezy/Freebsd amd64
Noyau : 2.6.32 / 3.2/
(G)UI : Gnome 2.30.2 / 3.2.4 / (bsd)2.32.1
Inscription : 25-07-2010

Re : [Résolu] Comprendre : parefeu iptables ufw

@vince06.fr

Je ne faisais que développer ma logique (qui n'est pas vérité absolue) suite à tes réponses du post #58 qui sont elles mêmes une réponse à mon post #51. J'aurais du quoté un peu plus (Lorus à écrit => vince06.fr à écrit) dans mon post #59. En ce sens, je te répondais avec des exemples que j'ai connu, en aucun cas je me permettrais de discréditer tes propos big_smile
Même si globalement nous sommes d'accord sur le fond, mon expérience issue d'une gestion de serveur, tout comme la tienne amène des divergences d'opinions et est une richesse pour DF, c'est passionnant smile

Nous sommes tous dans la communauté libre pour apprendre et partager les valeurs de chacun, j'accepte facilement la contradiction.

Dernier exemple pour en revenir au pc de Y316 wink

vince06.fr a écrit :

Ta porte dérobée, c'est un serveur et il a donc  besoin d'une connection entrante et non pas d'une connexion sortante en quoi interdire le trafic sortant protegerait M et Mme Michu dans ce cas?
ce qui les protege c'est d'interdire le trafic entrant!!!!



Oui pour un serveur mais si c'est un keylogger (le logiciel de dessin de mon exemple installe un keylogger), seul le port sortant importe, il enverra par exemple à des intervalles réguliers par email ou tout autre moyen, le contenu qu'il a capté sur le port n°xxxx à son/ses destinataires. Elle est autonome la bestiole. C'est pour cela que je maintiens qu'une station de travail doit être tout bloquant en entrant et sortant, avec ouverture du minimum sortant. Encore une fois ce n'est pas faux ce que tu écris pour un serveur, mais les malwares sont nombreux et différents! Un keylogger, tu le classes dans la catégorie serveur toi? Moi perso j'hésite... même si je dirais (conditionnel) que oui.

No souci, Jojo, planque là c'te boite lol

Bonne et belle journée à toutes et tous!

Lorus


Si vous êtes fan du « Si ce n’est pas cassé, ne le corrigez pas » , vous serez un grand fan de BSD. Mais si vous êtes du genre à avoir besoin que tout soit le plus récent possible, vous feriez mieux de migrer vers Linux aussi vite que possible histoire de ne pas être à la traîne.BSD a un système de base comprenant de nombreux outils, ils sont tous développés et packagés ensemble pour être cohésif.

Hors ligne

#66 08-12-2012 13:57:30

Y316
Membre
Distrib. : stretch/sid
Noyau : 4.3.0-1-amd64
Inscription : 15-11-2012

Re : [Résolu] Comprendre : parefeu iptables ufw

smile Je mets pas les noms des citations ...  peu importe qui a dit,  l'important c'est le quoi. smile

Je maintiens que bloquer le flux sortant sur une station de tavail chez un particulier ne présente quasiment aucun interet, à part peut être limiter le risque de participation d'une machine vérolée à un botnet..

C'est bien cela qui m'incite à suivre cette stratégie. Même s'il existe des "opérations" auxquelles j'adhèrerais volontier, je ne peux pas (veux pas) accepter le risque d'une utilisation malveillante.
Et si je veux proposer une utilité bienveillante (ne serait-ce que la mise à disposition de la puisssance de calcul car en bon michu je dois tourner aux environs de 15% d'usage des capacités matérielles), il faut, si j'ai bien compris,  protéger le TOR avec raison.
.
.

informer librement et au plus près des méthodes d'intrusions utilisées

Bien évidement, c'est nécessaire. Comment se protéger sans connaitre l'attaque ?
Mais je ne me fais aucune illusion sur les posibilités d'intrusion des machines-michus pour des professionnels (comptons pour nous rassurer que ces intrusions sont aussi le fait de "polices" sinçères et intègres). Quand au matériel physique, je sais aussi que sans Mdp bios et chiffrage de DD, autant pisser dans un violon que parler sécurité.
.
.

si c'est un keylogger

N'est-ce pas là le principal souci d'un michu en matière d'attaque (après l'ICC) ?
Mon autre souci c'est d'avoir un modem. Beaucoup de commentaires et de tutos sous-entendent que l'utilisateur et derrière une box qui le protège.
Quelles précautions particulières à ce sujet ?
.
.

je ne vois pas l'intérêt à changer un mot de passe sauf si l'on a constaté une intrusion ou si on l'a partagé avec quelqu'un.
    Face à une attaque "nouvelle", le mot de passe est toujours "nouveau".

Ce n'est pas parce qu'il n'y a pas eu detection qu'il n'y a pas eu intrusion...

Oui mais le premier travail de l'intru sera certainement de s'attribuer sa propre clef.
D'où l'interet de chercher l'intrus qui squate en silence. : http://debian-facile.org/viewtopic.php?id=6272
Mais face à un nouvel intrus, le Mdp est toujours "nouveau", même s'il "attend le nouvel intrus depuis x temps".
C'est là où je vois l'intérêt de Fail2ban face à la force brute. (Merci pour le lien, je vois que je connaissais bien peu ce logiciel ...).

.
.

dans l'exemple suivant, pourquoi les signes <> à règle et pas à port  ?
    Bloquer un port
    # ufw deny port
    Supprimer une règle
    # ufw delete <règle>

C'est assez evident, tu ne peux pas supprimer les port, qu'il soit ouvert ou fermé, ils existent, ce que tu peux faire c'est supprimer la regle ufw qui ouvre ou ferme le port wink

J'ai beau consulter man ufw, je ne vois pas que "port" est une commande ou une option.
C'est donc une indication de ce qui doit être adapté selon la configuration recherchée (une variable)

Dans ufw delete <règle> je comprends que <règle> est une syntaxe que je dois remplacer.
si cela est vrai pour "port", il faudrait écrire : ufw deny <port> .

Dernière modification par Y316 (08-12-2012 14:00:22)


Debian 8.3 (jessie)  + la pire ICC que vous ayez probablement jamais rencontré.

Hors ligne

#67 08-12-2012 14:14:27

lorus
Modérateur
Lieu : /var/log/snort/alert
Distrib. : Debian Squeeze/Wheezy/Freebsd amd64
Noyau : 2.6.32 / 3.2/
(G)UI : Gnome 2.30.2 / 3.2.4 / (bsd)2.32.1
Inscription : 25-07-2010

Re : [Résolu] Comprendre : parefeu iptables ufw

lorus a écrit :

si c'est un keylogger

Y316 a écrit :

N'est-ce pas là le principal souci d'un michu en matière d'attaque (après l'ICC) ?
Mon autre souci c'est d'avoir un modem. Beaucoup de commentaires et de tutos sous-entendent que l'utilisateur et derrière une box qui le protège.
Quelles précautions particulières à ce sujet ?


Comme évoquer dans nos posts, le keylogger s'installer souvent via un logiciel attractif, si tu restes dans les dépôts Debian main, les chances sont nulles... par cette méthode en tout cas.
Tu as un pare feu d'activer sur ton pc et configuré de manière satisfaisante, tu es bien protégé smile
Bien sûr, à coeur vaillant rien d'impossible smile Ta box ferait la même chose, mais je dirais que pour un particulier et surtout pour un pc portable, l'activation d'un pare feu logiciel lui permet, lors de ses utilisations nomades (réseau wifi public) d'être convenablement protégé.

Y316 a écrit :

Mais face à un nouvel intrus, le Mdp est toujours "nouveau", même s'il "attend le nouvel intrus depuis x temps".
C'est là où je vois l'intérêt de Fail2ban face à la force brute. (Merci pour le lien, je vois que je connaissais bien peu ce logiciel ...)



Fail2ban lit les logs, sinon comment est-il possible qu'il détecte des tentatives d'intrusion? smile
Je t'avais juste répondu que je préferais gérer les accès distants critiques (base de donnée, ftp, ssh,) d'un serveur web avec iptable qui autorise que quelques ip (ou dns )et rejette toutes les autres.
Je préfère la restriction total (dans la mesure de mes connaissances) à un logiciel qui veille (au risque qu'un vilain pas bô le trompe?) pour moi. Dans mon exemple, j'avais développé un script php qui veillait aux tentatives de log de la partie admin de mon site (exemple http://lesite.fr/admin/login.php)...
Peut-être que fail2ban aurait été plus sécure, cependant, je préfère utiliser un outil que je connais bien pour gérer la sécurité wink

Hé Jojo, les papillotes chocolatées compte ou non?

smile


Si vous êtes fan du « Si ce n’est pas cassé, ne le corrigez pas » , vous serez un grand fan de BSD. Mais si vous êtes du genre à avoir besoin que tout soit le plus récent possible, vous feriez mieux de migrer vers Linux aussi vite que possible histoire de ne pas être à la traîne.BSD a un système de base comprenant de nombreux outils, ils sont tous développés et packagés ensemble pour être cohésif.

Hors ligne

#68 08-12-2012 14:46:35

captnfab
Admin-Girafe
Lieu : /dev/random
Distrib. : Debian Stretch/Sid/Rc-Buggy
Noyau : Linux (≥ 4.3)
(G)UI : i3-wm (≥ 4.11)
Inscription : 07-07-2008
Site Web

Re : [Résolu] Comprendre : parefeu iptables ufw

Je ne suis pas vraiment d'accord avec la politique du « bloquer tous les ports sortants ».
Il y a des ports qui seront toujours autorisés, quitte à être relayés par des proxys. 80, 443…
Les keyloggers utilisent bien souvent ces ports-là, auquel cas un bloquage par ports est complètement inefficace.

S'il ne s'agit pas d'un petit programme mais d'un rootkit, alors il bypassera le firewall, donc la question ne se pose pas non plus.

captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.

Hors ligne

#69 08-12-2012 14:51:29

lorus
Modérateur
Lieu : /var/log/snort/alert
Distrib. : Debian Squeeze/Wheezy/Freebsd amd64
Noyau : 2.6.32 / 3.2/
(G)UI : Gnome 2.30.2 / 3.2.4 / (bsd)2.32.1
Inscription : 25-07-2010

Re : [Résolu] Comprendre : parefeu iptables ufw

Merci captnfab, tu éclaires ma lanterne sur les keyloggers et leur fonctionnement!
Donc on ouvre tous les ports sortants par défaut comme politique pour une station de travail?
Et on utilise un anti rootkit? (rkhunter?)

Merci.

Si vous êtes fan du « Si ce n’est pas cassé, ne le corrigez pas » , vous serez un grand fan de BSD. Mais si vous êtes du genre à avoir besoin que tout soit le plus récent possible, vous feriez mieux de migrer vers Linux aussi vite que possible histoire de ne pas être à la traîne.BSD a un système de base comprenant de nombreux outils, ils sont tous développés et packagés ensemble pour être cohésif.

Hors ligne

#70 08-12-2012 15:26:41

captnfab
Admin-Girafe
Lieu : /dev/random
Distrib. : Debian Stretch/Sid/Rc-Buggy
Noyau : Linux (≥ 4.3)
(G)UI : i3-wm (≥ 4.11)
Inscription : 07-07-2008
Site Web

Re : [Résolu] Comprendre : parefeu iptables ufw

Oui, a priori, ouvrir tous les ports sortants ne présente pas vraiment de risque.

Pour les rootkit, le problème n'est pas simple.
Un anti-rootkit ne peut pas réellement détecter la présence d'un rootkit. Au mieux, il peut détecter l'arrivée d'un rootkit. Mais pour ce faire, il faut qu'il soit suivi de près.
Ça n'est pas une protection, c'est un outil de diagnostic.

Il faut savoir que quand un système a subi une attaque et que l'attaquant a réussit à s'y introduire. La seule véritable méthode pour être à peu près certain qu'il n'y ait ni rootkit ni autre saloperie… c'est de formater la machine.

captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.

Hors ligne

#71 08-12-2012 15:43:53

Y316
Membre
Distrib. : stretch/sid
Noyau : 4.3.0-1-amd64
Inscription : 15-11-2012

Re : [Résolu] Comprendre : parefeu iptables ufw

Aparté :

$ aptitude search rkhunter
i   rkhunter                                                                - rootkit, backdoor, sniffer and exploit scanner

  cool
Bon si c'est comme ufw que je croyais "activé", ça m'avance pas du tout ce truc, encore du boulot .... ah les s*.... !
Allez  : courage joyeux libristes et tapons en coeur : :  man rakakakunter
!

lol  Bon j'arrête l'aparté, Y'a risque d'apartheid !   

J'ai aussi NoScript et Ghostery et puis clamav et je crois que j'en oublie.

sinon comment est-il possible qu'il détecte des tentatives d'intrusion?

C'est vraiment curieux cette différence de vues sur Fail2ban et le Mdp en général.
Quand on tente une connexion, légitime ou non, si l'on connait le Mdp, on passe.
Sans le Mdp, on tente une première fois un Mdp, c'est bien un couple qui est comparé (login et Mdp); la force brute consiste à répeter l'opération à des vitesses records avec des couples différents.
Simplement, Fail2ban détecte (par exemple) 2 rejets (paire invalide) et décide que la troisième tentative aura lieu seulement dans 1 minute.
Perso je trouve le principe, génialement ""humain"".
Cela ne dispense pas du parefeu et de la maintenance régulière et c'est seulement un "plus".
Comme tous les "plus", il a ses propres failles.


Debian 8.3 (jessie)  + la pire ICC que vous ayez probablement jamais rencontré.

Hors ligne

#72 08-12-2012 18:25:53

lorus
Modérateur
Lieu : /var/log/snort/alert
Distrib. : Debian Squeeze/Wheezy/Freebsd amd64
Noyau : 2.6.32 / 3.2/
(G)UI : Gnome 2.30.2 / 3.2.4 / (bsd)2.32.1
Inscription : 25-07-2010

Re : [Résolu] Comprendre : parefeu iptables ufw

@captnfab merci pour ton sentiment et tes précisions smile
On va tous finir parano, d'autant plus que Rkhunter me trouve deux "faux positifs" selon la communauté sur ma Deb main, filtrée par pare feu matériel et logiciel... neutral

Performing group and account checks
    Checking for passwd file                                 [ Found ]
    Checking for root equivalent (UID 0) accounts            [ None found ]
    Checking for passwordless accounts                       [ None found ]
    Checking for passwd file changes                         [ Warning ]
    Checking for group file changes                          [ Warning ]
    Checking root account shell history files                [ OK ]

Performing filesystem checks
    Checking /dev for suspicious file types                  [ None found ]
    Checking for hidden files and directories                [ Warning ]
File properties checks...
    Required commands check failed
    Files checked: 131
    Suspect files: 0

Rootkit checks...
    Rootkits checked : 242
    Possible rootkits: 2
    Rootkit names    : Xzibit Rootkit, Xzibit Rootkit

 



Je vais ouvrir un post sur le sujet pour recueillir les avis ou conseil!

Allez hop là.

Amitiés.

Édit:

Je viens de voir ce post là : http://debian-facile.org/viewtopic.php?id=4262 big_smile , 'vais le lire.

Dernière modification par lorus (08-12-2012 18:28:07)


Si vous êtes fan du « Si ce n’est pas cassé, ne le corrigez pas » , vous serez un grand fan de BSD. Mais si vous êtes du genre à avoir besoin que tout soit le plus récent possible, vous feriez mieux de migrer vers Linux aussi vite que possible histoire de ne pas être à la traîne.BSD a un système de base comprenant de nombreux outils, ils sont tous développés et packagés ensemble pour être cohésif.

Hors ligne

#73 08-12-2012 18:30:41

MaTTuX_
La Paillasse !!!
Lieu : Zoubidou-Land
Distrib. : 75 serveurs
Noyau : 3.2.0-4-amd64
(G)UI : tty et ... pas gnome en tout cas....
Inscription : 28-05-2007
Site Web

Re : [Résolu] Comprendre : parefeu iptables ufw

Pour les détection de intrusion il faut installer un IDS  http://fr.wikipedia.org/wiki/Syst%C3%A8 … 7intrusion

\o/ Le closedSource c'est tabou on a viendra tous à bout \o/

Hors ligne

#74 08-12-2012 19:27:12

lorus
Modérateur
Lieu : /var/log/snort/alert
Distrib. : Debian Squeeze/Wheezy/Freebsd amd64
Noyau : 2.6.32 / 3.2/
(G)UI : Gnome 2.30.2 / 3.2.4 / (bsd)2.32.1
Inscription : 25-07-2010

Re : [Résolu] Comprendre : parefeu iptables ufw

Yep Mattux!

Rkhunter est bien un IDS. Dans mon cas il trouve deux rootkits possible, selon la communauté ce sont de faux positifs, pourquoi perdurent-t-ils au fil des mois dans les logs de Rkhunter?
Est-ce un bug non résolu?

J'ajoute que pour configurer un firewall, j'utilise souvent un

# nano /etc/services

histoire de retrouver un port précis (j'ai une tête de linotte) big_smile


Si vous êtes fan du « Si ce n’est pas cassé, ne le corrigez pas » , vous serez un grand fan de BSD. Mais si vous êtes du genre à avoir besoin que tout soit le plus récent possible, vous feriez mieux de migrer vers Linux aussi vite que possible histoire de ne pas être à la traîne.BSD a un système de base comprenant de nombreux outils, ils sont tous développés et packagés ensemble pour être cohésif.

Hors ligne

#75 08-12-2012 19:30:28

MaTTuX_
La Paillasse !!!
Lieu : Zoubidou-Land
Distrib. : 75 serveurs
Noyau : 3.2.0-4-amd64
(G)UI : tty et ... pas gnome en tout cas....
Inscription : 28-05-2007
Site Web

Re : [Résolu] Comprendre : parefeu iptables ufw

C'est le problème de rkhunter il detecte pas l'intrusion mais deja l'intrus, et ya beaucoup de faux positif, ce n'est pas vraiment un bug.

\o/ Le closedSource c'est tabou on a viendra tous à bout \o/

Hors ligne

Pied de page des forums