Отърви се от стандартните настройки на сървъра

Съдържанието на статията

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

Нека започнем с конфигурацията на индийския, който е спечелил място на много сървъри в мрежата. Първата конфигурация, която искате да направите, е да направите невъзможно атакуващият да знае версията на Apache. За това има две директиви, които трябва да бъдат зададени на следните стойности:

Индивидуален потребител и група

Втората точка е да се уверите, че Apache работи под свой собствен потребител и група. Ако например СУБД ще работи при същия потребител, тогава в случай на компрометиране на уеб сървър, нападателят ще може да получи достъп до базата данни.

Основна директория

След това трябва да се уверите, че файловете извън основната директория не се обработват от уеб сървъра. Ако приемем, че всички сайтове на сървъра са в една и съща директория (да речем/web), конфигурацията трябва да изглежда така:

деактивиране на сървърната страна включва - Опции -Включва;

деактивирайте изпълнението на CGI - Опции -ExecCGI;

предотвратяват отварянето на Apache на символни връзки - Опции -FollowSymLinks .

Ресурси и DoS

За да смекчите ефекта от DoS атаки, можете да намалите стойността на времето за изчакване - Timeout 45. Като алтернатива можете също да зададете ограничение за размера на тялото на заявката, като го направите, например, равно на 1 MB - LimitRequestBody 1048576. Като цяло следните параметри ще повлияят на поведението на сървъра с повишено внимание към него от страна на ботовете: RequestReadTimeout, KeepAliveTimeout, MaxRequestWorkers, както и директиви, ограничаващи консумацията на ресурси: LimitRequestFields, LimitRequestFieldSize, LimitRequestLine и LimitXMLRequestBody

Ограничение на достъпа

Ако ресурсът, разположен на сървъра, е предназначен само за определена подмрежа, можете да ограничите достъпа до него:

Защита на настройките

За да защитите настройките за защита, които сте направили в конфигурационния файл, и да попречите на потребителите да ги променят, можете да деактивирате поддръжката на htaccess файлове:

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

Следващият гост на нашия преглед е уеб сървърът nginx. Първо, възможно е, както в случая с Apache, да скриете типа и версията на сървъра, това е така наречената сигурност чрез неяснота, която ще принуди нападателя да отдели допълнително време. За да направите това, променете редовете във файла src/http/ngx_http_header_filter_module.c

След това компилирайте сървъра. За да скриете версията на сървъра, добавете опцията server_tokens off в конфигурационния файл nginx.conf. Сега за нападателя няма да е толкова лесно да разбере вида на уеб сървъра и неговата версия. Което вече е добре.

Ограничаващи буфери

Освен това, за да се предпазите малко от атаки за преливане на буфер, можете да приложите следните настройки:

client_body_buffer_size определя размера на буфера за клиентската заявка;

client_header_buffer_size задава размера на буфера за четене на заглавката на заявката на клиента;

client_max_body_size - максималният размер на тялото на заявката на клиента;

large_client_header_buffers задава максималния брой и размер на буферите за четене на заглавка на голям клиент.

Филтриране на потребителски агенти

Конфигурационният файл nginx.conf ви позволява гъвкаво да конфигурирате уеб сървъра за себе си. Например можете да откажете достъп до определени потребителски агенти - ботове, скенери, изтеглящи:

Долу с горещите връзки

Друга полезна функция е забраната за горещи връзки (когато някои ресурси на трети страни се свързват с изображение или друг ресурс на вашия сървър):

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

Ограничение на достъпа

Забранени ботове

Можете да се борите с ботове, които сканират сървъра за различни домейни, като разрешавате заявки само до конфигурирани виртуални домейни или обратни прокси заявки:

По същия начин можете да ограничите броя на наличните HTTP методи, например, като оставите само GET, POST и HEAD:

Реферален спам

За да се борите с нежелания спам, който може да повлияе отрицателно на вашия SEO ранг, можете да използвате подобна конфигурация:

Географска забрана

Ако вашият ресурс е постоянно атакуван от някоя държава или ако съдържанието просто не е предназначено за някоя държава, тогава достъпът до потребители от такива държави също може да бъде ограничен. Първо, трябва да посочите местоположението на базата данни GeoIP в конфигурационния блок http <> - geoip_country /etc/nginx/GeoIP.dat; и след това кажете на nginx кои държави да блокират:

Блоково изпълнение на скриптове

Отказ за четене на файлове

Сменете корена

Промяната на името и паролата на суперпотребителя е друга добра стъпка към сигурността. По подразбиране това обикновено е основният потребител. Това се прави от следните команди:

За да не объркате лошите, по-добре е също така да изтриете тестовата база данни, създадена по време на инсталацията, и всички анонимни потребители с празни пароли.

Изчистване на историята

Също така ще бъде полезно да изчистите историята, където се съхранява много ценна информация (например пароли) и то в ясна форма. Това се прави по следния начин:

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

Опасни функции

Първо, можете да блокирате извикването на потенциално опасни функции с disable_functions = phpinfo, system, mail, exec. След това ограничете използването на ресурси - максималното време за изпълнение на скрипта (max_execution_time), времето за анализиране на заявката (max_input_time), размерът на паметта, консумиран от всеки скрипт (memory_limit), максималният размер на данните, предадени от заявката POST, и така нататък.

Грешки и регистрационни файлове

След това можете да деактивирате показването на грешки на потребителите - display_errors = Off и да активирате регистрирането:

Преобличане

Деактивирайте expose_php, за да не разкривате факта, че PHP присъства на сървъра. Вярно е, че такъв трик ще помогне само в случай на използване на CNC. В противен случай URL адресът ще даде всичко.

Можете също така да деактивирате възможността за отваряне на отдалечени файлове, за това в конфигурационния файл за сигурност security.ini задайте allow_url_fopen на Off .

Принудително пренасочване

И разбира се, можете да активирате safe_mode и да деактивирате register_globals .

Съвременните проекти стават все по-сложни и мащабни, с нарастването на броя на посетителите нараства и натоварването на сървъра. За справяне с нарастващото натоварване започва кеширането. Най-популярното решение е memcached. Много често сигурността се пренебрегва, когато се разгръща. В резултат на това потенциалните дупки могат да останат незабелязани в продължение на години, докато един ден някой „любезен” човек го открие и използва. Администраторите често забравят за настройването на връзка с memcached демона. Хабре има история за това как е открита такава грешка на phpclub.ru.

Справянето с този проблем е съвсем просто - ако услугата за кеширане се намира на същата машина като самия проект, тогава трябва да ограничите достъпа до нея само от локалния хост. За да направите това, в memcached конфигурационния файл променете реда OPTIONS = " на OPTIONS = "- l 127.0.0.1" и рестартирайте memcached. Ако кеширащият демон се намира на отделен сървър, трябва да ограничите достъпа до него с помощта на защитна стена.

Лош съвет

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

Колко правилно

Най-добре е изобщо да не използвате етикет

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

PHP-FPM & nginx

Друг пример е свързан с конфигурирането на пакета PHP-FPM + nginx. Тези, които са го настроили, е вероятно да се препънат в мрежата на код, съдържащ следните редове:

Къде е заровено кучето тук? Факт е, че ако поискате от сървъра да върне http://example.com/1px.gif/test.php, тогава URI ще изглежда като 1px.gif/test.php, който от своя страна ще попадне под местоположението

Колко правилно

Първият вариант е да зададете променливата cgi.fix_pathinfo на 0 в php.ini. Вариант втори - добавете try_files $ fastcgi_script_name = 404; към блока за местоположение:

Накрая

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