2

After a two week search and read I ended up with this iptable rule that blocks youtube (as string) to an ip range in my office network.

iptables -A FORWARD -t filter -m iprange --src-range 10.217.76.60-10.217.76.70 -m string --algo bm --string "youtube.com" -j DROP #block

As you can see computers from .60 to .70 (10 machines) cannot browse youtube, while e.g. .75 can. The rule works only for a few minutes and for some clients. After 2 or 3 minutes some clients can browse youtube normally. If I close those clients' browser, flush the iptables rules and re-run them again, all clients cannot connect to youtube but this lasts for 2-3 minutes again and for some clients (I'm talking about the ip-range clients).

Has anyone met this behavior again?! Does it have to do with the server I'm using (ubuntu 11.04), the cache or something else!?

I also have squid3 installed where i block the http of youtube and facebook, so i thought setting iptables i could cut the youtube for the https. (But some clients really need youtube to work, so i want to cut off song listening and useless network traffic).

EDIT: After a long I tried : iptables -I FORWARD -t filter -s 10.217.76.80/28 -m string --algo bm --string "youtube.com" -j DROP #from .80 to .95 (15 ip) and got a better solution ...just for a while. After some time some clients started browsing again (rule didn't work) while others still didn't (rule worked). I understand that (as MADHatter said) is a Youtube thing with many many servers, but what i don't understand is that when using a rule like this iptables -I FORWARD -m string --algo bm --string "youtube.com" -j REJECT all traffic for all clients is rejected for ever not just for some time, the only thing that I wanted is use the above rule for an ip range of users e.g from .10 to .240 and let all others freely browse youtube. Do you think there is a rule for that? Everything else similar that i tried worked only for a random time period.

ASK
  • 41
  • 1
  • 7
  • 1
    ASK, looking at your activity on ServerFault, may I point out that you should accept an answer you're happy with by clicking on the "tick" outline next to it? This drives the SF reputation system for both you and the answer's author, and stops the question floating around forever like a querulous albatross. I mention this particularly in respect of your earlier question, the answer to which you seem to be happy with. My apologies if you already know this. – MadHatter Sep 16 '15 at 07:55

1 Answers1

2

You say "i could cut the youtube for the https". This isn't going to work; URLs on an HTTPS connection are exchanged under cover of crypto. The firewall may be in the data stream, but it won't see this conversation, as by that point its job is reduced to taking encrypted packets from one interface to another.

Yes, it's possible for clients to try to go to http://youtube.com, and you can desynchronise that particular http connection. But that URL now redirects them straight to the https:// site; sooner or later, your clients are going to realise that they can access youtube via SSL, and you won't be able to see what they're doing.

The traditional correct method to moderate what URLs can be accessed is a mandatory web proxy - but in the case of HTTPS content, you still have a problem. You can man-in-the-middle it all, but unless you have a proxy that re-encrypts and re-signs each HTTPS request (and each of your clients has installed and trusts your proxy's CA certificate) this will result in a very unsatisfactory browsing experience for your users of any HTTPS content.

tl;dr: youtube has decided to mandate HTTPS connections to their sites, so without some highly sophisticated proxying (which noddy iptables rules are not) you can't stop your users going there.

MadHatter
  • 78,442
  • 20
  • 178
  • 229
  • thanks for your immediate answer, I have a question... when i use iptables -I FORWARD -m string --algo bm --string "facebook.com" -j REJECT I really block all facebook like a timeout is happening. With the above command no one can browse facebook either by typing the web address or by searching for it. I tried to extend that rule for allowing some clients browse the youtube while others don't. The strange thing is that for some clients the rule rejects all youtube traffic but on others happens the SSL browsing you mentioned Do you think i can do something about it?! – ASK Sep 16 '15 at 07:37
  • Actually, the rule will probably whack youtube.com connections successfully, due to the wonders of SNI. – womble Sep 16 '15 at 07:54
  • @womble I wondered about that, but figured youtube was big enough that they had dedicated servers, which don't need to (though of course still may) use SNI. In any case, clients can bypass that by turning off SNI client-side. I stand by my `tl;dr`, to the effect that reliably vetting HTTPS browsing requires more than this. – MadHatter Sep 16 '15 at 07:58
  • 1
    SNI is entirely client-controlled (the server can't ask for it or demand it). I agree that reliably filtering HTTPS traffic isn't something for a couple of, as you so eloquently put it, "noddy iptables rules". – womble Sep 16 '15 at 10:18
  • Then I think we're in agreement that clients could avoid falling foul of an `iptables` rule such as that above by not engaging in an SNI exchange during TLS client hello, and thus continue to connect to `https://youtube.com`. – MadHatter Sep 16 '15 at 11:34
  • If you **enforce a proxy** and **block non SNI https** connections (SSLv3) then you **check** that the requested **URL and SNI info matches**, you should have quite a robust https filtering mechanism – Pieter May 25 '16 at 14:24