20/05/2005
Firewall=composant de la sécurité Definition : methodologie dont l'objectif est de protéger le réseau de l'extérieur via 2 Types de firewall :
ISA intègre par défaut les authentifications Windows Caractéristiques:
Définition : quelqu'un qui va faire quelque chose pour quelqu'un d'autre Caractéristiques :
2 types :
Caractéristiques :
3 types de client ISA
DMZ ou perimeter network = zone sécurisée pour publier des services de l'interieur vers l'extérieur → three perimeter port:
→ Back to back perimeter network : 2 firewalls (page 22)
Chaque règle est basée sur 3 choses:
IP de la DMZ est soit privée (doit avoir un firewall NAT) soit publique (firewall transparent).
23/05/2005
On ne met jamais un serveur de mail qui stocke des mails dans une DMZ (sinon on baisse la sécurité).
Comment calibrer une DMZ?
http://callendor.zongo.be/wiki/images/ex_fw.png
DG = default gateway
#|
private | internet | remarque | ||
192.168.0.0/24 any any | 0.0.0.0 any any | tout le trafic sortant est autorisé | ||
DMZ | Internet | remarque | ||
192.168.0.10/32 TCP 25 | any TCP 25 | envoyer les emails vers l'extérieur | ||
192.168.0.11/32 DNS | any TCP DNS | DNS peut interroger les DNS publics pour la résolution de noms | ||
Internet | DMZ | remarque | ||
any TCP any | 164.15.59.210 TCP 25 | recevoir les emails de l'extérieur | ||
any UDP any | 164.15.59.211 TCP-UDP DNS | autoriser l'interrogation du DNS depuis l'extérieur | ||
DMZ | private | remarque | ||
192.168.1.10/32 TCP 25 | 192.168.0.11/32 TCP 25 | relais SMTP vers exchange | ||
private | DMZ | remarque | ||
192.168.1.11/32 DNS | any TCP DNS | exchange peut contacter SMTP relay dans DMZ | ||
Problème: on est open DNS: pour changer ça, refuser les recursives queries et DNS ne peut pas sortir de lui-même (initier). Pour la résolution DNS du SMTP relay (pour pouvoir envoyer les mails), il doit interroger le DNS dans la zone privée (ou bien ajouter un autre DNS server dans la DMZ juste pour ça.
Open DNS: consomme BP et process → peut réduire la disponibilité → c'est un problème de sécurité.
Même schéma, on remplace le serveur DNS par un serveur web (HTTP) dans la DMZ. Ce serveur web doit accéder à une base de données. Où va-t-on la placer?
2 types de DB:
2 endroits:
Si accès fichier en private: on fait un share
Pas très efficace → Si flat file, on le met en DMZ.
Si accès DB → Single sign on → authentification Windows.
Avec la DB dans la DMZ, on met une copie dans la private et une copie dans la DMZ (accédée par le serveur web).
Exemples:
DB dans private (mise à jour par user) et DB dans DMZ (mise à jour pas webserver)
Parfois: 2 DMZ:
Exchange avec webmail.
Exchange en private Webserver + Exchange (sans mailboxes) dans DMZ Authentification → accès à Exchange en privé (avec données = mailboxes)
On choisit donc l'architecture en fonction des besoins et des contraintes. “Il n'y a pas une bonne solution.”
MS Sharepoint portal server (basé sur SQL server): CMS avec partage de documents. Si met SQL server dans privé, problème avec firewall (parce que plusieurs connexions en même temps) → parfois on laisse la DB sur le serveur portail: pas top point de vue sécurité, mais difficile de faire autrement.
On a oublié les mises à jour du serveur web (gestion serveur):
Gestion outbound: modem Gestion inbound: réseau
On va autoriser depuis quelques IP de machines internes l'accès au serveur.
Ajouter dans le DNS interne un record www vers le serveur web (sinon il n'y arrive jamais, puisque c'est test.be des 2 côtés).
Installer::
Il faut créer un nouveau domaine hors de la forêt:
3 modes (choix une fois pour toutes):
D'abord installer Windows 2000, patcher, puis installer ISA. Extension du schema → irréversible
RAS remplacé par son propre service NAT remplaceé par son propre service stack IP remplacé par stack propre à ISA
Si IIS sur ISA, faire très attention parce qu'ISA utilise certains ports à usage du proxy (8080: admin IIS et proxy ISA) Attention: définir “l'intérieur” et “l'extérieur”: dans la local area table (que réseau privé, pas DMZ), pas toujours se fier à l'automatique.
ISA services:
Install:
cocher IIS
Remove Windows Component → Network → DNS
<code>dcpromo</code> * new domain, tree, forest
Je me suis trompé: 10.10.5.1, c'est l'adresse IP pour le DC (sur l'interface USB), puisque le firewall doit
être sur un autre réseau (10.10.3.1, puisque le gateway de la salle,c'est 10.10.3.250). Donc, c'est auprès de 10.10.5.1 qu'on doit s'enregistrer comme DNS.
My Network places → click droit → properties → choisir le réseau pour la carte USB (le
2e) → clic droit → propriétés → ~TCP/IP → propriétés
Installer ISA:
Il y a une workstation qu'il faut faire rentrer dans domain1.be avec l'IP 10.10.5.11 qui s'appelle ws11. La brancher sur le switch avec le serveur ISA. Enregistrer la machine dans le domaine. Il y avait une erreur, la machine s'appellait ws31 et il y en avait une autre qui s'appellait comme ça sur le même switch. J'ai dû la sortir du domaine (workgroup), rebooter, la renommer, la remettre dans le domaine, rebooter.
Patches pour ISA: aller chez MS, récupérer le dernier service pack et l'installer, plus
patches après.
Sur l'interface externe, décocher “Client for MS networks” dans Internet Properties et aussi
diable Netbios over ~TCP/IP
Gestion: Start → Programs → Microsoft ISA server → ISA Management View → Advanced Internet Security and Acceleration Server → servers and arrays → ISA1 → computer → ISA1
(dans l'autre fenêtre) → clic droit → secure… → choisir “Secure” system security level Reboot Vérifier
Il y a des feature packs qui ajoutent des règles de filtrage.
Il existe un client pour NT: \\ISA1\mspclnt
On n'installe jamais le client firewall sur un serveur ISA.
Le client une fois installé essaie de trouver le serveur ISA.
Quand on a installé le client sur une workstation, lorsqu'on clique sur MSIE, il installe
pour l'utilisateur (uniquement) les paramètres proxies. Pour tous les autres utilisateurs, s'ils doivent aussi utiliser le proxy, soit détection
dans les settings MSIE (auto-discovery), soit GPO.
Auto-discovery: ISA: ISA1 → click droit → properties → tab auto-discovery → cocher Configurer dans serveur DHCP: WPAD: se trouve à l'URL: http://isa1.domain1.be:80/wpad.dat
Local Domain Table: domaines internes (pour lesquels il ne faut pas sortir).
Backup de la config: ISA1 → clic droit → Backup… et restore quand ça s'impose.
ACLs Windows intégrés dans ISA: On peut donc le cas échéant attribuer la configuration d'une partie d'ISA à une personne spécifique. Cependant, en règle générale, la gestion d'ISA est confiée à une personne ou une équipe.
Gestion des alertes: ISA1 → Monitoring Configuration → Alerts On peut choisir d'être averti pas log (event viewer), email, SMS, etc.
Logs: ISA1 → Monitoring Configuration → Logs On peut les envoyer dans une DB. A conserver (seule preuve d'attaque, de tentative d'intrusion, etc.).
Rapports: ISA1 → Monitoring Configuration → Report Jobs cf. slides 81-82.
3 types d'access policies pour les accès sortants:
1. site & content 2. protocol rules 3. IP packet filtering
Pour que 1 et 2 fonctionnent, il faut une intersection entre les règles. Par défaut, dans 1 tout est autorisé, rien dans 2. Si on rajoute une règle (dans 2) “HTTP only” qui autorise le HTTP uniquement: ISA1 → Access Policy → Protocol Rules → clic droit → New → rule → allow → selected protocols → http
N.B: sur le browser de la machine cliente, ajouter un proxy (adresse = serveur ISA, port: 8080).
Pour packet filtering (3), il bypass 1 et 2. slide 88 et 110.
Une règles désactivée != règle deny
Règle deny > règle allow
Si une règle dit: en sortie, tout est permis 2e règle dit: si POP3, deny → si qqn veut faire accès POP, il est refusé
Dans un firewall traditionnel: dès qu'il trouve une règle qui matche, il applique → l'ordre des règles importe
24/05/2005
Avantages du client firewall par rapport au secure nat (NAT qui est installé d'office avec ISA server): on peut sortir en smtp parce que les socks sont gérés différemment.
Authentification: Il faut que pour 1 et pour 2, aucune règle ne peut être anonyme → basé sur groupes Windows. Si on veut sortir avec MSIE en bypassant le proxy, pas possible. Comme client du proxy, possible après authentification.
Tous les firewalls sont basés sur des objets. Ex: heures de travail:
Définir:
Client address set: ensemble d'IP à un nom
Dans l'outbound access, on n'utilise pas les IP Packet filters. Uniquement avec Site & Content Rules et Protocol Rules. Parfois pas possible (ICMP), alors on l'utilise.
Policy Elements → Protocol Definitions: on y définit les protocoles pour Access Policy → Protocol Rules
Des bonnes règles dans un firewall sont pré-établies: je veux arriver à tel résultat, je planifie les Protocol Definitions et puis je les utilise dans Protocol Rules + Site & Content Rules.
Créer des groupes (policy element), y mettre les utilisateurs ou d'IP dedans et puis faire deny everything sauf HTTP.
Pour définir des règles liées à des groups Windows (définis dans l'Active Directory): Site & Content Rules → rule → clic droit → properties → onglet applies to → Users and groups specified below → add
Pour éviter de télécharger des types de fichiers (défini selon l'extension et en HTTP uniquement), on peut définir ce qui est autorisé ou non: Policy Elements → Content Groups pour la définition Site and Content Rules → règle → Properties → onglet HTTP content
Cache configuration: config cache.
On utilise le packet filtering. Par défaut, elle est activée, mais pas la détection d'intrusion: ISA1 → Access Policy → IP Packet Filter → clic droit → Properties → tab General
“Enable IP routing”: c'est pour que les protocoles de bases couches ISO (ex: ICMP) puissent passer.
Quand on a activé la détection d'intrusion, on peut la configurer (définir ce qu'il faut surveiller): ISA1 → Access Policy → IP Packet Filter → clic droit → Properties → tab Intrusion Detection
Il faut donc aller activer la surveillance de toutes les tentatives d'intrusion → cf. log policies (section Monitoring ci-dessus) pour voir ce qu'il faut faire.
On peut également rajouter des filtres avec un wizard. ISA1 → Access Policy → IP Packet Filter → clic droit → new → filter
Ports dynamiques (> 1024): utilisé après initialisation de la connection. Se retrouve dans les connexions interieur → extérieur: on ne doit pas utiliser les packet filters pour ça. Peut se retrouver entre intérieur (private) et DMZ (ex: pour un backup sharepoint si on n'a pas fixé les ports).
Applications filters: ISA scanne le trafic. Quand il trouve quelque chose qui correspond à l'application et la règle définie, il exécute la règle. Ex: refuser les emails de hotmail.com, jeter les emails avec un attachement .exe Il existe des API pour les développeurs pour créer de nouveaux filtres applicatifs, mais au niveau utilisateur on ne peut pas rajouter de filtres.
N.B: quand on redémarre les services ISA, toutes les connexions internet sont coupées.
Accès aux serveurs internes via DMZ.
Parfois, pas utiliser packet filter, mais du publishing, une technique propre à MS. Exemple: accéder à un web server en interne depuis l'extérieur ISA1 → Access Policy → Publishing → Web Publishing Rules → clic droit → new → rule
ISA1 → Access Policy → Publishing → Server Publishing Rules → clic droit → secure mail server: on définit un serveur mail externe et on le mappe avec une IP interne
ISA1 → Access Policy → Publishing → Server Publishing Rules → clic droit → new → rule On peut choisir un tas de scénario (DNS, HTTP)
Avantage du publishing par rapport au mapping: mapping ne contrôle pas la connexion. Exemple: si publie serveur mail: autorise pas telnet sur port 25.
NAT = prendre un socket et le transformer en un autre socket.
Par défaut, ISA n'écoute pas: il s'en fout de ce qui vient de l'extérieur. ISA1 → clic droit → properties → tab Incoming Web Requests Une fois publié quelque chose qui doit être accessible de l'extérieur, il faut rajouter un listener.
Requête en HTTPS de l'extérieur → ISA → web serveur en SSL avec certificat Il faut ramener le certificat du web serveur sur le serveur ISA. Une fois que le browser client de l'extérieur a accepté le certificat, ISA laisse passer la connexion jusqu'au web server, mais en HTTP. Avantage: le firewall peut contrôler ce qui passe dans les requêtes HTTP et il peut éventuellement filter.
Reverse proxying utilisé pour sécurisation de serveurs dans DMZ.
Pourquoi avoir 2 ISPs?
PPTP ou IPSEC à travers un proxy ne marche pas (c'est le proxy qui va chercher pour moi). On peut avoir des tunnels entrants PPTP avec ISA
ISA1 → Access Policy → IP Packet Filter → clic droit → new → filter → allow packet transmission → predefined filter → PPTP call
SSL juste en-dessous de couche 5. SSL ne fournit que l'encryption, pas l'authentification (parce qu'on se trimbale pas avec son certificat, sinon c'est plus clientless)
IPSEC fait l'authentification, il n'est pas sensible au man-in-the-middle et à l'IP spoofing, ce qui n'est pas le cas avec SSL (puisqu'il est au-dessus de ~TCP/IP).