Ok, finalement j’avais pas trop mal compris et en plus j’ai pu installer un container avec EveBox et maintenant j’ai un tableau de bord, hors HA, de ces alertes IDS, exemples :
beaucoup de rouge ! dois je m’inquiéter 
Déjà j’ai repéré 3 caméras qui causent entre elles déjà, et en plus avec nos amis chinois, (Baidu) , et ce traffique beaucoup, ça sent le filtrage sur la box très prochainement !
@bemo47 et @Sigalou
Merci pour votre travail, j’adore! 
Je confirme, je me suis basé que sur l’analyse des netflows.
Je prévoyais 3 cas d’utilisation distinct:
1- inventaire du réseau (seulement les scans)
2a - inventaire du réseau + analyse des netflows
2b - inventaire du réseau + proxy dns
3 - inventaire du réseau + analyse des netflow + proxy dns
Je viens de finir mon travail sur la baseline (@bemo47
) sur le mode learning, j’ai amélioré les vues findings et j’ai rajouté des statistiques (la release v0.7.4 va sortir incéssamment sous peu ).
Et franchement, je pense que tu as raison @Sigalou: mon prochain module consistera à ingérer des logs de ids.
Merci pour le travail que vous faites et tous ces feedbacks constructifs! 
1 « J'aime »
Bon encore une fois il faut remercier Gemini dans mon cas, mais c’est vrai que ça semble plus facile pour moi de comprendre ce que me sort l’ids surtout avec encore une fois les conseils de Gemini.
Mais tout ça est impressionnant effectivement, et j’attends ta nouvelle version avec impatience !
Je pense que Suricat est top, spontanément, j’ai installé les deux (avec Softflowd) mais juste je me demande comment récupérer le json de Suricat. Un partage réseau, je trouve pas ça top, d’autant que j’ai préféré dédié le port eth0 du raspberry à l’analyse et donc je ne le détecte pas sur le réseau, j’utilise le wifi pour communiquer avec le raspberry. Je ne sais pas si ma logique est la meilleure. Récupérer le json en wifi pourquoi pas, mais j’aime pas trop, … là, ça atteint mes limite réseau.
@domo-monster
je t’ai mis des retours de trucs à prendre en compte, je sais plus où, surement sur l’autre discussion où tu avais présenté l’intégration
1 « J'aime »
j’ai pas encore répondu, oui, merci. mais je crois que j’ai déjà corrigé plusieurs de tes inputs !
1 « J'aime »
Mais regarde evebox, on doit même pouvoir le mettre sur le pi avec suricata et ça permet de filtrer efficacement la log de suricata, je l’ai installé dans un container proxmox donc avec partage nfs et ça marche très bien. Voir mon post plus haut.
Edit : après je ne sais pas ce que @domo-monster prévois comme intégration dans HSA mais ça sera intéressant de voir remonter tout ça dans HA
2 « J'aime »
En revanche le fichier de log de suricata croit à une vitesse démentielle : 600mo en moins de 24h… vous avez mis quoi comme durée de rotation ?
j’ai mis ça mais tu as raison, je vais surveiller :
Je viens de mettre ça pour les rotations :
/var/log/suricata/*.log
/var/log/suricata/*.json
{
daily
size 500M
rotate 14
missingok
notifempty
compress
delaycompress
copytruncate
sharedscripts
}
et ça a donné ça :
xxxxxxx@PiSFlow:~ $ ls -lh /var/log/suricata/
total 79M
-rw-r--r-- 1 root root 585K May 10 19:41 eve.json
-rw-r--r-- 1 root root 5.3M May 10 19:40 eve.json.1
-rw-r--r-- 1 root root 70M May 10 19:33 eve.json.2.gz
-rw-r--r-- 1 root root 17K May 10 19:41 fast.log
-rw-r--r-- 1 root root 120K May 10 19:40 fast.log.1
-rw-r--r-- 1 root root 371K May 10 19:32 fast.log.2.gz
-rw-r--r-- 1 root root 62K May 10 19:41 stats.log
-rw-r--r-- 1 root root 430K May 10 19:40 stats.log.1
-rw-r--r-- 1 root root 2.3M May 10 19:32 stats.log.2.gz
-rw-r--r-- 1 root root 0 May 10 19:32 suricata.log
-rw-r--r-- 1 root root 9.8K May 10 19:32 suricata.log.1
1 « J'aime »
J’ai une question de compréhension ou de traduction :
Dans l’onglet external IP il y a une colonne contacted by , ma question c’est est ce que c’est bien le réseau interne qui initie la connexion dans ce cas ( et donc attention aux ip malicious) ou est ce que c’est l’ip en question qui a contacté l’hôte ( et dans ce cas c’est peut-être grave aussi mais pas la même analyse)
En l’occurrence j’ai cowrie qui tourne et je ban tout ce qui tente de s’y connecter. Si c’est une ip externe qui initie la connexion, bah c’est peut-être pas grave. Si c’est l’hôte qui tente de de connecter à l’ip en question de façon proactive alors attention danger…
Un exemple:
Et j’ai pas trouvé dans la doc la solution à ma question…
Ne faudrait il pas une colonne contacted from ? Ou un truc dans le genre
Mais il y a l’IP externe et le contacted by, c’est pas ça que tu souhaites ? Ça donne bien le sens de la connection ?
Si l’IP en début de ligne est externe et le contacted by interne c’est donc une connexion initiée depuis ton LAN vers l’extérieur.
Bah justement, ip externe ca peut juste être la liste des ip qui ont eu une connexion sans préciser le sens. Et dans contacted by ca pourrait être juste la machine qui a eu l’interaction sans specification du sens exact.
C’est pour ça que je demande ça ne me semble pas limpide mais ce n’est peut-être que moi.
hmmm peut etre, pour moi « contacted by » ça veut dire que c’est cette ip qui a initié la connection vers l’ip qui citée en début de ligne, donc ça semble donner le sens ?
par exemple je vois le 1.1.1.1 et en « contacted by » je vois toutes mes ip locales, ça dit bien que toutes mes ip locales ont contacté ce dns
enfin c’est ma compréhension
Très bon point, merci.
Jusque là, je prenais en compte seulement des connections ‹ outbound › (du réseau interne vers une ip publique). Donc contacted by est bien l’ip qui initie la connection.
Ma foi, ton use case est censé: dans le cas d’un server hosté dans le réseau interne, c’est l’ip publique qui initie la connection.
→ actuellement, ce cas de figure n’est pas couvert (pas de traces dans External IPs) mais l’ip interne apparait dans les hosts avec ces ports ouverts.
Je songe à rajouter une colonne qui dirait direction: dans la plupart des cas ce sera du ‹ outbound ›, mais il pourrait y avoir du ‹ inbound › aussi (et ça devrait réagir comme pour le ‹ outbound › - enrichir et flagger si l’ip est malicieuse/suspicieuse).
Je rajoute également du ‹ both ›:
(signifie que la même adresse IP externe a été observée dans des flux de communication dans les deux sens :
- Au moins un flux sortant : l’un de vos appareils internes a initié une connexion vers cette adresse IP.
- Au moins un flux entrant : cette adresse IP a initié une connexion vers l’un de vos serveurs internes.
)
Use-cases
- Pattern webhook / callback — un appareil interne appelle une API cloud (sortant), et ce service cloud rappelle ensuite votre serveur webhook auto-hébergé (entrant). Comportement normal.
- Service à double rôle — vous faites tourner un serveur accessible depuis internet et ce même serveur émet aussi des connexions sortantes vers un hôte distant. Cet hôte distant apparaîtra en « Both ».
- Cas suspect — une IP que l’un de vos appareils a contactée en premier, et qui se reconnecte ensuite en entrant vers un autre hôte interne. Ce schéma (beacon puis rappel, ou reconnaissance C2) doit être alerté. Ce cas rajoute un
à côté de both.
je vais release avec ça et faire un test avec serveur interne de test.
@faiseurdepluie je suis preneur de feedback sur cette feature, merci encore!
3 « J'aime »
Ah top, hâte de tester ca !
Salut.
Tombé un peu par hasard tout à l’heure sur ton article, j’ai décidé de me lancer
Ayant un pfsense, ça m’a facilité le job . Installation de softflowd , puis config qui pointe vers mon Ha. Le reste de la procédure a été tiré de ton article.
Bon, 125 Cve trouvés en 10 mn
, j’ai un peu de travail devant moi.
En attendant, merci pour ton article !
2 « J'aime »
Autre question, pour le moment j’ai juste mis l’interface principale via softflowd
Mais je ne maîtrise pas assez pour savoir si je peux envoyer l’interface docker0 ou les bridge sur le même port, et ce que ca va donner sous HSA.
L’idée serait de surveiller aussi les mouvements latéraux bizarres. Ça peut déjà fonctionner ou j’oublie pour le moment et inutile de bidouiller/chercher ?