Firewalls Internet: Foire aux questions – Serveur d’impression

Firewalls Internet: Foire aux questions Date: 2004/07/26 15:34:42 Révision: 10.4 Ce document disponible en Postscript.et PDF.

1.1 À propos de la FAQ

Cette collection de questions fréquemment posées (FAQ) et de réponses a été compilé sur une période de plusieurs années, en voyant quelles questions les gens poser des questions sur les pare-feu dans des forums tels que Usenet, des listes de diffusion et Web des sites. Si vous avez une question, regardez ici pour voir si c'est répondu avant de poster votre question est bonne forme. Ne pas envoyer votre questions sur les pare-feu aux responsables de la FAQ. Les responsables maintiennent les commentaires et les contributions sur le contenu de cette FAQ. Les commentaires relatifs à la FAQ doivent être adressés à firewalls-faq@interhack.net. Avant de nous envoyer du courrier, assurez-vous de bien consulter les sections 1.2 et 1.3 pour s'assurer que c'est le bon document à lire.

1.2 Pour qui la FAQ est-elle écrite?

Les pare-feu ont parcouru un long chemin depuis le début de cette FAQ. Ils sont passés de systèmes hautement personnalisés administrés par leurs implémenteurs à un produit grand public. Les pare-feu ne sont plus uniquement entre les mains de ceux qui conçoivent et mettent en œuvre la sécurité systèmes; même les utilisateurs finaux soucieux de la sécurité les ont chez eux. Nous avons écrit cette FAQ pour les développeurs et les administrateurs de systèmes informatiques. Nous avons essayé d’être assez inclusifs, en laissant de la place aux nouveaux venus, mais nous supposons toujours des connaissances techniques de base. Si vous trouvez ça vous ne comprenez pas ce document, mais pensez que vous devez savoir Pour en savoir plus sur les pare-feu, il se peut que vous ayez réellement besoin de plus de fond dans les réseaux informatiques d'abord. Nous fournissons des références qui nous ont aidés; peut-être qu'ils vont aussi vous aider. Nous nous concentrons principalement sur les pare-feu "réseau", mais sur les pare-feu "hôtes" ou "personnels"  seront abordés le cas échéant.

1.3 Avant d'envoyer un courrier

Notez que cette collection de questions fréquemment posées est le résultat de interagir avec beaucoup de gens de différents horizons dans un large variété de forums publics. L'adresse firewalls-faq n'est pas une aide   bureau. Si vous essayez d'utiliser une application qui dit que c'est ne fonctionne pas à cause d'un pare-feu et vous pensez que vous devez supprimez votre pare-feu, veuillez ne pas nous envoyer de courrier demandant comment. Si vous voulez savoir comment vous "débarrasser de votre pare-feu" parce que vous ne pouvez pas utiliser certaines applications, ne nous envoyez pas de courrier demandant de l'aide. nous je ne peux pas t'aider. Vraiment. Qui peut vous aider? Bonne question. Cela dépendra de quoi exactement le problème est, mais voici plusieurs indications. Si aucun de ces fonctionne, veuillez ne plus nous en demander. Nous ne savons pas

Le fournisseur du logiciel que vous utilisez.

Le fournisseur de l'appliance matérielle que vous utilisez.

Le fournisseur du service réseau que vous utilisez. C'est, si   vous êtes sur AOL, demandez-leur. Si vous essayez d'utiliser quelque chose sur un   réseau d'entreprise, consultez votre administrateur système.

1.4 Où puis-je trouver la version actuelle de la FAQ?

La FAQ peut être trouvée sur le Web à Il est également posté mensuellement à Les versions publiées sont archivées à tous les endroits habituels. Malheureusement, la version publiée sur Usenet et archivée à partir de cette version n’a pas la jolies images et hyperliens utiles trouvés dans la version Web.

1.5 Où puis-je trouver des versions non anglaises de la FAQ?

Plusieurs traductions sont disponibles. (Si vous avez fait une traduction et ce n'est pas dans la liste, écrivez-nous pour que nous puissions mettre à jour le maître document.)

norvégien Traduction de Jon Haugsand http://helmersol.nr.no/haandbok/doc/brannmur/brannmur-faq.html

1.6 Contributeurs

Beaucoup de gens ont écrit des suggestions utiles et des commentaires réfléchis. Nous sommes reconnaissants à tous les contributeurs. Nous aimerions remercier quelques-uns par leur nom: Keinanen Vesa, Allen Leibowitz, Brent Chapman, Brian Boyle, D. Clyde Williamson, Richard Reiner, Humberto Ortiz Zuazaga et Theodore Hope.

1.7 Droits d'auteur et utilisation

Copyright © 1995-1996, 1998 Marcus J. Ranum. Copyright © 1998-2002 Matt Curtin. Copyright 2004, Paul D. Robertson. Tous les droits réservé. Ce document peut être utilisé, réimprimé et redistribué comme si fournissant cet avis de droit d'auteur et toutes les attributions reste intact. Traductions du texte complet de l'original L'anglais dans d'autres langues est également explicitement autorisé. Traducteurs peuvent ajouter leurs noms à la section "contributeurs". Avant de pouvoir comprendre une discussion complète sur les pare-feu, il est important de comprendre les principes de base qui font des pare-feu travail.

2.1 Qu'est-ce qu'un pare-feu de réseau?

Un pare-feu est un système ou un groupe de systèmes qui impose un accès politique de contrôle entre deux réseaux ou plus. Le moyen réel par lequel ceci est accompli varie beaucoup, mais en principe, le pare-feu peut être considéré comme une paire de mécanismes: celui qui existe pour bloquer trafic, et l'autre qui existe pour permettre le trafic. Quelques pare-feu mettre davantage l'accent sur le blocage du trafic, tandis que d'autres mettent l'accent sur permettant le trafic. Probablement la chose la plus importante à reconnaître à propos d'un pare-feu est qu'il implémente une politique de contrôle d'accès. Si vous n'avez pas une bonne idée du type d'accès que vous souhaitez autoriser ou nier, un pare-feu ne vous aidera vraiment pas. Il est également important de reconnaître que la configuration du pare-feu, car il s'agit d'un mécanisme pour l'application de la politique, impose sa politique sur tout ce qui est derrière elle. Les administrateurs de pare-feu qui gèrent la connectivité d’un grand nombre d'hôtes ont donc une lourde responsabilité.

2.2 Pourquoi voudrais-je un pare-feu?

Internet, comme toute autre société, est en proie au genre de saccades qui aiment l’équivalent électronique d’écrire sur d’autres personnes murs avec du spraypaint, en déchirant leurs boîtes aux lettres, ou tout simplement assis dans la rue soufflant leurs cornes de voiture. Certaines personnes essaient d'obtenir un vrai travail fait sur Internet, et d'autres ont des données sensibles ou propriétaires ils doivent protéger. En général, le pare-feu a pour but de garder les saccades de votre réseau tout en vous laissant faire votre travail. Beaucoup de sociétés et de centres de données de style traditionnel ont des ordinateurs politiques et pratiques de sécurité à suivre. Dans un cas où Les politiques d'une entreprise dictent la manière dont les données doivent être protégées, un pare-feu est très important car c’est l’incarnation de la politique de l’entreprise. Souvent, la partie la plus difficile de la connexion à Internet, si vous êtes un grande entreprise, ne justifie pas la dépense ou l'effort, mais convaincante gestion qu'il est prudent de le faire. Un pare-feu fournit non seulement de véritables sécurité – il joue souvent un rôle important en tant que couverture de sécurité pour la gestion. Enfin, un pare-feu peut agir en tant qu’ambassadeur de votre entreprise auprès du L'Internet. De nombreuses entreprises utilisent leurs systèmes de pare-feu comme un lieu de travail. stocker des informations publiques sur les produits et services de l'entreprise, des fichiers télécharger, corrections de bugs, etc. Plusieurs de ces systèmes ont deviennent des éléments importants de la structure de service Internet (par exemple, UUnet.uu.net, whitehouse.gov, gatekeeper.dec.com) et ont bien réfléchi sur leurs sponsors organisationnels. Notez que, si cela est historiquement vrai, la plupart des entreprises placent désormais des informations publiques sur un serveur Web, souvent protégées par un pare-feu, mais pas normalement sur le pare-feu lui-même.

2.3 Contre quoi un pare-feu peut-il être protégé?

Certains pare-feu ne permettent que le trafic de courrier électronique à travers eux, protéger le réseau contre toute attaque autre que les attaques contre le service de messagerie. Les autres pare-feu fournissent des protections moins strictes, et bloquer les services qui sont connus pour être des problèmes. En général, les pare-feu sont configurés pour protéger contre les utilisateurs non authentifiés. connexions interactives du monde "extérieur". Ceci, plus que empêche les vandales de se connecter aux machines de votre ordinateur. réseau. Des pare-feu plus élaborés bloquent le trafic de l'extérieur vers à l'intérieur, mais permettent aux utilisateurs de l'intérieur de communiquer librement avec l'extérieur. Le pare-feu peut vous protéger contre tout type de attaque par le réseau si vous le débranchez. Les pare-feu sont également importants car ils peuvent fournir un seul «  starter point '' où la sécurité et l'audit peuvent être imposés. Contrairement à une situation où un ordinateur est attaqué par une personne composant un numéro avec un modem, le pare-feu peut agir comme un "contact téléphonique" et un traçage efficaces outil. Les pare-feu fournissent une fonction importante de journalisation et d’audit; souvent, ils fournissent à l'administrateur des résumés sur les types et quantité de trafic traversé, combien de tentatives ont été faites pour casser dedans, etc. Pour cette raison, les journaux de pare-feu sont des données extrêmement importantes. Ils peuvent être utilisés comme preuves devant les tribunaux de la plupart des pays. Vous devez sauvegarder, analyser et protéger les journaux de votre pare-feu en conséquence. C'est un point important: à condition que ce "point d'étranglement" puisse servir le même but sur votre réseau comme une porte gardée peut pour votre site locaux physiques. Cela signifie que chaque fois que vous avez un changement dans les "zones" ou des niveaux de sensibilité, un tel point de contrôle est approprié. Une entreprise a rarement seulement une porte extérieure et pas de réceptionniste ou de personnel de sécurité vérifier les badges en entrant. S'il y a des couches de sécurité sur votre site, il est raisonnable d’attendre des couches de sécurité sur votre réseau.

2.4 Contre quoi un pare-feu ne peut-il pas être protégé?

Les pare-feu ne peuvent pas protéger contre les attaques qui ne passent pas par la pare-feu. De nombreuses entreprises qui se connectent à Internet sont très préoccupé par les données propriétaires fuyant de la société à travers cette route. Malheureusement pour les personnes concernées, une bande magnétique, les disques compacts, DVD ou clés USB peuvent être utilisés avec autant d'efficacité exporter des données. De nombreuses organisations qui sont terrifiées (à un management niveau) des connexions Internet n’a pas de politique cohérente concernant la l'accès via des modems doit être protégé. C'est idiot de construire un six pieds porte en acier épais quand vous vivez dans une maison en bois, mais il y a beaucoup de organisations achètent là-bas des pare-feu coûteux et négligent la nombreuses autres portes arrière de leur réseau. Pour qu'un pare-feu fonctionne, il doit faire partie d'une sécurité organisationnelle globale cohérente architecture. Les stratégies de pare-feu doivent être réalistes et refléter les niveau de sécurité sur l'ensemble du réseau. Par exemple, un site avec top les données secrètes ou classifiées n’ont pas du tout besoin de pare-feu: elles ne devrait pas être connecté à Internet en premier lieu, ou le les systèmes avec les données vraiment secrètes doivent être isolés du reste du réseau d'entreprise. Les traîtres sont une autre chose contre laquelle un pare-feu ne peut pas vraiment vous protéger ou des idiots à l'intérieur de votre réseau. Alors qu’un espion industriel pourrait exporter informations via votre pare-feu, il est tout aussi susceptible de l'exporter via un téléphone, un télécopieur ou un disque compact. Les CD sont un des moyens beaucoup plus susceptibles de fuite d'informations de votre organisation qu'un pare-feu. Les pare-feu ne peuvent pas non plus vous protéger contre la stupidité. Les utilisateurs qui révèlent des informations sensibles par téléphone sont bons cibles d'ingénierie sociale; un attaquant peut être en mesure de pénétrer dans votre réseau en contournant complètement votre pare-feu, s’il peut trouver un employé «utile» à l'intérieur qui peut être dupe en donnant accès à un pool de modem. Avant de décider que ce n'est pas un problème dans votre organisation, demandez-vous combien de problèmes un entrepreneur a à obtenir connecté au réseau ou combien de difficulté un utilisateur qui a oublié son mot de passe a le réinitialiser. Si les membres du service d’assistance croient que chaque appel est interne, vous avez un problème qui ne peut pas être résolu par resserrement des contrôles sur les pare-feu. Les pare-feu ne peuvent pas protéger contre la plupart des tunnels protocoles d’application à des clients victimes de chevaux de Troie ou mal écrits. Là n'y a pas de balles magiques et un pare-feu n'est pas une excuse pour ne pas mettre en œuvre contrôles logiciels sur les réseaux internes ou ignorer la sécurité de l'hôte sur les serveurs. Mise en tunnel des "mauvaises" choses via HTTP, SMTP et autres protocoles est assez simple et trivialement démontré. La sécurité n'est pas «tire et oublie». Enfin, les pare-feu ne peuvent pas protéger contre les mauvaises choses qui leur sont permises. Par exemple, de nombreux chevaux de Troie utilisent le protocole IRC (Internet Relay Chat) permettre à un attaquant de contrôler un hôte interne compromis à partir d'un ordinateur public Serveur IRC. Si vous autorisez un système interne à se connecter à un serveur externe votre pare-feu ne fournira aucune protection contre ce vecteur de attaque.

2.5 Qu'en est-il des virus et autres logiciels malveillants?

Les pare-feu ne protègent pas très bien contre des virus ou des logiciels malveillants (malware). Il y a trop de façons d'encoder fichiers binaires pour le transfert sur les réseaux, et trop nombreux architectures et les virus pour essayer de les rechercher tous. En d'autre En d’autres termes, un pare-feu ne peut pas remplacer la conscience de la sécurité. vos utilisateurs. En général, un pare-feu ne peut pas protéger contre un attaque basée sur les données – attaques dans lesquelles quelque chose est envoyé ou copié un hôte interne où il est ensuite exécuté. Cette forme d'attaque a dans le passé contre diverses versions de envoyer un mail, Ghostscript, scripting des agents utilisateurs de messagerie comme Perspective, et les navigateurs Web comme Internet Explorer. Les organisations profondément préoccupées par les virus doivent mettre en œuvre mesures de contrôle des virus à l'échelle de l'organisation. Plutôt que d'essayer de filtrer pare-feu, assurez-vous que tous les postes de travail vulnérables Un logiciel antivirus est exécuté au redémarrage de la machine. La couverture de votre réseau avec un logiciel antivirus protégera contre les virus provenant de disquettes, de CD, de modems et d’Internet. Essayer de bloquer les virus au niveau du pare-feu ne protégera que contre virus provenant d'Internet. Analyse antivirus au niveau du pare-feu ou du courrier électronique passerelle va arrêter un grand nombre d'infections. Néanmoins, un nombre croissant de fournisseurs de pare-feu proposent "pare-feu". Ils ne sont probablement utiles que pour les naïfs utilisateurs échangeant des programmes exécutables Windows sur Intel et documents d'application malveillants compatibles avec les macros. Il y a beaucoup de approches basées sur un pare-feu pour traiter des problèmes tels que le Le ver «ILOVEYOU» et les attaques connexes, mais ce sont vraiment approches trop simplistes qui tentent de limiter les dommages de quelque chose c'est si stupide que cela n'aurait jamais dû se produire. Ne comptez sur aucune protection contre des attaquants dotés de cette fonctionnalité. (Depuis que «ILOVEYOU» a fait le tour, nous avons vu au moins une demi-douzaine attaques similaires, notamment Melissa, Happy99, Code Red et Badtrans.B, qui ont tous été heureusement traversés par de nombreux virus détectant pare-feu et passerelles de messagerie.) Un pare-feu puissant ne remplace jamais un logiciel sensible qui reconnaît la nature de ce qu'il manipule – des données non fiables provenant d'un partie non authentifiée – et se comporte de manière appropriée. Ne pense pas ça parce que "tout le monde" utilise cette messagerie ou parce que le vendeur est un société multinationale gargantuesque, vous êtes en sécurité. En fait, ce n'est pas vrai que "tout le monde" utilise n’importe quel courrier, et les entreprises spécialisées en transformant la technologie inventée ailleurs en quelque chose qui est «  facile d'utiliser '' sans aucune expertise sont plus susceptibles de produire des logiciels cela peut être dupe. Un examen plus approfondi de ce sujet serait digne d'intérêt [3], mais dépasse le cadre de ce document.

2.6 IPSEC rendra-t-il les pare-feu obsolètes?

Certains ont soutenu que c'était le cas. Avant de prononcer un tel prédiction générale, cependant, il est utile d'examiner ce que IPSEC est et ce qu'il fait. Une fois que nous le savons, nous pouvons examiner si IPSEC résoudra les problèmes que nous essayons de résoudre avec des pare-feu. IPSEC (IP SECurity) fait référence à un ensemble de normes développées par le Groupe de travail d'ingénierie Internet (IETF). Il y a beaucoup de documents qui définir collectivement ce qu'on appelle «IPSEC» [6]. IPSEC résout deux problèmes qui ont affecté la suite de protocoles IP pour ans: authentification d'hôte à hôte (qui permettra aux hôtes de savoir que ils parlent aux hôtes qu’ils pensent être) et le cryptage (ce qui empêchera les attaquants de surveiller le trafic aller entre les machines). Notez qu’aucun de ces problèmes n’est ce à quoi les pare-feu ont été créés pour résoudre. Bien que les pare-feu puissent aider à atténuer certains des risques présent sur Internet sans authentification ni cryptage, il existe des vraiment deux classes de problèmes ici: l'intégrité et la vie privée de la l'information circulant entre les hôtes et les limites imposées à quels types de connectivité est autorisée entre différents réseaux. IPSEC s'adresse à la première classe et pare-feu à la seconde. Cela signifie que l'un n'éliminera pas le besoin de l'autre, mais cela crée des possibilités intéressantes quand on regarde combinaison de pare-feu avec des hôtes compatibles IPSEC. À savoir, des choses telles que Réseaux privés virtuels (VPN) indépendants du vendeur, meilleur paquet filtrage (en filtrant sur si les paquets ont le IPSEC d’authentification), et les pare-feu de la couche application pourront d'avoir de meilleurs moyens de vérification d'hôte en utilisant réellement l'IPSEC en-tête d'authentification au lieu de "simplement faire confiance" à l'adresse IP présenté.

2.7 Quelles sont les bonnes sources d'informations imprimées sur les pare-feu?

Il existe plusieurs livres sur les pare-feu. Les plus connus sont: Les références associées sont:

Interconnexion de réseaux avec TCP / IP Vols I, II et III

Auteurs Douglas Comer et David Stevens

Éditeur Prentice Hall

Édition 1991

ISBN 0-13-468505-9 (I), 0-13-472242-6 (II), 0-13-474222-2     (III)

Commentaire Une discussion détaillée sur l'architecture et     mise en œuvre de l'Internet et de ses protocoles. Volume I (sur     principes, protocoles et architecture) est lisible par tous.     Le volume 2 (sur la conception, la mise en œuvre et les internes) est plus     technique. Le volume 3 couvre l’informatique client-serveur.

Unix System Security – Un guide pour les utilisateurs et     Administrateurs système

Auteur David Curry

Éditeur Addison Wesley

Édition 1992

ISBN 0-201-56327-4

2.8 Où puis-je obtenir plus d'informations sur les pare-feu sur le   L'Internet?

Manuel de sécurité du site http://www.rfc-editor.org/rfc/rfc2196.txt Le site Security Handbook est un document d’information de l’IETF qui   décrit les questions fondamentales à prendre en compte pour bien construire   sécurité du site. Les pare-feu font partie d'une plus grande sécurité   stratégie, comme le montre le manuel sur la sécurité du site.

Liste de diffusion Firewalls http://www.isc.org/index.pl?/ops/lists/firewalls/ La liste de diffusion des pare-feu Internet est un forum pour pare-feu   administrateurs et implémenteurs.

Liste de diffusion des assistants pare-feu http://honor.icsalabs.com/mailman/listinfo/firewall-wizards La liste de diffusion des assistants de pare-feu est un pare-feu modéré et   liste liée à la sécurité qui ressemble plus à un journal qu'un public   caisse à savon.

Pare-feu http://www.linuxdoc.org/HOWTO/Firewall-HOWTO.html Décrit exactement ce qui est nécessaire pour construire un pare-feu, en particulier   en utilisant Linux.

Firewall Toolkit (FWTK) et papiers de pare-feu ftp://ftp.tis.com/pub/firewalls/

Les publications de Marcus Ranum sur le pare-feu http://www.ranum.com/pubs/

Outils de sécurité de l'Université Texas A & M http://www.net.tamu.edu/ftp/security/TAMU/

COAST Project Internet Firewalls page http://www.cerias.purdue.edu/coast/firewalls/

3.1 Quelles sont les décisions de conception de base dans un pare-feu?

Un certain nombre de problèmes de conception de base doivent être résolus par la personne chanceuse qui a été chargé de la responsabilité de concevoir, spécifier et mettre en œuvre ou superviser l'installation d'un pare-feu. La première et la plus importante décision reflète la politique de votre entreprise ou organisation veut faire fonctionner le système: est le pare-feu en place explicitement pour refuser tous les services, sauf ceux essentiels à la mission de connexion au Net, ou le pare-feu est-il en place pour fournir une méthode mesurée et vérifiée d’accès «en file d’attente» dans un manière non menaçante? Il y a des degrés de paranoïa entre ces les positions; la position finale de votre pare-feu pourrait être plus le résultat d'une décision politique qu'une décision d'ingénierie. La seconde est: quel niveau de contrôle, de redondance et de contrôle font tu veux? Après avoir établi le niveau de risque acceptable (c.-à-d. Comment paranoïaque vous êtes) en résolvant le premier problème, vous pouvez former un liste de contrôle de ce qui devrait être surveillé, autorisé et refusé. Dans En d’autres termes, vous commencez par définir vos objectifs généraux et puis combinez une analyse des besoins avec une évaluation des risques et triez les presque toujours des exigences contradictoires dans une liste de blanchisserie spécifie ce que vous prévoyez de mettre en œuvre. Le troisième problème est financier. Nous ne pouvons pas aborder celui-ci ici dans tout sauf des termes vagues, mais il est important d'essayer de quantifier toute solutions proposées en termes de combien il en coûtera pour acheter ou implémenter. Par exemple, un pare-feu complet peut coûter entre 100 000 $ dans le haut de gamme et gratuit dans le bas de gamme. La libre option, possibilité de configuration sur un routeur Cisco ou similaire ne coûtera que du temps de personnel et quelques tasses de café. L'implémentation d'un pare-feu haut de gamme à partir de zéro peut coûter plusieurs mois-hommes, ce qui peut représenter 30 000 dollars de salaire du personnel et avantages. Les frais généraux de gestion des systèmes sont également à prendre en compte. Construire une bière maison, c'est bien, mais il est important de la construire pour que il ne nécessite pas d'attention constante (et coûteuse). C'est important, en d'autres termes, pour évaluer les pare-feu non seulement en termes de ce qu'ils Coût maintenant, mais coûts continus tels que le support. Sur le plan technique, il y a quelques décisions à prendre, basées sur sur le fait que, à toutes fins utiles, ce dont nous parlons est un service de routage de trafic statique placé entre le service réseau le routeur du fournisseur et votre réseau interne. Le routage du trafic service peut être mis en œuvre à un niveau IP via quelque chose comme filtrage règles dans un routeur ou au niveau de l'application via des passerelles de proxy et prestations de service. La décision à prendre est de savoir s'il faut placer un objet exposé dépouillé machine sur le réseau extérieur pour exécuter des services proxy pour telnet, FTP, nouvelles, etc., ou s'il faut configurer un routeur de filtrage en tant que filtre, permettant la communication avec une ou plusieurs machines internes. Il y a avantages et inconvénients des deux approches, avec la machine proxy fournissant un plus haut niveau d'audit et, potentiellement, de sécurité en retour augmentation des coûts de configuration et diminution du niveau de service qui peut être fourni (puisqu’un proxy doit être développé pour chaque service souhaité). Le vieux compromis entre facilité d’utilisation et la sécurité revient nous hanter avec vengeance.

3.2 Quels sont les types de base de pare-feu?

Conceptuellement, il existe trois types de pare-feu:

Couche réseau

Couche d'application

Hybrides

Ils ne sont pas aussi différents qu'on pourrait le penser, et les dernières technologies estompent la distinction au point où il n'est plus clair si l'un ou l'autre est «meilleur» ou «pire». Comme toujours, vous devez être veillez à choisir le type qui répond à vos besoins. Qui dépend des mécanismes que le pare-feu utilise pour passer le trafic d'une zone de sécurité à une autre. L'international Modèle OSI (Open Systems Interconnect) d’organisation de normalisation (ISO) pour la mise en réseau définit sept couches, chaque couche fournissant des services que les couches "de niveau supérieur" dépendent. Dans l'ordre du bas, ces couches sont physiques, liaison de données, réseau, transport, session, présentation, application. La chose importante à reconnaître est que le niveau inférieur de la mécanisme de transmission, moins le pare-feu peut être examiné. De manière générale, les pare-feu de bas niveau sont plus rapides, mais plus faciles. tromper en faisant la mauvaise chose. De nos jours, la plupart des pare-feu entrent dans la catégorie «hybride», ce qui le filtrage de réseau ainsi qu'une certaine quantité d'inspection d'application. Le montant change en fonction du fournisseur, du produit, du protocole et de la version, donc un certain niveau de creuser et / ou de tester est souvent nécessaire.

3.2.1 Pare-feu de couche réseau

Ceux-ci prennent généralement leurs décisions en fonction de la source, de la destination adresses et ports (voir l’annexe 6 pour une description plus détaillée discussion sur les ports) dans des paquets IP individuels. Un simple routeur est le Pare-feu de couche réseau «  traditionnel '', car il n'est pas capable de faire décisions particulièrement sophistiquées sur ce qu'un paquet est en réalité parler à ou d'où il vient réellement. Couche réseau moderne les pare-feu sont devenus de plus en plus sophistiqués, et maintenant maintenant informations internes sur l'état des connexions passant par eux, le contenu de certains flux de données, etc. Une chose c'est une distinction importante sur de nombreux pare-feu de couche réseau est qu'ils acheminent le trafic directement par eux, alors utilisez-en un besoin d’avoir un bloc d’adresses IP valablement attribué ou d’utiliser un «  privé bloc d'adresse internet [5]. Les pare-feu de la couche réseau ont tendance être très rapide et ont tendance à être très transparent pour les utilisateurs.

Figure 1: Pare-feu hôte filtré

Dans la figure 1, un pare-feu de couche réseau appelé un "pare-feu hôte filtré" est représenté. Dans un hôte filtré pare-feu, l’accès vers et depuis un hôte unique est contrôlé au moyen d’un routeur fonctionnant sur une couche réseau. L'hôte unique est un bastion hôte; un point fort hautement défendu et sécurisé qui (espérons-le) peut résister à l'attaque.

Figure 2: Pare-feu de sous-réseau filtré

Exemple de pare-feu de couche réseau: Dans Figure 2, un pare-feu de couche réseau appelé «pare-feu de sous-réseau filtré» est représenté. Dans un sous-réseau filtré pare-feu, l'accès à et depuis tout un réseau est contrôlé au moyen de un routeur fonctionnant sur une couche réseau. C'est semblable à un projeté hôte, sauf qu’il s’agit effectivement d’un réseau d’hôtes filtrés.

3.2.2 Pare-feu de la couche d'application

Ce sont généralement des hôtes exécutant des serveurs proxy, qui ne permettent aucune le trafic directement entre les réseaux et qui effectuent une journalisation élaborée et audit du trafic qui les traverse. Depuis le proxy les applications sont des composants logiciels fonctionnant sur le pare-feu, c’est un bon endroit pour faire beaucoup de journalisation et de contrôle d'accès. Application Les pare-feu de couche peuvent être utilisés en tant que traducteurs d'adresses réseau, car le trafic va dans un côté et sort de l'autre, après avoir passé à travers une application qui masque efficacement l’origine du établir la connexion. Avoir une application dans le chemin dans certains cas peut avoir un impact sur les performances et rendre le pare-feu moins transparent. Les premiers pare-feu de la couche d’application, tels que ceux construits avec TIS pare-feu, ne sont pas particulièrement transparents pour les utilisateurs finaux et peut nécessiter une formation. Les pare-feu modernes de la couche d’application sont souvent totalement transparent. Les pare-feu de couche d’application ont tendance à fournir des rapports d’audit plus détaillés et ont tendance à imposer des mesures plus conservatrices. modèles de sécurité que les pare-feu de couche réseau.

Figure 3: Passerelle à double hébergement

Exemple de pare-feu de couche d'application: Dans Figure 3, un pare-feu de couche d'application appelé une «passerelle à double hébergement» est représenté. Une double passerelle est un hôte hautement sécurisé qui exécute un logiciel proxy. Il a deux réseau interfaces, une sur chaque réseau, et bloque tout le trafic passant à travers. La plupart des pare-feu se situent maintenant quelque part entre les pare-feu de couche réseau et pare-feu de couche d'application. Comme prévu, les pare-feu de la couche réseau sont de plus en plus "au courant" de l'information qui passe par les pare-feu de la couche d’application sont de plus en plus «faibles» niveau '' et transparent. Le résultat final est que maintenant il y a rapide systèmes de filtrage de paquets enregistrant et vérifiant les données au fur et à mesure de leur passage le système. De plus en plus de pare-feu (couche réseau et application) incorporer un cryptage afin de protéger le trafic transitant entre eux sur Internet. Pare-feux avec cryptage de bout en bout peut être utilisé par des organisations disposant de plusieurs points Internet connectivité pour utiliser Internet en tant que «  backbone privé '' sans se soucier de leurs données ou mots de passe étant reniflés. (IPSEC, décrit à la section 2.6, joue un rôle de plus en plus rôle important dans la construction de tels réseaux privés virtuels réseaux.)

3.3 Que sont les serveurs proxy et comment fonctionnent-ils?

Un serveur proxy (parfois appelé passerelle d’application ou expéditeur) est une application qui assure la médiation du trafic entre un réseau et Internet. Les procurations sont souvent utilisées au lieu de contrôles du trafic basés sur les routeurs, pour empêcher le trafic de passer directement entre les réseaux. Beaucoup de proxies contiennent une journalisation supplémentaire ou soutien à l'authentification de l'utilisateur. Puisque les mandataires doivent "comprendre" le protocole d'application utilisé, ils peuvent également implémenter le protocole sécurité spécifique (par exemple, un proxy FTP peut être configurable pour permettre FTP entrant et bloquer le FTP sortant). Les serveurs proxy sont spécifiques à l'application. Afin de soutenir une nouvelle protocole via un proxy, un proxy doit être développé pour cela. Un populaire ensemble de serveurs proxy est la boîte à outils TIS Internet Firewall («FWTK») qui inclut les mandataires pour Telnet, rlogin, FTP, le système X Window, Actualités HTTP / Web et NNTP / Usenet. SOCKS est un système de proxy générique qui peut être compilé dans une application côté client pour le faire fonctionner par un pare-feu. Son avantage est qu’il est facile à utiliser, mais ce n’est pas le cas. supporte l'ajout de hooks d'authentification ou de protocole spécifique enregistrement. Pour plus d'informations sur SOCKS, voir http://www.socks.nec.com/.

3.4 Quels sont certains outils bon marché de filtrage de paquets?

Les outils de sécurité de la Texas A & M University comprennent un logiciel pour mise en place de routeurs de filtrage. Karlbridge est un système de dépistage basé sur PC kit de routeur disponible à partir de ftp://ftp.net.ohio-state.edu/pub/kbridge/. Il existe de nombreux écrans de paquets au niveau du noyau, notamment: ipf, ipfw, ipchains, pf, et ipfwadm. Typiquement, ceux-ci sont inclus dans diverses implémentations Unix libres, telles que FreeBSD, OpenBSD, NetBSD, et Linux. Vous pourriez aussi trouver ces outils disponibles dans votre implémentation commerciale Unix. Si vous êtes prêt à vous salir les mains, c'est complètement possible de construire un pare-feu sécurisé et entièrement fonctionnel pour le prix du matériel et une partie de votre temps.

3.5 Quelles sont les règles de filtrage raisonnables pour un   écran de paquets basé sur le noyau?

Cet exemple est écrit spécifiquement pour ipfwadm sur Linux, mais les principes (et même une grande partie de la syntaxe) s’appliquent à d’autres interfaces du noyau pour le filtrage de paquets sur les systèmes Unix "open source". Il existe quatre catégories de base couvertes par le ipfwadm règles:

-UNE Comptabilité par paquets

-JE Pare-feu d'entrée

-O Pare-feu de sortie

-F Pare-feu de transmission

ipfwadm a également fait du masquerading (-M) capacités. Pour plus d'informations sur les commutateurs et les options, reportez-vous à la ipfwadm homme page.

3.5.1 Mise en œuvre

Ici, notre organisation utilise un réseau privé de classe C (RFC 1918) 192.168.1.0. Notre FAI nous a attribué l'adresse 201.123.102.32 pour l'interface externe de notre passerelle et 201.123.102.33 pour notre externe serveur de courrier. La politique organisationnelle dit:

Autoriser toutes les connexions TCP sortantes

Autoriser les serveurs SMTP et DNS entrants vers un serveur de messagerie externe

Bloquer tout autre trafic

Le bloc de commandes suivant peut être placé dans un fichier de démarrage du système. (peut-être rc.local sur les systèmes Unix).

ipfwadm -F -f       ipfwadm -F -p nier       ipfwadm -F -i m -b -P tcp -S 0.0.0.0/0 1024: 65535 -D 201.123.102.33 25       ipfwadm -F -i m -b -P tcp -S 0.0.0.0/0 1024: 65535 -D 201.123.102.33 53       ipfwadm -F -i m -b -P udp -S 0.0.0.0/0 1024: 65535 -D 201.123.102.33 53       ipfwadm -F -a m -S 192.168.1.0/24 -D 0.0.0.0/0 -W eth0

      / sbin / route add -host 201.123.102.33 gw 192.168.1.2

3.5.2 Explication

3.6 Quelles sont les règles de filtrage raisonnables pour un Cisco?

L’exemple de la figure 4 montre une possibilité configuration pour utiliser Cisco en tant que routeur de filtrage. C'est un échantillon cela montre la mise en œuvre de la politique spécifique. Votre politique sera sans aucun doute varier.

Figure 4: Routeur de filtrage de paquets

Dans cet exemple, une entreprise a l'adresse réseau 195.55.55.0 de classe C. Le réseau de l'entreprise est connecté à Internet via le fournisseur de services IP. La politique de la société est de permettre à tout le monde d’accéder aux services Internet. toutes les connexions sortantes sont acceptées. Toutes les connexions entrantes vont via «  mailhost ''. Mail et DNS ne sont que des services entrants.

3.6.1 Mise en œuvre

Autoriser toutes les connexions TCP sortantes

Autoriser les adresses SMTP et DNS entrantes sur mailhost

Autoriser les connexions de données FTP entrantes au port TCP élevé (1024)

Essayez de protéger les services qui vivent sur des numéros de port élevés

Seuls les paquets entrants provenant d'Internet sont vérifiés dans cette configuration. Rules are tested in order and stop when the first match is found. There is an implicit deny rule at the end of an access list that denies everything. This IP access list assumes that you are running Cisco IOS v. 10.3 or later.

no ip source-route ! interface ethernet 0 ip address 195.55.55.1 no ip directed-broadcast ! interface serial 0 no ip directed-broadcast ip access-group 101 in ! access-list 101 deny ip 127.0.0.0 0.255.255.255 any access-list 101 deny ip 10.0.0.0 0.255.255.255 any access-list 101 deny ip 172.16.0.0 0.15.255.255 any access-list 101 deny ip 192.168.0.0 0.0.255.255 any access-list 101 deny ip any 0.0.0.255 255.255.255.0 access-list 101 deny ip any 0.0.0.0 255.255.255.0 ! access-list 101 deny ip 195.55.55.0 0.0.0.255 access-list 101 permit tcp any any established ! access-list 101 permit tcp any host 195.55.55.10 eq smtp access-list 101 permit tcp any host 195.55.55.10 eq dns access-list 101 permit udp any host 192.55.55.10 eq dns ! access-list 101 deny tcp any any range 6000 6003 access-list 101 deny tcp any any range 2000 2003 access-list 101 deny tcp any any eq 2049 access-list 101 deny udp any any eq 2049 ! access-list 101 permit tcp any 20 any gt 1024 ! access-list 101 permit icmp any any ! snmp-server community FOOBAR RO 2 line vty 0 4 access-class 2 in access-list 2 permit 195.55.55.0 0.0.0.255

3.6.2 Explanations

Drop all source-routed packets. Source routing can be used for   address spoofing.

Drop directed broadcasts, which are used in smurf attacks.

If an incoming packet claims to be from a local net, loopback   network, or private network, drop it.

All packets which are part of already established   TCP-connections can pass through without further checking.

All connections to low port numbers are blocked except SMTP and   DNS.

Block all services that listen for TCP connections on high port   Nombres. X11 (port 6000+), OpenWindows (port 2000+) are a few   candidates. NFS (port 2049) runs usually over UDP, but it can be run   over TCP, so you should block it.

Incoming connections from port 20 into high port numbers are   supposed to be FTP data connections.

Access-list 2 limits access to router itself (telnet & SNMP)

All UDP traffic is blocked to protect RPC services

3.6.3 Shortcomings

You cannot enforce strong access policies with router access   lists. Users can easily install backdoors to their systems to get   over « no incoming telnet'' or « no X11'' rules. Also crackers   install telnet backdoors on systems where they break in.

You can never be sure what services you have listening for   connections on high port numbers. (You can't be sure of what   services you have listening for connections on low port numbers,   either, especially in highly decentralized environments where people   can put their own machines on the network or where they can get   administrative access to their own machines.)

Checking the source port on incoming FTP data connections is a   weak security method. It also breaks access to some FTP sites. Il   makes use of the service more difficult for users without preventing   bad guys from scanning your systems.

Use at least Cisco version 9.21 so you can filter incoming packets and check for address spoofing. It's still better to use 10.3, where you get some extra features (like filtering on source port) and some improvements on filter syntax. You have still a few ways to make your setup stronger. Block all incoming TCP-connections and tell users to use passive-FTP clients. You can also block outgoing ICMP echo-reply and destination-unreachable messages to hide your network and to prevent use of network scanners. Cisco.com use to have an archive of examples for building firewalls using Cisco routers, but it doesn't seem to be online anymore. There are some notes on Cisco access control lists, at least, at ftp://ftp.cisco.com/pub/mibs/app_notes/access-lists.

3.7 What are the critical resources in a firewall?

It's important to understand the critical resources of your firewall architecture, so when you do capacity planning, performance optimizations, etc., you know exactly what you need to do, and how much you need to do it in order to get the desired result. What exactly the firewall's critical resources are tends to vary from site to site, depending on the sort of traffic that loads the system. Some people think they'll automatically be able to increase the data throughput of their firewall by putting in a box with a faster CPU, or another CPU, when this isn't necessarily the case. Potentially, this could be a large waste of money that doesn't do anything to solve the problem at hand or provide the expected scalability. On busy systems, Mémoire is extremely important. Vous devez have enough RAM to support every instance of every program necessary to service the load placed on that machine. Otherwise, the swapping will start and the productivity will stop. Light swapping isn't usually much of a problem, but if a system's swap space begins to get busy, then it's usually time for more RAM. A system that's heavily swapping is often relatively easy to push over the edge in a denial-of-service attack, or simply fall behind in processing the load placed on it. This is where long email delays start. Beyond the system's requirement for memory, it's useful to understand that different services use different system resources. Alors le configuration that you have for your system should be indicative of the kind of load you plan to service. A 1400 MHz processor isn't going to do you much good if all you're doing is netnews and mail, and are trying to do it on an IDE disk with an ISA controller.

Tableau 1: Critical Resources for Firewall Services

Un service Critical Resource

Email Disk I/O

Netnews Disk I/O

Web Host OS Socket Performance

IP Routing Host OS Socket Performance

Web Cache Host OS Socket Performance, Disk I/O

3.8 What is a DMZ, and why do I want one?

« DMZ'' is an abbreviation for « demilitarized zone''. In the context of firewalls, this refers to a part of the network that is neither part of the internal network nor directly part of the Internet. Typically, this is the area between your Internet access router and your bastion host, though it can be between any two policy-enforcing components of your architecture. A DMZ can be created by putting access control lists on your access router. This minimizes the exposure of hosts on your external LAN by allowing only recognized and managed services on those hosts to be accessible by hosts on the Internet. Many commercial firewalls simply make a third interface off of the bastion host and label it the DMZ, the point is that the network is neither « inside'' nor « outside''. For example, a web server running on NT might be vulnerable to a number of denial-of-service attacks against such services as RPC, NetBIOS and SMB. These services are not required for the operation of a web server, so blocking TCP connections to ports 135, 137, 138, and 139 on that host will reduce the exposure to a denial-of-service attack. In fact, if you block everything but HTTP traffic to that host, an attacker will only have one service to attack. This illustrates an important principle: never offer attackers more to work with than is absolutely necessary to support the services you want to offer the public.

3.9 How might I increase the security and scalability of my   DMZ?

A common approach for an attacker is to break into a host that's vulnerable to attack, and exploit trust relationships between the vulnerable host and more interesting targets. If you are running a number of services that have different levels of security, you might want to consider breaking your DMZ into several « security zones''. This can be done by having a number of different networks within the DMZ. For example, the access router could feed two Ethernets, both protected by ACLs, and therefore in the DMZ. On one of the Ethernets, you might have hosts whose purpose is to service your organization's need for Internet connectivity. Celles-ci will likely relay mail, news, and host DNS. On the other Ethernet could be your web server(s) and other hosts that provide services for the benefit of Internet users. In many organizations, services for Internet users tend to be less carefully guarded and are more likely to be doing insecure things. (For example, in the case of a web server, unauthenticated and untrusted users might be running CGI, PHP, or other executable programmes. This might be reasonable for your web server, but brings with it a certain set of risks that need to be managed. It is likely these services are too risky for an organization to run them on a bastion host, where a slip-up can result in the complete failure of the security mechanisms.) By putting hosts with similar levels of risk on networks together in the DMZ, you can help minimize the effect of a breakin at your site. If someone breaks into your web server by exploiting some bug in your web server, they'll not be able to use it as a launching point to break into your private network if the web servers are on a separate LAN from the bastion hosts, and you don't have any trust relationships between the web server and bastion host. Now, keep in mind that this is Ethernet. If someone breaks into your web server, and your bastion host is on the same Ethernet, an attacker can install a sniffer on your web server, and watch the traffic to and from your bastion host. This might reveal things that can be used to break into the bastion host and gain access to the internal network. (Switched Ethernet can reduce your exposure to this kind of problem, but will not eliminate it.) Splitting services up not only by host, but by network, and limiting the level of trust between hosts on those networks, you can greatly reduce the likelihood of a breakin on one host being used to break into the other. Succinctly stated: breaking into the web server in this case won't make it any easier to break into the bastion host. You can also increase the scalability of your architecture by placing hosts on different networks. The fewer machines that there are to share the available bandwidth, the more bandwidth that each will get.

3.10 What is a `single point of failure', and how do I avoid   having one?

An architecture whose security hinges upon one mechanism has a single point of failure. Software that runs bastion hosts has bugs. Applications have bugs. Software that controls routers has bugs. Il makes sense to use all of these components to build a securely designed network, and to use them in redundant ways. If your firewall architecture is a screened subnet, you have two packet filtering routers and a bastion host. (See question 3.2 from this section.) Your Internet access router will not permit traffic from the Internet to get all the way into your private network. However, if you don't enforce that rule with any other mechanisms on the bastion host and/or choke router, only one component of your architecture needs to fail or be compromised in order to get inside. On the other hand, if you have a redundant rule on the bastion host, and again on the choke router, an attacker will need to defeat Trois mechanisms. Further, if the bastion host or the choke router needs to invoke its rule to block outside access to the internal network, you might want to have it trigger an alarm of some sort, since you know that someone has gotten through your access router.

3.11 How can I block all of the bad stuff?

For firewalls where the emphasis is on security instead of connectivity, you should consider blocking tout par default, and only specifically allowing what services you need on a case-by-case basis. If you block everything, except a specific set of services, then you've already made your job much easier. Instead of having to worry about every security problem with everything product and service around, you only need to worry about every security problem with a specific set of services and products. Before turning on a service, you should consider a couple of questions:

Is the protocol for this product a well-known, published   protocol?

Is the application to service this protocol available for public   inspection of its implementation?

How well known is the service and product?

How does allowing this service change the firewall architecture?   Will an attacker see things differently? Could it be exploited to   get at my internal network, or to change things on hosts in my DMZ?

When considering the above questions, keep the following in mind:

« Security through obscurity'' is no security at all.   Unpublished protocols have been examined by bad guys and defeated.

Despite what the marketing representatives say, not every   protocol or service is designed with security in mind. In fact, the   number that are is very few.

Even in cases where security is a consideration, not all   organizations have competent security staff. Among those who don't,   not all are willing to bring a competent consultant into the   projet. The end result is that otherwise-competent, well-intended   developers can design insecure systems.

The less that a vendor is willing to tell you about how their   système vraiment works, the more likely it is that security   (or other) problems exist. Only vendors with something to hide have   a reason to hide their designs and   implémentations [2].

3.12 How can I restrict web access so users can't view sites   unrelated to work?

A few years ago, someone got the idea that it's a good idea to block « bad'' web sites, i.e., those that contain material that The Company views « inappropriate''. The idea has been increasing in popularity, but there are several things to consider when thinking about implementing such controls in your firewall.

It is not possible to practically block everything that an   employer deems « inappropriate''. The Internet is full of every sort   of material. Blocking one source will only redirect traffic to   another source of such material, or cause someone to figure a way   around the block.

Most organizations do not have a standard for judging the   appropriateness of material that their employees bring to work,   e.g., books and magazines. Do you inspect everyone's briefcase for   « inappropriate material'' every day? If you do not, then why would   you inspect every packet for « inappropriate material''? Tout   decisions along those lines in such an organization will be   arbitrary. Attempting to take disciplinary action against an   employee where the only standard is arbitrary typically isn't wise,   for reasons well beyond the scope of this document.

Products that perform site-blocking, commercial and otherwise,   are typically easy to circumvent. Hostnames can be rewritten as IP   adresses. IP addresses can be written as a 32-bit integer value,   or as four 8-bit integers (the most common form). Autre   possibilities exist, as well. Connections can be proxied. Web   pages can be fetched via email. You can't block them all. le   effort that you'll spend trying to implement and manage such   controls will almost certainly far exceed any level of damage   control that you're hoping to have.

The rule-of-thumb to remember here is that you cannot solve social problems with technology. If there is a problem with someone going to an « inappropriate'' web site, that is because someone else saw it and was offended by what he saw, or because that person's productivity is below expectations. In either case, those are matters for the personnel department, not the firewall administrator.

4.1 What is source routed traffic and why is it a threat?

Normally, the route a packet takes from its source to its destination is determined by the routers between the source and destination. le packet itself only says where it wants to go (the destination address), and nothing about how it expects to get there. There is an optional way for the sender of a packet (the source) to include information in the packet that tells the route the packet should take to get to its destination; thus the name « source routing''. For a firewall, source routing is noteworthy, since an attacker can generate traffic claiming to be from a system « inside'' the firewall. In general, such traffic wouldn't route to the firewall properly, but with the source routing option, all the routers between the attacker's machine and the target will return traffic along the reverse path of the source route. Implementing such an attack is quite easy; alors firewall builders should not discount it as unlikely to happen. In practice, source routing is very little used. In fact, generally the main legitimate use is in debugging network problems or routing traffic over specific links for congestion control for specialized situations. When building a firewall, source routing should be blocked at some point. Most commercial routers incorporate the ability to block source routing specifically, and many versions of Unix that might be used to build firewall bastion hosts have the ability to disable or to ignore source routed traffic.

4.2 What are ICMP redirects and redirect bombs?

An ICMP Redirect tells the recipient system to override something in its routing table. It is legitimately used by routers to tell hosts that the host is using a non-optimal or defunct route to a particular destination, i.e., the host is sending it to the wrong router. le wrong router sends the host back an ICMP Redirect packet that tells the host what the correct route should be. If you can forge ICMP Redirect packets, and if your target host pays attention to them, you can alter the routing tables on the host and possibly subvert the security of the host by causing traffic to flow via a path the network manager didn't intend. ICMP Redirects also may be employed for denial of service attacks, where a host is sent a route that loses it connectivity, or is sent an ICMP Network Unreachable packet telling it that it can no longer access a particular network. Many firewall builders screen ICMP traffic from their network, since it limits the ability of outsiders to ping hosts, or modify their routing tables. Before you decide to block all ICMP packets, you should be aware of how the TCP protocol does « Path MTU Discovery'', to make certain that you don't break connectivity to other sites. If you can't safely block it everywhere, you can consider allowing selected types of ICMP to selected routing devices. If you don't block it, you should at least ensure that your routers and hosts don't respond to broadcast ping packets.

4.3 What about denial of service?

Denial of service is when someone decides to make your network or firewall useless by disrupting it, crashing it, jamming it, or flooding it. The problem with denial of service on the Internet is that it is impossible to prevent. The reason has to do with the distributed nature of the network: every network node is connected via other networks which in turn connect to other networks, etc. A firewall administrator or ISP only has control of a few of the local elements within reach. An attacker can always disrupt a connection « upstream'' from where the victim controls it. In other words, if someone wanted to take a network off the air, he could do it either by taking the network off the air, or by taking the networks it connects to off the air, ad infinitum. There are many, many, ways someone can deny service, ranging from the complex to the trivial brute-force. Si you are considering using Internet for a service which is absolutely time or mission critical, you should consider your fallback position in the event that the network is down or damaged. TCP/IP's UDP echo service is trivially abused to get two servers to flood a network segment with echo packets. You should consider commenting out unused entries in /etc/inetd.conf of Unix hosts, ajouter no ip small-servers to Cisco routers, or the equivalent for your components.

4.4 What are some common attacks, and how can I protect my   system against them?

Each site is a little different from every other in terms of what attacks are likely to be used against it. Some recurring themes do arise, though.

4.4.1 SMTP Server Hijacking (Unauthorized Relaying)

This is where a spammer will take many thousands of copies of a message and send it to a huge list of email addresses. Because these lists are often so bad, and in order to increase the speed of operation for the spammer, many have resorted to simply sending all of their mail to an SMTP server that will take care of actually delivering the mail. Of course, all of the bounces, spam complaints, hate mail, and bad PR come for the site that was used as a relay. There is a very real cost associated with this, mostly in paying people to clean up the mess afterward. The Mail Abuse Prevention Système1Transport Security Initiative2maintains a complete description of the problem, and how to configure about every mailer on the planet to protect against this attack.

4.4.2 Exploiting Bugs in Applications

Various versions of web servers, mail servers, and other Internet service software contain bugs that allow remote (Internet) users to do things ranging from gain control of the machine to making that application crash and just about everything in between. The exposure to this risk can be reduced by running only necessary services, keeping up to date on patches, and using products that have been around a while.

4.4.3 Bugs in Operating Systems

Again, these are typically initiated by users remotely. en fonctionnement systems that are relatively new to IP networking tend to be more problematic, as more mature operating systems have had time to find and eliminate their bugs. An attacker can often make the target equipment continuously reboot, crash, lose the ability to talk to the network, or replace files on the machine. Here, running as few operating system services as possible can help. Also, having a packet filter in front of the operating system can reduce the exposure to a large number of these types of attacks. And, of course, chosing a stable operating system will help here as well. When selecting an OS, don't be fooled into believing that « the pricier, the better''. Free operating systems are often much more robust than their commercial counterparts

5.1 Do I really want to allow everything that my users ask   for?

It's entirely possible that the answer is « no''. Each site has its own policies about what is and isn't needed, but it's important to remember that a large part of the job of being an organization's gatekeeper is éducation. Users want streaming video, real-time chat, and to be able to offer services to external customers that require interaction with live databases on the internal network. That doesn't mean that any of these things can be done without presenting more risk to the organization than the supposed « value'' of heading down that road is worth. Most users don't want to put their organization at risk. They just read the trade rags, see advertisements, and they want to do those things, too. It's important to look into what it is that they really want to do, and to help them understand how they might be able to accomplish their real objective in a more secure manner. You won't always be popular, and you might even find yourself being given direction to do something incredibly stupid, like « just open up ports foo through bar''. If that happens, don't worry about it. Il would be wise to keep all of your exchanges on such an event so that when a 12-year-old script kiddie breaks in, you'll at least be able to separate yourself from the whole mess.

5.2 How do I make Web/HTTP work through my firewall?

There are three ways to do it.

Allow « established'' connections out via a router, if you are   using screening routers.

Use a web client that supports SOCKS, and run SOCKS on your   bastion host.

Run some kind of proxy-capable web server on the bastion host.   Some options include   Squid3,   Apache4,   Netscape Proxy5,   et http-gw from the TIS firewall toolkit. Most of   these can also proxy other protocols (such as gopher and ftp), and   can cache objects fetched, which will also typically result in a   performance boost for the users, and more efficient use of your   connection to the Internet. Essentially all web clients (Mozilla,   Internet Explorer, Lynx, etc.) have proxy server support built   directly into them.

5.3 How do I make SSL work through the firewall?

SSL is a protocol that allows secure connections across the Internet. Typically, SSL is used to protect HTTP traffic. However, other protocols (such as telnet) can run atop SSL. Enabling SSL through your firewall can be done the same way that you would allow HTTP traffic, if it's HTTP that you're using SSL to secure, which is usually true. The only difference is that instead of using something that will simply relay HTTP, you'll need something that can tunnel SSL. This is a feature present on most web object caches. You can find out more about SSL from Netscape6.

5.4 How do I make DNS work with a firewall?

Some organizations want to hide DNS names from the outside. Beaucoup experts don't think hiding DNS names is worthwhile, but if site/corporate policy mandates hiding domain names, this is one approach that is known to work. Another reason you may have to hide domain names is if you have a non-standard addressing scheme on your internal network. In that case, you have no choice but to hide those adresses. Don't fool yourself into thinking that if your DNS names are hidden that it will slow an attacker down much if they break into your firewall. Information about what is on your network is too easily gleaned from the networking layer itself. If you want an interesting demonstration of this, ping the subnet broadcast address on your LAN and then do an « arp -a.'' Note also that hiding names in the DNS doesn't address the problem of host names « leaking'' out in mail headers, news articles, etc. This approach is one of many, and is useful for organizations that wish to hide their host names from the Internet. The success of this approach lies on the fact that DNS clients on a machine don't have to talk to a DNS server on that same machine. In other words, just because there's a DNS server on a machine, there's nothing wrong with (and there are often advantages to) redirecting that machine's DNS client activity to a DNS server on another machine. First, you set up a DNS server on the bastion host that the outside world can talk to. You set this server up so that it claims to be authoritative for your domains. In fact, all this server knows is what you want the outside world to know; the names and addresses of your gateways, your wildcard MX records, and so forth. This is the « public'' serveur. Then, you set up a DNS server on an internal machine. This server also claims to be authoritative for your domains; unlike the public server, this one is telling the truth. This is your « normal'' nameserver, into which you put all your « normal'' DNS stuff. You also set this server up to forward queries that it can't resolve to the public server (using a « forwarders'' line in /etc/named.boot on a Unix machine, for example). Finally, you set up all your DNS clients (the /etc/resolv.conf file on a Unix box, for instance), including the ones on the machine with the public server, to use the internal server. This is the key. An internal client asking about an internal host asks the internal server, and gets an answer; an internal client asking about an external host asks the internal server, which asks the public server, which asks the Internet, and the answer is relayed back. A client on the public server works just the same way. An external client, however, asking about an internal host gets back the « restricted'' answer from the public server. This approach assumes that there's a packet filtering firewall between these two servers that will allow them to talk DNS to each other, but otherwise restricts DNS between other hosts. Another trick that's useful in this scheme is to employ wildcard PTR records in your IN-ADDR.ARPA domains. These cause an an address-to-name lookup for any of your non-public hosts to return something like « unknown.YOUR.DOMAIN'' rather than an error. Ce satisfies anonymous FTP sites like ftp.uu.net that insist on having a name for the machines they talk to. This may fail when talking to sites that do a DNS cross-check in which the host name is matched against its address and vice versa.

5.5 How do I make FTP work through my firewall?

Generally, making FTP work through the firewall is done either using a proxy server such as the firewall toolkit's ftp-gw or by permitting incoming connections to the network at a restricted port range, and otherwise restricting incoming connections using something like « established'' screening rules. The FTP client is then modified to bind the data port to a port within that range. This entails being able to modify the FTP client application on internal hosts. In some cases, if FTP downloads are all you wish to support, you might want to consider declaring FTP a « dead protocol'' and letting you users download files via the Web instead. The user interface certainly is nicer, and it gets around the ugly callback port problem. Si vous choose the FTP-via-Web approach, your users will be unable to FTP files out, which, depending on what you are trying to accomplish, may be a problem. A different approach is to use the FTP « PASV'' option to indicate that the remote FTP server should permit the client to initiate connections. The PASV approach assumes that the FTP server on the remote system supports that operation. (See « Firewall-Friendly FTP'' [1].) Other sites prefer to build client versions of the FTP program that are linked against a SOCKS library.

5.6 How do I make Telnet work through my firewall?

Telnet is generally supported either by using an application proxy such as the firewall toolkit's tn-gw, or by simply configuring a router to permit outgoing connections using something like the « established'' screening rules. Application proxies could be in the form of a standalone proxy running on the bastion host, or in the form of a SOCKS server and a modified client.

5.7 How do I make Finger and whois work through my firewall?

Many firewall admins permit connections to the finger port from only trusted machines, which can issue finger requests in the form of: finger user@host.domain@firewall. This approach only works with the standard Unix version of finger. Controlling access to services and restricting them to specific machines is managed using either tcp_wrappers or netacl from the firewall toolkit. This approach will not work on all systems, since some finger servers do not permit user@host@host fingering. Many sites block inbound finger requests for a variety of reasons, foremost being past security bugs in the finger server (the Morris internet worm made these bugs famous) and the risk of proprietary or sensitive information being revealed in user's finger information. Dans general, however, if your users are accustomed to putting proprietary or sensitive information in their .plan files, you have a more serious security problem than just a firewall can solve.

5.8 How do I make gopher, archie, and other services work   through my firewall?

The majority of firewall administrators choose to support gopher and archie through web proxies, instead of directly. Proxies such as the firewall toolkit's http-gw convert gopher/gopher+ queries into HTML and vice versa. For supporting archie and other queries, many sites rely on Internet-based Web-to-archie servers, such as ArchiePlex. The Web's tendency to make everything on the Internet look like a web service is both a blessing and a curse. There are many new services constantly cropping up. Often they are misdesigned or are not designed with security in mind, and their designers will cheerfully tell you if you want to use them you need to let port xxx through your router. Unfortunately, not everyone can do that, and so a number of interesting new toys are difficult to use for people behind firewalls. Things like RealAudio, which require direct UDP access, are particularly egregious examples. The thing to bear in mind if you find yourself faced with one of these problems is to find out as much as you can about the security risks that the service may present, before you just allow it through. It's quite possible the service has no security implications. It's equally possible that it has undiscovered holes you could drive a truck through.

5.9 What are the issues about X11 through a firewall?

The X Windows System is a very useful system, but unfortunately has some major security flaws. Remote systems that can gain or spoof access to a workstation's X11 display can monitor keystrokes that a user enters, download copies of the contents of their windows, etc. While attempts have been made to overcome them (E.g., MIT « Magic Cookie'') it is still entirely too easy for an attacker to interfere with a user's X11 display. Most firewalls block all X11 traffic. Certains permit X11 traffic through application proxies such as the DEC CRL X11 proxy (FTP crl.dec.com). The firewall toolkit includes a proxy for X11, called x-gw, which a user can invoke via the Telnet proxy, to create a virtual X11 server on the firewall. When requests are made for an X11 connection on the virtual X11 server, the user is presented with a pop-up asking them if it is OK to allow the connection. Tandis que this is a little unaesthetic, it's entirely in keeping with the rest of X11.

5.10 How do I make RealAudio work through my firewall?

RealNetworks maintains some information about how to get RealAudio working through your firewall7. It would be unwise to faire tout changes to your firewall without understanding what the changes will do, exactly, and knowing what risks the new changes will bring with them.

5.11 How do I make my web server act as a front-end for a   database that lives on my private network?

The best way to do this is to allow very limited connectivity between your web server and your database server via a specific protocol that only supports the level of functionality you're going to use. Allowing raw SQL, or anything else where custom extractions could be performed by an attacker isn't generally a good idea. Assume that an attacker is going to be able to break into your web server, and make queries in the same way that the web server can. Est there a mechanism for extracting sensitive information that the web server doesn't need, like credit card information? Can an attacker issue an SQL sélectionner and extract your entire proprietary database? « E-commerce'' applications, like everything else, are best designed with security in mind from the ground up, instead of having security « added'' as an afterthought. Review your architecture critically, from the perspective of an attacker. Assume that the attacker knows everything about your architecture. Now ask yourself what needs to be done to steal your data, to make unauthorized changes, or to do anything else that you don't want done. You might find that you can significantly increase security without decreasing functionality by making a few design and implementation decisions. Some ideas for how to handle this:

Extract the data you need from the database on a regular basis   so you're not making queries against the full database, complete   with information that attackers will find interesting.

Greatly restrict and audit what you do allow between the web   server and database.

5.12 But my database has an integrated web server, and I want   to use that. Can't I just poke a hole in the firewall and tunnel   that port?

If your site firewall policy is sufficiently lax that you're willing to manage the risk that someone will exploit a vulnerability in your web server that will result in partial or complete exposure of your database, then there isn't much preventing you from doing this. However, in many organizations, the people who are responsible for tying the web front end to the database back end simply do not have the authority to take that responsibility. Further, if the information in the database is about people, you might find yourself guilty of breaking a number of laws if you haven't taken reasonable precautions to prevent the system from being abused. In general, this isn't a good idea. See question 5.11 for some ideas on other ways to accomplish this objective.

5.13 How Do I Make IP Multicast Work With My Firewall?

IP multicast is a means of getting IP traffic from one host to a set of hosts without using broadcasting; that is, instead of every host getting the traffic, only those that want it will get it, without each having to maintain a separate connection to the server. IP unicast is where one host talks to another, multicast is where one host talks to a set of hosts, and broadcast is where one host talks to all hosts. The public Internet has a multicast backbone (« MBone'') where users can engage in multicast traffic exchange. Common uses for the MBone are streams of IETF meetings and similar such interaction. Getting one's own network connected to the MBone will require that the upstream provider route multicast traffic to and from your network. Additionally, your internal network will have to support multicast routing. The role of the firewall in multicast routing, conceptually, is no different from its role in other traffic routing. That is, a policy that identifies which multicast groups are and aren't allowed must be defined and then a system of allowing that traffic according to policy must be devised. Great detail on how exactly to do this is beyond the scope of this document. Fortunately, RFC 2588 [4] discusses the subject in more detail. Unless your firewall product supports some means of selective multicast forwarding or you have the ability to put it in yourself, you might find forwarding multicast traffic in a way consistent with your security policy to be a bigger headache than it's worth.

by Mikael Olsson This appendix will begin at a fairly « basic'' level, so even if the first points seem childishly self-evident to you, you might still learn something from skipping ahead to something later in the text.

6.1 What is a port?

A « port'' is « virtual slot'' in your TCP and UDP stack that is used to map a connection between two hosts, and also between the TCP/UDP layer and the actual applications running on the hosts. They are numbered 0-65535, with the range 0-1023 being marked as « reserved'' or « privlileged'', and the rest (1024-65535) as « dynamic'' or « unprivileged''. There are basically two uses for ports:

« Listening'' on a port. This is used by server applications waiting for users to connect, to   get to some « well known service'', for instance HTTP (TCP port 80),   Telnet (TCP port 23), DNS (UDP and sometimes TCP port 53).

Opening a « dynamic'' port. Both sides of a TCP connection need to be identified by IP addresses   and port numbers. Hence, when you want to « connect'' to a server   process, your end of the communications channel also needs a « port''.   This is done by choosing a port above 1024 on your machine that is   not currently in use by another communications channel, and using it   as the « sender'' in the new connection.

Dynamic ports may also be used as « listening'' ports in some applications, most notably FTP. Ports in the range 0-1023 are almost always server ports. Ports in the range 1024-65535 are usually dynamic ports (i.e., opened dynamically when you connect to a server port). cependant, tout port may be used as a server port, and tout port may be used as an « outgoing'' port. So, to sum it up, here's what happens in a basic connection:

At some point in time, a server application on host 1.2.3.4   decides to « listen'' at port 80 (HTTP) for new connections.

You (5.6.7.8) want to surf to 1.2.3.4, port 80, and your browser   issues a connect call to it.

The connect call, realising that it doesn't yet have local port   number, goes hunting for one. The local port number is necessary   since when the replies come back some time in the future, your   TCP/IP stack will have to know to what application to pass the   reply. It does this by remembering what application uses which local   port number. (This is grossly simplified, no flames from   programmers, please.)

Your TCP stack finds an unused dynamic port, usually somewhere   above 1024. Let's assume that it finds 1029.

Your first packet is then sent, from your local IP, 5.6.7.8,   port 1029, to 1.2.3.4, port 80.

The server responds with a packet from 1.2.3.4, port 80, to you,   5.6.7.8, port 1029.

This procedure is actually longer than this, read on for a more   in-depth explanation of TCP connect sequences.

6.2 How do I know which application uses what port?

There are several lists outlining the « reserved'' and « well known'' ports, as well as « commonly used'' ports, and the best one is: ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers. For those of you still reading RFC 1700 to find out what port number does what, STOP DOING IT. It is horribly out of date, and it won't be less so tomorrow. Now, as for trusting this information: These lists do not, in any way, constitute any kind of holy bible on which ports do what. Wait, let me rephrase that: THERE IS NO WAY OF RELIABLY DETERMINING WHAT PORT DOES WHAT SIMPLY BY LOOKING IN A LIST.

6.3 What are LISTENING ports?

Suppose you did « netstat -a'' on your machine and ports 1025 and 1030 showed up as LISTENing. What do they do? Right, let's take a look in the assigned port numbers list.

blackjack 1025/tcp network blackjack     iad1 1030/tcp BBN IAD

Wait, what's happening? Has my workstation stolen my VISA number and decided to go play blackjack with some rogue server on the internet? And what's that software that BBN has installed? This is NOT where you start panicking and send mail to the firewalls list. In fact, this question has been asked maybe a dozen times during the past six months, and every time it's been answered. Not that THAT keeps people from asking the same question again. If you are asking this question, you are most likely using a windows boîte. The ports you are seeing are (most likely) two listening ports that the RPC subsystem opens when it starts up. This is an example of where dynamicly assigned ports may be used by server processes. Applications using RPC will later on connect to port 135 (the netbios « portmapper'') to query where to find some RPC service, and get an answer back saying that that particular service may be contacted on port 1025. Now, how do we know this, since there's no « list'' describing these ports? Simple: There's no substitute for experience. And using the mailing list search engines also helps a hell of a lot.

6.4 How do I determine what service the port is for?

Since it is impossible to learn what port does what by looking in a list, how do i do it? The old hands-on way of doing it is by shutting down nearly every service/daemon running on your machine, doing netstat -a et taking note of what ports are open. There shouldn't be very many listening ones. Then you start turning all the services on, one by one, and take note of what new ports show up in your netstat output. Another way, that needs more guess work, is simply telnetting to the ports and see what comes out. If nothing comes out, try typing some gibberish and slamming Enter a few times, and see if something turns up. If you get binary garble, or nothing at all, this obviously won't T'aider. :-) However, this will only tell you what listening ports are used. Il won't tell you about dynamically opened ports that may be opened later on by these applications. There are a few applications that might help you track down the ports utilisé. On Unix systems, there's a nice utility called lsof ça arrive preinstalled on many systems. It will show you all open port numbers and the names of the applications that are using them. Ça signifie that it might show you a lot of locally opened files aswell as TCP/IP sockets. Read the help text. :-) On windows systems, nothing comes preinstalled to assist you in this task. (What's new?) There's a utility called « Inzider'' which installs itself inside the windows sockets layer and dynamically remembers which process opens which port. The drawback of this approach is that it can't tell you what ports were opened before inzider started, but it's the best that you'll get on windows (to my knowledge). http://ntsecurity.nu/toolbox/inzider/.

6.5 What ports are safe to pass through a firewall?

ALL. No, wait, NONE. No, wait, uuhhh… I've heard that all ports above 1024 are safe since they're only dynamic?? Pas vraiment. You CANNOT tell what ports are safe simply by looking at its number, simply because that is really all it is. A number. Vous can't mount an attack through a 16-bit number. The security of a « port'' depends on what application you'll reach through that port. A common misconception is that ports 25 (SMTP) and 80 (HTTP) are safe to pass through a firewall. *meep* WRONG. Just because everyone is doing it doesn't mean that it is safe. Again, the security of a port depends on what application you'll reach through that port. If you're running a well-written web server, that is designed from the ground up to be secure, you can probably feel reasonably assured that it's safe to let outside people access it through port 80. Otherwise, you CAN'T. The problem here is not in the network layer. It's in how the application processes the data that it receives. This data may be received through port 80, port 666, a serial line, floppy or through singing telegram. If the application is not safe, it does not matter how the data gets to it. The application data is where the real danger lies. If you are interested in the security of your application, go s'abonner à bugtraq8or or try searching their archives. This is more of an application security issue rather than a firewall security issue. One could argue that a firewall should stop all possible attacks, but with the number of new network protocols, NOT designed with security in mind, and networked applications, neither designed with security in mind, it becomes impossible for a firewall to protect against all data-driven attacks.

6.6 The behavior of FTP

Or, « Why do I have to open all ports above 1024 to my FTP server?'' FTP doesn't really look a whole lot like other applications from a networking perspective. It keeps one listening port, port 21, which users connect to. All it does is let people log on, and establish ANOTHER connection to do actual data transfers. This second connection is usually on some port above 1024. There are two modes, « active'' (normal) and « passive'' mode. Ce word describes the server's behaviour. In active mode, the client (5.6.7.8) connects to port 21 on the server (1.2.3.4) and logs on. When file transfers are due, the client allocates a dynamic port above 1024, informs the server about which port it opened, and then the server opens a new connection to that port. This is the « active'' role of the server: it actively establishes new connections to the client. In passive mode, the connection to port 21 is the same. When file transfers are due, the SERVER allocates a dynamic port above 1024, informs the client about which port it opened, and then the CLIENT opens a new connection to that port. This is the « passive'' role of the server: it waits for the client to establish the second (data) lien. If your firewall doesn't inspect the application data of the FTP command connection, it won't know that it needs to dynamically open new ports above 1024. On a side note: The traditional behaviour of FTP servers in active mode is to establish the data session FROM port 20, and to the dynamic port on the client. FTP servers are steering away from this behaviour somewhat due to the need to run as « root'' on unix systems in order to be able to allocate ports below 1024. Running as « root'' is not good for security, since if there's a bug in the software, the attacker would be able to compromise the entire machine. The same goes for running as « Administrator'' or « SYSTEM'' (« LocalSystem'') on NT machines, although the low port problem does not apply on NT. To sum it up, if your firewall understands FTP, it'll be able to handle the data connections by itself, and you won't have to worry about ports above 1024. If it does NOT, there are four issues that you need to address:

Firewalling an FTP server in active mode You need to let your server open new connections to the outside   world on ports 1024 and above

Firewalling an FTP server in passive mode You need to let the outside world connect to ports 1024 and above on   your server. CAUTION!!!! There may be applications running on some   of these ports that you do NOT want outside people using. Disallow   access to these ports before allowing access to the 1024-65535 port   range.

Firewalling FTP clients in active mode You need to let the outside world connect to ports 1024 and above on   your clients. CAUTION!!!! There may be applications running on some   of these ports that you do NOT want outside people using. Disallow   access to these ports before allowing access to the 1024-65535 port   range.

Firewalling FTP clients in passive mode You need to let your clients open new connections to the outside   world on ports 1024 and above.

Again, if your firewall understands FTP, none of the four points above apply to you. Let the firewall do the job for you.

6.7 What software uses what FTP mode?

It is up to the client to decide what mode to use; the default mode when a new connection is opened is « active mode''. Most FTP clients come preconfigured to use active mode, but provide an option to use « passive'' (« PASV'') mode. An exception is the windows command line FTP client which only operates in active mode. Web Browsers generally use passive mode when connecting via FTP, with a weird exception: MSIE 5 will use active FTP when FTP:ing in « File Explorer'' mode and passive FTP when FTP:ing in « Web Page'' mode. There is no reason whatsoever for this behaviour; je suppose que someone in Redmond with no knowledge of FTP decided that « Of course we'll use active mode when we're in file explorer mode, since that looks more active than a web page''. Go figure.

6.8 Is my firewall trying to connect outside?

My firewall logs are telling me that my web server is trying to connect from port 80 to ports above 1024 on the outside. Quel est this?! If you are seeing dropped packets from port 80 on your web server (or from port 25 on your mail server) to high ports on the outside, they usually DO NOT mean that your web server is trying to connect somewhere. They are the result of the firewall timing out a connection, and seeing the server retransmitting old responses (or trying to close the connection) to the client. TCP connections always involve packets traveling in BOTH directions in the connection. If you are able to see the TCP flags in the dropped packets, you'll see that the ACK flag is set but not the SYN flag, meaning that this is actually not a new connection forming, but rather a response of a previously formed connection. Read point 8 below for an in-depth explanation of what happens when TCP connections are formed (and closed)

6.9 The anatomy of a TCP connection

TCP is equipped with 6 « flags'', which may be ON or OFF. These flags sont:

FIN « Controlled'' connection close

SYN Open new connection

RST « Immediate'' connection close

PSH Instruct receiver host to push the data up to the   application rather than just queue it

ACK « Acknowledge'' a previous packet

URG « Urgent'' data which needs to be processed immediately

In this example, your client is 5.6.7.8, and the port assigned to you dynamically is 1049. The server is 1.2.3.4, port 80. You begin the connection attempt:

5.6.7.8:1049 -> 1.2.3.4:80 SYN=ON The server receives this packet and understands that someone wants to form a new connection. A response is sent:

1.2.3.4:80 -> 5.6.7.8:1049 SYN=ON ACK=ON The client receives the response, and informs that the response is received

5.6.7.8:1049 -> 1.2.3.4:80 ACK=ON Here, the connection is opened. This is called a three-way handshake. Its purpose is to verify to BOTH hosts that they have a working connection between them. The internet being what it is, unreliable and flooded, there are provisions to compensate for packet loss. If the client sends out the initial SYN without receiving a SYN+ACK within a few seconds, it'll resend the SYN. If the server sends out the SYN+ACK without receiving an ACK in a few seconds, it'll resend the SYN+ACK packet. The latter is actually the reason that SYN flooding works so well. Si you send out SYN packets from lots of different ports, this will tie up a lot of resources on the server. If you also refuse to respond to the returned SYN+ACK packets, the server will KEEP these connections for a long time, resending the SYN+ACK packets. Some servers will not accept new connections while there are enough connections currently forming; this is why SYN flooding works. All packets transmitted in either direction after the three-way handshake will have the ACK bit set. Stateless packet filters make use of this in the so called « established'' filters: They will only let packets through that have the ACK bit set. This way, no packet may pass through in a certain direction that could form a new connection. Typically, you don't allow outside hosts to open new connections to inside hosts by requiring the ACK bit set on these packets. When the time has come to close the connection, there are two ways of doing it: Using the FIN flag, or using the RST flag. Using FIN flags, both implementations are required to send out FIN flags to indicate that they want to close the connection, and then send out acknowledgements to these FINs, indicating that they understood that the other end wants to close the connection. When sending out RST's, the connection is closed forcefully, and you don't really get an indication of whether the other end understood your reset order, or that it has in fact received all data that you sent to it. The FIN way of closing the connection also exposes you to a denial-of-service situation, since the TCP stack needs to remember the closed connection for a fairly long time, in case the other end hasn't received one of the FIN packets. If sufficiently many connections are opened and closed, you may end up having « closed'' connections in all your connection slots. This way, you wouldn't be able to dynamically allocate more connections, seeing that they're all used. Different OSes handle this situation différemment. We feel this topic is too sensitive to address in a FAQ, however, an independently maintained list (no warranty or recommendations are implied) can be found en ligne.9

Abuse of Privilege When a user performs an action that they   should not have, according to organizational policy or law.

Access Control Lists Rules for packet filters (typically   routers) that define which packets to pass and which to block.

Access Router A router that connects your network to the   external Internet. Typically, this is your first line of defense   against attackers from the outside Internet. By enabling access   control lists on this router, you'll be able to provide a level of   protection for all of the hosts « behind'' that router, effectively   making that network a DMZ instead of an unprotected external LAN.

Application-Layer Firewall A firewall system in which service   is provided by processes that maintain complete TCP connection state   and sequencing. Application layer firewalls often re-address traffic   so that outgoing traffic appears to have originated from the   firewall, rather than the internal host.

Authentification The process of determining the identity of a   user that is attempting to access a system.

Authentication Token A portable device used for authenticating   a user. Authentication tokens operate by challenge/response,   time-based code sequences, or other techniques. This may include   paper-based lists of one-time passwords.

Autorisation The process of determining what types of   activities are permitted. Usually, authorization is in the context   of authentication: once you have authenticated a user, they may be   authorized different types of access or activity.

Bastion Host A system that has been hardened to resist attack,   and which is installed on a network in such a way that it is   expected to potentially come under attack. Bastion hosts are often   components of firewalls, or may be « outside'' web servers or public   access systems. Generally, a bastion host is running some form of   general purpose operating system (e.g., Unix, VMS, NT, etc.) rather   than a ROM-based or firmware operating system.

Challenge/Response An authentication technique whereby a   server sends an unpredictable challenge to the user, who computes a   response using some form of authentication token.

Chroot A technique under Unix whereby a process is permanently   restricted to an isolated subset of the filesystem.

Cryptographic Checksum A one-way function applied to a file to   produce a unique « fingerprint'' of the file for later reference.   Checksum systems are a primary means of detecting filesystem   tampering on Unix.

Data Driven Attack A form of attack in which the attack is   encoded in innocuous-seeming data which is executed by a user or   other software to implement an attack. In the case of firewalls, a   data driven attack is a concern since it may get through the   firewall in data form and launch an attack against a system behind   the firewall.

Defense in Depth The security approach whereby each system on   the network is secured to the greatest possible degree. May be used   in conjunction with firewalls.

DNS spoofing Assuming the DNS name of another system by either   corrupting the name service cache of a victim system, or by   compromising a domain name server for a valid domain.

Dual Homed Gateway A dual homed gateway is a system that has   two or more network interfaces, each of which is connected to a   different network. In firewall configurations, a dual homed gateway   usually acts to block or filter some or all of the traffic trying to   pass between the networks.

Encrypting Router see Tunneling Router and Virtual Network   Perimeter.

Pare-feu A system or combination of systems that enforces a   boundary between two or more networks.

Host-based Security The technique of securing an individual   system from attack. Host based security is operating system and   version dependent.

Insider Attack An attack originating from inside a protected   network.

Intrusion Detection Detection of break-ins or break-in   attempts either manually or via software expert systems that operate   on logs or other information available on the network.

IP Spoofing An attack whereby a system attempts to illicitly   impersonate another system by using its IP network address.

IP Splicing / Hijacking An attack whereby an active,   established, session is intercepted and co-opted by the attacker. IP   Splicing attacks may occur after an authentication has been made,   permitting the attacker to assume the role of an already authorized   utilisateur. Primary protections against IP Splicing rely on encryption at   the session or network layer.

Least Privilege Designing operational aspects of a system to   operate with a minimum amount of system privilege. This reduces the   authorization level at which various actions are performed and   decreases the chance that a process or user with high privileges may   be caused to perform unauthorized activity resulting in a security   breach.

Enregistrement The process of storing information about events that   occurred on the firewall or network.

Log Retention How long audit logs are retained and maintained.

Log Processing How audit logs are processed, searched for key   events, or summarized.

Network-Layer Firewall A firewall in which traffic is examined   at the network protocol packet layer.

Perimeter-based Security The technique of securing a network   by controlling access to all entry and exit points of the network.

Politique Organization-level rules governing acceptable use of   computing resources, security practices, and operational procedures.

Proxy A software agent that acts on behalf of a user. Typical   proxies accept a connection from a user, make a decision as to   whether or not the user or client IP address is permitted to use the   proxy, perhaps does additional authentication, and then completes a   connection on behalf of the user to a remote destination.

Screened Host A host on a network behind a screening router.   The degree to which a screened host may be accessed depends on the   screening rules in the router.

Screened Subnet A subnet behind a screening router. The degree   to which the subnet may be accessed depends on the screening rules   in the router.

Screening Router A router configured to permit or deny traffic   based on a set of permission rules installed by the administrator.

Session Stealing See IP Splicing.

Trojan Horse A software entity that appears to do something   normal but which, in fact, contains a trapdoor or attack program.

Tunneling Router A router or system capable of routing traffic   by encrypting it and encapsulating it for transmission across an   untrusted network, for eventual de-encapsulation and decryption.

Social Engineering An attack based on deceiving users or   administrators at the target site. Social engineering attacks are   typically carried out by telephoning users or operators and   pretending to be an authorized user, to attempt to gain illicit   access to systems.

Virtual Network Perimeter A network that appears to be a   single protected network behind firewalls, which actually   encompasses encrypted virtual links over untrusted networks.

Virus A replicating code segment that attaches itself to a   program or data file. Viruses might or might not not contain attack   programs or trapdoors. Unfortunately, many have taken to calling tout malicious code a « virus''. If you mean « trojan horse'' or   « worm'', say « trojan horse'' or « worm''.

Worm A standalone program that, when run, copies itself from   one host to another, and then runs itself on each newly infected   host. The widely reported « Internet Virus'' of 1988 was not a virus   at all, but actually a worm.

Notes de bas de page

… Système1 http://mail-abuse.org/

… Initiative2 http://mail-abuse.org/tsi/

… Squid3 http://squid.nlanr.net/

… Apache4 http://www.apache.org/docs/mod/mod_proxy.html

… Proxy5 http://home.netscape.com/proxy/v3.5/index.html

… Netscape6

http://developer.netscape.com/docs/manuals/security/sslin/contents.htm

… firewall7 http://www.real.com/firewall/

… bugtraq8 http://www.securityfocus.com

… en ligne.9 http://www.thegild.com/firewall/.

paul@compuwar.net

Click to rate this post! [Total: 0 Average: 0]