Közös tárhelyet kapott, és aggódik a biztonság miatt? Itt van, amit tudnia kell

Hirdetés

Közös tárhely. Ez az olcsó lehetőség, nem igaz? És a lakosság hatalmas számának köszönhetően minden, amire szükségük van, webhelyük vagy webes alkalmazásuk üzemeltetésére. És ha jól sikerült, a megosztott tárhely méretezhető, gyors és biztonságos.

De mi történik, ha nem sikerült jól?

Nos, akkor kezdődik a veszélyes biztonsági kérdések kúszása. Erre akkor kerülhet sor, ha webhelyét megsemmisítik, vagy az Ön által tárolt személyes adatok kiszivárognak. De ne aggódj. Az internetes házigazdák túlnyomó többsége tisztességes biztonsági intézkedésekkel rendelkezik. Csak az éjszakai, alagsori alapanyag házigazdáinak kell vigyáznia.

Ajánljuk Az InMotion Hosting megosztott tárolása az SSD tárolóval.

Megvizsgáljuk a megosztott tárhelyet érintő biztonsági kérdéseket. De először beszéljünk arról, hogy mi teszi biztonságossá a megosztott tárhelyt.

Mi teszi a biztonságos webgazdagépet

Van néhány kiemelkedő biztonsági szempont, amelyet meg kell tenni a megosztott tárhely vonatkozásában.

• A szerver minden felhasználóját el kell különíteni a többi felhasználótól, és nem férhetnek hozzá más felhasználók fájljainak, illetve nem módosíthatják azokat.
  instagram viewer
• A kiszolgálón üzemeltetett webhely logikájának biztonsági rése nem befolyásolhatja más felhasználókat.
• A szervert rendszeresen javítják, frissítik és megfigyelik az építészeti biztonsági kérdések megoldása érdekében.
• Minden felhasználónak saját izolált adatbázis-hozzáféréssel kell rendelkeznie, és nem szabad megváltoztatnia a többi felhasználó tárolt rekordjait vagy tábláinak engedélyét.

A legtöbb internetes házigazda ismét megfelel ezeknek a követelményeknek a megosztott kínálatukra vonatkozóan. Ha azonban több webhelyet szeretne tárolni egy kiszolgálón, vagy kíváncsi szeretné látni, hogy a tárhely szolgáltatója hogyan áll fel, vagy akár arra gondol, hogy elindít egy saját tárhely szolgáltatót, és alig várja, hogy kidolgozza a felhasználók biztonságát, majd kérjük, olvassa el tovább.

De először is, egy nyilatkozat

Mielőtt elkezdenénk nézni a megosztott tárhelyszintű közös támadásokat, csak azt akarom nyilatkozzon arról, hogy ez a bejegyzés nem lesz (és nem szabad úgy értelmezni) a lehetséges biztonság kimerítő listája problémák.

A biztonság egyszóval nagy. Sokféle módon veszélyeztetheti a webhelyet. Ez megduplázódik a megosztott tárhely esetén. Egy cikkben való letakarás soha nem volt a kártyákon.

Ha paranoid a biztonsággal kapcsolatban, szerezzen be egy VPS-t vagy dedikált szervert. Ezek olyan környezetek, amelyekben (nagyrészt) abszolút ellenőrzése alatt áll, hogy mi folyik. Ha nem biztos benne, hogy különféle típusú webtárhely található, nézd meg ezt a posztot A webhely-tárolás különféle formáinak magyarázata [magyarázat a technológiára] Olvass tovább kollégámtól, James Bruce-től.

Hangsúlyoznom kellene azt is, hogy ezt a hozzászólást nem szabad a megosztott tárhely elleni támadásnak értelmezni. Inkább tisztán tudományos szemlélet a web hosting ezen kategóriájával kapcsolatos biztonsági kérdésekről.

Directory átjárása

Kezdjük a címtáráthaladás (gyakran az útvonal átjárása) támadásokkal. Az ilyen támadás lehetővé teszi a fájlok és könyvtárak elérését, amelyeket a web gyökérön kívül tárolnak.

Sima angolul? Nos, képzeljük el, hogy Alice és Bob ugyanazt a szervert használja webhelyeik üzemeltetésére. Alice fájljait a / var / www / alice mappában tárolja, míg Bob dokumentumai a / var / www / bob mappában találhatók. Tegyük fel úgy, mintha egy másik mappa lenne a szerveren (/ usr / crappyhosting / myfolder) amely egy nem titkosított egyszerű szöveges fájlt tartalmaz (ezt pwd.txt-nek hívjuk), amely a rendszer felhasználóneveit és jelszavakat.

Velem eddig? Jó. Képzeljük el tehát, hogy Bob weboldala a helyben létrehozott PDF fájlokat szolgálja, és a helyi fájlra hivatkoznak az URL-ben. Valami hasonló:

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

Mi történne, ha a „report.pdf” fájlt néhány olyan UNIX paraméterrel cserélném, amelyek megváltoztatják a könyvtárat?

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

Ha a kiszolgálót helytelenül konfigurálták, akkor ez lehetővé teszi, hogy láthassa Alice dokumentumgyökérét. Érdekes, de sokkal inkább érdekel minket az a lédús útlevél-fájl. Accio jelszavak!

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

Valóban ennyire egyszerű. De hogyan kezeljük ezt? Ez könnyű.

Hallottál valaha egy ismert, nem ismert Linux segédprogramról chroot? Valószínűleg már kitalálta, hogy mit csinál. Ez egy önkényes mappát állít be a Linux / UNIX gyökérre, ami lehetetlenné teszi a felhasználók számára a kilépést. Valójában megállítja a könyvtárak támadásait.

Nehéz megmondani, hogy a házigazda rendelkezik-e ezzel a helyén, anélkül, hogy megsértené a törvényt. Végül is tesztelni fogja olyan rendszereket és fájlokat, amelyekhez nincs hozzáférési jogosultsága. Ezt szem előtt tartva talán ésszerű lenne beszélni a webhelyével, és érdeklődni arról, hogy hogyan választják el a felhasználóikat egymástól.

Saját megosztott tárhelyszervert üzemeltet, és nem használja a chroot szolgáltatást a felhasználók védelme érdekében? Igaz, hogy környezeteinek chrootálása nehéz lehet. Szerencsére rengeteg plugin található, amelyek ezt megkönnyítik. Vessen egy pillantást különösen a mod_chroot-ra.

Parancs befecskendezése

Térjünk vissza Alice-hez és Bob-hoz. Tehát tudjuk, hogy Bob webalkalmazásában van néhány... Ahem... Biztonsági kérdés benne. Az egyik ilyen a parancs befecskendezésének biztonsági rése, amely lehetővé teszi a futtatást tetszőleges rendszerparancsok Rövid útmutató a Linux parancssori használatának megkezdéséhezSok csodálatos dolgot megtehetsz parancsokkal a Linux alatt, és ez tényleg nem nehéz megtanulni. Olvass tovább .

A Bob webhelye lehetővé teszi egy Whois-lekérdezés futtatását egy másik webhelyen, amely aztán megjelenik a böngészőben. Van egy szabványos HTML beviteli mező, amely elfogadja a domain nevet, majd futtatja a whois rendszer parancsát. Ezt a parancsot a rendszer () PHP parancs meghívásával hajtják végre.

Mi történne, ha valaki megadja a következő értéket?

példa.com && cd ../alice/ && rm index.html

Nos, szétbontjuk. Ennek némelyike ​​ismerős lehet Önnek, ha elolvasta a „Az első lépések útmutatója a Linuxhoz” Az első lépések a Linux és az Ubuntu használatávalÉrdekli a váltás a Linuxra... de hol kezdted? A számítógép kompatibilis? Kedvenc alkalmazásai működni fognak? Itt van minden, amit tudnod kell a Linux elindításához. Olvass tovább e-könyv, amelyet korábban 2010-ben tettünk közzé, vagy áttekintettünk rá Linux parancssori csalólap.

Először egy whois lekérdezést fog futtatni a example.com webhelyen. Ekkor az aktuális munkakönyvtárat Alice dokumentumgyökérré változtatja. Ekkor eltávolítja az „index.html” nevű fájlt, amely az ő webhelyének index oldala. Ez nem jó. Nem uram.

Tehát rendszergazdákként hogyan enyhíthetjük ezt? Visszatérve az előző példához, minden felhasználót mindig a saját, izolált, fertőtlenített, vezetés nélküli környezetbe tehetünk.

Ezt nyelvi szinten is megközelíthetjük. Lehetséges (bár ez megtörheti a dolgokat), hogy globálisan eltávolítsuk a funkciók deklarációit a nyelvekről. Vagyis el lehet távolítani a funkcionalitást azoktól a nyelvektől, amelyekhez a felhasználók hozzáférnek.

Különösen a PHP szempontjából eltávolíthatja a funkcionalitást a Runkit segítségével - a PHP hivatalos eszközkészletével, amely a nyelv funkcionalitását módosítja. Rengeteg dokumentáció található odakint. Olvassa el.

Módosíthatja a PHP konfigurációs fájlját (php.ini) is a hackerek által gyakran visszaélő funkciók letiltásához. Ehhez nyisson meg egy terminált a szerverén, és nyissa meg a php.ini fájlt egy szövegszerkesztőben. Élvezem a VIM használatát, de a NANO szintén elfogadható.

Keresse meg a disable_functions sorral kezdődő sort, és adja hozzá a tiltandó funkciódefiníciókat. Ebben az esetben az exec, a shell_exec és a system lesz, bár érdemes megjegyezni, hogy vannak más beépített funkciók is, amelyeket a hackerek kihasználnak.

Disable_functions = exec, shell_exec, system

Nyelvi és tolmács alapú támadások

Nézzük tehát a PHP-t. Ez a nyelv biztosítja a megrázó számú webhelyet. Számos sajátos szinkronizációval és furcsa viselkedéssel jár. Mint ez.

A PHP-t általában az Apache webszerverrel együtt használják. Általában lehetetlen betölteni a nyelv több verzióját ezzel a konfigurációval.

Miért van ez a probléma? Nos, képzeljük el, hogy Bob webes alkalmazását eredetileg 2002-ben építették. Ez már régen. Erre az időre, amikor a Michelle Branch még mindig a toplistákat töltötte be, Michael Jordan még mindig a Washington Wizards játékában játszott, a PHP pedig sokkal más volt.

De Bob weboldala továbbra is működik! Teljes csomót használ leállított és elavult PHP funkciókat, de működik! A PHP modern verziójának használata valóban megsemmisíti Bob weboldalát, és miért kellene újraírnia a weboldalt a weboldalán, hogy megfeleljen a webgazda szeszélyének?

Ez adhat neked egy képet a dilemmáról, amelyet néhány webtárhely szembesül. Egyensúlyban kell tartaniuk az építészeti szempontból megalapozott és biztonságos szolgáltatást, miközben ezt összhangban tartják a fizető ügyfelek boldogságának biztosításával.

Ennek eredményeként nem ritka, hogy a kisebb, független gazdagépek a PHP (vagy bármilyen nyelv) tolmács régebbi verzióit használják.

Nem ritka, hogy a kisebb, független gazdagépek régebbi PHP-verziókat használnak, potenciálisan kitéve a felhasználókat biztonsági kockázatoknak.

Miért rossz ez? Nos, először is, a felhasználókat számos biztonsági kockázatnak teheti ki. A legtöbb nagy szoftvercsomaghoz hasonlóan a PHP folyamatosan frissül a folyamatosan felfedezett (és nyilvánosságra hozott) biztonsági rések sokasága érdekében.

Ez azt is jelenti, hogy a felhasználók nem használhatják a legújabb (és legnagyobb) nyelvi funkciókat. Ez azt is jelenti, hogy az okból elavult funkciók megmaradnak. A PHP programozási nyelv Tanulj meg építeni a PHP-vel: Összeomló pályaA PHP az a nyelv, amelyet a Facebook és a Wikipedia naponta milliárd kérés kiszolgálására használ; az emberek web-programozásának tanításához használt tényleges nyelv. Gyönyörűen egyszerű, de ragyogóan erős. Olvass tovább , ez magában foglalja a nevetségesen szörnyű (és a közelmúltban elavult) mysql_ funkciókat, amelyek az interakcióhoz használatosak a MySQL relációs adatbázis rendszerrel és a dl () -nel, amely lehetővé teszi a felhasználók számára, hogy saját nyelvüket importálják kiterjesztéseket.

Felhasználóként látnia kell, hogy melyik tolmács verziója fut a szolgáltatásán. Ha elavult, vagy számos biztonsági rést tartalmaz, vegye fel a kapcsolatot a házigazdával.

Mi a helyzet a rendszergazdákkal? Itt van néhány lehetőség. Az első (és a legígéretesebb) az, hogy a Docker programot minden felhasználóhoz felhasználja. A Docker lehetővé teszi egyidejűleg több, elkülönített környezet futtatását, ugyanúgy, mint egy virtuális gép, bár anélkül, hogy másik operációs rendszert kellene futtatnia. Ennek eredményeként ez gyors. Tényleg, nagyon gyors.

Sima angolul? A felhasználók többsége, míg az ügyfelek számára a legfrissebb és legnagyobb verziós tolmácsot futtathatja akik olyan régi alkalmazásokat használnak, amelyek ősi, elavult tolmácsokat használnak, anélkül, hogy másokat veszélyeztetnének felhasználók számára.

Ennek az az előnye is, hogy nyelv-agnosztikus. PHP, Python, Ruby. Tök mindegy. Ugyanaz.

Ne legyen rémálmai.

Ez a bejegyzés néhány dolgot szánt. Először az volt, hogy felhívja a figyelmére a biztonsági kérdések számát, amelyekkel a web hosting cégeknek szembe kell nézniük ügyfeleik és adataik biztonságának biztosítása érdekében.

Azt is meg kívánta mutatni, hogy az ugyanazon a szerveren tárolt webhelyek hogyan befolyásolhatják egymást. Szeretne egy fogat beletenni ebbe? Keresse meg a jó, biztonságos kódolási szabványok betartását. Különösen el kell kezdenie a bemenetek fertőtlenítését mind az elülső, mind a hátsó oldalon.

Jó indulás az új HTML5 űrlap-érvényesítési funkcióval. Erről már korábban beszéltünk a HTML5 útmutatóban. Összességében biztonságosabbá tehetjük a webhelyeket azzal, hogy jobb, lelkiismeretes programozók vagyunk.

Mint mindig, kész vagyok a gondolatainak meghallgatására. Írj nekem egy megjegyzést alább.

Fotó jóváírás: Mindenkinek szüksége van egy hackerekre (Alexandre Dulaunoy), Taxi ablakon matrica (Cory Doctorow), Szerver szoba (Torkild Retvedt), Linux Könyvek és Magazinok (library_mistress), PHP elefánt (Markus Tacker)