Bonjour,
 
Je suis en train de mettre en place une Police de sécurité, et je voudrais être sûr d'interdire les protocols les plus riskés et vulnérables aux attaques style FTP, TFTP... soient bien pris en compte.
 
Y a t'il un document qui note les protocols par risk? Existe -'il des check lists pour être sûr de ne rien oublier?
 
J'ai déjà visiter US-CERT qui dit de filtrer les protocols ci après:
DNS zone transfers : socket 53 (TCP)
tftpd : socket 69 (UDP)
link : socket 87 (TCP) (commonly used by intruders)
SunRPC & NFS : socket 111 and 2049 (UDP and TCP)
BSD UNIX "r" cmds : sockets 512, 513, and 514 (TCP)
lpd : socket 515 (TCP)
uucpd : socket 540 (TCP)
openwindows :socket 2000 (UDP and TCP)
X windows : socket 6000+ (UDP and TCP)
 
 
Petit lien du site:http://www.cert.org/tech_tips/packet_filtering.html

Autre question:
Si je souhaite autoriser un protocol dit "risqué", dois-je obligatoirement le faire inspecter niveau applicatif?
ou est-ce que le fait de restreindre son utilisation à une IP addresse permet de réduire significamment le risk d'abus (IP spoofing possible tout de même)

Que me conseillez vous?
Merci

La stratégie de base de tout firewall est : on autorise ce dont on a besoin, le reste est bloqué par défaut.
Là tu pars complètement à l'inverse, à revoir à mon avis !

 
Je compte bien appliquer cette règle, mais toutefois si j'ai besoin d'un protocol comme FTP, est ce que je dois nécessairement utliser un filtrage applicatif?? ou un filtrage réseau suffit? Qu'en est-il pour DNS?
 
C'est plus dans ce sens que je le voyais.

Je comprends pas bien ta question. Si tu veux accéder à des FTP externes, il faut autoriser le trafic sur le port 21 dans ton firewall (qu'il soit logiciel ou matériel, on s'en fiche)
Si ton but c'est d'autoriser la connexion d'utilisateurs extérieurs à un FTP interne, alors il faut ajouter une redirection NAT.
Concernant DNS, bloquer le port 53 rendra impossible la résolution de noms via des serveurs externes, donc à éviter...
Fais un inventaire de tes besoin, autorise les flux dont tu te sers, et laisse le reste fermé, c'est aussi simple que ça...

Une architecture correctement montée rend déjà bien des services, c'est à dire :
- pas de flux directs entre l'interne et l'externe
- services entrants et services sortants séparés
- services externes et services internes séparés
 
Pour FTP, je pense qu'il faut songer à le remplacer par SFTP ou WebDAV/HTTPS ou au moins mettre un proxy pour éviter les flux directs. Mais si tu laisses FTP, les mots de passe passeront en clair, même avec un filtrage applicatif.

Pour DNS, configurer le ou les serveurs externes pour faire des recherches itératives peut éviter la pollution de cache. TSIG et RSIG peuvent aider aussi.

Ben justement la question posée concerne le filtrage couche 7. En effet les politiques de sécurité telles que tu les décris, ou un port est soit ouvert soit fermé, c'est plus suffisant si on cherche une sécurité solide dans un environnement pro. Il faut filtrer les paquets avec des IPS/IDS/UTM/Deep Inspection/etc. Ceux-ci bossent avec des bases de signatures qui peuvent détecter/bloquer des attaques au niveau applicatif (attaque d'un serveur web par SQL Injection par exemple).

Bien sûr ce qui fait la qualité d'un filtrage applicatif, c'est une bonne base de signature bien à jour. Déja c'est quoi la taille de ton archi ? Tu veux protéger quoi ? Tu voudrais des appliances (firewall et IPS/IDS séparés) ou un firewall UTM tout-en-un ? Du propriétaire ou du libre ?

Ceci dit entièrement d'accord avec Shinmaki, avant de voir la couche 7, il faut rigoureusement appliquer tous les principes qu'il cite (les 3).

Si tu veux éviter l'exposition de tes services à des attaques de ce genre, un proxy inverse comme ISA Server permet de réécrire les requêtes pour les transmettre au serveur publié, ce qui annihile les tentatives d'attaques par exploit de requête mal écrites... Ensuite je m'y connais pas assez en sécu pour être catégorique m'enfin une appliance firewall IPS en entrée + un ISA en DMZ qui publie les applications comme web/messagerie/et autres me semble sécurisé.

 
Merci il s'agit bien de ce genre de filtrage dont je parlais. Les politiques de niveau 3 sont très basic (soit tout, soit rien), même si elles permettent de limiter l'accès aux services en fonction des IP utilisateurs, il y a toujours un risque de spoofing.  
 
Je sais que toute solution de firewall dépend avant tout des besoins, mais je souhaite une vision plus pragmatiques par protocols.  
Je voudrais évaluer le risque des principaux protocols à utiliser et déterminer quel filtrage est mieux adapter pour chacun des protocols.  

Mais y a t'il un document de référence pour justement déterminer les risques liés aux protocols les plus couramment utilisés?
 
Je pense pas vraiment comme tu le dis que le filtrage dépend de la taille du réseau; elle dépend surtout des services que tu proposes, et ces services en questions que je veux évaluer. Je dois évaluer en amont le cout de la sécurité pour certains autres services que la compagnie veut proposer. Ceci doit déterminer si la compagnie oui ou non va les implémenter ou passer par une entreprise tiers.
 
Merci

Une question simplifiée à mon interrogation, à partir de quel moment doit-on songer à opter pour un filtrage applicatif ?
Dans quel contexte est-ce absolumment impératif?
 
Avant de dépendre de la taille de la compagnie, ça dépends bien des services qu'elle propose et bien sûr de "l'importance des données" qu'elle stocke.
 
Merci

Je retourne la question.
Et pourquoi ne pas utiliser un filtrage applicatif en complément d'autres filtrage de couches ?  
En quoi cela pause problème ? La vitesse ? La gestion ?

Je dirais LE PRIX. Pour des petites companies, n'est-il pas préferable d'utiliser un filtrage par etat? Si il y a 10 employés, pas de resources importantes, ça suffit non??

Il y a des filtrages applicatif gratuite sous licence GPL comme l'IDS "snort".

Le prix à l'achat de ce genre de solution est nul mais pas l'implémentation et la maintenance ne s'improvise pas et coute en temps. Je ne pense pas que le profil open-source convienne pour les petites entreprises. Mais à vrai dire je n'ai pas assez d'expérience pour dire quelle solution est la mieux adaptée ou non.

J'ai une vision assez théorique de la sécurité, et malheureusement très peu pratique, et j'ai du mal à déterminer quelle solution adaptée, pour quel budget.  
 
J'ai vu les menaces TOP 20 2007 sur le site de du SANS :
http://www.sans.org/top20/?utm_sou [...] &ref=27974
 
Et ya de quoi rendre parano. Même si on ne fournit pas de services externes, il faut être vigilant aux flux externes (une station interne infecté peut être administrer à distance pour attaquer d'autres réseaux, je ne vous apprend rien >> BOTNETS) Alors FILTRAGE APPLICATIF dans ce cas???
 
Quelques personnes pourraient me convaincre de l'utilité du stateful firewall dans ce monde d'hostilité!!! N'est ce pas sa mort? Et dans quel cas l'utiliser à bon escient.
 
Merci