-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Paul Julian Sent: Friday, 31 May 2019 6:18 PM To: 'MikroTik Australia Public List' <public@talk.mikrotik.com.au> Subject: Re: [MT-AU Public] Filtering by part of URL
Interesting one.
The Layer 7 stuff is only for the data within the packets, it's not for
such, you will need to find something unique in the data stream for each of those connections and then try and match that. From my experience find some really simple data to match within the
any work with layer 7 for me has always been hit and miss for me, sometimes it seems that the data needs to be in regex, sometimes not, it's strange.
Regards Paul
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Malcolm Faed Sent: Friday, 31 May 2019 5:57 PM To: MikroTik Australia Public List Subject: [MT-AU Public] Filtering by part of URL
Hi all,
I would like to filter access by a portion of the URL.
I have a HLS streaming server where the URLs are in the form:
http://123.123.123.123:4545/hls/1/1.m3u8 http://123.123.123.123:4545/hls/2/2.m3u8 http://123.123.123.123:4545/hls/3/3.m3u8 (These can not be changed)
The server is behind DST-NAT
I need to allow / block access from different IP public addresses based on
http request header always includes the resource path requested, and almost always also the server hostname in plain text. So long as the request is not encrypted, it is possible to do request filtering using L7 inspection just on the first packet of the TCP request, and then add connection mark to deal with the entire request and response streams. So technique described by Malcolm is valid - EXCEPT that since the packet final destination is not the router itself, then forward chain is the correct filter chain to use. Input chain is only where the packet final destination is the router itself. Also, since L7 content inspection is quite CPU intensive, I would encourage to also limit the filter rule to first packet in the connection request only, i.e: add action=drop chain=forward comment="Drop all traffic to CCTV except allowed" \ dst-address='my public ip' dst-port=4545 layer7-protocol=CCTV log=yes \ protocol=tcp src-address=!203.123.168.150 \ tcp-state=new It may not make much difference in this case where http request header is likely to fit inside one packet anyway, but if there is ever a need for the remote client to upload data to the server, then limit to the tcp-new packet will prevent inspection of every subsequent packet in the data stream. Cheers! the URL as packet, the
" hls/1/1.m3u8" part of the URL.
Here has been my naive approach that did not work.
I tried creating a layer 7 filter add comment="Match HLS stream for CCTV" name=CCTV regexp="\/hls\/1\/1.m3u8"
And using this in the filter add action=drop chain=input comment="Drop all traffic to CCTV except allowed" dst-address='my public ip' dst-port=4545 layer7-protocol=CCTV log=yes protocol=tcp src-address=!203.123.168.150
I also tried the forward chain based on the wiki, but since this is behind a DST NAT, I think input is correct.
Any advise appreciated.
TIA, Mal
*Malcolm Faed*Network Broadcast Engineer malcolm@avcomm.com.au
Av-Comm
Office: +61 2 9939 4377 Mobile+61 424 957 053
Unit 24 / 9 Powells Road, Brookvale, NSW 2100, Australia. avcomm.com.au
[image: Twitter] <https://twitter.com/AvCommSatellite>[image: Google Plus] <https://plus.google.com/+AvcommAustralia/>[image: Youtube] <https://www.youtube.com/channel/UCO8ZtcnwoTH7e54LAndE-yw>[image: Linkedin] <https://www.linkedin.com/company-beta/6583589/>
This e-mail message may contain confidential or legally privileged information and is intended only for the use of the intended recipient(s). Any unauthorised disclosure, dissemination, distribution, copying or the taking of any action in reliance on the information herein is prohibited. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, or contain viruses. Anyone who communicates with us by e-mail is deemed to have accepted these risks. Av-Comm is not responsible for errors or omissions in this message and denies any responsibility for any damage arising from the use of e-mail. Any opinion and other statement contained in this message and any attachment are solely those of the author and do not necessarily represent those of the company. _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au