Résultats de recherche pour iptables

Connecteur OpenCTI – AbuseIPDB Blacklist

Posté le de — Aucun commentaire ↓

Bonjour à tous, aujourd’hui, je continue avec OpenCTI parce que je vous ai développé un petit connecteur OpenCTI. J’en ai un peu chié :’-) entre le python qui n’est pas ma tasse de thé et le fait que je démarre avec OpenCTI : je suis pas parti avec des bonus là…^^
Mais du coup je me dis que ca vaut le coup de vous partager un peu de ce que j’ai fait, car il y avait de bon trucs à apprendre notamment autour du format Stix.

L’environnement de development.

Alors c’est probablement la partie la plus simple au départ, il suffit quasiment de suivre le guide du projet il peut y avoir quelques subtilité pour déployer Python sur votre Windows avec VSCode et pip mais globalement ça ne se passe pas si mal.

Une fois votre environnement de dev en place, il faut :

  1. Forker le projet OpenCTI connectors sur votre Github
  2. Faire une branche dédié et basculer dessus
  3. Si comme moi vous créer un nouveau connecteur :
    1. Copier le répertoire template
    2. renommer quelques variables/chemin comme indiqué dans la doc.

Jusqu’ici tout va bien.

Le development

Alors la bonne nouvelle c’est comme il existe déjà plein de connecteurs, vous … Lire la suite

OpenCTI

Posté le de — Aucun commentaire ↓

Bonjour à tous, aujourd’hui on va se pencher sur la plateforme OpenCTI avec docker et portainer, comme d’habitude. OpenCTI c’est une plateforme de Cyber-Threat Intelligence qui a vocation a accueillir et gérer votre base de données d’indicateurs de compromission de sources externes ou internes et à servir de point de pivot avec l’ensemble de votre écosystème : cortex et the hive, AbuseIPDB, abuse.ch, les CVE du NIST, Splunk, et j’en passe… L’intérêt ? c’est que c’est un plateforme industrialisable avec des capacité de reporting intégré, une API toute prête, et un paquet de plugins communautaire déjà fait.

Rappel des articles de la série « Docker et Portainer » :

… Lire la suite

BlockList iptable avec Splunk et d’AbuseIPDB

Posté le de — Aucun commentaire ↓

Bonjour à tous, aujourd’hui je continue avec un article qui suit ce qu’on avait fait avec la Blacklist Iptables AbuseIPDB la dernière fois. Cette fois on va voir comment construire une BlockList iptable avec Splunk et d’AbuseIPDB.

Qu’est ce que j’entends derrière ce titre ? Simplement que la blacklist ma dernière fois n’est pas très « maline ». Dans le sens, où on verrouille juste 10 000 IP comme des bourrins et sans trop se demander si les vulns ou services qu’elles checkent nous concerne en effet. Alors, ça ne sert pas à rien hein. C’est une bonne base à bloquer facilement mais ce n’est pas forcément utile dans le sens où ces 10 000 ne se connecterons pas forcément à votre site ou infra au final.

En effet, ce qu’on souhaiterai plus, notamment dans une optique de CTI (Cyber threat Intelligence) : c’est de bloquer (sinon détecter au moins) celles qui se connectent effectivement sur nos services (genre à la fail2ban). Le problème c’est que fail2ban c’est bien en protection mono instance. Mais, quand vous protégez tout un système d’information, ça ne passe pas super bien à échelle. Par exemple, je vous laisse imaginez quand vous … Lire la suite

Rsyslog en duplication de log (sur Redhat)

Posté le de — Aucun commentaire ↓

Bonjour à tous, aujourd’hui je vais vous montrer comment configurer un serveur Rsyslog en duplication de log, c’est une configuration qui est très très utile quand on bosse sur un SIEM. En effet, parfois les solutions (au hasard Broadcom SEP…) qui émettent du syslog ne permettent pas toujours d’envoyer les logs à plusieurs destinations. C’est gênant car en cas d’étude ou tout simplement changement de SIEM, on ne peut pas dupliquer les logs vers le nouveau système. Si c’est mal géré cela peut obliger à des bascules en mode big bang dans ce genre de situation, ce qui n’est pas pas idéal pour des reprises en douceur.

Mais ce problème peut être simplement adressé avec un petit serveur rsyslog devant le SIEM. En effet ce service possède nativement la fonctionnalité de reforwardé des logs. Du coup, un petit passage dans la doc de rsyslog et un nouveau serveur plus tard et pouf on a la procédure suivante :

Installer et configurer Rsyslog en duplication de log

yum install rsyslog

Puis configurer en éditant le fichier /etc/rsyslog.conf. Notez que vous avez un générateur de configuration automatique fourni directement sur le site du projet. Il faut admettre que la syntaxe n’est … Lire la suite