post_max_size en veiligheid

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Ozzie PHP

Ozzie PHP

02/06/2016 15:12:32
Quote Anchor link
Ik wil een goede waarde instellen voor 'post_max_size' en 'upload_max_filesize'. Nu lees ik op veel sites dat een te grote 'post_max_size' het risico op DDoS-aanvallen vergroot, omdat een hacker je site kan overspoelen met enorme ladingen post data.

Echter, ik kan nergens terugvinden wat dan wél een 'veilige' waarde is voor 'post_max_size'. Ik zie situaties waarin mensen deze waarde letterlijk instellen op 1 of 2 Gigabyte, maar ik zie op andere websites al waarschuwingen voor DDoS-aanavallen voorbij komen als post_max_size op 30 mb wordt ingesteld.

Weet iemand wanneer dit daadwerkelijk een issue wordt? Vanaf welke bestandsgrootte je je website inderdaad ontvankelijk maakt voor DDoS-aanvallen als gevolg van overvloedige post data?
Gewijzigd op 11/06/2016 18:08:07 door Bas IJzelendoorn
 
PHP hulp

PHP hulp

25/04/2024 15:30:17
 
Thomas van den Heuvel

Thomas van den Heuvel

02/06/2016 15:38:18
Quote Anchor link
Weer zo'n vraag die niet echt op voorhand beantwoord kan worden.

Hangt van de applicatie af? Wie weet wat de omvang is van de documenten waarmee je werkt?

Wellicht wil je dit ook op een andere plek oplossen (afschermen met login?), zodat niet jan en alleman van alles kan uploaden.

Is dit net zoiets vragen als "Hoe kan ik mij weren tegen een DDoS aanval". Niet? Nauwelijks? Met veel geld?

Ik zie "op veel sites" "situaties waarin mensen" en "andere websites" enzo. Link eens wat bronnen zodat we deze stellingen wat meer op waarde kunnen schatten.
 
Ozzie PHP

Ozzie PHP

02/06/2016 16:11:28
Quote Anchor link
>> Hangt van de applicatie af? Wie weet wat de omvang is van de documenten waarmee je werkt?

Nee, vanuit die insteek stel ik mijn vraag niet. Ik stel de vraag enkel vanuit veiligheids-oogpunt en in algemene zin, dus niet applicatie-gericht.

Correct me if I'm wrong ... wellicht weet Ben van Velzen dit ... maar volgens mij kun je (als buitenstaander/hacker) naar iedere pagina van een website posten via een extern formulier. Hiermee belast je dus de server via een zogenaamde 'flood attack'. De server stroomt dan als het ware over. Althans dat is wat ik er van begrijp. Dus stel je post_max_size staat op 300 mb, dan kan een hacker bestanden naar je server posten van 300 mb waarmee ie jouw server lam legt.

Mijn vraag is dus of dit iets is waar je rekening mee moet houden. Ik hoef geen bestanden van 100'en mb's te kunnen uploaden. Maar stel ik mezelf bijv. aan een risico bloot door post_max_size op bijv. 30mb te zetten? Of speelt dit verhaal pas vanaf bijv. 100mb?

Wellicht weet Ben hier meer over te vertellen aangezien hij gespecialiseerd is op het gebied van systeembeheer.
 
Thomas van den Heuvel

Thomas van den Heuvel

02/06/2016 17:07:59
Quote Anchor link
post_max_size kun je aanpassen al naar gelang de situatie.

Ok.

Ik ga ook niet meer reageren op dit soort vragen, vraag het maar aan Uncle Ben.

Enne, je zou kunnen overwegen om je vragenspurt te bundelen in een soort van artikel of blog, zodat je ook eens wat teruggeeft aan phphulp.
 
Ben van Velzen

Ben van Velzen

02/06/2016 17:09:50
Quote Anchor link
Ik ga het je nog veel sterker vertellen: ongeacht de instelling van post_max_size kun je gigantische bakken data naar de server sturen, dit wordt pas gecontroleerd nadat de data binnen is. Sterker nog, je kunt ongeacht de geldigheid van de URL altijd gewoon roepen POST en een bak data doorsturen (ook bij 404). Dit zul je dus in je Apache configuratie moeten aanpakken, PHP staat hier feitelijk buiten. Zeker als hij als FastCGI draait. De instelling in PHP is bedoeld om het geheugengebruik in de hand te houden. De data moet immers een buffer in, en je zult bij een upload van 300MB dus minstens 300MB aan RAM (tijdelijk) kwijt zijn aan de POST.

Toevoeging op 02/06/2016 17:10:23:

>> Enne, je zou kunnen overwegen om je vragenspurt te bundelen in een soort van artikel of blog, zodat je ook eens wat teruggeeft aan phphulp.

Leuk idee!
Gewijzigd op 02/06/2016 17:12:38 door Ben van Velzen
 
Ozzie PHP

Ozzie PHP

02/06/2016 17:21:03
Quote Anchor link
@Thomas

>> post_max_size kun je aanpassen al naar gelang de situatie.

Ja, je kunt alles aanpassen naar gelang de situatie, maar daar gaat mijn vraag helemaal niet over.

>> Ik ga ook niet meer reageren op dit soort vragen, vraag het maar aan Uncle Ben.

Je bent gelukkig tot niks verplicht, dus als je geen zin hebt om te antwoorden dan zou ik dat ook zeker niet doen.

>> ... zodat je ook eens wat teruggeeft aan phphulp.

Jammerlijke opmerking ... ga er verder maar niet op in.

@Ben

>> Sterker nog, je kunt ongeacht de geldigheid van de URL altijd gewoon roepen POST en een bak data doorsturen.

Oké ... wat ik dus begreep is dat als je dus de post_max_size op bijv. 5 mb zet en iemand post vervolgens 10 MB, dat deze post data dan überhaupt niet aankomt / wordt verwerkt (?) ... waarmee je dus een DDoS-aanval kunt voorkomen.

Klopt deze info naar jij weet? Ik wil bijv. niet een post_max_size van 30 mb instellen en vervolgens ineens zo'n aanval over me heen krijgen waardoor m'n server er een aantal uren uitligt.

>> Dit zul je dus in je Apache configuratie moeten aanpakken

Heb je een hint welke setting ik daarvoor kan gebruiken?
 
Ben van Velzen

Ben van Velzen

02/06/2016 17:27:57
Quote Anchor link
>> Oké ... wat ik dus begreep is dat als je dus de post_max_size op bijv. 5 mb zet en iemand post vervolgens 10 MB, dat deze post data dan überhaupt niet aankomt / wordt verwerkt (?) ... waarmee je dus een DDoS-aanval kunt voorkomen.

Het zal eerst aankomen, en dan worden gecontroleerd. Dit is technisch niet anders mogelijk.

>> Heb je een hint welke setting ik daarvoor kan gebruiken?
LimitRequestBody, en deze staat standaard op 0, dus onbeperkt. Dat had google je uiteraard ook wel kunnen vertellen ;-)
 
Ozzie PHP

Ozzie PHP

02/06/2016 17:42:15
Quote Anchor link
>> Het zal eerst aankomen, en dan worden gecontroleerd. Dit is technisch niet anders mogelijk.

Vreemd. Dan vraag ik me af waarom overal wordt gewaarschuwd dat je post_max_size niet te hoog moet instellen ivm DDos-aanvallen, als zoals jij zegt het dan blijkbaar toch helemaal niks uitmaakt.

Google kan me overigens een heleboel vertellen, moet je alleen wel eerst weten waar je het moet zoeken.

Maar goed, ik krijg steeds vaker de indruk dat mijn vragen me blijkbaar niet in dank worden afgenomen, dus ik zal voortaan maar wat minder vragen gaan stellen denk ik. Ik krijg ook de indruk dat er enkele leden zijn die daarbij hun focus specifiek op mij richten. Wellicht moet ik tzt dit forum maar verlaten als mijn aanwezigheid niet meer op prijs wordt gesteld. Het doel van een forum is om vragen te kunnen stellen en je kennis te verbreden. Jammer dat sommige leden dan vinden dat je te veel of te specifiek vraagt. Volgens mij verplicht ik helemaal niemand tot antwoorden.
 
Ben van Velzen

Ben van Velzen

02/06/2016 17:46:46
Quote Anchor link
Je moet het niet te hoog instellen ivm het geheugengebruik, je server door zijn geheugen heen laten fietsen is immers veel effectiever dan welke andere methode dan ook.

Het is niet zozeer zo dat vragen niet in dank worden afgenomen, maar de vragen zijn vaak subjectief: er is vaak geen beste manier van beveiligen of een betere manier van instellen van je webserver of wat dan ook. Er zijn veel wegen die naar Rome leiden, en zelden is er een beste manier. Veel waarschuwingen die je online tegenkomt zijn van papegaaien die zelf geen flauw benul hebben waar de zogenaamde risico's vandaan komen. Het is soms lastig om deze onzin te scheiden van feiten.
Gewijzigd op 02/06/2016 17:48:04 door Ben van Velzen
 
Ozzie PHP

Ozzie PHP

02/06/2016 18:24:13
Quote Anchor link
>> Je moet het niet te hoog instellen ivm het geheugengebruik ...

Ik begreep dat daar nu juist weer memory_limit om de hoek komt kijken.

Check bijv. eens deze pagina: https://h5p.org/installation/configure-php

Quote:
Now before you go wild with these settings you should keep in mind that increasing them will make you more vulnerable to vicious Denial of Service attacks

Dit gaat dus over upload_max_filesize en post_max_size. En ik kom diezelfde opmerkingen over DDoS-aanvallen op meerdere websites tegen. Lijkt me dus niet echt een vorm van 'papegaaien'. Dit lijkt dus niet helemaal overeen te stemmen met jouw eerdere verklaring dat die settings niets met DDoS-aanvallen te maken kunnen hebben.

>> Het is niet zozeer zo dat vragen niet in dank worden afgenomen, maar de vragen zijn vaak subjectief

Nee, ik probeer ze juist zo algemeen mogelijk te maken (lees maar eens terug), alleen proberen sommigen er dan ineens iets specifieks of applicatie-afhankelijks van te maken, terwijl dat nergens in mijn vraag terugkomt. Dat doe ik dus niet zelf, maar dat gebeurt door anderen. Daarnaast is het ook 'le ton qui fait la musique'. Je kunt ook op een normale manier communiceren zonder onnodige steken onderwater, gewoon netjes met elkaar omgaan. Is toch niet zoveel gevraagd lijkt mij? Ik heb geen zin om me hier door iemand in de zeik te laten zetten, en ik denk dat dat voor de meesten van ons geldt.
 
Ben van Velzen

Ben van Velzen

02/06/2016 18:36:01
Quote Anchor link
Wat daar staat klopt wel, maar de reden klopt niet. Even uittekenen:
post_max_size heeft te maken met geheugengebruik, wanneer een te grote POST wordt gestuurd (liefst zo vaak mogelijk naast elkaar) kun je snel een server lam leggen.
upload_max_filesize geeft aan welk deel van de post_max_size gebruikt kan worden voor file uploads. Uploads kunnen snel tot vollopen van de schijf leiden, en daarmee een DOS veroorzaken.
memory_limit is de limiet die gesteld wordt nadat de data binnen is, wanneer je een post_max_size hebt van 300MB en een memory_limit van 500MB kun je dus maximaal 800MB verbruiken. Minimaal dat, want je hebt ook je request overhead nog die niet meegeteld wordt.
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.