Because, I have to add same rule to filter table and mangle table
like this
For filter table
;;; Block Fake DNS Record 49.50.69.28
chain=input action=drop layer7-protocol=49.50.69.28 protocol=udp src-address-list=My DNS in-interface=Telecom src-port=53
packet-size=60-180
This above rule can be filter for ros itself.
For mangle
;; Block Fake DNS Record 49.50.69.28
chain=prerouting action=change-ttl new-ttl=set:0 passthrough=yes layer7-protocol=49.50.69.28 protocol=udp
src-address-list=My DNS in-interface=Telecom src-port=53 packet-size=60-180
Even if TTL set to 0 because no drop action in mangle table so ros is able to receive the fake dns record, I have to set similar rule in filter table to filter the same fake dns record.
If raw table can be support L7 function that will one filter rule can get same result.
You could try the “content” field in RAW. I am now using it since a few hours after reading your posting and it works well to detect a IP in a http stream.
On RAW and content I had some strange behaviour that have to look into. I had to invert (!) the content field to have the content field to been seen by Mikrotik if Fasttracking is enabled. If you disable for testing Fasttracking in the Rules tab and test again does it then works?
It didnot worked. My environment did not have fast track rules. I think Fast track will not come into effect in RAW table, Because RAW table handles the packet highest priority than filter nat mangle table.
I learned the hard way that RAW will get the packet first, but what if the the package you want to catch is further up in the stream. Fasttrack will take over because the connection is established. I have changed the fasttrack so that it only will help traffic that I generate internal. From external is exempted from Fasttrack and will have to go through the rules.
OK
I added fast track in filter table and mangle table added it automaticlly,
test content 180.168.41.175 and HEX(\xB4\xA8)\xAF) in RAW table still not worked.
Hahaha fasttrack is making it more difficult to detect content so not activating makes testing easier. Then you can switch it on and tune your settings and have advantage of the acceleration offered by fasttrack.
You are looking for IP 180.168.41.175 and regex is only applicable in L7. I have not read about any limitations (lentght/number of packages) of the content field like there is for L7.
Did you have a look with package sniffer or WireShark if the IP is writen in that way because some time you see them being reversed (175.41.168.180).
I just don’t know enough about this part and lets hope someone with more knowledge will pay attention to your question.
master wrote:
Hahaha fasttrack is making it more difficult to detect content so not activating makes testing easier. Then you can switch it on and tune your settings and have advantage of the acceleration offered by fasttrack.
You are looking for IP 180.168.41.175 and regex is only applicable in L7. I have not read about any limitations (lentght/number of packages) of the content field like there is for L7.
Did you have a look with package sniffer or WireShark if the IP is writen in that way because some time you see them being reversed (175.41.168.180).
I just don’t know enough about this part and lets hope someone with more knowledge will pay attention to your question.
I disabled fast track rules when I finished tested
This IP was pushed by the DNS server when it has non dns record.I used Wireshark and never saw the reversed address of 180.168.41.175 before.
Thank you for your zealous help and hope someone can help me also.
about L7: as far as I remember, L7 rules require Connection Tracking, so they are not possible in RAW table
It worked in Filter table when ROS as DNS server.
I forgot whether L7 needs connection tracking. I tested the rule in Linux, it worked. See below.
iptables -t raw -A PREROUTING -p udp --src 202.96.209.5 --sport 53 -m string --algo bm --hex-string “|B4A829AF|” --from 60 --to 180 -j DROP
ROS as DNS server their rules worked in Filter table, when built a slave DNS server via ROS to get the DNS record, they did not work except ROS had similar rules in Mangle table,
I want one new rule that can take effect to replace the old rules in both Filter and Mangle table. So I propose the developer team to solve the problem.
Yes If I only have one DNS server whatever ROS itself or dedicated DNS server, you are right.
For my environment, I have to build 2 rules for ROS and dedicated DNS server.
I just want that the data packet enters into the Filter/Nat table before, ROS can first deal with the data, Because I can use one rule for both DNS servers.
One rule means less system overhead and shorter operation time, right？
wrong if one rule is in ‘output’ chain and one is in ‘forward’, each packet goes to only one of them, not both. so each packet is being processed by only one rule. no overhead
I understand what you mean.
add one rule in filter table output chain add another one in filter table forward chain, right?
No additional overhead bcoz each packet goes through different chain.
But this condition just for a spot of IPs only.
If I want to block hundred IPs they are too many rules in output and forward chain.
DNS cache pollution by GFW, If I use public DNS server like 8.8.8.8 that will lose CDN effective, So I have to block all fake IPs from local ISP DNS servers.
if one rule is in ‘output’ chain and one is in ‘forward’, each packet goes to only one of them, not both. so each packet is being processed by only one rule. no overhead