-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Sat, Apr 27, 2024 at 01:52:19PM -0000, qubist wrote:
> On Tue, 23 Apr 2024 12:04:22 +0200 Marek Marczykowski-Górecki wrote:
>
> > Have you measured it? I'd say it's up to ones who propose a change to
> > justify it.
>
> Now, I have.
>
> Setup:
>
> 2 VMs: firewall and client (vif interface). TCP and UDP port 1000 is
> explicitly open on firewall's input for the purpose of testing.
>
> Testing procedure:
>
> - run a test for at least 1 minute
> - note load average in firewall VM
> - wait 1 minute before next test
>
> ======================================================================
>
> Original Qubes firewall
> -----------------------
>
> ### Spoof
>
> # time (timeout 65s hping3 10.137.0.88 --flood --spoof 10.137.0.88)
> HPING 10.137.0.88 (eth0 10.137.0.88): NO FLAGS are set, 40 headers + 0 data
> bytes
> hping in flood mode, no replies will be shown
>
> --- 10.137.0.88 hping statistic ---
> 14397433 packets transmitted, 0 packets received, 100% packet loss
> round-trip min/avg/max = 0.0/0.0/0.0 ms
>
> real 1m5.015s
> user 0m6.268s
> sys 0m47.634s
>
> load average: 0.21, 0.07, 0.02
>
> ----------------------------------------------------------------------
>
> ### iperf3 between the 2 VMs
>
> # iperf3 -c 10.137.0.88 -p 1000 -t 65
> ...
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval Transfer Bitrate Retr
> [ 5] 0.00-65.00 sec 37.4 GBytes 4.94 Gbits/sec 1158 sender
> [ 5] 0.00-65.01 sec 37.4 GBytes 4.94 Gbits/sec receiver
>
> load average: 1.44, 0.49, 0.17
>
>
> ======================================================================
>
> Antispoof in ingress
> --------------------
>
> This is what the modified vif-route-qubes creates. The policy is 'drop'
> because only traffic from the original (non-spoofed) IP address is
> allowed anyway and the chain has no other function:
>
> # nft list table netdev antispoof
> table netdev antispoof {
> chain antispoof-vif19-0-10-137-0-11 {
> type filter hook ingress device "vif19.0" priority -500; policy
> drop;
> iifgroup 2 ip saddr 10.137.0.11 accept
> counter packets 13 bytes 796
> }
> }
>
> Before testing, remove unused rules too:
>
> # nft flush chain ip qubes antispoof
> # nft flush chain ip6 qubes antispoof
> # nft flush chain ip qubes prerouting
> # nft flush chain ip6 qubes prerouting
>
>
> ### Spoof
>
> # time (timeout 65s hping3 10.137.0.88 --flood --spoof 10.137.0.88)
> HPING 10.137.0.88 (eth0 10.137.0.88): NO FLAGS are set, 40 headers + 0 data
> bytes
> hping in flood mode, no replies will be shown
>
> --- 10.137.0.88 hping statistic ---
> 13443086 packets transmitted, 0 packets received, 100% packet loss
> round-trip min/avg/max = 0.0/0.0/0.0 ms
>
> real 1m5.016s
> user 0m5.999s
> sys 0m47.699s
>
> load average: 0.03, 0.13, 0.09
>
> ----------------------------------------------------------------------
>
> ### iperf3 between the 2 VMs
>
> # iperf3 -c 10.137.0.88 -p 1000 -t 65
> ...
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval Transfer Bitrate Retr
> [ 5] 0.00-65.00 sec 37.4 GBytes 4.95 Gbits/sec 887 sender
> [ 5] 0.00-65.01 sec 37.4 GBytes 4.95 Gbits/sec receiver
>
> load average: 1.21, 0.47, 0.22
>
> ======================================================================
>
> Side by side summary:
>
> Spoof:
>
> current Qubes firewall: load average: 0.21
> antispoof in ingress: load average: 0.03
>
>
> iperf3:
>
> current Qubes firewall: 4.94 Gbits/sec, load average: 1.44
> antispoof in ingress: 4.95 Gbits/sec, load average: 1.21
Ok, so it does improve performance a bit. The scenario of flooding with
spoofed traffic is not very realistic, but does show the impact. But
even on more realistic scenario of allowed traffic, the difference is
noticeable. IMO worth changing.
> ======================================================================
>
> The code:
>
> # This is the new /etc/qubes/qubes-antispoof.nft:
>
> #!/usr/sbin/nft -f
>
> table netdev antispoof
> delete table netdev antispoof
>
> table netdev antispoof {
> }
>
> I am attaching the modified vif-route-qubes.
As for the implementation, few remarks:
- - you create separate chain per IP, each with policy drop - it will
fail for multiple IPs (for example both IPv4 and IPv6) - it should be
one chain with possibly multiple rules (or one with a set?)
- - "downstream" map is gone (without a replacement using the new method),
opening spoofing on eth0 - see QSB-056 for details:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-056-2019.txt
If you open a pull request on github, we have quite extensive set of
tests I can schedule from there.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmZOiPQACgkQ24/THMrX
1yzCXQf/SvshTsK2mloZ7XngZRvQw4jBZa2STU2eNAp4yC94VkSCLsu4SrM8GzLw
Hy940Pm5Z6IBSpkIjaqvcZ+DUqmd5dipZk8BvwehqAG947hTiAVoNly+R4sMArs9
mw9YT5o+tFDvelrbd+R4glRPhWPZhl1flILG2GU75WVqJnJGnM1sXlZM6YTdMGOA
U1j02SJE6tlA7pb145Aqeg69c8pdWrL5HBu/D/Fe8ACAEeWQnTgBXcbF9FKePkNf
8OjRa4JfKg6Z0dtaDnWpIaB3KSclSPm/ldSpssyYxEJBd47WuwQ0sOF/fmnVy4wo
X+DlqaElycm1msmqIvSnuIlqERYm6A==
=VdWn
-----END PGP SIGNATURE-----
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/Zk6I9FsTh2YLoFs3%40mail-itl.
