* Blocking Google Earth
@ 2005-08-12 20:18 fabricio bianco abreu
2005-08-12 20:29 ` Raphael Jacquot
0 siblings, 1 reply; 11+ messages in thread
From: fabricio bianco abreu @ 2005-08-12 20:18 UTC (permalink / raw)
To: netfilter
Hi folks,
Is there a way to use iptables to deny access to Google Earth servers, without
blocking access to Google search engine (www.google.com)??
I have googled the Internet to find a way to do so and all I found was users
trying to configure Norton firewall to allow access to Google Earth.
Thanks in advance
________________________________________________________________
Fabricio Bianco Abreu
Núcleo de Informática e Processamento de Dados
TRIBUNAL DE CONTAS DO DISTRITO FEDERAL (http://www.tc.df.gov.br)
Tel 55 - 61 - 314 2236
Fax 55 - 61 - 314 2268
Utilize software livre (visite http://www.tc.df.gov.br/tcbrasil)
________________________________________________________________
________ Information from NOD32 ________
This message was checked by NOD32 Antivirus System for Linux Mail Server.
http://www.nod32.com
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Blocking Google Earth
2005-08-12 20:18 Blocking Google Earth fabricio bianco abreu
@ 2005-08-12 20:29 ` Raphael Jacquot
2005-08-12 22:38 ` fabricio bianco abreu
0 siblings, 1 reply; 11+ messages in thread
From: Raphael Jacquot @ 2005-08-12 20:29 UTC (permalink / raw)
To: fabricio bianco abreu; +Cc: netfilter
fabricio bianco abreu wrote:
> Hi folks,
>
> Is there a way to use iptables to deny access to Google Earth servers, without
> blocking access to Google search engine (www.google.com)??
>
> I have googled the Internet to find a way to do so and all I found was users
> trying to configure Norton firewall to allow access to Google Earth.
why would one want to do that ?
it's not like it's P2P stuff or anything...
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Blocking Google Earth
2005-08-12 20:29 ` Raphael Jacquot
@ 2005-08-12 22:38 ` fabricio bianco abreu
2005-08-13 2:31 ` Thilo Schulz
0 siblings, 1 reply; 11+ messages in thread
From: fabricio bianco abreu @ 2005-08-12 22:38 UTC (permalink / raw)
To: Raphael Jacquot; +Cc: netfilter
I would like to block it because a user using Google Earth consumes about
256kbps bandwith. I have 600+ users and only a 2Mbps link to the Internet.
att.
Fabricio
---------------
Citando Raphael Jacquot <raphael.jacquot@imag.fr>:
> fabricio bianco abreu wrote:
> > Hi folks,
> >
> > Is there a way to use iptables to deny access to Google Earth servers,
> without
> > blocking access to Google search engine (www.google.com)??
> >
> > I have googled the Internet to find a way to do so and all I found was
> users
> > trying to configure Norton firewall to allow access to Google Earth.
>
> why would one want to do that ?
> it's not like it's P2P stuff or anything...
>
________ Information from NOD32 ________
This message was checked by NOD32 Antivirus System for Linux Mail Server.
http://www.nod32.com
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Blocking Google Earth
2005-08-13 2:31 ` Thilo Schulz
@ 2005-08-12 23:59 ` Eric Scopinho
2005-08-13 12:32 ` Jan Engelhardt
2005-08-13 14:14 ` Leonardo Rodrigues Magalhães
2 siblings, 0 replies; 11+ messages in thread
From: Eric Scopinho @ 2005-08-12 23:59 UTC (permalink / raw)
To: netfilter
Maybe something like this would help:
iptables -I FORWARD -p TCP --dport 80 -m string --string "User-Agent:
kh_lt/LT" -j DROP
P.S: I'm not able to test it right now. :-(
[]s
Eric Scopinho
Thilo Schulz wrote:
> On Saturday 13 August 2005 00:38, fabricio bianco abreu wrote:
>
>>I would like to block it because a user using Google Earth consumes about
>>256kbps bandwith. I have 600+ users and only a 2Mbps link to the Internet.
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Blocking Google Earth
2005-08-12 22:38 ` fabricio bianco abreu
@ 2005-08-13 2:31 ` Thilo Schulz
2005-08-12 23:59 ` Eric Scopinho
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Thilo Schulz @ 2005-08-13 2:31 UTC (permalink / raw)
To: netfilter
[-- Attachment #1: Type: text/plain, Size: 908 bytes --]
On Saturday 13 August 2005 00:38, fabricio bianco abreu wrote:
> I would like to block it because a user using Google Earth consumes about
> 256kbps bandwith. I have 600+ users and only a 2Mbps link to the Internet.
I don't see how you would do that without doing a packet inspection for all
packets directed at www.google.com, as maps.google.com is - as you
undoubtedly already know - is an alias for www.google.com
You would have to do packet inspection and filter for maps.google.com. This
could be easily circumvented by using an SSL capable proxy.
Maybe QoS could do the trick for you. While allowing access to google earth,
it might discourage that user from excessively using it by restricting his
bandwidth to something like 64kbit/s while google itself is still perfectly
usable. It is generally a sensible idea to make use of QoS on a setup like
yours.
--
Thilo Schulz
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Blocking Google Earth
2005-08-13 2:31 ` Thilo Schulz
2005-08-12 23:59 ` Eric Scopinho
@ 2005-08-13 12:32 ` Jan Engelhardt
2005-08-14 1:15 ` Dwayne Hottinger
2005-08-13 14:14 ` Leonardo Rodrigues Magalhães
2 siblings, 1 reply; 11+ messages in thread
From: Jan Engelhardt @ 2005-08-13 12:32 UTC (permalink / raw)
To: Thilo Schulz; +Cc: netfilter
>> I would like to block it because a user using Google Earth consumes about
>> 256kbps bandwith. I have 600+ users and only a 2Mbps link to the Internet.
- QoS / egress
- string/layer7 match with "Host: earth.google.com" or whatever fits
- Full Transparent proxying using e.g. squid
Jan Engelhardt
--
| Alphagate Systems, http://alphagate.hopto.org/
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Blocking Google Earth
2005-08-13 2:31 ` Thilo Schulz
2005-08-12 23:59 ` Eric Scopinho
2005-08-13 12:32 ` Jan Engelhardt
@ 2005-08-13 14:14 ` Leonardo Rodrigues Magalhães
2005-08-13 15:11 ` Thilo Schulz
2 siblings, 1 reply; 11+ messages in thread
From: Leonardo Rodrigues Magalhães @ 2005-08-13 14:14 UTC (permalink / raw)
To: netfilter
I really dont think it's easy to limit bandwidth usage ONLY for
Earth Google without making bad experiencies on doing searchs on Google.
No matter if searches are low-bandwidth. If you get some QoS and band
limitation on google IPs, be sure that your google earth users will use
ALL the available bandwidth, thus making google earth as well as google
serching probably extremely slow.
I'm actually making some limitations on Google Earth on the HTTP
proxy, squid. Several of them are running transparent. User doesnt need
to configure it on the browser. In some cases, I have squid running
without caching and without logging. They are running JUST for limiting
that !!!!
On the actual version, software Google Earth seems to get
information using HTTP. I just get this from my squid log file:
Sat Aug 13 10:59:51 2005 949 192.168.1.50 TCP_MISS/200 15300 GET
http://kh.google.com/flatfile?f1-0023212010203-i.4 -
DIRECT/64.233.179.93 application/octet-stream
Sat Aug 13 10:59:53 2005 1979 192.168.1.50 TCP_MISS/200 2631 GET
http://kh.google.com/flatfile?f1c-0023212010331-t.1 -
DIRECT/64.233.179.93 application/octet-stream
Sat Aug 13 10:59:53 2005 4464 192.168.1.50 TCP_MISS/200 18827 GET
http://kh.google.com/flatfile?f1-0023212010312-i.4 -
DIRECT/64.233.179.93 application/octet-stream
Sat Aug 13 10:59:54 2005 3026 192.168.1.50 TCP_MISS/200 20208 GET
http://kh.google.com/flatfile?f1-0023212010320-i.4 -
DIRECT/64.233.179.91 application/octet-stream
Sat Aug 13 10:59:54 2005 5746 192.168.1.50 TCP_MISS/200 20088 GET
http://kh.google.com/flatfile?f1-0023212010313-i.4 -
DIRECT/64.233.179.91 application/octet-stream
So, using some simpe ACLs (for kh.google.com for example) and Delay
Access features, you can easily make heavy limitation on Google Earth
software without making bad experiencies for google searching users.
Now let's go to Google Maps, http://maps.google.com/
This is Google Maps in the 'Map' view:
Sat Aug 13 11:10:23 2005 1347 192.168.1.50 TCP_MISS/200 6745 GET
http://mt.google.com/mt?v=w2.5&x=15294&y=25565&zoom=1 -
DIRECT/64.233.179.99 image/png
Sat Aug 13 11:10:23 2005 1352 192.168.1.50 TCP_MISS/200 7662 GET
http://mt.google.com/mt?v=w2.5&x=15294&y=25567&zoom=1 -
DIRECT/64.233.179.104 image/png
Sat Aug 13 11:10:24 2005 1686 192.168.1.50 TCP_MISS/200 10810 GET
http://mt.google.com/mt?v=w2.5&x=15294&y=25566&zoom=1 -
DIRECT/64.233.179.104 image/png
This is Google Maps in the 'Satellite' view:
(here's our kh.google.com again !!)
Sat Aug 13 11:11:14 2005 2169 192.168.1.50 TCP_MISS/200 19040 GET
http://kh.google.com/kh?v=3&t=tqtsrrqsssrt - DIRECT/64.233.179.93 image/jpeg
Sat Aug 13 11:11:14 2005 2169 192.168.1.50 TCP_MISS/200 11572 GET
http://kh.google.com/kh?v=3&t=tqtsrrqsssst - DIRECT/64.233.179.91 image/jpeg
Sat Aug 13 11:11:14 2005 2321 192.168.1.50 TCP_MISS/200 14974 GET
http://kh.google.com/kh?v=3&t=tqtsrrqssssq - DIRECT/64.233.179.93 image/jpeg
Sat Aug 13 11:11:16 2005 1701 192.168.1.50 TCP_MISS/200 11026 GET
http://kh.google.com/kh?v=3&t=tqtsrrqsssts - DIRECT/64.233.179.91 image/jpeg
Sat Aug 13 11:11:16 2005 1511 192.168.1.50 TCP_MISS/200 13554 GET
http://kh.google.com/kh?v=3&t=tqtsrrqssstq - DIRECT/64.233.179.93 image/jpeg
And this is Google Maps in the 'Hybrid' view:
Sat Aug 13 11:11:49 2005 385 192.168.1.50 TCP_MISS/200 4454 GET
http://mt.google.com/mt?v=w2t.1&x=476&y=796&zoom=6 -
DIRECT/64.233.179.104 image/png
Sat Aug 13 11:11:49 2005 442 192.168.1.50 TCP_MISS/200 3052 GET
http://mt.google.com/mt?v=w2t.1&x=479&y=800&zoom=6 -
DIRECT/64.233.179.99 image/png
Sat Aug 13 11:11:49 2005 465 192.168.1.50 TCP_MISS/200 2917 GET
http://mt.google.com/mt?v=w2t.1&x=477&y=796&zoom=6 -
DIRECT/64.233.179.99 image/png
Sat Aug 13 11:11:49 2005 571 192.168.1.50 TCP_MISS/200 2674 GET
http://mt.google.com/mt?v=w2t.1&x=475&y=800&zoom=6 -
DIRECT/64.233.179.104 image/png
Sat Aug 13 11:11:49 2005 445 192.168.1.50 TCP_MISS/200 1083 GET
http://mt.google.com/mt?v=w2t.1&x=475&y=797&zoom=6 -
DIRECT/64.233.179.104 image/png
Sat Aug 13 11:11:49 2005 389 192.168.1.50 TCP_MISS/200 2862 GET
http://mt.google.com/mt?v=w2t.1&x=479&y=796&zoom=6 -
DIRECT/64.233.179.99 image/png
Sat Aug 13 11:11:49 2005 391 192.168.1.50 TCP_MISS/200 3782 GET
http://mt.google.com/mt?v=w2t.1&x=476&y=800&zoom=6 -
DIRECT/64.233.179.99 image/png
And let's not forget the new Google Moon:
Sat Aug 13 11:13:13 2005 2366 192.168.1.50 TCP_MISS/200 22795 GET
http://moon.google.com/kh?v=2&t=ttqqq - DIRECT/66.102.7.99 image/jpeg
Sat Aug 13 11:13:13 2005 2678 192.168.1.50 TCP_MISS/200 22970 GET
http://moon.google.com/kh?v=2&t=tqttq - DIRECT/64.233.187.99 image/jpeg
Sat Aug 13 11:13:13 2005 3703 192.168.1.50 TCP_MISS/200 24877 GET
http://moon.google.com/kh?v=2&t=trsss - DIRECT/66.102.7.147 image/jpeg
Sat Aug 13 11:13:14 2005 3365 192.168.1.50 TCP_MISS/200 23140 GET
http://moon.google.com/kh?v=2&t=tqttt - DIRECT/66.102.7.104 image/jpeg
Sat Aug 13 11:13:15 2005 2579 192.168.1.50 TCP_MISS/200 25423 GET
http://moon.google.com/kh?v=2&t=tsrrr - DIRECT/66.102.7.99 image/jpeg
With these URLs and a transparent http proxy running, you can surely
imply hard limitations on bandwidth usage for Google Earth/Maps/Moon
services.
Only with iptables/QoS features ? Can be done, but i'm sure it will
not be so efficient and maybe not low-CPU solution as with squid. Of
course you can use string and look for 'kh.google.com' .... but that
would certainly blow your CPUs. You can use layer7, but you would have a
great amount of CPU usage as well.
Sincerily,
Leonardo Rodrigues
Thilo Schulz escreveu:
>On Saturday 13 August 2005 00:38, fabricio bianco abreu wrote:
>
>
>>I would like to block it because a user using Google Earth consumes about
>>256kbps bandwith. I have 600+ users and only a 2Mbps link to the Internet.
>>
>>
>
>I don't see how you would do that without doing a packet inspection for all
>packets directed at www.google.com, as maps.google.com is - as you
>undoubtedly already know - is an alias for www.google.com
>You would have to do packet inspection and filter for maps.google.com. This
>could be easily circumvented by using an SSL capable proxy.
>
>Maybe QoS could do the trick for you. While allowing access to google earth,
>it might discourage that user from excessively using it by restricting his
>bandwidth to something like 64kbit/s while google itself is still perfectly
>usable. It is generally a sensible idea to make use of QoS on a setup like
>yours.
>
>
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Blocking Google Earth
2005-08-13 14:14 ` Leonardo Rodrigues Magalhães
@ 2005-08-13 15:11 ` Thilo Schulz
0 siblings, 0 replies; 11+ messages in thread
From: Thilo Schulz @ 2005-08-13 15:11 UTC (permalink / raw)
To: netfilter
[-- Attachment #1: Type: text/plain, Size: 970 bytes --]
On Saturday 13 August 2005 16:14, Leonardo Rodrigues Magalhães wrote:
> I really dont think it's easy to limit bandwidth usage ONLY for
> Earth Google without making bad experiencies on doing searchs on Google.
> No matter if searches are low-bandwidth. If you get some QoS and band
> limitation on google IPs, be sure that your google earth users will use
> ALL the available bandwidth, thus making google earth as well as google
> serching probably extremely slow.
He only had that problem with one single user. Likewise, he can restrict
bandwidth to google only for that one single user too. Like I already said,
your proxy method can be easily circumvented using something like an SSL
proxy after your proxy, whereas QoS can selectively keep a user from unfairly
exceeding certain bandwidth. This will not only solve problems with the http
protocol, but also problems with the user using too much bandwidth in
general.
--
Thilo Schulz
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: Blocking Google Earth
@ 2005-08-13 19:44 Joris Dobbelsteen
2005-08-15 6:22 ` Jan Engelhardt
0 siblings, 1 reply; 11+ messages in thread
From: Joris Dobbelsteen @ 2005-08-13 19:44 UTC (permalink / raw)
To: netfilter
Other solutions might include:
* Request the user not to use the application.
* Install a HTTP proxy server that catches all port 80 traffic. Squid might be a good candidate. Here you can easily make a policy to deny access to the kh.google.com servers (it was I believe).
An advantage of a proxy is increased response times for your users (and also a little decrease in bandwidth requirements). My experience with 3 users behind it was that response times decreased and bandwidth requirements did not change (noticably). With 600+ users that situation will change significantly.
Some proxies can also limit the priority of some traffic, e.g. for kh.google.com. Unfortunally google.com doesn't allow caching of google earth traffic (sigh), I forced it on my proxy. Yeah, I know, it increases the administrative workload...
Of course, I guess you use a decent machine for routing for 600+ users.
- Joris Dobbelsteen
>-----Original Message-----
>From: netfilter-bounces@lists.netfilter.org
>[mailto:netfilter-bounces@lists.netfilter.org] On Behalf Of
>Thilo Schulz
>Sent: zaterdag, 13 augustus 2005 17:11
>To: netfilter@lists.netfilter.org
>Subject: Re: Blocking Google Earth
>
>On Saturday 13 August 2005 16:14, Leonardo Rodrigues Magalhães wrote:
>> I really dont think it's easy to limit bandwidth usage ONLY for
>> Earth Google without making bad experiencies on doing
>searchs on Google.
>> No matter if searches are low-bandwidth. If you get some QoS
>and band
>> limitation on google IPs, be sure that your google earth users will
>> use ALL the available bandwidth, thus making google earth as well as
>> google serching probably extremely slow.
>
>He only had that problem with one single user. Likewise, he
>can restrict bandwidth to google only for that one single user
>too. Like I already said, your proxy method can be easily
>circumvented using something like an SSL proxy after your
>proxy, whereas QoS can selectively keep a user from unfairly
>exceeding certain bandwidth. This will not only solve problems
>with the http protocol, but also problems with the user using
>too much bandwidth in general.
>
>--
>Thilo Schulz
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Blocking Google Earth
2005-08-13 12:32 ` Jan Engelhardt
@ 2005-08-14 1:15 ` Dwayne Hottinger
0 siblings, 0 replies; 11+ messages in thread
From: Dwayne Hottinger @ 2005-08-14 1:15 UTC (permalink / raw)
To: netfilter
Wouldnt it be easier to just kick the user in the butt?
ddh
Quoting Jan Engelhardt <jengelh@linux01.gwdg.de>:
>
> >> I would like to block it because a user using Google Earth consumes about
> >> 256kbps bandwith. I have 600+ users and only a 2Mbps link to the Internet.
>
> - QoS / egress
> - string/layer7 match with "Host: earth.google.com" or whatever fits
> - Full Transparent proxying using e.g. squid
>
>
> Jan Engelhardt
> --
> | Alphagate Systems, http://alphagate.hopto.org/
>
--
Dwayne Hottinger
Network Administrator
Harrisonburg City Public Schools
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: Blocking Google Earth
2005-08-13 19:44 Joris Dobbelsteen
@ 2005-08-15 6:22 ` Jan Engelhardt
0 siblings, 0 replies; 11+ messages in thread
From: Jan Engelhardt @ 2005-08-15 6:22 UTC (permalink / raw)
To: Joris Dobbelsteen; +Cc: netfilter
>* Request the user not to use the application.
>* Install a HTTP proxy server that catches all port 80 traffic. Squid might be a good candidate. Here you can easily make a policy to deny access to the kh.google.com servers (it was I believe).
Transparently intercept the traffic, mark outgoing squid packets with a value
and reroute them via IMQ / standard Qos ;-) Combines both Hostname-granularity
and speed limit.
Jan Engelhardt
--
| Alphagate Systems, http://alphagate.hopto.org/
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2005-08-15 6:22 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-08-12 20:18 Blocking Google Earth fabricio bianco abreu
2005-08-12 20:29 ` Raphael Jacquot
2005-08-12 22:38 ` fabricio bianco abreu
2005-08-13 2:31 ` Thilo Schulz
2005-08-12 23:59 ` Eric Scopinho
2005-08-13 12:32 ` Jan Engelhardt
2005-08-14 1:15 ` Dwayne Hottinger
2005-08-13 14:14 ` Leonardo Rodrigues Magalhães
2005-08-13 15:11 ` Thilo Schulz
-- strict thread matches above, loose matches on Subject: below --
2005-08-13 19:44 Joris Dobbelsteen
2005-08-15 6:22 ` Jan Engelhardt
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.