Date: Thu, 20 Aug 2020 10:00:01 -0400 From: mike tancsa <mike@sentex.net> To: Navdeep Parhar <np@FreeBSD.org>, FreeBSD Questions <freebsd-questions@freebsd.org> Subject: Re: packet filtering via Chelsio NICs Message-ID: <380724d9-69f3-8726-aa73-48f9aec17e34@sentex.net> In-Reply-To: <ac997a3f-dd63-9ff1-9b5a-3446ccf55e49@FreeBSD.org> References: <6628bb23-c263-0cd7-4861-642977dfe467@sentex.net> <ac997a3f-dd63-9ff1-9b5a-3446ccf55e49@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >> > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?380724d9-69f3-8726-aa73-48f9aec17e34>