Snort - Barnyard2 - syslog sur un serveur dans le cloud

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" …