[Oisf-users] Working with mirror sampling

[Alan Wanderley dos Santos]

Interesting.

We are starting the project, so, we must do the things step by step. Unfortunately, we have very limited resources. Maybe, with some results i can try more resources and think about get other trap solutions.

At the moment, all we have are routers junos and VM servers. So, working only with that resources is comulsory :/

att,

-----------------------------------------------
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>
Cc: "Chris Wakelin" <cwakelin at emergingthreats.net>, oisf-users at lists.openinfosecfoundation.org
Enviadas: Terça-feira, 1 de setembro de 2015 13:43:51
Assunto: Re: [Oisf-users] Working with mirror sampling

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

It's not a good or a bad idea.  Often its the only option if you can't
afford the hardware to process everything.

Anyways, there are lots of possible solutions.  For example, you could
use an Arista or Gigamon box to tap/sample the traffic.  You could also
chose to only monitor certain hosts or ports via a Cisco ACL mechanism.

We do both, actually.  We sample traffic both via our tap/monitor
mechanism, as well as BPF filters and pass rules on the sensor.

- -Coop

On 9/1/2015 9:39 AM, Alan Wanderley dos Santos wrote:
> 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
> 
> 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)

iQEcBAEBAgAGBQJV5dXHAAoJEKIFRYQsa8FWahwH/AzddpULg+r0nfykmzgqHtaZ
9S/b970ipDCdCiMsukaoHVqB3/2A1I07bMgR5B7pL5UVLVOAENLt1wH0A/T/h3N3
4Xo2x1gfwphUG6duwvt+zLy3n1Qrn6ptNb/BgN+ZC0QdMzUYYspsIgk4w+K+WAZJ
r/d4GmJMUBYTrH5/3vrxBVDQqH5/7JQGPUIyaZgaQ7v5fJfcVCawstMqeuLMiUSp
g0BL16re4cct+TpsUS2HCqZbbRRDbiiAhSCQhrqf5o7YbYYwhszvwA0K5F0H9Ct+
xMPNcWUAxKUMeRJmFygKIsZnxYZ9Pbk9P6Yb1NFx3cWLpFepA/4bnl2BolMTZhs=
=BavB
-----END PGP SIGNATURE-----