On Sun, 3 Nov 2024, at 7:51 AM, Lars Noodén wrote: > Greetings, > > There is some discussion on another list about dealing with the problem > of a type of spoofed SSH connection. Here is a description of the > problem, along with how to use tcpdump to identify it: > > https://delroth.net/posts/spoofed-mass-scan-abuse/ > > One solution offered in a message on the other list was to add the > following rule into its own table: > > nft add rule ip accounting input \ > tcp sport 22 tcp flags == syn\|ack counter > > The following seems to load without error and I have some beginner level > questions. Specifically, I wonder how or if it does the job. For that rule to be of any conceivable value, you would have to refrain from ever using your host to connect to an instance of sshd(8) that is listening on port 22. Moreover, it does not account for RST backscatter, should that be the job in question. > > Also, > > 1) Do port 22 IPv4 packets pass through both tables? They seem to. But > how can I verify that? To verify such for packets that arrive at your host, create a chain bearing the hook: type filter hook prerouting priority raw; policy accept; Populate the chain with rules that match the packets you are interested in, and which conclude with "meta nftrace set 1". The manner in which said packets traverse your ruleset may then be determined by running "nft monitor trace". The chain in question may reside in any table as long as the table bears the relevant address family. > > 2) Is a second similar table needed for IPv6? IPv6 packets can only be hooked within tables that are defined with either the "ip6" or "inet" address families. Whether you would prefer to have separate tables for IPv4 and IPv6 or leverage the "inet" family to cover both would be for you to decide. -- Kerin Millar
