[Solved] Why (simple) firewall (nftables) IP blocking is not working?

Help
1

Hey everyone!

I (think I) have a simple firewall use case: Block a single IP address (example: A.B.C.D) with nftables (completely).

Background: A.B.C.D somehow spams my server with 5 permanent multicast UDP connections on the 5 IPs 239.192.84.97–239.192.84.101 at port 5004 (which ~2Mb per connection).
(I hope I’ll have contact in time to the owner of A.B.C.D. ATM I only wanna drop the connection …)

Because I have no service on the port 5004 I use tcpdump/iftop/nethogs to view the connections. The following tcpdump is flooding my terminal …

[root@host:~]# tcpdump -Q in -nn
[…]
19:03:30.812825 IP A.B.C.D.5004 > 239.192.84.100.5004: UDP, length 1452
19:03:30.813367 IP A.B.C.D.5004 > 239.192.84.97.5004: UDP, length 1452
19:03:30.814311 IP A.B.C.D.5004 > 239.192.84.101.5004: UDP, length 1452
19:03:30.814359 IP A.B.C.D.5004 > 239.192.84.99.5004: UDP, length 1452
19:03:30.815310 IP A.B.C.D.5004 > 239.192.84.98.5004: UDP, length 1452
19:03:30.817826 IP A.B.C.D.5004 > 239.192.84.100.5004: UDP, length 1452
19:03:30.817875 IP A.B.C.D.5004 > 239.192.84.97.5004: UDP, length 1452
19:03:30.818818 IP A.B.C.D.5004 > 239.192.84.101.5004: UDP, length 1452
19:03:30.820316 IP A.B.C.D.5004 > 239.192.84.99.5004: UDP, length 1452
19:03:30.820360 IP A.B.C.D.5004 > 239.192.84.98.5004: UDP, length 1452
19:03:30.822320 IP A.B.C.D.5004 > 239.192.84.97.5004: UDP, length 1452
19:03:30.822331 IP A.B.C.D.5004 > 239.192.84.100.5004: UDP, length 1452
19:03:30.823858 IP A.B.C.D.5004 > 239.192.84.101.5004: UDP, length 1452
19:03:30.825321 IP A.B.C.D.5004 > 239.192.84.99.5004: UDP, length 1452
19:03:30.825367 IP A.B.C.D.5004 > 239.192.84.98.5004: UDP, length 1452
19:03:30.828363 IP A.B.C.D.5004 > 239.192.84.100.5004: UDP, length 1452
19:03:30.828537 IP A.B.C.D.5004 > 239.192.84.101.5004: UDP, length 1452
19:03:30.828537 IP A.B.C.D.5004 > 239.192.84.97.5004: UDP, length 1452
19:03:30.829872 IP A.B.C.D.5004 > 239.192.84.99.5004: UDP, length 1452
19:03:30.830828 IP A.B.C.D.5004 > 239.192.84.98.5004: UDP, length 1452
[…]

Setup (stripped-down):

networking = {
  firewall = {
    enable = true;
    extraInputRules = "ip saddr A.B.C.D counter drop";
  };
  nftables.enable = true;
};

This results in the following nftables rules set:

[root@host:~]# nft list ruleset
table inet nixos-fw {
        set temp-ports {
[…]
        }

        chain rpfilter {
[…]
        }

        chain rpfilter-allow {
        }

        chain input {
[…]
        }

        chain input-allow {
[…]
                ip saddr A.B.C.D counter packets 0 bytes 0 drop
        }
}

And as you can see, no packets get dropped and I don’t no why … :frowning:

Has someone any idea?
(I tried the whole day. Starting with iptables and I also tried firewall rules w/ and w/o protocol/port/… #everything)

Thank you in advance and best regards!

1 Like
2

I’m no expert in nftables, but looking at a few online resources + the NixOS options for it, I came up with the following: (block-multicast-abuser can be changed to whatever you desire, it’s just the name of the rule table)

networking.nftables.tables.block-multicast-abuser = {
  family = "ip"; # Use `inet` for both ipv4 and ipv6 if necessary
  content = ''
    chain input {
      ip saddr 239.192.84.97–239.192.84.101 dport 5004 drop
    }
  '';
};

This will (hopefully) drop incoming traffic from those specified IPs on that specific port. You can, of course, omit the port and straight up block the IPs.

I really want to know if this works or not. So please post an update if you decide to try this!

1 Like
3

The multicast address would be the destination address, OP would have to swap in the source addresses. Chain input is likely what is wanted, agreed on that.

Also, that is probably moot in most regards anyway. Without an active multicast listener/subscription, it should be dropping all unwanted/unneded traffic receives.

Is the server subscribed to an mcast stream of any variety? Modern multi-cast routing typically prunes it to not waste bandwidth.

2 Likes
4

Thank you @Kaukov for your input!

I tried:

nftables = {
  enable = true;
  tables.block-multicast-abuser = {
    family = "ip"; # Use `inet` for both ipv4 and ipv6 if necessary
    content = ''
      chain input {
        ip saddr A.B.C.D counter drop
      }
    '';
  };
};

Edit: I made a mistake, see post #7

This changed the nftablesrules set.
It moved my rule from the chain input-allow in the nixos-fw table to the input chain in a new block-multicast-abuser table:

[root@host:~]# nft list ruleset
table ip block-multicast-abuser {
        chain input {
                ip saddr A.B.C.D counter packets 0 bytes 0 drop
        }
}
[…]

But … The traffic is still there, also after a reboot … :face_with_raised_eyebrow:

Thanks for suggesting!

2 Likes
5

Thank you too, @Michael-C-Buckley!

To be fair, I’m not very experienced with that stuff (you are talking about) … #sry Maybe you can be more detailed and give me a concrete example?

So here is a bit more background, which may not(?) help, but for better understanding.

I bought (from a reseller) a Root Server at netcup in October and had no time to play w/ it.
In November I booted up a NixOS Installer ISO, tried multiple (NixOS/nix/flake/CLAN/flake-parts/Sops/Agenix) things, but didn’t finish.
Yesterday I had some spare time again, looked at the virtual console of the server and found that the installer was still running. I played a bit (again) and detected some strange bandwidth usage. – Then I looked at the netcup adminsitration panel and saw the bandwidth usage for (only) December: >700GB :face_in_clouds:

So today I wanted to tackle the mystery and at the end I came up w/ the conclusion that the traffic is coming in from a IP address within the same data center (at netcup). And I think the previous owner of the server had another server, where my IP is hard-coded or so …

I contacted the prev. owner and found out, that the person also bought the server from another one, some months ago, I contacted that person and now I’m waiting …

ATM (like from the beginning) the machine only has a running SSH service, nothing else.
The setup is w/ IPv4 and IPv6, uses systemd-networkd and resolved, most parts are straight from the wiki … I had ~70 derivations/builds and multiple reboots.

So far … KR

6

I’m not an expert in Multicast UDP, but from what I understand, the A.B.C.D server is sending UDP packets to the Multicast address, and the datacenter’s router is what’s forwarding them to your IP.

They can’t be blocked because your IP stack is rejecting them early, because they don’t match your IPs, and your kernel doesn’t have any active multicast listener ports. you can only see them in tcpdump, because it collects traffic before it goes through all the input filtering.

Unfortunately there is not connection to drop, but you can potentially ask your upstream router to remove you from the mcast group. the following should send an IGMP Group Leave packet to remove you from the group.

for group in 239.192.84.{97..101}; do
  ip maddr del $group dev <interface>
done
2 Likes
7

Thank you @twoolie, too – especially for the explanation!

1st: I think this thread is out of the scope of nix/NixOS. (As explained, the firewall can’t block, so it’s no issue w/ the NixOS firewall …)

2nd: I tried leaving the IGMP Group as @twoolie suggested, which wasn’t possible.

[root@host:~]# ip maddr del 239.192.84.97 dev enps3
Error: Invalid address length 4 - must be 6 bytes

3rd: I saw I made a mistake in my response to @Kaukov (see post #4).
I used the remote IP address (A.B.C.D) for the input chain, where he suggested to use the multicast addresses. #meaculpa
I tried again, w/o any differences.
FYI: I triedip saddr 239.192.84.97-239.192.84.101 udp dport 5004 counter drop and also (as @Michael-C-Buckley wrote) with the swapped addresses.

ATM I’m uncertain if I/we should discuss/find a solution to this problem in this forum.
There are so many question marks in my head about this multicast topic …
Anyway, I’ll leave some of them here and I’m fine w/ no response. I think I’ll post the final solution, if it happens.

Multicast subscription(s)?

@Michael-C-Buckley asked

Is the server subscribed to an mcast stream of any variety?

IMHO yes, but as far as I see/understand, not relevant to the problematic UDP traffic/subnet(s).
Here is the (IMHO relevant) output (, which also looks relatively normal/default for a NixOS machine):

[root@host:~]# ip -4 -o maddr show ens3
2:      ens3\   inet  224.0.0.252
2:      ens3\   inet  224.0.0.1

Why I get that traffic?

And as far as I understood, w/o a subscription to a group/a membership – regarding the topic, e. g. to 239.192.84.97– I can’t leave/unsubscribe the group/subscription/membership, which should be the reason why ip maddr del 239.192.84.97 dev enps3didn’t succeeded.

Is it real traffic?

If I’m not subscribed and (as discussed) there is no listener and the input filtering isn’t reached and my machine isn’t processing the traffic, why is the traffic shown in iftop, nethogsand calculated at netcup …? Is unprocessed incoming traffic real?

That’s it for the moment from my side. (It’s exhausting and until now I do not understand how I can have such a problem w/o doing anything wrong …)

Thank you all, community! I think you will hear from me again …

8

Is unprocessed incoming traffic real?

Of course it’s real: the ethernet card is demodulating those signals into bits, the kernel is decoding those bits and turning them into IP packets, but there’s no userspace process that wants them, so the kernel ultimately drops them.

1 Like
9

It’s real traffic as far as bandwidth consumption is concerned. It’s “not” real in that your system isn’t requesting or listening for that traffic so it’s actually dropping all of it as irrelevant.

1 Like
10

I was wrong about the addresses and mistakingly suggested the multicast addresses instead of the incoming address. @Michael-C-Buckley was very quick to point it out in his comment below mine.

Other than that - I think you’ve received plenty of answers by people with way more knowledge than me. I hope you resolve your issue soon!

1 Like
11

I read the doc for this wrong, it looks like ip wants a mac address here, not an IP. try:

nix-shell -p smcroute --run "smcroute -l enps3 239.192.84.97"

I don’t think this problem is too off-topic, since nixos does ship with smcrouted , mrouted, and FRR. I don’t think there’s modules for these tools though which is probably an oversight.

1 Like
12

Hey everyone (involved in this thread)!

Unfortunately I have no real news, regarding my original problem. But I will shortly finalise this thread …

I got no response from the original server owner.
So I wrote a support ticket to the netcup support team, which responded (after some back and forth) like this:

The problem was caused by one of our customers. He has now solved this.

That’s it – the traffic is gone …
Happy new + good year at all! :slight_smile:

2 Likes