Page 1 of 1

L7 Filter rule exception.

Posted: Sat Jan 09, 2021 3:51 pm
by techclerk
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.

Posted: Sat Jan 09, 2021 3:58 pm
by sindy
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.
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?

Re: L7 Filter rule exception.

Posted: Sat Jan 09, 2021 4:12 pm
by techclerk
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?
Okay.I am trying to get specific IP not part of the allowedlist to be able to open youtube.
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
 /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=!allowedlist
What I need is that IP in !allowedlist but in youtubeonly can access youtube.

Re: L7 Filter rule exception.

Posted: Sat Jan 09, 2021 4:38 pm
by sindy
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.

Re: L7 Filter rule exception.

Posted: Sat Jan 09, 2021 8:01 pm
by techclerk
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?
What I want is to have a rule, that uses the general allowedlist. So far, everything works, except L7 exceptions.
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
Should youtubeonly be an address-list, you have to use two rules in proper order.
Yes. I have rule with higher priority that states
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.

Posted: Sat Jan 09, 2021 9:50 pm
by sindy
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.

Posted: Sun Jan 10, 2021 4:48 pm
by techclerk
I'd have to see the complete filter rules to understand why it is happening..
These are the rules.
 add action=drop chain=forward comment=SiteRestrictions dst-address-list=blocklist src-address-list=!allowedlist 
Blocklist is a list of sites that are blocked. Before it I have L7 REXEXP blocking.
/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=!allowedlist
These are all the blocking rules.
I add exceptions to the SiteRestrictions, allowing an IP to bypass the restriction completely for IP-s that should not be restricted using this.
add action=accept chain=forward dst-address=mikrotik.com dst-port=80,443 \protocol=tcp src-address=192.168.10.10
I want to add exception for Youtube.com, bypassing only the L7 protocol rule for IP that is not in allowedlist.
I tried to do it this way
add action=accept chain=forward comment="Youtube Access ]" disabled=no \
dst-port=80,443 layer7-protocol="DisableYoutube" protocol=tcp \ src-address-list=!onlyyoutube
I put the ACCEPT for the address list onlyyoutube before DisableYoutube and before SiteRestrictions.
I 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
add action=accept chain=forward dst-address=youtube.com dst-port=80,443 \protocol=tcp src-address=192.168.10.10
This is my problem.
If 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.

Posted: Sun Jan 10, 2021 5:32 pm
by sindy
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

Re: L7 Filter rule exception.

Posted: Sun Jan 10, 2021 8:51 pm
by techclerk
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
So, if I understand correctly
add action=drop chain=forward comment=DisableYoutube disabled=\no dst-port=80,443 layer7-protocol="DisableYoutube"
 protocol=tcp \ src-address-list=!allowedlist
This handles the traffic in both directions? I thought that it handles the traffic in only one direction. Client->Server.
I 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.

Posted: Sun Jan 10, 2021 8:58 pm
by sindy
So, if I understand correctly
add action=drop chain=forward comment=DisableYoutube disabled=\no dst-port=80,443 layer7-protocol="DisableYoutube"
 protocol=tcp \ src-address-list=!allowedlist
This handles the traffic in both directions?
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.

Re: L7 Filter rule exception.

Posted: Sun Jan 10, 2021 9:38 pm
by pe1chl
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)

Re: L7 Filter rule exception.

Posted: Wed Jan 13, 2021 6:02 pm
by techclerk
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.
I was reluctant to post a complete an export of the Firewall rules, because of the fact that I had much to edit.
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.
# 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
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)
TLS host blocking wont work if the connection to the site is already established. And I can't find other way.
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.

Posted: Wed Jan 13, 2021 7:06 pm
by pe1chl
TLS host blocking wont work if the connection to the site is already established. And I can't find other way.
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.
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.
I am trying to block only the most time wasting sites. Reading news is fine, but not spending the whole day in facebook.
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]")

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.

Posted: Thu Jan 14, 2021 7:40 pm
by techclerk
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]")
I highly doubt that leaving a door widely open and putting a sign "You may be fined" is better than just locking the door.
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.

Posted: Thu Jan 14, 2021 8:28 pm
by sindy
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.

Re: L7 Filter rule exception.

Posted: Thu Jan 14, 2021 8:30 pm
by pe1chl
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.

Re: L7 Filter rule exception.

Posted: Sat Jan 16, 2021 3:36 pm
by techclerk
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.
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.1
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.
First, I admit I don't understand why your firewall rules above do not do what you expect them 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.
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.

Posted: Sat Jan 16, 2021 5:08 pm
by pe1chl
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.
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.1
That assumes that it is YOU who are the admin of those computers and can control everything, and not the persons operating the computer.
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.

Posted: Sat Jan 16, 2021 10:44 pm
by Sob
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, ...

Re: L7 Filter rule exception.

Posted: Sat Jan 16, 2021 11:31 pm
by pe1chl
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, ...
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.

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.

Posted: Fri Jan 29, 2021 8:05 pm
by techclerk
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.
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.

Re: L7 Filter rule exception.

Posted: Sat Jan 30, 2021 2:40 am
by Van9018
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.

Posted: Sat Jan 30, 2021 1:58 pm
by techclerk
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.
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.