I grabbed an APP packet with the package grabbing tool，0000 14 5f 94 0f 0a ef 00 76 aa 10 1e c9 08 00 45 00 ._…v…E.
0010 00 a2 de 0a 40 00 36 11 54 c4 3d 81 08 64 c0 a8 …@.6.T.=..d..
0020 0a ef 79 c1 a3 1a 00 8e 41 30 00 01 00 00 13 15 ..y…A0…
0030 00 00 00 00 01 00 33 66 00 09 00 09 40 13 00 00 …3f…@…
0040 00 16 03 00 00 00 18 00 00 00 5e 02 10 37 78 9c …^..7x.
0050 63 60 60 e1 66 60 60 ba ca 00 02 2c 39 cf 99 59 c.f…,9..Y
0060 18 18 44 32 18 e4 98 99 80 7c b3 66 86 a9 bc 40 ..D2…|.f…@
0070 06 b3 40 f3 ff 1d 4d 40 06 d7 83 16 46 b0 4a 06 ..@…M@…F.J.
0080 91 74 06 61 26 a8 9a c9 3c 50 35 47 1b 81 12 69 .t.a&…<P5G…i
0090 08 cd bd dc 50 89 cb 0d 10 cd 0c 50 cd a9 08 cd …P…P…
00a0 f5 5c 10 35 0c ee f5 00 07 cf 16 c0 9e c6 14 57 ..5…W
I tried to match 33 66 00 09 00 09 40 13， and I wrote the command /ip fi l add name=test regexp=“\x33\x66.?\x09.?\x09\x40\x13”
A rule was added to firewall，
The same data is sent repeatedly
There is no traffic passing through the rules.
Can anybody help me?
First, the regexp matching in L7 skips \x00 bytes as if they weren’t in the packet at all.
Second, it is not enough to define the match regexp in /ip firewall layer7-protocol, you have to use it as matcher in a rule in /ip firewall filter to see whether it works or not.
thanks
Yes, I added rules to the filter rules, which is also ineffective. Then how should I write L7 to match? Can you give me an example?
It is not “also” ineffective - it doesn’t match because the L7 regexp doesn’t match the pattern.
The whole /ip firewall layer7-protocol config branch is basically just a way to keep the filter rules readable, instead of putting the (often lengthy) regexp pattern directly to the line specifying the filter rule, you give them a short symbolic name to which you then refer from filter. So without being referred to, it does nothing; when referred to but it doesn’t match, the filter rule referring to it doesn’t match as a whole.
In this case you don’t actually need L7 because there is no variable part in your pattern. So another matcher - content, which is used directly in filter rules and has a slightly different syntax and doesn’t work with regular expression matching, just mere string matching, but should happily match zero bytes, is better for your puspose. Give it a try: /ip firewal filter add place-before=0 action=log content=“\33\66\00\09\00\09\40\13”. Don’t be surprised that print will show something different, only hard to display bytes are displayed in the \xx form.
hi Brother , you solved my big problem. I love you. 
I want to get the target address by matching the data. And it’s not a local address. For shunting to other routes, what should be done if there is a change in a single Hex in the matching data, such as 33 66 00 09 09 4013 to 33 55 or 33 44 or others。So how should we solve it?Thank you very much.
I’m not sure I get you right, especially the “shunting to other routes”. But I assume you need to choose a specific route and/or to change the packet’s destination address if it has a particular contents, and that, after all, part of the match pattern within the contents is variable while the rest is fixed. The only thing I can suggest here is to find the longest fixed sequence of bytes which is the same in all the packets of interest, match it using the content matcher in a rule with action=jump jump-target=l7-analysis, and in that new chain, use a single rule which would refer to a layer7-protocol regexp matching the signature sequence again, this time with . in place of the variable bytes and nothing at all in place of the bytes which are always zero and with the final action to take (which would likely be mark-connection if this whole setup is used in mangle table to choose a specific route, or dst-nat if it is used in nat table to redirect the packet to another destination address).
If the variable byte(s) may be both zero and non-zero, you’ll need two (or more) different layer7-protocol items and a corresponding number of rules in chain=l7-analysis.
I assume only initial packets of each connection to be handled by this sequence of two rules.
But even this way, the probability of false match is not zero, as the pattern you use as a signature one may appear in initial packets of other connections and as you cannot specify the position of the pattern within the packet (maybe you can use ^ in the regex but it doesn’t help much as you cannot be sure that some bytes won’t be \x00 ones sometimes, which would change the offset).
Also, in the OP you mention an ARP packet which an IP firewall never receives, but you packet dump matches to a UDP one, so I guess it’s actually OK and you can add protocol=udp to the first rule with action=jump. Maybe also the range of source and/or destination ports is known and can help you lower the probability of false positives.
I’m not sure I get you right, especially the “shunting to other routes”. But I assume you need to choose a specific route and/or to change the packet’s destination address if it has a particular contents, and that, after all, part of the match pattern within the contents is variable while the rest is fixed. The only thing I can suggest here is to find the longest fixed sequence of bytes which is the same in all the packets of interest, match it using the content matcher in a rule with action=jump jump-target=l7-analysis, and in that new chain, use a single rule which would refer to a layer7-protocol regexp matching the signature sequence again, this time with . in place of the variable bytes and nothing at all in place of the bytes which are always zero and with the final action to take (which would likely be mark-connection if this whole setup is used in mangle table to choose a specific route, or dst-nat if it is used in nat table to redirect the packet to another destination address).
If the variable byte(s) may be both zero and non-zero, you’ll need two (or more) different layer7-protocol items and a corresponding number of rules in chain=l7-analysis.
I assume only initial packets of each connection to be handled by this sequence of two rules.
But even this way, the probability of false match is not zero, as the pattern you use as a signature one may appear in initial packets of other connections and as you cannot specify the position of the pattern within the packet (maybe you can use ^ in the regex but it doesn’t help much as you cannot be sure that some bytes won’t be \x00 ones sometimes, which would change the offset).
Also, in the OP you mention an ARP packet which an IP firewall never receives, but you packet dump matches to a UDP one, so I guess it’s actually OK and you can add protocol=udp to the first rule with action=jump. Maybe also the range of source and/or destination ports is known and can help you lower the probability of false positives.
[/quote]
Yes, you are right. I can match the data with 90% accuracy. Of course, I can also get the CDN data of the big company (alibaba, Tencent) by monitoring DNS data, and then get the target address. Just need to do a routing marker to distribute the data, so that the data can go along the specified line. Yes, I already have the application environment in use, and it is very stable, but we will face different application rings. We need to collect more information.If the L7 matching effect is strong enough, or some simpler matching methods will make our updating work easier, thank you again, thank you for your patience. have a good day