I have L7 filter rule that blocks Youtube. It's hard to block it via IP filter because Google uses multiple addresses and this affects the use of other sites, like Gmail or Google Seach. The problem is that my filter rule is REGEXP. I apply it for all IPs that are not part of the Allowed users IP-s.
This works just fine. But when I try to make exception for Youtube only, without allowing users to open other blocked sites - I can get it to work.
My rule for allowed users is
!Allowed users
L7 filter rule
I tried putting rule before it,
IP address
!L7 filter rule
I tried it also this way
!IP address
L7 filter rule.
Nothing seems to be working and I cant add L7 filter rule exception for a certain IP that is not a part of Allowed Users IP-s.
I can use the same as forwarding TCP from the SourceIP to the Destination IP of the site, but because Google uses multiple servers and IP-s this wont work.
I can use static DNS entries, but because I also run a DC controller, when I do something like this and DC caches that certain dns record leads to 127.0.0.0,
this will interfere with the connectivity of any computers, even the ones that are allowed to open it. If I make an exception for the DC, on the other hand
- this bypasses the DNS static entries completely.
I cant block youtube using a proxy, because it will screw up any HTTPS sites and will give Certificate warnings.
My Mikrotik is from the newer ones, pretty solid hardware, so I don't think that some L7 rules will have adverse effect on it's performance.
I also heard that I can block sites using TLS host, but because of already established session it will not take effect immediately.
So, I decided that it will be L7 rule. Good, but I cant add exception for specific private IP-s.
Also, I have filter list in Lists. Sometimes the Mikrotik has hard time updating the IP-s. What script do I need for it to update the list several times a day?
Because for example I block access to certain site, but after some time(if it uses multiple IP-s) they are able to open it.
The same is when I allow access by using a rule to forward the traffic by it bypassing the rule. If the site changes IP, they are unable to open it,
until I open the rule, enter the DNS name of the site again, it gets the new IP and then everything is fine.
Re: L7 Filter rule exception.
I am sure you understand what you mean by the above, but I don't.My rule for allowed users is
!Allowed users
L7 filter rule
I tried putting rule before it,
IP address
!L7 filter rule
I tried it also this way
!IP address
L7 filter rule.
Can you show the above three variants in the form of firewall filter rules exported from the Mikrotik?
Re: L7 Filter rule exception.
Okay.I am trying to get specific IP not part of the allowedlist to be able to open youtube.I am sure you understand what you mean by the above, but I don't.
Can you show the above three variants in the form of firewall filter rules exported from the Mikrotik?
I can make a second list with every IP in allowedlist plus every IP that needs to open only Youtube
and use this instead of allowedlist, but this is tedious task.
I tried to make a separate list with IP-s that need to open Youtube, but not other sites
Code: Select all
/ip firewall layer7-protocol
add name="DisableYoutube" regexp="^.+(youtube.com).*\$"
/ip firewall filter
add action=accept chain=forward comment="Youtube Access ]" disabled=no \
dst-port=80,443 layer7-protocol="DisableYoutube" protocol=tcp \
src-address-list=onlyyoutube
add action=drop chain=forward comment=DisableYoutube disabled=\
no dst-port=80,443 layer7-protocol="DisableYoutube" protocol=tcp \
src-address-list=!allowedlistRe: L7 Filter rule exception.
So are you saying you want to extend the single action=drop rule currently matching on src-address-list=!allowedlist layer7-protocol="DisableYoutube" with yet another match condition, which would prevent it from dropping packets sent from a "youtubeonly" address although such packets would match the other conditions of that rule?
If so, such an additional condition may be added for a single address, prefix, or range, e.g. src-address=!192.168.1.15-192.168.15.39. But you cannot add more than one src-address-list condition to a single rule. Should youtubeonly be an address-list, you have to use two rules in proper order.
If so, such an additional condition may be added for a single address, prefix, or range, e.g. src-address=!192.168.1.15-192.168.15.39. But you cannot add more than one src-address-list condition to a single rule. Should youtubeonly be an address-list, you have to use two rules in proper order.
Re: L7 Filter rule exception.
What I want is to have a rule, that uses the general allowedlist. So far, everything works, except L7 exceptions.So are you saying you want to extend the single action=drop rule currently matching on src-address-list=!allowedlist layer7-protocol="DisableYoutube" with yet another match condition, which would prevent it from dropping packets sent from a "youtubeonly" address although such packets would match the other conditions of that rule?
If the IP is not in this list, everything in blocked sites list will be blocked and Youtube will be blocked via L7 rule.
If the IP is not in this list, but must be able to access youtube, then to add exception for the L7 rule.
Everything else continues to be blocked, except youtube.
I tried to add a rule, where I use src-address=192.168.10.5. Even then it is not working.
What I need is
!192.168.10.5 or !allowedlist = drop
If 192.168.10.5 but !allowelist = accept.
This is what I want to create. If it is not specific exception, neither it is in global allowedlist, then block it.
If it is exception for youtube - allow it, but block the rest of the sites in my blocklist.
If it is in the allowedlist - let everything pass.
I have separate rules that state
src-address=!allowed list
dst-address=blocklist
action=drop
Yes. I have rule with higher priority that statesShould youtubeonly be an address-list, you have to use two rules in proper order.
NOT in youtube only, L7 filter
Then
NOT in allowedliist , L7 filter
NOT in allowedlist, Blocklist
The problem is that the rule with higher priority that allows is not working. The Mikrotik blocks it anyway, if the second rule is active.
I want specific IP-s not in allowedlist, but part of youtubeonly to bypass the L7 filter rule.
The simplest solution is to have 2 lists - for every other site and for youtube only.
But this is tedious task.
Re: L7 Filter rule exception.
I'd have to see the complete filter rules to understand why it is happening. If two rules both match on exactly the same layer7-protocol expression, and only one of them matches on the other conditions, the completely matching one is executed. If a packet matches to all conditions of both such rules, the order matters, so the former rule shadows the latter one. layer7-protocol matching is tricky in the sense that it matches on the whole connection, not just on the single packet where the pattern appears, but if both rules refer to the same layer7-protocol row, this should cause no difference.
Re: L7 Filter rule exception.
These are the rules.I'd have to see the complete filter rules to understand why it is happening..
Code: Select all
add action=drop chain=forward comment=SiteRestrictions dst-address-list=blocklist src-address-list=!allowedlist Code: Select all
/ip firewall layer7-protocol
add name="DisableYoutube" regexp="^.+(youtube.com).*\$"
add action=drop chain=forward comment=DisableYoutube disabled=\no dst-port=80,443 layer7-protocol="DisableYoutube"
protocol=tcp \ src-address-list=!allowedlistI add exceptions to the SiteRestrictions, allowing an IP to bypass the restriction completely for IP-s that should not be restricted using this.
Code: Select all
add action=accept chain=forward dst-address=mikrotik.com dst-port=80,443 \protocol=tcp src-address=192.168.10.10I tried to do it this way
Code: Select all
add action=accept chain=forward comment="Youtube Access ]" disabled=no \
dst-port=80,443 layer7-protocol="DisableYoutube" protocol=tcp \ src-address-list=!onlyyoutubeI tried to use IP instead of address list.
The firewall should match the packet using the first rule YoutubeAccess. But seems like it continues to use the second rule, where if it is not in allowedlist, it is blocked.
Seems like IF NOT in youtube only, but not in allowedlist=blocked.
I want to make it IF in youtube only or if in allowedlist=allow for the L7 rule.
Otherwise, I will need to use 2 addresslists, where 1 is specifically for youtube and includes IPs that must access youtube only and IP-s that are allowed to access everything. And second list for IP-s that need to access everything and not IP-s that must access youtube only. This means that I must duplicate every entry from allowedlist in youtube only, so they can access everything plus youtube.
I want to avoid this.
Because Google and youtube use multiple IP-s, I cant use
Code: Select all
add action=accept chain=forward dst-address=youtube.com dst-port=80,443 \protocol=tcp src-address=192.168.10.10If there was an option to block domain/DNS names, I would never had such a problems. But there isn't such an option and static DNS entries pointing to Localhost are not an option because of the DomainController. What I need in a perfect world would be for DNS names to be resolved correctly, but connections to site IP-s to be refused. So that my DomainController will not cache invalid DNS entries, which will make sites inaccessible for all domain computers, regardless of whether they are allowed or not.
Option to point out 2 address lists in a Firewall rule will be great. But there is no such option.
Re: L7 Filter rule exception.
Things would be much simpler if you posted the complete /ip firewall filter export, but I think I can see the flaw.
With the default firewall rules implementing a stateful firewall, where the one of the first ones in chain=forward is action=accept connection-state=established,related,untracked, the action=drop rule dropping packets matching the layer7-protocol would never be reached by the mid-connection packet carrying the interesting text pattern (the pattern is not in the initial packet of a session but in the third one in client->server direction at the earliest). So this "drop youtube" rule must be before the "accept established" one, if the latter exists in your firewall at all.
But if it is the case, the rule
add action=accept chain=forward dst-port=80,443 layer7-protocol="DisableYoutube" protocol=tcp src-address-list=!onlyyoutube
only handles the packets in the client->server direction, whereas the subsequent "drop youtube" one acts on packets in both directions - the layer7-protocol matching stores the complete contents of the first few packets of each connection and searches for the pattern in all of them, regardless their direction. So to accept also the server->client packets before they reach the "drop youtube" rule, you need to add one more rule before the "drop youtube" one:
add action=accept chain=forward src-port=80,443 layer7-protocol="DisableYoutube" protocol=tcp dst-address-list=!onlyyoutube
With the default firewall rules implementing a stateful firewall, where the one of the first ones in chain=forward is action=accept connection-state=established,related,untracked, the action=drop rule dropping packets matching the layer7-protocol would never be reached by the mid-connection packet carrying the interesting text pattern (the pattern is not in the initial packet of a session but in the third one in client->server direction at the earliest). So this "drop youtube" rule must be before the "accept established" one, if the latter exists in your firewall at all.
But if it is the case, the rule
add action=accept chain=forward dst-port=80,443 layer7-protocol="DisableYoutube" protocol=tcp src-address-list=!onlyyoutube
only handles the packets in the client->server direction, whereas the subsequent "drop youtube" one acts on packets in both directions - the layer7-protocol matching stores the complete contents of the first few packets of each connection and searches for the pattern in all of them, regardless their direction. So to accept also the server->client packets before they reach the "drop youtube" rule, you need to add one more rule before the "drop youtube" one:
add action=accept chain=forward src-port=80,443 layer7-protocol="DisableYoutube" protocol=tcp dst-address-list=!onlyyoutube
Re: L7 Filter rule exception.
So, if I understand correctlyonly handles the packets in the client->server direction, whereas the subsequent "drop youtube" one acts on packets in both directions - the layer7-protocol matching stores the complete contents of the first few packets of each connection and searches for the pattern in all of them, regardless their direction. So to accept also the server->client packets before they reach the "drop youtube" rule, you need to add one more rule before the "drop youtube" one:
add action=accept chain=forward src-port=80,443 layer7-protocol="DisableYoutube" protocol=tcp dst-address-list=!onlyyoutube
Code: Select all
add action=drop chain=forward comment=DisableYoutube disabled=\no dst-port=80,443 layer7-protocol="DisableYoutube"
protocol=tcp \ src-address-list=!allowedlistI thought that using L7-Protocol REGEXP in BlockYoutube will look in only the outbound packets.
Because with the usual rules, I have to have 2 sets, one which block outbound and one which block inbound. So, I allow the client to send packets to Youtube using the first rule, but they never return because they match the second rule, which blocks it for anybody not in allowedlist!?
Re: L7 Filter rule exception.
This particular one doesn't - there's also the dst-port=80,443 which restricts the match to the client->server packets.So, if I understand correctlyThis handles the traffic in both directions?Code: Select alladd action=drop chain=forward comment=DisableYoutube disabled=\no dst-port=80,443 layer7-protocol="DisableYoutube" protocol=tcp \ src-address-list=!allowedlist
But I'm tired asking you to post the complete firewall filter.
Re: L7 Filter rule exception.
It would be better when you tried to find some way to live without the "block this or that site"...
It will be a short pleasure anyway. Soon, all this "matching using L7 header" (which is not clever anyway since we already have the option to match on TLS host!) will be completely gone as the parties involved are working on encrypting that piece of information as well.
That will make it practically impossible to implement selective blocks of certain websites.
(which are not effective anyway because your users can simply start a VPN and go around them)
It will be a short pleasure anyway. Soon, all this "matching using L7 header" (which is not clever anyway since we already have the option to match on TLS host!) will be completely gone as the parties involved are working on encrypting that piece of information as well.
That will make it practically impossible to implement selective blocks of certain websites.
(which are not effective anyway because your users can simply start a VPN and go around them)
Re: L7 Filter rule exception.
I was reluctant to post a complete an export of the Firewall rules, because of the fact that I had much to edit.This particular one doesn't - there's also the dst-port=80,443 which restricts the match to the client->server packets.
But I'm tired asking you to post the complete firewall filter.
We can both agree that there is much confidential information inside the router configuration.
I intentionally removed some websites from the filter, as well as some IP-s from the allowedlist.
Otherwise the quote will be rather long. I also tried to replace the youtubeonly list with specific IP. Still not working properly.
Code: Select all
# xx/xx/xxx xx:xx:xx by RouterOS 6.46.1
# software id = xxxxxxx
#
# model = RB3011UiAS
# serial number = xxxxxxx
/ip firewall layer7-protocol
add name="YoutubeBlock" regexp="^.+(youtube.com).*\$"
/ip firewall address-list
add address=yahoo.com list=blocklist
add address=facebook.com list=blocklist
add address=wetransfer.com list=blocklist
add address=192.168.10.10 list=allowedlist
add address=192.168.10.11 list=allowedlist
add address=192.168.10.12 list=allowedlist
add address=192.168.10.13 list=allowedlist
add address=192.168.10.14 list=youtubeonly
add address=192.168.10.15 list=youtubeonly
/ip firewall filter
add action=drop chain=input comment="WanDNS" dst-port=53 in-interface-list=WAN protocol=udp
add action=accept chain=forward comment="Youtube Access rule" dst-port=80,443 layer7-protocol="YoutubeBlock" protocol=tcp src-address-list=youtubeonly
add action=drop chain=forward comment="BlockYoutubeRule" dst-port=80,443 layer7-protocol="YoutubeBlock" protocol=tcp src-address-list=!allowedlist
add action=drop chain=forward comment="GeneralRestrictions" dst-address-list=blocklist src-address-list=!allowedlist
add action=drop chain=forward comment="drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
add action=drop chain=input comment="drop invalid" connection-state=invalid
add action=accept chain=input comment="accept established,related,untracked" connection-state=established,related,untracked
add action=accept chain=forward comment="accept established,related, untracked" connection-state=established,related,untracked
add action=accept chain=forward comment="accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment=" accept out ipsec policy" ipsec-policy=out,ipsec
add action=drop chain=forward comment="drop invalid" connection-state=invalid
add action=drop chain=input comment="defconf: drop all not coming from LAN" disabled=yes in-interface-list=!LAN
add action=drop chain=input comment="WAN protection" dst-port=8291 in-interface-list=WAN protocol=tcp
add action=drop chain=input dst-port=8291 protocol=udp
add action=drop chain=input dst-port=128 protocol=tcp
add action=drop chain=input dst-port=128 protocol=udp
add action=drop chain=input dst-port=129 protocol=tcp
add action=drop chain=input dst-port=129 protocol=udp
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
TLS host blocking wont work if the connection to the site is already established. And I can't find other way.It would be better when you tried to find some way to live without the "block this or that site"...
It will be a short pleasure anyway. Soon, all this "matching using L7 header" (which is not clever anyway since we already have the option to match on TLS host!)
will be completely gone as the parties involved are working on encrypting that piece of information as well.
That will make it practically impossible to implement selective blocks of certain websites.
(which are not effective anyway because your users can simply start a VPN and go around them)
I am trying to block only the most time wasting sites. Reading news is fine, but not spending the whole day in facebook.
Re: L7 Filter rule exception.
Of course you use TLS blocking to prevent the connection from getting established enough to get any data. It will get established in TCP but not in TLS.TLS host blocking wont work if the connection to the site is already established. And I can't find other way.
I think that is best accomplished by letting the TLS blocking set a connection mark on the connection, and then use the connection mark to drop all traffic.
You need to do that in some other way. Like with agreements, rules and enforcement thereof.I am trying to block only the most time wasting sites. Reading news is fine, but not spending the whole day in facebook.
("using the company network to follow your facebook page is not allowed, and when we catch you doing it the punishment is: [fill in what is legally allowed]")
That will be more effective than technical measures, which in this particular case also have an unfortunate side-effect: by blocking people to use facebook, you also block them from logging in on sites that use facebook as authentication, even when those sites are valuable for company use.
Re: L7 Filter rule exception.
I highly doubt that leaving a door widely open and putting a sign "You may be fined" is better than just locking the door.You need to do that in some other way. Like with agreements, rules and enforcement thereof.
("using the company network to follow your facebook page is not allowed, and when we catch you doing it the punishment is: [fill in what is legally allowed]")
Let's keep the posting to something relevant to RouterOS, I don't want to fall into debates concerning ethics and etc.
The reason why TLS host blocking may not work is QUIC.
If facebok is not allowed, then they also are not supposed to log in somewhere with facebook. And I have no intention to track all network traffic.
Not to mention that this will lead to increased load of the router. Big companies like Facebook or Google try to do everything they can to make it difficult for the admins to block them. We need simpler and more powerful website blocking implemented in Mikrotiks. During POST, hostname is still not encrypted. I think that there must be a way to deny a connection to specific URI.
Re: L7 Filter rule exception.
First, I admit I don't understand why your firewall rules above do not do what you expect them to do.
Regarding the ways how to filter connections by url - there is no difference between GET and POST for the point of view of access to the url. Either it is a plaintext HTTP, so you can see the complete url, or it is HTTPS, i.e. a TLS-encapsulated HTTP, and then you can only see the hostname in plaintext as the SNI field of Client Hello (which is what the tls-host match of Mikrotik firewall is looking at), and this is only true up to TLS1.2, as TLS1.3 implements Encrypted Client Hello mostly to prevent exactly that - traffic matching on SNI.
So what enterprise security appliances do is nothing less than a man-in-the-middle attack, where they impersonate the TLS client in communication with the server, and impersonate the sever in the communication with the client, using a certificate signed by their own root CA (which must be trusted by the client so that it would not display a security warning to the user), so that they could get to the plaintext payload of the TLS. This is something you are only allowed to do at network level in some countries or states and only under some circumstances (enterprise network, employees informed). It is also the only way to detect malware in the encrypted contents, so many contemporary anti-viruses running directly on the PC are doing the same.
Regarding the ways how to filter connections by url - there is no difference between GET and POST for the point of view of access to the url. Either it is a plaintext HTTP, so you can see the complete url, or it is HTTPS, i.e. a TLS-encapsulated HTTP, and then you can only see the hostname in plaintext as the SNI field of Client Hello (which is what the tls-host match of Mikrotik firewall is looking at), and this is only true up to TLS1.2, as TLS1.3 implements Encrypted Client Hello mostly to prevent exactly that - traffic matching on SNI.
So what enterprise security appliances do is nothing less than a man-in-the-middle attack, where they impersonate the TLS client in communication with the server, and impersonate the sever in the communication with the client, using a certificate signed by their own root CA (which must be trusted by the client so that it would not display a security warning to the user), so that they could get to the plaintext payload of the TLS. This is something you are only allowed to do at network level in some countries or states and only under some circumstances (enterprise network, employees informed). It is also the only way to detect malware in the encrypted contents, so many contemporary anti-viruses running directly on the PC are doing the same.
Re: L7 Filter rule exception.
There IS no permanent, always-working, way to block websites. It will always fail after some time. And the measures you have implemented may have or develop side-effects that you notice only after some time.
QUIC is one thing, but encryption of the plaintext hostname in TLS setup is already running on some websites and will soon be standard in Firefox.
It is a lost battle. That has nothing to do with MikroTik.
QUIC is one thing, but encryption of the plaintext hostname in TLS setup is already running on some websites and will soon be standard in Firefox.
It is a lost battle. That has nothing to do with MikroTik.
Re: L7 Filter rule exception.
In fact, there is a way. Static DNS entries and blocking external DNS. So, requests go via the Mikrotik and are resolved externally if there isn't static dns entry which can be resolved by the Mikrotik. Therefore, if you change your DNS servers in your network adapter settings, you still will be unable to reach the sites, because of static DNS entries being pointed at 127.0.0.1There IS no permanent, always-working, way to block websites. It will always fail after some time. And the measures you have implemented may have or develop side-effects that you notice only after some time.QUIC is one thing, but encryption of the plaintext hostname in TLS setup is already running on some websites and will soon be standard in Firefox.
It is a lost battle. That has nothing to do with MikroTik.
And then you can add exceptions for certain IP-s, allowing them to bypass this and request directly some DNS server, like Googles 8.8.8.8 or your IP's DNS server.
Combine Static DNS entries with restrictive Active Directory policies, which deny software installation and you will be mostly fine.
Unless you have a list with the IP-s of certain sites and access the sites that way, which won't work most of the time anyway, because most use Shared Hostings and one IP is used for more than 1 site. So, multiple DNS names correspond to 1 IP. Or the other way - multiple IP-s per one DNS name, which most big players use for load balancing. SNI is used for TLS, because of the shared hostings used, so the server can offer the certificate for the requested site.
DNS over HTTPS and Encrypted SNI will make L7 sniffing impossible. As well as TLS host matching. The result will be me will be allocating those functions to WindowsServer. If you tie the computers in your network with your own local DNS, you can do whatever pleases you.
I have intentionally got one of the more powerful mikrotiks, because I don't want to complicate things and prefer to allocate these functions to the router/firewall.
It is not like you cant just push a HOSTS file update for all AD computers and ban any non AD computer from your network. Or just run a local DNS server.
Computers first look in their HOSTS/local DNS cache before addressing any DNS server. If cache has expired or no match in HOSTS is found, then the computer contacts DNS servers.
As a user, I admire this. As a person who must get some work done - I don't. And your suggestion to play mouse and cat, because if you cant sniff the traffic, you literary have to install cameras pointed at the users monitors, is not something I intend to do.
For now L7 matching is the laziest option and I don't understand what causes the exceptions not work. About the rest - I already knew this.First, I admit I don't understand why your firewall rules above do not do what you expect them to do.
I thought that this is caused by Firewall rule problem, but if nothing is wrong, this may in fact be RouterOS bug?
---
I started to use Mikrotik as firewall, because Open DNS produced the dreaded "connection not private/secure" warnings. And I really didn't want to install Certificate on every single computer.
Re: L7 Filter rule exception.
That assumes that it is YOU who are the admin of those computers and can control everything, and not the persons operating the computer.In fact, there is a way. Static DNS entries and blocking external DNS. So, requests go via the Mikrotik and are resolved externally if there isn't static dns entry which can be resolved by the Mikrotik. Therefore, if you change your DNS servers in your network adapter settings, you still will be unable to reach the sites, because of static DNS entries being pointed at 127.0.0.1There IS no permanent, always-working, way to block websites. It will always fail after some time. And the measures you have implemented may have or develop side-effects that you notice only after some time.QUIC is one thing, but encryption of the plaintext hostname in TLS setup is already running on some websites and will soon be standard in Firefox.
It is a lost battle. That has nothing to do with MikroTik.
And also it assumes that browser manufacturers are not implementing DNS over HTTPS in their updates, which they are doing.
So after a while your user's DNS requests will not be processed by your router anymore but go directly to some unknown server which does not have your static entries.
For now you can still add some blacklist for "known DNS over HTTPS servers" but what if these become much more widespread, or this function is being combined
with a service you cannot block? (e.g. running on the same servers as www.google.com?)
Re: L7 Filter rule exception.
If I was boss, you were my non-behaving employees, and the social approach ("don't try to make me mad, or else!") wouldn't work, I'd probably cut off direct internet access. The only way to get anywhere would be through e.g. SOCKS proxy. That should be pretty reliable with right ACLs. Connections to numeric addresses? No way, blocked, only requests with hostnames would be allowed, you wouldn't hide the true destination from me. Blocking connections to selected domains and subdomains? No problem. Tunnelling traffic through some other server? Yes, for a while, until I'd look at statistics (everything would be logged of course) and block it. I'd be really evil. :)
Technically it could work relatively well, better than other solutions. Web browsers support it, there's no problem there. Many other programs too. Unfortunatelly, it still doesn't solve the main problem. If you don't want to work, you'll always find a way. Browse internet on your phone, play tic tac toe with yourself, stare at ceiling, ...
Technically it could work relatively well, better than other solutions. Web browsers support it, there's no problem there. Many other programs too. Unfortunatelly, it still doesn't solve the main problem. If you don't want to work, you'll always find a way. Browse internet on your phone, play tic tac toe with yourself, stare at ceiling, ...
Re: L7 Filter rule exception.
That is so true... when the boss wants to keep the employees at work by blocking facebook and youtube, there must be something else going wrong there.Unfortunatelly, it still doesn't solve the main problem. If you don't want to work, you'll always find a way. Browse internet on your phone, play tic tac toe with yourself, stare at ceiling, ...
Either the employees do not really want to work there, or the boss is assuming something that is not really going on.
I can sympathize with the 1000-times overbooked wireless internet providers that have their uplink from 4G or satellite and want to limit the bandwidth "wasted" on high-bandwidth services like video platforms, but even then only when their customers know about that and agreed to it when getting their cheap internet connection.
Imposing such limitations on employees of a company "because otherwise they will not work" does not seem like the right thing to do.
Re: L7 Filter rule exception.
I said that this topic is not for political or ethical debates. I have dedicated and guaranteed, but limited bandwidth internet connectivity. And this is still network, which I manage. Youtube and some other services are bandwidth intensive. Opening other sites is fine. And I still decide how I will proceed and manage my network. Facebook is not okay at work, anyway. I will not explain any further, nor I like to participate in ethical debates. My primary goal is everything to work flawlessly, not people to be able to chat or watch youtube videos. If watching youtube hogs my connection to the world, then I will just block youtube. There is a reason why I want to block only websites, that are bandwidth intensive. And only youtube, but not gmail.That is so true... when the boss wants to keep the employees at work by blocking facebook and youtube, there must be something else going wrong there.
Either the employees do not really want to work there, or the boss is assuming something that is not really going on.
...Imposing such limitations on employees of a company "because otherwise they will not work" does not seem like the right thing to do.
Re: L7 Filter rule exception.
If you're able to install a CA certificate on all computers in your network, then you can use something like the Fortigate firewall. Because you've installed the CA certificate on all computers, it can re-sign all encrypted connections. This gives it the ability to transparently inspect the content of an HTTPS connection. Then you can filter based on the Host header in the HTTP headers, or by attachment types and so on.
Re: L7 Filter rule exception.
Yes, I probably can. But meanwhile, I prefer different solutions. A complete overhaul of the network is in progress. Also, Fortigate wirewall or Sophos firewall is significantly more expensive than Mikrotik. I will say 10-15x. It is prohibitively expensive at the moment. And I am one man army. Some day I may be able to do what you say. But not right now.If you're able to install a CA certificate on all computers in your network, then you can use something like the Fortigate firewall. Because you've installed the CA certificate on all computers, it can re-sign all encrypted connections. This gives it the ability to transparently inspect the content of an HTTPS connection. Then you can filter based on the Host header in the HTTP headers, or by attachment types and so on.