Can you tell me if this looks ok for my basic protection for the home use?
My firewall rules - please advise
I basically copied the rules for mikrotik wiki and added the fasttrack action.
Can you tell me if this looks ok for my basic protection for the home use?
Can you tell me if this looks ok for my basic protection for the home use?
Last edited by meazz1 on Fri May 31, 2019 4:10 pm, edited 1 time in total.
Re: My firewall rules - please advise
Winbox shows about 1/3 of all parameters of the firewall rules in this overview. If you want a qualified advice, you have to provide qualified input information. See my automatic signature for a hint. Click the [terminal] button in Winbox to obtain a command line window.
Re: My firewall rules - please advise
1. Open new terminal.
2. Type "ip firewall filter export" (without quotation marks).
3. Paste here the results.
4. Wait for an answer of someone of here.
Regards.
2. Type "ip firewall filter export" (without quotation marks).
3. Paste here the results.
4. Wait for an answer of someone of here.
Regards.
Re: My firewall rules - please advise
The winbox default settings are home safe out of the box.
Then when configuring the router often folks add too much stuff or dont understand what they are doing.
So its best to post the complete config as there are many related moving parts.
(in other words just filter rules is not the whole story).
/export hide-sensitive file=yourconfigmay30
Then when configuring the router often folks add too much stuff or dont understand what they are doing.
So its best to post the complete config as there are many related moving parts.
(in other words just filter rules is not the whole story).
/export hide-sensitive file=yourconfigmay30
Re: My firewall rules - please advise
Here is my ip firewall filter export
Code: Select all
# may/30/2019 21:27:33 by RouterOS 6.45beta50
# software id = S1MG-NEED
#
# model = RouterBOARD 750G r3
# serial number = XXXXXXXXXXX
/ip firewall filter
add action=accept chain=forward connection-state=established,related
add action=fasttrack-connection chain=forward connection-state=established,related
add action=add-src-to-address-list address-list=Syn_Flooder address-list-timeout=30m chain=input \
comment="Add Syn Flood IP to the list" connection-limit=30,32 protocol=tcp tcp-flags=syn
add action=drop chain=input comment="Drop to syn flood list" src-address-list=Syn_Flooder
add action=add-src-to-address-list address-list=Port_Scanner address-list-timeout=1w chain=input \
comment="Port Scanner Detect" protocol=tcp psd=21,3s,3,1
add action=drop chain=input comment="Drop to port scan list" src-address-list=Port_Scanner
add action=jump chain=input comment="Jump for icmp input flow" jump-target=ICMP protocol=icmp
add action=drop chain=input comment="Block all access to the winbox - except to support list # DO NOT ENA\
BLE THIS RULE BEFORE ADD YOUR SUBNET IN THE SUPPORT ADDRESS LIST" disabled=yes dst-port=8291 \
protocol=tcp src-address-list=!support
add action=jump chain=forward comment="Jump for icmp forward flow" jump-target=ICMP protocol=icmp
add action=drop chain=forward comment="Drop to bogon list" dst-address-list=bogons
add action=add-src-to-address-list address-list=spammers address-list-timeout=3h chain=forward comment=\
"Add Spammers to the list for 3 hours" connection-limit=30,32 dst-port=25,587 limit=30/1m,0 \
protocol=tcp
add action=drop chain=forward comment="Avoid spammers action" dst-port=25,587 protocol=tcp \
src-address-list=spammers
add action=accept chain=input comment="Accept DNS - UDP" port=53 protocol=udp
add action=accept chain=input comment="Accept DNS - TCP" port=53 protocol=tcp
add action=accept chain=input comment="Accept to established connections" connection-state=established
add action=accept chain=input comment="Accept to related connections" connection-state=related
add action=accept chain=input comment="Full access to SUPPORT address list" src-address-list=support
add action=drop chain=input comment=\
"Drop anything else! # DO NOT ENABLE THIS RULE BEFORE YOU MAKE SURE ABOUT ALL ACCEPT RULES YOU NEED" \
disabled=yes
add action=accept chain=ICMP comment="Echo request - Avoiding Ping Flood" icmp-options=8:0 limit=1,5 \
protocol=icmp
add action=accept chain=ICMP comment="Echo reply" icmp-options=0:0 protocol=icmp
add action=accept chain=ICMP comment="Time Exceeded" icmp-options=11:0 protocol=icmp
add action=accept chain=ICMP comment="Destination unreachable" icmp-options=3:0-1 protocol=icmp
add action=accept chain=ICMP comment=PMTUD icmp-options=3:4 protocol=icmp
add action=drop chain=ICMP comment="Drop to the other ICMPs" protocol=icmp
add action=jump chain=output comment="Jump for icmp output" jump-target=ICMP protocol=icmp
Re: My firewall rules - please advise
Here's my
/export hide-sensitive file
/export hide-sensitive file
Code: Select all
# may/30/2019 21:24:29 by RouterOS 6.45beta50
# software id = S1MG-NEED
#
# model = RouterBOARD 750G r3
# serial number = xxxxxxxxxxx
/interface bridge
add name=bridge1
/interface list
add name=WAN
add name=LAN
/ip pool
add name=dhcp ranges=192.168.4.10-192.168.4.100
/ip dhcp-server
add address-pool=dhcp disabled=no interface=bridge1 name=dhcp1
/interface bridge port
add bridge=bridge1 interface=ether2
add bridge=bridge1 interface=ether3
add bridge=bridge1 interface=ether4
add bridge=bridge1 interface=ether5
/interface list member
add interface=ether1 list=WAN
add interface=bridge1 list=LAN
/ip address
add address=192.168.4.1/24 interface=ether2 network=192.168.4.0
/ip cloud
set update-time=no
/ip dhcp-client
add dhcp-options=hostname,clientid disabled=no interface=ether1 use-peer-dns=\
no use-peer-ntp=no
/ip dhcp-server network
add address=192.168.4.0/24 dns-server=192.168.4.5 gateway=192.168.4.1 \
netmask=24
/ip dns
set max-udp-packet-size=512 servers=192.168.4.5
/ip firewall address-list
add address=0.0.0.0/8 comment="Self-Identification [RFC 3330]" list=Bogons
add address=10.0.0.0/8 comment="Private[RFC 1918] - CLASS A # Check if you nee\
d this subnet before enable it" list=Bogons
add address=127.0.0.0/8 comment="Loopback [RFC 3330]" list=Bogons
add address=169.254.0.0/16 comment="Link Local [RFC 3330]" list=Bogons
add address=172.16.0.0/12 comment="Private[RFC 1918] - CLASS B # Check if you \
need this subnet before enable it" list=Bogons
add address=192.0.2.0/24 comment="Reserved - IANA - TestNet1" list=Bogons
add address=192.88.99.0/24 comment="6to4 Relay Anycast [RFC 3068]" list=\
Bogons
add address=198.18.0.0/15 comment="NIDB Testing" list=Bogons
add address=198.51.100.0/24 comment="Reserved - IANA - TestNet2" list=Bogons
add address=203.0.113.0/24 comment="Reserved - IANA - TestNet3" list=Bogons
add address=224.0.0.0/4 comment=\
"MC, Class D, IANA # Check if you need this subnet before enable it" \
list=Bogons
add address=192.168.4.0/24 list=support
add address=0.0.0.0/8 comment="Self-Identification [RFC 3330]" list=bogons
add address=10.0.0.0/8 comment="Private[RFC 1918] - CLASS A # Check if you nee\
d this subnet before enable it" disabled=yes list=bogons
add address=127.0.0.0/8 comment="Loopback [RFC 3330]" list=bogons
add address=169.254.0.0/16 comment="Link Local [RFC 3330]" list=bogons
add address=172.16.0.0/12 comment="Private[RFC 1918] - CLASS B # Check if you \
need this subnet before enable it" disabled=yes list=bogons
add address=192.168.0.0/16 comment="Private[RFC 1918] - CLASS C # Check if you\
\_need this subnet before enable it" disabled=yes list=bogons
add address=192.0.2.0/24 comment="Reserved - IANA - TestNet1" list=bogons
add address=192.88.99.0/24 comment="6to4 Relay Anycast [RFC 3068]" list=\
bogons
add address=198.18.0.0/15 comment="NIDB Testing" list=bogons
add address=198.51.100.0/24 comment="Reserved - IANA - TestNet2" list=bogons
add address=203.0.113.0/24 comment="Reserved - IANA - TestNet3" list=bogons
add address=224.0.0.0/4 comment=\
"MC, Class D, IANA # Check if you need this subnet before enable it" \
disabled=yes list=bogons
/ip firewall filter
add action=accept chain=forward connection-state=established,related
add action=fasttrack-connection chain=forward connection-state=\
established,related
add action=add-src-to-address-list address-list=Syn_Flooder \
address-list-timeout=30m chain=input comment=\
"Add Syn Flood IP to the list" connection-limit=30,32 protocol=tcp \
tcp-flags=syn
add action=drop chain=input comment="Drop to syn flood list" \
src-address-list=Syn_Flooder
add action=add-src-to-address-list address-list=Port_Scanner \
address-list-timeout=1w chain=input comment="Port Scanner Detect" \
protocol=tcp psd=21,3s,3,1
add action=drop chain=input comment="Drop to port scan list" \
src-address-list=Port_Scanner
add action=jump chain=input comment="Jump for icmp input flow" jump-target=\
ICMP protocol=icmp
add action=drop chain=input comment="Block all access to the winbox - except t\
o support list # DO NOT ENABLE THIS RULE BEFORE ADD YOUR SUBNET IN THE SUP\
PORT ADDRESS LIST" disabled=yes dst-port=8291 protocol=tcp \
src-address-list=!support
add action=jump chain=forward comment="Jump for icmp forward flow" \
jump-target=ICMP protocol=icmp
add action=drop chain=forward comment="Drop to bogon list" dst-address-list=\
bogons
add action=add-src-to-address-list address-list=spammers \
address-list-timeout=3h chain=forward comment=\
"Add Spammers to the list for 3 hours" connection-limit=30,32 dst-port=\
25,587 limit=30/1m,0 protocol=tcp
add action=drop chain=forward comment="Avoid spammers action" dst-port=25,587 \
protocol=tcp src-address-list=spammers
add action=accept chain=input comment="Accept DNS - UDP" port=53 protocol=udp
add action=accept chain=input comment="Accept DNS - TCP" port=53 protocol=tcp
add action=accept chain=input comment="Accept to established connections" \
connection-state=established
add action=accept chain=input comment="Accept to related connections" \
connection-state=related
add action=accept chain=input comment="Full access to SUPPORT address list" \
src-address-list=support
add action=drop chain=input comment="Drop anything else! # DO NOT ENABLE THIS \
RULE BEFORE YOU MAKE SURE ABOUT ALL ACCEPT RULES YOU NEED" disabled=yes
add action=accept chain=ICMP comment="Echo request - Avoiding Ping Flood" \
icmp-options=8:0 limit=1,5 protocol=icmp
add action=accept chain=ICMP comment="Echo reply" icmp-options=0:0 protocol=\
icmp
add action=accept chain=ICMP comment="Time Exceeded" icmp-options=11:0 \
protocol=icmp
add action=accept chain=ICMP comment="Destination unreachable" icmp-options=\
3:0-1 protocol=icmp
add action=accept chain=ICMP comment=PMTUD icmp-options=3:4 protocol=icmp
add action=drop chain=ICMP comment="Drop to the other ICMPs" protocol=icmp
add action=jump chain=output comment="Jump for icmp output" jump-target=ICMP \
protocol=icmp
/ip firewall nat
add action=masquerade chain=srcnat out-interface-list=WAN
/ip service
set ssh port=2200
/ip ssh
set allow-none-crypto=yes forwarding-enabled=remote strong-crypto=yes
/system clock
set time-zone-name=America/New_York
/system identity
set name=Tulip
/system ntp client
set enabled=yes primary-ntp=38.229.71.1 secondary-ntp=199.180.133.100
/system ntp server
set broadcast=yes enabled=yes
/tool bandwidth-server
set enabled=no
/tool graphing interface
add interface=bridge1
add interface=ether1
add interface=ether5
/tool graphing queue
add
/tool mac-server ping
set enabled=no
Re: My firewall rules - please advise
Hi,
/export has one disadvantage as compared to Winbox/WebFig, it doesn't auto-arrange the rules to display them sorted by chains, so I always do that manually to be able to review the dependencies among the rules; another feature is that /export, unlike /print, doesn't show dynamically added rules as it's not its job.
So I've re-grouped your filter rules by chains and numbered them to make it easier to refer to them.
Before commenting on individual rules, I'd recommend you to make yourself familiar with the idea of stateful firewall and connection tracking. Each packet is inspected by all firewall rules from the top of the respective chain until one of rules which match to the real fields of the packet header and the metafields associated to the packet by previous stages of firewall processing provides a final decision about the packet (accept, drop or reject). As matching to each rule consumes some CPU cycles, it is important that an average packet would pass through as few rules as possible or, in another words, that the topmost rules match on most packets and the less likely a packet is to match a given rule, the lower in the list the rule was.
So given the above, rules 9 and 10 can be merged into one by use of combined match condition connection-state=established,related, but the result should be moved to the position in chain=input. Rules 13 and 14 in chain=forward are properly placed in this regard relatively to the other rules in their chain, howeverer their mutual order is wrong - rule 13 shadows rule 14 so none of your connections is ever fasttracked. Rule 13 has to stay, however, because a small share of packets belonging to fasttracked connections is not acually fasttracked, and these packets need rule 13 to be let through by the filter.
Rule 2 should not only be right the next one after 9+10, so that flood SYNs would waste as little as possible CPU by being dropped before other rules; only after it, rule 1 should follow, to handle only SN flood sources which haven't be added to the Syn_Flooder list yet. However, a much better place for Rule 2 is in /ip firewall raw, because by placing it there you drop those packets already before handling in connection tracking which is a CPU-expensive operation too. Rule 1 must stay in /ip firewall filter.
Rules 2 and 4 may be merged into one if you merge the address-lists into one; rules 1 and 3 must stay separate as the criteria differ. In any case, banning an IP address for misbehavior may be different, as it is too easy to spoof a source address, so if someone sends you a SYN flood impersonating one of the addresses from which you access your machine remotely, he locks you out for a week. Which means that rule 6 should be placed before rules 1 and 3 and inverted - instead of "drop what comes from a source missing on the list of permitted ones", it should say "accept what comes from a source which is on the list of permitted ones". The way rule 6 is written now just drops these packets a few rules earlier than rule 12 would drop them anyway provided that it is active. So the right order of actions is to first invert rule 6 (change action from drop to accept adn remove the exclamation mark in the src-address-list clause in a single step), then disconnect and re-connect using Winbox and check that rule 6 has counted a hit, and then enable rule 12. The role of rule 12 is critical - it says "drop everything which wasn't accepted by any of the preceding rules", and if it is missing, everything which didn't match any of the preceding rules will be accepted which is definitely not what you want. So you have to double-check that all addresses from which you want to permit management access, including the LAN ones (which may be represented by the whole LAN subnet, though), will be on the address-list.
Rules 7 and 8 accept DNS requests from any source, including WAN. This is only a good idea in a limited number of cases, otherwise you open the door to various kinds of DNS attacks against your own system or against other systems - one more time a DNS request with a spoofed src-address will be responded to that spoofed address, so your machine will be overloading someone else's resources, hiding the actual attacker.
The ICMP chain to which you send the icmp packets using rule 5 can be basically reduced to rule 20. The thing is that an ICMP echo request creates a new tracked connection if it bears a yet unknown ID. ICMP echo responses are related to existing tracked connections (so those which are not will not be accepted by rule 9+10 moved to the top of the list, and thus will be dropped by rule 12), and all other ICMP types are relatable to existing TCP or UDP traffic and as such they will be either accepted by 9+10 as they match connection-state=related if they really are related, or dropped by rule 12 if they are not. In general, any tighter restrictions on ICMP are a really bad idea.
The only thing is that if you want rule 20 to really throttle ping floods, rule 20 should not only replace rule 5 and rule 15 but it should be also placed before rule 9+10, as all ICMP echo requests bearing the same ID are considered part of an established connection if the first one of them has been accepted.
As rule 17 does not check for interface-list WAN, you can easily cut off your internal mailserver if the connection to some downstream SMTP server fails outside your network - your one will keep retrying and rule 17 will ban it, and the ban will continue being renewed. For rule 18, the same as for rules 2 and 4 applies.
Rule 19 just protects the rest of the world from this Mikrotik going mad - I don't think it makes any sense. Chain output only cares about packets sent by the Mikrotik itself.
/export has one disadvantage as compared to Winbox/WebFig, it doesn't auto-arrange the rules to display them sorted by chains, so I always do that manually to be able to review the dependencies among the rules; another feature is that /export, unlike /print, doesn't show dynamically added rules as it's not its job.
So I've re-grouped your filter rules by chains and numbered them to make it easier to refer to them.
Before commenting on individual rules, I'd recommend you to make yourself familiar with the idea of stateful firewall and connection tracking. Each packet is inspected by all firewall rules from the top of the respective chain until one of rules which match to the real fields of the packet header and the metafields associated to the packet by previous stages of firewall processing provides a final decision about the packet (accept, drop or reject). As matching to each rule consumes some CPU cycles, it is important that an average packet would pass through as few rules as possible or, in another words, that the topmost rules match on most packets and the less likely a packet is to match a given rule, the lower in the list the rule was.
So given the above, rules 9 and 10 can be merged into one by use of combined match condition connection-state=established,related, but the result should be moved to the position in chain=input. Rules 13 and 14 in chain=forward are properly placed in this regard relatively to the other rules in their chain, howeverer their mutual order is wrong - rule 13 shadows rule 14 so none of your connections is ever fasttracked. Rule 13 has to stay, however, because a small share of packets belonging to fasttracked connections is not acually fasttracked, and these packets need rule 13 to be let through by the filter.
Rule 2 should not only be right the next one after 9+10, so that flood SYNs would waste as little as possible CPU by being dropped before other rules; only after it, rule 1 should follow, to handle only SN flood sources which haven't be added to the Syn_Flooder list yet. However, a much better place for Rule 2 is in /ip firewall raw, because by placing it there you drop those packets already before handling in connection tracking which is a CPU-expensive operation too. Rule 1 must stay in /ip firewall filter.
Rules 2 and 4 may be merged into one if you merge the address-lists into one; rules 1 and 3 must stay separate as the criteria differ. In any case, banning an IP address for misbehavior may be different, as it is too easy to spoof a source address, so if someone sends you a SYN flood impersonating one of the addresses from which you access your machine remotely, he locks you out for a week. Which means that rule 6 should be placed before rules 1 and 3 and inverted - instead of "drop what comes from a source missing on the list of permitted ones", it should say "accept what comes from a source which is on the list of permitted ones". The way rule 6 is written now just drops these packets a few rules earlier than rule 12 would drop them anyway provided that it is active. So the right order of actions is to first invert rule 6 (change action from drop to accept adn remove the exclamation mark in the src-address-list clause in a single step), then disconnect and re-connect using Winbox and check that rule 6 has counted a hit, and then enable rule 12. The role of rule 12 is critical - it says "drop everything which wasn't accepted by any of the preceding rules", and if it is missing, everything which didn't match any of the preceding rules will be accepted which is definitely not what you want. So you have to double-check that all addresses from which you want to permit management access, including the LAN ones (which may be represented by the whole LAN subnet, though), will be on the address-list.
Rules 7 and 8 accept DNS requests from any source, including WAN. This is only a good idea in a limited number of cases, otherwise you open the door to various kinds of DNS attacks against your own system or against other systems - one more time a DNS request with a spoofed src-address will be responded to that spoofed address, so your machine will be overloading someone else's resources, hiding the actual attacker.
The ICMP chain to which you send the icmp packets using rule 5 can be basically reduced to rule 20. The thing is that an ICMP echo request creates a new tracked connection if it bears a yet unknown ID. ICMP echo responses are related to existing tracked connections (so those which are not will not be accepted by rule 9+10 moved to the top of the list, and thus will be dropped by rule 12), and all other ICMP types are relatable to existing TCP or UDP traffic and as such they will be either accepted by 9+10 as they match connection-state=related if they really are related, or dropped by rule 12 if they are not. In general, any tighter restrictions on ICMP are a really bad idea.
The only thing is that if you want rule 20 to really throttle ping floods, rule 20 should not only replace rule 5 and rule 15 but it should be also placed before rule 9+10, as all ICMP echo requests bearing the same ID are considered part of an established connection if the first one of them has been accepted.
As rule 17 does not check for interface-list WAN, you can easily cut off your internal mailserver if the connection to some downstream SMTP server fails outside your network - your one will keep retrying and rule 17 will ban it, and the ban will continue being renewed. For rule 18, the same as for rules 2 and 4 applies.
Rule 19 just protects the rest of the world from this Mikrotik going mad - I don't think it makes any sense. Chain output only cares about packets sent by the Mikrotik itself.
Code: Select all
/ip firewall filter
1. add action=add-src-to-address-list address-list=Syn_Flooder address-list-timeout=30m chain=input comment="Add Syn Flood IP to the list" connection-limit=30,32 protocol=tcp tcp-flags=syn
2. add action=drop chain=input comment="Drop to syn flood list" src-address-list=Syn_Flooder
3. add action=add-src-to-address-list address-list=Port_Scanner address-list-timeout=1w chain=input comment="Port Scanner Detect" protocol=tcp psd=21,3s,3,1
4. add action=drop chain=input comment="Drop to port scan list" src-address-list=Port_Scanner
5. add action=jump chain=input comment="Jump for icmp input flow" jump-target=ICMP protocol=icmp
6. add action=drop chain=input comment="Block all access to the winbox - except to support list # DO NOT ENABLE THIS RULE BEFORE ADD YOUR SUBNET IN THE SUPPORT ADDRESS LIST" disabled=yes dst-port=8291 protocol=tcp src-address-list=!support
7. add action=accept chain=input comment="Accept DNS - UDP" port=53 protocol=udp
8. add action=accept chain=input comment="Accept DNS - TCP" port=53 protocol=tcp
9. add action=accept chain=input comment="Accept to established connections" connection-state=established
10. add action=accept chain=input comment="Accept to related connections" connection-state=related
11. add action=accept chain=input comment="Full access to SUPPORT address list" src-address-list=support
12. add action=drop chain=input comment= "Drop anything else! # DO NOT ENABLE THIS RULE BEFORE YOU MAKE SURE ABOUT ALL ACCEPT RULES YOU NEED" disabled=yes
13. add action=accept chain=forward connection-state=established,related
14. add action=fasttrack-connection chain=forward connection-state=established,related
15. add action=jump chain=forward comment="Jump for icmp forward flow" jump-target=ICMP protocol=icmp
16. add action=drop chain=forward comment="Drop to bogon list" dst-address-list=bogons
17. add action=add-src-to-address-list address-list=spammers address-list-timeout=3h chain=forward comment= "Add Spammers to the list for 3 hours" connection-limit=30,32 dst-port=25,587 limit=30/1m,0 protocol=tcp
18. add action=drop chain=forward comment="Avoid spammers action" dst-port=25,587 protocol=tcp src-address-list=spammers
19. add action=jump chain=output comment="Jump for icmp output" jump-target=ICMP protocol=icmp
20. add action=accept chain=ICMP comment="Echo request - Avoiding Ping Flood" icmp-options=8:0 limit=1,5 protocol=icmp
21. add action=accept chain=ICMP comment="Echo reply" icmp-options=0:0 protocol=icmp
22. add action=accept chain=ICMP comment="Time Exceeded" icmp-options=11:0 protocol=icmp
23. add action=accept chain=ICMP comment="Destination unreachable" icmp-options=3:0-1 protocol=icmp
24. add action=accept chain=ICMP comment=PMTUD icmp-options=3:4 protocol=icmp
25. add action=drop chain=ICMP comment="Drop to the other ICMPs" protocol=icmp
Re: My firewall rules - please advise
@sindy
Really appreciate your time and help.
So I will delete everything from IP---> Firewall
and open a terminal and paste your scripts?
Thanks
Really appreciate your time and help.
So I will delete everything from IP---> Firewall
and open a terminal and paste your scripts?
Thanks
Re: My firewall rules - please advise
No way! The "script" contains your existing rules with no effective change, just re-grouped by their membership in chains but keeping your original order within each chain, and numbered so that I could refer to each rule by its number in the explanatory text above. My assumption was that you read and understand each point and modify and re-arrange your rules according to that understanding.So I will delete everything from IP---> Firewall
and open a terminal and paste your scripts?
If your goal is less ambitious than to understand why things work the way they do and you just want to have a decent firewall, simply use the one from the default configuration as a whole and only extend it by rules you really need, such as permission of access to Winbox port from one or two trusted IPs in the internet.
Re: My firewall rules - please advise
Thanks for your advise.No way! The "script" contains your existing rules with no effective change, just re-grouped by their membership in chains but keeping your original order within each chain, and numbered so that I could refer to each rule by its number in the explanatory text above. My assumption was that you read and understand each point and modify and re-arrange your rules according to that understanding.So I will delete everything from IP---> Firewall
and open a terminal and paste your scripts?
If your goal is less ambitious than to understand why things work the way they do and you just want to have a decent firewall, simply use the one from the default configuration as a whole and only extend it by rules you really need, such as permission of access to Winbox port from one or two trusted IPs in the internet.