unfortunately I have no possibilities to block files (exe, iso, dmg etc.) download. I was told here https://forum.mikrotik.com/viewtopic.php?f=21&t=150767&start=50#p744362 that I shouldn’t use L7 Protocol for this. Do you have a solution that works?
Now that everyone uses https, this is not possible anymore.
Yes, I am aware of that, but how do the others do it, at train stations, airports … ? a few weeks ago I set up a WLAN connection at the airport and I couldn’t download any files. So there has to be a solution.
Strangely enough, URL Block also works for HTTPS pages.
This works here, for example:
^.+(youtube.com|facebook.com).*$
Domain block (not URL block) works because the domain is visible (unencrypted) during the TLS session setup between the browser and the server.
After that, you cannot see anything due to TLS (so you cannot block specific URLs or specific extensions to a URL).
This will also stop working after TLS 1.3 becomes the standard, as it will no longer contain the unencrypted domain in the request.
I doubt they were able to block files download over an HTTPS connection. Only whole domains and/or IPs.
With unencrypted HTTP is very easy to block anything you want using a transparent proxy.
@Link100, You can block HTTPS with devices like Sonicwall, Proxy’s, etc, maybe that is what they used at the airport
Sonicwall has a feature that can inspect HTTPS packets, but it is an “extra” feature that does not come with the standard license of the product
But that only works after you have destroyed the security of your device (by adding a new root certificate that cannot be trusted).
So that only works inside companies where they can decide to do this on their own workstations.
It is not a solution that could be used on a public WiFi.
@pe1chl, also true
Which I don’t understand. HTTPS pages can be blocked with the above regexp, but HTTPS downloads cannot.
squid/proxy filtering with the L7 Protocol principle?
If you have https://www.someserver.tld/some/file.exe, the part visible to L7 is only www.someserver.tld.
The filename and filetype of the download URL is not visible to the L7 matcher!
squid/proxy filtering with the L7 Protocol principle?
Same problem. Squid sees only “CONNECT www.sitename.tld:443” and not the reason for that connection.
Okay, thank you guys for the answer.
Too bad there’s no possibility for MikroTik.
This is not a problem of MikroTik!
What you want is simply not possible anymore.
You can blame Google and others for migrating everything to https to prevent that people like you look in the traffic.
You misunderstood me.
As I have already mentioned above, I have set up on airport WLAN connection and I could do everything. Only *.exe, *.mp4 …files, could not be downloaded. This means that there is the possibility with other router network technology, but it is a pity that the same is not possible with MikroTik.
I’m gonna test this out:
https://wiki.mikrotik.com/wiki/Block_Download_Based_Download_Sizes
EDIT
Works! 
Download will be slowed down and then stopped!
Also a possibility. Better than nothing!
I don’t believe that. Likely only via http and not via https. There is no way a public WLAN system, no matter what manufacturer, can see what you download over https.
And if they would have a rogue root certificate, you could just setup a VPN to circumvent it.
Limit the amount of bytes per connection is a possibility, but it is not what you requested.
And please understand that it will have false positives. Someone not downloading a file but working in a google docs document will be affected just as well.
You can believe that. I couldn’t download any files. Because it seems to be the same. It starts Download, but it is stopped when downloading.
And please understand that it will have false positives. Someone not downloading a file but working in a google docs document will be affected just as well.
Exactly, therefore the next question 
On the page there is a hint, without an example of how to do it:
…
“Also You can start this strategy base on File Extensions , Such as ( mp3 , avi , flv , zip , … )”
Now the question is, how do you do it?
And another question:
…
add action=add-src-to-address-list address-list=Src address-list-timeout=1h
chain=forward connection-bytes=1970000-0 disabled=no protocol=tcp
src-address=192.168.0.0/24
…
The input in the web interface is incorrect. What is wrong?
It had much better change to work in 2011, when it was written. There was more of plaintext http and less encrypted https back then.
Edit: And about connection-bytes option, congratulations, it looks like you found a bug in WebFig. It works correctly in WinBox and CLI.
With blocking of connection once a volume is reached one can block that connection, but the user can just resume the download with a new connection.
So the net effect is slight delay.
A more effective approach would be to slow down the connection once a volume has been reached: based on volume, assign connection / packet marks to assign connection to a different queue with lower priority / lower bandwidth.
It was possible only for transfers occurring in plaintext. I.e. http, ftp etc.
Today these are seldomly used anymore.
So what is written there is no longer possible today. It should be updated in the wiki.
@Sob, my brain is tired, been fighting with L2 fiber provider all day for poor service, but just so I can follow, I can’t see what is wrong in the webfig, it shows 1970k instead of 1970000, which seems to be correct according to my current tired brain?