Hi all,
i’m not very skilled in networking except that i know some basics.
Anyway, i set FW rule to drop incoming connections from this IP 141.98.80.115
But everyday i see in the logs that this IP is trying to get access to my router.
Added picture..
What can i do further to ban this IP ?
Thanks
Create a firewall to drop it before any rules to accept PPTP input.
Add this
/ip firewall raw add action=drop src-address=141.98.80.115
Does not work. You need to tell what chain to use. example.
/ip firewall raw add action=drop src-address=141.98.80.115 chain=input
right, that’s what you get for writing commands from memory…
/ip firewall raw add action=drop src-address=141.98.80.115 chain=prerouting
Thx!
I wouldn’t advise to use raw-prerouting rule. It might have negative impact on speed of all (including fasttracked) connections. Original idea with filter-input rule was was better. It was probably just incorrectly placed on the end of all rules.
Raw-prerouting is great for specific purpose - when you need to drop packets before conntrack, in order to minimize potential resource consumption in flood-type situations. Since this is not a (D)DoS, it will have more negative, than positive consequences because ROS can’t peacefully skip the RAW table and has to test every single packet going through router against this rule
I wouldn’t advise to use raw-prerouting rule. It might have negative impact on speed of all (including fasttracked) connections.
…
it will have more negative, than positive consequences because …
This is based on what factual info / data?
It a rule base system like any other table (filter,nat,mangle) in linux kernel.
The filter table firewall rules are usually structured so that packets which belong to established connections only hit a minimal number of rules: One of the first rules in the filter table input chain is to accept packets belonging to established and related connections. These are the vast majority of packets, so if they need to pass many rules before they are accepted, the CPU load will be high. You really want to base complicated decisions only on the first packet of a “connection”. The raw table is checked before the filter table, so every packet will hit any rule you put there before it can be accepted in the filter table input chain by the “accept established, related” rule. This is bad even without fasttracking.
The order of rules matters: Rules which accept packets that occur frequently or with sensitive timing should be higher in the list of rules. Packets belonging to established connections occur much more frequently than any other type of packet, so these should be handled at the very top of the list unless something else absolutely needs to be done first. Filtering out SYN packets from one particular IP address which appear only infrequently is definitely not more important. The raw table rules are higher on the list than the filter table rules. Don’t filter there.
I asked for factual info & data, not some gut feelings and expectations!
…to pass many rules before they are accepted, the CPU load will be high…
Can you prove it? Tik can easily handle hundreds of rules with no / minimal impact (caveat: as long as no heavy matchers are used)
This is bad even without fasttracking.
Prove it!
Your logic is wrong (1) and I can prove it on real system(2).
(1)
One of the first rules in the filter table input chain is to accept packets belonging to established and related connections.
(BTW: that depends on configuration)
And how do you imagine all those packets are matched to existing table of connections? By MAGIC?
for each packet some cpu cycles will be used to compare with existing list of connections and determine if it’s established or related to them and if they can be allowed to pass
(2)
I DO have rules in raw table, and whether I enable them or disable there is NO measurable impact on cpu load with heavy traffic throughput.
So come with founded data + info, or don’t bother…
… which might be thousands of comparisons if that many connections are tracked by FW at given time. Compared to that, a few (hundred) raw rules is peanuts …
Actually, no.
Things like tracked connections (and also address lists) are stored in a clever way so the match can be made more quickly than by checking them all.
For example, by storing them in a sorted tree, often sorted by a hashvalue of the keys used to look them up. That way, to find the match in a collection of N items does not require N/2 comparisons (on average) but more like 2Log(N).
On the other hand, with a few hundred raw rules the only way to check them all is to check them one by one, top to bottom, because that is how they are defined to work.
If we’re speculating: why should raw rules be stored any differently than tracked connections? Because typically they only contain a fraction of information compared to tracked connections?
But then, the connection tracking engine should update state of the connection (to check if e.g. TCP connection got FIN or RST) and for that it has to touch individual connection in the list (however it might be sorted). Which indeed means that connection list should be searchable very efficiently. All of it doesn’t mean that raw rules couldn’t use similar mechanizm.
Because the manual states that raw rules are processed sequentially from top to bottom. So that is the only way they can be matched. First check the first rule, if it matches perform its action, then check the second rule, if it matches perform that action, etc etc. (or until the passthrough flag is not set for a matching rule).
Tracked connections, however, are not in any predetermined sequence. When a packet comes in and the corresponding connection is to be looked up, there is no need to touch them all. A clever method can find the correct connection in only a few tries, even when there are many.
@pe1chl Don’t get me wrong, in fact everytime MKX is wrong I do a happy dance and treat myself to a nice cold beer! BUT…
“Things like tracked connections (and also address lists) are stored in a clever way so the match can be made more quickly than by checking them all.”
Appears to be an assumption/speculation/opinion UNLESS one can provide references and/or threads were MT staff have stated such indepth knowledge of MT code.
Awaiting your clarification, music cued, opener poised on the beer bottle… 
I try really hard not to be wrong too often because I don’t want you to become alcohol-addict
What pe1chl writes makes much sense to me.
The Linux kernel code is open source. You can look it up yourself. This is the Mikrotik Beginner Basics forum, not a technical debate club.
…to pass many rules before they are accepted, the CPU load will be high…
Can you prove it? Tik can easily handle hundreds of rules with no / minimal impact (caveat: as long as no heavy matchers are used)
Just because your router has enough CPU power to handle an inefficient firewall design doesn’t mean it generally doesn’t matter.
One of the first rules in the filter table input chain is to accept packets belonging to established and related connections.
(BTW: that depends on configuration)
Yes, it does depend on configuration. You can run without connection tracking, without a firewall or with just a stateless firewall, but the default configuration (not the blank configuration) comes with a stateful firewall configuration that has an “accept established, related” rule very high in the filter table input/forward chains. Beginner Basics forum, remember?
And how do you imagine all those packets are matched to existing table of connections? By MAGIC?
The Linux kernel (which is at the heart of every Mikrotik router) uses hash tables for connection tracking. The kernel does not search a list to find the matching connection for a packet. A hash table is a “constant time” data structure. In contrast, every packet needs to be checked against every firewall rule (in order) until a packet is accepted, rejected or dropped.
for each packet some cpu cycles will be used to compare with existing list of connections and determine if it’s established or related to them and if they can be allowed to pass
Yes, except it’s not a comparison with a list but essentially a constant time lookup, and unless you don’t use connection tracking for a particular packet, this happens anyway, so checking packets which belong to already established connections against additional rules adds unnecessary overhead to the processing of these packets. This matters when the router is operating close to its maximum throughput.
I DO have rules in raw table, and whether I enable them or disable there is NO measurable impact on cpu load with heavy traffic throughput.
So come with founded data + info, or don’t bother…
It’s really common sense that the order of firewall rules matters, if you’ve read the iptables documentation. Anyway, does Mikrotik documentation count?
https://wiki.mikrotik.com/wiki/Tips_and_Tricks_for_Beginners_and_Experienced_Users_of_RouterOS#Ease_load_on_firewall_by_sorting_firewall_filter.2C_NAT_and_mangle_rules
Useless ref in regard to the question posed… looking for a reference that the router processes filter rules of accepted/related more efficiently than other firewall filter rules in general and specifically better than raw rules. If it was so important and so clear, then it would be in a wiki and not force users to learn linux, open up the source code and make the necessary conclusion.! What planet did you say you were from???
Nobody said anything like that. Each rule that needs to be checked takes some time, When processing a packet that belongs to an established connection, i.e. the vast majority of packets, a rule that comes before the “accept established, related” rule (regardless of the table it is in) takes more time than a rule that comes after it. The rather obvious reason for this is that a rule which comes before the “accept established, related” rule needs to be processed, but a rule that cames after it does not need to be processed, because the “accept established, related” rule has already accepted the packet.
Once more, Mikrotik says the order of firewall rules matters, in their wiki: https://wiki.mikrotik.com/wiki/Tips_and_Tricks_for_Beginners_and_Experienced_Users_of_RouterOS#Ease_load_on_firewall_by_sorting_firewall_filter.2C_NAT_and_mangle_rules
Here’s what happens when you filter in the raw table and a packet belonging to an established connection arrives:
Here’s what happens when you filter in the filter table, after the “accept established, related” rule, and a packet belonging to an established connection arrives:
This takes less time. It’s literally the same work minus the raw table filter rule checking. And because this affects the vast majority of all packets, this is the right way to do it. The other way works too, but it’s less efficient.
Filtering in the raw table can sometimes make sense in cases where an extreme amount of traffic arrives that is to be dropped before it can register a “connection”, e.g. UDP traffic or traffic to be dst-natted (“portforwarding” in most router speak).
But in this case there is no extreme amount of traffic, and it is to be dropped mainly to keep the log clean. The proper place to do that indeed is after “accept established,related” and before “accept this traffic from everyone”, in the filter table.
When there is more than one address to be filtered, the proper way of doing it is with a single rule in the firewall table using an “address list” for the source address match, with the addresses to be matched inserted in the address list.
That is because an entry in an address list can be looked up quite quickly and there is no (linear) increase in the processing time when there are more addresses in the table, as there would be when more and more rules are added to the firewall filter table.
Furthermore, with an address list you can configure the router to automatically insert the address in the list, temporarily or permanently, when some conditions are met. So you can auto-block addresses when you like.
(but always be very careful with that, certainly as a beginner. you need to know what you are doing and what can be the consequences when auto-blacklisting addresses!)
Okay that makes more sense now.