FastTrack security implications

tirkitneth · Sat Oct 10, 2015 12:21 pm

Hello,

I am a little bit concerned using FastTrack because of this sentence on the wiki:

Fasttracked packets bypass firewall, connection tracking, simple queues, queue tree with parent=global, ip traffic-flow(restriction removed in 6.33), ip accounting, ipsec, hotspot universal client, vrf assignment

Currently, my firewall filter forward chain starts like this:

 0  D ;;; special dummy rule to show fasttrack counters
      chain=forward
 1    chain=forward action=drop connection-state=invalid log=no log-prefix=""
 2 X  chain=forward action=fasttrack-connection connection-state=established,related log=no log-prefix=""
 3    chain=forward action=accept connection-state=established,related log=no log-prefix=""

Since I already accept established/related packets without FastTrack, would it make a difference on security to enable rule 2 ?

Thanks.

doneware · Sat Oct 10, 2015 6:22 pm

short answer:
no security implication, just speedup cause fastracked sessions will avoid firewall processing, so they won't bump though the rules till they are accepted or rejected.

longer version:
fastrack works with connection table entries. so if you have a new session, it will go through the "slow" path,
then - say after the 3way tcp handshake - the session is established, so your fw rule will put it on the fastrack path.

if you have NAT, you're fine, cause it's highly unlikely that anybody is able to guess the src-dst address pair of an established session and inject traffic into it.

but w/o NAT, you are pretty much open. The firewall chains accept everything at the end, so if you want to keep filtering the new sessions, you need explicit drop rules. see wiki:
"If a packet has not matched any rule within the chain, then it is accepted."
http://wiki.mikrotik.com/wiki/Manual:IP ... ter#Chains

it's fine that you drop "invalid" connections, but your filter config won't filter any new session establishment, which then will be either accepted (old config) or fastracked (new config)

So to be secure _without_ NAT, i'd add a rule to your forward chain at the end:
/ip firewall filter add chain=forward in-interface=<the name of your public interfaces> action=drop

this will reject connections coming from the outside, but still allows to start new connections from the inside.

cheers

tirkitneth · Sat Oct 10, 2015 9:36 pm

First, thank you for your answer

short answer:
no security implication, just speedup cause fastracked sessions will avoid firewall processing, so they won't bump though the rules till they are accepted or rejected.

longer version:
fastrack works with connection table entries. so if you have a new session, it will go through the "slow" path,
then - say after the 3way tcp handshake - the session is established, so your fw rule will put it on the fastrack path.

OK, I was afraid that fasttrack would "bypass the firewall" and accept anything and everything.

About the remaining of your message: I only showed the first few rules because I thought they were the only ones to matter. After those, I have a few rules to allow/deny some connections to go through, and a drop at the end

efaden · Sat Oct 10, 2015 10:12 pm

First, thank you for your answer

short answer:
no security implication, just speedup cause fastracked sessions will avoid firewall processing, so they won't bump though the rules till they are accepted or rejected.

longer version:
fastrack works with connection table entries. so if you have a new session, it will go through the "slow" path,
then - say after the 3way tcp handshake - the session is established, so your fw rule will put it on the fastrack path.
OK, I was afraid that fasttrack would "bypass the firewall" and accept anything and everything.

About the remaining of your message: I only showed the first few rules because I thought they were the only ones to matter. After those, I have a few rules to allow/deny some connections to go through, and a drop at the end

I mean you could fast-track EVERYTHING, but that wouldn't really be a great it. Mostly fast-track just lets the stuff you have already accepted (related, established) pass through faster after the first time.

lapsio · Sun Apr 10, 2016 2:50 pm

I'm also a bit worried about this whole bypassing thing. I mean okay - lets say I have super fast links between some segments of internal network so I don't need QoS there at all, I need QoS only on internet traffic. There's NAT from outside but inside ofc not and I have plenty of networks with various level of trust including publicly available network. Would it be secure to fasttrack all connections with src-address and dst-address of local subnet? Like 192.168.0.0/16 to catch all local networks.

I'm using following processing of packets:
firewall filter (without connection/packet mark rules)
NAT (rather for internet)
Mangle + Queue tree (only for internet)
VLAN interfaces, bridges, VWLANs
packet packing between routers

None of this is listed as broken by fasttrack tho (except queues but they can work only for non fasttracked)

add chain=forward comment=forward connection-state=established,related
add action=drop chain=forward connection-state=invalid
add action=drop chain=forward dst-address=192.168.0.0/24 log=yes log-prefix=>_>
add action=drop chain=forward in-interface=ether1-gateway log=yes log-prefix=>_> src-address=192.168.0.0/16
add action=drop chain=forward in-interface=ether9-trunk-local log=yes log-prefix=X_X
add action=drop chain=forward in-interface=br-main log=yes log-prefix=X_X src-address=!192.168.1.0/24
add action=drop chain=forward in-interface=br-extern log=yes log-prefix=X_X src-address=!192.168.2.0/24
add action=drop chain=forward in-interface=br-public log=yes log-prefix=X_X src-address=!192.168.3.0/24
add action=drop chain=forward in-interface=br-alt log=yes log-prefix=X_X src-address=!192.168.4.0/24
add action=drop chain=forward dst-address=192.168.0.0/16 log=yes log-prefix=X_X src-address=192.168.3.0/24
add chain=forward src-address=192.168.0.0/16
add chain=forward connection-nat-state=dstnat in-interface=ether1-gateway
add action=drop chain=forward log=yes log-prefix=O_O

Could adding fasttrack:

add chain=forward src-address=192.168.0.0/16 dst-address=192.168.0.0/16 connection-state=established,related action=fasttrack

as first forward chain rule break anything, or it wouldn't make difference in terms of functionality? I'm especially concerned on 192.168.3.0 network - they wouldn't get fasttracked at all because I'm dropping connections from .3.0/24 to .0.0/16 right? And fasttrack wouldn't break it? And queues would still work for all internet traffic?

FastTrack security implications

FastTrack security implications

Re: FastTrack security implications

Re: FastTrack security implications

Re: FastTrack security implications

Re: FastTrack security implications

Who is online