Community discussions

MikroTik App
 
TicToc
just joined
Topic Author
Posts: 10
Joined: Mon Nov 02, 2015 4:22 am

Drop Invalid vs. Drop "all"

Mon Jul 26, 2021 3:19 am

Hello,

i am making myself familiar with Mikrotik these days. Coming from a Netgate/pfSense background, it took me some time to get used to it but a little bit of knowledge
about IPTables and the book RouterOS by example SE from Stephen R.W. Discher made things easier for me.

Still, there are a few things i have a hard time to understand, so maybe you can help me out a little bit.

In the Mikrotik firewall setup guide one of the rule examples in the forward chain is to drop "invalid" packets, so packets that don`t have an entry in the conntrack table, right?
But why do i have to drop invalid packets if i do that implicitly by using a drop (ALL) for the INPUT and FORWARD chain anyways? Is there a specific reason behind it?

Same with bogon IPs. Mikrotik recommends in their guide, to drop packets on WAN coming from non-public IPv4 adress spaces.
That makes sense of course but from my experience, this is only really necessary if you need access from WAN to ports on the router itself (INPUT chain) or to one of your internal hosts (FORWARDING chain) If you don`t forward anything at all, then there is no need to explicitly drop bogon IP spaces, correct?

Thank you :)
Last edited by TicToc on Mon Jul 26, 2021 1:13 pm, edited 1 time in total.
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11381
Joined: Thu Mar 03, 2016 10:23 pm

Re: Drop Invalid vs. Drop "all"

Mon Jul 26, 2021 8:55 am

Re. drop invalid: invalid packets are not the ones that don't have corresponding entry in conntrack table (in principle those are "new" packets), but those which don't have valid characteristics. That could either be invalid according to existing conntrack entry (i.e. too low sequence number for TCP packet or invalid flags) or have invalid characteristics for new conection (e.g. fail to establish the 3-way handshake for new TCP connection).
The default implicit action of any firewall chain is to accept the packet which doesn't match any criteria. So if you want to drop invalid packets, you can either explicitly drop those or add explicit "drop all" rule at the end. However, you can add "drop invalid" rule quite at the top of the rule list hence you drop invalids early in the process. This both reduces chance of invalid packet to pass the firewall and somehow reduces processing efforts needed to process packets (as invalids are dropped early). Keep in mid that firewall filter rules are processed from top to bottom and packet matching later rules requires some more processing resources than packet dropped (or accepted) early. When rules are equally important from security point of view (and don't target the same packet properties), then for performance reasons rules targeting larger share of packets should come earlier.

Dropping bogons is seen as enforcement of security. If you drop packets which ingress router/firewall through interfaces where they should not, this largely reduces chances of getting hacked using spoofed addresses ... or DoS attack targeting internal servers. Similar reasoning is behind dropping bogons on egress ... in case NAT table or routing table gets somehow corrupted (or in case of incorrect SRC-NAT configuration).
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Drop Invalid vs. Drop "all"

Mon Jul 26, 2021 2:10 pm

Good question and well explained by mkx!

I would add that I keep it in both chains because I dont want invalid packets being compared to any other firewall rules along the line, just want them out of the system at the earliest opportunity. Also probably because I dont know much about packets and networking and thus I have unknown and maybe unrealistic fears that exploits/hacks could occur with invalid packets!

As for the bogon list, the only one I can see of any use is the LAN to WAN one, placed just prior to the rule allowing your basic LAN to WAN internet traffic. In this case I can see some logic in that instead of letting all traffic to the internet (wide open) one can without any danger to normal traffic block those bogon addresses.
In this case your drop all rule will not catch them because they are already matched and allowed if they hit the allow internet traffic rule.
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11967
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: Drop Invalid vs. Drop "all"

Mon Jul 26, 2021 2:36 pm

>retry later to explain<
Last edited by rextended on Mon Jul 26, 2021 5:55 pm, edited 1 time in total.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Drop Invalid vs. Drop "all"

Mon Jul 26, 2021 5:37 pm

Rextended that was a very confusing and thus not useful post.
I couldnt really understand the points being made to learn what I need to know which is a tad frustrating because you are trying patiently to educate us non-TCP
/IT literate folks and really do appreciate the effort.

Suggesting that you write in very smooth poetic Italian and add it as a separate paragraph and then I can translate through various programs so that I can understand.

(1) Didnt understand what invalid actually does?
(2) Dont know the right way to stop all those other issues that have not affected me yet, but you seem to think are dangerous, that invalid does not cover?
(3) Didnt understand how incoming bogons would reach my router if I have a drop all end rule on my input chain?
(4) Didnt understand clearly why a block bogon from LAN to WAN prior to my allow all traffic to internet was a bad idea??
 
TicToc
just joined
Topic Author
Posts: 10
Joined: Mon Nov 02, 2015 4:22 am

Re: Drop Invalid vs. Drop "all"

Mon Jul 26, 2021 5:39 pm

First of all thank you for all your replies.

From the IPTables documentation, the INVLAID state is described and i quote:
The INVALID state means that the packet can't be identified or that it does not have any state. This may be due to several reasons, such as the system running out of memory or ICMP error messages that do not respond to any known connections. Generally, it is a good idea to DROP everything in this state.
So simply put, any packet that is not NEW, ESTABLISHED, RELATED or is either unidentifiable or otherwise "stateless" is considered INVALID.
With that being said, are the following assumptions correct?

- If your firewall rules are completly stateful, there is no need to explicitly drop INVALID packets.
(Here is an IPTables example that hopefully illustrates what i am getting at.)

Example 1:
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p tcp --dport 22 -j ACCEPT

Example 2:
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT

In example 1 invalid packets would be accepted whereas in example 2 no invalid packets would come through (assuming you have a default DROP all rule at the end of the INPUT chain)
because only packets with a state of NEW, ESTABLISHED and RELATED are allowed anyways.

If you forward any traffic originating from one of you local subnets, lets say:

add action=accept chain=forward src-address-list=$LAN_network in-interface=ether2 (LAN) out-interface=ether1 (WAN)

I can see the benefit of checking for invalid packets because, if my way of thinking is correct (according to the example above) invalid packets could go through with that forwarding rule alone, even if i drop ALL at the end of the forwarding chain. But if i make this rule stateful by only forwarding NEW, ESTABLISHED RELATED connections then i don`t need to worry about invalid packets.
Are my assumptions in this case correct as well?

@rextended
Sorry, i appreciate your effort but i can`t really follow your train of thought.
I do think that we mean more or less the same, Cause your seem to acknowledge the fact that droping invalid explicitly is not needed, if there is a general DROP policy (rule) in place but as soon as you open ports in a stateless manner, things change. Did i get that right?
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11967
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: Drop Invalid vs. Drop "all"

Mon Jul 26, 2021 5:53 pm

Yes, sorry for all for poor traduction...

I try to extremely summarize without write too much why:

IF some services on LAN side are opened for WAN (NATted or using directly a Public IP)
Try to not drop TCP packet than appear to be with source "bogon-used-on-lan" coming from WAN directed to LAN services,
if are "last ACK from Client" (TCP/ACK) or RST packet (TCP/RST)
because some remote router do not translate on NAT the source IP of the last packet used for close the connection,
and the packet instead coming with Public IP have one of the "bogon-used-on-lan".
Stopping that packet cause the service use more memory because from 30s to 30m the connection is still considerered open for lack of ACK (or RST).


The rule "invalid" do not consider:
1) TCP packet with invalid Flags
2) invalid IP Options on packet
3) invalid Ports 0
4) SYN fragmented attack
5) New TCP connection without SYN attack

BUT you can block all with drop all at the end of chain

BUT if you open one or more services on LAN, reaachables from WAN,
if those things are not blocked, can reach the service on internal LAN.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Drop Invalid vs. Drop "all"

Mon Jul 26, 2021 6:21 pm

Okay

Can you provide services that are open on the ROUTER (not the LAN) ???
Other than VPN I cannot think of any I would open?
I do have NTP server but points to internet time clock.
I do have DNS services but points to internet DNS servers.

What does invalid protect if the DROP all rule is in place? (other than small CPU losses if waiting for drop all rule) ?
If no benefit, then assuming MT includes it because their default concept is allow all block rest?

So this may boil down to your concern if someone has port forwarding allowed on their router.
In other words, if ANY traffic is coming to the router with a destination public IP: and a destination port, then there is possibility of problems.
We agree.
Step one: Use source address list. If not then your server is open to the internet wide open. Source address list helps narrow down the entry list.
Step Two: If possible ensure the server has decent protection not just open password (at least encrypted https, or FTPs login etc.)
(RP filter loose also helps keep the reins on bad traffic.)
Step Three: What else............... is this where you state on the forward chain drop all bogons headed for the LAN, and if so would have to be done before the allow rule for port forwarded traffic as the drop all rule would note be reached.

In summary,
What I can do then is
a. get rid of invalid rule in both chains
b. get rid of lan to wan bogon rule
c. add wan to lan bogon rule right before allow port forwarding rule.
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11381
Joined: Thu Mar 03, 2016 10:23 pm

Re: Drop Invalid vs. Drop "all"

Mon Jul 26, 2021 6:25 pm

Stopping that packet cause the service use more memory because from 30s to 30m the connection is still considerered open for lack of ACK (or RST).

I don't think this is correct. According to ROS packet flow, both connection tracking and SRC-NAT are part of prerouting part of packet flow ... but connection tracking comes first, connection state gets updated on home router even before SRC-NAT does its magic. Firewall filter comes much later (towards the end of forward part of packet flow) and dropping a packet there doesn't affect the connection state.

If you're writing about remote router failing to SRC-NAT certain packet ... well, in that case connection tracking machinery can't guess that he RST (or FIN) packet arriving from some RFC1918 address (with non-translated src-port as well!) belongs to some particular connection, can it?

The rule "invalid" do not consider
Do you mind to elaborate this further? The way I understand things these are exactly cases of invalid packet and fikter rule would drop them.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Drop Invalid vs. Drop "all"

Mon Jul 26, 2021 6:29 pm

Allrighty then we have a debate! Bring it ON. I learn when the masters bring their points forward!!
Okay so I dont have much of a life and this is my excitement of the day, I may learn something.
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11967
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: Drop Invalid vs. Drop "all"

Mon Jul 26, 2021 7:12 pm

If I do not remember wrong, the last packet on TCP connection is not a FIN (server->client) but consecutive "last ACK" (client->server)
Server: FINished!
Client: ACKnowledged.
And if the server do not receive ACK, close the connection after some time, depend on settings, on meantime the connection resources still busy.

Do you mind to elaborate this further? The way I understand things these are exactly cases of invalid packet and fikter rule would drop them.
Simply after drop "invalid" place my rules on the link on my signature and watch the counters...

But I have explicity write: are necessary only if someting on NAT is leaved open for internal LAN services, not hosted on routerboard, like e-mail, webserver, ftp, etc.
when this services mus be used worldwide.

Also APNIC suggest that some of that rules must be placed:
https://blog.apnic.net/2021/06/24/how-t ... imization/
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Drop Invalid vs. Drop "all"

Mon Jul 26, 2021 7:24 pm

@rextended, Drop me an email if you get a chance and are inclined to do so.
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11967
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: Drop Invalid vs. Drop "all"

Mon Jul 26, 2021 7:33 pm

Uhm...
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Drop Invalid vs. Drop "all"

Mon Jul 26, 2021 8:04 pm

signature if stumped.......
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11967
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: Drop Invalid vs. Drop "all"

Mon Jul 26, 2021 8:20 pm

You got "Greetigs form Italy"
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11381
Joined: Thu Mar 03, 2016 10:23 pm

Re: Drop Invalid vs. Drop "all"

Mon Jul 26, 2021 10:20 pm

And if the server do not receive ACK, close the connection after some time, depend on settings, on meantime the connection resources still busy.

Right, in Linux such connection state is called FIN_WAIT or FIN_WAIT2. I still fail to see how not dropping non-NATed ACK (or whatever is sent) helps server (or any innocent firewall in between) to release resources sooner than until after timers expire.


Do you mind to elaborate this further? The way I understand things these are exactly cases of invalid packet and fikter rule would drop them.
Simply after drop "invalid" place my rules on the link on my signature and watch the counters...

But I have explicity write: are necessary only if someting on NAT is leaved open for internal LAN services, not hosted on routerboard, like e-mail, webserver, ftp, etc.
when this services mus be used worldwide.
I'm not going to observe counters, they don't tell much about what is really happening on the line. I'd still like to hear (read) the reasoning why it's useless (or why one should not even) to drop packets, flagged as "invalid" by ROS' connection tracking machinery. As long as none of valid packets gets dropped (hampering or breaking valid ongoing connection) it doesn't hurt ... even if it doesn't really help with security as much as innocent firewall administrator would like to think.
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11967
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: Drop Invalid vs. Drop "all"

Mon Jul 26, 2021 10:23 pm

One explicit thing for be clear: I never say to remove the "invalid" filter on firewall.

Who is online

Users browsing this forum: cciprian, GoogleOther [Bot], sokalsondha and 36 guests