Suricata XDP Syncookie

[vincentmli]

Make sure these boxes are signed before submitting your Pull Request -- thank you.

• I have read the contributing guide lines at
  https://docs.suricata.io/en/latest/devguide/contributing/contribution-process.html
• I have signed the Open Information Security Foundation contribution agreement at
  https://suricata.io/about/contribution-agreement/ (note: this is only required once)
• I have updated the user guide (in doc/userguide/) to reflect the changes made (if applicable)

Describe changes:

• Add XDP Syncookie feature to prevent host from SYN flooding attack in AF_PACKET IDS

Provide values to any of the below to override the defaults.

To use a pull request use a branch name like pr/N where N is the
pull request number.

Alternatively, SV_BRANCH may also be a link to an
OISF/suricata-verify pull-request.

SV_REPO=
SV_BRANCH=
SU_REPO=
SU_BRANCH=
LIBHTP_REPO=
LIBHTP_BRANCH=

[codecov]

Codecov Report

Attention: 8 lines in your changes are missing coverage. Please review.

Comparison is base (9fe00ff) 82.52% compared to head (906b316) 82.53%.
Report is 1 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master   #10268   +/-   ##
=======================================
  Coverage   82.52%   82.53%           
=======================================
  Files         978      978           
  Lines      272148   272166   +18     
=======================================
+ Hits       224595   224619   +24     
+ Misses      47553    47547    -6     

Flag	Coverage Δ
fuzzcorpus	63.61% <0.00%> (+0.01%)	⬆️
suricata-verify	61.86% <0.00%> (-0.03%)	⬇️
unittests	62.83% <0.00%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

[vincentmli]

Hi @victorjulien

I send this XDP syncookie PR and noticed the build failed on Debian 11 for the XDP syncookie program and user space program, I suspect Debian 11 may have old libbpf and kernel that does not support the XDP program and user space program. (https://github.com/OISF/suricata/actions/runs/7699348152/job/20980796747?pr=10268).

the XDP kernel program contains bpf kernel function that is supported from kernel 6.2 and above, I suspect none of existing Suricata distribution CI test has 6.2 kernel, Could you share your suggestion on this?

[victorjulien]

Interesting work. Some comments and questions inline.

Big question for me: can you share some results?

[victorjulien]

what is the origin of this file? similar for the other headers below

[vincentmli]

these header files are from https://github.com/xdp-project/bpf-examples/tree/master/headers/vmlinux with modification, the aim is to include minimum header files for the bpf program, not include full vmlinux.h header file which is too big

[victorjulien]

where does this come from? Did you modify it?

[vincentmli]

this is from the Linux kernel tree bpf selftests https://elixir.bootlin.com/linux/latest/source/tools/testing/selftests/bpf/xdp_synproxy.c, I did modify it by removing some code from it.

[victorjulien]

these files look like they are pulled in from somewhere. Where are they from? Did you modify them? Is it necessary to have them in our repo?

[vincentmli]

this is from https://elixir.bootlin.com/linux/latest/source/tools/testing/selftests/bpf/progs/xdp_synproxy_kern.c with modification by removing some code, and change code behavior, I think it is easier to be included in Suricata repo for user to use, if user get the code from kernel tree separately, it will not work since code behavior changes.

[vincentmli]

Interesting work. Some comments and questions inline.

Big question for me: can you share some results?

what result you expect to see? for the XDP bpf program performance, the original author has good performance result in
https://netdevconf.info/0x15/slides/30/Netdev%200x15%20Accelerating%20synproxy%20with%20XDP.pdf, maybe add a reference link to it in doc ?

[victorjulien]

Interesting work. Some comments and questions inline.
Big question for me: can you share some results?

what result you expect to see? for the XDP bpf program performance, the original author has good performance result in https://netdevconf.info/0x15/slides/30/Netdev%200x15%20Accelerating%20synproxy%20with%20XDP.pdf, maybe add a reference link to it in doc ?

Suricata with and without this, under some kind of stress test.

[vincentmli]

Suricata with and without this, under some kind of stress test.

I did SYN flooding test with and without this with Suricata, Suricata CPU spikes near 100% without this and enter into emergency mode, with this, Suricata CPU usage is about 6% under SYN flood as normal. or you are concerned if this feature introduce any overhead to Suricata itself in data path and need some other kind of stress test? I am not familiar with Suricata stress test, so any reference documentation on stress test would be great.

[vincentmli]

I updated the commit message with Suricata CPU usage when under SYN flooding attack without and with this feature, the CPU usage difference is from nearly 99% to 0.0%, this is expected since XDP is in early data path before Suricata AF_PACKET, Suricata will not even see the SYN flood packet since XDP already dropped SYN flood attach

with:

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                       
   1703 root      20   0  752860 372940 329216 S   0.3   1.1   0:00.32 FM#01                                         
   1699 root      20   0  752860 372940 329216 S   0.0   1.1   0:00.52 Suricata-Main                                 
   1702 root      20   0  752860 372940 329216 S   0.0   1.1   0:00.06 W#01-eno1                                     
   1704 root      20   0  752860 372940 329216 S   0.0   1.1   0:00.00 FR#01                                         
   1705 root      20   0  752860 372940 329216 S   0.0   1.1   0:00.00 CW                                            
   1706 root      20   0  752860 372940 329216 S   0.0   1.1   0:00.00 CS                                            
   1707 root      20   0  752860 372940 329216 S   0.0   1.1   0:00.00 US     

without:

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                       
   1702 root      20   0  752860 413900 329216 R  99.9   1.3   0:11.12 W#01-eno1                                     
   1703 root      20   0  752860 413900 329216 S   0.7   1.3   0:00.60 FM#01                                         
   1699 root      20   0  752860 413900 329216 S   0.0   1.3   0:00.64 Suricata-Main                                 
   1704 root      20   0  752860 413900 329216 S   0.0   1.3   0:00.00 FR#01                                         
   1705 root      20   0  752860 413900 329216 S   0.0   1.3   0:00.00 CW                                            
   1706 root      20   0  752860 413900 329216 S   0.0   1.3   0:00.01 CS                                            
   1707 root      20   0  752860 413900 329216 S   0.0   1.3   0:00.01 US                                            

[vincentmli]

@victorjulien any further feedback?

[catenacyber]

I think Victor expects a new rebased PR (instead of pushes on the existing one which has changes-requested status)

[vincentmli]

I think Victor expects a new rebased PR (instead of pushes on the existing one which has changes-requested status)

ok, the process works different for other project, I will do rebase then and send new PR.