How can I set a rule for checking also and hex-string like linux iptables?
I want to write a rule to cacth this package
-m string --algo kmp --hex-string “|55ffffffff|”
you can start with Level 7 filters here: https://wiki.mikrotik.com/wiki/Manual:IP/Firewall/L7
or simple content filters here: https://wiki.mikrotik.com/wiki/Manual:IP/Firewall/Filter
Neither are going to work with SSL.
hex-string “|55ffffffff|”
how to set with layer7 filter?
ip firewall layer7-protocol add name=match-55ffffff regexp=“\x55\xff\xff\xff”
Really thanks for your help.
and my last question is packet going with other hex how can I wildcard it?
ffffffff55872ede29
[\x55\xff\xff\xff\~] ?
- Take the string and split it into groups of two hex digits each:
ff ff ff ff 55 87 2e de 29 - place \x in front of each group and remove the spaces:
regexp=“\xff\xff\xff\xff\x55\x87\x2e\xde\x29”
The double \ is there because a single \ is an escape character (so if you want to place a " sign into a "-delimited string, you write “"”).
It is possible that when you export the configuration, some characters will be replaced by their ASCII equivalent, so you may end up with something like
regexp=“\xff\xff\xff\xffU\x87.\xde)”
If so, there is a danger that the . character will be interpreted as a wildcard (which it is in regexp syntax), so you woul get false matches. To prevent that, you need to use \. instead of plain .
Is it true 3 string? Lastone is for wildcard for the rest.
\xff\xff\xff\xff\x54\x53\x6f\x75\x72\x63\x65\x20\x45\x6e\x67\x69\x6e\x65\x20\x51\x75\x65\x72\x79.*
\xff\xff\xff\xff\x67\x65\x74\x63\x68\x61\x6c\x6c\x65\x6e\x67\x65\x20
\x55\xff\xff\xff\xff.*
I don’t understand the question. You have provided three regular expressions, none of which matches a superset of what any of the remaining two matches. The last one matches four 0xff bytes in a row but they must be preceded by 0x55 which is not the case for the other two.
Other than that, .* in the end of a regexp is functionally equivalent to nothing at all because it says “anything, including end of data, may follow”
And it is probably easier and less prone to typing errors to use
“\xff\xff\xff\xffTSource Engine Query”
and
"\xff\xff\xff\xffgetchallenge "
If you want to accept/drop/whatever else packets matching any of the three patterns, you can use a single regexp and a single rule referring to it:
regexp=“(\xff\xff\xff\xffgetchallenge |\xff\xff\xff\xffTSource Engine Query|U\xff\xff\xff\xff)”
What is the correct layer7 Regex for finding “bad checksum” or “empty checksum” packages with Mikrotik Rule?
for empty checksum I found this.
-m u32 --u32 “24&0xffff=0x0000”
and how to set 00 00 ?
0000ffffffff54
I’m afraid there is none, as the \x00 bytes are removed before matching to the regex, so you can neither find them using the regex nor be sure how many of them are there if you would specify something like .{24}\x00\x00.
Regardless that, a “wrong checksum” is a very different case than “not calculated checksum (0x0000)”; to detect a wrong checksum, you have to calculate it on your own and compare it with the one which has been received, so even in iptables, you would need a specific match target which would do the calculation (and thus slow down packet processing quite a lot).
I try to catch this package.
OK, so that’s one with a not calculated checksum, yet due to what I wrote above regarding zero bytes and regex matching, it is not possible to match such packet using layer7-protocol rules.
I think package come with checksum value. Because other packages come with checksum value. Only this package come without checksum.
Also iptables rule catch empty checksum packages. If iptables able to do this also Mikrotik able to do it, I think. Am I wrong?
Unfortunately not everything that can be configured using iptables is available in Mikrotik and vice versa. E.g. for address lists, you need an extra module for netfilter, and I don’t know a module for netfilter which would support regular expression matching on packet contents, I only know how to do that by sending the packet to a userspace queue. In RouterOS, in turn, a possibility to match a particular byte value on a particular offset in the packet doesn’t exist to my knowledge.