Si les techniques de filtrages mises en oeuvre dans les routeurs d’accès peuvent s’avérer un outil de sécurité indispensable, ces mécanismes souffrent toutefois de limitations et de contraintes particulières :
· Si les ACLs sont longues et complexes, il peut en résulter une baisse notable de performances du fait du...
balayage des règles de filtrage pour tous les paquets reçus, · L’interface d’administration de tels mécanismes, même s’il existe désormais des interfaces graphiques à ces systèmes, se révèle bien souvent assez lourde à l’emploi et peu ergonomique,
· Le contenu protocolaire n’est pas traité par ces règles : un routeur filtrant ne saura pas détecter qu’un segment TCP à destination du port 25 n’est pas du SMTP mais, par exemple, du HTTP puisque seul le port de service est reconnu, pas le protocole qui l’utilise,
· Il n’existe pas de notion de « contexte de session », qui permettrait de rejeter un paquet à priori valide éventuellement injecté dans un flot de communication entre deux machines par un pirate, ou qui permettrait d’identifier une session TCP en tant que telle. Le filtrage est ici réalisé paquet par paquet, indépendamment de la communication en elle-même.
· Ce type de filtrage nécessite que l’on connaisse précisément les ports de services TCP qui seront utilisés entre les machines, or certains protocoles fonctionnent sur un mécanisme d’allocation dynamique des ports (cas de H323 par exemple qui écoute sur un numéro de port précis, mais qui négocie les ports TCP des communications ultérieures)
· Dans les situations où l’on dispose de nombreuses règles de filtrage, il devient impératif de bien les
organiser. Il se peut en effet qu’une règle sensée interdire un service soit sans effet, si une règle précédente, plus générale, a déjà autorisée le service et ce en raison du mécanisme de « first
match »
· Si les ACLs sont longues et complexes, il peut en résulter une baisse notable de performances du fait du...
balayage des règles de filtrage pour tous les paquets reçus, · L’interface d’administration de tels mécanismes, même s’il existe désormais des interfaces graphiques à ces systèmes, se révèle bien souvent assez lourde à l’emploi et peu ergonomique,
· Le contenu protocolaire n’est pas traité par ces règles : un routeur filtrant ne saura pas détecter qu’un segment TCP à destination du port 25 n’est pas du SMTP mais, par exemple, du HTTP puisque seul le port de service est reconnu, pas le protocole qui l’utilise,
· Il n’existe pas de notion de « contexte de session », qui permettrait de rejeter un paquet à priori valide éventuellement injecté dans un flot de communication entre deux machines par un pirate, ou qui permettrait d’identifier une session TCP en tant que telle. Le filtrage est ici réalisé paquet par paquet, indépendamment de la communication en elle-même.
· Ce type de filtrage nécessite que l’on connaisse précisément les ports de services TCP qui seront utilisés entre les machines, or certains protocoles fonctionnent sur un mécanisme d’allocation dynamique des ports (cas de H323 par exemple qui écoute sur un numéro de port précis, mais qui négocie les ports TCP des communications ultérieures)
· Dans les situations où l’on dispose de nombreuses règles de filtrage, il devient impératif de bien les
organiser. Il se peut en effet qu’une règle sensée interdire un service soit sans effet, si une règle précédente, plus générale, a déjà autorisée le service et ce en raison du mécanisme de « first
match »
0 com:
Enregistrer un commentaire
Suggérer des améliorations à apporter au blog, des articles, des commentaires ou des liens sur la sécurité informatique.Merci