How to ***really*** block invalid TCP and UDP packet

rextended · Tue Mar 25, 2014 11:11 pm

When you set on firewall one rule like:

add action=drop connection-state=invalid

you really not block any malicious connection or package.

This rule simply drop any package or connection if are not finded any match on connection tracking.

The following rule 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.

These are the rules.
That rules must the first rules for each chain.

On input chain we suppose that the router is already protected from other rules.
There are no reason to put the extended rules also on output chain, we suppose RouterOS generate only standard packet.

/ip firewall filter
add action=accept chain=input connection-state=established
add action=accept chain=input connection-state=related
add action=drop chain=input connection-state=invalid
add action=drop chain=forward comment="TCP flags and Port 0 attacks" protocol=tcp tcp-flags=!fin,!syn,!rst,!ack
add action=drop chain=forward protocol=tcp tcp-flags=fin,syn
add action=drop chain=forward protocol=tcp tcp-flags=fin,rst
add action=drop chain=forward protocol=tcp tcp-flags=fin,!ack
add action=drop chain=forward protocol=tcp tcp-flags=fin,urg
add action=drop chain=forward protocol=tcp tcp-flags=syn,rst
add action=drop chain=forward protocol=tcp tcp-flags=rst,urg
add action=drop chain=forward protocol=tcp src-port=0
add action=drop chain=forward dst-port=0 protocol=tcp
add action=drop chain=forward protocol=udp src-port=0
add action=drop chain=forward dst-port=0 protocol=udp
add action=accept chain=forward connection-state=established
add action=accept chain=forward connection-state=related
add action=drop chain=forward connection-state=invalid
add action=accept chain=output connection-state=established
add action=accept chain=output connection-state=related
add action=drop chain=output connection-state=invalid

IF ANYONE USE MY IDEA OR THIS RULES, PLEASE ADD KARMA.
THANKS TO ALL.

If anyone find a bug, please report.
Thanks.

efaden · Tue Mar 25, 2014 11:58 pm

Thanks

Sent from my SCH-I545 using Tapatalk

efaden · Wed Mar 26, 2014 12:06 am

When you set on firewall one rule like:
add action=drop connection-state=invalid
you really not block any malicious connection or package.

This rule simply drop any package or connection if are not finded any match on connection tracking.

The following rule 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.

These are the rules.
That rules must the first rules for each chain.

On input chain we suppose that the router is already protected from other rules.
There are no reason to put the extended rules also on output chain, we suppose RouterOS generate only standard packet.
Code: Select all
/ip firewall filter
add action=accept chain=input connection-state=established
add action=accept chain=input connection-state=related
add action=drop chain=input connection-state=invalid
add action=drop chain=forward comment="TCP flags and Port 0 attacks" protocol=tcp tcp-flags=!fin,!syn,!rst,!ack
add action=drop chain=forward protocol=tcp tcp-flags=fin,syn
add action=drop chain=forward protocol=tcp tcp-flags=fin,rst
add action=drop chain=forward protocol=tcp tcp-flags=fin,!ack
add action=drop chain=forward protocol=tcp tcp-flags=fin,urg
add action=drop chain=forward protocol=tcp tcp-flags=syn,rst
add action=drop chain=forward protocol=tcp tcp-flags=rst,urg
add action=drop chain=forward protocol=tcp src-port=0
add action=drop chain=forward dst-port=0 protocol=tcp
add action=drop chain=forward protocol=udp src-port=0
add action=drop chain=forward dst-port=0 protocol=udp
add action=accept chain=forward connection-state=established
add action=accept chain=forward connection-state=related
add action=drop chain=forward connection-state=invalid
add action=accept chain=output connection-state=established
add action=accept chain=output connection-state=related
add action=drop chain=output connection-state=invalid
IF ANYONE USE MY IDEA OR THIS RULES, PLEASE ADD KARMA.
THANKS TO ALL.

If anyone find a bug, please report.
Thanks.

Why are the only on the forward chain?

rextended · Wed Mar 26, 2014 12:11 am

Why are the only on the forward chain?

Because output chain are generated by RouterOS services, are indipendent from all the other sources, we suppose all output are good,
and the input chain is directed only INSIDE a RouterOS services. I lock/protect from unwanted access all routeros services on input [from internet].

Only the forward traffic go from clients to internet and vice-versa.

For more info:
http://wiki.mikrotik.com/wiki/Manual:Packet_Flow
packet flow inside routeros.

drank · Wed Mar 26, 2014 8:40 am

Isn't it easier to switch to a "default deny" policy and then just open whatever is needed, instead of trying to cover all possible incoming packet scenarios in a "default accept" policy?

Or is there a benefit to it that I am missing?

Thank you and best regards

rextended · Wed Mar 26, 2014 9:34 am

Isn't it easier to switch to a "default deny" policy and then just open whatever is needed, instead of trying to cover all possible incoming packet scenarios in a "default accept" policy?

Or is there a benefit to it that I am missing?

Thank you and best regards

Default deny on Input is ok,
but on forward chain can not cover all possible scenery.
(On output chain "default deny" not matter)

On "Default Deny" mode [the best way] some rules can be breaked, can accept legit destination, but not check if some packed are "bad"...

The only way to be sure to deny all must be denied, is block all literally...

My rules here are for policy integration, not for substitution of all rules

drank · Thu Mar 27, 2014 8:52 am

Aha, I got it. So in "default deny" you open what you need and on top of that you additionally stop malformed/illegal packets (which would otherwise travel through the router if you wouldn't add these additional protocol inspection rules).

Thank you for the explanation.

Best regards.

rextended · Thu Mar 27, 2014 6:16 pm

Aha, I got it. So in "default deny" you open what you need and on top of that you additionally stop malformed/illegal packets (which would otherwise travel through the router if you wouldn't add these additional protocol inspection rules).

Thank you for the explanation.

Best regards.

Exactly!

If any of this are useful to you, please add Karma,
Thanks.

dadaniel · Thu Apr 10, 2014 5:51 pm

The only rule that get hits is

add action=drop chain=forward dst-port=0 protocol=tcp

in my case. 12 Packets in the last 7h.

bajodel · Mon Apr 14, 2014 12:13 pm

thanks rextended, I'd like to give you karma ..but I'm still unable to

edit now I can

coylh · Sun May 25, 2014 5:21 pm

Here's what I get after about a month.

Alupis · Wed Nov 12, 2014 8:46 am

i like this. very similar to the default firewall rules i use whenever setting up a new linux box.

rextended · Wed Nov 12, 2014 3:33 pm

i like this. very similar to the default firewall rules i use whenever setting up a new linux box.

thanks!

Maggiore81 · Sat Dec 13, 2014 8:48 am

Hmmm. I implemented them too. But is it really useful to drop port 0 ?

There are differents views on the matter!

Sat Dec 13, 2014 4:33 pm

Hmmm. I implemented them too. But is it really useful to drop port 0 ?

There are differents views on the matter!

I'm not aware of those "different views"... Only of a few facts...

As far as "outsiders going in" - If your router can be reached by multiple public IPs (that it then forwards to different other devices), dropping port 0 will minimize the effectiveness of a potential (D)DoS attack on your other devices, instead letting your router take the hit. If your router can be accessed from only a single public IP (and your client devices are in a private network), then dropping port 0 will happen anyway, with or without those rules, so it doesn't hurt to have it, at least so that you can see with the counter how much packets like that are you getting.

And as far as "insiders going out" - Dropping port 0 helps to make sure your devices are not originators of such (D)DoS attacks. The rules above could potentially be tweaked to also log offenders from your network, and perhaps even automatically block their entire internet connection on a certain threshold, forcing your clients to fix their devices (which probably have Trojans if they're doing that).

The only "different view" I can see here is whether it's worth sacrificing your router to shield your clients' devices from incoming attacks. If you have multiple ISPs, you can always just temporarily disable the interface of the ISP from which port 0 packets are coming, in turn keeping your router alive AND keeping your clients blissfully ignorant that there's even a problem. If you don't have multiple ISPs though, making the call is a little tougher. You are making a bet as to whether an attacker will make a large scale attack on all of your public IPs at once. If so, taking the hit is worth it, but if only one IP is attacked, it probably isn't.

amigo3900 · Wed Dec 31, 2014 10:09 am

Thank you so much for this advice. Karma is given!

Could you please advise on how to tweak? :

"And as far as "insiders going out" - Dropping port 0 helps to make sure your devices are not originators of such (D)DoS attacks. The rules above could potentially be tweaked to also log offenders from your network, and perhaps even automatically block their entire internet connection on a certain threshold, forcing your clients to fix their devices (which probably have Trojans if they're doing that)."

Thanking you

Hennie

rado3105 · Sun Feb 08, 2015 6:44 pm

Is it not better to use reject instead of drop?

Mon Feb 09, 2015 12:15 am

Is it not better to use reject instead of drop?

From a security standpoint, it's better to drop instead of reject.

"Reject" will notify the other end that they've been declined access, making the attacker aware of the presence of the rule, and implicitly, the presence of your device (in that "it's online"). Furthermore, in a DDoS prevention case, sending ANY packet (even a single ICMP packet) per attempted connection means you're doing more load on the network, meaning it takes less coordinated devices to take you down.

"Drop" will not notify the attacker about the rejection, in that it will not send anything. Without further information and/or prior knowledge, the attacker wouldn't know if your device is offline, doesn't exist at all, or exists, but has a rule for dropping the packet. And also, since there's no packets going back on the line, it would take more incoming packets before the uplink goes down.

"Reject" is useful for routers inside larger networks for debugging purposes, but not so much for "edge" routers (i.e. those connected directly to the internet).

elmakong · Fri May 15, 2015 3:17 pm

i test this rule. and merge some accept rules to one...connection state established, related....is there any difference?
using winbox to add rule

Fri May 15, 2015 6:00 pm

Do not forget TARPIT for TCP data. What does it do ?

basically for bad connections, will keep a connection open until it times out (12-24 minutes depending on the client). With most brute force attacks running as a loop through a list of user names and passwords, keeping the connection open that long increases the attack time by enough that the bad guys will either give up or produce no useful result.

http://en.wikipedia.org/wiki/Tarpit_%28 ... el_tarpits
http://www.symantec.com/connect/article ... ms-tarpits

TomosRider · Wed May 20, 2015 4:29 pm

Nice topic. Will give these rules a shot...

RackKing · Sun Jun 14, 2015 5:59 pm

So I understand these rules would be in addition to existing firewall rules - as somewhat of a newbie, in a home environment would I simply add these to the standard Mikrotik home config they recommend?

/ip firewall filter
add chain=input connection-state=established action=accept
add chain=input connection-state=related action=accept
add chain=input connection-state=invalid action=drop
add action=drop chain=forward comment="TCP flags and Port 0 attacks" protocol=tcp tcp-flags=!fin,!syn,!rst,!ack
add action=drop chain=forward protocol=tcp tcp-flags=fin,syn
add action=drop chain=forward protocol=tcp tcp-flags=fin,rst
add action=drop chain=forward protocol=tcp tcp-flags=fin,!ack
add action=drop chain=forward protocol=tcp tcp-flags=fin,urg
add action=drop chain=forward protocol=tcp tcp-flags=syn,rst
add action=drop chain=forward protocol=tcp tcp-flags=rst,urg
add action=drop chain=forward protocol=tcp src-port=0
add action=drop chain=forward dst-port=0 protocol=tcp
add action=drop chain=forward protocol=udp src-port=0
add action=drop chain=forward dst-port=0 protocol=udp
add chain=input in-interface=inside action=accept
add chain=input action=drop
add chain=forward connection-state=established action=accept
add chain=forward connection-state=related action=accept
add chain=forward connection-state=invalid action=drop
add chain=forward in-interface=inside action=accept
add action=accept chain=output connection-state=established
add action=accept chain=output connection-state=related
add action=drop chain=output connection-state=invalid

Does something like that work? does someone have a home router config they would post that includes these more locked down rules?

Thanks

RackKing · Tue Jun 16, 2015 9:29 pm

Anyone?

amt · Fri Jun 17, 2016 2:46 pm

When you set on firewall one rule like:
add action=drop connection-state=invalid
you really not block any malicious connection or package.

This rule simply drop any package or connection if are not finded any match on connection tracking.

The following rule 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.

These are the rules.
That rules must the first rules for each chain.

On input chain we suppose that the router is already protected from other rules.
There are no reason to put the extended rules also on output chain, we suppose RouterOS generate only standard packet.
Code: Select all
/ip firewall filter
add action=accept chain=input connection-state=established
add action=accept chain=input connection-state=related
add action=drop chain=input connection-state=invalid
add action=drop chain=forward comment="TCP flags and Port 0 attacks" protocol=tcp tcp-flags=!fin,!syn,!rst,!ack
add action=drop chain=forward protocol=tcp tcp-flags=fin,syn
add action=drop chain=forward protocol=tcp tcp-flags=fin,rst
add action=drop chain=forward protocol=tcp tcp-flags=fin,!ack
add action=drop chain=forward protocol=tcp tcp-flags=fin,urg
add action=drop chain=forward protocol=tcp tcp-flags=syn,rst
add action=drop chain=forward protocol=tcp tcp-flags=rst,urg
add action=drop chain=forward protocol=tcp src-port=0
add action=drop chain=forward dst-port=0 protocol=tcp
add action=drop chain=forward protocol=udp src-port=0
add action=drop chain=forward dst-port=0 protocol=udp
add action=accept chain=forward connection-state=established
add action=accept chain=forward connection-state=related
add action=drop chain=forward connection-state=invalid
add action=accept chain=output connection-state=established
add action=accept chain=output connection-state=related
add action=drop chain=output connection-state=invalid
IF ANYONE USE MY IDEA OR THIS RULES, PLEASE ADD KARMA.
THANKS TO ALL.

If anyone find a bug, please report.
Thanks.

Hi,
can i use it for ddos ? can it handle for ddos attack ?

Thanks

soamz · Sat Jul 30, 2016 11:08 am

So whats the final version of code to add ?

chuky0 · Sun May 28, 2017 8:52 am

Should these be used for ipv6 filter as well?

hlev80 · Tue Jan 02, 2018 1:32 am

add action=drop chain=forward protocol=tcp tcp-flags=fin,!ack

Why is this rule there?
As I read it, it drops TCP FIN packets on the forward chain in both directions, doesn't it? If so, why is that desirable?

MichalPospichal · Sat Mar 03, 2018 10:06 pm

Code: Select all
add action=drop chain=forward protocol=tcp tcp-flags=fin,!ack
Why is this rule there?
As I read it, it drops TCP FIN packets on the forward chain in both directions, doesn't it? If so, why is that desirable?

I think the correct interpretation of the rule is "Drop if TCP FIN AND is NOT ACK

anav · Sat Mar 03, 2018 11:06 pm

Can we, or better......... SHOULD we move any of your rules into RAW vice Filter??? If so which ones? and why> and if not, why not??

Nollitik · Sun Mar 04, 2018 7:19 pm

Is there such a thing as port 0 UDP? I thought UDP ports are 1025 - 65535, although this throws a monkey wrench: https://en.wikipedia.org/wiki/List_of_T ... rt_numbers

Ports 1 - 1024 are privilege ports and is always source ports...never destination ports.

anav · Mon Mar 05, 2018 1:48 am

Nollitick, google is your friend if you want to learn about TCP and UDP packets.
This thread is about blocking TCP and UDP.

Ex....
Security Activity Bulletin
TCP/IP and UDP Network Traffic with a Source Port of 0

Summary
Malformed TCP/IP and UDP network traffic may have a source port of 0. TCP and UDP port 0 is a reserved port and should not normally be assigned. Traffic with this configuration may indicate malicious or abnormal activity. Intrusion detection or intrusion prevention devices may detect and/or block such traffic using signatures. Administrators should be aware that ongoing transmissions of TCP/IP and UDP packets with a source port of 0 could indicate ongoing attacks, such as spoofing or an attempt to identify a targeted host's operating system.

Nollitik · Mon Mar 05, 2018 3:42 am

Nollitick, google is your friend if you want to learn about TCP and UDP packets.
This thread is about blocking TCP and UDP.

Ex....
Security Activity Bulletin
TCP/IP and UDP Network Traffic with a Source Port of 0

Summary
Malformed TCP/IP and UDP network traffic may have a source port of 0. TCP and UDP port 0 is a reserved port and should not normally be assigned. Traffic with this configuration may indicate malicious or abnormal activity. Intrusion detection or intrusion prevention devices may detect and/or block such traffic using signatures. Administrators should be aware that ongoing transmissions of TCP/IP and UDP packets with a source port of 0 could indicate ongoing attacks, such as spoofing or an attempt to identify a targeted host's operating system.

Thank you Anav for the tip...I believe the router should recognize that port 0 is not a valid port and drops the traffic as others have said. I won't include those (TCP or UDP).

Nollitik · Tue Mar 06, 2018 5:53 am

Well. I decided to implement all the rules despite having a PFSense machine with Suricata and Snort in front of the Mikrotik...will now add karma to OP...thank you! Oh...could not find the karma button

Cha0s · Tue Mar 06, 2018 1:45 pm

I am not sure blocking traffic with port 0 is wise.

As far as I know, when the payload of a message is too large to fit in a TCP/UDP packet (see MTU), then it gets split into multiple packets (ie: fragmented packets).
The first packet contains the TCP/UDP headers with the source/dest ports but the next fragmented packets do not contain the real ports but port 0.

So as far as I understand it, dropping traffic with source/dest port 0, you might as well drop legit traffic that simply didn't fit in single packets and had to get fragmented into multiple ones.
But, if PMTUd works properly on both ends, then theoretically there shouldn't be a problem with dropping this traffic.

Granted, many DDoS attacks use this fragmentation method to probably bypass firewalls or generally make it harder to drop without dropping legit traffic.

Edit: A way better explanation on port 0 that I remembered myself about it. http://www.lovemytool.com/blog/2013/08/ ... cleod.html

anav · Wed Mar 07, 2018 4:36 pm

Still waiting from the OP, conveniently does not have an IM LOL, to state which of his rules make sense to put in RAW filtering?????????????

pe1chl · Wed Mar 07, 2018 5:13 pm

Wouldn't it be much easier to just block all packets with the EVIL bit set according to RFC3514?

rextended · Mon Jun 11, 2018 6:26 pm

Still waiting from the OP, conveniently does not have an IM LOL, to state which of his rules make sense to put in RAW filtering?????????????

When I wrote the post, "raw" did not exist at that time.

rextended · Mon Jun 11, 2018 6:34 pm

Wouldn't it be much easier to just block all packets with the EVIL bit set according to RFC3514?

You have read all RFC3514? It's a joke...
"Attack program must set evil bit"...

George90 · Fri Aug 31, 2018 6:37 am

I have a problem with droping invalid packets rule (forward).
Sometimes drop packets from VPN clients, sometimes doesn't.
What can be problem?

expert · Fri Aug 31, 2018 12:17 pm

As far as I know, when the payload of a message is too large to fit in a TCP/UDP packet (see MTU), then it gets split into multiple packets (ie: fragmented packets).
The first packet contains the TCP/UDP headers with the source/dest ports but the next fragmented packets do not contain the real ports but port 0.

Your post is absolutely odd. MTU has nothing to do with TCP or UDP. IP reassembly occurs of course on 3rd (IP) layer, whereas 4th (TCP) layer sees already defragmented packets.
Of course TCP header is only in the first IP fragment, and is never ever repeated in next fragments.

I suggest you to study IP reassembly algorithm (RFC 815).

Cha0s · Fri Aug 31, 2018 12:46 pm

Well,

You are the expert. Why don't you explain it to us then?

expert · Fri Aug 31, 2018 1:04 pm

Well,

You are the expert. Why don't you explain it to us then?

Well, you're forum veteran, so why you're posting impressions instead of facts here?

vchrizz · Wed Dec 05, 2018 6:22 pm

Still waiting from the OP, conveniently does not have an IM LOL, to state which of his rules make sense to put in RAW filtering?????????????
When I wrote the post, "raw" did not exist at that time.

question regarding setup of a firewall on an edge router, is the ruleset from OP still apropriate to use nowadays?
regarding "raw" i guess the ruleset would look different now?

do "connection-state=established" and "connection-state=related" have to be each in an own rule? i usually set them both in one rule?

as this thread ranks top on google searches, a recent example would be great!
thanks

elico · Mon Aug 05, 2019 2:03 am

I am missing a full "fasttracked" rule-set with these protection rules.
I assume that the ESTABLISHED,RELATED and INVALID (ACCEPT, FASTTRACK and DORP) can be matched before these filtering rules.
Even if some of the TCP packets are malformed I am assuming the attacked side would not accept these as it probably have a steady IP stack.
If for some reason these will fail, the issue would probably be much worse and might be parallel to "TCP SACK" cve's level.

Also I am not sure but pretty sure that 0 port packets will not be masqueraded to the world via nat.
(As in a linux kernel these would be forwarded to the next hop or network hop as a routed packet)

Who is online