[Oisf-users] Suricata seperate Rx/Tx connection
Michał Purzyński
michalpurzynski1 at gmail.com
Tue Mar 3 21:55:21 UTC 2020
Here's the hardware and software version
arista-eis-nsm1#show ver
Arista DCS-7150S-52-CL-R
*Hardware version: 12.04*
*Software image version: 4.23.2F-2GB*
Architecture: i686
*Internal build version: 4.23.2F-2GB-15405360.4232F*
*Internal build ID: 85bd3770-9843-4dbb-b95b-cd95eb743c5b*
As you can see we run 4.23 - and 4.14 is extremely old. I don't really
remember what things looked like back there.
To process IPv6 packets, you need to tune the configuration slightly and
add dedicated ACLs + class maps + policy maps for IPv6. Here's how I do it.
First, you need one ip ACL and a ipv6 ACL to select packets
! match IPv6 packets you are interested in
*ipv6* access-list match_any6
10 permit *ipv6* any any
! match IPv4 packets you are interested in
*ip* access-list match_any
10 permit *ip* any any
! first class map - to map ipv4 packets
class-map type tapagg match-any match_from_taps
10 match *ip* access-group match_any
! another class map - to map ipv6 packets Only IPv6 ACLs are accepted here.
class-map type tapagg match-any match_from_taps6
10 match *ipv6* access-group match_any6
(I keep them separated into two class-maps for no good reason. Maybe they
are just easier to manage this way. Pretty sure you could do 20 match ipv6
instead)
policy-map type tapagg from_taps
! send IPv4 packets in match_from_taps to aggregation-group to_nsm
100 class match_from_taps
set aggregation-group to_nsm
! send IPv6 packets in match_from_taps to aggregation-group to_nsm
110 class match_from_taps6
set aggregation-group to_nsm
I'm pretty sure most packet broker configurations in the world are broken
and do not select IPv6 correctly. I fixed mine a while ago.
On Tue, Mar 3, 2020 at 9:11 AM mohammad kashif <kashif.alig at gmail.com>
wrote:
> Hi Michal
>
> Sorry for restarting this thread again but I thought it is better than
> starting a new one. Thanks a lot for giving this complete configuration. It
> worked for me when I have one input group and one output group.
>
> Now I am trying to send same data to netflow, I have come across an
> issue.
>
> policy-map type tapagg from_taps
> 10 class match_noise
> set aggregation-group to_null
> !
> 100 class match_from_taps
> set aggregation-group group to_bro group to_suricata
>
> I am using Arista 7150S with software version 4.14 . Apparently I can only
> 'set aggregation-group to_suricata' . There is no 'group' option coming
> after 'aggregation-group' in the switch. Is it something to do with
> software version or switch hardware? What is version of software/hardware
> you are using?
>
> There is another issue which I noticed later
> class-map type tapagg match-any match_from_taps
> 10 match ip access-group match_any
>
> So I have defined an IP access list match_any
> IP Access List match_any
>
> 10 permit ip any any
>
>
> But it doesn't include ipv6 traffic and switch is not allowing me to
> include ipv6 access-list to class-map type . Have you come across this
> issue?
>
>
> Thanks in advance :)
>
>
> Regards
>
>
> Kashif
>
>
>
>
>
>
> On Fri, Nov 1, 2019 at 9:38 PM Michał Purzyński <
> michalpurzynski1 at gmail.com> wrote:
>
>> I think we are all over-complicating things here and no one shares a
>> complete solution ;)
>>
>>
>> https://www.arista.com/en/um-eos/eos-section-20-4-tap-aggregation-traffic-steering
>>
>> If you have Arista in front of your cluster, you connect RX and TX from
>> all your taps there, and then configure it creating bonding / aggregate
>> interface on Arista (not on Linux) and connect those "bonded" ports to a
>> number of network cards from the same or different sensors.
>> Traffic will be load balanced per 2 or 3-tuple. You can then start
>> Suricata with AF_Packet on all Ethernet interfaces
>>
>> OMG watch me drawing in ASCII ;)
>>
>> ---> (tap 1 RX) - |et1| | AR |
>> ---> (tap 1 TX) - |et2| | IS | | et41 | -> | Po10 | -> | sensor's first
>> card |
>> ---> (tap 2 RX) - |et3| | TA | | et42 | -> | Po10 | -> | sensor's second
>> card |
>> ---> (tap 2 TX) - |et4| | |
>>
>> Arista's configuration (and literally any packet broker will do, this one
>> is cheap, Gigamon is expensive but makes a coffee while deduplicating
>> packets and God knows what else. I deduplicated with a couple access-list,
>> took me like one day)
>>
>> # conf t (hi, Cisco!!)
>>
>> tap aggregation
>> mode exclusive
>>
>> load-balance policies
>> load-balance fm6000 profile NSMConSymm
>> port-channel hash-seed 39
>> no fields mac
>> fields ip protocol dst-ip src-ip
>> distribution symmetric-hash mac-ip
>>
>> reboot here
>>
>> Create "output" aggregated links where you will connect your sensors, I
>> have two (and I'm lying but that's for brevity)
>>
>> interface Port-Channel10
>> description Bro production
>> l2 mtu 9000
>> switchport mode tool
>> switchport tool group set to_bro
>> !
>> interface Port-Channel20
>> description Suricata production
>> ip access-group drop_noise_before_suricata out
>> l2 mtu 9000
>> switchport mode tool
>> switchport tool group set to_suricata
>> !
>>
>> Then for each port where you have a tap connected
>>
>> interface Ethernet1
>> speed forced 10000full
>> l2 mtu 9000
>> ingress load-balance profile NSMConSymm
>> ip access-group drop_noise_from_taps in
>> service-policy type tapagg input from_taps
>> switchport mode tap
>>
>> Repeat as necessary
>>
>> Each sensor has two network cards here to deal with the "2x 10Gbit > 1x
>> 10Gbit" problem and also for NUMA (optional)
>>
>> First interface on the sensor, will get all packets that are part of the
>> flow between 1.2.3.4 <-> 23.24.25.26 for example
>>
>> interface Ethernet41
>> description nsm6:1a
>> channel-group 20 mode on
>> switchport mode tool
>> !
>>
>> Second interface on the sensor, will get other 3-tuple hashed flows, etc
>>
>> interface Ethernet42
>> description nsm6:2a
>> channel-group 20 mode on
>> switchport mode tool
>> !
>>
>> Going back to Arista's configuration, now let's glue it all together
>>
>> Class-map filters what's send to sensors, here we just send everything,
>> while maintaining a configuration that lets me steer part of the traffic
>> somewhere else, should I need to, like during DDoS.
>>
>> class-map type tapagg match-any match_from_taps
>> 10 match ip access-group match_any
>> !
>> class-map type tapagg match-any match_noise
>> 10 match ip access-group send_noise_to_null
>> !
>>
>> Take traffic "labeled" as from_taps, try to match it against class
>> match_noise, if it does, send to ports tagged with "to_null. Take remaining
>> traffic, try to match against class match_from_taps, everything that
>> matches is send to ports tagged to_bro and to_suricata
>>
>> policy-map type tapagg from_taps
>> 10 class match_noise
>> set aggregation-group to_null
>> !
>> 100 class match_from_taps
>> set aggregation-group group to_bro group to_suricata
>> !
>>
>> On Fri, Nov 1, 2019 at 2:02 PM Nelson, Cooper <cnelson at ucsd.edu> wrote:
>>
>>> What packet capture method are you using?
>>>
>>>
>>>
>>> -Coop
>>>
>>>
>>>
>>> *From:* Amar <amar at countersnipe.com>
>>> *Sent:* Friday, November 1, 2019 1:58 PM
>>> *To:* Nelson, Cooper <cnelson at ucsd.edu>
>>> *Cc:* mohammad kashif <kashif.alig at gmail.com>; Oisf-Users <
>>> oisf-users at lists.openinfosecfoundation.org>
>>> *Subject:* Re: [Oisf-users] Suricata seperate Rx/Tx connection
>>>
>>>
>>>
>>> CounterSnipe default setup bonds all interfaces into a single bond#(0)
>>> and starts Suri with -i bond0 and it works fine.
>>>
>>>
>>>
>>> On Nov 1, 2019 at 10:49 PM, <Cooper Nelson <cnelson at ucsd.edu>> wrote:
>>>
>>> That would work with pcap, not sure how AF_PACKET handles bonded
>>> interfaces.
>>>
>>>
>>>
>>> We use an Arista with two 10Gbit interfaces and pevma’s config.
>>>
>>>
>>>
>>> -Coop
>>>
>>>
>>>
>>> *From:* Amar <amar at countersnipe.com>
>>> *Sent:* Friday, November 1, 2019 8:19 AM
>>> *To:* mohammad kashif <kashif.alig at gmail.com>
>>> *Cc:* Nelson, Cooper <cnelson at ucsd.edu>; Oisf-Users <
>>> oisf-users at lists.openinfosecfoundation.org>
>>> *Subject:* Re: [Oisf-users] Suricata seperate Rx/Tx connection
>>>
>>>
>>>
>>> Could bonding be the solution here. Bond eth1 and 2 and simply monitor
>>> the bond.
>>>
>>>
>>>
>>> On Nov 1, 2019 at 4:08 PM, <mohammad kashif <kashif.alig at gmail.com>>
>>> wrote:
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Suricata IDS Users mailing list: oisf-users at openinfosecfoundation.org
>>> Site: http://suricata-ids.org | Support:
>>> http://suricata-ids.org/support/
>>> List:
>>> https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>>>
>>> Conference: https://suricon.net
>>> Trainings: https://suricata-ids.org/training/
>>
>> _______________________________________________
>> Suricata IDS Users mailing list: oisf-users at openinfosecfoundation.org
>> Site: http://suricata-ids.org | Support: http://suricata-ids.org/support/
>> List: https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>>
>> Conference: https://suricon.net
>> Trainings: https://suricata-ids.org/training/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20200303/0319ae3e/attachment-0001.html>
More information about the Oisf-users
mailing list