Mindannyian, így vagy úgy, biztosak akarunk lenni abban, hogy senki sem törheti fel weboldalunkat vagy blogunkat. De sajnos a valóság az, hogy minden rendszer sérülékeny, bármennyire is védve lenne. Minden csak az erőforrásokon és egy betörő kitartásán múlik... Hmm... Valami rossz irányba sodort... Tekintsük ezt előszónak =)
Nem is olyan régen írtam arról, hogyan. De tegyük fel, hogy vett egy kész CMS-t, és nem tudja, hogyan valósítják meg ott a letöltést, és csak csináljon minden védelmet. Természetesen a különösen érdeklődő és hozzáértő fejlesztők tanulmányozzák ennek a CMS-nek a kódját, mielőtt felteszik webhelyükre. De mi van azokkal, akiknek nincs annyi idejük?
Nos, vagy mondjuk te azok közé tartozol, akik úgy vélik, hogy a biztonság ill helyes beállítás szerver nem felesleges? Ha igen, akkor üdvözöljük a cat alatt.
Nem, a cikkben nem talál olyan szuper duper beépülő modult, amely kiszűri az összes adatot, amelyet minden fájlnak tartalmaznia kell. Az én ötletem az irányelv használata auto_prepend_fileés az engedélyezett fájlok listájának összeállítása ... De általában olvassa el magad ...
Régóta ott motoszkált a fejemben ez az ötlet, de végre a kezembe került, bár nincs itt semmi bonyolult, és sikerült ezt a rendszert megvalósítanom és cikket írni =)
Működés elve
Ahogy fentebb is mondtam, a rendszer az irányelv működésén alapul auto_prepend_file V php.ini. Ő felel a szkript telepítéséért, amely a fő parancsfájl végrehajtása ELŐTT lefut.
Például megnyitottad az index.php-t, és a végrehajtás előtt a megadott fájlt auto_prepend_file. A lényeg az, hogy ebben a szkriptben tudjuk irányítani további munka egyéb szkriptek. Durván szólva, folytassa a munkát, és futtassa a kért szkriptet, vagy azonnal lépjen ki ( meghal()).
Például a helyzet – egy támadó valamilyen sebezhetőségen keresztül shellt töltött fel a webhelyére, és megpróbálja megnyitni egy böngészőben. A héja helyett pedig ok nélkül azt adják neki, itt van egy ilyen hiba:
Valami ilyesmi kábulatba hozna...
Ahhoz, hogy a rendszerem működjön, szükségem van az engedélyezett fájlok listájára, a listán nem szereplő fájlokhoz való hozzáférés blokkolva lesz.
(Nem tudom, szükség van-e erre a diagramra, úgy tűnik, mindennek világosnak kell lennie...)
Természetesen egy ilyen lista manuális összeállítása nem nemes dolog, ezért arra a következtetésre jutottam, hogy van értelme az úgynevezett "tanulási módot" megvalósítani. Az a mód, amelyben az összes parancsfájl összes hívása automatikusan felkerül az engedélyezett fájlok listájára.
Mit ad? Futtathatja ezt a rendszert tanulási módban, és folytathatja a webhely használatát. Használata során az adatbázisa feltöltődik azokkal az oldalakkal, amelyeket használ (elnézést a szójátékért). És tegyük fel, hogy egy hónap múlva a listája tartalmazza az összes olyan fájlt, amely a webhelyéhez kapcsolódik (amelyhez közvetlenül hozzáfért).
És vegye figyelembe, hogy a lista csak azokat a fájlokat tartalmazza, amelyekkel közvetlenül fog dolgozni. A szokásos átlagos webhelymotor egy csomó fájlt tartalmaz (osztályokkal, függvényekkel, könyvtárakkal, modulokkal stb.), ezek a fájlok nem fognak szerepelni ebben a listában, és a hozzáférésük a jövőben blokkolva lesz a mi szinten. védelem (persze az átlagos motoroknál van védelem a közvetlen indítás ellen, de hirtelen valahol ez a védelem kimarad).
Mit tehetünk
Mivel ez egy fogalom, nem tudjuk, mennyire.
- A jogosulatlan szkriptek blokkolása (valójában a fő funkció). De ez megint konfigurálható, a kapcsolatot nem lehet blokkolni, csak e-mailben értesíteni az adminisztrátort
- A jogosulatlan kérések értesítése az adminisztrátornak e-mailben (rövid jelentés vagy teljes jelentés, utóbbi tartalmazza a csomagfejléceket és az adatokat is POST kérés Ha vannak ilyenek)
- Megadhatja az adminisztrátor IP címét, aki hozzáférhet bármilyen szkripthez, pl. ezt a rendszert ez nem lesz hatással (ezek az IP-k nem vesznek részt a tanulási módban). Például nem kell bezárni .htaccess olyan szoftverek, mint a PhpMyAdmin, SupexDumper és más rendszer segédprogramok.
- Egyébként az Ip-címek támogatják az egyszerű maszkokat =)
- Teljesen kommentált kód és minden konfigurációs direktíva részletes leírása
- Huh mi más...
Beállítás
Most arról, hogyan építheti be ezt a védelmet webhelyére…
Ehhez hozzá kell férnie a php.ini fájlhoz
- Először töltse le magát a szkriptet: PrependSecuritySystem
- Csomagolja ki az archívum tartalmát (data.txt és main.php) a szerver valamelyik mappájába, lehetőleg olyan mappába, amely nem elérhető a webről (nem szükséges, mert bármelyikben működik, érdemes eltávolítani a forgatókönyvet távol a ropogtató szeme elől)
- Nyissa meg a main.php fájlt, és módosítsa a beállításokat. Meg kell változtatni az admin ip címét és email címét. A többi beállítás Önön múlik.
- Engedélyek beállítása a kicsomagolt fájlokhoz. Niks alatt mindkét fájl tulajdonosát kívánatos megváltoztatni, eltérve attól a felhasználótól, amelyen a webszerver fut. Fájlhoz main.php mindenkinél le kell tiltani a felvételt. Fájlhoz data.txt mindenkinek írási és olvasási engedélyt kell beállítania (ez ideiglenes, a képzési időszakra)
- Nyitunk php.iniés írja be a következőket:
auto_prepend_file=[a kicsomagolt main.php fájl elérési útja] - VAL VEL Ebben a pillanatban rendszeredzés indul. Várunk egy bizonyos időt, ami az Ön véleménye szerint elegendő a rendszer teljes betanítására.
- A képzés végén nyissa meg a fájlt main.phpés szerkessze az állandót PSS_STATUS_BLOCK, állítsa be az értékét igaz, megment
- Módosítsa a data.txt fájl engedélyeit. A szerkesztést tiltjuk adott fájl mindenkinek.
- Most a rendszer átváltott a jogosulatlan szkriptek blokkolásának módjára
Persze túl sok lépés, de nekem úgy tűnik, még egy gyerek is megbirkózik vele.
Ha újra kell tanítania a rendszert (a semmiből vagy kiegészíteni), akkor a következőket kell tennie:
- Írás engedélyezése data.txt fájlba
- A data.txt tartalmának törlése (CSAK akkor, ha újra kell tanítania a rendszert a semmiből)
- Állandó szerkesztése PSS_STATUS_BLOCK fájlban main.phpértékének beállításával hamis
- Átképzzük...
- Az átképzés végén szerkesztjük az állandót PSS_STATUS_BLOCKértékére állítva vissza igaz
- Tilos a data.txt fájl írása
Nos, most a szomorúról
Nem fogok szétszedni, és most a hiányosságokról fogok beszélni.
- Talán a fő hátrány, amelyhez képest az összes többi elhalványul, hogy ez a rendszer megkerülhető. Azt kérdezed: hogy van? Minden nagyon egyszerű, iránymutató auto_prepend_file-ben is megadható .htaccess. És ha józanul közelít, akkor ha a támadó hirtelen képes volt kitölteni a kagylót, akkor biztosan ki tudja tölteni .htaccess amelyben letilthatja az eredeti direktívát.
Ez csak alatt működik apache, de például alatt nginx ez a trükk nem fog működni (az nginx nem rendelkezik .htaccess fájlokkal). DE! Az Nginx alatt általában feltöltheti a . - A támadó szerkesztheti az "engedélyezett" szkriptet, ha erre érvényes jogosultságai vannak, és a rendszerünk sajnos nem tud ellene tenni. Hacsak nem kell beállítania a megfelelő engedélyeket az összes végrehajtható fájlhoz
- A PHP-n kívül van még mindenféle perl, cgi, stb... ez a rendszer nem működik velük.
- További terhelés. De vrtyali ez a terhelés észrevehető lesz.
Ezért úgy tűnik, hogy egy ilyen eredeti rendszer nem nevezhető ideálisnak. De nagyon alkalmas egyszerű megelőző intézkedésként, amely megállítja nem a legmakacsabb, kemény orrú betörőket. Ez a rendszer legalább időt vehet igénybe a támadótól a támadás végrehajtásához. Például a rendszer értesíti az adminisztrátort egy feltörési kísérletről, így lehetőséget ad a rendszergazdának a sebezhetőség kijavítására mindaddig, amíg a támadó meg nem érti a sikertelenség okát.
Következtetés
Mégis, mindenesetre ez egy koncepció, talán ez alapján lehet valami jobbat kitalálni. Vagy talán az én rendszerem megfelel neked.
Véleményem szerint az ésszerű védelem nem sok történik. Rajtad múlik, hogy használsz-e hasonlót a webhelyeden vagy sem.
Fú. Hát írtam, szinte az egész nap elment. Bocsáss meg, ha kicsit kaotikusan írtam le. Általában tegye fel kérdéseit a megjegyzésekben, megpróbálok válaszolni.
PS: bár a lehető legmegfelelőbben kódoltam, a szkriptnek lehetnek hibái. Win/apache/php 5.2-n tesztelve - minden rendben volt.
A "Biztonság nem tréfa dolog" szlogen a világ repülőterén található. Mindegyikben ugyanaz a szlogen Rendszergazda a PHP szerverem mellett kellett volna horgonyozni. És mindenkinek, aki az interneten található szerverhez csatlakozik, megfelelő biztonsági intézkedéseket kell tennie, különben meg kell kockáztatnia, hogy a rosszindulatú hackerek miatt adatot, sőt pénzt veszítsen. szoftver kárt okozhatnak számítógépük billentyűzetével.
Az oldal fejlesztője, aki aggódik a biztonsági kérdések miatt, köteles folyamatosan ismételni: "Ne bízzon a hálózatban." Ha aggódik webhelye védelme miatt, ismételje meg ezt a mondást, miközben webhelye jövőbeli oldalait kódolja. Bármilyen információ, amely a hálózaton keresztül továbbított a szervernek (legyen az URL, adat HTML űrlapok vagy máson keresztül érkező adatok hálózati port) potenciálisan veszélyesnek kell tekinteni. Ez a cikk számos módszert javasol a bejövő információk védelmére. Nemcsak ezeket a módszereket kell alkalmazni, hanem oda kell figyelni pontos idő más lehetséges veszélyek észlelése és megelőzésük módjainak megtalálása érdekében.
A biztonságos webhely létrehozásának második ökölszabálya: "Minimálisra csökkentse a kárt." Mi történik, ha az Ön által írt, Ön szerint meglehetősen megbízható program valóban sebezhetőnek bizonyul? Még csak azért is, hogy bent maradjak teljes biztonság, korlátozza azt a kárt, amelyet a támadó a biztonsági rést kihasználva okozhat.
Amikor a látogatók felkeresik webhelyét, abban reménykednek, hogy az oldal érvényes információkat tartalmaz, amelyek nem károsítják sem őket, sem számítógépeiket, és az általuk megadott információkat megfelelően kezelik. Egy látogató számára mindig fennáll a védelem megsértésének bizonyos kockázata, amikor bármilyen webhelyet használ, függetlenül attól, hogy szórakoztató, információs vagy e-kereskedelmi webhelyről van szó. Az oldal tervezőjének felelőssége, hogy megvédje a látogatókat az ilyen kockázatoktól. Ez azt jelenti, hogy nemcsak biztonságosan kell tárolnia a látogatók által szolgáltatott információkat a szerverén, hanem intézkedéseket kell tennie a látogatók számítógépeiről az Ön szerverére történő átvitel során közölt információk védelmére is.
Mindezek a megfontolások azonban nem akadályozhatják szándékait, például az e-kereskedelmi webhely online megjelenését.
Lehetséges támadások
A szerver internethez való csatlakoztatása egy forgalmas utcában történő üzlet megnyitásához hasonlítható. Szeretne sok látogatót, de óvintézkedések nélkül azt tapasztalhatja, hogy nem hétköznapi látogatók, hanem nagyon nem kívánt vendégek fogják kihasználni figyelmetlenségét.
Általában hackerek hívd fel azokat, akiket helyesebb lenne betörők szoftveres védelem . A számítógépes közösségben a biztonsági crackerek olyan szakemberek, akik szerencsével vagy képességeik segítségével legyőzik a védelmet. számítógépes rendszerekés kárt okozni. A hackerek pedig olyan programozók, akik mesterien tudnak programokat írni, és nemcsak az összetett kódot képesek megérteni, hanem önállóan is képesek hatékony (és gyakran kívülállók számára elérhetetlen) kódot írni sok nyelven. Egy programozó számára a hacker cím megtiszteltetés, a szoftvertörő cím pedig úgy tűnik, hogy a tulajdonosának szemmel kell tartania a Wanted jegyzeteket.
Sok kezdő programozó nem veszi észre, hogy mennyire megalázó a szoftvertörő cím, ezért az interneten talált eszközökhöz és szkriptekhez folyamodik ezen az úton. Az ilyen kezdő crackereket script-kiddeknek vagy nálunk coolhackereknek hívják. Ezek az emberek gyakran azt sem tudják, mit csinálnak. Jellemzően a támadóknak ez a kategóriája áll az olyan primitív támadások mögött, mint a webhely-kompromittálódás, az XSS és az SQL-befecskendezés.
Webhely-kompromittálódás és XSS-támadások
A webhelyek sokszor kellemetlen, mint valójában káros kompromittálások meglehetősen gyakoriak, hiszen sok oldal lehetőséget ad arra, hogy egy biztonsági cracker bejelentse a világnak, hogy sikerült elérnie a célt. Néha egy webböngésző önmagában is elegendő egy rosszul megtervezett webhely veszélyeztetéséhez. Vegyük például a következő programot:
Oldal egy egyszerű űrlappal a megjegyzések hozzáadásához ".$row["szöveg"].""; } } ?>Ez a program egy megjegyzésrendszert valósít meg nagyon primitív formában (ha a PHP kézikönyvemet az elejétől olvasta, lehet, hogy nem ismeri az adatbázis-műveleteket; ha igen, akkor azt javaslom, hogy a vonatkozó anyagok elolvasása után térjen vissza ehhez a cikkhez. MySQL).
Ezt a kódot olvasva egy tapasztalt programozó bizonytalannak érzi magát (ne feledje - "Ne bízzon a hálózatban"). Egy ilyen program olyan űrlapadatokat fogad el, amelyek várhatóan tartalmazzák a megjegyzés szövegét. Ez a szöveg a $comment változóhoz van hozzárendelve, és az adatbázisban tárolódik, hogy megjelenjen a jövőbeli látogatók számára. Ha a megadott adatok megfelelnek az elvárásoknak, akkor nem lesz probléma.
Most helyezd magad egy pillanatra a coolhacker helyébe, és képzeld el, mi történne, ha a bemenet HTML-címkéket tartalmazna. Ez egyszerű program mechanikusan beilleszti az ilyen leírókat a generált oldalba, és ez a torz oldal kerül telepítésre a többi látogató böngészőjében a normál oldal helyett. Az egyik leíró, amely adatbiztonsági szempontból különösen veszélyes lehet, a leíró
Betöltés...