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?2w = two weeks
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.I am dropping traffic, yet nothing is been added to the address list...see screen shot, what's up?
/ip firewall filter export
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.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.I am dropping traffic, yet nothing is been added to the address list...see screen shot, what's up?
Press the Terminal button and post here the output ofentered 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.Code: Select all/ip firewall filter export
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.Here's the screen shot you requested.
Your second question is your answer. There are no flags in UDP. So the first UDP packet fromone 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?
add.re.ss.A:portX
add.re.ss.B:portY
psd
psd
connection-state=related,established
connection-state=new
connection-state
new
SYN
add-src-to-address-list
drop
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.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.Here's the screen shot you requested.
Your second question is your answer. There are no flags in UDP. So the first UDP packet fromone 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?toCode: Select alladd.re.ss.A:portX
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.Code: Select alladd.re.ss.B:portY
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 thematcher 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 theCode: Select allpsd
matcher doesn't work.Code: Select allpsd
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(in this case, this means related or established)Code: Select allconnection-state=related,established
- acceptif other conditions like destination port, source address etc. are met - for TCP,Code: Select allconnection-state=new
matchesCode: Select allconnection-state
only for packets with theCode: Select allnew
flag aloneCode: Select allSYN
- 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 anrule before theCode: Select alladd-src-to-address-list
one, you get about the same result as with your full list of wrong flag combinations.Code: Select alldrop
You can useI am a MAC user and could not copy with Apple C.
file=something
I may be blind but I cannot see any rule withSo, 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?
protocol=udp
psd=...
/ip firewall export
psd
0.0.0.0/0
dst-address
chain=input
chain=forward
address-list
in-interface
dst-address
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 withI also wondered how the IP address of offenders is added to the Port scanners address-list as well as how to view the list.
action=add-src-to-address-list
address-list=some_name
action=drop
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 withand a parameterCode: Select allaction=add-src-to-address-list
before the rule withCode: Select alladdress-list=some_name
.Code: Select allaction=drop
I'm not 100% sure whether what I wrote are actually answers to your questions.
What makes you think that? The order must be exactly as I wrote.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
filter
accept
drop
reject
add-src-to-address-list
add-dst-to-address-list
passthrough
log
tarpit
which was probably correct years ago but since then theIf 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)
passtrough
add-xxx-to-address-list
mangle
accept
mark-packet
mark-connection
mark-routing
passthrough
no
address-list
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....
Some rule actions stop the journey of the packet down the current rule chain if taken - in table, these areCode: Select allfilter
,Code: Select allaccept
, andCode: Select alldrop
. Some don't - in case of filter, these areCode: Select allreject
,Code: Select alladd-src-to-address-list
,Code: Select alladd-dst-to-address-list
, andCode: Select allpassthrough
. I'm not sure aboutCode: Select alllog
as I've never used it.Code: Select alltarpit
There is a sentence on the manual page right before the table above,which was probably correct years ago but since then theIf 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)andCode: Select allpasstrough
actions have been added and seemingly nobody has noticed that the sentence has to be updated.Code: Select alladd-xxx-to-address-list
...
I have 6.41.4, and for me the default of passthrough property is "yes"?...
In, the situation is even more complex. OnlyCode: Select allmangle
stops the journey of the packet through the chain immediately; forCode: Select allaccept
,Code: Select allmark-packet
andCode: Select allmark-connection
, you can choose whether you want the packet to continue down the chain if the action is taken, by means of theCode: Select allmark-routing
parameter (at least in 6.41.3, the default isCode: Select allpassthrough
although the manual doesn't state any). None of the other actions stops the packet from continuing down the rule chain.Code: Select allno
...
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.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.
/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
It unfortunately depends on where you look and what you call "default":I have 6.41.4, and for me the default of passthrough property is "yes"?
passthrough
passthrough=no
...It unfortunately depends on where you look and what you call "default":I have 6.41.4, and for me the default of passthrough property is "yes"?. Remember the Bee Gees song? Don't ask me why...
- if you use command line to add the mangle rule and you don't provide the
property at all, the rule behaves as ifCode: Select allpassthrough
. That's a default behaviour to me.Code: Select allpassthrough=no
- 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.
What I wrote was based on a test too... except that it was at 6.41.3. There it behaves as I wrote.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
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.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...
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?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?
/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
What I wrote was based on a test too... except that it was at 6.41.3. There it behaves as I wrote.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
...
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......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.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...
...
add-src-to-address-list
drop
add-src-to-address-list
address-list
chain=prerouting
/ip firewall raw
/ip firewall filter
connection-state=established
established
connection-state=new
new
SYN
connection-state=invalid
connection-state=invalid
SYN
invalid
add-src-to-address-list
raw prerouting
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.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 manyrules, and maybe I even understand what you had in mind byCode: Select alladd-src-to-address-list
beforeCode: Select alldrop
.Code: Select alladd-src-to-address-list
One of primary purposes of anis 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 intoCode: Select alladdress-list
ofCode: Select allchain=prerouting
, 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.Code: Select all/ip firewall raw
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: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.
- the rules in this chain are evaluated for every single packet,
- no connection context is available at this stage yet.
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:Code: Select all/ip firewall filter
What hasn't matched to any of the two rules above may be
- first accept packets with
, because connection tracking only marks packets asCode: Select allconnection-state=established
if they belong to an already existing connection and their combination of tcp flags is valid,Code: Select allestablished
- then accept packets with
if they match other requirements (like dst-port) because connection tracking only marks asCode: Select allconnection-state=new
packets bearing theCode: Select allnew
flag alone.Code: Select allSYN
Packets from any of these two groups are marked as
- 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.
.Code: Select allconnection-state=invalid
The dangerous point here is that a packet may be marked asalso 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 withoutCode: Select allconnection-state=invalid
so cannot establish a new connection, they are classified asCode: Select allSYN
by the connection tracker which has just started running.Code: Select allinvalid
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 anrule, 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 inCode: Select alladd-src-to-address-list
, and only few packets reach the complex matching stage.Code: Select allraw prerouting