This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Circumventing quota time allocation

I have my UTM configured to apply quota to media streaming but I found an issue.  The check on available time only seems to be done at the start of the streaming, the consequence of this is that a user can allocate 10 minutes of their allowed quota and then kick of a streamed video and be able to watch the whole thing even if it is several hours long.  

Does anyone know of a way to stop this ?

Regards

Gnome


This thread was automatically locked due to age.
  • If the streaming app buffers everything within 10 minutes, then  there's no way to stop it at all,
    IT also might be that the request happens with http(/s) and the reply happens with a different protocol/set of ports, which aren't controlled by proxy. I know about quicktime and silverlight doing such things.

    In both cases, there's no such thing as stopping it.
    Just out of interest:
    Are you(or someone else) still able to browse that very same website in a different tab, even past those 10 minutes?
  • I am fairly sure that the whole stream is not bufered in the 10 min slot, I have had an instance of a 5 hour youtune stream being watch and only using 10 mins of the quota.  Not sure about the ports being different, I will have a look at that.

    Ref your question on the browsing, that is not effective, so taking the youtube example, the user (actually my kids) can brows youtube and the quota only gets checked at the point the streaming starts.  Generally they have multiple tabs up which work ok.

    Regards

    Gnome
  • If you look in your http log and see a bunch of streaming requests that are going through that should be blocked, then this might be considered a problem.

    More likely, however, is that you wont see anything in the log.  For example if this is HTTPS youtube and you are not doing HTTPS scanning.  If it it is out of band somehow.

    Or if you can see it in the logs but the category of the content delivery network URL is not a type you are doing quota for.

    However as a generic problem, its not the UTM.  For example if you say that you are only allowed to go to News sites for 10 minutes a day there is nothing stopping someone from opening 100 tabs of articles within that time and then read it over a few hours.  We don't control the browser, only the traffic.
  • I think the problem is that the quota appears to be checked at the begginging of a strame and is then not terminated when the quota runs out.

    If you applied the quota to something like normal web page access then this is not a problem but when you apply it to a media stream which can last a couple of hours to does not work properly. :-(
  • There is a similar issue with online game sites e.g. based on Adobe Flash/Shockwave Player. The quota is checked via URL request when you start playing. During the game no URL request is sent. Therefore the time quota check cannot be performed, and you get unlimited play time. The following scenario is possible: At the beginning of your play time quota you open different games in different browser tabs, getting a real huge playground for many hours. Is there any way to fix this issue within the UTM 9? I searching for a mechanism which limits the play time independently from URL requests.

  • Something that is probably related:

    With https scanning disabled, the logs contain a single "Connect" entry for each https session.   

    I have determined that the Size information on the log entry represents the total volume of traffic moved during the session, and that the log entry is not written until the session is closed.

    Youtube (and other Google sites) are fully https-based.  So the best that we can expect is that the quota will be updated when the session is closed, at which point a new session will not be allowed, but it does not solve your problem with the long session.

    Https inspection might solve the problem, because each request is logged separately.   That requires deploying the UTM CA and a proxy configuration to each device.