packet filtering via Chelsio NICs

[mike tancsa]

Hi Navdeep,

    Thanks for the followup and thanks for the awesome tools and
features in the drivers!  So far so good dropping the traffic. I havent
yet had to deal with dropping L3/L4 checksums, but in a DDOS that might
be handy.  I see the standard mix of stuff from straight up UDP & ICMP
blasts both spoofed and not, back scatter attacks (SYN-ACKS) etc.  At my
borders I like to drop all RFC 1918 addrs. With ipfw thats easy enough
with one line

deny ip from 192.168.0.0/16,10.0.0.0/8,172.16.0.0/12 to any via cxl0 //
stop bogons from leaking and entering

However, I dont think thats possible with the TCAM filters ? I can drop
those RFC 1918 addrs inbound on cxl0 with the filter

cxgbetool t5nex0 filter 3 iport 0 sip 172.16.0.0/12 action drop

but I cant do the equiv of "via" no ? I would have to add an addition rule

cxgbetool t5nex0 filter 4 iport 1 sip 172.16.0.0/12 action drop

assuming port 0 is outside facing and 1 is inside facing.

Another nice feature would be to somehow expose the stats via sysctl ?
Or is that needlessly expensive to keep track of ?  It would be nice to
hook this into our monitoring system (cacti etc) to detect when an
actual DDoS is happening or even just track attacks over time.

Other quick thing, would be to render the filter IPs in dotted quad
rather than as a hex int ?

cxgbetool t5nex0 filter list
 Idx     Hits FCoE Port      vld:VLAN  Prot MPS Frag                 
DIP                  SIP     DPORT     SPORT Action
   1   119961  0/0  0/7 0:0000/0:0000 00/00 0/0  0/0   
00000000/00000000    0a000000/ff000000 0000/0000 0000/0000 Drop
   2    54832  0/0  0/7 0:0000/0:0000 00/00 0/0  0/0   
00000000/00000000    c0a80000/ffff0000 0000/0000 0000/0000 Drop
   3    19478  0/0  0/7 0:0000/0:0000 00/00 0/0  0/0   
00000000/00000000    ac100000/fff00000 0000/0000 0000/0000 Drop

    ---Mike

On 8/19/2020 6:48 PM, Navdeep Parhar wrote:
> Hi Mike,
>
> Your followup on -questions indicates that you got the information that
> you were looking for.
>
> In addition to that, it is also possible to drop entire categories of
> bad packets in the hardware automatically --- stuff like incorrect L3/L4
> checksums, bad header lengths, etc.  This is not done by default because
> then you can't use tcpdump to see what was wrong with the frame and the
> sw drop counters won't increment either.  In case you see a lot of bad
> traffic of this sort and do not want to spend any CPU cycles on it let
> me know and I'll add a tunable to enable this behavior.
>
> Regards,
> Navdeep
>
> On 8/17/20 6:13 AM, mike tancsa wrote:
>> Has anyone used the packet filtering features of the T520 and T540 cards
>> on FreeBSD ? Rather than use ipfw or pf, I am hoping to offload some of
>> the packet filtering to the features on the card. Does it save CPU
>> processing power in the end ? Is there a sweet spot to using it, or am I
>> better off using ipfw ? I am looking at dropping traffic in the 2-5Gb/s
>> range filtering out bogons and other bad packets.
>>
>> Would appreciate any examples / caveats / tip on how to use it as the
>> docs are kind of sparse. Using it on RELENG_12
>>
>>     ---Mike
>>
>
>