On Thu, Apr 18, 2024 at 1:57 AM Michael Tremer michael.tremer@ipfire.org wrote:
Hello,
On 17 Apr 2024, at 23:36, Vincent Li vincent.mc.li@gmail.com wrote:
On Wed, Apr 17, 2024 at 9:07 AM Michael Tremer michael.tremer@ipfire.org wrote:
Hello Vincent,
On 10 Apr 2024, at 19:01, Vincent Li vincent.mc.li@gmail.com wrote:
On Wed, Apr 10, 2024 at 8:17 AM Peter Müller peter.mueller@ipfire.org wrote:
Hello Vincent,
thank you for your e-mail and the proposal.
Hi Adolf,
Please see my reply inline
On Wed, Apr 10, 2024 at 2:04 AM Adolf Belka adolf.belka@ipfire.org wrote: > > Hi Vincent, > > I am not very familiar at all with this type of stuff but one thing that I noticed is that in the image you provided a link to, the XDP section has a line labelled XDP_TX which completely bypasses the whole Netfilter section which doesn't seem to be a good idea to me. > XDP_TX is to redirect the packet out after processing the packet at XDP stage, yes, netfilter will not see these packets. for example for DDoS SYN flood attack scenario, when the SYN packet is received, XDP program can generate SYN+ACK with syncookie and send the SYN+ACK out, netfilter/Linux tcp stack knows nothing about it, which actually saves host CPU cycles to process the SYN in netfilter/TCP stack, which is actually good thing.
Also, XDP_DROP, XDP_PASS, XDP_TX action is depending on the XDP program attached to the network interface, so it is the XDP program author decide what to do with the packet, if no XDP program attached to the network interface, everything works as usual, no interference from XDP.
If my understanding of this is correct, then this would lead to the exact opposite of what IPFire is designed to do. Rather than having packets processed below any level of operating system influence, the objective of IPFire in particular and firewalls in general is to control network traffic, which inherently requires thorough visibility on it.
Kernel still has the traffic statistics processed by XDP program and store in eBPF maps so the user space program can query and view. you can still view XDP as part of the firewall except it processes packets early at the driver layer for efficiency.
I would like to understand what your need is to use XDP.
As Peter has stated, your system will pass packets with this, but 90% of the features that IPFire has won’t work any more:
- Connection Tracking won’t be up to date
- QoS won’t be able to categorise packets correctly and won’t be able to do its job
- The IPS won’t be able to inspect any data
I think I did not explain the XDP use case clearly, for now, most XDP use cases and particularly my use case is to do DDoS protection at the earliest packet receiving path in high efficiency since XDP works inside the network driver. the things you mentioned above would work fine even if the packets go through XDP program, yes XDP program can drop, modify, reflect the packet, but in non-DDoS packet senario, XDP simply passes the packet to Linux as if nothing happened. so it is up to the XDP program logic, also even if ipfire has the kernel feature enabled, users still need to attach XDP program to the interface, if no XDP program is attached to the interface, nothing is in the way to stop packet flowing to IPfire filtering. Again this diagram is great to describe the packet path https://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.sv..., so the XDP_PASS action from XDP program is to pass packet to Linux as usual. from the same diagram, you also see "AF_PACKET", right? that is where tcpdump taking place to capture packet for network troubleshooting, but tcpdump would not stops all the scenario above you mentioned working, actually tcpdump is based on classic BPF technology, the XDP/eBPF is to extended classic BPF technology, it not only can clone (packet capture), but can also drop, redirect. Please read more about eBPF/XDP in general if you would like, many online resources explain better than me :) > Those three are just a few, but they are commonly used features of IPFire and without them, it would not be what it is.
Thank you. I am very familiar with how Netfilter works, including BPF and XDP.
I think your diagram just proves my point when I say that everything is going to bypass the OS. That is the long arrow at the bottom.
I think you refer to the XDP_TX action to bypass the whole OS, for IPFire, this is not recommended
At least I am assuming that you are interested in forwarding packets instead of going the “XDP_PASS” route, because for that you don’t need XDP?
For IPFire, XDP_PASS action is recommended because we don't want to bypass the OS, we only want to drop DDoS packet at the driver, the good packet passes through the OS as usual.
I think you still haven’t explained what your goal is on a lower level. DoS protection is incredibly broad and that does not strictly require XDP. What kind of XDP program are you interested in using?
use XDP to stop DoS has low overhead, save OS cycles, I have IPFire KVM instance, if I run TCP SYN flood the IPFire, the IPFire ssh session, WeUI session because sluggish and unresponsive, but with XDP, it is almost like nothing happening, IPFire is responsive all the time during flood attack.
these are the XDP program I am interested in using https://elixir.bootlin.com/linux/latest/source/tools/testing/selftests/bpf/p... https://github.com/NLnetLabs/XDPeriments
I had ported them to xdp-tools https://github.com/vincentmli/xdp-tools/tree/vli-xdp-synproxy so xdp-tools loader program could attach multiple XDP programs to red0 interface to stop various DDoS attack
As far as I am aware, IPFire is currently able to handle 25 GBit/sec. on the right hardware, and SYN flooding attacks are not a major threat to IPFire users, given that we have historically implemented some fine-tuning to make such attacks less viable.
DDoS attacks to IPFire users do not happen now does not mean it will not happen in the future, SYN flood is just one scenario, so better be prepared than sorry later :) One IPFire user had asked for help https://community.ipfire.org/t/filter-out-ddos-attacks-anyone-can-help-me-pl...
Is this only about SYN flooding? for layer 4 TCP DDoS, the most common scenario is SYN flooding, ACK flooding, RST flooding. all these flooding can be stopped by SYN cookie that is already built in the Linux TCP host stack, but IPFire is a middle box firewall, the packet destination endpoint is not IPFire, but the host/green network port forwarded by IPFire, so that is where the netfilter SYNPROXY module plays in, I don't see SYNPROXY module being referenced anywhere in IPFire, so even without XDP, I still recommend IPFire provides user option to use SYNPROXY for TCP SYN/ACK/RST flood attack
I have studied IPFire, I do not see relevant SYN flooding or DDoS tuning, where is it? netfilter with SYNPROXY module? or the TCP stack syncookie implementation, or suricata ddos rules...etc? keep in mind all these are handled in software, no hardware acceleration.
Yes, IPFire runs in software. We cannot use hardware acceleration because it is designed to pass packets and not to do what we are doing here.
hardware acceleration probably is not the right word here for XDP because XDP is actually still in the software driver, not inside the hardware, though there is one hardware vendor that supports running XDP byte code inside the hardware itself for true hardware acceleration, but that is not common. again XDP does not interfere with the IPfire filter except in DDoS scenarios, users can have the option to drop the packet early in the network driver without consuming IPfire CPU/memory resource. >
But do you have any kind of system out there that is under constant fire and the OS cannot cope? What kind of packet rates or bandwidth are we talking about?
I don't have IPFire in production since I am just starting to know about the IPFire project. My day time job is enterprise network engineer supporting fortune 500 enterprise customer with our enterprise product (BIG-IP) which handles 10G/25G/40G or even 100G throughput with FPGA, we often has enterprise customer under DDoS attack, and sometime my day time job is to simulate such high bandwidth attack in lab to see if enterprise product handles well or not. I don't think IPFire can handle such flood attack since I know the limitation of netfilter ( with more than 20 years of working with Linux networking :))
IPFire uses SYN cookies by default for all incoming connections. We currently do not use the SYNPROXY module, but that is simply because there has not been any demand for it. If this suits your use-case I would rather implement that than XDP.
home users very unlikely would have this demand because there isn't much gain for attackers who would use DDoS to attack home users. For small/medium size businesses, attackers could start DDoS because business could be impacted and lose profit when under DDoS attack, many businesses choose cloud DDoS providers if they could not afford DDoS protection devices. XDP DDoS protection on IPFire provides DDoS protection on inexpensive commodity hardware. There are already a lot of open source XDP programs out there, including XDP SYNCookie from Linux kernel source, I have ported it to xdp-tool repo and ported xdp-tool to IPfire.
Maybe share this code on the list here so that people understand better what you are looking for.
see above link I shared
I am still not sure what kind of changes you are asking us to make.
actually the asking is minimum, turn on the kernel config feature for eBPF for networking
CONFIG_BPF_SYSCALL=y CONFIG_DEBUG_INFO=y CONFIG_DEBUG_INFO_BTF=y CONFIG_DEBUG_INFO_DWARF4=y CONFIG_BPF_UNPRIV_DEFAULT_OFF=y
I have a working fork of IPFire https://github.com/vincentmli/BPFire/tree/bpfire, the discussion here is I want to share that great technology with the IPFire community and contribute that to IPFire.
Vincent
-Michael
-Michael
Why not give IPFire users the options when the options already exist in the IPFire kernel?
Therefore, I - personally - neither see the necessity nor benefit of pursuing this proposal at this time.
Thanks, and best regards, Peter Müller
> I don't understand what the difference is between XDP_PASS and XDP_TX but I would expect that nothing should be allowed to bypass the netfilter section unless it is being dropped or rejected already by the XDP process. >
XDP_PASS is to pass the packet to netfilter/TCP stack as usual after XDP program packet processing, XDP_TX is to redirect the packet back out through the same network interface after XDP program packet processing.
> Regards, > > Adolf. > > On 09/04/2024 19:36, Vincent Li wrote: >> Hi, >> >> I have been working on enabling eBPF XDP/TC kernel feature for IPFire, >> please refer to >> https://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.sv... >> for where XDP fit in Linux network datapath, XDP will not interfere >> with existing IPFire firewall rules. XDP is especially good at DDoS >> packet filtering at high speed, see >> https://netdevconf.info/0x15/slides/30/Netdev%200x15%20Accelerating%20synpro... >> >> I think we only need to enable XDP/TC network filtering capability >> without eBPF tracing capability which some users are concerned about >> potential host security information leaks. >> >> Please let me know what you think, thanks! >> >> Vincent