Firewall et AD

Fabrice a écrit :

Bonsoir à tous

Bonsoir,

Je cherche à établir les regles dénéssaires sur un fierwall (kerio) afin
d'établir les accès nécésssaires pour que le poste d'un réseau local puisse
se connecter à AD et bénéficier des services sans réduire sa sécurité.

Tout dépend comment est configuré ton domain, derrière le terme AD, on
met souvent pas mal de chose et il y a en fait souvent pas mal de chose
et en général on parle s'AD pour AD/DC/DNS...
Voici une liste de flux possibles (entre le client et l'AD)
- DNS, tcp et udp 53 (résolution de nom et de services)
- kerberos, tcp et udp 88 (ticket d'authentification)
- LDAP, tcp 389 (aussi possible en UDP)
- global catalog (GC), tcp 3268 (gestion des groupes de user entre autre)
- MS-RPC, tcp et udp 135 (la source d'embêtement... vu que'on peut avoir
ensuite des ports dynamiques),
- NTDS qui est un port dynamique en général tcp 1026 (parfois 1025), on
peut le fixer, cf :
http://support.microsoft.com/default.aspx?scid=kb;en-us;280132&sd=tech
Si on est on mode full SSL, on doit passer au version SSL pour certains
protocoles :
- LDAP su SSL, tcp 636
- Global Catalog sur SSL, tcp 3269
Pour les partage (fichiers, imprimantes politique) :
- SMB, tcp 445
Pour la synchronisation horaire :
- NTP, udp 123 (parfois)
Ensuite si on est mode compatibilité NT4/98...on peut avoir besoin de :
- Netbios sur IP, tcp 139, udp 137 et 138
- réplication WINS, tcp 42 (si il y a un autre serveur WINS)

Il faut bien sûr autorisé les flux retour (si je ne me trompe, kerio est
statefull, donc c'est automatique). En cas d'utilisation d'autres
services, il y aura des ports dynamiques qu'il serait préférable de
fixer, sinon il vaut mieux restreindre les valeurs possibles :
http://support.microsoft.com/default.aspx?scid=kb;EN-US;154596


Normalement, il suffit de regarder ce qui est bloqué et logué et
d'ouvrir en fonction de la liste ci-dessus.

Merci de votre aide.
fabrice

--
Julien

- NTP, udp 123 (parfois)

Non pas parfois.
Toujours et necessaire des que profils itinérants
Bien la contribution, connaisseur, c'est agréable
de lire.
Si je peux me permettre un tout petit plus si IP/Sec
dans le coup voir les ports dans le coup.

--
Cordialement
GG.

"Julien Salgado" <Julien.Salgado@f_r_e_e_f_r.ignore.invalid> wrote in
message news:slrncebd79.9q8.Julien.Salgado@io.cdr.fluxus.net...

Normalement, il suffit de regarder ce qui est bloqué et logué et
d'ouvrir en fonction de la liste ci-dessus.

Microsoft conseille aussi d'établir un lienVPN L2TP car certains protocoles
nécessitent d'ouvrir une grande variété de ports. C'est le cas Exchange,
donc autant faire un VPN tout de suite.

C'est le
cas Exchange, donc autant faire un VPN tout de suite.

Pas exagérer, avec Outlook Web Access et Exchange
il ne sufit que d'ouvrir le 80 et le port SSL 443, ce n'est
pas une enorme quantité de port cela. :-)
--
Cordialement
GG.

"Jerome T" <jerome_th@yahoo.com> wrote in message
news:40e5c6fa$0$24420$636a15ce@news.free.fr...

"Julien Salgado" <Julien.Salgado@f_r_e_e_f_r.ignore.invalid> wrote in
message news:slrncebd79.9q8.Julien.Salgado@io.cdr.fluxus.net...

Normalement, il suffit de regarder ce qui est bloqué et logué et
d'ouvrir en fonction de la liste ci-dessus.

Microsoft conseille aussi d'établir un lienVPN L2TP car certains
protocoles
nécessitent d'ouvrir une grande variété de ports. C'est le cas Exchange,
donc autant faire un VPN tout de suite.

Concernant RPC, je vous recommande la lecture de cette fiche :
http://support.microsoft.com/?id4596

Cordialement

--
Thierry MILLE
www.lab-os.com

Thierry MILLE écrivait (wrote) :

Concernant RPC, je vous recommande la lecture de cette fiche :
http://support.microsoft.com/?id4596

Plutôt que de modifier la base de registres directement, il est plus
aisé d'utiliser rpccfg, cf :

http://www.hsc.fr/ressources/breves/min_srv_res_win.html.fr

S'il n'y a qu'une seule chose à faire sur un Windows par défaut, c'est
bien cela (changer l'intervalle de ports utilisés par les services RPC
sur TCP/IP), avant même d'arrêter des services réseaux...

Jean-Baptiste Marchand
--
jbm@glou.net
Real Unix Books are written with Troff
(W. Richard Stevens)

GG a écrit :

- NTP, udp 123 (parfois)

Non pas parfois.
Toujours et necessaire des que profils itinérants

Disons, qu'il n'est pas forcément nécessaire que NTP soit sur l'AD, et
pas forcément nécessaire d'en avoir un. Par contre, il faut que les
machines soient synchronisées pour avoir une chance de recouvrement pour
les validités de tickets kerberos (ce qui est un prérequis pour les
profils itinérants), donc l'utilisation de NTP est fortement
recommandée. Donc, tu as raison, il vaut mieux dire toujours.

Bien la contribution, connaisseur, c'est agréable
de lire.

Malheureusement (ou heureusement), je ne suis pas un connaisseur,
j'essaye juste de comprendre, mais merci pour le compliment.

Si je peux me permettre un tout petit plus si IP/Sec
dans le coup voir les ports dans le coup.

<mode type="je crie un peu">
Si IPSEC est dans le coup... déjà dans beaucoup de cas ça n'apporte pas
plus de sécurité car, on fait passer des flux inconnus à travers le
firewall. En résumé, c'est pas par ce qu'on met en place de l'IPSEC sur
un réseau windows qu'on a un réseau IP plus sécurisé.

C'est par ce qu'on ne sait pas faire un schéma de flux ou qu'on ne sait
pas configurer ses applications pour ne pas ouvrir des ports dynamiques
dans tous les sens, qu'il faut faire un VPN/IPSEC. En plus, dans la
plupart des cas cela veut dire que le firewall ne sert plus quasiment à
rien (oui je sais j'exagère un peu).
</>

IPSEC est surtout interessant si le réseau entre la machine client (de
l'AD) et l'AD n'est pas sûr. Sur un réseau local sur lequel, la même
entité gère le réseau et les machines on diminue en fait la sécurité
puisque le filtrage est effectuée par les machines à protéger plutôt que
sur un équipement tiers de technologie différente éventuellement. Donc
dans ce cas IPSEC ne fait juste qu'apporter une baisse de performance.
La plupart du temps il est plus raisonable de se rabattre sur les
versions SSL pour le transport.

Ceci étant dit... si on fait du VPN (je généralise car le terme IPSEC
est mis à pas mal de sauce un peu partout), c'est-à-dire un réseau privé
virtuel, tout dépend comment le VPN est fait et ou se trouve le
firewall. Les flux firewall permettent d'encapsuler la plupart des
protocoles, mais il se peut que certains ne soient pas encapsulés (tout
dépend de la topologie), c'est par exemple souvent le cas pour le DNS
qui peut être nécessaire dans les premières phases de communication.

Pour faire simple, il y a deux type de VPN :
- PPTP qui est une encapsulation GRE négociée en TCP, il y a donc un
flux en TCP (port 1723) du client vers le serveur VPN, et ensuite
il y a une communication GRE (protocole IP 47) entre les deux,
- IPSEC, dans ce cas il y a l'établissement d'un lien de confiance
(sécurité association, SA) en IKE (UDP 500). Ensuite, il y a
communication suivant trois différents modes possibles :
. ESP (protocole IP 50)
. ESP et AH pour l'authentification (protocole IP 51), plus rare
. Encapsulation UDP sur le port 500 (ce qui permet la NAT transversale)
Suivant les versions de windows en jeu, on peut avoir l'une ou
plusieurs des possibilités.
En plus, de cela on pour faire de l'encapsulation de niveau 2 (L2TP) qui
est négociée en IKE (UDP 500) et le transport en UDP (port 1701).

Bien sûr, dans les situations complexes on a un joyeux mélange, c'est le
cas dans les mises en place de serveurs VPN qui font du L2TP d'un côté
et de l'IPSEC de l'autre.




--
Julien

"Julien Salgado" <Julien.Salgado@f_r_e_e_f_r.ignore.invalid> wrote in
message news:slrncelo6e.9q8.Julien.Salgado@io.cdr.fluxus.net

<mode type="je crie un peu">
Si IPSEC est dans le coup... déjà dans beaucoup de cas ça n'apporte pas
plus de sécurité car, on fait passer des flux inconnus à travers le
firewall. En résumé, c'est pas par ce qu'on met en place de l'IPSEC sur
un réseau windows qu'on a un réseau IP plus sécurisé.

C'est par ce qu'on ne sait pas faire un schéma de flux ou qu'on ne sait
pas configurer ses applications pour ne pas ouvrir des ports dynamiques
dans tous les sens, qu'il faut faire un VPN/IPSEC. En plus, dans la
plupart des cas cela veut dire que le firewall ne sert plus quasiment à
rien (oui je sais j'exagère un peu).
</>

Pour ma part, je filtre simplement en sortie du tunnel, et hop !

Pour faire simple, il y a deux type de VPN :
- PPTP qui est une encapsulation GRE négociée en TCP, il y a donc un
flux en TCP (port 1723) du client vers le serveur VPN, et ensuite
il y a une communication GRE (protocole IP 47) entre les deux,

<troll>
C'est moyen VPN non ? pasque l'aspect privé et sécurisé dans PPTP il
est un poil réduit.
Je préfère parler de tunnel que de VPN, qui comme tu le disais, est un
terme trop souvent employé pour désigner un peu tout ce qui permet
de faire de l'encapsulation (et le T de PPTP est bien pour tunneling)
Sus aux VPNs à tout va !! :-)
</troll>





--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Malheureusement (ou heureusement), je ne suis pas un connaisseur,
j'essaye juste de comprendre, mais merci pour le compliment.

De rien.
C'est bien la compréhension semble bonne, alors

Si IPSEC est dans le coup... déjà dans beaucoup de cas ça n'apporte
pas plus de sécurité car, on fait passer des flux inconnus à travers
le firewall. En résumé, c'est pas par ce qu'on met en place de
l'IPSEC sur un réseau windows qu'on a un réseau IP plus sécurisé.

Non pas avec ISA server mais bon c'est encore du Firewall MS et
donc de l'argent a dépenser, alors qu'effectivement avec iptables
et un squid pas possible. ;-)

dans la plupart des cas cela veut dire que le firewall ne sert
plus quasiment à rien (oui je sais j'exagère un peu).

allez repub ;-) pas avec ISA Server qui travaille bien sur ce
point surtout quand il est configuré en mode Entreprise et
qu'il s'integre à AD. :-)

Donc dans ce cas IPSEC ne fait juste qu'apporter une baisse de
performance.

Certains mais pour l'exterieur on peut le coupler au radius intergré
encore un fois dans l'offre MS (IAS) et dans ces conditions c'est
presque parfait, mais il faut se marier definitivement avec MS et
ca c'est vrai cela peut rebuter, tout les oeufs dans le même panier.
:-)

c'est par exemple souvent le cas pour
le DNS qui peut être nécessaire dans les premières phases de
communication.

Il faut implementer un DNS racine sous AD dans l'entreprise et un
secondaire pour les sorties sur Internet comme cela plus de crainte
de ce coté.

- PPTP qui est une encapsulation GRE négociée en TCP, il y a donc un
flux en TCP (port 1723) du client vers le serveur VPN, et ensuite
il y a une communication GRE (protocole IP 47) entre les deux,

Pas super extra mais pratique et suffisant dans beaucoup de cas
simple.

- IPSEC, dans ce cas il y a l'établissement d'un lien de confiance
(sécurité association, SA) en IKE (UDP 500). Ensuite, il y a
communication suivant trois différents modes possibles :
. ESP (protocole IP 50)
. ESP et AH pour l'authentification (protocole IP 51), plus rare
. Encapsulation UDP sur le port 500 (ce qui permet la NAT
transversale) Suivant les versions de windows en jeu, on peut avoir
l'une ou plusieurs des possibilités.
En plus, de cela on pour faire de l'encapsulation de niveau 2 (L2TP)
qui est négociée en IKE (UDP 500) et le transport en UDP (port 1701).

Associé au radius IAS c'est parfait de chez parfait, c'est ce que je fais
quand il y a du wifi qui traine, ca était bien décrit durant les journées
sécurité organiser par MS , mais c'est du full MS on aime ou on n'aime
pas.
--
Cordialement
GG.

GG a écrit :

Malheureusement (ou heureusement), je ne suis pas un connaisseur,
j'essaye juste de comprendre, mais merci pour le compliment.

De rien.
C'est bien la compréhension semble bonne, alors

Si IPSEC est dans le coup... déjà dans beaucoup de cas ça n'apporte
pas plus de sécurité car, on fait passer des flux inconnus à travers
le firewall. En résumé, c'est pas par ce qu'on met en place de
l'IPSEC sur un réseau windows qu'on a un réseau IP plus sécurisé.

Non pas avec ISA server mais bon c'est encore du Firewall MS et
donc de l'argent a dépenser, alors qu'effectivement avec iptables
et un squid pas possible. ;-)

Oui, sauf que dans ce mode là ISA server est en mandataire... donc
déchiffre et désencapsule les trames. Si on place un firewall digne de
ce nom dans la même situation il est aussi capable de faire de l'analyse
de niveau 7. Je parlais plus particulièrement du cas d'un LAN. Dans le
cas d'un WAN, avoir un équipement qui fini le tunnel et qui filtre ce
n'est pas vraiment exceptionnel.

dans la plupart des cas cela veut dire que le firewall ne sert
plus quasiment à rien (oui je sais j'exagère un peu).

allez repub ;-) pas avec ISA Server qui travaille bien sur ce
point surtout quand il est configuré en mode Entreprise et
qu'il s'integre à AD. :-)

Je me plaçais dans le cas d'un firewall qui ne déchiffrait pas les flux
et donc ne voit passer qu'un truc incompréhensible. ISA server aurait
autant de mal à faire l'analyse dans la même situation.

Donc dans ce cas IPSEC ne fait juste qu'apporter une baisse de
performance.

Certains mais pour l'exterieur on peut le coupler au radius intergré
encore un fois dans l'offre MS (IAS) et dans ces conditions c'est
presque parfait, mais il faut se marier definitivement avec MS et
ca c'est vrai cela peut rebuter, tout les oeufs dans le même panier.
:-)

Toujours d'accord dans le cas d'un WAN sur le principe, par contre il y
a pas mal d'autre solution qu'on peut coupler avec un RADIUS ou un autre
type d'authentification/autorisation...
Et comme tu le dis on place ses oeufs dans le même panier car les
couches réseau et applicative viennent de la même base et sont donc
suceptibles d'avoir une faille en même temps. La brisure technologique
à ses avantages en terme de sécurité même si elle apporte indubitablement
une hétérogénéïté en terme d'administration et de gestion.

c'est par exemple souvent le cas pour
le DNS qui peut être nécessaire dans les premières phases de
communication.

Il faut implementer un DNS racine sous AD dans l'entreprise et un
secondaire pour les sorties sur Internet comme cela plus de crainte
de ce coté.

Là, il faut être patient et courageux de pas vouloir faire gérer la
hiéarchie locale par autre chose que le DNS local qui n'est pas
forcément sur l'AD d'ailleurs (IPSEC ou non). Par contre, pour trouver
l'AD on a besoin du DNS et donc on peut se mettre facilement dans des
situations type de l'oeuf et de la poule, si on ne fait pas attention.

- PPTP qui est une encapsulation GRE négociée en TCP, il y a donc un
flux en TCP (port 1723) du client vers le serveur VPN, et ensuite
il y a une communication GRE (protocole IP 47) entre les deux,

Pas super extra mais pratique et suffisant dans beaucoup de cas
simple.

En autre, dans les trucs pas sympa, on ne peut pas facilement faire de la
NAT globale (masquerading) par contre la NAT statique est possible.

- IPSEC, dans ce cas il y a l'établissement d'un lien de confiance
(sécurité association, SA) en IKE (UDP 500). Ensuite, il y a
communication suivant trois différents modes possibles :
. ESP (protocole IP 50)
. ESP et AH pour l'authentification (protocole IP 51), plus rare
. Encapsulation UDP sur le port 500 (ce qui permet la NAT
transversale) Suivant les versions de windows en jeu, on peut avoir
l'une ou plusieurs des possibilités.
En plus, de cela on pour faire de l'encapsulation de niveau 2 (L2TP)
qui est négociée en IKE (UDP 500) et le transport en UDP (port 1701).

Associé au radius IAS c'est parfait de chez parfait, c'est ce que je fais
quand il y a du wifi qui traine, ca était bien décrit durant les journées
sécurité organiser par MS , mais c'est du full MS on aime ou on n'aime
pas.

C'est vrai, que encapusler directement le niveau 2 du 802.11b, c'est
plus chouette que de faire l'encapuslation au niveau 3.


--
Julien