[Oisf-users] Working with mirror sampling

[Alan Wanderley dos Santos]

Hi Cooper,

I'm really convicted that send just "n" bytes from each packet is a bad idea.

Anyway, sampling full packets still a bad idea? I mean, we will have less accuracy, but solve the hardware's limitation problem.

About ignoring traffic, i see that link before, but, depends of traffic, the way will be congested. For exemple, if a send 10Gbps of traffic for a host with 100Mbps iface, de system is going crash. So, ignoring Traffic will not work rigth?

I think that the best solution would be mirror just specifics kinds of traffic (as you say, ignoring top-talkes).

Thank you again! Our talks on the list are helping a lot.

Regards,

-----------------------------------------------
Alan Santos
Analista de Segurança
Centro de Atendimento a Incidentes de Segurança (CAIS)
Rede Nacional de Ensino e Pesquisa (RNP)
(19) 3787-3314 | alan.santos at rnp.br

----- Mensagem original -----
De: "Cooper F. Nelson" <cnelson at ucsd.edu>
Para: "Alan Wanderley dos Santos" <alan.santos at rnp.br>, "Chris Wakelin" <cwakelin at emergingthreats.net>
Cc: oisf-users at lists.openinfosecfoundation.org
Enviadas: Terça-feira, 1 de setembro de 2015 12:38:17
Assunto: Re: [Oisf-users] Working with mirror sampling

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

As mentioned, sampling packets will break suricata, as it will cause every IP packet larger than 120 bytes to have a bad checksum.

There are lots of ways to filter what traffic is sent to the suricata process.  The most common ones are documented here:

> https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Ignoring_Traffic

Consider filtering top-talkers like streaming video sites, particularly if your ISP has Google/Netflix caches.

If you really want to actually sample traffic, a much better process is to sample flows vs. packets.  For example, this bpf filter will sample port 80 TCP flows:

> (not tcp src port 80 or (tcp src port 80 and ((tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 or tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x48545450))))

... recording all client packets, server HTTP headers and SYN/FIN packets.  The 'fat tail' of the HTTP session will be discarded, however.  Keep in mind this will trigger HTTP decoder errors if you have those enabled. 

- -Coop

On 9/1/2015 7:03 AM, Alan Wanderley dos Santos wrote:
> Hi Chris,
> 
> Thank you by the advice.
> 
> I sayed 120 bytes, but i don't have this denominator yet (sorry for
> that). 120 was a guess, but, after your advice i'll think about get
> full package. Do the sampling was a attempt of increment our
> detection capability. But, increment the number of packets and
> downgrade de accuracy is a bad idea.
> 
> Best Regards,


- -- 
Cooper Nelson
Network Security Analyst
UCSD ACT Security Team
cnelson at ucsd.edu x41042
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJV5cZpAAoJEKIFRYQsa8FWdoIIAM/nHgw9TlL+/celQqrdRoG1
WukYTrpoDYznJJmZ88sjZp9ZTa9J0MJsYXOO7wu5vIYuoSm1mA/N5q2WIreSCLUH
cQtCr1FholnDFVMPM/8ktB39IsHQ2/C+00CI121deXrxpm8fBVEndfeYcqW/ID1C
pfISlWepAR0ZSgk85zPNEMuDXCx86ANQQf3Zt8hcgrYZGP+TJEVWVmTisOyZe404
xHKRKkTugD1pn5huNGsMhDejJO1aPoIFFBGGSh46zmB8VMXS4b/6TM0CShANgRHu
xCziGI/NwdU68qXjNvUCkF6fsY/RHZutu3HfwpskHPTBY7DHKk5jVolPTess/Tg=
=wBD4
-----END PGP SIGNATURE-----