Drop connections or drop packets?
Hello. Should we mark connections and then packets in order to drop packets? or Could we just mark and drop connections?
Re: Drop connections or drop packets?
Default SOHO setup does not bother with marking anything, just drops connection in /ip firewall filter...
Re: Drop connections or drop packets?
The Filter process at connection level or a packet level?
Re: Drop connections or drop packets?
Filter in principle works on connection level. However ....
ROS implements a feature called "fast track", which largely bypasses firewall functions for packets belonging to certain connections (depends on other parameters of enabler command, default setup is to use this feature for all established and related connections). When this feature is enabled, ordinary filters only deal with packets belonging to new (and invalid) connections, which are relatively rare, and performance of filter rules is normally not a huge concern.
If you want to deal with traffic on packet level, you can use /ip firewal raw rules ...
ROS implements a feature called "fast track", which largely bypasses firewall functions for packets belonging to certain connections (depends on other parameters of enabler command, default setup is to use this feature for all established and related connections). When this feature is enabled, ordinary filters only deal with packets belonging to new (and invalid) connections, which are relatively rare, and performance of filter rules is normally not a huge concern.
If you want to deal with traffic on packet level, you can use /ip firewal raw rules ...
Re: Drop connections or drop packets?
In fact what I want is to block traffic the most efficient way in terms of accuracy and performance. I assume that the filter rules inspects every packet of a connection. Then connections should be mangled first in order to be filtered the most efficient way just inspecting the mangle marks of every packet. Am I wrong?
Re: Drop connections or drop packets?
As I mentioned, /ip filter raw works more or less directly on packets without notion of connections.
Then at some intermediate moment, there comes connection tracking which is a quite expensive operation. However, stateful firewalls have to do it and firewall in ROS is a stateful one. If you don't need connection tracking, you can disable it.
And after that, /ip firewall filter rules kick in. As I already wrote, when connection is tracked, it is possible to take some shortcuts. E.g. have a filter rule which allows all packets belonging to established connections and related connections. So we have single firewall filter rule which deals with vast majority of packets. Packets that are left have connection state either new (and we have to apply additional filter rules to determine whether we pass those packets or not), invalid (probably we want to drop those) or untracked (its up to particular config whether to pass those or not).
Keep in mind, that firewall filter rules are executed against packet in order as they are listed from top to bottom. So it's good to have filter rules which either pass or block most packets at the top of the list (on the other hand more specific rules have to precede more general rules which might trigger on same packets). So if we place the "accept established&related" rule to the top of rules, then vast majority of packets get matched only against a single rule matching connection state. It is not possible to construct such a rule in raw where connection states are not known (yet).
Remember: if packets, initiating new connection, are blocked/dropped, then such connection can never reach state "established" and further packets belonging to such blocked connection are then considered invalid - if connection initiator is not some malware, then further packets normally don't arrive.
And then there's the feature I wrote about: fast-track. It's a bit of magic what and how it works, but if used efficiently it reduces firewall resource consumption quite dramatically. It marks connections to bypass most of firewall and thus speeding up firewall processing a lot.
Probably it is not as fast as it would be with disabled connection tracking (fast-track can't work without connection tracking), but with disabled connection tracking firewall raw would have to deal witl just every packet passing router.
You may refer to packet flow description ... it's heavy to read, but after one manages through it is good information.
BTW, it shows that connection tracking for ingress packets is done even before mangling, only raw prerouting is done earlier.
Then at some intermediate moment, there comes connection tracking which is a quite expensive operation. However, stateful firewalls have to do it and firewall in ROS is a stateful one. If you don't need connection tracking, you can disable it.
And after that, /ip firewall filter rules kick in. As I already wrote, when connection is tracked, it is possible to take some shortcuts. E.g. have a filter rule which allows all packets belonging to established connections and related connections. So we have single firewall filter rule which deals with vast majority of packets. Packets that are left have connection state either new (and we have to apply additional filter rules to determine whether we pass those packets or not), invalid (probably we want to drop those) or untracked (its up to particular config whether to pass those or not).
Keep in mind, that firewall filter rules are executed against packet in order as they are listed from top to bottom. So it's good to have filter rules which either pass or block most packets at the top of the list (on the other hand more specific rules have to precede more general rules which might trigger on same packets). So if we place the "accept established&related" rule to the top of rules, then vast majority of packets get matched only against a single rule matching connection state. It is not possible to construct such a rule in raw where connection states are not known (yet).
Remember: if packets, initiating new connection, are blocked/dropped, then such connection can never reach state "established" and further packets belonging to such blocked connection are then considered invalid - if connection initiator is not some malware, then further packets normally don't arrive.
And then there's the feature I wrote about: fast-track. It's a bit of magic what and how it works, but if used efficiently it reduces firewall resource consumption quite dramatically. It marks connections to bypass most of firewall and thus speeding up firewall processing a lot.
Probably it is not as fast as it would be with disabled connection tracking (fast-track can't work without connection tracking), but with disabled connection tracking firewall raw would have to deal witl just every packet passing router.
You may refer to packet flow description ... it's heavy to read, but after one manages through it is good information.
BTW, it shows that connection tracking for ingress packets is done even before mangling, only raw prerouting is done earlier.
Re: Drop connections or drop packets?
Thanks mkx for such good info. I had the impression that mangling connections was mandatory in order to do an efficient filtering. I used to think that filter was made at packet level.
Re: Drop connections or drop packets?
Filtering, and any other firewall operation, is always made at packet level. But if connection tracking is enabled, each packet gets labeled with one of the connection-state labels: new,untracked,established,related,invalid as Metod has stated, at most two connection-nat-state labels: srcnat and/or dstnat, at most one connection-mark (which is assigned by means of mangle rules), and some attributes of the connection related to rate and total amount of bytes transported; all these metafields are attached by the connection tracking module to every packet it handled. action=notrack in /ip firewall raw makes matching packets avoid connection tracking which is otherwise activated.
So all the firewall rules always handle individual packets, but on top of the actual packet headers, rules in all tables except raw can match on the metafields listed above. It is not mandatory to use these metafields if you don't need to use the features of a stateful firewall. Also, there is no way to drop a connection, in the sense of removing it from the list of tracked connections, by means of any action of a firewall rule, except maybe by rejecting a packet (rather than just dropping it) which belongs to that connection, and I am far from sure that all reject-with types cause the connection to be dropped. If you just drop a packet which belongs to a tracked connection, it won't change anything about the connection state, so you can e.g. imitate a lossy network by randomly dropping one packet out of every 50 without breaking the connection state. But you can e.g. implement "drop all packets of a connection which has exceeded a given number of bytes" by adding a drop rule before "accept established,related" which states a threshold value for connection-bytes. This won't remove the connection from the tracking table as such, but will prevent the actual communication from proceeding, so the remote end will give up after some time due to absence of any response, so the tracked connection will time out or, in case of TCP connections, be removed due to an arrival of a RST packet from either endpoint.
So all the firewall rules always handle individual packets, but on top of the actual packet headers, rules in all tables except raw can match on the metafields listed above. It is not mandatory to use these metafields if you don't need to use the features of a stateful firewall. Also, there is no way to drop a connection, in the sense of removing it from the list of tracked connections, by means of any action of a firewall rule, except maybe by rejecting a packet (rather than just dropping it) which belongs to that connection, and I am far from sure that all reject-with types cause the connection to be dropped. If you just drop a packet which belongs to a tracked connection, it won't change anything about the connection state, so you can e.g. imitate a lossy network by randomly dropping one packet out of every 50 without breaking the connection state. But you can e.g. implement "drop all packets of a connection which has exceeded a given number of bytes" by adding a drop rule before "accept established,related" which states a threshold value for connection-bytes. This won't remove the connection from the tracking table as such, but will prevent the actual communication from proceeding, so the remote end will give up after some time due to absence of any response, so the tracked connection will time out or, in case of TCP connections, be removed due to an arrival of a RST packet from either endpoint.
Re: Drop connections or drop packets?
I got confused again. Let's face this in practical terms. Considering connection tracking enabled, if I want, in the most efficient way, to block traffic identified by a specific protocol, ports and a long address list, should I apply directly a filter rule o mangle the connections first? And, should I filter or mangle just connection-state:new packets?
Re: Drop connections or drop packets?
Mangle is the wrong tool for this job. Firewall can block connections with these parameters most straightforwardly.
If you are rejecting or accepting traffic on connection-based protocols (e.g., not UDP), you should always use connection-state=new. This causes the firewall rule to be checked only once per connection, instead of for every subsequent packet in the connection, which is very inefficient.
If you are rejecting or accepting traffic on connection-based protocols (e.g., not UDP), you should always use connection-state=new. This causes the firewall rule to be checked only once per connection, instead of for every subsequent packet in the connection, which is very inefficient.
Re: Drop connections or drop packets?
ROS firewall fakes connection state for UDP connections. Might not be as accurate as for statefull protocols, but helps to make constructing firewall filter rules easier. Probably helps for performance as well.
Re: Drop connections or drop packets?
ROS firewall fakes connection state for UDP connections. Might not be as accurate as for statefull protocols, but helps to make constructing firewall filter rules easier. Probably helps for performance as well.
Good to know, thanks. I've never had reason to block UDP.
Re: Drop connections or drop packets?
Thanks for your answers.
Who is online
Users browsing this forum: Ahrefs [Bot], rextended and 102 guests