Block google page cache at firewall?

block search?q=cache: E.

iptables -A FORWARD -j DROP -p tcp -m string --string "search?q=cache:"

http://66.249.93.104/search?q=%63ache:nBfHGlVAkfMJ:

Yours, VB.

In the case of blocking obfuscated strings such as hexadecimal representations; use the L7 filter. It may be easier and more efficient to mark the http traffic and then jump to a regular expression target to match against.

Something such as:

\\x[:printxdigit:][:printxdigit:]([:printxdigit:])?

This should match against \\xNN where N is a hexadecimal character; as well as \\xNNN. That is --- if my regex skill aren't too rusty. ;)

You mean %, not \\x, because this is an URL?

One has to be clever to find out all possible combinations for only blocking google cache:

http://66.249.93.104/search?q=%20cache:nBfHGlVAkfMJ:

Yours, VB.

Actually, the regex engine does utilize the "\\x" string to identify a wide hexadecimal character representation by concatentating the "\\x" string with up to three hexadecimal digits. Depending on representation value only two digits may be utilized. Hence that is why the final digit specification is set as optional.

Here's the faq on the regex specific extensions:

Very true. That is why i think it is best to set a user-defined chain for only the regex rules.

Well, then you still just identified the char that does NOT show up in the URL because it is escaped using URI escaping (with % syntax).

Then you'll have no match because I'm using URL escapes with %.

Yours, VB.

There are numerous representations --- notice i state representations

--- of a hexadecimal character. All depending on the utilization and/or architecture.

i.e. 0xCD, 100Fh, %20 etc ...

Because L7 is an application level filter. All these representations can be evaluated against. A URl is not exclusive to the hexdecimal numbering system.

In the prevous examples these hexadecimal characters are denoted by a designation digit(s).

i.e. 0x, h, %

Because these designation digits are not part of the hex character --- they are simply there to denote to an object(person or applicaiton) that the character is hexdecimally encoded. It points to the following digits as a hex character. It neither adds or removes any value to the encoded byte.

It is up to the end-user to explicitly declare a particular designation digit for evaluation. That is why I refrained from explicitly type-setting the "%" digit as a hexadecimal requirement.

I am not sure if it holds true for every location (cause they can do some Geo-targeted load sharing), but my Google cache always gets served from IP address 72.14.203.104 it is pretty consistent, so I think even if your G cache serves from different IP, it should be a pretty stable IP address (keep checking on it like once in two weeks or so though). Just block any traffice from that IP. Well, it happens to be one of Google's datacenters so every once in a while someone won't get their search results ;-)

By the way, this sounds like you are working for a school and trying to deal with smart kids ;-). I just wanted to point out that the kids are real smart these days and nothing prevents them from using (in addition to Google cache) English-to-English translation of the page using Google, Altavista or any other translation services there are out there. It could even be any language to any other language if all they're interested in is the universal language of human body's photographic representation ;-)

Good luck!

-------------------------------------

##-----------------------------------------------## Delivered via