Hello,
I would like to know what are security considerations and risks of enabling FastTrack for established and related connections. I suppose, there are some, otherwise processing such connections by FastTrack should already been deployed as native, built-in behavior.
I would like to hear Mikrotik official representatives’ answer as well.
Thank you.
I think it’s pretty clear why it can’t be always-on built-in feature:
I don’t think its a security problem (unless you have special jumping rules I guess). Its that you can’t manage them with QTrees (if you’re into that sort of thing).
You should control access in from WAN via “New” connections, then anything Rel / Est should be trusted and no security risk
I guess there should be some risks. If not, why it’s not built-in for est\rel. Hopefully Mikrotik officials will also comment in this thread.
Sob answered your question clearly, but you can always mail MikroTik support to get an “official” answer. They will probably refer to the wiki.
MikroTik has stated multiple times that this is a MikroTik “user” forum.
It is not “built in” for flexibility, you might have 1 set of requirements, and the person right next to you might have totally different set of requirements. i.e. Fasttrack does not work well with policy routing, or queues, etc, now you might not have any need for this, but many other people might.
I am using simple queues and packets\connections marking, routing, etc. May be I am missing anything, I am talking about established connections only (let’s forget about related for now, not sure for those). Why one may not want to have FastTrack enabled for established connections?
All connections (except those you block) become established. But you may still want to run them through queues, etc. Only that no longer happens, when you fasttrack them.
Fasttrack and fastpath are always the first options I remove when configuring a router.
I don’t need the performance and I don’t want to debug subtle problems caused by these (because some features do not work in fastpath/fasttrack).
So I am against your proposal.
I also do not see why you want it! The default config has Fasttrack rules and you do not need to touch them.
But please allow me to delete them, do not make then “always there”!
This is what I missed. So it does not negatively impact security, but disables some additional functionalities!? Then sure, it should not be built-in.
P.S. I am still not sure it does not negatively impact security.
I agree with you. Myself I always reset new routers to empty config and configure everything myself. I just recently had some performance related issues and trying to resolve it thought, that why should not FT be always enabled for established connections, if we don’t lose anything. I missed, that even if we don’t have negative security impact, we still lose other functionalities.
Well, it’s clear now why it should not be a built-in feature. But I would like to be sure about security impact when enabling FT for established connections. May be in some very specific scenarios it can be used for attacks, which are not possible, when FT is disabled? Anyone has any ideas?
For me, fasttrack borders on hack. I don’t mean it in bad way, it’s very interesting feature, how to squeeze more from weak devices, and as such it’s great. But there are too many side effects (all those other features it’s not compatible with). It can be done right, e.g. you can selectively fasttrack only connections you know won’t need those other features. But it adds another layer of complexity.
About security, I don’t think there should be any problems. If you use it with established connections, it means that they already went through some sanity checks, so it’s not like anything would pass. Reading how they bypass firewall may sound dangerous, but it’s only from the point you make them fasttracked. And typically you don’t do anything with establieshed connections anyway, except accepting them by very first rules to accept established.
Thank you for the reply Sob.
I never used FastTrack and honestly, I decided to not use it in future as well. I don’t want to have strange issues in future, when I make changes to routers configs and get strange behavior, because I forgot about FT specific functionality and impact.
Besides, while reading your reply, I thought, that if someone hijacks TCP session, for example, FT may ease or open new options for hacks. With UDP it should probably be even easier.
I mean routers use some details on packets to define if they belong to established sessions. Obviously those details can be used to send fake packets, and if FT stops them from being processed further by filters and other stuff, then it may make hacking easier.
Not sure though. I would like to read experts analysis on FT impact on security. Hopefully we’ll have some in future.
Thanks again!