Vidéos (très) lentes.
-
Bonjour à tous,
Contexte : Installation PFsense sur un serveur de type 385DL. Dernière version à jour.
Besoin : Firewall avec Suricata et PFBlockerNG. Pour l’instant pas de Squid ni de Squidguard.
Schéma :
WAN (modem/routeur/box) : 1 modem fibre OBS IP publique aucune NAT connexion WAN fixe en IPV4.
LAN : 1 seul LAN en /24 IP fixe pour rester dans une configuration simple à maintenir.
DMZ : Aucune (pour l’instant).WIFI : Aucun.
Autres interfaces : Néant
Règles NAT : Tout par défaut (pour l’instant dans l’attente éventuellement d’un serveur de messagerie).Règles Firewall : Tout par défaut.
Packages ajoutés : Shellcmd.
Autres fonctions assignées au pfSense : Aucune. Précision il n’y a aucun shaping de paramétré.
Question : Tout fonctionne très bien et personne ne se plaignait jusqu’au moment où ils ont rattaché un service communication et marketing (2 personnes). C’est le début de mes ennuis… Ce service est très gourmand en supports lourds et notamment par des vidéos en provenance du WAN sous forme de streaming. Il n’y a aucun distinguo entre un streaming encapsulé dans un lecteur flash ou que ce soit du HTML5 les problèmes sont identiques. Les supports sont propriétaires il ne s’agit pas de regarder la TV ou des divertissements via Youtube et cie, mais j’ai constaté les mêmes symptômes sur Youtube, Dailymotion, etc…
De façon aléatoire, les pages web se chargent avec un lecteur plus ou moins fonctionnel ne permettant parfois pas de démarrer la lecture même en rafraichissant les pages.
Le plus fréquent et le plus ennuyeux c’est qu’une fois la vidéo commencée il ne faut surtout pas vouloir l’avancer ou la reculer. Toute action sur la time line provoque une pause très longue comme si on attendait le téléchargement complet du support et parfois ça ne redémarre jamais. En clair les vidéos sont instables alors que tout le reste du trafic est impeccable il n'y a pas de surcharge du réseau et la bande passante est loin d'être intégralement consommée (mesures locales et outils support OBS).Je n’explique pas cette situation avec un lien SDSL de 20 megas.
Logs et tests : J’ai fouillé un peu de partout sans rien trouver de particulier mais peut-être n’ai-je pas fouillé aux bons endroits. Une suggestion serait la bienvenue. Concernant les tests de lecture de vidéos sur le net en by-pass du Pfsense cela fonctionne très bien (IE ou FF).
Je sèche complètement.Merci par avance pour votre aide.
-
Je n’explique pas cette situation avec un lien SDSL de 20 megas.
Avez vous examiné ce que peut consommer comme ressource un outil tel que Suricata ?
Les besoins dépendent du débit du lien à surveiller et de la nature du trafic et du nombre de règles actives. Avec de la video je ne suis pas certain que 8 Gbits de ram pour Suricata sur un lien 20 Mbits soit suffisant. Il n'est pas rare de voir des configuration avec 128 Go de ram pour Suricata.Je ne parle même pas de l' aberration que constitue le déploiement d'un ids directement sur le firewall: vous êtes en train de l'expérimenter. Vous avez la détection et l'IHM sur la même machine, ce n'est pas viable en production.
Il n'est pas impossible que la latence induite par l'IDS génère votre problème. Si on regarde le fonctionnement d'un ids et les besoins pour un visionnage fluide la la video on comprend assez vite que c'est fortement consommateur.
Vous n'expliquez rien de la configuration de Suricata (coupure, dérivation, règles, signatures recherchées, stockage des logs, …)
en by-pass du Pfsense cela fonctionne très bien (IE ou FF).
Et en bypass de Suricata ?
-
Merci pour ce retour très rapide.
Ne sachant plus trop par où attraper le problème, je vais donc apporter quelques informations complémentaires.
Il s'agit d'une PME de 23 salariés dont seulement 16 ont accès au WAN. J'ai repris le contrat depuis seulement 1 mois et pas mal de choses sont à revoir comme d'habitude dans un budget serré.
Ayant remarqué que la sécurité avait été un peu mise de côté car il y avait bien un serveur "mourant" qui faisait office de firewall avec une distribution de Pfsense installée pas vraiment up to date :( j'ai eu la possibilité de remplacer la machine d'origine en doublant les capacités. Donc aujourd'hui il y a un vrai serveur bi Xeon avec 32 GB de RAM 4 NIC 1000 base T RAID 10 et une distribution Pfsense à jour ce qui est en soit une petite révolution.
Avez vous examiné ce que peut consommer comme ressource un outil tel que Suricata ?
Les besoins dépendent du débit du lien à surveiller et de la nature du trafic et du nombre de règles actives. Avec de la video je ne suis pas certain que 8 Gbits de ram pour Suricata sur un lien 20 Mbits soit suffisant. Il n'est pas rare de voir des configuration avec 128 Go de ram pour Suricata.Effectivement ce problème a été vu au départ et je ne décèle pas d'anomalie de fonctionnement de Suricata ou de ralentissement.
Ni dans les logs, ni côté hardware.Je ne parle même pas de l' aberration que constitue le déploiement d'un ids directement sur le firewall: vous êtes en train de l'expérimenter. Vous avez la détection et l'IHM sur la même machine, ce n'est pas viable en production.
Il n'y a pas de budget pour implémenter une seconde lame, je dois jongler entre le cahier des charges et la trésorerie. Comme très souvent les bests practices sont mises de côté, mais on essaie de faire au mieux ;)
Il n'est pas impossible que la latence induite par l'IDS génère votre problème. Si on regarde le fonctionnement d'un ids et les besoins pour un visionnage fluide la la video on comprend assez vite que c'est fortement consommateur.
J'ai désinstallé Suricata pour effectuer des tests. Aucune différence le problème reste identique même sans IDS.
Vous n'expliquez rien de la configuration de Suricata (coupure, dérivation, règles, signatures recherchées, stockage des logs, …)
Plutôt que de faire un pavé énorme, je pourrai poster des screens dans la soirée. Mais on est dans une configuration "basique".
Et en bypass de Suricata ?
Je voulais dire un by-pass de la lame complète, on ignore complètement la machine Pfsense.
C'est une bidouille sale puisque le PC de test se connecte directement sur l'IP publique sans intermédiaire.Bilan des consommations constatées :
- RAM : entre 8 et 17% Je n'ai jamais réussi à consommer plus (tant mieux parce que le client voudrait faire du filtrage web, mais là je laisse un peu trainer et vous savez pourquoi…)
- CPU : Entre 0 et 6% Un record à 23% a été établi lors de l'installation de packages qui a duré 5 minutes. Jamais reproduit en production.
- RAID : 1 au départ, pensant que les disques saturaient j'ai basculé en RAID 10 en multipliant par 4 la vitesse d'écriture (aucun effet).
- WAN : 30% consommé (mesuré par OBS) pics à 45% mais qui correspondent à des sauvegardes nocturnes ou du Windows Update, mais pas à des utilisateurs en streaming.
Information : C'est uniquement le streaming qui pose problème et surtout la navigation dans une vidéo car si je télécharge le fichier swf ou mp4 le débit est excellent (autour des 2,2 Mo/s).
-
Quand je regarde la configuration hardware de ton pfSense, je trouve cela absolument énorme si on considère que ton accès web, c'est seulement du 20 Mb/s.
Un simple PCEngines à 150 € (si on exclu bien sûr tous les add-ons que tu pourrais ajouter) ferait tout aussi bien en terme de performance.- Comme tu le fais remarquer, ta consommation CPU et mémoire sont très faibles.
- dans un mode "FW" uniquement, il n'y a pratiquement pas d'I/O. Que ton disque soit en RAID 1 ou RAID 10 ne change strictement rien
- et, pour compléter le tableau, je pense que la mise en œuvre de Suricata est un peu prématurée. Le principe même de l'IDS nécessite d'y consacrer des ressources (et pas que du hardware, il faut également y passer pas mal de temps).
Comme le dit ccnet, l'IDS ne nécessite pas d'être "en ligne" sur le flux réseau. Ce peut être une machine à part.
Pour l'IPS, c'est plus simple si celui-ci tourne sur le FW, mais là n'est pas la question.J'ai l'impression que ta démarche pour résoudre ce problème est un peu empirique et je crains fort que tu y passes beaucoup de temps (et d'argent) avant de trouver une solution. Ajouter du hardware, CPU, disque, mémoire etc… ne te sert à rien tant que tu n'as pas identifié quel est l'élément limitant.
En fonction de ton navigateur, il y a différents outils qui te permettent de voir comment se décompose le temps de réponse. A partir de là, tu pourras identifier plus facilement quel est l'élément sur lequel il faut travailler en priorité. Mais sauf problème au niveau de tes interfaces réseau de la machine pfSense, il est évident qu'avec un débit de 20 Mb/s, ce n'est pas le hardware.
Autre point annexe: avec ce hardware et uniquement une vingtaine d'utilisateurs, mettre en place un proxy HTTP, même sur le hardware que tu décris, ne pose aucun problème de performance.
-
Quand je regarde la configuration hardware de ton pfSense, je trouve cela absolument énorme si on considère que ton accès web, c'est seulement du 20 Mb/s.
Un simple PCEngines à 150 € (si on exclu bien sûr tous les add-ons que tu pourrais ajouter) ferait tout aussi bien en terme de performance.Tout à fait d'accord, sans vouloir entrer dans ce débat qui ne résoudra pas le problème et en résumant (trop) traiter un client pro avec un "simple" PC risque de donner une très mauvaise image… Mais pas seulement c'est trop résumé.
Bref, le Hardware mis en place est lié à un accord que j'ai avec HP et pour l'instant les 150€ de pièces ne sont pas encore atteint.- dans un mode "FW" uniquement, il n'y a pratiquement pas d'I/O. Que ton disque soit en RAID 1 ou RAID 10 ne change strictement rien
Oui j'avais juste un doute puisque c'est le seul élément non monitoré.
Le principe même de l'IDS nécessite d'y consacrer des ressources (et pas que du hardware, il faut également y passer pas mal de temps).
Ca pour y passer du temps, j'en passe ;)
Comme le dit ccnet, l'IDS ne nécessite pas d'être "en ligne" sur le flux réseau. Ce peut être une machine à part.
Ca je le sais j'ai préconisé cette éventualité au client, mais pour des raisons de coût de fonctionnement et de maintenance on me l'a refusé. De plus comme dit plus haut la machine est sur sur dimensionnée ce qui colle bien avec cette politique de ces dernières années où l'on met le moins de machine possible avec des configurations gigantesques pour virtualiser tout et n'importe quoi…
Ajouter du hardware, CPU, disque, mémoire etc… ne te sert à rien tant que tu n'as pas identifié quel est l'élément limitant.
Ce n'est pas tout à fait ça. A part le RAID qui est passé de 1 à 10 le reste n'a pas été modifié. Il y avait un serveur IBM en fin de vie qu'il fallait remplacer au risque de le voir tomber en panne à tout instant. J'ai déjà perdu un temps fou avec les caprices de ce tromblon…
Et justement j'ai épluché les logs, provoqué des streamings en masse pour saturer le LAN, le WAN et Pfsense mais rien trouvé d'anormal.
C'est l'absence d'anomalie visible qui me pose un problème donc je viens chercher des avis ici ;)En fonction de ton navigateur, il y a différents outils qui te permettent de voir comment se décompose le temps de réponse. A partir de là, tu pourras identifier plus facilement quel est l'élément sur lequel il faut travailler en priorité. Mais sauf problème au niveau de tes interfaces réseau de la machine pfSense
Effectivement j'ai analysé ça sous Firefox… Devinez?
Rien de bizarre, j'ai des résultats presque similaire chez moi en ADSL et le WAN n'est pas en cause puisque en shuntant Pfsense c'est nickel.
Je peux changer la carte réseau du serveur, même si honnêtement je n'y crois pas trop...Autre point annexe: avec ce hardware et uniquement une vingtaine d'utilisateurs, mettre en place un proxy HTTP, même sur le hardware que tu décris, ne pose aucun problème de performance.
J'ai botté ce sujet en touche provisoirement car mettre en place Squid sur une machine qui ne donne pas une satisfaction pleine va encore plus noyer les problèmes. De plus on m'impose l'IDS donc du temps à consacrer pour ça, je vais éviter de m'éparpiller ;)
-
Un hardware tel celui là, pour une ligne de 20 Mb, est juste de la confiture …
De plus comme dit plus haut la machine est sur sur dimensionnée ce qui colle bien avec cette politique de ces dernières années où l'on met le moins de machine possible avec des configurations gigantesques pour virtualiser tout et n'importe quoi
A propos, le firewall est-il virtualisé (ce qu'il ne faut pas faire …) ?
Si c'est le cas, la perf d'un firewall virtualisé n'est pas 'déchiffrable' ...
Les facteurs, qui impactent la perf d'un firewall, sont la mémoire, le processeur, les cartes réseaux (via leur driver), la présence de packages (+ ou - bien configurés et compris), et en tout dernier le système disque. En particulier Squid est le package sans doute le plus perturbant (avec petite mémoire) ...
Il est notable que n'est pas précisé les modèles de cartes réseaux (en dehors du nombre). -
C'est peut-être de la confiture, mais entre ce que l'on met sur le papier et la réalité il existe un gouffre.
Je passe 70% du temps à faire de la pédagogie pas de l'informatique. Les installations en production datent d'une époque que beaucoup n'ont même pas connu…
Il n'empêche que c'était 65€ HT à l'achat et qu'il y a 1 an de maintenance HP avec... Les parcs sont tellement hétérogènes (clients/serveurs) que j'essaie aussi de faire en sorte d'harmoniser un peu tout ça.A mon arrivée l'ancien matériel firewall ressemblait plutôt à ça en 2016 :o
La photo n'est pas de moi, mais on s'en rapproche.
Quand même il y a des limites…Ils ont aussi 2 blades HP et 1 Dell car j'ai enfin réussi à leur faire comprendre que le DC ne devait pas (plus) être virtuel surtout sans failover.
Donc 1 HP (c'est aussi un 380 DL mais moins costaud) en DC et un autre en firewall. Le Dell fait office de serveur de fichiers, VM, etc... Je n'ai pas fini de pleurer avec celui-là.Voilà pourquoi après moult négociations et vu que l'on part de très très loin je n’insisterai pas pour implémenter un troisième appareil en IDS sachant qu'il va falloir changer le PABX par un IPBX... Et si quelqu'un a du temps à perdre j'ai encore des machines sous XP dans un domaine 2003 à migrer ;D
Donc pour répondre clairement le FW n'est pas virtuel et les cartes réseau sont des cartes Intel pro/1000 dual port server adapter. Il y en a 2 séparées j'ai testé les 4 ports c'est pareil. Les packages installés sont biens Suricata, PfBlockerNG et Shellcmd.
Pas de Squid installé (même si le client me tanne avec ça).Merci à tous pour vos participations ;)
-
Ne te méprends pas. Le point n'est pas de proposer un remplacement du hardware. Il peut y avoir tout un tas de raisons pas forcément techniques, comme tu le soulignes, pour choisir tel ou tel matériel.
Il fallait cependant écarter les risques avec les cartes réseau. Ton explication à ce sujet est assez claire.
En ce qui concerne l'IDS, même si c'est une figure imposée, il n'est pas inutile, à titre de test, et donc temporairement, de ne pas l'utiliser, au moins pour arriver à isoler la source du problème.
Ce qui m'échappe dans ton explication, c'est que, si je comprends bien, d'un coté tu dis "les temps de réponse en streaming sont mauvais" et d'un autre "lorsque je mesure, tout est normal". Ce n'est pas très clair pour moi.
Autre point qu'il ne faut pas négliger: la performance ne dépend pas que du FW ou du proxy mais également du poste client. As-tu fait différents tests à ce sujet ?
-
(La matériel sur la photo … j'ai travaillé avec ... et pfSense ne s'y installerait certainement pas : pas 386 !)
(Un biXeon avec 32G de mémoire à 95€ et avec 2 dual Pro/1000, cela parait surréaliste : de l'occasion ?)Un bi-Xeon, 32 G de mémoire, 4 ports Intel Pro : c'est très surdimensionné pour une simple SDSL 20M.
Donc si la perf n'est pas bonne, c'est nécessairement vers les package : le seul évident est Suricata (qui comme Squid n'est pas à placer sur un firewall)
Donc, si test toujours mauvais avec Suricata désinstallé et après reboot, il faut chercher ailleurs ...
NB : Le devoir d'une société de service vis à vis d'un client est aussi de lui dire que ce qu'il demande n'est pas bon ... quoi qu'il en coute ...
-
@jdh:
Donc si la perf n'est pas bonne, c'est nécessairement vers les package : le seul évident est Suricata (qui comme Squid n'est pas à placer sur un firewall)
Je suis assez intéressé à ce que tu expliques comment utiliser Suricata avec pfSense sans que Suricata tourne sur la même machine que pfSense ;)
sauf bien sûr à expliquer que, dans le principe, IPS n'est pas une bonne solution (ce qui est un autre débat, fort intéressant)- ton client a bien raison pour insister afin d'avoir un proxy: à défaut d'améliorer les choses en ce qui concerne le problème que tu décris, ça permettrait de mettre en œuvre du filtrage à mon avis bien plus efficace que pfblockerNG
- fait quand même un essai en arrêtant les packages ;-)
-
Ne te méprends pas.
Aucun risque ;)
En ce qui concerne l'IDS, même si c'est une figure imposée, il n'est pas inutile, à titre de test, et donc temporairement, de ne pas l'utiliser, au moins pour arriver à isoler la source du problème.
Fait en désactivant complètement Suricata, en le désinstallant et en utilisant une version de Pfsense from scratch sans package.
Résultat idem.Ce qui m'échappe dans ton explication, c'est que, si je comprends bien, d'un coté tu dis "les temps de réponse en streaming sont mauvais" et d'un autre "lorsque je mesure, tout est normal". Ce n'est pas très clair pour moi.
Moi aussi c'est confus parce que les vidéos ne démarrent pas de façon aléatoire ou si la lecture fonctionne il ne faut surtout pas naviguer. Je pensais à un souci avec la gateway mais quoi :-\
Autre point qu'il ne faut pas négliger: la performance ne dépend pas que du FW ou du proxy mais également du poste client. As-tu fait différents tests à ce sujet ?
Testé avec un PC de test dans la salle serveur (PC de bureautique simple mais pas obsolète) et avec mon PC perso (Machine très puissante) les résultats sont les mêmes.
@jdh:
(La matériel sur la photo … j'ai travaillé avec ... et pfSense ne s'y installerait certainement pas : pas 386 !)
La photo n'est pas celle du matériel trouvé, mais s'en rapproche. C'est juste une illustration pour faire comprendre d'où on part.
Content de savoir qu'il y a des "vieux" ici je me sens moins seul ;D@jdh:
de l'occasion ?)
Obligatoirement. Ce sont des opérations de recyclage de parc comme beaucoup de marques le proposent aujourd'hui.
Il y a des avantages et quelques inconvénients…@jdh:
il faut chercher ailleurs …
C'est bien ça, mais je ne sais plus trop par quel bout attraper le souci.
@jdh:
Le devoir d'une société de service vis à vis d'un client est aussi de lui dire que ce qu'il demande n'est pas bon … quoi qu'il en coute ...
Les clients sont informés des "bests practices" mais ils ont aussi des comptables. Donc en fonction des besoins réels il faut mettre des priorités aux chantiers et surtout les chiffrer. Tout ne se fait pas en un jour donc oui souvent on doit faire un peu moins "propre" sans pour autant faire n'importe quoi. Dans un monde virtuel on pourrait rêver que plus personne ne soit administrateur de son poste, que la sécurité des routeurs soit au top même chez les particuliers (qui travaillent comme à la maison), que les antivirus soit rangés dans un musée et que les hackers n'existent pas… Ce n'est pas pour demain :(