How to choose the Web Proxy/Filter?
- Robert Rybicki
- Feb 18, 2023
- 4 min read

What is it about?
The World Wide Web, or so-called "the Internet", is a common attack vector allowing attackers to target your users directly, think about it as opening a tunnel from the attacker to your endpoints through all your defenses.
That is why I can't emphasize the importance of choosing a proper web-filter wisely.
The presentations performed by sales guys will be attractive and interesting but most likely they don’t understand the threats you are facing and rarely can offer a complete solution, they just want to sell you stuff.
I know very few vendors that can cover the fundamental requirements discussed later in this post.
People don't understand that whitelisting is no longer "too complicated to achieve" methodology of keeping your users secure.
It is not even something to "aim for" it has become the minimum, as even whitelisted sites get compromised.
You should think about how to defend against that, focus on in instead of spreading your attention on defending your users from millions of potential attack vectors by blacklisting known bad sites.
Actually... it is much difficult to deal with the consequences of constant breaches and exploitation due to malvertising / exploit packs on hacked / phishing sites etc... than maintaining a whitelist.
Please don’t hide your head in the sand and implement a whitelisting policy – it is very difficult initially but it does pay off tremendously in terms of protection.
...just do it.
I propose a simple ‘statistical approach’, building a baseline of the most visited sites in a month, followed by an assessment of which ones are safe and business-focused will give you a good list of sites that should be whitelisted.
Then just move further down the funnel, reviewing requests to add sites as they come in.
Evaluating a web filter
The list below doesn't contain everything, but it's a good start.
Support, understand that when you attend the first technical sales presentation have a list of difficult questions based on your past experience and needs. Look for the confidence and speed you receive answers with, if you keep getting the ‘we will get back to you on that’ – expect worse support in the future. Actually, always expect worse support than what you’ll get during the technical sales meetings, and base your assessment on that. Support should be able to modify settings on the fly and when needed, even tweak undocumented features. When you get promised a feature ‘which is being worked on’ – demand the exact stage at which the feature development is and ask them for hard dates for implementation with financial penalties if the promise is broken. If the sales guys were honest when promising it, it would not be a problem for them.
The ability for users to request the unblocking of a web resource right on the page where it says “blocked”, which would then be entered in a database allowing the admin to quickly and easily check / uncheck requests. It is very important to avoid e-mail notifications on a blocked site unblock request and only focus on products which offer seamless integration of that page with the back-end administrative system.
Demand a demonstration of the web filter ability to filter malicious pages – with malicious javascript on them, for example. Find new malicious URLs – for example, from http://www.malwaredomainlist.com/mdl.php - and TEST the newest entries there right during the sales demonstration to test the ability of the solution to ‘think on the fly’ without relying on a database of known bad hosts. This is very, very important.
The ability to block executables within archives for certain users / groups - The reason behind this requirement: only system admins / designated personnel should be able to download executables or executables within archives. All other users should be denied this right – and you should have a formal process to allow employees to request a download of a certain executable, for which a request should be filed and which request should go through a security review process. No executable should enter your network without proper authorization and risk assessment.
The ability to detect mismatching MIME types and block them (executable with a .jpg extension, for example).
Ability to block downloads from untrusted (non-whitelisted sites)
Ability to block advertisement networks and ads. Very important.
Ability to block POST requests larger than X bytes for all sites except a list of users, accessing a list (whitelist) of allowed websites. - this requirement effectively prevents data exfiltration and / or phishing. If you block ALL post requests except a list of whitelisted sites for a list of users (a user should request access to submit POST requests to a specific site and every request should be pre-approved).
Ability to block websites based on reputation and age. You should NOT!!!! Allow access to any website younger than 1 month and having no reputation or classification in the web filter database.
Ability to block encrypted sessions to IP addresses and URLs not present on a pre-approved list. This is obvious – only pre-approved sites and hosts should be able to establish encrypted sessions with your endpoints.
Ability to block based on regular expressions
Ability to integrate 3rd party AV engines - this requirement allows for the use of multiple AV engines at once, as opposed to a single AV engine.
Ability to integrate with the mobile devices managed by your company.
SSL inspection should be on by default. There should be a capability of raising an alert on first SSL connection to a non-SSL whitelisted (allowed) host. SSL whitelisting should be possible.
As mentioned in the beginning, this is a short summary, the list of points you should create before approaching vendors should be much longer.
Keep in mind that many vendors might not have all the features in the world, but those mentioned above are important.
In general, no proxy connection should be possible in a so-called "transparent mode", all devices wanting to connect via the proxy should have it manually configured.
No server or workstation within the internal network should be able to bypass the proxy and directly access the internet... otherwise... why do we bother with setting it up :)
Bonus stuff:
Ask your web proxy vendor if they can prevent "data exfiltration over encrypted channels" and how do they do it.
If their answer is unsatisfactory, you could implement your own box for that purpose following a simple guide:
(google for "Detecting and Preventing Data Exfiltration Through Encrypted Web Sessions via Traffic Inspection")
コメント