red0ct's questions

Here I faced with a bit strange rule:

iptables -A INPUT -s 10.26.95.20 -j REJECT --reject-with tcp-reset

This rule matches all the protocols from specific network and rejects it with TCP RST packet.
How is this supposed to work with non-TCP packets? If other end (10.26.95.20) sends UDP packet it then receives TCP RST? This looks extremely strange..

When I researched some methods of DDoS protection I faced with some firewall rule which limit packets with RST bit set to 60 per second. Indeed it makes some sense. But it also doesn't check the other flags.
For me it seems that packets with RST flag set and also some other flags set are invalid, so we can drop/reject it.

The questions is: can in practice we see valid TCP RST packets along with other TCP flags (bits) set?

Here is the Linux Iptables rule I'm talking about:

iptables -A INPUT -p tcp --tcp-flags RST RST -m limit --limit 2/s --limit-burst 2 -j ACCEPT

I think it should be something like:

iptables -A INPUT -p tcp --tcp-flags ALL RST -m limit --limit 2/s --limit-burst 2 -j ACCEPT

Source: IPtables DDoS Protection for VPS

I want to reduce the priority of specific network traffic using tc in particular tc-u32 in my Linux server. In other words all other traffic must have higher priority than traffic with specified IP-proto.

I'm trying to apply this tc filter rule to make outgoing ICMP traffic lower priority:

tc f a dev eno1 parent 1: prio 2 u32 match ip protocol 1 0xff

But it returns this error:

RTNETLINK answers: Invalid argument
We have an error talking to the kernel

Here are some things are still unclear to me about tc in this context:

1. How to make this rule work properly?
2. Do I need some another rule to tell Linux something like "all other traffic goes with 1 priority" or this is done by default?
3. What is the basic logic behind such naming - 1:, 2:, etc.? What does 0xff mean? Should I explicitly specify classid field?