packet filtering via Chelsio NICs
mike at sentex.net
Thu Aug 20 14:00:03 UTC 2020
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
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.
> 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
More information about the freebsd-questions