I am creating a drop port scanners per https://wiki.mikrotik.com/wiki/Drop_port_scanners and wanted to find out what the 2w means in address-list-timeout=2w. The only option offered is none dynamic or none static…see screen shot.
2w = two weeks
Thanks Pe1ch1…wasn’t expecting such a long time…I now take that to mean the time the source list shall exist. So, does dynamic therefore means that the list would roll over to the next two weeks period?
I am dropping traffic, yet nothing is been added to the address list…see screen shot, what’s up?
Your picture shows you are adding only source addresses of TCP packets to the list, but dropping everything. So other than TCP packets are just dropped, their addresses are not added to the list.
Press the Terminal button and post here the output of ****
/ip firewall filter export
entered at the terminal. The GUI does not show all match columns in the table view so it is impossible to do any deeper analysis based on that.
Thank you Sindy for responding. Good catch…I had thought about that while I was setting up the filter per instruction that only calls for TCP. So, I am just learning one can use UDP to scan ports…wondered why that wasn’t added to the instruction above. How do I add UDP port scanning to the post scanners address list and what flags to use? Here’s the screen shot you requested.
I would advise you to not bother about such filtering on a router that already has an “established,related” filter to allow only related traffic and maybe some dstnatted ports.
It will only serve to load your router with all that matching and address list building, and it will not add any security.
It is merely a nice project for study, not something useful in production networks.
It could be different when your router is basically transparent (so it allows all the traffic inbound and the filtering is done further up in the network) and you want to limit the traffic that is caused by those scanners, which would load your internal links (that could be radio links).
I didn’t 
What I actually wanted was a copy-paste of the text output (select the text, right-click on it, left-click on “copy” in the drop-down menu, then Ctrl-V here), not a picture. You cannot use Ctrl-F for strings in a picture, you cannot rearrange the rules using a text editor when analysing configurations from people who interleave rules belonging to input, output, forward and eventually other chains, etc. Not that it would be necessary in this case, just think about it in general.
one can use UDP to scan ports…wondered why that wasn’t added to the instruction above. How do I add UDP port scanning to the post scanners address list and what flags to use?
Your second question is your answer. There are no flags in UDP. So the first UDP packet from ****
add.re.ss.A:portX
to
add.re.ss.B:portY
constitutes a new connection, and the first packet in the opposite direction makes the connection confirmed. The rest is the job of the application layer. So except application protocols on top of UDP for which the firewall has a handling module (like SIP), the firewall cannot tell “valid” UDP packets from “invalid” ones.
So if something is sending UDP packets to several different ports of your device within a short time window, it is probably a scanner and the ****
psd
matcher can be applied on it. However, some scanners may target a single service (like IPsec on UDP port 500 or DNS on UDP port 53), and in such case the
psd
matcher doesn’t work.
What I do is that I drop anything on UDP ports other than those I need to listen at, and on these, I drop everything what comes from addresses which are not on the address-list of exceptions, and add each new arrival to a list of “attackers”. When I need to permit a connection from a new source, I just move the address from the address-list of attackers to the address-list of exceptions.
And as @pe1chl wrote, for TCP, it is enough to:
- accept ****
connection-state=related,established
(in this case, this means related or established)
- accept ****
connection-state=new
if other conditions like destination port, source address etc. are met - for TCP,
connection-state
matches
new
only for packets with the
SYN
flag alone
- drop what remains, because what has not matched any of the two rules above must be broken in some way (wrong combination of flags or a combination of flags not matching the connection state). If you add an ****
add-src-to-address-list
rule before the
drop
one, you get about the same result as with your full list of wrong flag combinations.
Thank you Sindy for responding…yes, that’s what I wanted to provide you…I am a MAC user and could not copy with Apple C. So, I set up the UDP filter with psd however, I wondered whether I set up port scanners properly (see screen shot above). Should I have an IP address of my subnet instead of 0.0.0.0? I also wondered how the IP address of offenders is added to the Port scanners address-list as well as how to view the list.
For disclosure, my WAN is govern by Pfsense and my LAN is govern by Mikrotik (Pfsense HP Pavillion a6242n > RB450G). Looking at my firewall with all those forward chain flags, I noticed that only the fin-ack is dropping traffic. Then, reading and rereading your response as well as what Pe1chi said, it seems that I can make my firewall simpler and more effective. I’ll reread yours again.
You can use ****
file=something
as ana dditional parameter to export and print and then download the file to get to the text if Apple browsers do not allow to mark and copy text.
So, I set up the UDP filter with psd however, I wondered whether I set up port scanners properly (see screen shot above). Should I have an IP address of my subnet instead of 0.0.0.0?
I may be blind but I cannot see any rule with ****
protocol=udp
and
psd=...
in the screenshot above (the
/ip firewall export
in your previous post) nor the screenshot below (where most rule parameters are hidden becase this table view is intended for overview of rule counters so if a
psd
match is somewhere there I cannot say anything about its parameters).
As for using ****
0.0.0.0/0
or your subnet address as
dst-address
, it is a more complex topic. In
chain=input
, there is no point in specifying your subnet address because if the packets have arrived to you, their destination address must have been one of yours, so why lose CPU time by matching their destination address at all. In
chain=forward
, you most likely want to discriminate between packets coming from the WAN side and packets coming from the LAN side - at least because if devices in your LAN start port-scanning the internet, you want to learn about it even faster than if something from outside is port-scanning you. So you may want to use a different
address-list
for each type of attacker (external and internal), but it is easier to use an
in-interface
match than the
dst-address
one for the discrimination.
I also wondered how the IP address of offenders is added to the Port scanners address-list as well as how to view the list.
In WebFig and Winbox, there is a tab “address list” in the firewall window. To add attacker’s address to an address list, you have to use a rule with
action=add-src-to-address-list
and a parameter
address-list=some_name
before the rule with
action=drop
.
I’m not 100% sure whether what I wrote are actually answers to your questions.
The add src to address list must be after the drop rule, else your address list will just keep increasing and never get to the drop rule
What makes you think that? The order must be exactly as I wrote.
Some rule actions stop the journey of the packet down the current rule chain if taken - in table
filter
, these are
accept
,
drop
, and
reject
. Some don’t - in case of filter, these are
add-src-to-address-list
,
add-dst-to-address-list
,
passthrough
, and
log
. I’m not sure about
tarpit
as I’ve never used it.
There is a sentence on the manual page right before the table above,
If a packet matches the criteria of the rule, then the specified action is performed on it, and no more rules are processed in that chain (the exception is the passthrough action)
which was probably correct years ago but since then the
passtrough
and
add-xxx-to-address-list
actions have been added and seemingly nobody has noticed that the sentence has to be updated.
In ****
mangle
, the situation is even more complex. Only
accept
stops the journey of the packet through the chain immediately; for
mark-packet
,
mark-connection
and
mark-routing
, you can choose whether you want the packet to continue down the chain if the action is taken, by means of the
passthrough
parameter (at least in 6.41.3, the default is
no
although the manual doesn’t state any). None of the other actions stops the packet from continuing down the rule chain.
Each address may exist on each ****
address-list
only once. If a firewall rule adds the same address again, the timeout value of the existing item on the list is rewritten to the value provided by the adding rule and that’s it.
That is interesting, wish they would keep the Wiki docs accurate and current in order for us to configure thing properly and efficient!!! With that said though, logically I think it is still better to place drop rule before the add src rule, reason is that you might have multiple rules for adding src to the same address list, then the packets to be dropped does not have to go through the long list of src adding rules and saving some resources on the router.
I have 6.41.4, and for me the default of passthrough property is “yes”?
Once the packet matches to a drop rule, it gets dropped and that’s the very end of its life, dot. So the rules following the drop one never see it.
As for the “long list” of add-src-to-address-list rules, there would be just one per each address list you want to keep separate. As a meta-rule “add the address to a list and then drop the packet”, you normally use a custom chain, someting like:
/ip firewall rule
add chain=input protocol=tcp dst-port=22 connection-state=new action=jump target=add-and-drop-ssh-list
add chain=input protocol=tcp dst-port=443 connection-state=new action=jump target=add-and-drop-https-list
...
add chain=add-and-drop-ssh-list action=add-src-to-address-list address-list=ssh-attackers
add chain=add-and-drop-ssh-list action=drop
...
add chain=add-and-drop-https-list action=add-src-to-address-list address-list=https-attackers
add chain=add-and-drop-https-list action=drop
I have 6.41.4, and for me the default of passthrough property is “yes”?
It unfortunately depends on where you look and what you call “default”:
- if you use command line to add the mangle rule and you don’t provide the ****
passthrough
property at all, the rule behaves as if
passthrough=no
. That’s a default behaviour to me.
- if you use WebFig (and maybe also Winbox) and choose one of the actions for which the passthrough value is relevant, the passthrough property appears with a ticked checkbox.
. Remember the Bee Gees song? Don’t ask me why…
Just tested this, and nope, I do not get same results as you, when I use terminal to add the rule, it still adds passthrough property as “yes” even though I did not specify it specifically
There seems to be so many discrepancies and problems in Mikrotik, especially watching the last couple of releases since December 2017, makes me wonder if it is the correct product for customers…
Just asking, to learn, except if you want to log specific info per protocol/port, why will you want to separate ports 22 and 443 as per your example, will it not be better / more efficient to just create 1 rule for both 22, 443?
What I wrote was based on a test too… except that it was at 6.41.3. There it behaves as I wrote.
There seems to be so many discrepancies and problems in Mikrotik, especially watching the last couple of releases since December 2017, makes me wonder if it is the correct product for customers…
Replace “Mikrotik” by any other brand name and your sentence becomes true as well as soon as you get to know it as detailed as you know Mikrotik. From a distance everything looks shiny and perfect, you have to start really using it you see the naked truth.
Just asking, to learn, except if you want to log specific info per protocol/port, why will you want to separate ports 22 and 443 as per your example, will it not be better / more efficient to just create 1 rule for both 22, 443?
Well, it was you who has mentioned “a lot of add-xxx-to-address-list rules to pass”, so I’ve understood it in such a way that you have in mind exactly this - separate logging of attacks to indiviual address-lists per attacked service, so I’ve created an exampe exactly for that. If this was a wrong understanding, can you give an example of what you had in mind so that we could analyze and possibly optimize it?
Example of multiple add src address from my home router
/ip firewall raw
add action=drop chain=prerouting comment="Drop Router Access from External" dst-port=21,22,23,80,81,82,8080,8081,8082,8089,8181,8291 in-interface-list=WAN protocol=tcp
add action=drop chain=prerouting comment="Drop Port Scan list" in-interface-list=WAN src-address-list="port scanners"
add action=drop chain=prerouting comment="Drop \"Drop\" Address List" in-interface-list=WAN src-address-list=Drop
add action=drop chain=prerouting comment="Drop MAC requesting DHCP on WAN" in-interface-list=WAN src-mac-address=52:54:00:74:6D:87
add action=add-src-to-address-list address-list="port scanners" address-list-timeout=2w chain=prerouting comment="Add SRC to Port Scan list" in-interface-list=WAN protocol=tcp psd=21,3s,3,1
add action=add-src-to-address-list address-list="port scanners" address-list-timeout=2w chain=prerouting comment="NMAP FIN Stealth scan" in-interface-list=WAN protocol=tcp tcp-flags=\
fin,!syn,!rst,!psh,!ack,!urg
add action=add-src-to-address-list address-list="port scanners" address-list-timeout=2w chain=prerouting comment="SYN/FIN scan" in-interface-list=WAN protocol=tcp tcp-flags=fin,syn
add action=add-src-to-address-list address-list="port scanners" address-list-timeout=2w chain=prerouting comment="SYN/RST scan" in-interface-list=WAN protocol=tcp tcp-flags=syn,rst
add action=add-src-to-address-list address-list="port scanners" address-list-timeout=2w chain=prerouting comment="FIN/PSH/URG scan" in-interface-list=WAN protocol=tcp tcp-flags=\
fin,psh,urg,!syn,!rst,!ack
add action=add-src-to-address-list address-list="port scanners" address-list-timeout=2w chain=prerouting comment="ALL/ALL scan" in-interface-list=WAN protocol=tcp tcp-flags=fin,syn,rst,psh,ack,urg
add action=add-src-to-address-list address-list="port scanners" address-list-timeout=2w chain=prerouting comment="NMAP NULL scan" in-interface-list=WAN protocol=tcp tcp-flags=\
!fin,!syn,!rst,!psh,!ack,!urg
Never doubted / questioned you, just stated what happens on my side and hence my comment re discrepancies.
I will take your word on this, you seem to have way more knowledge and experience in this than I do, especially on a technical level. I like Mikrotik and for now I will stick around. I just need some stability when I install something at my customers as it will reflect bad on me…
As far as updating documentation goes, I don’t understand why it is a problem, surely you can just make it part of Change Management process, i.e. change request does not get signed off as completed till documentation on Wiki is done/updated. If this is the case, then there are some Quality Control issues.
Well, now I do understand why you are afraid of many ****
add-src-to-address-list
rules, and maybe I even understand what you had in mind by
drop
before
add-src-to-address-list
.
One of primary purposes of an ****
address-list
is to be able to drop the packet based on its source address alone, without need to inspect it deeper. So it is a very good idea to place a drop rule for anything from an address already placed to a list of attacker addresses before into
chain=prerouting
of
/ip firewall raw
, because if you get rid of packets from these sources already at this stage, you don’t need to waste CPU on their further processing.
However, it is a very bad idea to use that chain of that table for complex matching, like the one you do here (matching on many incorrect combinations of flags), for two reasons:
- the rules in this chain are evaluated for every single packet,
- no connection context is available at this stage yet.
In later stages of processing, the connection context becomes available and there is a good chance that the accept/drop verdict on most packets can be provided already before they reach the complex matching stage.
In the particular case of TCP, the connection tracker is very helpful for this purpose because it “knows” what flag combinations are “legal” at which connection state. So for normal situations, it is enough to do the following in ****
/ip firewall filter
:
- first accept packets with ****
connection-state=established
, because connection tracking only marks packets as
established
if they belong to an already existing connection and their combination of tcp flags is valid,
- then accept packets with ****
connection-state=new
if they match other requirements (like dst-port) because connection tracking only marks as
new
packets bearing the
SYN
flag alone.
What hasn’t matched to any of the two rules above may be
- either packets attempting to establish new connections which we don’t wish to accept
- or packets which have an illegal combination of TCP flags with regard to the connection state.
Packets from any of these two groups are marked as
connection-state=invalid
.
The dangerous point here is that a packet may be marked as ****
connection-state=invalid
also for other reasons than illegal combination of TCP flags, e.g. in case of some transient effects in the network - if the Mikrotik restarts when a TCP session has already been established, the remote server keeps re-transmitting packets; as they come without
SYN
so cannot establish a new connection, they are classified as
invalid
by the connection tracker which has just started running.
So if you would place the source address of any TCP packet which has reached the third stage above to an address list of attackers, you could blacklist some harmful remote addresses. Therefore, if you want to blacklist the attackers/port scanners, this is the right place to use matching on those various illegal combinations of flags. This way, if a source sends a TCP packet with any illegal combination of flags, you blacklist it here using an ****
add-src-to-address-list
rule, and any further packets from the same source will be dropped already in the raw table. So the bulk of traffic is either accepted by one of the two basic rules above or dropped by the blacklist rule in
raw prerouting
, and only few packets reach the complex matching stage.
Process-wise this has obviously been handled properly as the information about the added actions and their related parameters has been added to the wiki page. I cannot imagine how to mark relevance of individual sentences or words in the documentation to features. So I’m quite sensitive about documentation accuracy but I can fully understand how this sentence could have evaded the modification.
The generic problem is that the available number of qualified first-time readers is always lower than the necessary number of documentation updates 