Heeft u gedeelde hosting en maakt u zich zorgen over de beveiliging? Dit is wat je moet weten

Advertentie

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

Maar wat gebeurt er als het niet goed wordt gedaan?

Welnu, dat is wanneer gevaarlijke beveiligingsproblemen beginnen binnen te sluipen. Dat is wanneer uw site het risico loopt te worden geschonden of de privégegevens die u bewaart, worden gelekt. Maar maak je geen zorgen. De overgrote meerderheid van webhosts heeft behoorlijke beveiligingsmaatregelen. Het zijn alleen de 'fly-by-night', goedkope koopjes waar je op moet letten.

Wij raden aan De gedeelde hosting van InMotion Hosting met SSD-opslag.

We gaan de beveiligingsproblemen rond shared hosting onderzoeken. Maar laten we eerst praten over wat een gedeeld hostingplatform veilig maakt.

Wat maakt een veilige webhost

Er zijn een paar opvallende beveiligingsoverwegingen die moeten worden gemaakt met betrekking tot shared hosting.

• Elke gebruiker op de server moet geïsoleerd zijn van andere gebruikers en mag geen toegang hebben tot de bestanden van andere gebruikers of deze kunnen 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 bewaakt om architectonische beveiligingsproblemen aan te pakken.
• Elke gebruiker moet zijn eigen geïsoleerde databasetoegang hebben en mag geen wijzigingen aanbrengen in de opgeslagen records of tabelrechten van andere gebruikers.

Nogmaals, de meeste webhosts voldoen aan deze vereisten voor hun gedeelde aanbod. Maar als u meerdere websites op één server wilt hosten of nieuwsgierig bent naar hoe uw hostingbedrijf het doet, of zelfs maar denken aan het lanceren van uw eigen hostingbedrijf en willen graag uitzoeken hoe u uw gebruikers kunt beveiligen, lees dan alstublieft Aan.

Maar eerst een disclaimer

Voordat we ingaan op het kijken naar gemeenschappelijke aanvallen op shared hosting, wil ik het gewoon vermeld dat dit bericht geen volledige lijst van mogelijke beveiliging zal zijn (en niet mag worden gelezen) problemen.

Beveiliging is in één woord groot. Er zijn veel manieren waarop u een site kunt compromitteren. Dit geldt voor gedeelde hosting. Het was nooit op de kaarten om ze in één artikel te behandelen.

Als je paranoïde bent over je beveiliging, koop dan een VPS of dedicated server. Dit zijn omgevingen waarin je (grotendeels) absolute controle hebt over wat er gebeurt. Als u niet zeker bent van de verschillende soorten webhosting, bekijk dit bericht De verschillende vormen van website-hosting uitgelegd [Technologie uitgelegd] Lees verder van mijn collega, James Bruce.

Ik moet ook benadrukken dat dit bericht niet mag 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 hebt u toegang tot bestanden en mappen die buiten de webroot 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 zijn opgeslagen in / var / www / alice, terwijl Bob's documenten te vinden zijn in / var / www / bob. Laten we bovendien doen alsof er een andere map op de server staat (/ usr / crappyhosting / myfolder) die een niet-versleuteld bestand met platte tekst bevat (we noemen het pwd.txt) met systeemgebruikersnamen en wachtwoorden.

Met mij tot nu toe? Goed. Stel je voor dat Bob's website pdf-bestanden weergeeft die lokaal zijn gegenereerd, en naar het lokale bestand wordt verwezen in de URL. Zoiets als:

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

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

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

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

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

Zo eenvoudig is het echt. Maar hoe gaan we ermee om? Dat is gemakkelijk.

Ooit gehoord van een weinig bekend Linux-hulpprogramma genaamd chroot? Je hebt waarschijnlijk al geraden wat het doet. Het zet de Linux / UNIX-root in een willekeurige map, waardoor het voor gebruikers onmogelijk is om het te verlaten. In feite stopt het de traversale aanvallen op hun sporen.

Het is moeilijk te zeggen of uw gastheer dit heeft gedaan zonder de wet te overtreden. Om het te testen, zou u immers toegang krijgen tot systemen en bestanden waartoe u geen toestemming hebt. Met dat in gedachten is het misschien verstandig om met uw webhost te praten en te vragen hoe zij hun gebruikers van elkaar isoleren.

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

Command Injection

Laten we teruggaan naar Alice en Bob. We weten dus dat Bob's webapplicatie een paar... Ahem... Beveiligingsproblemen bevat. Een daarvan is het beveiligingslek met betrekking tot het injecteren van opdrachten, waardoor u kunt uitvoeren willekeurige systeemopdrachten Een beknopte handleiding om aan de slag te gaan met de Linux-opdrachtregelJe kunt veel geweldige dingen doen met opdrachten in Linux en het is echt niet moeilijk om te leren. Lees verder .

Met Bob's website kun je een whois-zoekopdracht 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 whois-systeemopdracht uitvoert. Deze opdracht wordt uitgevoerd door de system () PHP-opdracht aan te roepen.

Wat zou er gebeuren als iemand de volgende waarde invoerde?

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

Laten we het opsplitsen. Een deel hiervan is u misschien bekend als u onze hebt gelezen ‘Aan de slag-gids voor Linux’ Aan de slag met Linux en UbuntuJe bent geïnteresseerd in het overschakelen naar Linux... maar waar begin je? Is uw pc compatibel? Werken uw favoriete apps? Hier is alles wat u moet weten om aan de slag te gaan met Linux. Lees verder e-book, dat we eerder in 2010 publiceerden, of een blik op ons hebben geworpen Linux Command Line Cheat Sheet.

Ten eerste wordt er een whois-query uitgevoerd op example.com. Vervolgens wordt de huidige werkmap gewijzigd in de documentroot van Alice. Vervolgens wordt het bestand met de naam ‘index.html’ verwijderd, de indexpagina van haar website. Dat is niet goed. Nee meneer.

Dus, als systeembeheerders, hoe kunnen we dit tegengaan? Welnu, teruggaand naar het vorige voorbeeld, kunnen we elke gebruiker altijd in zijn eigen geïsoleerde, gezuiverde, gechroote omgeving plaatsen.

We kunnen dit ook benaderen vanuit een taalniveau. Het is mogelijk (hoewel dit dingen kan breken) om functieverklaringen uit talen wereldwijd te verwijderen. Dat wil zeggen, het is mogelijk om functionaliteit te verwijderen uit de talen waartoe gebruikers toegang hebben.

Als u met name naar PHP kijkt, kunt u functionaliteit verwijderen met Runkit - de officiële toolkit van PHP voor het wijzigen van de functionaliteit van de taal. Er is een schat aan documentatie beschikbaar. Lees erin.

U kunt ook het configuratiebestand van PHP (php.ini) wijzigen 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 gebruik graag VIM, maar NANO is ook acceptabel.

Zoek de regel die begint met uitschakelen_functies en voeg de functiedefinities toe die u wilt uitsluiten. In dit geval zouden het exec, shell_exec en systeem zijn, hoewel het vermeldenswaard is dat er andere ingebouwde functies zijn die door hackers kunnen worden misbruikt.

disable_functions = exec, shell_exec, systeem

Taal- en tolkaanvallen

Laten we dus eens kijken naar PHP. 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. Het is voor het grootste deel onmogelijk om meerdere versies van de taal te laden met deze configuratie.

Waarom is dit een probleem? Laten we ons voorstellen dat de webtoepassing van Bob oorspronkelijk in 2002 is gebouwd. Dat is lang geleden. Dat was toen Michelle Branch nog steeds bovenaan de hitlijsten stond, Michael Jordan speelde nog steeds voor de Washington Wizards en PHP was een heel andere taal.

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 Bob's website 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 behouden van een architectonisch solide en veilige service, terwijl ze dat in harmonie moeten houden met het zorgen dat de betalende klanten tevreden zijn.

Als gevolg hiervan is het niet ongebruikelijk dat kleinere, onafhankelijke hosts oudere versies van de PHP (of welke taal dan ook) -tolk gebruiken.

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

Waarom is dit een slechte zaak? Ten eerste zou het gebruikers blootstellen aan een aantal beveiligingsrisico's. Zoals de meeste grote softwarepakketten, wordt PHP voortdurend bijgewerkt om de overvloed aan beveiligingsproblemen aan te pakken die constant worden ontdekt (en onthuld).

Bovendien betekent dit dat gebruikers de nieuwste (en beste) taalfuncties niet kunnen gebruiken. Het betekent ook dat functies die om een ​​bepaalde reden zijn beëindigd, blijven bestaan. In het geval van de PHP programmeertaal Leer bouwen met PHP: een spoedcursusPHP is de taal die Facebook en Wikipedia gebruiken om dagelijks miljarden verzoeken te verwerken; de de facto taal die wordt gebruikt om mensen webprogrammering te leren. Het is prachtig eenvoudig, maar briljant krachtig. Lees verder , dit omvat de belachelijk vreselijke (en recentelijk verouderde) mysql_-functies die worden gebruikt om te communiceren met het MySQL Relational Database System, en dl (), waarmee gebruikers hun eigen taal kunnen importeren extensies.

Als gebruiker zou u moeten kunnen zien welke versie van een tolk op uw service draait. Als het verouderd is of een aantal beveiligingsproblemen bevat, neem dan contact op met je host.

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

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

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

Heb geen nachtmerries.

Deze post was bedoeld om een ​​aantal dingen te doen. Ten eerste was het om u onder de aandacht te brengen van 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 een deuk in doen? Begin met het gehoorzamen van goede, veilige coderingsnormen. Begin in het bijzonder met het opschonen van uw invoer aan de voorkant en aan de achterkant.

Een goed begin is met de nieuwe HTML5-functionaliteit voor formuliervalidatie. We hebben hier eerder over gesproken in onze HTML5-gids. Gezamenlijk kunnen we websites veiliger maken door betere, meer 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 taxiraam (Cory Doctorow), Serverruimte (Torkild Retvedt), Linux-boeken en -tijdschriften (library_mistress), PHP olifant (Markus Tacker)