Re: [squid-users] Content filtering, this could be an idea

Fabian Vilers wrote:

>I'm back with my content filtering problem. At this time, Squid is not
>smart enough to see that a renamed valid mp3 file to test.txt is still a
>n audio file. I don't want my users to download these kind of files.
>
>It seems that there is no workaround with existing redirectors so let's
>write one. But I don't know anything about squid's working for now. I'm
>just wondering if it feasable.
>
>Imagine that Squid downloads the bad file but before giving it to the
>user who initiate the donwload, it checks it with the "file -bi <file>",
>if it's a mp3 file will return audio/mpeg. If this matches a denied
>regexp, don't give the file to the user.
>
>
Even if you could do it (you can't right now, as redirectors just
rewrite URLs), performance would suck badly,
and cunning users could hack around the problem by disgusing the content
with enough stuff at the beginning to
confuse 'file' or mod_mime_magic or whatever.

There's no way you can completely prevent cunning users with complicit
site admins from transfering content through your proxy - this is really
a social engineering problem, and as such, it depends on why you want to
prevent people from doing that, and what the consequences are if they do.

The best policy I think would be to do some basic blocking of audio and
video serving sites, eg by using Squidguard and their audio and video
blacklists, block the video and audio mimetypes, and place either an
upper limit on file size downloads, or place large file downloads into a
slow delay pool. Then, assuming you're using proxy authentication or
ident, you can track down the users who tried to access those content
types and given them a warning, dump them into a savagely delayed dog
box category, or just pull their proxy access privilages.

That won't defeat users who have complicit site admins, but you can spot
the large downloads, or series of small, sequential downloads of the
same file in the logs and catch them too.

HTH,
John
Received on Thu Dec 09 2004 - 17:32:38 MST