How can we improve GFI WebMonitor

Wishlist based on WebMonitor 2015 b20150518

1. Replace IIS Express with "full" version. Things like https access to administrator UI are much easier to do in IIS. MailEssentials use full IIS and it is much more comfortably to fine-tune it.
2. Fix 'Page cannot be displayed' when HTTPS scan is off. Something like option "do not scan https but send https error page" is needed. Of course, this will require to deploy Webmon certificate on user PCs, but at least it will be proper decision and it will not confuse users with mysterious errors.
3. Add site URL to blocking page. Site category is not always enough (cross-site content, iframes etc.).
4. Separate blocking page for bandwidth policy will be very useful. "You have been blocked from downloading THIS FILE since it breaches a SECURITY policy" creates confusion amongst our users, not everyone reads further details.
5. Put on this page a button that will request bandwidth counter reset, NOT access to site! This is quite absurd situation when it requests access to just one site with unlimited bandwidth after quota exceeding.
6. Add ability to show custom html page instead of default block\warn page. Like, additional component in policy editor "Show custom page". Just simple static page from html file in WebMonitor\UserPages with data I need to give user in this particular situation.
7. Ability to limit connection speed for users\IPs is absolutely necessary.
8. Remote access to admin UI without setting proxy server (access by server hostname or IP) is needed too.

4 votes
Sign in
Signed in as (Sign out)

We’ll send you updates on this idea

Fokin  VladimirFokin Vladimir shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Signed in as (Sign out)
  • Zoltan B.Zoltan B. commented  ·   ·  Flag as inappropriate

    Yes, HTTPS scanning should be enabled to have full control of HTTPS traffic. The fact that we can block some HTTPS connections without HTTPS scanning is only a lucky situation, we can use of some properties of the initial HTTPS connecting mechanisms ...

    Reverse proxy and other similar functionality that TMG has is not currently planned for WebMonitor, at least not in the near future.

    I have checked now explicitly the blocking page and remembered the reasons why we cannot show all data there. It is due to the optimized policy rule engine that we have implemented for the new version. In nutshell, we are evaluating all policy conditions and once we found out that some request should be blocked, we stop immediately and blocking page is displayed. At that point we do not have all the data, for example we do not wait more to obtain the category of that site or wait for the user to authenticate and so on. Therefore, according to what blocking condition do you configure in your policy, we might have or might not have other (extended) information because we do not wait for that. We want to have control as soon as possible, otherwise there might be situations in which requests or part of requests can go out uncontrolled. It seems that these limitations are a slight tradeoff to obtain very good security / performance.

  • Fokin  VladimirFokin Vladimir commented  ·   ·  Flag as inappropriate

    Correction about #3. And expansion for original request.

    I found why we had different results. It seem that blocking page shows only fields described in policy. For example, simple "block all" rule will show "Breached policy" field ONLY. User, domain, domain category are not shown. Policy, that blocks some cathegory, will show domain category on blocking page. Policy that blocks domain will show domain.

    So, correction to #3 will be:
    Make blocking page show some minimal data set regardless of triggered policy. At least it should include: user name and workstation IP, blocked domain, site category, triggered policy.

  • Fokin  VladimirFokin Vladimir commented  ·   ·  Flag as inappropriate

    Well, the only viable option is to use inspection than. To trade higher load on server for absence of strange errors on user's screens.

    BTW, another addition to wishlist!
    Reverse proxy and URL redirection. Both ways.
    Because for now I am in process of replacing of ISA+WebMon functions to WebMon + something else.
    Or maybe you do not have plans to replace all (or at least most) functions of TMG, including reverse proxy etc. and concentrating on user security only?

    Everything else is answered, yes. Thanks for your patience.

  • Zoltan B.Zoltan B. commented  ·   ·  Flag as inappropriate

    By reading your latest comments I believe there is only item 2. left to have answered, about how to display blocking pages without HTTPS scanning.

    Unfortunately what you desire is technically not possible. We need to know at the very first request whether we are going to inspect that HTTPS traffic or not. Once that decision is taken, there is no way back for that connection. And at the very first request you rarely know whether that will be blocked or not. We can take only simple decisions like blocking based on a particular URL or not. After that, you can have lots of other policies applied that need further content, like AV scanning, bandwidth/time limitations, application detection and so on.

    I hope my answer was good enough for you for this item.

  • Fokin  VladimirFokin Vladimir commented  ·   ·  Flag as inappropriate

    1. Yes, HTTPS on Express is definitely possible, but I am not sure if it needs some ajustments on your end, or just configuration edits from our end. Anyway, some more convenient way to enable this is very desirable. Sending potentially sensitive data over http (even inside our network) isn't the best choice.

    2. Yes, I remember this xml setting. But how it works? Is it possible to make some kind of "dynamic" DomainsExceptedFromHTTPSInspection list that will check site against policy and autoexclude it if there is no blocking rule?
    Also, I am not talking about "modify traffic without encrypting it", I am talking about "override" traffic by our own, as you already do when showing blocking pages when HTTPS inpection enabled.
    Let's explain it like this: HTTPS inspection is ON, all traffic is decrypted-reencrypted by default, BUT policy applies dynamic DomainsExceptedFromHTTPSInspection list that will exclude from inspection ALL sites EXCEPT those which blocked by policy. For these sites Webmonitor does full inspection and therefore shows proper blocking page.
    Result is exactly what I proposed - no "page cannot be displayed" on blocked https sites, no decryption-reencryption for permitted sites, even if inside it is still means "inpection is on".
    There will be three states for setting: no inspection \ internally on (for blocked sites only) \ full inspection. Of course, blocking rule must override static DomainsExceptedFromHTTPSInspection - without it users will get same uninformative error.
    Not sure if this is more visual. But I am definitely no specialist in such matters.

    3. Will do.

    6. "blocking page should necessarily contain dynamic data as well"
    Well, in this case I will create some pre-defined policies with strict if-then dependence. No real parametrized data is needed, everything will be hardcoded by me. But if you can do parametrization too - why not?
    "add to the current blocking page a section that can display custom text"
    Very interesting idea. But it will require additional form in policy editor, that will allow to change font size, section placing etc. - like forum posting form. There must be some room for maneuver.
    To give us a template for creating our own pages and a way to show the result to users is simplier (I believe) for you and will give us more choice (but, of course, it will require more work from our side). For me these options balance each other.

    "Regarding your comments on how users can find out ways to access the WebMonitor console - that is already protected by the current product."
    Yes, of course. I used this to limit access to UI. I just wanted to clarify how publishing UI lowers security. I misunderstood you, I decided that accessing by adds some more protection mechanisms from proxy service itself.
    Of course it will be published to internal network only, no public access. That was the point - access to UI from internal network by server address from browser without proxy setings configured. Just for convenience. It is possible - that's enough for me.

    "please note that the generated certificate is used ONLY to encrypt the connection between the GFI Proxy and the client machines, so that happens in your local network only"
    Yes, i understand. But browsers still will show errors to users because of SHA1. It's not security concern, it's users comfort concern. And therefore it's my comfort concern. Well, you aware about that and you will do update - that's enough.

  • Zoltan B.Zoltan B. commented  ·   ·  Flag as inappropriate

    Thank you for the detailed replies, they are greatly appreciated. Let me provide you with further feedback from our end on the items discussed earlier:

    1. We can consider to offer alternatively WebMonitor UI access over the more secure HTTPS protocol, we can check this for future releases. At this point I am not sure whether IIS (non-Express) version would be required only to offer HTTPS access, since IIS Express also supports this. However, this feature obviously will introduce some overhead of handling certificates and so on.
    2. Unfortunately, accepting the connection is not possible in the operation mode when you do not decrypt the traffic, and then at some point you decide that you wish to block that. The entire logic speaks against the purpose of HTTPS encryption. If you can modify traffic without encrypting it, it means you have hacked the sole purpose of HTTPS and you would make it irrelevant. That is why I have asked you to point out any product that can do this.
    In the article you have pointed out they are doing or not HTTPS decryption. Please note that we can also do that from WebMonitor, by editing Data\proxyConfig.xml file. There we can add exclusions for domains/users/IP addresses that will not have their HTTPS connections decrypted. But this does not bring you any closer to solving the initial problem.
    3. I have just made again a quick test with WebMonitor, by blocking a particular domain, and on the blocking page the domain name also appears that was blocked. We can investigate more the reason why in your case the URL is not included in the blocking page, but for this please open a support ticket.
    6. I understand your point now. However, I still believe the blocking page should necessarily contain dynamic data as well, like what is blocked and why - which means parametrized template. An alternate option would be to add to the current blocking page a section that can display custom text that the administrator defines, like numbers to call, people to contact etc. What do you think about this?

    Regarding your comments on how users can find out ways to access the WebMonitor console - that is already protected by the current product. Please check Settings->Advanced Settings->UI Access control section where you can set up a set of access policies to enable access only to specific users (IP addresses). Moreover, you can also customize what section your users should be able to access, for example restricting their access to monitoring only and not to be able to change settings. By default, users that are not added to the "Default Authorization Rule" do not have access to the configuration UI at all.

    And for the last item, we are also aware that SHA1 is getting obsolete, and we are considering to update also the certificate generation within the product with SHA2. However, please note that the generated certificate is used ONLY to encrypt the connection between the GFI Proxy and the client machines, so that happens in your local network only (i.e. traffic is not visible outside of your network).

    If you have further comments on what to improve on the product, they are more than welcome!

  • Fokin  VladimirFokin Vladimir commented  ·   ·  Flag as inappropriate

    1. Mostly. BTW, HOW to do this? <binding protocol="https" bindingInformation="*:443:" /> + netsh http add sslcert ipport= certhash=... etc. didn't help. I have almost no expirience with IIS Express (I am no developer and we use full version on windows server in production).
    Answer on forum ( did not really helped.
    Also, full IIS allows things like "put this site on specific IP or port", HSTS (yes, I am paranoid and prefer to force protection rather than allow to forget about it) and certificate-based auth from GUI, not from manual config edits. Not that it was important, just a good bonus.

    2. Well... My idea about this (again, I am no developer and can be terribly wrong):
    a) Accept connection
    b) Find destination adress from CONNECT request
    c) If rule is "block" -> send blocking page by https with webmon certificate as usual. That's why deployment is needed.
    d) Else pass connection as is, undecrypted.
    (sorry, not sure if there is translated version)
    There is an option there "Decrypt traffic only from selected domains". And "Decrypt everything except selected domains". Everything else goes without decryption.

    3. Where? I mean exactly "on blocking page", not browser address field.

    4, 5. Thanks.
    6. Thanks again. Use case scenarios? Well, mostly "just in case" for specific blocking situations. Like "call this number if you need assistance", "to get access to this cathegory you need to apply..." (yes, BUREAUCRACY; sometimes we cannot just allow users to do something as we desire and need to follow the rules...) etc., nothing specific. Simple static page will be fine, template with parametrized data is cool but I think there is little need in this and it will require more work from you.

    7. Excellent.

    8. Good.
    About security concerns... HTTPS access to UI should fix them, right? And certificate-based auth. And full IIS will make these things easy as pie. :)
    Also, just out of curiosity, how current method increases security? I mean, it still possible to find out proxy server address (from user PCs, WPAD etc.), find out that it is webmonitor (from blocking message) and use "default" way to access UI described in manual. Harder than automatic port scanning, but still not a problem.

    One more thing: update certificate generator, please! SHA1 is deprecated and will (in future) cause:
    "Broken https" and “Untrusted Connection” errors are no good.

    I was unable to replace generated certificate with one from our own CA, so... you're my only hope.

  • Zoltan B.Zoltan B. commented  ·   ·  Flag as inappropriate

    Thank you for the detailed feedback. Please see my comments below for each item mentioned.

    1. IIS Express is a lightweight component that should suit the requirements of our product. Can you elaborate more on what exactly you cannot do with it? Do you only wish to have access to the UI over HTTPS instead of HTTP?
    2. I don't think this is technically possible. If WebMonitor proxy is not decrypting HTTPS traffic, all we can do is to drop the connection on CONNECT. We cannot write any response back to the client browser in this case. Do you know any other product that can display custom blocking message without HTTPS decryption?
    3. On the blocking page the domain is also displayed. Would you like to see there the full URL instead of the domain? Please note that full URLs can get extremely long.
    4. We will analyze the possibility to display more appropriate blocking pages in the scenarios described by you, for future versions.
    5. You have a valid point there, we will check this together with item 4).
    6. We can also consider this option. Can you please highlight the use case scenarios in which you would need to display custom blocking pages to clients instead of the default one? Would you need to be parametrized or just a static page all the time? (like also showing blocked URL, policy or other relevant data)
    7. This is a feature request that we already have it in mind, it is considered for future versions.
    8. There is currently a possibility to publish the WebMonitor UI also on the IP address for example:
    - Locate and edit WebUI\WebServer.config file within the WebMonitor installation folder
    - Locate the following xml node: "<binding>"
    - Insert a new child node under <binding> node:
    "<binding protocol="http" bindingInformation="*:1007:[IPADDRESS]" />" - where [IPADDRESS] refers to the IP address where the GFI proxy is listening
    - Restart the WebMonitor services

    Please note that we do not recommend publishing the WebMonitor configuration on a public IP address that is accessible remotely, due to security concerns.

Feedback and Knowledge Base