[linux] Verboden Extenties

[LoBbY_1]

Hoi,

Ik zit met een vraag waar ik tot nu toe nog niet een goede oplossing voor heb gevonden. Ik beheer een website waarop mensen gratis hun site's kunnen hosten. Nu wil het geval dat mensen zaken als mp3's en zip files willen plaatsen wat veel bandbreedte kost.

Eerder heb ik dit redelijk goed kunnen oplossen met deze oplossing

code:

find /vhost/usr -depth -iname *.EXTENTIE -exec rm '{}' \;

Deze plaatste ik in een cron. Maar aangezien er meerdere "verboden" extenties zijn zorgde dit voor heel veel IO-activiteit.

Omdat deze code in meer als 25.000 sites moet zoeken op extenties duurde deze operatie erg lang, en zorgde voor een hele hoge load!

Na veel zoeken heb ik nog geen goede oplossing voor dit probleem kunnen vinden. Ik heb gezocht of er misschien een optie voor het ext3-file system was om deze extentie's te kunnen filteren, maar helaas hier ook niets op kunnen vinden.

Als FTP-server gebruik ik Pure-ftpd, deze bied helaas ook geen oplossing voor dit probleem. Extenties filteren met dit ftp-servertje kon ik niet vinden. Helaas is het redelijk lastig te switchen van FTP server aangezien de accounts staan verdeeld over enkele SQL servers.

Heeft misschien iemand een idee om deze extenties goed te kunnen filteren, of zelfs kunnen verbieden?

Alvast bedankt voor de hulp!

[jvhaarst]

Van http://www.pureftpd.org/README :

------------------------ AFTER AN UPLOAD ------------------------


After a successful upload, any external program or shell script can be
spawned with the name of the newly uploaded file as an argument. You can use
that feature to automatically send a mail when a new file arrives. Or you
can pass it to a moderation system, an anti-virus, a MD5 signature generator
or whatever you decide can be done with a file.

To support this, the server has to be configured --with-uploadscript at
compilation time. Upload scripts won't be spawned on unreadable directories.
So it's highly recommended to use upload scripts with the --customerproof
run-time option and without unreadable parent directories.
To tell the FTP server to use upload scripts, it has to be launched with the
'-o' option. Finally, you have to run another daemon called 'pure-uploadscript'
provided by this package.

IMPORTANT:

YOU MUST START PURE-FTPD _FIRST_ and _THEN_ START PURE-UPLOADSCRIPT.
THE REVERSE ORDER WON'T WORK.

For security purposes, the server never launches any external program. It's
why there is a separate daemon, that reads new uploads pushed into a named
pipe by the server. Uploads are processed synchronously and sequencially.
It's why on loaded or untrusted servers, it might be a bad idea to use
pure-uploadscript with lenghty or cpu-intensive scripts.

The easiest way to run pure-uploadscript is 'pure-uploadscript -r <script>':

/usr/local/sbin/pure-uploadscript -r /bin/antivirus.sh

The absolute path of the newly uploaded file is passed as a first argument.
Some environment variables are also filled with interesting values:

- UPLOAD_SIZE : the size of the file, in bytes.
- UPLOAD_PERMS : the permissions, as an octal value.
- UPLOAD_UID : the uid of the owner.
- UPLOAD_GID : the group the file belongs to.
- UPLOAD_USER : the name of the owner.
- UPLOAD_GROUP : the group name the file belongs to.
- UPLOAD_VUSER : the full user name, or the virtual user name. (127 chars max)

There are also some options to "pure-uploadscript":

- '-u <uid>' and '-g <gid>' to switch the account pure-uploadscript will run
as. The script will be spawned with the same identity.

- '-B' to fork in background.

Please have a look at the man page ('man pure-uploadscript') for additional
info.

[ Voor 91% gewijzigd door jvhaarst op 16-01-2006 16:18 ]

[Verwijderd]

Het is misschien een domme vraag maar kan je het probleem niet aanpakken bij de bron? voorkomen dat ze files met bepaalde extensies niet kunnen uploaden? Of is dit technisch niet haalbaar?

[Janoz]

Als het een website is kun je natuurlijk ook gewoon in je browserwebserver aangeven welke bestanden hij wel en welke hij niet mag serveren.

[ Voor 8% gewijzigd door Janoz op 16-01-2006 20:31 ]

[blaataaps]

Kun je niet met behulp van htaccess/httpd.conf het downloaden van die bestanden verbieden, en dan vervolgens een keer per dag de logs van pure-ftpd greppen op de ongewenste bestanden en die dan verwijderen?

[jvhaarst]

Allemaal leuk, maar een extensie zegt niks over de inhoud.....
Je zult dus van ieder bestand kijken wat voor type bestand het is, en aan de hand daarvan actie ondernemen.

[ Voor 47% gewijzigd door jvhaarst op 16-01-2006 16:22 ]

[Verwijderd]

anders beginnen ze gewoon liedje.renamethistomp3 bestanden up te loaden

[LoBbY_1]

jvhaarst schreef op maandag 16 januari 2006 @ 16:20:
Allemaal leuk, maar een extensie zegt niks over de inhoud.....
Je zult dus van ieder bestand kijken wat voor type bestand het is, en aan de hand daarvan actie ondernemen.

Dat klopt helemaal, maar aangezien de meeste mensen deze kennis niet hebben maak ik me daar voorals nog weinig zorgen over. Het mooiste is zeker voorkomen dat de betsanden naar de server worden verstuurt zodat er geen nacontrole nodig is.

Kun je niet met behulp van htaccess/httpd.conf het downloaden van die bestanden verbieden, en dan vervolgens een keer per dag de logs van pure-ftpd greppen op de ongewenste bestanden en die dan verwijderen?

Ik heb inderdaad nog niet naar de mogelijkheid gekeken of er een mannier is om apache deze bestanden te laten blocken. Maar behalve bandbteedte is het ook een kwestie van hd-ruimte. Deze moet ook een beetje in de hand worden gehouden

Als het een website is kun je natuurlijk ook gewoon in je browser aangeven welke bestanden hij wel en welke hij niet mag serveren

Het zijn duizenden bezoekers per uur die allemaal verschillende browsers gebruiken, en tevens worden de site's gemaakt door de gebruikers zelf waardoor je weinig/geen contole hebt over hun eigen script's.

@jvhaarst
Dit lijkt een redelijke oplossing, ik zal kijken of deze te implementeren is:)

[blaataaps]

LoBbY_1 schreef op maandag 16 januari 2006 @ 17:32:


[...]


Ik heb inderdaad nog niet naar de mogelijkheid gekeken of er een mannier is om apache deze bestanden te laten blocken. Maar behalve bandbteedte is het ook een kwestie van hd-ruimte. Deze moet ook een beetje in de hand worden gehouden


[...]

Klopt, maar zolang je periodiek de pure-ftpd logs doorsnuffelt (zo vaak als nodig blijkt, en dat is een stuk minder zwaar dan find) is het niet erg als ze er staan, en men ze toch niet kan downloaden. Daarmee zorg je dat je /moet/ zoeken en deleten op het moment dat het jou uitkomt (voordat je schijf vol is), en niet als al bandbreedte geslurpt is waar je niet op zat te wachten.
Welke oplossing je ook doet, zolang je periodiek gaat deleten blijft het tegenhouden via apache de moeite waard volgens mij.
Waar je ook naar zou kunnen kijken is de "upload-script" optie van pure-ftpd, dit wordt bij elke upload aangeroepen, daar zou je een check op filename kunnen maken, en zelfs op inhoud, en dan op basis van je eisen het verse bestand gelijk kunnen deleten.

[Gertjan]

LoBbY_1 schreef op maandag 16 januari 2006 @ 16:00:
Helaas is het redelijk lastig te switchen van FTP server aangezien de accounts staan verdeeld over enkele SQL servers.

Proftpd heeft een configuratieoptie waarmee je op extensies kan filteren. Ook kan proftpd gewoon users authenticeren vanuit een database, dus een overstap is zeker mogelijk. De hoeveelheid werk om over te stappen, versus de hoeveelheid werk om de upload zelf te filteren op wat voor manier dan ook mag je zelf maken

[croontje]

Waarom niet gewoon een maximum bestandsgrootte instellen van bv 1 of 2 MB per file? Een liedje van minder dan 1 of 2 MB is toch te slechte kwaliteit. En wie gaat er nu een file van 100 MB rarren naar bestandjes van 2 MB???

[LoBbY_1]

Waarom niet gewoon een maximum bestandsgrootte instellen van bv 1 of 2 MB per file? Een liedje van minder dan 1 of 2 MB is toch te slechte kwaliteit. En wie gaat er nu een file van 100 MB rarren naar bestandjes van 2 MB???

dit gebeurt regelmatig Een limiet voor de groote van een bestand weerhoud mensen er niet van om alsnog populaire software te distributeren.

@Gertjan
Ik kijken of dit makkelijk is te doen:) Eerst moeten we een goede testomgeving hebben voordat we zulke stappen gaan ondernemen.

Waar je ook naar zou kunnen kijken is de "upload-script" optie van pure-ftpd, dit wordt bij elke upload aangeroepen, daar zou je een check op filename kunnen maken, en zelfs op inhoud, en dan op basis van je eisen het verse bestand gelijk kunnen deleten.

Dit lijkt mij de alles beste oplossing die ook op korte termijn te realiseren is. Een filter is opzich redelijk snel geschreven.

[terrapin]

Dus mensen gaan wel bestanden in hele kleine stukjes hakken om een beveiliging te omzeilen, maar zijn te lui om de extensie te veranderen? Het lijkt mij toch echt eerder andersom..
Het is trouwens werkelijk triviaal om in Apache bepaalde bestanden te blokkeren, zoals mensen hierboven al hebben gezegd.

[ Voor 26% gewijzigd door terrapin op 16-01-2006 21:25 ]

[LoBbY_1]

Ik ben wat wezen spelen met de tip van Jvhaarst en dit lijkt aardig leuk te werken:) Ik heb snel in C een programmatje geschreven om te testen of dit ook echt zo mooi werkt als word aangegeven, en het lijkt tamelijk goed te werken in de paar testjes die ik heb gedaan. De ondetstaande code is tamelijk lelijk, en word zeker nog aangepast, maar geeft wel aan dat het werkt

Iedereen bedankt voor de tips!

code:

//dit programma kijkt of een extentie verboden is

#include <iostream>
#include <iomanip>
#include <fstream>
#include <time.h>

using namespace std;

void writeLog(string message, char fileLocation[])
{
    //kijk of log bestaat.

    ofstream logFile;
    time_t logTime; 

    //Probeer log te openen
    logFile.open("removedFiles.log", ios::app);
    if(logFile.fail())
    {
      cout << "Log kon niet worden geopend, sluit programma!\n";    
      exit(2);
    }
    
    //Schrijf log
        time(&logTime); 
    logFile << ctime(&logTime)  << message << " : " << fileLocation << "\n";

    //sluit log
    logFile.close();
}

void fileExist(char file[])
{
    //Probeer bestand te openen, anders programma eindigen
    //var
    fstream filecheck;

    //Kijk of bestand ook echt bestaat
    filecheck.open(file);
    if(filecheck.fail())
    {
     //Bestand kon niet worden gevonden
     writeLog("Bestand kon niet worden gevonden : ", file);
     exit(1);
    }
    filecheck.close();
}

void removeFile(char fileName[])
{
   unlink(fileName);
   writeLog("Bestand verwijderd!!\n\n","");
}

void allowedExtention(string fileName, char fileLocation[])
{
    //kijken naar de extentie
    int    length    = fileName.size() -4;
    string extention =  fileName.substr(length, 4);


    if(extention == ".exe" || extention == ".zip" || extention == ".avi" || extention == ".mpg" || extention == ".wav" || extention == ".mp3" || extention == ".mp4" || extention == ".ram" || extention == ".rm" || extention == ".tar" || extention == ".rar" || extention == ".wmv" || extention == ".wma" || extention == ".mov" || extention == "mpeg" || extention == "tar.gz" || extention == ".tar" || extention == ".asx" || extention == ".asf" || extention == "part" || extention == "list" || extention == "stem" || extention == ".ram" || extention == ".ogg" || extention == ".scr")
    {
        cout << "Illegale extentie gevonden, bestand word verweiderd : " << fileName << "\n";
        
        //Schrijf naar log
        writeLog("Illegale extentie gevonden, bestand word verweiderd", fileLocation);
        //verweider file
        removeFile(fileLocation);
    }else{
        return;
    }
}

int main(int argc, char *argv[])
{
    //kijk of het bestand bestaat
    fileExist(argv[1]); 
    allowedExtention(argv[1], argv[1]);
}

[ Voor 38% gewijzigd door LoBbY_1 op 17-01-2006 00:01 ]

[Tha_Butcha]

mm, je zegt dat je een vrij populaire site hebt, met enkele duizende gebruikers. Ik zou dan behoorlijk zenuwachtig worden om dan een FTP server neer te pleuren, tenzij ik voor ISP wil spelen.

Ik zou gaan voor de optie die al eerder genoemd is, dat pure-ftpd uploadscript dingie gebruiken.\
en anders ff een uploader scripten in php ofzo, en alleen zo gebruikers laten uppen, en dan daar een filecheck in bouwen.

[LoBbY_1]

mm, je zegt dat je een vrij populaire site hebt, met enkele duizende gebruikers. Ik zou dan behoorlijk zenuwachtig worden om dan een FTP server neer te pleuren, tenzij ik voor ISP wil spelen.

Dat klopt, ik speel ook voor isp:) Dit is een uit de hand gelopen hobby, maar wel leuk om te doen.

[Verwijderd]

Misschien begrijp ik het probleem niet, maar als je dat soort mogelijkheden aanbiedt als ISP heb je toch een max aan dataverkeer dat een website mag genereren? Ik neem aan dat je dat ook meet. Zijn ze over hun datalimiet gewoon die website op zwart zetten.

Moet je dat natuurlijk wel vermelden in je voorwaarden...

[LoBbY_1]

Verwijderd schreef op dinsdag 17 januari 2006 @ 00:10:
Misschien begrijp ik het probleem niet, maar als je dat soort mogelijkheden aanbiedt als ISP heb je toch een max aan dataverkeer dat een website mag genereren? Ik neem aan dat je dat ook meet. Zijn ze over hun datalimiet gewoon die website op zwart zetten.

Moet je dat natuurlijk wel vermelden in je voorwaarden...

Dit klopt wel, maar aangezien sommige gebruikers maar 10 MB per maand aan verkeer genereren, en sommige meer is er voor gekozen om geen data-limiet te handhaven en om een soort van "fair use policy" te gebruiken Als volgens logs blijkt dat site's echt tientallen gigabyte's verbruiken dan worden deze ook wel aangesproken op hun verbruik. Verder konden we ook geen goed bandbreedte beheer vinden voor apache 2. Gebruikes met een gratis account kunnen op deze mannier doen wat ze willen met hun ruimte met als nadeel dat er word gefilterd op extenties. Verder word er ook geen garantie van uptime gegeven op de server met de gratis website's. Op de andere servers wel, en is het filteren van extentie's ook niet nodig.

[RagaBaSH]

LoBbY_1 schreef op maandag 16 januari 2006 @ 23:54:

[...]

code:

[...]
    
    cout << "Illegale extentie gevonden, bestand word verweiderd : " << fileName << "\n";

[...]

"verweiderd"?

* RagaBaSH mompelt iets over missende spellcheckers in notepad

[LoBbY_1]

Haha, je hebt gelijk Alleen voor VIM heb ik nog geen spellingschecker kunnen vinden. Als deze bestaan dan hoor ik hier graag meer over Ik gebruik beina nooit notepad.

[Sprite_tm]

Misschien is het makkelijker om het programma 'file' eroverheen los te laten?

code:

jeroen@laptop:/tmp$ file "02 - Dire Straits - Walk of life.mp3"         
02 - Dire Straits - Walk of life.mp3: MPEG ADTS, layer III, v1, 128 kBits, 44.1 kHz, JntStereo
jeroen@laptop:/tmp$ mv "02 - Dire Straits - Walk of life.mp3" "Dit is echt geen mp3tje hoor.jpg"
jeroen@laptop:/tmp$ file "Dit is echt geen mp3tje hoor.jpg" 
Dit is echt geen mp3tje hoor.jpg: MPEG ADTS, layer III, v1, 128 kBits, 44.1 kHz, JntStereo
jeroen@laptop:/tmp$

[psyBSD]

LoBbY_1 schreef op dinsdag 17 januari 2006 @ 11:47:
Haha, je hebt gelijk Alleen voor VIM heb ik nog geen spellingschecker kunnen vinden. Als deze bestaan dan hoor ik hier graag meer over Ik gebruik beina nooit notepad.

Aspell en vim aspell plugin.

edit:

Als je actief gebruik maakt van auto-completion (met bijvoorbeeld de supertab extentie, anders Ctrl-N)
Dan worden de woorden automatisch afgemaakt opbasis van de aspell dictionary.

[ Voor 25% gewijzigd door psyBSD op 17-01-2006 11:58 ]

[rulus]

beina

[Gertjan]

Je hebt het nu de hele tijd ever het blokkeren/verwijderen/whatever van bestanden op basis van extensies. De manier die Sprite_tm aandraagt is dan al iets nauwkeuriger, maar het blijft beperkt tot bepaalde types. Als je eerst eens analyseert waar het je nu echt om gaat: het besparen van traffic. Waardoor wordt veel traffic veroorzaakt: door grote bestanden, en niet specifiek door mp3- of zipbestanden. Wat je volgens mij dus veel beter kunt doen, is een limiet stellen aan de bestandsgrootte. Afbeeldingen die op het web gebruikt worden, zijn meestal niet groter dan 1 MB, dus stel hier bijvoorbeeld de limiet op in.
In veel gevallen (ftp-server, file-upload script) kun je dan al afvangen dat het bestand uberhaupt op de server komt. Eventueel kun je met behulp van de upload-script-optie van pure-ftpd nog je eigen checks op bestandsgrootte doen als je dat nodig vindt.

/edit

RagaBaSH schreef op dinsdag 17 januari 2006 @ 09:07:
[...]

"verweiderd"?

* RagaBaSH mompelt iets over missende spellcheckers in notepad

* Gertjan mompelt iets over de droefheid van het feit dat mensen spellcheckers nodig hebben om geen grammaticale of spellingsfouten te maken...

[ Voor 19% gewijzigd door Gertjan op 17-01-2006 12:21 ]

[RagaBaSH]

Als ik kijk naar de lijst met extenties die je wil blokken ben je bijna alles behalve een "persoonlijke" website aan het blokken.
Bovendien als iemand echt wil, kan hij/zij er ook wel omheen (7zip, WinAce, andere WinRAR extentie).
Kan je niet beter gewoon een wat strakker regime gaan hanteren op basis van het algemene verkeer (200x 50kb plaatjes op 1 pagina is ook veel traffic zeg maar).
Gewoon een host platgooien als hij meer dan ##MB per uur of dagdeel oid doet. (zoals geocities).
Dan kan je makkelijk claimen dat alles in principe mag, maar dat je het recht voorbehoud ten behoeve van de kwaliteit van de service een "groot-gebruiker" tijdelijk te blokkeren. Met dergelijk beleid gaan mensen vanzelf wel nadenken of ze nu echt die mp3 bij jou willen hosten of dat ze daar een "extra traffic" pakket voor willen nemen.

[r0b]

/me gooit idee naar binnen

Of met een whitelist werken ipv een blacklist?
Het blocken op filesize lijkt mij niet wenselijk, vooral niet met de super-duper Trust camera's van tegenwoordig die ook al een JPEG van 2mb durven te genereren per foto. Of een *.psd bestand (Photoshop data) die een gebruiker even wil delen met een kennis. etc.

PureFTPd werkt ook met MySQL, ik weet alleen niet of beide FTPd's onderlijn zo uitwisselbaar zijn. Of dat je met een paar kleine aanpassingen al klaar bent.

[Tha_Butcha]

als we dan toch gaan zeiken over spelling: het is extensie
maar ja, de meeste tweakers hier kunnen toch niet fatsoenlijk spellen onder het mom van "dyslexie" (wel typerend dat ze dat wel altijd wel goed kunnen spellen)

anyways, OT:

ik weet niet hoe het nu met de apache 2.0 zit, maar voor zover ik weet draaien de grote jongens de 1.3 serie, of loop ik nou achter??? Want daar heb je wel mod_throttle voor..

[Gertjan]

r0b schreef op dinsdag 17 januari 2006 @ 13:56:
Het blocken op filesize lijkt mij niet wenselijk, vooral niet met de super-duper Trust camera's van tegenwoordig die ook al een JPEG van 2mb durven te genereren per foto. Of een *.psd bestand (Photoshop data) die een gebruiker even wil delen met een kennis. etc.

Het gaat de TS om het beperken van de traffic die een gebruiker genereert. Dat lijkt me maar op 1 manier kunnen: door grote bestanden te blokkeren. Of het nu een mp3-bestand van 2MB is of een foto van 2 MB, feit blijft dat er elke keer 2MB+overhead aan traffic verstookt zal worden als er iets gedownload wordt. Daarnaast denk ik niet dat een foto van 2MB zo geschikt is om in een website te gebruiken en daarom vaak verkleind zal worden. Misschien moet de grens wel op 2MB worden gelegd hoor, daar durf ik geen uitspraken over te doen.
Feit blijft dat ik het filteren op extensies gewoon een beperkte en slecht uitbreidbare oplossing vind, en dat de echte oplossing volgens mij in de grootte van de bestanden zit.

[LoBbY_1]

Over het blokkeren van grote bestanden werd ook wel nagedacht. Toch zijn veelal polulaire bestanden zaken zoals nieuwe mp3's of programmatje's. Als voorbeeld, er is in de meuktracker ooit eens een verwijzing geweest naar een zip op een van onze servers. Dit genereerd veel sneller traffic als een foto, veel mensen zitten niet te wachten op super grote foto's op internet.

ik weet niet hoe het nu met de apache 2.0 zit, maar voor zover ik weet draaien de grote jongens de 1.3 serie, of loop ik nou achter??? Want daar heb je wel mod_throttle voor..

Dat klopt, en dit is zeker nog iets om te testen!

de meeste tweakers hier kunnen toch niet fatsoenlijk spellen onder het mom van "dyslexie"

Je raadt het nooit, offtopic(toch wel jammer dat mensen die hier wel echt last van hebben over dezelfde kam worden geschoren.)

Misschien is het makkelijker om het programma 'file' eroverheen los te laten

Van het bestaan van dit programma wist ik niets af, maar het is zeker de moeite waard om dit te gaan gebruiken!

Gewoon een host platgooien als hij meer dan ##MB per uur of dagdeel oid doet. (zoals geocities).

Dit is zeker een van de mooiste oplissingen!! Ik zal eens kijken hoe ze dit realiseren!
Bedankt voor de vele reacties! Dit heeft tot nu toe heel goed geholpen!

[ Voor 3% gewijzigd door LoBbY_1 op 17-01-2006 19:19 ]

[Gertjan]

LoBbY_1 schreef op dinsdag 17 januari 2006 @ 19:19:
Over het blokkeren van grote bestanden werd ook wel nagedacht. Toch zijn veelal polulaire bestanden zaken zoals nieuwe mp3's of programmatje's. Als voorbeeld, er is in de meuktracker ooit eens een verwijzing geweest naar een zip op een van onze servers. Dit genereerd veel sneller traffic als een foto, veel mensen zitten niet te wachten op super grote foto's op internet.

Wat ik probeer te zeggen is dat "grote bestanden" maar 1 gemeenschappelijke eigenschap hebben, en dat is de bestandsgrootte. Je noemt nu het voorbeeld van een zip-bestand dat in de meuktracker stond en dat te veel traffic genereerde. Dus, wil je zip-bestanden afschermen. Maar stel dat er volgende week ineens een link naar installer staat die op exe eindigt. Dan moet jij je script weer aanpassen. De week erop verschijnt er ineens een link naar een rar, tar, tar.gz, deb, of rpm-bestand. Het is gewoon erg moeilijk, en IMO kortzichtig, om dit op basis van extensie te gaan oplossen.

[Verwijderd]

Kan je niet beter dit doen? In plaats van die lange boolean.

_{if(extention != ".html")}

En zoals Sprite_TM als zei. Kan je ook "file" gebruiken om de file type vast te stellen.


_{kevin@sneezy:/home/www$ file index.html
index.html: HTML document text}

Dit zou je dan weer eventueel in een var kunnen zetten om naderhand weer te vergelijken.