Contenu | Rechercher | Menus

Annonce

Si vous rencontrez des soucis à rester connecté sur le forum (ou si vous avez perdu votre mot de passe) déconnectez-vous et reconnectez-vous depuis cette page, en cochant la case "Me connecter automatiquement lors de mes prochaines visites".

#51 Le 19/03/2013, à 19:48

Haleth

Re : Filtrage réseau sous Linux et son avenir

Donc, si je comprends bien: tu sais, mais tu ne veux pas partager ton savoir.
Ou plutôt: tu ne sais pas, donc tu éludes les questions.

'kthx bye;


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

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

Hors ligne

#52 Le 19/03/2013, à 19:50

Brunod

Re : Filtrage réseau sous Linux et son avenir

Starting Nmap 5.00 ( http://nmap.org ) at 2013-03-19 18:43 CET
NSE: Loaded 30 scripts for scanning.
Failed to find device wlan0 which was referenced in /proc/net/route
Initiating Ping Scan at 18:43
Scanning 78.214.132.184 [8 ports]
Completed Ping Scan at 18:43, 0.08s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 18:43
Completed Parallel DNS resolution of 1 host. at 18:43, 0.28s elapsed
Initiating SYN Stealth Scan at 18:43
Scanning amp80-4-78-214-132-184.fbx.proxad.net (78.214.132.184) [1000 ports]
SYN Stealth Scan Timing: About 17.60% done; ETC: 18:46 (0:02:25 remaining)
SYN Stealth Scan Timing: About 36.30% done; ETC: 18:47 (0:02:10 remaining)
SYN Stealth Scan Timing: About 49.65% done; ETC: 18:47 (0:01:45 remaining)
SYN Stealth Scan Timing: About 62.55% done; ETC: 18:47 (0:01:20 remaining)
SYN Stealth Scan Timing: About 75.75% done; ETC: 18:47 (0:00:53 remaining)
Completed SYN Stealth Scan at 18:47, 220.26s elapsed (1000 total ports)
Initiating Service scan at 18:47
Initiating OS detection (try #1) against amp80-4-78-214-132-184.fbx.proxad.net (78.214.132.184)
Retrying OS detection (try #2) against amp80-4-78-214-132-184.fbx.proxad.net (78.214.132.184)
NSE: Script scanning 78.214.132.184.
NSE: Script Scanning completed.
Host amp80-4-78-214-132-184.fbx.proxad.net (78.214.132.184) is up (0.18s latency).
All 1000 scanned ports on amp80-4-78-214-132-184.fbx.proxad.net (78.214.132.184) are filtered
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Aggressive OS guesses: AXIS 70U Network Document Server (97%), IBM OS/400 V4R3 (97%), Juniper Networks SSG 20 firewall (97%), Microsoft Xbox game console (modified, running XboxMediaCenter) (97%), NetOptics iBypass switch (97%), Sensatronics E4 temperature monitor (97%), Bay Networks BayStack 450 switch (software version 3.1.0.22) (97%), Bay Networks BayStack 450 switch (software version 4.2.0.16) (97%), IBM i5/OS V5R3 (97%), IBM i5/OS V5R4 (97%)
No exact OS matches for host (test conditions non-ideal).

Read data files from: /usr/share/nmap
OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 233.53 seconds
           Raw packets sent: 2037 (92.632KB) | Rcvd: 11 (1048B)

Rien ne passe ... Tu es blindé smile


Windows est un système d'exploitation de l'homme par l'ordinateur.
Linux, c'est le contraire ... --> état de la conversion : 34 pc linux

Hors ligne

#53 Le 19/03/2013, à 19:54

Haleth

Re : Filtrage réseau sous Linux et son avenir

Quoi ? Je suis blindé, sans firewall ? MAIS PAR QUEL MIRACLE ?!?


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

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

Hors ligne

#54 Le 19/03/2013, à 20:23

Pierre Lhabitant

Re : Filtrage réseau sous Linux et son avenir

Brunod a écrit :
Starting Nmap 5.00 ( http://nmap.org ) at 2013-03-19 18:43 CET
NSE: Loaded 30 scripts for scanning.
Failed to find device wlan0 which was referenced in /proc/net/route
Initiating Ping Scan at 18:43
Scanning 78.214.132.184 [8 ports]
Completed Ping Scan at 18:43, 0.08s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 18:43
Completed Parallel DNS resolution of 1 host. at 18:43, 0.28s elapsed
Initiating SYN Stealth Scan at 18:43
Scanning amp80-4-78-214-132-184.fbx.proxad.net (78.214.132.184) [1000 ports]
SYN Stealth Scan Timing: About 17.60% done; ETC: 18:46 (0:02:25 remaining)
SYN Stealth Scan Timing: About 36.30% done; ETC: 18:47 (0:02:10 remaining)
SYN Stealth Scan Timing: About 49.65% done; ETC: 18:47 (0:01:45 remaining)
SYN Stealth Scan Timing: About 62.55% done; ETC: 18:47 (0:01:20 remaining)
SYN Stealth Scan Timing: About 75.75% done; ETC: 18:47 (0:00:53 remaining)
Completed SYN Stealth Scan at 18:47, 220.26s elapsed (1000 total ports)
Initiating Service scan at 18:47
Initiating OS detection (try #1) against amp80-4-78-214-132-184.fbx.proxad.net (78.214.132.184)
Retrying OS detection (try #2) against amp80-4-78-214-132-184.fbx.proxad.net (78.214.132.184)
NSE: Script scanning 78.214.132.184.
NSE: Script Scanning completed.
Host amp80-4-78-214-132-184.fbx.proxad.net (78.214.132.184) is up (0.18s latency).
All 1000 scanned ports on amp80-4-78-214-132-184.fbx.proxad.net (78.214.132.184) are filtered
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Aggressive OS guesses: AXIS 70U Network Document Server (97%), IBM OS/400 V4R3 (97%), Juniper Networks SSG 20 firewall (97%), Microsoft Xbox game console (modified, running XboxMediaCenter) (97%), NetOptics iBypass switch (97%), Sensatronics E4 temperature monitor (97%), Bay Networks BayStack 450 switch (software version 3.1.0.22) (97%), Bay Networks BayStack 450 switch (software version 4.2.0.16) (97%), IBM i5/OS V5R3 (97%), IBM i5/OS V5R4 (97%)
No exact OS matches for host (test conditions non-ideal).

Read data files from: /usr/share/nmap
OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 233.53 seconds
           Raw packets sent: 2037 (92.632KB) | Rcvd: 11 (1048B)

Rien ne passe ... Tu es blindé smile



Il ne sert à rien ton scan, il a un routeur, c'est le routeur qui est blindé, t'aurais dû attendre qu'il crée une DMZ, qu'il désactive le pare feu de la box, ça aurait eu de l'intérêt, un peu.

Dernière modification par Pierre Lhabitant (Le 19/03/2013, à 20:27)

Hors ligne

#55 Le 19/03/2013, à 20:24

Brunod

Re : Filtrage réseau sous Linux et son avenir

Ok, passe son routeur alors... wink


Windows est un système d'exploitation de l'homme par l'ordinateur.
Linux, c'est le contraire ... --> état de la conversion : 34 pc linux

Hors ligne

#56 Le 19/03/2013, à 20:29

Pierre Lhabitant

Re : Filtrage réseau sous Linux et son avenir

Brunod a écrit :

Ok, passe son routeur alors... wink


J'aurais besoin de son adresse mail...

Hors ligne

#57 Le 19/03/2013, à 20:30

Brunod

Re : Filtrage réseau sous Linux et son avenir

Pourquoi ?


Windows est un système d'exploitation de l'homme par l'ordinateur.
Linux, c'est le contraire ... --> état de la conversion : 34 pc linux

Hors ligne

#58 Le 19/03/2013, à 20:31

Pierre Lhabitant

Re : Filtrage réseau sous Linux et son avenir

A ton avis?

Dernière modification par Pierre Lhabitant (Le 19/03/2013, à 20:32)

Hors ligne

#59 Le 19/03/2013, à 20:35

Brunod

Re : Filtrage réseau sous Linux et son avenir

Aucune idée, c'est pour ça que je demande. Je ne vois pas en quoi une adresse mail d'un compte de son fai ou autre (gmail...) puisse aider à traverser un routeur qui est chez lui.
EDIT : enfin si, avec backorifice il y a 15 ans, mais on a évolué depuis. Donc non, je ne sais pas.

Dernière modification par Brunod (Le 19/03/2013, à 20:39)


Windows est un système d'exploitation de l'homme par l'ordinateur.
Linux, c'est le contraire ... --> état de la conversion : 34 pc linux

Hors ligne

#60 Le 19/03/2013, à 20:57

Haleth

Re : Filtrage réseau sous Linux et son avenir

Ouais, j'avoue, c'est l'IP de mon "router" (boite avec 3 puces, un port ethernet et un Linux dessus, pas de conf spécial).
J'te donne un autre os à ronger: un server de la boite, du genre qu'on range dans une armoire. Étant admsys, je pense être compétent pour te dire qu'il n'y a pas de conf spécifique, iptables ou autre.

IP: 178.250.209.22

Au plaisir ..
Quand à mon @mail, en veux-tu en voila: kikoolaul37@laposte.net
Haa, sacré alias tien..


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

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

Hors ligne

#61 Le 19/03/2013, à 20:58

tiramiseb

Re : Filtrage réseau sous Linux et son avenir

Pierre Lhabitant a écrit :

il faut rapidement ou pas trop tardivement créer une interface graphique plus détaillée que gufw, afin que linux puisse s'adapter aux principaux dangers qu'il risque de rencontrer si son expansion se poursuit

Donc, si je résume ton propos :

1/ il faut absolument créer une interface graphique car un administrateur système et réseaux n'est pas capable d'utiliser un des très nombreux outils très performants en ligne de commande (de ufw pour les débutants à shorewall pour les besoins avancés). Merci pour eux.

2/ Linux a déjà dépassé les 60% de parts de marché sur les serveurs web et les 25% de téléphones mais c'est pas grave, restons alarmistes, un système qui a 60% des parts d'un marché n'est pas intéressant pour les pirates ; si la part de marché augmente encore les pirates s'y intéresseront.

Ah non désolé, selon toi les pirates ne s'intéressent probablement qu'aux postes de travail, ils ne cherchent pas à pirater les serveurs. Vu que c'est sur le poste de travail que Linux a grosso modo 1% de parts de marché...

Dernière modification par tiramiseb (Le 19/03/2013, à 21:06)


Sébastien Maccagnoni-Munch - administrateur Linux depuis le XXème siècle
Consultant informatique indépendant - http://www.smm-informatique.fr
Geek et tout plein d'autres choses - http://www.tiramiseb.fr

Hors ligne

#62 Le 19/03/2013, à 21:04

tiramiseb

Re : Filtrage réseau sous Linux et son avenir

Haleth a écrit :

Ouais, j'avoue, c'est l'IP de mon "router" (boite avec 3 puces, un port ethernet et un Linux dessus, pas de conf spécial).

Ouais enfin bon ton routeur, comme tu le dis c'est déjà un Linux... Donc pas sécurisé selon Pierre Lhabitant !
Et puis toutes les Freebox ce sont des Linux aussi, donc pas sécurisés selon Pierre Lhabitant non plus.
Ou peut-être que "un routeur sous Linux" c'est sécurisé alors que "un serveur sous Linux" c'est pas sécurisé ? hahaha

Pierre : tu as besoin d'autres exemples où Linux est le noyau d'un matériel très largement diffusé ?

Dernière modification par tiramiseb (Le 19/03/2013, à 21:07)


Sébastien Maccagnoni-Munch - administrateur Linux depuis le XXème siècle
Consultant informatique indépendant - http://www.smm-informatique.fr
Geek et tout plein d'autres choses - http://www.tiramiseb.fr

Hors ligne

#63 Le 19/03/2013, à 22:55

Brunod

Re : Filtrage réseau sous Linux et son avenir

Haleth a écrit :

...
J'te donne un autre os à ronger: un server de la boite, du genre qu'on range dans une armoire. Étant admsys, je pense être compétent pour te dire qu'il n'y a pas de conf spécifique, iptables ou autre.

IP: 178.250.209.22
..

http://debit.kwaoo.net/

Starting Nmap 5.00 ( http://nmap.org ) at 2013-03-19 21:42 CET
NSE: Loaded 30 scripts for scanning.
Failed to find device wlan0 which was referenced in /proc/net/route
Initiating Ping Scan at 21:42
Scanning 178.250.209.22 [8 ports]
Completed Ping Scan at 21:42, 0.06s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 21:42
Completed Parallel DNS resolution of 1 host. at 21:42, 0.14s elapsed
Initiating SYN Stealth Scan at 21:42
Scanning debit.kwaoo.net (178.250.209.22) [1000 ports]
Discovered open port 80/tcp on 178.250.209.22
Discovered open port 22/tcp on 178.250.209.22
Discovered open port 5001/tcp on 178.250.209.22
Completed SYN Stealth Scan at 21:42, 8.01s elapsed (1000 total ports)
Initiating Service scan at 21:42
Scanning 3 services on debit.kwaoo.net (178.250.209.22)
Completed Service scan at 21:44, 116.03s elapsed (3 services on 1 host)
Initiating OS detection (try #1) against debit.kwaoo.net (178.250.209.22)
Retrying OS detection (try #2) against debit.kwaoo.net (178.250.209.22)
178.250.209.22: guessing hop distance at 11
Initiating Traceroute at 21:44
Completed Traceroute at 21:44, 0.62s elapsed
Initiating Parallel DNS resolution of 14 hosts. at 21:44
Completed Parallel DNS resolution of 14 hosts. at 21:44, 1.06s elapsed
NSE: Script scanning 178.250.209.22.
NSE: Starting runlevel 1 scan
Initiating NSE at 21:44
Completed NSE at 21:44, 4.09s elapsed
NSE: Script Scanning completed.
Host debit.kwaoo.net (178.250.209.22) is up (0.024s latency).
Interesting ports on debit.kwaoo.net (178.250.209.22):
Not shown: 997 closed ports
PORT     STATE SERVICE        VERSION
22/tcp   open  ssh            OpenSSH 5.5p1 Debian 6+squeeze3 (protocol 2.0)
|  ssh-hostkey: 1024 fd:0a:56:90:54:0d:3a:06:c8:fd:9a:29:f4:e9:53:dc (DSA)
|_ 2048 d9:1d:57:94:94:d9:37:ab:b8:c9:f6:99:4b:3d:82:ca (RSA)
80/tcp   open  http           Apache httpd 2.2.16 ((Debian))
|_ html-title: Test de d\xE9bit K-Net
5001/tcp open  commplex-link?
OS fingerprint not ideal because: Host distance (11 network hops) is greater than five
No OS matches for host
Uptime guess: 0.449 days (since Tue Mar 19 10:57:39 2013)
Network Distance: 11 hops
TCP Sequence Prediction: Difficulty=262 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: OS: Linux

Une vraie passoire ! Bin oui, mais c'est le rôle d'un serveur qu'on puisse y accéder smile


Windows est un système d'exploitation de l'homme par l'ordinateur.
Linux, c'est le contraire ... --> état de la conversion : 34 pc linux

Hors ligne

#64 Le 20/03/2013, à 09:29

Pierre Lhabitant

Re : Filtrage réseau sous Linux et son avenir

On peut remarquer que quand j'ai posé la question "à ton avis?" personne n' a répondu avec précision, vraiment inquiétant, comme je l'ai déjà fait dit, les connaissances basiques en matière d'attaque réseau sont quasi nulles chez certains membres de ce forum.

Les box, les serveurs c'est du linux... évidemment c'te blague! des hackers capables de pirater du linux ça doit se compter sur les doigts d'une main, ces messieurs pensent rentabilité, à quoi ça sert de s'intéresser à un parc de 1% de PC qui ne va pas rapporter un rond? il ne faut pas prendre pour une qualité intrinsèque (du noyau linux) ce qui n'est que le résultat d'une rareté persistante.

Donc, "à ton avis?", si le routeur (linux) est sans faille détectée (pour l'instant), s'il n'y a pas de ports ouverts, de serveur sans surveillance et/ou mal configuré, inutile de lancer les petites commandes, pas d'attaque directe possible, restent les attaques indirectes, d'où ma question sur l'adresse email, voilà ce qu'on aurait dû me répondre.

Dernière modification par Pierre Lhabitant (Le 20/03/2013, à 09:31)

Hors ligne

#65 Le 20/03/2013, à 09:42

tiramiseb

Re : Filtrage réseau sous Linux et son avenir

On peut remarquer que quand j'ai posé la question "à ton avis?" personne n' a répondu avec précision

Si, je t'ai répondu avec précision que je suis effaré par le nombre de lignes que tu es obligé de maintenir ; que si vraiment ces lignes sont nécessaires sous Windows, alors en effet Windows est une passoire !
Et si tu veux une réponse sur le contenu de ces lignes, fais l'effort de bien les présenter car on n'a pas nécessairement des heures à perdre pour remettre en forme une telle liste mal présentée juste pour tes beaux yeux. Si tu veux un conseil basé sur ces données non formatées, tu peux payer une prestation d'un consultant qui se fera un plaisir d'y passer du temps et de te facturer ce travail.

à quoi ça sert de s'intéresser à un parc de 1% de PC

Tu te fous vraiment de la gueule du monde, non ?
Je t'ai donné les détails de l'utilisation du noyau Linux dans le monde ! Plus de la moitié des serveurs ! Plus du quart des téléphones ! 1% sur le bureau, et alors ? Les PC de bureau ne sont pas les seuls équipements connectés à Internet, loin de là ! Et parce que je suis gentil et je ne suis pas encore assez vexé que tu ne lises pas correctement nos messages et les liens inclus, je te redonne le lien qui détaille un peu ça :
http://en.wikipedia.org/wiki/Usage_shar … ng_systems

Pourquoi t'évertues-tu à ne pas lire nos réponses ?
Je te pose une question précise, j'attends une réponse précise de ta part. Comme toi.

restent les attaques indirectes, d'où ma question sur l'adresse email

Quel est le rapport entre une "attaque indirecte" et une adresse e-mail ?
Mon adresse e-mail perso est "sebastien@tiramiseb.fr". Mon adresse e-mail pro est "sebastien@smm-informatique.fr". Quel est le rapport entre ces adresses et mon fournisseur d'accès ?
Je te pose une question précise, j'attends une réponse précise de ta part. Comme toi.

Tout ce que tu peux faire avec une adresse e-mail, c'est du social engineering. Mais je ne pense pas qu'une personne qui fréquente Ubuntu-fr te répondrait des informations confidentielles par e-mail smile


Pour finir, avec un "comportement" comme le tien ne t'étonne pas que certains ne te répondent tout simplement pas... Un peu de cordialité et de lecture des réponses serait, je pense, bénéfique à notre compréhension mutuelle.

Ce que tu es en train de faire là, on appelle ça du FUD : Fear, Uncertainty, Doubt.
http://fr.wikipedia.org/wiki/Fear,_unce … _and_doubt


Sébastien Maccagnoni-Munch - administrateur Linux depuis le XXème siècle
Consultant informatique indépendant - http://www.smm-informatique.fr
Geek et tout plein d'autres choses - http://www.tiramiseb.fr

Hors ligne

#66 Le 20/03/2013, à 10:09

Brunod

Re : Filtrage réseau sous Linux et son avenir

Pierre Lhabitant a écrit :

...
Donc, "à ton avis?", si le routeur (linux) est sans faille détectée (pour l'instant), s'il n'y a pas de ports ouverts, de serveur sans surveillance et/ou mal configuré, inutile de lancer les petites commandes, pas d'attaque directe possible, restent les attaques indirectes, d'où ma question sur l'adresse email, voilà ce qu'on aurait dû me répondre.

La seule attaque indirecte valable est l'adresse physique du serveur : tu y vas avec un pied de biche et tu ramènes le dd chez toi.
Une adresse mail, comme on vient de le dire, ne sert à rien.


Windows est un système d'exploitation de l'homme par l'ordinateur.
Linux, c'est le contraire ... --> état de la conversion : 34 pc linux

Hors ligne

#67 Le 20/03/2013, à 10:51

Pierre Lhabitant

Re : Filtrage réseau sous Linux et son avenir

"Et si tu veux une réponse sur le contenu de ces lignes, fais l'effort de bien les présenter"

C'était juste pour montrer la différence entre un vrai outil réseau (de windows) et celui de linux, pas plus.


ps: hâbleur s'abstenir, réponse précise sans attaque personnelle souhaitée.

Hors ligne

#68 Le 20/03/2013, à 10:58

Pierre Lhabitant

Re : Filtrage réseau sous Linux et son avenir

Pour les gens intéressés par le problème des attaques et les méthodes employées, voir les sites de hack, mais attention dans le choix des URL, on ne sait jamais... même chez linux.

Dernière modification par Pierre Lhabitant (Le 20/03/2013, à 11:01)

Hors ligne

#69 Le 20/03/2013, à 11:16

tiramiseb

Re : Filtrage réseau sous Linux et son avenir

C'était juste pour montrer la différence entre un vrai outil réseau (de windows) et celui de linux, pas plus.

La différence entre un outil qui a besoin de 600 règles pour être sécurisé et un outil qui est sécurisé de lui-même sans avoir besoin de boucher des trous ?
C'est bon, la différence on la connaît.


Pour les gens intéressés par le problème des attaques et les méthodes employées, voir les sites de hack

Donnes des liens s'il te plaît, si tu veux qu'on parle de la même chose...


Sébastien Maccagnoni-Munch - administrateur Linux depuis le XXème siècle
Consultant informatique indépendant - http://www.smm-informatique.fr
Geek et tout plein d'autres choses - http://www.tiramiseb.fr

Hors ligne

#70 Le 20/03/2013, à 11:20

Pierre Lhabitant

Re : Filtrage réseau sous Linux et son avenir

Voir mon lien nmap, c'est une bonne approche, et il n'est pas pourri.

Hors ligne

#71 Le 20/03/2013, à 11:54

tiramiseb

Re : Filtrage réseau sous Linux et son avenir

Voir mon lien nmap, c'est une bonne approche, et il n'est pas pourri.

Ce qui est dommage avec ce document, c'est qu'il est vieux, très vieux : publié en 1997, il y a 16 ans. Ne s'appuyer que sur ce document, c'est léger comme approche. Et puis le site officiel de nmap n'est pas "un site de hack"... Ce document, ce n'est rien d'autre que l'une des premières versions de la documentation de nmap...

Cela étant dit, bien qu'obsolète il aborde pas trop mal le sujet du scan de port (heureusement, de la part de l'auteur de nmap smile ).

Mais cela n'est, justement, qu'un document parlant du scan de ports.
Je ne vois pas en quoi ce document apporte quoi que ce soit par rapport à la différence entre le firewall et Windows et Netfilter.
Le scan de port n'est qu'une éventuelle première approche dans un piratage.

Les sujets abordés par ce document sont les suivants (tu veux de la précision, tu auras de la précision) :
- Vanilla TCP connect() scanning : découverte brute et simple des ports ouverts - dans ce cas, s'il n'y a pas de démon/service en écoute, il n'y a pas besoin de filtrage, que ce soit sous Windows ou sous Linux ;
- TCP SYN (half open) scanning : découverte de ports mais sans répondre au paquet "SYN|ACK" - on ne découvre pas plus de chose qu'avec la technique précédente, par contre ces tentatives peuvent ne pas être enregistrées par certains outils (donc scan plus discret) - dans ce cas, s'il n'y a pas de démon/service en écoute, il n'y a pas besoin de filtrage, que ce soit sous Windows ou sous Linux ;
- TCP FIN (stealth) scanning : découverte de ports encore plus discrète, on envoie un paquet "FIN" (on demande de terminer une communication), alors s'il n'y a rien en écoute le serveur répond "RST" (il n'y a pas de communication à terminer) - de cette manière, on peut voir quels ports ne sont pas en écoute, cela ne permet en tout cas pas de pénétrer un serveur - cette technique permet aussi de différencier un système Linux/UNIX (qui répond "RST" uniquement quand un port est en écoute, conformément à la norme) et un système Windows (qui ne respecte pas la norme et qui répond "RST" pour tous les ports) ;
- Fragmentation scanning : juste une autre manière discrète de savoir si un port est ouvert ou non, on ne va pas s'éterniser hein - soit on voit qu'un port est ouvert, soit on ne le voit pas - cette technique ne fonctionne pas partout par contre elle est vachement discrète ;
- TCP reverse ident scanning : cette méthode permet d'identifier quel est l'utilisateur qui fait tourner un service - si l'utilisateur est "root", alors ce service est très intéressant : si on arrive à le corrompre on a tous les droits sur un système, un pirate risque alors de s'y concentrer - mais sous Linux, la grande majorité des services n'écoutent pas en tant que root, dans ce cas cette découverte est inutile ;
- TCP ftp proxy (bounce attack) scanning : cette technique fait des tentatives de connexion par proxy FTP - il peut alors être possible de déposer des fichiers sur un serveur FTP qui aurait dû être protégé par un pare-feu de réseau - mais pour cela, encore faut-il qu'un serveur propose le service FTP, qui est quand même l'un des moins sécurisés des protocoles réseau - de nos jours, FTP n'est plus utilisé par les administrateurs sérieux ;
- UDP raw ICMP port unreachable scanning : il s'agit là d'essayer de trouver les ports UDP ouverts, en cherchant à obtenir les réponses ICMP "unreachable" - c'est une des justifications qu'utilisent certains "spécialistes" de la sécurité pour le blocage d'ICMP - mais de toute manière, s'il n'y a pas de démon/service en écoute, il n'y a pas besoin de filtrage car il n'y a pas de risque d'attaque - je suis pour ma part opposé au filtrage des paquets ICMP de ce genre, leur inconvénient étant plus important que la sécurité que ça apporterait ;
- UDP recvfrom()  and write() scanning : encore une autre technique pour trouver les ports UDP ouverts, qui utilise également les messages ICMP pour savoir si un port est ouvert ou non - encore une fois, on peut filtrer l'ICMP pour ça, mais la pseudo-sécurité que ça apporte est bien maigre face aux inconvénients que rencontre l'administrateur au jour le jour - et de toute manière, s'il n'y a pas de démon/service en écoute, il n'y a pas besoin de filtrage car il n'y a pas de risque d'attaque ;
- ICMP echo scanning (ping-sweep) : un simple ping pour savoir si un hôte est présent ou non - je ne vois pas quel en est l'intérêt, vu qu'un scan de port permet de savoir si le serveur est joignable ou non, et sur quel(s) port(s) - c'est juste un "ping", quoi - combien d'administrateurs réseau n'ont jamais été emmerdés par un "ping timeout" ? encore un filtrage qui est plus un inconvénient pour les administrateurs qu'une piste valable pour un pirate.


Que ce soit sous Windows ou sous Linux, arrêter les services inutiles est la meilleure chose à faire pour sécuriser un serveur.
De mon point de vue, la différence est que :
- sous Linux, ces services ne sont pas activés (même pas installés) par défaut
- sous Windows, les gens semblent préférer bloquer les ports avec un firewall plutôt qu'arrêter les services (je ne saurais pas dire pourquoi)

De toute manière un scan de port réussira à voir les ports ouverts et les ports fermés. Il faut correctement sécuriser son système en arrêtant les services inutiles et en ne faisant rien tourner "en tant que root", mais ce ne sont que des règles de bon sens... Un pare-feu est, là, inutile.

Comme je l'ai déjà expliqué et que je le réexplique, s'il n'y a pas de service/démon en écoute il n'y a pas besoin de filtrage. Et s'il y a besoin de ne pas écouter un port, il est bien plus sécurisé d'arrêter complètement le service, un pare-feu n'est donc pas nécessaire.





Et si toutefois on souhaite faire du filtrage, le pare-feu de Linux (Netfilter) est tout aussi performant que celui de Windows, sinon plus.

Ce n'est pas la nécessité de mettre en place des centaines de règles qui définit l'efficacité d'un pare-feu.
Cette nécessité ne fait que démontrer le besoin de bloquer des services sous Windows qui ne devraient pas fonctionner par défaut.

Dernière modification par tiramiseb (Le 20/03/2013, à 11:55)


Sébastien Maccagnoni-Munch - administrateur Linux depuis le XXème siècle
Consultant informatique indépendant - http://www.smm-informatique.fr
Geek et tout plein d'autres choses - http://www.tiramiseb.fr

Hors ligne

#72 Le 20/03/2013, à 12:37

Pierre Lhabitant

Re : Filtrage réseau sous Linux et son avenir

"s'il n'y a pas de démon/service en écoute, il n'y a pas besoin de filtrage"


Déjà répondu là dessus, inutile de délayer la même chose, c'est sans intérêt, pour un windowsien un daemon/service on peut en faire ce qu'on veut, le démarrer, le fermer, se faire passer pour lui, de l'illusion de protection chez linux par manque d'expérience vécue.


nmap (et quelques outils qui vont avec) trop vieux... pfff! ça fait rire, si tu veux des liens "hack" tout frais cherche les toi même, tu retrouveras nmap, mais pas sûr que le modo va apprécier.

Dernière modification par Pierre Lhabitant (Le 20/03/2013, à 12:39)

Hors ligne

#73 Le 20/03/2013, à 12:47

tiramiseb

Re : Filtrage réseau sous Linux et son avenir

"s'il n'y a pas de démon/service en écoute, il n'y a pas besoin de filtrage"
Déjà répondu là dessus, inutile de délayer la même chose, c'est sans intérêt, pour un windowsien un daemon/service on peut en faire ce qu'on veut, le démarrer, le fermer, se faire passer pour lui, de l'illusion de protection chez linux par manque d'expérience vécue.

Alors je ne comprend pas ta réponse.

Quand on est administrateur sur un système, on sait ce qui tourne comme logiciel, on sait ce qui est en écoute.
Le service, quand il est arrêté il est arrêté. Donc il n'y a pas de possibilité de pénétrer par le port concerné.
Je ne vois pas en quoi ta réponse dit le contraire.

"illusion de protection" ? comment ça ? S'il n'y a pas de service, il n'y a pas d'écoute : s'il n'y a pas d'écoute il n'y a pas de possibilité de faille liée au service. Je ne comprend pas ton raisonnement.
Si un pirate a déjà accès au serveur au point de pouvoir lancer un service, alors il vaut mieux réinstaller entièrement le système, ce n'est pas installer un pare-feu qui protégera quoi que ce soit.


Je pense vraiment qu'il y a un point d'incompréhension autour de cela... Mais je n'arrive pas à voir ce que tu n'arrives pas à comprendre dans le raisonnement simple que je t'explique ci-dessus.


Sébastien Maccagnoni-Munch - administrateur Linux depuis le XXème siècle
Consultant informatique indépendant - http://www.smm-informatique.fr
Geek et tout plein d'autres choses - http://www.tiramiseb.fr

Hors ligne

#74 Le 20/03/2013, à 13:19

Haleth

Re : Filtrage réseau sous Linux et son avenir

À partir du moment où ton système est suffisament troué pour permettre à X de controler le compte root ..
Il peut désactivé ton parefeu, donc ca ne te sert, une fois de plus, à rien.

Par ailleurs, il peut également controller la chaine de boot, donc le secureboot de m$ (j'suis sur que t'es un fan, non ?) ne sert, également, à rien.

Ne pas croire les marketeux..


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

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

Hors ligne

#75 Le 20/03/2013, à 13:22

Bigcake

Re : Filtrage réseau sous Linux et son avenir

Résumons :
- J'étale mon incompréhension au fonctionnement réseaux, kernel, firewall, à la sécurité informatique de manière générale (rien de honteux la dedans)
- J'impose mon point de vue erroné
- Je réponds a coté des arguments avancés
- Je continue à sortir des inepties maintes et maintes fois démontrés fausse
- Je donne le moins d'arguement possible en critiquant les compétences de ceux qui répondent

Je suis ....? je suis .....? un bon gros troll poilu !!!! (2ème possibilité : une personne immature qui ne connait pas la remise en question)

Bravo pour ta patience tiramiseb ! Pour ma part, j'ai sorti le pop-corn \o/

Dernière modification par Bigcake (Le 20/03/2013, à 13:23)


"Les gens" ne sont pas con, ils ont été habitués à la facilité et à la désinformation. Le meilleur moyen de ne pas les aider, c'est de se moquer. Le meilleur moyen de les aider, c'est de les informer, encore et encore. La réflexion viendra. N'oubliez pas que vous aussi, vous êtes le con d'un autre.
HADOPI/LOPPSI/ACTA/CETA ou comment détruire le net
Radio+musique libre= www.oxyradio.net

Hors ligne

Haut de page ↑