Serveur d'impression

Firewalls Internet: Foire aux questions – Serveur d’impression

Le 3 mai 2019 - 85 minutes de lecture

Firewalls Internet: Foire aux questions

Date: 2004/07/26 15:34:42

Révision: 10.4

Ce document disponible en Postscript.et PDF.

Sommaire




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 à
[email protected]
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:




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:

  1. Couche réseau
  2. Couche d'application
  3. 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.

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.

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.

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.

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.




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.

  1. Allow « established'' connections out via a router, if you are
      using screening routers.
  2. Use a web client that supports SOCKS, and run SOCKS on your
      bastion host.
  3. 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 [email protected]@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
[email protected]@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ème
1
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/


bugtraq
8
http://www.securityfocus.com


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


[email protected]

Commentaires

Laisser un commentaire

Votre commentaire sera révisé par les administrateurs si besoin.