Question SIEM: Le pare-feu excessive nie / règle Modifier la question
Nous avons un SIEM dans notre environnement que nous accordons actuellement un réglage et une partie de ce processus réduit le bruit de notre console.
Une infraction sur laquelle j'ai travaillé est la suivante: Le pare-feu excessive nie entre hôtes contenant la session refusée.
La règle qui déclenche le trafic et la génération de l'infraction est la suivante: Anomalie: un pare-feu excessivement nie à partir d'une source unique. La règle est construite comme suit:
- and when any of these BB:CategoryDefinition: Firewall or ACL Denies with the same source IP more than 400 times, across exactly 1 destination IP within 10 minutes
J'ai pris un échantillon de 10/20 infractions et j'ai examiné le trafic et confirmé que le trafic frappe notre interface externe dans le DMZ et est refusé par nos pare-feu. Non Permet.
Puisque nous générons beaucoup de bruit dans notre console, j'ai soulevé le seuil de timing dans la règle de 10 minutes à 15 minutes qui a toujours déclenché des infractions. Je l'ai ensuite plongé de 15 minutes à 30 minutes. + Ma question est que, puisque les noyaux que nous voyons sont des nies légitimes, devrais-je augmenter le seuil du temps et/ou des instances de la règle de déclencher une infraction afin que je ne voie qu'une attaque soutenue envers notre Public IP? Quels risques inciteraient si j'ai fait ce changement, le cas échéant?
Merci pour l'aide!
Cela ressemble à une règle de Qradar. Il serait bon de poser la question sur les Forums de développeurs IBM comme vous aurez plus d'yeux de l'administrateur QRADAR.
Cela étant dit, le pare-feu nie est inévitable si vous avez un DMZ. La faille est que beaucoup de gens regardent juste le pare-feu nie, mais ne regardez pas les permis de pare-feu. Denies ne ressent que ce que vous espérez voir. Les permis sont là où le véritable danger réside.
Pour les services mal confrontés:
Si les refus sont des concigurations ou des services connus, corrigez-les ou les ajoutent à la liste de fausses positives.
Pour tout service non légitime ou scanner de réseau malveillant:
Créez une règle qui attrape plus que x nombre de pare-feu nie en x minutes (ce sont des chiffres que vous devriez être à l'aise). Utilisez ensuite cette règle pour ajouter une IP de source d'incrimination à un jeu de référence (par exemple, appelez-le: Reference Set: Malicious Scanner). Enfin, créez une autre règle qui vérifie BB:CategoryDefinition: Firewall or ACL Accept (En supposant que vous êtes des permis de journalisation) et vérifie contre le Reference Set: Malicious Scanner. Lorsqu'un permis de pare-feu est enregistré d'une adresse IP dans le Reference Set: Malicious Scanner, Une nouvelle infraction devrait tirer parti. De cette façon, vous attrapez quand une adresse IP suspecte connue parvient à réussir le pare-feu.
Si vous n'êtes pas des permis de journalisation, mais utilisez NetFlow Data, créez une règle de flux qui vérifie contre le Reference Set: Malicious Scanner Pour tout trafic qui ne frappe pas le réseau DMZ. Cela peut vous aider à identifier si une adresse IP parvient à contourner le pare-feu. Les données NetFlow ne sont pas aussi précises que les journaux.
Je crois que vous utilisez QRADAR SIEM. C'est juste un événement normal si votre pare-feu est placé sur le DMZ. Mais cela dépend de votre analyse, si l'IP délinquante interroge plusieurs ports à 100 fois, ce qui est clairement une analyse de port. Mais si cela implique simplement 1 ou 2 ports, vous pourriez avoir une mauvaise configuration sur votre pare-feu.
Ma règle est Firewall or ACL Denies with the same source IP more than 100 times, across exactly 1 destination IP within 5 minutes.
Je pense qu'il n'y a pas de risque si c'est tout le pare-feu nier, il a déjà été atténué. L'attaquant ne peut pas contourner cela, mais vous devez également vous assurer que vous pouvez détecter des tentatives d'exploitation de votre IPS/WAF. C'est à ce moment-là que vous devriez bloquer la propriété intelligente sur la fin du pare-feu.
Les attaques de périmètre sont faciles à contenir car vous ne spécifiez que les ports autorisés sur votre pare-feu DMZ tel que 80 ou 443 seulement. Il est préférable que vous ayez également une surveillance sur vos serveurs DMZ/point final en déployant la protection EDR/EndPoint. (Protection de la défense en profondeur/en couches)