Fabian Vilers wrote:
Even if you could do it (you can't right now, as redirectors just rewrite URLs), performance would suck badly,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.
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
