У більшості випадків сервери веб-додатків повинні бути загальнодоступними, що означає, що вони наражаються на всі види загроз.
Багато з цих загроз передбачувані та їх легко уникнути, тоді як інші невідомі та можуть застати вас зненацька. Щоб звести до мінімуму ймовірність цього останнього випадку, ми пропонуємо перелік важливих порад щодо забезпечення якомога більшої безпеки серверів веб-додатків.
Перш ніж почати зі списку підказок, вам потрібно зрозуміти, що сервер веб-додатків — це не острів. Сервер є центральним компонентом у фермі веб-додатків, який робить можливим розміщення та роботу веб-додатку. Тому, щоб захистити, ви повинні взяти до уваги всі компоненти, які його оточують, і захистити все середовище веб-програми.
Базове середовище для розміщення та запуску веб-додатків включає операційну систему (Linux, Windows), програмне забезпечення веб-сервера (Apache, Nginx), сервер бази даних. Якщо будь-який із цих компонентів буде зламано, зловмисники можуть отримати доступ і виконати всі зловмисні дії, які їм заманеться.
Перша і основна порада щодо захисту такого середовища, як описане вище, полягає в тому, щоб прочитати інструкції з безпеки та список найкращих практик для кожного з компонентів. З огляду на це, давайте розглянемо низку здорових інструкцій із безпеки, які застосовуються майже до кожного середовища веб-додатків.
Брандмауер демістифікований
У вас може виникнути спокуса швидко перевірити цей пункт, подумавши: «Мені пощастило, у мене вже є брандмауер, який захищає мою мережу». Але вам краще притримати коней.
Можливо, ваш брандмауер піклується про кордони вашої мережі, не даючи злим хлопцям потрапити назовні, а хорошим – увійти, але, безперечно, він залишає двері відкритими для зловмисників, щоб зламати ваш сервер веб-додатків.
як?
Просто: ваш мережевий брандмауер повинен принаймні дозволяти вхідний трафік на портах 80 і 443 (тобто HTTP і HTTPS), і він не знає, хто або що проходить через ці порти.
Щоб захистити свою програму, вам потрібен брандмауер веб-програми (WAF), який спеціально аналізує веб-трафік і блокує будь-які спроби використання вразливостей, таких як міжсайтовий сценарій або впровадження коду. WAF працює як звичайний антивірус і захист від шкідливих програм: він шукає відомі шаблони в потоці даних і блокує їх, коли виявляє зловмисний запит.
Щоб бути ефективним, WAF має постійно оновлювати свою базу даних новими шаблонами загроз, щоб мати можливість їх блокувати. Проблема із запобіганням атакам на основі шаблонів полягає в тому, що ваша веб-програма може стати однією з перших цілей нової загрози, про яку ваш WAF ще не знає.
З цих причин ваша веб-програма потребує додаткових рівнів захисту, окрім мережевого брандмауера.
Сканування веб-вразливостей
Знову ж таки, не думайте, що ваш сервер веб-додатків вільний від уразливості лише тому, що ваш сканер безпеки мережі так говорить.
Мережеві сканери не можуть виявити вразливості програми. Щоб виявити та усунути ці вразливості, ви повинні піддати програми серії тестів і аудитів, таких як тести на проникнення, сканування чорної скриньки та аудит вихідного коду. Однак жоден із цих методів не є куленепробивним. В ідеалі ви повинні виконати якомога більше їх, щоб усунути всі вразливості.
Наприклад, сканери безпеки, як Invicti, гарантуйте, що жоден код, який можна використовувати, не потрапить у виробниче середовище. Але можуть бути логічні вразливості, які можна виявити лише за допомогою ручного аудиту коду. Ручний аудит, окрім того, що коштує багато, є людським і, отже, схильним до помилок методом. Гарною ідеєю для проведення такого роду аудиту, не витрачаючи багато грошей, є вбудовування його в процес розробки, здебільшого шляхом навчання ваших розробників.
Навчайте своїх розробників
Розробники схильні думати, що їхні програми працюють в ідеальних світах, де ресурси необмежені, користувачі не роблять помилок і немає людей з безжальними намірами. На жаль, у певний момент їм потрібно зіткнутися з проблемами реального світу, особливо з проблемами інформаційної безпеки.
Розробляючи веб-програми, кодери повинні знати та впроваджувати механізми безпеки, щоб переконатися, що в них немає вразливостей. Ці механізми безпеки мають бути частиною посібника з найкращих практик, якого повинна дотримуватися команда розробників.
Аудит якості програмного забезпечення використовується для забезпечення відповідності найкращим практикам. Найкращі практики та аудит є єдиними способами виявлення логічних уразливостей, таких як (наприклад) передача незашифрованих і видимих параметрів усередині URL-адреси, яку зловмисник може легко змінити, щоб робити те, що він або вона хоче.
Вимкніть непотрібні функції
Припускаючи, що веб-додатки максимально безпомилкові, а веб-ферма захищена, давайте подивимося, що можна зробити на самому сервері, щоб захистити його від атак.
Основна порада здорового глузду полягає в тому, щоб зменшити кількість потенційно вразливих точок входу. Якщо зловмисники можуть використати будь-який із компонентів веб-сервера, весь веб-сервер може опинитися під загрозою.
Складіть список усіх відкритих портів і запущених служб або демонів на вашому сервері та закрийте, вимкніть або вимкніть непотрібні. Сервер не слід використовувати для будь-яких інших цілей, окрім запуску ваших веб-програм, тому подумайте про переміщення всіх додаткових функцій на інші сервери у вашій мережі.
Використовуйте окремі середовища для розробки, тестування та виробництва
Розробникам і тестувальникам потрібні привілеї щодо середовищ, у яких вони працюють, яких вони не повинні мати на живому сервері програм. Навіть якщо ви сліпо довіряєте їм, їхні паролі можуть легко витекти та потрапити до небажаних рук.
Окрім паролів і привілеїв, у середовищах розробки та тестування зазвичай є бекдори, файли журналів, вихідний код або інша інформація для налагодження, яка може розкрити конфіденційні дані, такі як імена користувачів і паролі бази даних. Процес розгортання веб-програми має здійснюватися адміністратором, який має переконатися, що жодна конфіденційна інформація не розкрита після встановлення програми на живому сервері.
Ту саму концепцію сегрегації потрібно застосовувати до даних програми. Тестувальники та розробники завжди віддають перевагу реальним даним для роботи, але не дуже гарна ідея надавати їм доступ до робочої бази даних або навіть до її копії. Окрім очевидних проблем конфіденційності, база даних може містити параметри конфігурації, які розкривають внутрішні параметри сервера — наприклад, адреси кінцевих точок або імена шляхів, щоб назвати пару.
Оновлюйте серверне програмне забезпечення
Яким би очевидним це не здавалося, це одне з найбільш забутих завдань. SUCURI виявив, що 59% програм CMS застаріли, що є ризикованою.
Нові загрози з’являються щодня, і єдиний спосіб запобігти їх загрозі вашому серверу – завжди встановлювати найновіші патчі безпеки.
Раніше ми згадували, що мережевих брандмауерів і сканерів мережевої безпеки недостатньо для запобігання атакам на веб-програми. Але вони необхідні для захисту вашого сервера від поширених загроз кібербезпеці, таких як DDoS-атаки. Тому переконайтеся, що такі програми постійно оновлюються, і що вони ефективно захищають вашу бізнес-програму.
Обмежте доступ і привілеї
Основний захід безпеки полягає в тому, щоб трафік віддаленого доступу, наприклад RDP і SSH, був зашифрований і тунельований. Також доцільно зберегти скорочений список IP-адрес, з яких дозволено віддалений доступ, переконавшись, що будь-які спроби віддаленого входу з будь-якої іншої IP-адреси блокуються.
Час від часу адміністратори надають сервісним обліковим записам усі можливі привілеї, оскільки вони знають, що таким чином «усе працюватиме». Але це не є хорошою практикою, оскільки зловмисники можуть використовувати вразливості в службах, щоб проникнути на сервер. Якщо ці служби запускаються з правами адміністратора, вони можуть захопити весь сервер.
Хороший баланс між безпекою та практичністю вимагає, щоб кожен обліковий запис — як обліковий запис для входу, так і обліковий запис служби — мав привілеї, необхідні для виконання своєї роботи, і нічого більше.
Наприклад, ви можете визначити різні облікові записи для адміністратора для виконання різних завдань: один для створення резервних копій, інший для очищення файлів журналу, треті для зміни конфігурації служб і так далі. Те саме стосується облікових записів бази даних: програмі зазвичай потрібні лише дозволи для читання та запису даних, а не для створення чи видалення таблиць. Тому його слід запускати з обліковим записом із обмеженими привілеями для виконання завдань, які він повинен виконувати.
Слідкуйте за журналами сервера
Файли журналів існують не просто так.
Адміністратори повинні регулярно контролювати їх, щоб виявити будь-яку підозрілу поведінку до того, як вона завдасть будь-якої шкоди. Аналізуючи файли журналів, ви можете відкрити багато інформації, яка допоможе вам краще захистити програму. Якщо відбудеться атака, файли журналу можуть показати вам, коли та як вона почалася, допомагаючи краще контролювати пошкодження.
Ви також повинні мати автоматизовану процедуру видалення старих файлів журналу або скорочення застарілої інформації, щоб вони не займали весь доступний простір для зберігання на сервері.
Бонусна порада: тримайте себе в курсі
В Інтернеті є багато безкоштовної та корисної інформації, яку можна використати на користь вашої веб-програми. Не пропускайте жодної нової публікації в авторитетних блогах безпеки (як цей) і будьте в курсі подій у сфері безпеки та веб-індустрії.
Підручники, курси, відео та книги також є джерелами корисних знань. Виділяйте одну-дві години на тиждень лише на те, щоб бути в курсі галузевих новин — це дасть вам душевний спокій, усвідомлюючи, що ви робите правильні речі, щоб захистити свої програми.