Получихте споделен хостинг и се притеснявате за сигурността? Ето какво трябва да знаете

реклама

Споделен хостинг. Това е евтиният вариант, нали? И за голяма част от населението, това е всичко, което някога ще им е необходимо, за да хоствате своя уебсайт или уеб приложение. А когато се направи добре, споделеният хостинг е мащабируем, бърз и сигурен.

Но какво се случва, когато не е добре?

Е, тогава започват да възникват опасни проблеми със сигурността. Това е, когато вашият сайт е застрашен от неизпълнение или личните данни, които държите, ще бъдат изтекли. Но не се притеснявайте По-голямата част от уеб хостовете имат прилични мерки за сигурност. Трябва да бъдете предпазливи само домакините, които работят през нощта и в мазето.

Препоръчваме Споделеният хостинг на InMotion хостинг със SSD хранилище.

Ще проучим проблемите със сигурността около споделения хостинг. Но първо, нека поговорим за това, което прави споделена хостинг платформа защитена.

Какво прави сигурен уеб-домакин

Има няколко независими съображения за сигурност, които трябва да се направят по отношение на споделения хостинг.

• Всеки потребител на сървъра трябва да бъде изолиран от други потребители и да не може да има достъп или да променя файловете на други потребители.
• Уязвимостта на сигурността в логиката на уебсайт, хостван на сървъра, не трябва да може да засегне други потребители.
• Сървърът редовно се коригира, актуализира и следи за справяне с проблемите на архитектурната сигурност.
• Всеки потребител трябва да има собствен изолиран достъп до база данни и не трябва да им се разрешава да прави промени в съхранените записи или разрешения на таблици на други потребители.

Отново повечето уеб хостове отговарят на тези изисквания за своите споделени предложения. Но ако търсите хостинг на няколко уебсайта на един сървър или сте любопитни да видите как вашата хостинг компания се подрежда, или дори мислите да стартирате собствена хостинг компания и нямате търпение да разберете как да защитите вашите потребители, моля, прочетете На.

Но първо, отказ от отговорност

Преди да се впуснем в месото на разглеждане на общи атаки, изравнени при споделен хостинг, просто искам заявете, че тази публикация няма да бъде (и не трябва да се чете като) изчерпателен списък на потенциална сигурност въпроси.

Сигурността с една дума е голяма. Има много начини, по които можете да компрометирате сайт. Това става двойно за споделен хостинг. Покриването им в една и съща статия никога не е присъствало на картите.

Ако сте параноични по отношение на сигурността си, вземете VPS или специален сървър. Това са среди, в които имате (в по-голямата си част) абсолютен контрол върху това, което става. Ако не сте сигурни в различните видове уеб хостинг, вижте тази публикация Разяснени различните форми на хостинг на уебсайтове [Обяснени технологии] Прочетете още от колегата Джеймс Брус.

Трябва също да подчертая, че тази публикация не трябва да се тълкува като атака срещу споделен хостинг. По-скоро това е чисто академичен поглед върху проблемите със сигурността, свързани с тази категория уеб хостинг.

Преминаване на директории

Нека започнем с атаката на обиколка на директорията (често известна като „обиколка на пътя“). Този вид атака ви позволява да получите достъп до файлове и директории, които се съхраняват извън уеб корен.

На обикновен английски? Е, нека си представим, че Алис и Боб използват един и същ сървър, за да хостват своите уебсайтове. Файловете на Алиса се съхраняват във / var / www / alice, докато документите на Bob могат да бъдат намерени в / var / www / bob. Освен това, нека се преструваме, че има друга папка на сървъра (/ usr / crappyhosting / myfolder) който съдържа некриптиран файл в безпроблемен текст (ще го наречем pwd.txt), съдържащ системни потребителски имена и пароли.

С мен досега? Добре. Сега, нека си представим, че уебсайтът на Боб обслужва PDF файлове, генерирани локално, а локалният файл е посочен в URL адреса. Нещо като:

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

Какво ще се случи, ако заменя „report.pdf“ с някои параметри на UNIX, които променят директорията?

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

Ако сървърът е конфигуриран неправилно, това ще ви позволи да видите корен на документа на Alice. Интересно е, но ние сме много по-заинтересовани от този сочен паспорт. Accio пароли!

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

Наистина е толкова лесно като това. Но как да се справим с него? Това е лесно.

Някога чувате ли за малко известна помощна програма, наречена Linux Chroot? Вероятно вече сте се досетили какво прави. Той задава корен на Linux / UNIX на произволна папка, което прави невъзможно потребителите да излязат от него. Ефективно спира спирането на атаки на директорията в техните песни.

Трудно е да се каже дали вашият домакин има това място, без да нарушава закона. В крайна сметка, за да го тествате, ще имате достъп до системи и файлове, до които нямате разрешение за достъп. Имайки това предвид, може би би било разумно да говорите с вашия уеб хост и да попитате как те изолират своите потребители един от друг.

Работите ли със собствен сървър за споделен хостинг и не използвате chroot за защита на потребителите си? Наистина, хронирането на вашата среда може да бъде трудно. За щастие, има множество приставки, които правят това лесно. Обърнете внимание по-специално на mod_chroot.

Инжектиране на командите

Да се ​​върнем към Алис и Боб. Знаем, ние знаем, че уеб приложението на Bob има няколко... Ahem... Проблеми със сигурността в него. Една от тях е уязвимостта на командната инжекция, която ви позволява да стартирате произволни системни команди Бързо ръководство за започване на работа с командния ред на LinuxМожете да правите много невероятни неща с команди в Linux и наистина не е трудно да се научите. Прочетете още .

Уебсайтът на Bob ви позволява да стартирате Whois заявка на друг уебсайт, който след това се показва в браузъра. Има стандартно поле за въвеждане на HTML, което приема име на домейн и след това изпълнява системната команда whois. Тази команда се изпълнява чрез извикване на системната () PHP команда.

Какво би се случило, ако някой въведе следната стойност?

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

Е, нека го разградим Някои от това може да са ви познати, ако сте чели нашите „Ръководство за работа с Linux“ Първи стъпки с Linux и UbuntuИнтересувате се да преминете към Linux... но откъде да започнете? Вашият компютър съвместим ли е? Ще работят ли любимите ви приложения? Ето всичко, което трябва да знаете, за да започнете работа с Linux. Прочетете още електронна книга, която по-рано публикувахме през 2010 г. или погледнахме над нашата Чит лист на командния ред на Linux.

Първо, ще изпълни Whois заявка в example.com. Тогава ще промени текущата работна директория в корен на документа на Алиса. Тогава тя ще премахне файла, наречен „index.html“, който е индексната страница към нейния уебсайт. Това не е добре. Не, Господине.

И така, като системни администратори, как да смекчим това? Е, връщайки се към предишния пример, винаги можем да поставим всеки потребител в неговата собствена изолирана, дезинфекцирана, хронирана среда.

Можем също да подходим към това от езиково ниво. Възможно е (въпреки че това може да наруши нещата) глобално премахване на декларации за функции от езици. Това означава, че е възможно да премахнете функционалността от езиците, до които потребителите имат достъп.

Разглеждайки по-специално PHP, можете да премахнете функционалността с Runkit - официалния инструментариум на PHP за промяна на функционалността на езика. Има богата документация. Прочетете в него.

Можете също да промените конфигурационния файл на PHP (php.ini), за да деактивирате функции, които често се злоупотребяват от хакерите. За целта отворете терминал на вашия сървър и отворете вашия файл php.ini в текстов редактор. Обичам да използвам VIM, но и NANO е приемливо.

Намерете реда, който започва с disabled_functions и добавете определенията на функциите, които искате да забраните. В този случай това ще бъде exec, shell_exec и система, въпреки че си струва да се отбележи, че има и други вградени функции, които могат да се използват от хакерите.

disabled_functions = exec, shell_exec, система

Езикови и преводачески атаки

Така че, нека да разгледаме PHP. Това е езикът, който дава възможност за стряскащ брой уебсайтове. Той също така идва с редица идиосинкразии и странно поведение. Като този.

PHP обикновено се използва заедно с уеб сървъра Apache. В по-голямата си част е невъзможно да се заредят няколко версии на езика с тази конфигурация.

Защо това е проблем? Е, нека си представим, че уеб приложението на Боб първоначално е създадено през 2002 г. Това е много отдавна. Връща се, когато Мишел Бранч все още оглавяваше класациите, Майкъл Джордан все още играеше за Washington Wizards и PHP беше много по-различен език.

Но уебсайтът на Боб все още работи! Той използва цял куп прекратени и оттеглени PHP функции, но работи! Използването на модерна версия на PHP би повредило ефективно уебсайта на Боб и защо Боб трябва да пренапише уебсайта си, за да се справи с капризите на уеб хоста си?

Това трябва да ви даде представа за дилемата, с която се сблъскват някои уеб-домакини. Те трябва да балансират да поддържат архитектурно стабилна и сигурна услуга, като в същото време поддържат това в хармония с това да гарантират, че плащащите клиенти са доволни.

В резултат на това не е рядкост да видите, че по-малки, независими хостове използват по-стари версии на интерпретатора на PHP (или на какъвто и да е език).

Не са редки случаите, когато по-малки, независими хостове използват по-стари версии на PHP, потенциално излагащи потребителите на рискове за сигурността.

Защо това е лошо нещо? Е, първо, това би изложило потребителите на редица рискове за сигурността. Подобно на повечето основни софтуерни пакети, PHP непрекъснато се обновява за справяне с множеството уязвими места в сигурността, които постоянно се откриват (и разкриват).

Освен това, това означава, че потребителите не могат да използват най-новите (и най-добрите) езикови функции. Това също означава, че функциите, които са остарели по някаква причина, остават. В случай на PHP език за програмиране Научете се да изграждате с PHP: Курс за катастрофаPHP е езикът, който Facebook и Wikipedia използват за обслужване на милиарди заявки всеки ден; езикът фактически, използван за преподаване на уеб програмиране на хора. Това е красиво просто, но блестящо мощно. Прочетете още , това включва смешно страшните (и наскоро оттеглени) функции mysql_, които се използват за взаимодействие със системата за релационни бази данни MySQL и dl (), която позволява на потребителите да импортират собствения си език разширения.

Като потребител трябва да можете да видите каква версия на преводач работи на вашата услуга. Ако той е остарял или съдържа редица уязвими места за сигурност, свържете се с вашия хост.

Какво ще кажеш за sysadmins? Имате няколко опции тук. Първото (и най-обещаващото) е да използвате Docker за всеки от вашите потребители. Docker ви позволява да стартирате множество, изолирани среди едновременно, подобно на виртуалната машина, макар и без да се налага да стартирате друга операционна система. В резултат това става бързо. Наистина, много бързо.

На обикновен английски? Можете да стартирате най-новия и най-добрият преводач на краищата за повечето от потребителите си, докато клиентите които използват стари приложения, които използват древни, остарели интерпретатори, за да го правят, без да компрометират други потребители.

Това също има предимството, че е езиков агностик. PHP, Python, Ruby. Както и да е. Всичко е едно и също.

Да няма кошмари.

Този пост беше предназначен да направи няколко неща. Първо, трябваше да се обърне на вниманието ви броя на проблемите със сигурността, с които уеб хостинг компаниите трябва да се сблъскат, за да гарантират сигурността на своите клиенти и техните данни.

Освен това е имало за цел да ви покаже как сайтовете, хоствани на един и същ сървър, могат да влияят един на друг. Искате ли да поставите вдлъбнатина в това? Започнете да се подчинявате на добри, сигурни стандарти за кодиране. По-специално, започнете да дезинфекцирате вашите входове както отпред, така и отзад.

Добро начало е с новата функционалност за валидиране на HTML5 формуляр. Говорихме за това преди в ръководството ни за HTML5. Колективно можем да направим уебсайтовете по-сигурни, като бъдем по-добри и съвестни програмисти.

Както винаги, аз съм готов да чуя вашите мисли. Пусни ми коментар по-долу.

Кредит за снимка: Всички се нуждаят от хакер (Александър Дулауной), Стикер на прозореца за такси (Cory Doctorow), Сървърна стая (Torkild Retvedt), Linux книги и списания (library_mistress), PHP слон (Markus Tacker)