Heb je Shared Hosting en ben je bezorgd over de beveiliging? Dit is wat u moet weten

Gedeelde hosting. Het is de goedkope optie, is het niet? En voor een groot deel van de bevolking is dit alles wat ze nodig hebben om hun website of webtoepassing te hosten. En wanneer het goed wordt gedaan, is shared hosting schaalbaar, snel en veilig.

Maar wat gebeurt er als het niet goed wordt gedaan?

Welnu, dat is het moment waarop gevaarlijke beveiligingsproblemen beginnen in te kruipen. Dat is het moment waarop uw site het risico loopt beschadigd te worden of de privégegevens die u in uw bezit heeft, worden gelekt. Maar maak je geen zorgen. De overgrote meerderheid van webhosts beschikken over behoorlijke beveiligingsmaatregelen. Het zijn slechts de fly-by-night, koopjes-kelder hosts waar je op moet letten.

We raden de gedeelde hosting van InMotion Hosting aan met SSD-opslag.

We gaan de beveiligingsproblemen rond shared hosting onderzoeken. Maar laten we eerst eens kijken naar wat een gedeeld hostingplatform veilig maakt.

Wat zorgt voor een veilige webhost

Er zijn enkele opvallende beveiligingsoverwegingen die moeten worden gemaakt met betrekking tot gedeelde hosting.

• Elke gebruiker op de server moet worden geïsoleerd van andere gebruikers en moet de bestanden van andere gebruikers niet kunnen openen of wijzigen.
• Een beveiligingsprobleem in de logica van een website die op de server wordt gehost, mag geen invloed hebben op andere gebruikers.
• De server wordt regelmatig gepatcht, bijgewerkt en gecontroleerd om architecturale beveiligingsproblemen aan te pakken.
• Elke gebruiker moet zijn eigen geïsoleerde databasetoegang hebben en mag geen toestemming krijgen om wijzigingen aan te brengen in de opgeslagen records of tabelrechten van andere gebruikers.

Nogmaals, de meeste webhosts voldoen aan deze vereisten voor hun gedeelde aanbod. Maar als u op zoek bent naar het hosten van meerdere websites op één server, of benieuwd bent naar hoe uw hostingbedrijf het doet, of denkt u erover om uw eigen hostingbedrijf te lanceren en wilt u graag weten hoe u uw gebruikers kunt beveiligen, lees dan op.

Maar eerst, een disclaimer

Voordat we ons gaan bezighouden met het kijken naar gemeenschappelijke aanvallen op shared hosting, wil ik alleen maar zeggen dat dit bericht niet (en mag niet worden gelezen als) een uitputtende lijst van potentiële beveiligingsproblemen is.

Beveiliging is in één woord groot. Er zijn veel manieren waarop u een site kunt beschadigen. Dit wordt dubbel voor shared hosting. Het was nooit op hen om hen in één artikel te verslaan.

Als je paranoïde bent over je beveiliging, koop dan een VPS of een dedicated server. Dit zijn omgevingen waarin je (voor het grootste deel) absolute controle hebt over wat er gebeurt. Als je niet zeker bent over de verschillende soorten webhosting, bekijk dan dit bericht De verschillende vormen van Website Hosting Explained [Technologie verklaard] De verschillende vormen van Website Hosting Explained [Technologie verklaard] Lees meer van mijn collega, James Bruce.

Ik wil ook benadrukken dat dit bericht niet moet worden opgevat als een aanval op shared hosting. Het is eerder een puur academische kijk op de beveiligingsproblemen rond deze categorie webhosting.

Directory Traversal

Laten we beginnen met directory traversal (vaak bekend als 'path traversal') aanvallen. Met dit soort aanvallen heeft u toegang tot bestanden en mappen die buiten de webrootwortel zijn opgeslagen.

In gewoon Engels? Laten we ons voorstellen dat Alice en Bob dezelfde server gebruiken om hun websites te hosten. De bestanden van Alice worden opgeslagen in / var / www / alice, terwijl de documenten van Bob te vinden zijn in / var / www / bob. Laten we verder doen alsof er een andere map op de server is (/ usr / crappyhosting / myfolder) die een niet-versleuteld leesbaar tekstbestand bevat (we noemen het pwd.txt) met systeemgebruikersnamen en -wachtwoorden.

Met mij tot nu toe? Goed. Laten we ons nu voorstellen dat de website van Bob PDF-bestanden bedient die lokaal worden gegenereerd en dat het lokale bestand in de URL wordt vermeld. Zoiets als:

http://example.com/file?=report.pdf

Wat zou er gebeuren als ik het 'report.pdf' zou vervangen door de enkele UNIX-parameters die de directory veranderen?

http://example.com/file?=... / alice /

Als de server verkeerd is geconfigureerd, kunt u de documentroot van Alice zien. Interessant, maar we zijn veel meer geïnteresseerd in dat sappige paspoortenbestand. Accio-wachtwoorden!

http://example.com/file?=... / ... / ... /usr/crappyhosting/myfolder/pwd.txt

Het is echt zo eenvoudig als dat. Maar hoe gaan we ermee om? Dat is eenvoudig.

Ooit gehoord van een weinig bekend genoemd Linux-hulpprogramma chroot? Je hebt waarschijnlijk al geraden wat het doet. Het zet de Linux / UNIX-root in een willekeurige map, waardoor gebruikers het niet meer kunnen afsluiten. In feite stopt het de traversal-aanvallen van mappen in hun tracks.

Het is moeilijk te zeggen of je gastheer dit op zijn plaats heeft zonder de wet te overtreden. Om het te testen, zou je immers toegang hebben tot systemen en bestanden waar je geen toegang toe hebt. Met dat in gedachten, misschien is het verstandig om met uw webhost te praten en te informeren naar hoe zij hun gebruikers van elkaar isoleren.

Bedient u uw eigen shared hosting-server en gebruikt u geen chroot om uw gebruikers te beschermen? Toegegeven, chrooting van uw omgevingen kan moeilijk zijn. Gelukkig zijn er een overvloed aan plug-ins die dit gemakkelijk maken. Kijk vooral naar mod_chroot.

Command Injection

Laten we teruggaan naar Alice en Bob. Dus we weten dat Bob's webapplicatie een paar ... Ahem ... Beveiligingsproblemen bevat. Een daarvan is de kwetsbaarheid van de opdrachtinjectie, waarmee je willekeurige systeemopdrachten kunt uitvoeren. Een korte handleiding Aan de slag met de Linux-opdrachtregel Een korte handleiding Aan de slag met de Linux-opdrachtregel Je kunt veel geweldige dingen doen met opdrachten in Linux en het is echt niet moeilijk om te leren. Lees verder .

Met de website van Bob kunt u een whois-query uitvoeren op een andere website die vervolgens in de browser wordt weergegeven. Er is een standaard HTML-invoervak ​​dat een domeinnaam accepteert en vervolgens de opdracht whois-systeem uitvoert. Deze opdracht wordt uitgevoerd door het PHP-commando system () aan te roepen.

Wat zou er gebeuren als iemand de volgende waarde invoerde??

example.com && cd ... / alice / && rm index.html

Laten we het afbreken. Een deel hiervan is misschien bekend voor u als u onze 'Getting Started Guide To Linux' handleiding hebt gelezen Aan de Linux gids Aan de slag Aan de slag met Linux A Newbie voor Linux! U hebt waarschijnlijk wel eens gehoord van Linux, het gratis, open-source besturingssysteem dat tegen Microsoft is opgeschoten. Lees Meer e-boek, dat we eerder in 2010 publiceerden, of een blik hebben geworpen op onze cheat sheet van Linux Command Line.

Ten eerste voert het een whois-query uit op example.com. Vervolgens zou het de huidige werkmap veranderen in de documentroot van Alice. Vervolgens wordt het bestand met de naam 'index.html' verwijderd. Dit is de indexpagina van haar website. Dat is niet goed. Nee meneer.

Dus, als systeembeheerders, hoe kunnen we hiertegen verzachten? Welnu, als we teruggaan naar het vorige voorbeeld, kunnen we altijd elke gebruiker in zijn eigen geïsoleerde, opgeschoonde, chrooted omgeving plaatsen.

We kunnen dit ook vanuit een taalniveau benaderen. Het is mogelijk (hoewel dit dingen kan breken) om functie-verklaringen wereldwijd uit talen te verwijderen. Dat wil zeggen dat het mogelijk is om functionaliteit te verwijderen van de talen waar gebruikers toegang toe hebben.

Kijkend naar PHP in het bijzonder, kunt u functionaliteit verwijderen met de officiële toolkit van Runkit - PHP om de functionaliteit van de taal te wijzigen. Er is een schat aan documentatie beschikbaar. Lees erin.

Je kunt ook het configuratiebestand van PHP (php.ini) aanpassen om functies uit te schakelen die vaak door hackers worden misbruikt. Open hiervoor een terminal op uw server en open uw php.ini-bestand in een teksteditor. Ik geniet ervan om VIM te gebruiken, maar NANO is ook acceptabel.

Zoek de regel die begint met disable_functions en voeg de functiedefinities toe die u wilt verbannen. In dit geval zou het exec, shell_exec en systeem zijn, hoewel het de moeite waard is om op te merken dat er andere ingebouwde functies zijn die kunnen worden misbruikt door hackers.

disable_functions = exec, shell_exec, systeem

Taal en op tolk gebaseerde aanvallen

Laten we dus naar PHP kijken. Dit is de taal die een verrassend aantal websites aanstuurt. Het komt ook met een aantal eigenaardigheden en raar gedrag. Zoals dit.

PHP wordt meestal gebruikt in combinatie met de Apache-webserver. Voor het grootste deel is het onmogelijk om meerdere versies van de taal met deze configuratie te laden.

Waarom is dit een probleem? Nou, laten we ons voorstellen dat Bob's webapplicatie oorspronkelijk in 2002 werd gebouwd. Dat is lang geleden. Dat is terug toen Michelle Branch nog steeds bovenaan stond, Michael Jordan nog steeds speelde voor de Washington Wizards en PHP een heel andere taal was.

Maar Bob's website werkt nog steeds! Het gebruikt een hele reeks beëindigde en verouderde PHP-functies, maar het werkt! Het gebruik van een moderne versie van PHP zou de website van Bob effectief breken, en waarom zou Bob zijn website herschrijven om tegemoet te komen aan de grillen van zijn webhost?

Dit zou u een idee moeten geven van het dilemma waarmee sommige webhosts worden geconfronteerd. Ze moeten een evenwicht vinden tussen het houden van een architectonisch gezonde en veilige service, en dat in overeenstemming houden met het zorgen dat de betalende klanten tevreden zijn.

Als gevolg hiervan is het niet ongebruikelijk om te zien dat kleinere, onafhankelijke hosts oudere versies van de PHP (of welke taal dan ook) gebruiken als interpreter.

Het is niet ongebruikelijk om te zien dat kleinere, onafhankelijke hosts oudere versies van PHP gebruiken, waardoor gebruikers mogelijk worden blootgesteld aan beveiligingsrisico's.

Waarom is dit een slechte zaak? In de eerste plaats zou dit gebruikers blootstellen aan een aantal veiligheidsrisico's. Net als de meeste grote softwarepakketten, wordt PHP voortdurend bijgewerkt om de overvloed aan beveiligingskwetsbaarheden aan te pakken die voortdurend worden ontdekt (en onthuld).

Bovendien betekent dit dat gebruikers de nieuwste (en grootste) taalfuncties niet kunnen gebruiken. Dit betekent ook dat functies die voor een bepaalde reden zijn verouderd, nog steeds beschikbaar zijn. In het geval van de PHP-programmeertaal omvat dit de lachwekkend slechte (en recentelijk verouderde) mysql_-functies die worden gebruikt voor interactie met het MySQL Relational Database System en dl (), waarmee gebruikers hun eigen taalextensies kunnen importeren.

Als gebruiker moet u kunnen zien welke versie van een tolk op uw service wordt uitgevoerd. Neem contact op met uw host als deze verouderd is of een aantal beveiligingsrisico's bevat.

Hoe zit het met sysadmins? Je hebt hier een paar opties. De eerste (en meest veelbelovende) is om Docker te gebruiken voor elk van uw gebruikers. Met Docker kunt u meerdere geïsoleerde omgevingen tegelijkertijd laten werken, net zoals een virtuele machine dat doet, maar zonder dat u een ander besturingssysteem hoeft te gebruiken. Als gevolg hiervan is dit snel. Echt, heel snel.

In gewoon Engels? U kunt de nieuwste en beste bleeding-tolk voor de meerderheid van uw gebruikers gebruiken, terwijl de klanten die oude applicaties gebruiken die oude, achterhaalde tolken gebruiken om dit te doen zonder andere gebruikers in gevaar te brengen.

Dit heeft ook het voordeel dat het taalagnostisch is. PHP, Python, Ruby. Wat dan ook. Het is allemaal hetzelfde.

Heb geen nachtmerries.

Dit bericht was bedoeld om een ​​paar dingen te doen. Allereerst moest het uw aandacht vestigen op het aantal beveiligingsproblemen waarmee webhostingbedrijven te maken hebben om de veiligheid van hun klanten en hun gegevens te waarborgen.

Het was ook bedoeld om u te laten zien hoe sites die op dezelfde server worden gehost elkaar kunnen beïnvloeden. Wil je hier de deuk in steken? Start met het gehoorzamen van goede, veilige coderingsnormen. Begin in het bijzonder met het zuiveren van uw invoer op zowel de front-end als de back-end.

Een goed begin is met de nieuwe HTML5-formuliervalidatiefunctionaliteit. We hebben dit eerder besproken in onze HTML5-handleiding. Samen kunnen we websites veiliger maken door betere, gewetensvolle programmeurs te zijn.

Zoals altijd, ben ik klaar om je gedachten te horen. Stuur me een reactie hieronder.

Fotocredit: Iedereen heeft een hacker nodig (Alexandre Dulaunoy), Sticker op taxi-venster (Cory Doctorow), Serverruimte (Torkild Retvedt), Linux-boeken en -tijdschriften (library_mistress), PHP Elephant (Markus Tacker)

Meer informatie over: online beveiliging, webhosting.