[routeur]demande d'amélioration

[djibb]

Bonjour,

sera-t-il possible d'avoir une possibilité de mettre en place une DMZ sur le routeur, avec une prise réseau dédiée ?
J'm'ixplik :
1) de toutes façons, dès qu'on a plus de 2 ordis connectés, on doit mettre un switch. (2 ordis + 1 NAS + le téléphone + la télé, ça passe pas)
2) dès qu'on veut profiter du débit et faire de l'auto-hébergement, on est obligés de jouer avec les ports (et la dernières fois que j'ai joué avec le port 80 le routeur a pas apprécié.). Et puis -> le 80, le 21, le 22 et je ne sais quoi encore ça lui fait pas mal à gérer. Et c'est lourd (même si l'interface est très claire et fonctionnelle)

-> pourquoi ne pas éventuellement avoir la possibilité de rediriger tout le trafic externe vers une DMZ, avec port dédié ? (ou Mac... je suis pas sectaire). Par défaut non activée. Et pour la personne qui l'active elle doit savoir ce qu'elle fait (protection des ports de son côté etc.)


Voilou, c'était la demande du jour.

[Nico_S]

1) Si tu as plus de 4 PC il te faudrait aussi un switch, si les ports 3 et 4 n'étaient pas occupés, donc autant acheter un switch tout de suite 
Par exemple, chez moi j'ai 4 PC permanent, un serveur FTP permanent et deux autres machines quand j'ai besoin de tester, une imprimante réseau, le téléphone déporté du PAP2T, il faut donc un switch obligatoirement, et de nos jours nombreux sont ceux qui des installations similaires, donc le switch s'impose de lui même, aucune box n'étant pourvu de suffisamment de ports (les FAI doivent penser que le wifi c'est bien  )
2) Chez moi ça fonctionnait bien le redirection de port, et pourtant je partageais (avec le routeur K-Net, j'ai changé de routeur depuis) des serveurs web apache sur le 80, le 8080, le 8181 et le 443 + un serveur FTP sur le 21.
Tous étaient accessibles (depuis je ne suis plus que sur un FTPES et un accès distant sécurisé).

Si je ne me trompe pas, même si tu veux héberger chez toi plusieurs sites (ou serveurs) web sur le même port, c'est ta configuration apache qui va dispatcher l'accès vers tes différents sites via le même port, non ?
DU coup la DMZ devient inutile. ET quitte à demander le retour de la DMZ (qui doit exister sur le FW original Netgear), autant demander le retour de toutes les autres fonctions qui ont été cachées et qui seraient pour certains nécessaires (certaines ont déjà été demandées sur le forum).

[jack]

Tu peux mettre ton matériel en passant la kbox en mode bridge, et ensuite faire ce que tu veux chez toi;

La DMZ, si tu parles bien de ça est, pour citer Sheakspeare, "beaucoup de bruit pour rien" : une augmentation drastique de la complexité pour un gain de sécurité nul.

M'enfin sache que la solution est en vue :
(http://i.qkme.me/3oyc8o.jpg)

[djibb]

hé hé

oki

en fait, la dernière fois que j'ai joué avec les ports... j'ai perdu ma connexion (et j'étais loin de chez moi).

En fait, je viens d'essayer, ça marche bien finalement. Effectivement, ça vaut ptet pas le coup.

[Nico_S]

Tu peux mettre ton matériel en passant la kbox en mode bridge, et ensuite faire ce que tu veux chez toi;

La DMZ, si tu parles bien de ça est, pour citer Sheakspeare, "beaucoup de bruit pour rien" : une augmentation drastique de la complexité pour un gain de sécurité nul.

M'enfin sache que la solution est en vue :
(http://i.qkme.me/3oyc8o.jpg)

Je croyais que c'était inutile le mode bridge sur resoliain, car c'est le CPE qui est le premier élément actif et ensuite le routeur K-Net qui ... route !
Pas comme sur 4CF ou c'est le routeur qui est le premier élément actif du réseau.
Sauf si djibb est sur 4CF.

Sinon a quand IPV6 ?

[guizmos123]

Mode bridge = switch.

En IPV4, c'est le routeur qui fixe des IP des appareils connectés (limité à 254 IP privé généralement en 192.168.1.X). Le routeur gère intégralement le traffic (redirection des ports, UPNP, NAT,...). C'est plus facile à gérer en locale (gestion des IP), plus sure (tout les ports fermés par défaut, ou presque) mais beaucoup plus restrictif vu d'Internet (on ne peut accéder qu'à 1 machine pour 1 port).

En IPV6, ce sont les appareils connectés au switch (ou borne Wifi en bridge) qui récupère automatiquement une IP public parmi une très large plage fournie par K-Net (on parle de millions d'IP pour 1 seul client !). Le gros plus par rapport à l'IPV4 est que chaque machine dispose d'une IP public, donc directement connecté et accessible au net (n'importe quel service, n'importe quel port,...).
Par contre le gros gros point négatif est que chaque appareil doit avoir son système de sécurité actif (firewall) car tout est disponible (pas de NAT, tout les ports ouvert).

[gloubi]

La DMZ, si tu parles bien de ça est, pour citer Sheakspeare, "beaucoup de bruit pour rien" : une augmentation drastique de la complexité pour un gain de sécurité nul.

Bonjour,

Navré pour ce premier post qui pourra paraître un peu agressif, mais j'ai été choqué de voir ce qui a été écrit par un membre de k-net.
Dans le lien wikipedia que tu cites, troisième paragraphe :

En cas de compromission d'un des services dans la DMZ, le pirate n'aura accès qu'aux machines de la DMZ et non au réseau local.

Si l'isolation périmétrique d'une attaque informatique est un "gain de sécurité nul", j'aimerais connaitre ta position quant à la sécurisation de la publication de services sur Internet, quel que soit le type.

[SendLaB]

Ne serait-il pas judicieux d'ouvrir un sujet pour les demandes d'amélioration pour le firmware K-Net ?
Chacun irait de ses suggestions et l'équipe de développement pourrait attribuer à la ToDo/Wishlist/Roadmap des priorités.

[jack]

Je suis partisan du KISS: Keep It Simple, Stupid
La sécurité par l'obscurité est un échec, on peut le constater avec de nombreux projets logiciels.
Ainsi, je pense que faire un sac à noeud dans un réseau pour "perdre l'attaquant dans un foutoir" est une mauvaise idée : d'abord parce que ce n'est pas suffisant (question de persévérance), ensuite parcque cela rend la gestion du réseau beaucoup plus complexe, il est donc plus simple de faire des erreurs (ce qui diminue la sécurité de l'ensemble).

Enfin, il ne faut pas oublié que 76% des "compromissions" ont pour origine l'intérieur du réseau, et non le monde extérieur. Dans la plupart des cas, c'est l'utilisateur (le logiciel ou la personne devant) qui "invite" un méchant (a priori, sans le savoir / vouloir). Lorsque ce dernier est en place, il peut faire ce qu'il souhaite. Il est dans la partie "sécurisé" de ton réseau DMZ (la partie "postes clients", pour reprendre le schéma de wikipedia). À noter que c'est pour cette même raison que les parefeu "nazi" ont une utilité plus que limité.

Ma position quant à la mise à disposition de services sur le réseau : le service est seul compétent pour se protéger. Un tiers peut difficilement savoir ce qui est bon ou pas. Par exemple pour un serveur Web, seule l'application (php ..) peut trier les bonnes requêtes des mauvaises. Un tiers ne peut identifier si cette requête contenant du SQL est légale ou pas.
Dans l'ensemble, chaque service possède un environnement limité et suffisant, dans lequel il est compétent pour assurer sa propre sécurité.

Pour conclure, deux points qui, à mon humble avis, augmentent considérablement la sécurité :
- une machine par service (limitation physique des risques)
- pas de services inutiles

Je sais que certains systèmes aiment utiliser beaucoup de ressources pour faire fonctionner une plétore de services inutiles, la vie est dure 
Qu'en penses-tu ?

PS: ceci n'est que mon avis, je ne suis pas le porte-parole de Knet

[gloubi]

Déjà, merci pour cette réponse complète ! Ca fait plaisir de voir des gens capables de discuter pour de vrai, ça n'est plus si courant sur les forums

Pour ma part, je pense qu'il ne faut pas mélanger les choses, et que tu mixes un peu trop les différents niveaux.

Pour les 76% (chiffre très aléatoire donné par les éditeurs de solution de sécurité, qui les arrange tout à fait. Crois-moi, je bossais chez l'un deux..) d'attaquants externes, on ne parle pas d'attaque par rebond sur un poste/serveur piégé, mais bien d'éléments internes à l'entreprise s'attaquant au SI : admin sys/dba viré qui casse tout, comptable qui vole les données fournisseurs (si si, c'est comptabilisé dedans), technicien avec un peu trop de délégations sur le serveur mail qui va mater les salaires de ses collègues dans la BaL du DRH, admin réseau qui fait partie d'un groupe quelconque et qui ouvre son système à de vilains externes pour diverses raisons.

Pour ce qui est de "perdre l'attaquant dans un foutoir", je te l'accorde, ça ne sert à rien -DU TOUT. En revanche, créer une DMZ aux permissions spécifiques, c'est à dire que la machine peut être contactée depuis le web sur le port de ses services publiés, n'a pas le droit de sortir vers le web sur tous les protocoles, n'a pas le droit de contacter le LAN, etc, c'est très utile et même s'il y a élévation de pouvoir sur la dite machine, l'attaquant sera piégé par des règles de firewall auxquelles il ne pourra toucher puisque externes à la machine. Et non, les clients ne sont pas, ne sont jamais dans une DMZ.

En gros le schéma idéal de publication :

||InterWeb des méchants|| -> ||DMZ publique avec rproxy et première IDS ou directement le service si pas de front possible|| -> ||DMZ privée avec l'appli et les données|| -> ||LAN/LAN Serveurs||

A chaque flèche va correspondre une limitation protocolaire : si tu publies un Exchange en WebAccess, en DMZ Publique tu auras uniquement TMG, en DMZ Privée01 tu auras la publication web OWA, en DMZ Privée02 tu auras un RODC, ton web OWA pourra joindre le RODC uniquement en LDAP sécurisé via Kerberos, ainsi que ton CAS/DAG via HTTPS. Tes clients internes joindront tout directement sur l'Exchange core.

Pour ce qui est ensuite de la sécurité applicative, c'est encore une autre couche. D'une part la présence d'IDS et de scripts réagissant à des connexions/comportements anormaux est une très bonne base, faire tout tourner en chroot lorsque c'est possible ou en jail pour les gens qui utilisent des os réellement durcis (don't feed the troll) c'est encore mieux, mais ça n'exclue pas de ne jamais mixer des réseaux en connexion directe avec l'extérieur et le réseau dit sécurisé. Et l'utilisation d'un proxy sécurisé type Bluecoat est encore meilleure, puisqu'on peut faire de la détection fine via DPI sans pour autant brider les utilisateurs.

Le souci de la machine par service c'est que ça marche super bien en environnement virtualisé et dans le cas de boites qui utilisent massivement des *nix libres. Dès que tu commences à penser en terme de licence et de support, notamment sur du service hébergé, ça peut revenir très cher au fournisseur comme au client.

Après, il est aussi possible qu'on ne se comprenne pas simplement parce qu'on évolue dans des environnements un peu trop différents (ISP contre consultant pour diverses boites ou hébergeurs)  

Au plaisir

[jack]

C'est sur que ne pas pouvoir faire confiance à son collègue, c'est une situation difficile;
Me méfier de moi-même, voila ce que je ne conçois pas

Après, il est aussi possible qu'on ne se comprenne pas simplement parce qu'on évolue dans des environnements un peu trop différents (ISP contre consultant pour diverses boites ou hébergeurs)  

Je pense que c'est tout à fait cela 

NB: 76%, c'est sorti du chapeau : rien ne vaut les bonnes vieilles stats pour soutenir un discours, pas vrai ?

[gloubi]

Les grands chiffres c'est 50% des attaques externes avec complicité interne, 75% d'attaques purement internes.
Et oui, maintenant qu'on a bétonné la sécurité de l'extérieur, pour continuer à vendre, faut bien créer une nouvelle menace

Se méfier de soi-même ? Discutable, mais je me souviens de la phrase qu'on se répétait sans cesse à l'époque à laquelle j'étais admin sys :

Il y a deux types d'admins Unix. Ceux qui ont fait un #rm -rf / en prod... Et ceux qui vont le faire !