For ISP: How to ***really*** block invalid ICMP, TCP, UDP packets and others (ver. 2021)

rextended · Tue Mar 25, 2014 11:11 pm

search tag # rextended firewall raw rules

Added 2021-07-06:
compared from 2014 version i have added a lot more things
I am not done, I add more when I have time.
WORK IN PROGRESS

I appreciate any suggestions, and also positive comments, if any...

Thanks BartoszP, I actualize the rules when I can
viewtopic.php?f=9&t=83387#p482224
************************************************

When you set on firewall one rule like the default:

add action=drop connection-state=invalid

you really not block any malicious connection or packet.
The drop invalid rule simply drop any package or connection if are not finded any match on "connection tracking".

The following rules block all forged or incorrect packages, instead.
This rule are based on how the TCP and UDP packages must be written to be valid on RFC rules.
Any comment like "UDP Port 0 are used with some load balancers" we do not matter, do not follow the RFC rules and not used from MikroTik.
boen_robot explain more:
viewtopic.php?f=9&t=83387&p=417864#p460244

That rules must be set on "/firewall raw", on this way do not interfere how regular default "/firewall filter" works.

Warning: those rules do not replace, but must be used at least with default "/firewall filter" rules.

/ip firewall raw
add action=drop chain=prerouting comment="TCP invalid combination of flags attack (7 rules)" protocol=tcp tcp-flags=!fin,!syn,!rst,!ack
add action=drop chain=prerouting protocol=tcp tcp-flags=fin,syn
add action=drop chain=prerouting protocol=tcp tcp-flags=fin,rst
add action=drop chain=prerouting protocol=tcp tcp-flags=fin,!ack
add action=drop chain=prerouting protocol=tcp tcp-flags=fin,urg
add action=drop chain=prerouting protocol=tcp tcp-flags=syn,rst
add action=drop chain=prerouting protocol=tcp tcp-flags=rst,urg
add action=drop chain=prerouting comment="TCP Port 0 attack (2 rules)" protocol=tcp src-port=0
add action=drop chain=prerouting dst-port=0 protocol=tcp
add action=drop chain=prerouting comment="UDP Port 0 attack (2 rules)" protocol=udp src-port=0
add action=drop chain=prerouting dst-port=0 protocol=udp

Why is better "drop" than a (lost CPU time and generate useless traffic with) "reject"
Again thanks to boen_robot for explain:
viewtopic.php?f=9&t=83387&p=417380#p467921

SYN fragmented attack

/ip firewall raw
add action=drop chain=prerouting comment="SYN fragmented attack" fragment=yes protocol=tcp tcp-flags=syn

Protected Zone (protect against Teardrop Attack and others)
Some type of attacks use IP packet fragmentation.
Some packet fragmentation can be wanted or needed.
For create "Protected Zones" from IP Fragmented Attack, use one or both of this

Create one interface list of protected Interfaces:

/interface list
add name=fragment_protected_interface
/ip firewall raw
add action=drop chain=prerouting comment="Fragment attack Interface Protection" fragment=yes in-interface-list=fragment_protected_interface

Create one address list of protected IPs:

/ip firewall address-list
add address=2.3.4.5 list=fragment_protected_IP
/ip firewall raw
add action=drop chain=prerouting comment="Fragment attack IP Protection" fragment=yes dst-address-list=fragment_protected_IP

IP Options attacks
Attack made with normally unused (or misused) IPv4 flag options.

/ip firewall raw
add action=drop chain=prerouting comment="IP option loose-source-routing" ipv4-options=loose-source-routing
add action=drop chain=prerouting comment="IP option strict-source-routing" ipv4-options=strict-source-routing
add action=drop chain=prerouting comment="IP option record-route" ipv4-options=record-route
add action=drop chain=prerouting comment="IP option router-alert" ipv4-options=router-alert
add action=drop chain=prerouting comment="IP option timestamp" ipv4-options=timestamp
add action=drop chain=prerouting comment="IP options left, except IP Stream used by the IGMP protocol" ipv4-options=any protocol=!igmp

IP Spoofing (prevent LAND Attack and others)
All ISPs should do this and 95% of DDoS attacks wouldn't exist ...

The default configuration have two interface list for WAN and for LAN:

/interface list
add name=WAN
add name=LAN

Defining one or more IP list of IP used on LOCAL side of network (can be also Public IPs):

/ip firewall address-list
add address=192.168.88.0/24 list=IP_used_on_LAN

We do not expect Internal IP incoming from WAN or from Internal LAN incoming other IP than the IP_used_on_LAN

/ip firewall raw
add action=drop chain=prerouting comment="IP Spoofing protection from WAN" in-interface-list=WAN src-address-list=IP_used_on_LAN
add action=drop chain=prerouting comment="IP Spoofing protection from LAN" in-interface-list=LAN src-address-list=!IP_used_on_LAN \
    src-address=!0.0.0.0 dst-address=!255.255.255.255

src-address=!0.0.0.0 and dst-address=!255.255.255.255 prevent to block services on LAN like DHCP Server (src 0.0.0.0 -> dst 255.255.255.255)

Unused Protocol
Removing unassigned protocol is not feasible easily, because on protocol filed accept only one number, not interval
The protocol from 144 to 255 are unassigned https://www.iana.org/assignments/protoc ... bers.xhtml
But on real use not all 144 protocols are used, for example on 95% of cases only 1 ICMP, 6 TCP and 17 UDP.
We can not set a rule like drop protocol=144-255 because is unsupported, we can accept all used, and drop the others.
This rules must be put at THE END!!!

/ip firewall raw
add action=accept chain=prerouting protocol=icmp
add action=accept chain=prerouting protocol=igmp
add action=accept chain=prerouting protocol=tcp
add action=accept chain=prerouting protocol=udp
add action=accept chain=prerouting protocol=gre
add action=log chain=prerouting log-prefix="Not TCP protocol" protocol=!tcp
add action=drop chain=prerouting comment="Unused protocol protection" disabled=yes protocol=!tcp

The last rule is disabled on purpose, first add all protocol you use (for example 47 GRE for pptp, EoIP etc.) before you enable it
Accept pass to next /firewall filter section, do not accept directly the packet.

New TCP connection without SYN
New TCP connection must start with packet with SYN flag
If the SYN on first packet are not present, is an attack or scan for sure...
Each rule must go first on /ip firewall filter on respective input and forward section, do not work on raw, because need connection-tracking for work.

/ip firewall filter
add action=drop chain=input connection-state=new protocol=tcp tcp-flags=!syn comment="TCP non SYN scan attack input"
add action=drop chain=forward connection-state=new protocol=tcp tcp-flags=!syn comment="TCP non SYN scan attack forward"

If anyone find a bug, please report.
Thanks.

donkeyKong · Sat Jun 03, 2023 11:19 am

Thanks for these helpful rules. Using Wireguard, I've gotten quite a few droppped packets by the UDP drop port zero rule, for traffic which seems to be valid:

 01:13:56 firewall,info UDP port 0 prerouting: in:(unknown 1) out:(unknown 0), connection-state:new proto UDP, 127.0.0.1:13131->127.0.0.1:0, len 176

I'm using this rule instead:

add action=drop chain=prerouting protocol=udp port=0 src-address=!127.0.0.1 dst-address=!127.0.0.1

hagoyi · Sun Jun 18, 2023 12:36 pm

New TCP connection without SYN
New TCP connection must start with packet with SYN flag

/ip firewall filter
add action=drop chain=input connection-state=new protocol=tcp tcp-flags=!syn comment="TCP non SYN scan attack input"
add action=drop chain=forward connection-state=new protocol=tcp tcp-flags=!syn comment="TCP non SYN scan attack forward"

Does this rule do the same as using STRICT TCP tracking as you wrote in this post? In other words, do I need to add this "TCP non SYN scan attack" rule if I'm already using STRICT tracking ?

/ip firewall connection tracking
set loose-tcp-tracking=no

rextended · Sun Jun 18, 2023 6:41 pm

New TCP connection without SYN
New TCP connection must start with packet with SYN flag
Code: Select all
/ip firewall filter
add action=drop chain=input connection-state=new protocol=tcp tcp-flags=!syn comment="TCP non SYN scan attack input"
add action=drop chain=forward connection-state=new protocol=tcp tcp-flags=!syn comment="TCP non SYN scan attack forward"
Does this rule do the same as using STRICT TCP tracking as you wrote in this post? In other words, do I need to add this "TCP non SYN scan attack" rule if I'm already using STRICT tracking ?
Code: Select all
/ip firewall connection tracking
set loose-tcp-tracking=no

This is for "SYN scan attack" not for (randomly) resume NAT session if you reboot the router....

anav · Sun Jun 18, 2023 6:49 pm

Wow, pinches himself, I dont use any of these techniques but still humming along just fine!
Am I lucky?
Am I awaiting disaster around the next corner?
Am I pushing my luck?
Or are these measures for specific scenarios:, types of use ( home vs soho vs corporate )

Applicability ?????

rextended · Sun Jun 18, 2023 6:53 pm

Wow, pinches himself, I dont use any of these techniques but still humming along just fine!
Am I lucky?
Am I awaiting disaster around the next corner?
Am I pushing my luck?
Or are these measures for specific scenarios:, types of use ( home vs soho vs corporate )

Applicability ?????

the ISP should do it rather than the end user, the whole topic was ISP oriented, but then I'm not maintaining it that much...

anav · Sun Jun 18, 2023 7:40 pm

Okay got it, this is more for ISP run entities such as those running PPPOE server for many clients etc........
Not aware of enterprise places using MT for Up stream routers............. ( edge routers )??

rextended · Sun Jun 18, 2023 10:23 pm

My edge infrastructure is all MikroTik (all on v6.48.7 except one on 7.10)

hagoyi · Mon Jun 19, 2023 11:38 am

This is for "SYN scan attack" not for (randomly) resume NAT session if you reboot the router....

I understand. But if STRICT were to check every new packet for the SYN flag, it would drop the same bad packets as this "SYN scan attack" rule, right?

ankostis · Wed Oct 18, 2023 3:37 pm

That rules must be set on "/firewall raw", on this way do not interfere how regular default "/firewall filter" works.

Warning: those rules do not replace, but must be used at least with default "/firewall filter" rules.

...

As a warning to others, I tried this 1st code-block and i immediately got locked out of my router - had to hard reset it and restore from backup!

rextended · Wed Oct 18, 2023 3:44 pm

As a warning to others, I tried this 1st code-block and i immediately got locked out of my router - had to hard reset it and restore from backup!

None of those lines, even if applied only one or randomly, can block winbox, webfig, ssh, telnet, etc...
It's a terrible habit to copy-and-paste without knowing what you're doing.
Since 25 Mar 2014 you are the only user auto-locked, it is definitely your fault. Especially if you have been using Windows 11 Notepad.

anav · Wed Oct 18, 2023 4:06 pm

Then the poster is an amazing beta tester or has a special skill set often called error-prone!

Check ur email .!

PS.
Still think the title of this tread should be

"ISPs --> How to ***really*** block invalid ICMP, TCP, UDP packets and others (ver. 2021)"

DarkNate · Wed Oct 18, 2023 7:28 pm

I was hoping rextended removed the ICMP stuff, which is a bad idea to deploy in prod or even for home users.

1. ICMP is rate limited in RouterOS by default, and same on all network vendor OSes, same on Linux vanilla kernel as well
2. Breaks PMTUD and is just stupid, I've seen large-scale networks doing this and then calls me up to ask "Why TCP transfers are slow or unstable on our network?" Answer: "Because you learnt from some random MikroTik forum post."
3. Really only drop ICMP types that IANA has depreciated

rextended · Wed Oct 18, 2023 7:56 pm

which is a bad idea to deploy in prod or even for home users.

Yes, but is clearly indicated:
Warning: this two rules can break the Path MTU Discovery (PMTUD), use only if your device are sensible to "Large ICMP" or "Ping of Death" attack.
On doubt, do not use at all!!!

3) Thanks, added on future update.

ICMP Completely removed, to avoid problems.
In Italy there is a saying: The mother of idiots is always pregnant.

DarkNate · Wed Oct 18, 2023 8:08 pm

Yes, but is clearly indicated:
Warning: this two rules can break the Path MTU Discovery (PMTUD), use only if your device are sensible to "Large ICMP" or "Ping of Death" attack.
On doubt, do not use at all!!!

3) Thanks, added on future update.

ICMP Completely removed, to avoid problems.
In Italy there is a saying: The mother of idiots is always pregnant.

This would still break jumbo frame sized packets. Remove these both as well.

add action=drop chain=prerouting comment="ICMP large packet attack" packet-size=1601-65535 protocol=icmp
add action=drop chain=prerouting comment="ICMP fragmentation attack" fragment=yes protocol=icmp

rextended · Wed Oct 18, 2023 8:11 pm

Oops, left by mistake, removed

jspool · Wed Oct 18, 2023 8:44 pm

IP Spoofing (prevent LAND Attack and others)

If ISP is using OSPF, BGP, BFD,VRRP on any of those interfaces they will need to ensure the rules don't impact those protocols.

rextended · Wed Oct 18, 2023 9:57 pm

they will need to ensure the rules don't impact those protocols.

Remember to tie your shoes if you use shoes with laces.

Any misconfiguration impacts everything.
If you don't know what you're doing, that's the same.

yudh24 · Thu Oct 19, 2023 10:23 am

i didn't get at this point

/ip firewall raw
add action=drop chain=prerouting comment="TCP invalid combination of flags attack (7 rules)" protocol=tcp tcp-flags=!fin,!syn,!rst,!ack
add action=drop chain=prerouting protocol=tcp tcp-flags=fin,syn
add action=drop chain=prerouting protocol=tcp tcp-flags=fin,rst
add action=drop chain=prerouting protocol=tcp tcp-flags=fin,!ack
add action=drop chain=prerouting protocol=tcp tcp-flags=fin,urg
add action=drop chain=prerouting protocol=tcp tcp-flags=syn,rst
add action=drop chain=prerouting protocol=tcp tcp-flags=rst,urg
add action=drop chain=prerouting comment="TCP Port 0 attack (2 rules)" protocol=tcp src-port=0
add action=drop chain=prerouting dst-port=0 protocol=tcp
add action=drop chain=prerouting comment="UDP Port 0 attack (2 rules)" protocol=udp src-port=0
add action=drop chain=prerouting dst-port=0 protocol=udp

on the second till the seventh rule is that same as i create that rule?

/ip firewall raw
add action=drop chain=prerouting protocol=tcp tcp-flags=fin,syn,rst,!ack,urg

or maybe the tcp-flags didnt read by "OR" logic

rextended · Thu Oct 19, 2023 4:46 pm

i didn't get at this point [...]

->For ISP:

Mine are tips on how to block unwanted traffic at the source, not lessons on how TCP/IP works...

on the second till the seventh rule is that same as i create that rule?

NO.
Before making any assumptions, it is better to first study what they are for and how the TCP flags are set, and how firewall match the rule.

erlinden · Thu Oct 19, 2023 5:18 pm

Really love this post, turns out my provider is not blocking a lot....
As well as my GS accesspoints turned out to broadcast a lot to 224.0.0.120.

One thing:

add action=log chain=prerouting log=yes log-prefix="Not TCP protocol" protocol=!tcp

Because the action=log, you don't have to do log=yes as well. Otherwise this line of code will cause double logging per hit.

rextended · Thu Oct 19, 2023 5:37 pm

Because the action=log, you don't have to do log=yes as well. Otherwise this line of code will cause double logging per hit.

Thanks, fixed, the rules coming from RouterOS v6 of 9 years ago... Something is changed. Double-Log bug is inserted....
On old versions you must create separate log entry instead of clicking on "log" on unique entry...

For ISP: How to really block invalid ICMP, TCP, UDP packets and others (ver. 2021)

For ISP: How to really block invalid ICMP, TCP, UDP packets and others (ver. 2021)

Re: How to really block invalid ICMP, TCP, UDP packets and others (ver. 2021)

Re: How to really block invalid ICMP, TCP, UDP packets and others (ver. 2021)

Re: How to really block invalid ICMP, TCP, UDP packets and others (ver. 2021)

Re: How to really block invalid ICMP, TCP, UDP packets and others (ver. 2021)

Re: How to really block invalid ICMP, TCP, UDP packets and others (ver. 2021)

Re: How to really block invalid ICMP, TCP, UDP packets and others (ver. 2021)

Re: How to really block invalid ICMP, TCP, UDP packets and others (ver. 2021)

Re: How to really block invalid ICMP, TCP, UDP packets and others (ver. 2021)

Re: How to really block invalid ICMP, TCP, UDP packets and others (ver. 2021)

Re: How to really block invalid ICMP, TCP, UDP packets and others (ver. 2021)

Re: How to really block invalid ICMP, TCP, UDP packets and others (ver. 2021)

Re: For ISP: How to really block invalid ICMP, TCP, UDP packets and others (ver. 2021)

Re: For ISP: How to really block invalid ICMP, TCP, UDP packets and others (ver. 2021)

Re: For ISP: How to really block invalid ICMP, TCP, UDP packets and others (ver. 2021)

Re: For ISP: How to really block invalid ICMP, TCP, UDP packets and others (ver. 2021)

Re: For ISP: How to really block invalid ICMP, TCP, UDP packets and others (ver. 2021)

Re: For ISP: How to really block invalid ICMP, TCP, UDP packets and others (ver. 2021)

Re: For ISP: How to really block invalid ICMP, TCP, UDP packets and others (ver. 2021)

Re: For ISP: How to really block invalid ICMP, TCP, UDP packets and others (ver. 2021)

Re: For ISP: How to really block invalid ICMP, TCP, UDP packets and others (ver. 2021)

Re: For ISP: How to really block invalid ICMP, TCP, UDP packets and others (ver. 2021)

Who is online