Чому зламують навіть захищені CMS на безпечному хостингу



Очевидно, що якщо у сайту є уразливості, то його можна зламати за допомогою веб-атак. Але навіть якщо сайт захищений технічними засобами, працює на надійної CMS, його все одно можуть скомпрометувати. Яким чином це відбувається і як захистити сайт від різних варіантів злому не через веб-уразливості, про це розповів на партнерської конференції «1С-Бітрікс» Григорій Земсков, керівник компанії «Ревизиум».

З кожним роком зростає кількість зламів і потерпілих від них власників сайтів. А в останні два роки проблема безпеки сайтів стає особливо актуальною: в рази зросла кількість атак і обсяги вхідного небезпечного трафіку, і, як наслідок, кількість зламаних ресурсів. Бачачи це, веб-майстри та власники веб-проектів поступово починають усвідомлювати проблему і цікавитися питаннями інформаційної безпеки сайтів, зокрема, їх захистом. Для того, щоб грамотно захистити свій ресурс, власник веб-ресурсу повинен розуміти, які є варіанти злому, як діє зловмисник, які вектори атак найбільш критичні і як їх закрити.

На жаль, існує дуже багато статей і відео, які вводять в оману тих, хто цікавиться цими питаннями. Проблема тут у тому, що питання безпеки висвітлюється однобоко, зазвичай розглядаються тільки технічні засоби захисту. Причому не в повному обсязі, а тільки ті, які блокують веб-атаки. Це дає веб-майстрам почуття помилкової захищеності і абсолютно не гарантує безперебійну роботу веб-ресурсу і захист від несанкціонованих змін. У більшості випадків у власника сайту немає бажання витрачати свої ресурси: гроші, час на безпеку проекту, тому вибирається на його погляд оптимальна стратегія: використовувати популярну комерційну систему управління сайтом та розмістити сайт на популярному хостингу. Все, начебто, логічно: захищена система працює в захищеному середовищі, тобто можна більш не думати про безпеку і захист. Але це всього лише одна з популярних міфів про безпеку сайтів, поряд з тим, що досить одних лише технічних заходів захисту.

На жаль, всі ці «міфи» — про використання лише веб-атак для злому сайтів, про захищеність CMS і достатність технічних заходів, що призводять до нових масових зломів сайтів. Що ж робити, щоб цього не відбувалося? Необхідний комплексний підхід до питання безпеки сайту. Далі ми розглянемо, чому потрібно приділяти постійну і особливу увагу як технічних засобів захисту, так і організаційних заходів. Це важливо хоча б тому, що існує багато варіантів злому сайтів, які виконуються нетехнічними методами і без використання веб-вразливостей.

Варіанти злому сайтів
Всі варіанти злому сайтів можна умовно розділити на три великі групи (виділені жовтим, блакитним і сірим кольором):



Найбільше говорять і пишуть про зломи допомогою веб-атак. Оскільки даний аспект висвітлений досить добре, у цій публікації я лише побіжно згадаю про нього, а основний наголос хотілося б зробити на двох незаслужено забутих категоріях: компрометації ресурсів технічними засобами без використання «людського фактора» (жовтий блок) і злом з вини підрядників і співробітників, тобто тих, хто допомагає обслуговувати сайт. У кількісному вираженні зломи через веб становлять близько 75%, чим і обумовлена настільки пильну увагу до цього класу.



Що стосується інших двох, то вони не такі популярні, але все ж не менш важливі. За нашою статистикою, на злом з вини підрядників і співробітників припадає близько 5% інцидентів. Але ця цифра поступово зростає, оскільки зараз багато сайтів віддається на обслуговування в веб-студії, діджитал-агентства або фрілансерів.

Отже, розглянемо варіанти по-порядку. Почнемо з самої численної групи, злом сайту за допомогою веб-атак:

  • В більшості випадків це стає можливим в результаті експлуатації вразливостей
    • в скриптах CMS, в плагінах і модулях. Розробники припускають помилки: недостатньо фільтруються вхідні параметри, не перевіряються розміщуються в базі дані, інформація виводиться на сторінці «як є», без безпечних перетворень.
    • доопрацювань. Можна поставити безпечну CMS, але при цьому покликати недосвідченого розробника. Він допише плагін, який внесе іноді не одну критичну вразливість і через них зламають сайт. Веб-програміст повинен бути знайомий з принципами безпечної розробки, а власнику сайту слід звертатися до досвідчених підрядникам.
  • Другий варіант злому сайту можливий завдяки брутфорсу панелей адміністрування, тобто підбору логінів/паролів. Це дуже поширений тип атаки, особливо на захищені CMS. Раніше користувачі встановлюють короткі або словникові паролі, які легко перебираються зловмисниками і можуть бути підібрані за кінцевий час. В результаті доступ до адмін-панелі можна отримати буквально за кілька хвилин. Ситуація ускладнюється тим, що доступ в панель адміністратора зазвичай не обмежується додатковими засобами, такими як двофакторна аутентифікація, дозволеним списком IP-адрес, а число невдалих спроб входу не обмежена.
Захист від веб-атак
Позбутися від веб-атак не можна, але їм можна протидіяти. Нижче представлений список заходів проти злому через веб.

  1. Необхідно оновлювати CMS і скрипти. З кожною новою версією виходять патчі безпеки: закриваються уразливості, виправляються помилки. Все це дозволяє знизити ймовірність злому через веб, хоча і не захищає від нього на 100%, тому що і в нових апдейта, на жаль, можуть з'явитися нові «діри».
  2. Необхідно мінімізувати обсяг плагінів в CMS. Чим більше плагінів, тим більше ймовірність наявності вразливостей. В ідеалі, використовувати рішення «з коробки», з застосованими патчами і критичними оновленнями, які закривають усі відомі публічні вразливість в ядрі CMS. Але, оскільки, функціональності не завжди вистачає, то перед установкою плагіна потрібно обов'язково перевіряти, наскільки вони захищені і безпечні.
  3. Доопрацювання потрібно віддавати досвідченим веб-розробникам, які мають уявлення про безпеку сайтів і джерелах проблем, тобто розуміють необхідність фільтрації вхідних і вихідних параметрів, безпечних алгоритмів аутентифікації та авторизації безпечного зберігання даних і т. п.
  4. Трафік необхідно фільтрувати. За статистикою сервісів проксі серверів трафіку, близько 50% всіх запитів йдуть від ботів, причому приблизно чверть запитів – це атаки на веб-ресурс. Фільтрація запитів до сайту блокує атаки, паразитний трафік і знижує навантаження при DDOS — і брутфорс-атаки. Фільтрувати можна як за допомогою зовнішнього сервісу (Web Application Firewall/AntiDDOS), так і модуля веб-сервера (naxsi/mod_security). Ще одна корисна функція WAF – це віртуальний патчінг вразливостей. Необов'язково (та і не завжди можливо) ставити «латки» на скрипти, але WAF може виконувати віртуальний патчінг, тобто на льоту блокувати небезпечні запити, не даючи експлуатувати вразливість. Крім сервісу та модуля веб-сервера, файрвол буває вбудований в CMS. Він, звичайно, не може бути повноцінною заміною зовнішніх сервісів WAF або AntiDDOS, але частково знижує ймовірність злому в результаті веб-атак.
  5. Необхідно використовувати плагіни та сервіси для захисту від брутфорса. Скажімо, встановлений на VPS Fail2ban через кілька невдалих спроб авторизації на деякий час блокує клієнта. Це істотно ускладнює і розтягує у часі підбір пароля.
Деякі веб-майстри вже застосовують перераховані технічні засоби і заходи захисту, і тому вважають свої сайти невразливими. Але, на жаль, сайт все одно можуть зламати і завирусовать.

Якщо CMS невразлива
Чому зламують навіть невразливі CMS на безпечному хостингу? Причина криється в тому, що існують і інші варіанти компрометації або зараження сайтів, зовсім не обов'язково, що сайт зламають через уразливості в скриптах. Наведу кілька з них:

  • З нашої практики, найпопулярніший варіант — це злом через «сусідів» по аккаунту. Наприклад, на віртуальному хостингу розміщений сайт, якого безпеки приділяється велика увагу: він працює на оновленій версії CMS, до нього застосовані технічні засоби захисту. Але на тому ж shared-акаунті може бути розміщено ще два десятки сайтів з уразливими версіями CMS, або розміщуватися стара тестова версія сайту, про яку всі давно забули, а в ній може бути відкритий завантажувач файлів або доступна без аутентифікації адмін-панель. Подібні незахищені сайти і є джерелами проблем безпеки. Через їх уразливості можна впровадити адміністратора сайту в базу даних, завантажити веб-шелл або бекдор, а потім отримати повний контроль над аккаунтом хостингу. Чому це можливо? На shared-акаунтах, де немає фізичної ізоляції сайтів один від одного, всі дані розташовані в межах загального файлового простору (у файлів аккаунта загальний користувач операційної системи), тобто скрипти одного сайту можуть читати, змінювати, видаляти скрипти, шаблони і базу даних іншого сайту на тому ж записі. Це є причиною масових взломів сайтів на акаунті, коли однотипне зараження спостерігається на всіх ресурсах віртуальної площадки.

    Це стосується не тільки віртуального хостингу, але і VPS-серверів. Часто, навіть при технічній можливості і абсолютної дешевизні, на виділеному сервері створюється один адміністративний обліковий запис (користувач admin), і всередині нього розміщується кілька десятків сайтів на різних CMS. А для злому облікового запису достатньо мати одну єдину критичну уразливість на будь-якому з цих сайтів. За пару секунд на кожен сайт буде завантажено декілька десятків шкідливих скриптів, а процес лікування буде нагадувати вычерпывание води з дірявої човни: з одного сайту прибрали шкідливий код, а він з іншого знову «перейшов» на вилікуваний. Тому одне з базових правил безпеки сайтів – ізольоване розміщення сайтів.
  • Наступний варіант злому захищеного сайту — брутфорс SFTP/FTP-акаунтів або SSH-доступів. Для своєї зручності і до радості зловмисників веб-майстри встановлюють слабкі словникові паролі, які потрапляють у ТОП-100, ТОП-1000 популярних і підбираються за пару годин.
  • Третій варіант — злом через phpMyAdmin (а також інші інструменти, якими користуються веб-розробники і адміністратори). PhpMyAdmin — це засіб адміністрування бази даних. Поширюється open source-ліцензії, зручний, простий, доступний, його ставлять на всі хостинги і виділені сервера під керуванням популярних панелей. Найцікавіше, що адресу у нього майже завжди фіксований. Тобто можна набрати ім'я_сайту/myadmin або /phpmyadmin, і відкриється форма авторизації phpmyadmin. Якщо туди ввести пароль і логін від бази даних, які можна дізнатися різними методами, ви отримаєте доступ до бази даних. А далі за допомогою SQL-запиту можна впроваджувати шкідливий код в шаблони, читати або створювати файли на диску. А це вже можуть бути бекдори, що дозволяють завантажувати довільні файли та виконувати довільний код. Багато хакери безпосередньо впроваджують код в базу даних, і при цьому не залишають ніяких слідів у файловій системі. Тобто власник сайту або веб-майстер просто не зрозуміє, яким чином вірус з'являється в коді сторінки.

    Насправді, він, часом, навіть не знає про існування phpMyAdmin, його публічної доступності та можливості злому сайту через нього.

    У читача може виникнути питання: яким чином зловмисник дізнається логіни і паролі від бази даних, адже для цього потрібно отримати доступ до файлу конфігурації CMS? Насправді, отримати дані для підключення до БД набагато простіше, ніж здається. Іноді запит в пошукову систему Google дозволяє знайти дуже багато індексовані файли, що містить різну «чутливу» інформацію. Наприклад, бекапи сайтів з файлом налаштувань, або помилково проіндексовані файли конфігурації. В якості прикладу можна взяти один старий запит з Google Hacking Database – хакерської бази даних, що містить запити до Google для пошуку проіндексованих вразливих скриптів і чутливих файлів.



    Вводимо його в рядок пошуку і отримуємо приблизно 288 тис. файлів, які містять відкритий логін, пароль, хост. Залишається просто взяти їх звідти, зайти на сторінку /myadmin (або аналогічну для конкретного хостингу) та авторизуватися для проведення операцій з базою даних.

    Другий варіант простого отримання пароля від бази даних — це пошук бекапів. Зловмисник може отримати несанкціонований доступ до резервних копій сайту, якщо вони лежать в кореневому каталозі сайту (часто їх називають backup.zip, backup.tar.g тощо) або у разі небезпечною налаштування веб-сервера, коли каталог backup відкритий для читання по прямой ссылке (а іноді його навіть індексує пошуковик). Тобто зловмисники за якимось фіксованим шляхами (в Wordpress це wp-content/uploads або /backups) можуть перебрати різні імена файлів і вивантажити бекап сайту. У цьому архіві знаходиться конфігураційний файл, в якому зберігаються необхідні доступи до бази даних.
  • Ще один варіант зараження сайту – коли веб-майстер добровільно встановлює заражений компонент. Наприклад, замість покупки плагіна або шаблону для сайту, він завантажує цей же архів з «варезных» сайтів або каталогу тем. А в цьому плагіні вже «вшитий» бекдор або шкідливий код. Природно, через деякий час такий сайт зламують.
  • І останній варіант, який рідко зустрічається у великих хостерів, але періодично виникає серед власників виділених серверів – це «рутованіе» сервера (злом сервера і отримання адміністративних повноважень). Це можливо в тому випадку, якщо програмне забезпечення, компоненти операційної системи і сервіси містять вразливості або помилки налаштування. Якщо VPS сервер не адмініструється фахівцем, то його досить швидко зламують через відомі уразливості, а потім вже, як наслідок, зламують і знаходяться на ньому сайти.
Підсумую способи злому не через веб:

  1. Перехоплення або крадіжка доступів, тобто компрометація доступів до сайту.
  2. Брутфорс-атака на сервіси: SFTP, FTP, SSH або адміністративну панель хостингу.
  3. Злом сайтів через «сусідів».
  4. Компрометація сервера хостингу, тобто отримання несанкціонованого доступу через уразливості або помилки налаштування.
Захист від злому
Як від цього захиститися?

  1. Потрібно правильно підбирати хостера, звертати увагу на використовувані технічні засоби і сервіси, на наявність ізоляції сайтів всередині акаунтів. Все це значно знижує ймовірність злому.
  2. Розміщуйте сайти ізольовано. Не економте на безпеці, не лінуйтеся створювати для сайтів окремі акаунти. В ідеалі потрібно розміщувати кожен сайт на окремому записі. Якщо це сервер, також створюйте для кожного сайту окремий аккаунт. Зараз навіть можна знайти хостинг-компанію, у якій сайти розміщуються ізольовано всередині shared-аккаунта. Таких не багато, але вони є.
  3. Використовуйте обмеження по IP або двофакторну аутентифікацію при вході в панель керування, при роботі з FTP і SSH. Потрібно обов'язково встановлювати додатковий захист, тобто обмежувати доступ лише для надійного кола осіб.
  4. Регулярно міняйте паролі. Очевидний рада, якій слідують одиниці. Це захищає у багатьох випадках, навіть при компрометації доступів. Якщо зловмисник не встиг ними скористатися, то регулярна зміна паролів дозволяє зберегти свій доступ до сайтів. Справа в тому, що ви не знаєте, чи був факт компрометації і виходити треба з песимістичного сценарію. Тому в якості превентивної міри необхідно регулярно встановлювати нові паролі.

    Крім того, важливо не просто їх міняти, а мати якусь розроблену політику безпеки, що визначає процедуру зміни паролів з точки зору частоти і стійкості. Це повинен бути спланований і підтримуваний процес.
  5. При роботі з сайтом по FTP/в адмінці використовуйте VPN для запобігання перехоплення доступів, чутливих і конфіденційних даних.
  6. Забудьте про FTP і заблокуйте його на хостингу, так як він небезпечний. Якщо на акаунті є така можливість, підключіть SFTP — це надбудова над SSH-протоколу для роботи з файлами. Зараз він підтримується практично на всіх хостингах. З точки зору роботи з файлами, різниці з FTP ви не помітите, а з точки зору безпеки – різниця колосальна.
  7. Якщо ви часто користуєтеся якимись функціями в панелі керування, то створіть окремий аккаунт з обмеженою функціональністю і винесіть ці популярні функції в цей обліковий запис. Якщо у вас його і зламають, то отримають лише обмежений доступ до управління сайтами.

Коли винний підрядник або співробітник
Часом «вразливістю», через яку зламують і заражають сайт, є сама людина. Зокрема, співробітники та підрядники, які обслуговують сайт: контент-менеджери, SEO-фахівці, веб-розробники. Які проблеми безпеки підстерігають власника сайту в цьому випадку?

  1. Недобросовісний підрядчик. Часто бувають ситуації, коли сайти віддаються на обслуговування фрілансерам, які не завжди сумлінні. Наприклад, є ймовірність, що в результаті співпраці йому щось не сподобається, здасться мало грошей, він образиться на критику і почне шантажувати власника сайту доступами. Або він просто використовує свої повноваження адміністратора і зашкодить сайт. Оскільки у підрядника є повний контроль над сайтом, він може впровадити на сторінки шкідливий код, може почати продавати на ньому посилання з біржі Sape.ru/Trustlink/и тощо, розміщувати несанкціоновану рекламу. І часом власник сайту або менеджер проекту не здогадуються, що колишній веб-майстер «паразитує» на веб-ресурсі, залишивши на ньому свої закладки.
  2. Буває, що підрядник встановлює плагіни, які містять уразливості або бекдори. Наприклад, власник сайту знаходить гарний плагін галереї для сайту і просить фрілансера купити і налаштувати цей модуль. Фрілансер знаходить такий же плагін на «варезном» сайті, бере гроші з замовника на покупку, але насправді викачує безкоштовно. У «нулленом» варіанті буде присутня якась «корисна» навантаження у вигляді бекдор або «чорних» seo-посилань. Власник сайту про це швидше за все ніколи не дізнається, тому що не буде перевіряти те, що встановив фрілансер.
  3. Витік доступів — теж дуже серйозний момент, тому що підрядники часто не замислюються про безпеку клієнтських доступів і сайтів, і недбало ними розпоряджаються. Наприклад, велике діджитал-агентство зазвичай працює за різних завдань з партнерами (субпідрядниками), яким передаються клієнтські доступи, і що з ними роблять партнери, ніхто не знає. Ці доступи можуть передаватися відкрито через популярні месенджери небезпечним мережевому підключенню, зберігатися в текстових файлах, зберігати в різних незахищених CRM і т. п. В результаті шансів розкриття даних доступів маса, і досить складно буде знайти причину компрометації.

    Живий приклад — це коли такий партнер великого діджитал-агентства сидить у кафе, оновлює сайт по FTP, а де-небудь поруч з ним влаштувався хакер, який перехоплює трафік в тій же WIFI мережі. Або роутер, через який працює фахівець в коворкінг-кафе, заражений трояном. Шкідливе ПО збирає всі ці доступи і передає зловмисникам. Зараз таке вже не рідкість, перехоплення трафіку у відкритих мережах – операція дуже проста і ефективна. Тому працювати в публічному місці без активного VPN – це майже злочин.
  4. І останній варіант — використання соціальної інженерії. Скажімо, підряднику, приходить фішінговий листа: «Ваш сайт зламали! Будь ласка, терміново змініть пароль!» і посилання. Наляканий виконавець в замішанні клацає по посиланню, йому відкривається знайома форма авторизації CMS, але він не помічає, що сторінка завантажена з підставного сайту зловмисника. Вводить пароль і останній благополучно надсилається хакеру.
Що робити? Як захиститися?
Для захисту від подібних інцидентів і проблем власник сайту поряд з технічними засобами повинен впроваджувати та організаційні заходи захисту.

  1. Керувати доступами. Власник повинен знати, коли і як їх змінювати, у кого вони є, кому їх передавати і в якому обсязі. Це захистить від багатьох проблем.
  2. Проводити аудит безпеки після виконання робіт підрядником. Файли, бази і сторінки сайту можна перевірити самостійно з допомогою доступних сканерів або інструментів для контролю цілісності, а можна звернутися до відповідних фахівців з безпеки.
  3. Інструктувати підрядників. Обов'язково потрібно скласти керівництво по безпечній роботі з сайтом для співробітників і підрядників і проінструктувати по ньому. Багато фахівці можуть чудово виконувати свої завдання, але не замислюватися про безпеку сайту.
  4. Працювати за договором і з перевіреними компаніями. Співпраця з фрілансерами часто обертається проблемами безпеки з сайтом.
висновок
Безпека – це безперервний процес, якому потрібно пильну увагу. Тільки у випадку комплексного підходу до безпеки, що включає в себе обов'язкове використання технічних засобів та організаційних заходів, ваш сайт буде надійно захищений.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.