Note aux modos: Merci de supprimer le post mis par mégarde sur la sous catégorie "réseau public"  

 
 
Bonjour à tous, me voici de retour pour vous jouer un mauvais...
 
Alors voila, a priori le sujet que je vais traiter à déjà fait l'objet d'un topic datant de 2010/2011. Et ne répondant pas aux questions que je me pose, j'ai donc décider d'en ouvrir un nouveau.
 
Afin que tous le monde puissent comprendre je vais tenter de décrire au mieux mon architecture dans un premier temps, puis le(s) problème(s) que je rencontre.
 
Materiel:
- Des postes clients (win 7, vista, win8).
- Firewall IPCOP 2.0.6
- Serveur 2003 (oui encore lui ) avec AD, controleur de domaine (nom de domaine: ADtest.local)
 
Configuration du firewall:
 
Interface Rouge: coté Internet (donc vers mon routeur FAI)
Interface Verte: réseau local, @réseau: 10.101.0.0/16 @interface: 10.101.0.1
Interface Bleu: réseau local restreint (j'en reparle après), @réseau: 10.104.0.0/16, @interface: 10.104.0.1
Interface Orange: pas de rapport avec le(s) problème(s) donc osef.
 
 
Alors pour le réseau sur l'interface Bleu, c'est le réseau où les développeurs pourrons utiliser Internet. Mais ne pas avoir accès aux serveur qui son situer dans le réseau Vert SAUF l'active directory afin qu'il puisse se loggé.
 
Coté restrictions, sur toutes les interfaces sont en mode "fermée", donc rien n'est autorisé.  
 
 
Les besoins sont les suivants:
 
- Réseau Vert doit avoir accès aux services suivants (http, https, imap, imaps, pop3, pop3s, smtp, dns)
Les utilisateurs sont loggés sur le domaine, et peuvent allez sur Internet, utiliser leur messagerie.
 
- Réseau Bleu doit avoir accès au services suivants (http, https, dns)
Donc allez sur Internet tranquille.
Mais ils doivent être loggué sur le domaine. Du coup j'ai ajouter les services suivants (ldap, ldaps, epmap, kerberos, microsoft-ds, msft-gc et msft-gc-ssl). Cette liste que j'ai pris sur le site de microsoft.
 
 
J'ai donc réalisé une matrice de flux entre les interfaces: désolé c'est pas super beau    
 
 
Services utilisés  IP Source          Port Source IP Destination  Port Destination     Valeur
 
Ipcop https        10.101.0.10 (admin)      *       10.101.0.1 (ipcop)     TCP 8443      autoriser
Ipcop https         *                              *       10.101.0.1 (ipcop)     TCP 8443      refuser
 
Http                 10.104.0.0/16              *                *              TCP 80             autoriser
Https                10.104.0.0/16              *                *              TCP 443     autoriser
DNS                 10.104.0.0/16              *            IP DNS                 TCP/UDP 53     autoriser
 
Http                  10.101.0.0/16              *                *              TCP 80             autoriser
Https         10.101.0.0/16              *                     *              TCP 443           autoriser
POP3                10.101.0.0/16              *     178.xxx.xxx.xxx      TCP 110    autoriser
POP3 SSL        10.101.0.0/16              *     178.xxx.xxx.xxx      TCP 995    autoriser
SMTP                10.101.0.0/16              *     178.xxx.xxx.xxx      TCP 587    autoriser
IMap                 10.101.0.0/16              *     178.xxx.xxx.xxx      TCP/UDP 143    autoriser
IMap SSL        10.101.0.0/16              *     178.xxx.xxx.xxx      TCP 993    autoriser
DNS                 10.101.0.0/16              *             IP DNS              TCP/UDP 53     autoriser
 
LDAP                10.104.0.0/16         *     10.101.0.5 (serveur ldap)TCP/UDP 389    autoriser
LDAP SSL        10.104.0.0/16         *     10.101.0.5                TCP/UDP 636    autoriser
DNS                 10.104.0.0/16         *      10.101.0.5                TCP/UDP 53     autoriser
EPMAP (RPC EMC)10.104.0.0/16         *     10.101.0.5                TCP/UDP 135    autoriser
Msft-GC        10.104.0.0/16         *     10.101.0.5                TCP/UDP 3268  autoriser
Msft-GC-SSL      10.104.0.0/16         *     10.101.0.5                TCP/UDP 3269  autoriser
Kerberos        10.104.0.0/16         *     10.101.0.5                TCP/UDP 88     autoriser
Microsoft-ds      10.104.0.0/16         *      10.101.0.5                TCP 445     autoriser
     
 
Service Miscrosoft-ds = SMB, DFS, LsaRPC,Nbtss, NetLogonR, SamR, SrvSrc
 
Voila ma matrice. Donc j'ai mis en place ces règles sur mon IPCOP.  
 
Résultat:
 
Réseau Vert:
Toutes les entités présentes dans ce réseau on bien accès seulement aux services autoriser a passer le parfeu. Pas de ftp, pas de icmp.
Les utilisateurs peuvent accéder au domaine.
 
Réseau Bleu:
L'accès restreint à Internet est bien en place.
Par contre ils ne peuvent pas joindre le Domaine...  
 
Aurais-je oublier des ports à ouvrir ? Ou une fausse manip quelque part ?
 
Question: Comment faire pour que mes machines coter Réseau Bleu puissent rejoindre le Domaine ?
 
 
En esperant avoir été assez clair, je suis dispo si vous voulez des précisions et vous remercie d'avance pour les réponses que ce soit des critiques ou des propositions
 
Cordialement,
 
 
Nckd.

Le DHCP coté bleu fournit-il aux clients l'IP du contrôleur de domaine en seul serveur DNS ?

Le DHCP est désactivé par défaut.
Les machines présentent dans le réseau Bleu ont l'adresse du serveur DNS situé sur le réseau vert.

Qui est donc bien un serveur DNS intégré à AD ?
A partir d'un client sur le bleu, tu résous bien sans problème le FQDN de ton DC ?

Comment tester que la résolution est bien effectué ? Un Ping suffirais ?

Oui ou un nslookup.
Mais quel est le serveur DNS que tu mentionnes ?

C'est un Serveur AD, qui fait également office de serveur DNS, controleur de domaine autonome

Si vous avez des idées de ports a ouvrir qui serais succeptible de bloqué la connexion au serveur d'Authentification je suis preneur

http://support.microsoft.com/kb/179442

C'est ce que j'ai fais il me semble.  J'ai ouvert les ports: 389, 636, 53, 135, 3268, 3269, 88 et 445. Je n'ai pas ouvert les port dynamique par contre... ça pourrait venir de la. Par contre comment savoir quel port ouvrir en 1024 et 65535, sa fait plusieurs milliers de possibilité...

Bon alors cette résolution DNS ?
 
Sinon, pourquoi ne pas autoriser tout le trafic depuis le bleu vers l'IP du DC plutôt que de faire cela port par port ?

 
Tu fais une règle comme ça :
 
IP source : ton LAN bleu
Port source : any
 
IP destination : ton/tes DC
Port Destination : ton port
 

 
C'est pas le must en sécurité... mais ça peut servir à des fins de test.

Je test tout ça et je vous tiens au jus.
Pour ce qui est de la résolution DNS c'est OK.  
Merci pour vos conseils

 
 
Plutôt que d'ouvrir des tas de ports vers les services en écoute ?
Perso je ne vois pas de différence.

Si tu ne vois pas la différence, tu ferais mieux de te renseigner avant de donner ce genre de conseil.

Je vais quand même t'aider
 
Si tu ouvres toutes les portes vers ton DC, alors par exemple, un dev pourra prendre la main en RDP sur ton serveur, et depuis ce dernier, rebondir sur toute ton infra.
 
Le principe est de n'ouvrir qu'un service (en l'occurrence AD/DNS dans le cas présent) afin de s'assurer que les DEVs ne pourront pas effectuer trop de manipulations.

Oui c'est se que j'essaie de faire, actuellement, si je met cela en place dans l'état, les DEVs on accès seulement a internet. J'aimerais les intégrer dans le domaine toujours pour un problème de contrôle (Mod Corée du Nord [ON]).
Comment faire, pour n'ouvrir que AD/DNS, je pensais que les ports que j'avais ouvert suffisait mais a priori non.  

Ca devrait le faire avec la liste de port que je t'ai fournis.
 
Si ça bloque encore, il faut regarder les logs pour voir exactement ce qu'il se passe.
 
Commence par regarder les logs sur le PC, sur l'AD puis sur le Parefeu.

tu n'aurais pas du NAT ou un routage faux qui empêcherait la com ? Je dis ca car souvent c'est un truc à la con qui gêne

La liste est bonne. Toutefois, comment définir les ports dynamiques ? Je suis bloqué ici.  
Ensuite je regarderai les logs avec plaisir

 
 
Ah ouais OK, tu ouvres le LDAP 389 mais le RDP, c'est cata, c'est ça ?
Et parce qu'il devient accessible, il est plus faillible que le 389 ?
 
C'est moi qui vais t'aider. Si tu veux de la sécu qui fait bien dans le texte mais qui dans la réalité de 95% des boites n'apporte rien, tu ne fais pas ce qu'il demande.
Tu places le DC en DMZ ou tu mets en place un AD LDS.

 
 
IDEM que l'expert avant toi.
CF ma réponse.

Euhhhh il me semble être resté sympa ... Mais si tu le prends sur ce ton ..

Mettre un AD en DMZ ...

AD LDS ... Franchement ... Dans ce contexte je vois pas trop le truc, c'est bien pour les sous traitants, mais là il veut juste s'assurer que les DEVS font rien sur le réseau LAN de prod.

Rien compris à ta première phrase ... Il ouvre pas non plus le NET à son DC, mais une sorte de VLAN privée (qui n'a pas plus d'entrée depuis l'extérieur que depuis le LAN de ce que je comprends) ... Si les DEVS sont dans une DMZ alors là je préconiserais de ne pas ouvrir les ports. Il veut simplement éviter le plus possible les usages frauduleux ...

Et pour info, aux yeux d'un DG ... La sécurité n'apporte rien ... Il acquiesce parce qu'aujourd'hui la sécu a le vent en poupe, mais au fond de lui ca le gonfle les VPN, les mots de passes et les services impossibles à rendre car pas assez Secure.

Ton patron te demande de faire n'importe quoi et tu dis amen ? C'est ton problème ... Après si entre 2 LAN tu acceptes d'ouvrir tous tes ports, c'est que tu ne veux pas trop de sécu, mais plus prévenir les fausses manipes et je ne le critique pas, des fois il faut en passer par là ... Mais là ce n'est pas le cas car il se creuse la tête à vouloir limiter les usage d'un subnet à un autre.

Ou as-tu vu que je préconise de permettre l'accès total de son interface bleu à vert ?
Uniquement vers son DC.
A partir du moment où tu permets l'accès à LDAP, DNS, le partage de fichiers et j'en passe, ca fait quelle différence concrètement ?
Aucune, 0, nada, niet.
 
Mais maintenant, si tu es un esthète de la sécurité, tu ne viens pas pinailler sur RDP alors que t'as d'autres portes grandes ouvertes (d'autant plus que le RDP, tu peux toujours le limiter à l'écouter du subnet LAN).
Tu mets un DC en DMZ avec relation d'appro unidirectionnel avec ton DC sur le LAN ou oui tu utilises AD LDS.

un AD en DMZ c'est trop risqué. Je suis en sécu réseau, certes novice mais j'ai fais les gros yeux quand j'ai vu ça. Après je suis loin d'etre aussi fort que certains en la matière.
 
Euh ChaTTon2 a compris mon problème, ShonGail le contourne (mon problème).  
 
ChaTTon2, vous m'avez compris !
 
Je veux simplement que le réseau Bleu, n'ai accès qu'au serveur AD/DNS afin de faire entrer les machines dans le domaine.  
La question est simple, quels ports ouvrir. Ceux citer dans la doc Microsft OK, sauf les ports dynamique, car je ne sais pas comment les définir.
 
Je rappel que les ports des services qu'y m'ont semblé susceptible d'ouvrir sont les suivant:
LDAP TCP/UDP 389
 
LDAP SSL TCP/UDP 636
 
DNS TCP/UDP 53  
 
EPMAP (RPC EMC) TCP/UDP 135
 
Msft-GC TCP/UDP 3268
 
Msft-GC-SSL TCP/UDP 3269
 
Kerberos TCP/UDP 88  
 
Microsoft-ds (SMB, DFS, LsaRPC,      TCP/UDP 445  
Nbtss, NetLogonR, SamR, SrvSrc)
 
 
Merci pour votre aide, et vous battez pas Deal With It
 
 
 

Nan mais attends ... Mettre un minimum de barrière comme empêcher un RDS sur le serveur ... C'est quand même pas si con que ça à tes yeux ... Oui ouvrir l'annuaire au travers d'un FW oblige à ouvrir énormément de choses ... J'en suis conscient, et c'est pour cela que je dis que depuis une DMZ (même toute petite soit elle) je pourrais jamais le préconiser.
 
Mais simplement limiter un service au plus simple et empêcher qu'un rigolo ne se connecte en RDS sur le serveur DC pour ensuite avoir donc une connexion sur le LAN ... Ca empêche déjà beaucoup de "petits malins".
 
Je ne suis pas RSSI où je boss ... Mais si je lui en parle je suis sûr qu'il bondit ... Je sais pas je me fais peut être vieux, mais ouvrir tous les ports d'un réseau vers un serveur conviens à ouvrir pour moi une brèche béante ...

Si tu te connectes sur le DC en bureau à distance, c'est que t'as un un compte admin du domaine.
A partir de là, ton problème, il n'est pas au niveau du routage/firewall.
Et que les développeurs, qui font partie de la même boite que ceux sur le LAN n'aient accès "qu'à" LDAP ou SMB, le problème ne va pas être moindre.
 
De toutes façons, on discute pour rien. l'auteur du topic cherche ce qu'il veut imaginer être la sécu. Ca ne l'intéresse pas d'y réfléchir réellement.
 
Son besoin, c'est des VLAN, pas du routage entre deux départements d'une même boite ...

Suffit pas qu'un port soit ouvert pour faire ce que l'on veut avec un serveur. Il y a d'autres sécurités, comme les ACL par exemple

C'est un bon débat, après la sécurité j'y réfléchis réellement, puisque c'est mon travail. Je souhaite juste avoir plus de précision sur certain points qui me seront utiles à l'évolution de ma plateforme de test actuelle.
 
Et comment définir les ports dit "dynamique" ? toujours cette sympathique question
 

Si la sécu c'est ton dada, réfléchis alors au fait d'ouvrir un DC a des users sur lesquels tu n'as visiblement aucune confiance.
Pour que ca fonctionne, il faut ouvrir tout un tas de services dont le RDP n'est pas le moins sensible (et en plus au risque de me répéter, celui là au moins on peut limiter son écoute au subnet local).

Par expérience, il ne faut jamais faire confiance aux utilisateurs. Ou alors pouvoir cibler les responsables en cas de problèmes.  
Je vais ouvrir le 3389 et voir ce que ça donne.  
Merci de prendre le temps de me répondre en tout cas

Pour faire de l'acl il faut avoir un milieu un équipement qui le gère. Pour moi un simple switch Cisco ou autre au milieu, des vlans et effectivement des ACL ... Mais dans son archi il a un Firewall, donc je m'adapte.
 
ShonGail : Quand au fait d'avoir un compte admin du domaine pour se co à un DC ... Oui ... Mais la première cause de piratage reste la négligence d'un superuser ou d'un admin qui va taper son mot de passe alors qu'une personne le regarde, un keylogger (matériel ou logiciel ... Matériellement j'ai 2 boutique non loin du bureau qui en vendent pour une bouché de pain) ... Bref ...  
 
Si au moins il a un pc qui n'accède pas au dc en RDP et bien il lui faudra en trouver un. Rien n'est impossible ... Le risque 0 ca n'éxiste carrément pas. Si tu me dis qu'il bosse dans une boite de 5 personnes, je dirais que c'est peut être un peu démesuré comme sécu, mais je ne pense pas qu'il boss dans une TPE.
 
Après tu fais comme tu veux ...  
 
Mais ... D'ailleurs, pour clore le truc, pourquoi ne souhaites-tu pas que les devs aient un accès trop important sur le DC ? Serais-tu en train de créer ce que l'on pourrait classifier de Gros BAC à sable pour leur permettre simplement de pouvoir tester du DEV sans pour au temps impacter la prod ?

nckd -> Oui enfin là on cause d'users de ta boite.
A partir du moment où tu permets l'accès à un DC, pourquoi en totalité pour les uns et pas pour les autres ?
A part se prendre la tête sur du routage, c'est quoi le gain ?
 
Ensuite, ma préco n'est pas d'ouvrir le port 3389 spécifiquement. Il ne sert à rien pour les échanges entre postes client et DC.
On en cause car certains on voulu m'apprendre que c'était abominable d'y permettre l'accès alors que le partage de fichiers et le LDAP, ca c'est sécu
 
Ma préco, c'est de penser ton besoin, pas de mettre en place des usines à gaz techniques parce qu'on s'imagine que complexifier c'est sécuriser.
L'interface bleu sous Ipcop n'a pas été pensé pour y placer un service spécifique de la société. Elle est là pour permettre l'accès à Internet à des invités, avec 0 accès au LAN.
Vos développeurs ne sont pas des invités, non ?
Ils font parties de la boite, ils doivent être sur le domaine donc ils doivent accéder au DC !
 
Il faut les placer sur le LAN et si tu ne veux pas qu'ils accèdent aux postes des autres services, tu les places sur un Vlan propre.

Je parle des ACL au niveau OS. Par défaut n'importe qui n'accède pas à un DC par exemple.

 
Oui enfin si le dev il récupère le MDP admin du domaine, ca te fait une belle jambe qu'il n'accède pas en TSE au DC alors qu'il a accès au LDAP ou au partage de fichiers.
Tu lui fermes un fenêtre alors que la porte d'entrée est grande ouverte pour qu'il puisse mettre le feu à la baraque.
 
Et puis pourquoi se méfier du dev alors que l'autre employé lui a accès à tout ?
Perso, j'ai du mal à comprendre la logique de sécurité qui est avancée.

Merci pour les réponses.  
 
Alors pourquoi cette sécurité.
Je vais tenter de vous retranscrire ce qui mets imposer par la politique de sécurité de la boite.  
Les devs ont un réseau réservé au développement, accès a des serveurs bref, leur réseaux est cloisonné a 100%.
Les développeurs ont besoins d'Internet, et ne pouvant pas l'avoir dans leur réseau. Ils l'auront depuis un réseau a part (la zone bleu) appelé "Postes Libre Service".
La zone verte est pour le service Support, ce service à accès a Internet, on le serveur AD, et des serveurs autres contenant des informations confidentielles. Autrement dit les Dev doivent avoir seulement accès au serveur AD.
La zone orange est pour les "invités de l'entreprise". La zone est déjà effective et ne pose pas de problème.
 
Pour récapituler, les dev qui viennent sur le réseau bleu, doivent s'authentifier sur le serveur AD, faire leur recherche sur internet et c'est tout.  
Voila si vous avez des questions, ou si vous avez mal compris une truc, pas de soucis je réexplique.
 
Bon coté test, j'arrive a joindre le serveur depuis la zone Bleu, maintenant j'ai ça:
Le serveur RPC n'est pas disponible.
 
Je dois donc ouvrir le/les port(s) RPC. Ceux ci étant a priori dynamiques, comment faire ?
 
Merci encore une fois de participé et d’apporté votre aide.
 

C'est donc un VLAN qu'il te faut.
Si tu restes sur le principe de routage entre deux réseaux physiquement séparés (est-ce au moins le cas ?) alors j'en reviens à mon 1er post : tu autorises tout bleu vers l'IP du DC en vert. Niveau sécu, ca ne fait aucune différence !
Et si, sans raisons techniques, l'accès au RDP, plus qu'aux autres services, te file des boutons, réjouis toi, c'est le seul dont tu peux :
- arrêter le service sans que cela influe sur le fonctionnement du domaine
- changer le port par défaut
- limiter à l'écoute sur le seul réseau vert.

Sinon, rien à voir, il est peut-être dommage d'avoir inversé l'orange, voulu comme DMZ et le bleu, voulu comme LAN "bis" pour des invités car à l'avenir, pas de proxy possible sur l'orange. Pas intégré à Ipcop en tous cas. D'ailleurs à moins que cela ait changé ou qu'un addon fasse le job, pas de serveur DHCP sur Orange non plus.

Ah ben c'est sur que si tu lui autorises le partage de fichier vers les serveurs de fichiers ... Maintenant imagine qu'il n'a accès QUE au LDAP pour pouvoir se logger ... Ce que demande l'auteur ... Avec un passe admin, si il a cloisonné, ça lui fera une belle jambe d'avoir le mot de passe admin puisqu'il n'aura accès à rien niveau réseau.  
 
Il pourra toujours faire du mal, mais cette fois ci il faudra qu'il soit connecté physiquement sur le LAN, et là on entre dans la sécurité physique du batiment avec badges d'accès etc ...
 
Cela te semble dur à comprendre, et j'avoue que ce system n'est au premier regard pas productif, mais il n'est absolument pas farfelus.

Sans partage de fichiers, l'accès aux GPO va être de suite plus difficile ...
Ensuite avec un accès au port 389 d'un DC, tu peux t'authentifier dessus comme admin du domaine et modifier ce que tu veux dans AD.
 
Alors je le répète, y'a 0 sécu supplémentaire (dans le cas présent) à n'autoriser que certains ports et pas d'autres. Surtout lorsque les ports en question permettent l'accès à AD ...
 
Donc soit les users accèdent au DC en totalité, soit ils n'y accèdent pas du tout et on trouve d'autres solutions (autre domaine avec relation d'approbation, AD LDS, que sais-je d'autre encore).