Preprocesseur Http, et innondation d'alertes inhabituelles

megs

Bonjour,

PFSENSE: 2.4.4-RELEASE-p2 (amd64)
Basé sur Wed Dec 12 07:40:18 EST 2018
FreeBSD 11.2-RELEASE-p6

snort security 3.2.9.8_6

depuis fin aout, j'observe ce genre d'alerte en pagaille tout les jours. pourtant rien n'a changé dans le paramétrage SNORT. pour un seul site distant a la foi.
Faux positif?

(http_inspect) PROTOCOL-OTHER HTTP server response before client request -- 2019-09-03 23:22:02

2019-08-30
11:22:26 3 TCP Unknown Traffic 94.228.188.131
80 194.x.x.x
9580 120:18
(http_inspect) PROTOCOL-OTHER HTTP server response before client request

2019-09-04
12:38:35 3 TCP Unknown Traffic 108.128.181.18
80 194.x.x.x
20194 120:18
(http_inspect) PROTOCOL-OTHER HTTP server response before client request

gersonalves

Même problème ici. Jusqu'à présent, je n'ai rien trouvé sur le Web concernant ces alertes.

jdh

Cela n'est visiblement aucunement un problème pfSense.

Concernant les IDS (Snort est un IDS), êtes vous sûr qu'un firewall soit LE BON positionnement pour un IDS ? (ou le positionnement recommandé)

gersonalves

Eh bien, Pfsense est un outil de sécurité qui me permet de contrôler le trafic réseau via les règles de sécurité définies pour mon environnement. Snort est responsable de la surveillance du compartiment réseau, m'avertit d'éventuelles intrusions non autorisées et peut les bloquer au moment de la détection, conformément aux règles définies dans mon environnement.
Pfsense et Snort travaillent très bien ensemble :)

Tatave

Salut salut

Non ce que voulait dire jdh est qu'il serait judicieux d'attribuer cette application sur une machine à coté de pf pour de réelles raisons de sécurité aussi, sujet longtemps débattu sur la section tout comme le positionnement d'un proxy sur pf.

un pare feu routeur
un serveur sécurité avec snort,
un serveur de filtrage avec squid

Après libre a vous de tenter le diable, mais manifestement c'est pour votre cas snort qui n'est pas content, que vous dit le support snort ?

Cordialement

megs

@Tatave Nous pourrions débattre longtemps mais la réalité sécuritaire n'est pas la réalité budgetaire. or malheureusement le premier ne bouge pas sans le deuxième, on fait avec ce que l'on a. Tout le monde ne peut pas faire peur a son employeur et parfois doit répondre aux standards édicté par les procédures pompeuses prédéfinies mises en place pour permettre l’opération de diverses personnes a rotation de postes pour des infrastructures réseaux franchement incommodante et pousse au crime. Et je ne dévoilerais pas la méthode casse gueule de certaine région pour faire remonter du GLPI en externe.

Personnellement mon avis est que ça sent le faux positif... vu que je ne suis pas le seul. Ca pue la mise a jour de règles snort trops entreprenantes.

jdh

Visiblement, vous ne comprenez pas ce qu'on écrit.
J'ai attiré votre attention sur 2 points (et Tatave vous les a souligné) :

vous avez des alertes Snort : cela ne concerne en rien pfsense, allez donc voir sur un forum sur Snort !
les recommandations basiques indiquent (toutes) que le firewall N'EST PAS la bonne place pour un IDS. Quand on réfléchit 1 minute, on le comprend aisément.

Il est assez évident qu'un IDS ne doit pas être placé sur un firewall car il analysera tout le trafic y compris celui qui sera bloqué par les règles de firewall. Il accomplit donc un travail totalement inutile et génère des alertes qui n'apparaitraient pas si l'IDS était placé en deçà du firewall, ce qui est peut-être le cas des alertes citées !

1 minute de réflexion = 2 phrases simples, et on devrait comprendre.

Enfin ne parlez pas de budget : essayer de faire du snort sans le mettre en oeuvre correctement , c'est déjà biaiser l'analyse et la rendre inutile/inéfficace, à commencer par traiter des alertes qu'il ne faudrait pas traiter, ce qui est une perte de temps considérable (temps=argent).

Stop pour moi, j'ai largement dit ce qu'il y avait à dire et suffisamment argumenté.

gersonalves

Os comentários foram de grande valia. Estarei implementando o Snort em outro servidor e realizarei alguns testes no ambiente de homologação. É sempre bom poder contar com os colegas do fórum. Utilizo o Pfsense há poucos anos e não domino ainda 100% a ferramenta e sou grato a todos os colegas que aqui postam suas visões e opiniões sobre o assunto. Em relação ao post dos alertas do Snort, em pesquisas pela Web, outros companheiros também disseram ser um falso positivo

ccnet

Il n'est pas inutile de poster en français sur le forum français.
Sinon.
En termes de bonnes pratiques, le placement d'une sonde sur l'interface du firewall, sur laquelle transitent aussi, les flux métiers, les flux d'administration de Pfsense, de Snort, c'est quand très très moyen.
Au regard des bonnes pratiques de défense en profondeur, c'est aussi très moyen. Vous perdez votre firewall, vous perdez toutes vos défenses.
Ce positionnement de la sonde ne vous permettra pas de voir tout ce qui est déplacement latéral d'un attaquant. Son trafic dans ce cas ne transite pas par les interfaces de votre firewall. Pas terrible comme couverture.
Snort a des qualités indéniables. Mais aussi des défauts. Le virtual patching avec Snort c'est vraiment très lourd. Chez d'autres (certes c'est plus cher, mais çà marche) une cve = une règle.
Et souvent on besoin de règles différentes pour différents résaeux. Donc avoir de multiples segments disponibles sur l'ips c'est essentiels.

Snort est responsable de la surveillance du compartiment réseau, m'avertit d'éventuelles intrusions non autorisées ...

Il existe des intrusions autorisées ?
Après le compartiment fumeur, le compartiment réseau, puis le compartiment enfumeur ...
Je suis sévère mais vous êtes trop optimiste et trop confiant. Ce positionnement d'une sonde ne vous donne qu'une vision très partielle des événements de sécurité. Il suppose que vous privilégiez l’extérieur comme source de menaces. Ce qui ne correspond pas à la réalité. C'est très courant comme perception.

megs

Visiblement, vous ne comprenez pas ce qu'on écrit.
visiblement je ne suis pas le seul...
Il est assez évident qu'un IDS ne doit pas être placé sur un firewall car il analysera tout le trafic y compris celui qui sera bloqué par les règles de firewall.
c'est exactement ce que je recherche, voir plus bas. et au delà de l'evidence.
Il accomplit donc un travail totalement inutile et génère des alertes qui n'apparaitraient pas si l'IDS était placé en deçà du firewall, ce qui est peut-être le cas des alertes citées !
une évidence, vous ne m'apprenez rien.
1 minute de réflexion = 2 phrases simples, et on devrait comprendre.
Valable pour tout le monde apparemment...
Enfin ne parlez pas de budget : essayer de faire du snort sans le mettre en œuvre correctement , c'est déjà biaiser l'analyse et la rendre inutile/inéfficace, à commencer par traiter des alertes qu'il ne faudrait pas traiter, ce qui est une perte de temps considérable (temps=argent).
Mort de rire, pour information, snort dispose d'un suppresseur de messages selon certaines règles, si il y en avait pas besoin ça se saurait. et mon message était là pour jauger un ajout ou non. pas posté sur le bon forum..clairement. l'argent virtuel dont vous me parler n'est pas pris en compte sur le budget réel et le tenancier du porte feuille dans mon cas s'en balance. La seule perte de temps est la réponse que vous m'avez envoyé, et la mienne qui en découle.
Stop pour moi, j'ai largement dit ce qu'il y avait à dire et suffisamment argumenté.
Oui vaut mieux.

Thanks gersonalves, Merci tatave et ccnet pour vos réponses utiles... Ma PF gère deux WAN, et 4 LAN... il n'est pas meilleur position pour un seul IDS afin de les surveiller tous, et dans les logs les lier, ( ceci sans faire un VM par IDS et par LAN/WAN... pas les moyens techniques. )
Oui , j'ai fait en sorte que les règles de surveillances diffères selon que je surveille un WAN ou un LAN ( certains LAN n'ont pas forcement les mêmes règles que d'autres, d'ailleurs ces messages n'apparaissent que pour un seul interface sur les 6. )

Si je me trompe dites le moi, mais l'IDS firewall ne rend pas compte des attaques WAN lorsque qu'il n'est connecté qu'au LAN, et inversement (impossible de localiser une machine au travers du NAT,Car les logs externes affichent l'ip du FW Natté, ( et sous PF c'est assez le bordel pour faire un lien port natté/ip interne rapidement, les connexions étant fort volatiles).
J'ai des petits rigolos qui s'amusent, normal c'est une école... et c'est assez intéressant de disposer des logs sortant/intrant par interfaces afin de cibler précisément quelles machines posent problèmes et dans quel LAN.

Faire une adéquation des attaques externe en fonction du traffic interne peu révéler des choses intéressantes.
Mais oui, ca génère parfois des messages intempestifs selon les majs de règles. Mais je n’aurais jamais posé ma question si je ne le savait pas.La pluspart de ses messages sont traité dans la ignore list. selon la couverture de l'interface.

Savoir si d'autres on le même problème, permet de juger rapidement si c'est un Faux positif.

Par ailleurs, comme dit au premier message, ses alertes étaient forts soudaines et inhabituelles.. les mises a jour des règles s'opérant régulièrement ça me semblais la meilleurs option nécessitant vérification avec d'autres usagers.

CCNET:Au regard des bonnes pratiques de défense en profondeur, c'est aussi très moyen. Vous perdez votre firewall, vous perdez toutes vos défenses.

Aurais tu des textes de référence là dessus s'il te plaît ? ça m'intéresserai d'approfondir la question. merci par avance.( sinon je googlize ). Quoi qu'il en soit merci a vous.

Tatave

Salut salut

Soit vous arrivez à monter une machine avec snort avec plusieurs cartes réseaux sur vos segments avec sur chaque un blocage de tous les flux entrant sauf les sondes, et une qui sert d'administration/ monitoring de snort.
soit vous passer par ce site qui est un tutoriel intéressant qui ne m'a pris que 1 min pour chercher, il y a force d'informations pour la mise en place et le pourquoi faire ou ne pas faire certaine modifications
https://www.osnet.eu/fr/content/tutoriel-snort-et-logiciel-pfsense%C2%AE

Personnellement je resterais sur la première solution que la deuxième même si cela pourrait paraitre étrange ou inconcevable pour certain

megs

@Tatave
Lol, j'était déjà sur le même site lorsque tu as répondu. merci. section APPID.
Et je me rends compte que. mis a par la proximité des services, la config me parait plutôt bonne.
cordialement.

ccnet

@megs
Les documents de l'ANSSI notamment traitent de ces points. Ils sont disponibles librement sur leur site.
https://www.ssi.gouv.fr/guide/la-defense-en-profondeur-appliquee-aux-systemes-dinformation/
Mais il y a des controverses sur le sujet :
https://www.informatiquenews.fr/cybersecurite-lechec-concept-de-defense-profondeur-cyrille-badeau-threatquotient-51210
Si l'auteur pointe des réalités avec précisions, ses solutions sont beaucoup plus floues et on rentre dans un discours très généraliste, très marketing dont on ne voir pas la traduction opérationnelle possible. Le SIEM pour établir des corrélations fait gagner beaucoup de temps.

Si je me trompe dites le moi, mais l'IDS firewall ne rend pas compte des attaques WAN >lorsque qu'il n'est connecté qu'au LAN, et inversement (impossible de localiser une >machine au travers du NAT,Car les logs externes affichent l'ip du FW Natté, ( et sous PF >c'est assez le bordel pour faire un lien port natté/ip interne rapidement, les connexions >étant fort volatiles).

Cela dépend des flux que l'on traite. En http /https le problème ne se pose pas vraiment, même après nat et un reverse proxy un ips montre (peut montrer) l'ip source réelle.

En ce qui concerne le "bordel" du nat, la solution est dans la qualité de la doc pour le nat sur flux entrant. Là où cela devient très difficile à interpréter, car peu lisible, c'est le cas où vous avez du nat dans les deux sens sur une même ip publique. Ceci indépendamment du firewall employé.

megs

@ccnet said in Preprocesseur Http, et innondation d'alertes inhabituelles:

la solution est dans la qualité de la doc pour le nat sur flux entrant

Oui, pour sûr, mais trop souvent(pour ne pas dire tout le temps) le temps d'aller chercher l'info et de corréler le port à l'ip, le port est réutilisé par une autre connexion.

ccnet

le temps d'aller chercher l'info et de corréler le port à l'ip, le port est réutilisé par une autre connexion.

Je ne comprend pas bien comment vous travaillez.