Les expressions régilières utilisées par le projet Layer7 sont beaucoup trop faciles à contourner : le filtre layer7 ne vérifie que la présence de données applicatives correspondant à une regexp dans l'ensemble des données.
Il n'y a pas de notion de "contexte" applicatif !
Par exemple pour HTTP, il faudrait vérifier :
- que les commandes sont dans la liste des commandes reconnus en HTTP d'après la RFC (GET, POST, HEAD, OPTIONS...)
- qu'après une commande valide, on doit avoir un URL ou non (pas après HEAD par exemple, mais obligatoire après GET...)
- qu'une URL a une syntaxe valide...
Enfin voila pourquoi, le projet Layer7 n'atteint pas aujourd'hui la qualité et la pertinence des firewalls applicatifs "industriels".
Layer7 peut être bien pour faire de la QoS (avec tc) car se tromper sur de l'analyse de protocole n'est pas "trop" génant, pas contre pour faire du filtrage, c'est trop facile à mettre en échec avec quelques outils simples.
C'est d'ailleurs pour cela que les devs principaux du projet PF (packet filter d'OpenBSD) ont toujours refusés d'ajouter ce genre de fonction à PF : pas sûr si ça n'utilise que des regexp.
[^] # Re: Protocoles supportés par L7-filter
Posté par Foxy (site web personnel) . En réponse au journal iptables, un futur firewall applicatif ?. Évalué à 3.
Les expressions régilières utilisées par le projet Layer7 sont beaucoup trop faciles à contourner : le filtre layer7 ne vérifie que la présence de données applicatives correspondant à une regexp dans l'ensemble des données.
Il n'y a pas de notion de "contexte" applicatif !
Par exemple pour HTTP, il faudrait vérifier :
- que les commandes sont dans la liste des commandes reconnus en HTTP d'après la RFC (GET, POST, HEAD, OPTIONS...)
- qu'après une commande valide, on doit avoir un URL ou non (pas après HEAD par exemple, mais obligatoire après GET...)
- qu'une URL a une syntaxe valide...
Enfin voila pourquoi, le projet Layer7 n'atteint pas aujourd'hui la qualité et la pertinence des firewalls applicatifs "industriels".
Layer7 peut être bien pour faire de la QoS (avec tc) car se tromper sur de l'analyse de protocole n'est pas "trop" génant, pas contre pour faire du filtrage, c'est trop facile à mettre en échec avec quelques outils simples.
C'est d'ailleurs pour cela que les devs principaux du projet PF (packet filter d'OpenBSD) ont toujours refusés d'ajouter ce genre de fonction à PF : pas sûr si ça n'utilise que des regexp.