1

We run a pretty vanilla Centos 7 LAMP server ( Apache 2.4 with mod_pagespeed PHP 5.6, MariaDB 5.5 ), and recently started embedding html5 videos on the background of some pages as per code:

<video class="banner-video" loop autoplay poster="img/poster.jpg">
    <source src="videos/intro.mp4" type="video/mp4">
</video>

The video works as expected, and auto-loop as expected, most of our clients load the video once and reload the video from the cache after the first run, but we have some clients ( I am counting 3 at the moment ) that keep re-downloading every time after the first run and this blows our bandwidth quota pretty fast ( sometimes the same ip address downloads 35gb worth of the same 7mb video file ).

I am pretty sure that this behavior is not malicious ( in this case at least, i am willing to believe it is some misconfiguration at their proxy server or some such ), and so I am looking at ways to limit the bandwidth used by one ip address, or to better inform the client browser to cache the video file, we already tried to use in the apache virtual-host and via .htaccess this config and it doesn't seems to make a difference.

<FilesMatch "\.(mp4)">
    Header set Cache-Control "max-age=604800, must-revalidate"
</FilesMatch>

I've already tested moving the video file to another server with a different configuration ( an even more vanilla Centos 6.6 LAMP ) to test if it was not some misconfiguration on our part

so my question is is there an easy way to block using apache configuration (temporarily by 24 hours or one week maybe) only the loading of a file by certain ip addresses after say 10 loadings, while maintaining the ability to load the rest of the site ?

or is there a better way to inform the client to follow the cache rules ?

I probably could write an PHP script that counted the times the file has been loaded and responded with a 403 in case that it has been downloaded more than X times by the same IP but i don't think this solution is optimal.

as by apache logs our client is running windows 10 x64 with google chrome 48 ( maybe this is a know bug )

Rafael Rotelok
  • 121
  • 1
  • 7
  • Somebody loaded your video 5,000 times?! That probably _is_ malicious. – Michael Hampton Feb 27 '16 at 03:00
  • that was what i though at first too... but we resell web hosting and this ip address is from the the network our client and him trying to make his webpage unavailable would be a shot on the foot, so i think maybe it is something at their end that is keeping the video from caching properly and asking if there is something i could do to prevent it – Rafael Rotelok Feb 27 '16 at 03:06
  • 1
    You can talk to the client and ask them why they loaded the video 5,000 times. – Michael Hampton Feb 27 '16 at 03:08
  • or i could block his IP at the firewall level, until i have this same problem with another client at another video file, it's a game of cat and mouse that i don't want to play..... as stated in the question the video is looping, and by my logs what i think happens is, he arrives at work open the browser and keep his company webpage open at a background tab, my problem arises from the fact that for every loop of the video it is re-downloading the video file and ignoring the browser cache – Rafael Rotelok Feb 27 '16 at 03:17
  • The fact that all requests come from the same IP does not mean it is from the same user. It might just be their ISP's public IP with a whole city/county/country WAN behind it. – Vedran B Apr 05 '20 at 20:45
  • back then CGNAT wasn't as common as today, and the IP address belonged to the client ipv4 network, but you got a good point and nowadays a few ISPs share a single ipv4 with multiple clients – Rafael Rotelok Jun 18 '20 at 23:16

1 Answers1

0

Just a small follow-up answer to this question so it don't end up unanswered forever, it doesn't actually fix the problem but at least it lowers the bill we had to pay.

I was able to replicate the issue with a badly configured squid server acting as a proxy.

What I did in this case was host the video, and other videos we had to host since then, in another server that had a higher latency but extremely cheap bandwidth.

The overall client experience doesn't change much because as we are only hosting the video files in the cheap server we are not paying the high latency price for every file, just for the request to the video.

Rafael Rotelok
  • 121
  • 1
  • 7