Snort - Barnyard2 - syslog sur un serveur dans le cloud

ccnet

De quoi parlez vous exactement? Quel rapport avec Pfsense ?
https://forum.pfsense.org/index.php?topic=79600.0

hamdy.aea

Contexte : milieu perso, réseau privé

Besoin : Je souhaite envoyer les logs de WAN Barnyard2 vers Snort.

Schéma :

WAN (modem/routeur/box) : 1 une box du fournisseur internet câblée

LAN : 1 seul lan

DMZ : pas de DMZ

Autres fonctions assignées au pfSense : Snort - Barnyard2

Question : Je souhaite envoyer les logs de WAN Barnyard2 de Snort vers un serveur syslog dans le cloud (https://papertrailapp.com/). J'ai mis l'adresse serveur donnée par papertrailapp après l'inscription et j'ai ouvert le port 514 UDP du firewall pfsense.

Pistes imaginées

Recherches : Pour l'instant j'ai fais beaucoup de recherches mais la plus part des réponse que j'ai trouvées proposaient d'exporter vers un serveur SQL ou un serveur syslog en local.

ccnet

J'ai mis l'adresse serveur donnée par papertrailapp après l'inscription et j'ai ouvert le port 514 UDP du firewall pfsense.

Où, quelle page ?
Vous pensez que Pfsense dans son onglet Status: System logs: Settings gère l'adresse de estination des logs distants pour les packages ?
Observez le trafic sur l’interface par laquelle ces logs sont sensés sortir.
La box est en pont, en routeur ?

J'ai ouvert le port 514 udp du firewall

Vous ne dites pas sur quelle interface.

jdh

Comme indiqué par ccnet, l'envoi de log (au format syslog) depuis un firewall pfSense se fait

dans Status > System-logs > onglet Settings
Remote Syslog Server (1,2,3) : adresse ip ou nom du serveur qui va recevoir les logs
Contents : choix de ce qui est envoyé
Il n'y a, normalement, pas d'autres réglages à faire : le firewall émet directement le flux (= ce n'est ni du LAN ou WAN).

Par contre, le serveur recevant le flux doit accepter 514/udp.

NB : Snort : je n'utilise pas (pas assez compétent ni assez disponible), et je considère que la place de Snort n'est pas sur le firewall …

hamdy.aea

Voici le log d'erreur quand j'éssaie de mettre en marche WAN Barnyard2 :

Barnyard2 spooler: Event cache size set to [8192]
Jan 04 19:06:14 178.83. barnyard2: Log directory = /var/log/snort/snort_re041684
Jan 04 19:06:14 178.83. barnyard2: using operation_mode: default
Jan 04 19:06:18 178.83. barnyard2: FATAL ERROR: could not resolve address[logs3.papertrailapp.com:21749]
Jan 04 19:06:18 178.83. barnyard2: Barnyard2 exiting
Jan 04 19:06:18 178.83. barnyard2: ===============================================================================

Jan 04 19:06:18 178.83. php-fpm: /snort/snort_interfaces.php: The command '/usr/pbi/snort-amd64/bin/barnyard2 -r 41684 -f "snort_41684_re0.u2" –pid-path /var/run --nolock-pidfile -c /usr/pbi/snort-amd64/etc/snort/snort_41684_re0/barnyard2.conf -d /var/log/snort/snort_re041684 -D -q' returned exit code '1', the output was ''

ccnet

Je pense que cela parle de lui-même.

hamdy.aea

J'utilise le même serveur de log pour les syslog de pfsense et sa fonctionne parfaitement. Alors je ne comprends pas pourquoi il n'arrive pas à le joindre avec WAN Barnyard2

ccnet

Pourtant clair : could not resolve address[logs3.papertrailapp.com:21749]

hamdy.aea

J'ai bien vu le message d'erreur. Il n'arrive pas à joindre le serveur. Ce que je ne comprends pas c'est que j'arrive à le joindre avec le syslog de pfsense. Je cherche une solution. J'ai aussi lu ce log.

chris4916

@hamdy.aea:

J'ai bien vu le message d'erreur. Il n'arrive pas à joindre le serveur.

Ce n'est pas exactement ça:
avant de pouvoir joindre ce serveur, il faut pouvoir traduire ce nom en une adresse IP.
Et l'application n'arrive pas à résoudre ce nom (c'est un problème de DNS) et donc ne risque pas de joindre le serveur

hamdy.aea

Pour moi ce n'est pas un problème de DNS
j'ai éssayé en mettant l'ip du serveur. et j'ai le même résultat :

FATAL ERROR: could not resolve address[173.247.107.220:21749]

chris4916

@hamdy.aea:

Pour moi ce n'est pas un problème de DNS
j'ai éssayé en mettant l'ip du serveur. et j'ai le même résultat :

FATAL ERROR: could not resolve address[173.247.107.220:21749]

C'est ce module ?

    if (inet_aton(op_data->server,&op_data->sockaddr.sin_addr) != 1) 
    {
	if ((op_data->hostPtr = gethostbyname(op_data->server)) == NULL) 
	{
	    FatalError("could not resolve address[%s]",op_data->server);
	}

	memcpy(&op_data->sockaddr.sin_addr,op_data->hostPtr->h_addr,sizeof(op_data->sockaddr.sin_addr));
    }

    op_data->sockaddr.sin_port = htons(op_data->port);
    op_data->sockaddr.sin_family = AF_INET;

hamdy.aea

Oui c'est sa. Sa vient du syslog quand je relance l'interface Snort après avoir configuré WAN Barnyard2.

jdh

Je vais décrire mon avis sur ce sujet (et ce n'est pas un jugement, ça ne l'est jamais …).

Pourquoi je n'ai jamais utilisé Snort ?
Snort a pour but de déceler des attaques réseaux, qui vont généralement comporter des paquets anormaux.
De facto, Snort va sortir des alertes … dont il va falloir comprendre le sens, ... et auxquelles il va falloir répondre rapidement.
Je n'ai ni la compétence (pour comprendre l'alerte) ni le temps.
Néanmoins, je connais le produit, j'ai lu de la doc, je sais à peu près comment il fonctionne et comment l'installer ...

En fait, je pense que Snort est destiné à des services informatiques importants en effectif : capable d'affecter un informaticien expert et curieux à cette tache.
Bref sûrement pas une PME ...

Ce fil

Snort ne devrait pas être placé sur un firewall : cf doc et livre blanc sur pfSense
Barnyard2 est un addon de Snort : on trouve des tutos d'install sur Ubuntu …
l'alimentation de Barnyard2 se fait par un fichier 'spool' que l'on déclenche par une option de la conf de Snort
ce fichier spool n'est pas dans le syslog (et ne sera jamais dans syslog !)
il serait assez inefficace d'aller exporter un syslog dans le cloud ... pour ensuite rapatrier le log pour analyse

Bref, mon avis, faute de compétence, on est (très) loin d'aboutir à un début de mise en oeuvre ...

hamdy.aea

Finalement sa fonctionne, J'ai mis le nom du serveur sans les :et le port. J'ai mis le port de destionation à la place du 514. J'ai ouvert le port en udp et tcp dans le firewall et j'ai relancer l'interface de Snort. Je crois que là où j'ai fais l'erreur c'est que j'ouvrais que l'UDP et pas le tcp. 8)

ccnet

Je crains que cette analyse des causes du dysfonctionnement initial (notamment l'ouverture des port ttcp et udp) soit erroné. Mais comme "ça tombe en marche" …