До моменту звернення в нашу компанію веб-майстер, як правило, вже намагався впоратися з проблемою самостійно: він відкотив сайт до незараженной, на його думку, версії; оновив CMS; поміняв всі паролі і навіть спробував видалити шкідливий код. Але сайт чомусь заражався знову і знову.
В ході бесіди з веб-фахівцями з'ясовувалися окремі нюанси, але так чи інакше помилки, що відбуваються новачками, були типові. У даній статті ми розповімо про основні з них. Обмовимося відразу, ми не проводили спеціальних досліджень і опитувань, а всього лише систематизували інформацію, отриману нами в результаті багаторічного практичного досвіду по лікуванню і захисту сайтів.
Умовно всі помилки веб-майстрів можна розділити на три великі групи: до початку лікування, під час лікування і після нього. Що ж, почнемо по порядку.
Попереджений, але не озброєний
Сайт, над яким попрацював хакер, якийсь час може себе ніяк не видавати. Часто веб-ресурси заражаються в кілька етапів. На першому етапі хакер знаходить вразливість на сайті і непомітно завантажує на нього шелл. Він навіть може акуратно «заштопати» після себе пролом, щоб не віддавати шматок пирога колегам по цеху. Якщо регулярно не перевіряти сайт сканером шкідливого коду, наприклад AI-BOLIT, який визначає хакерські шелли і бекдори, то можна упустити можливість своєчасної безболісної ліквідації непроханого гостя на сайті.
Через пару тижнів хакер звернутися до веб-ресурсу знову, але вже з метою завантажити віруси, впровадити редирект або розмістити спам-розсильників. З того моменту як на сайті почнуть заробляти до моменту, коли ви це виявите, може пройти досить багато часу - все залежить від масштабу лиха. За розсилку спаму або розміщення фішингових сторінок хостер може заблокувати відразу, пошуковики можуть також оперативно відреагувати на вірусний код на сторінках або дорвеи. Але іноді зараження проявляється в уповільненої, не настільки помітною формі. Начебто періодично скаржаться відвідувачі, іноді виникає повідомлення в панелі веб-майстра про те, що на сайті вірус. Але вже на наступний день користувачі спокійно продовжують здійснювати покупки в вашому інтернет-магазині, а пошуковики мовчать. В результаті веб-майстер «розслабляється» - приємніше думати, що у поскаржився користувача заражений браузер, а пошукова система просто помилилася.
На жаль, в реальності все не так просто. Як вже говорилося, існують різні види зараження. Вірус може бути активним в певні дні, певні години, для користувачів певних пристроїв і регіонів. І якщо пошуковий бот перевіряє ваш сайт в момент, коли зловредів неактивний, то повідомлення з панелі веб-майстра зникне.
Тому не ігноруйте будь-попередження, що стосується безпеки веб-проекту. Навіть якщо вас не заблокує хостер або пошукова система, є й інші, більш серйозні наслідки - адже доступ до вашого сайту є у кого-то ще крім вас. І це може бути доступ не тільки до файлів і бази даних, але і до резервних копій. А значить є ризик втратити сайт без можливості його відновлення.
У нашій практиці були випадки, коли подібне ігнорування ситуації закінчувалося шантажем з боку зловмисника - хакер, який отримав адміністративний доступ до веб-ресурсу, вимагав гроші, погрожуючи знищити веб-проект повністю, і наша команда підключалися вже в «пожежному» режимі для термінового вирішення проблеми .
Є підозра на шкідливу активність - не полінуйтеся перевірити сайт на предмет злому і зараження.
Некоректна робота зі сканером шкідливого коду
Рада тут може бути тільки один, якщо відчуваєте, що поки не готові вирішити проблему самостійно - зверніться до фахівців, замовте послугу на комерційній основі, а потім проконсультуйтеся у виконавця щодо ваших підозр.
Крім того, розробники інструментів для пошуку вірусів на сайті, як правило, можуть проконсультувати вас щодо звіту безкоштовно (до певного рівня). Не ризикуйте, збираєте знання, отримуйте нові - це допоможе справлятися з проблемою в майбутньому самостійно.
Обман пошукових систем
Так чи інакше успішність веб-проекту багато в чому залежить від його взаємовідносин з пошуковими системами. І, напевно, одне з найбільш непотрібних занять намагатися їх обдурити.
Припустимо, сайт виявився у списку «загрожують безпеці комп'ютера або мобільного пристрою ...». В панелі веб-майстра позначаться сторінки, на яких був виявлений шкідливий код. Але замість того, щоб шукати джерело зараження деякі фахівці видаляють заражені сторінки, що зовсім не вирішує проблеми безпеки. Гірше того, іноді веб-майстри цілком блокують доступ до сайту за допомогою правил в robots.txt, вважаючи, що це допоможе уникнути перевірки сайту антивірусний ботом.
Заборона індексації - небезпечний крок. По-перше, це може привести до випадання сторінок сайту з пошукового індексу, а, по-друге, правила, які поширюються на пошукові механізми, не працюють для роботів антивірусних сервісів.
Та й знову ж, не можна залишати без уваги той факт, що сайт вже експлуатується зловмисниками - адже поки ви витрачаєте час на обман Яндекса і Google, ваш веб-проект знаходиться під серйозною загрозою.
Лікування сайту за допомогою антивірусу для комп'ютера
Початківці веб-майстри часто намагаються лікувати сайти, використовуючи антивірусники для десктопів. Веб-майстер робить бекап сайту і «нацьковує» на нього антивірусне програмне забезпечення, призначене для комп'ютера. Такий підхід не дасть бажаних результатів, оскільки віруси, написані для сайтів, відрізняються від вірусів, що заражають комп'ютери користувачів, і антивірус для робочого столу не зможе знайти більшість вірусів у файлах і базі даних сайту.
Для перевірки сайту необхідно використовувати спеціалізовані сканери вредонсоного коду, база даних яких регулярно поповнюється новими екземплярами шкідливих елементів.
Відновлення сайту з резервної копії замість лікування
Нерідко при появі вірусу на сайті веб-майстра намагаються розв'язати цю проблему простим відкатом сайту до незараженной версії. І продовжують робити це кожен раз, як тільки відбувається нове зараження. Розберемося. А що вважається чистою версією сайту? Адже, як ми вже знаємо, хакерський шелл може перебувати на сайті досить довго і ніяк себе на проявляти. Тобто точкою повернення стає зламаний сайт тільки без редиректу або спам-розсильників, але вже з шеллом?
Припустимо, що відновити чистий сайт з резервної копії вдалося. Але питання безпеки залишається відкритим: якщо на ваш сайт несанкціоновано проникли один раз і ви нічого не зробили для запобігання цій ситуації, то буде і другий раз, і третій.
Відкат сайту - досить незручний, непрактичний і вже точно небезпечний варіант. Будь-яке повернення назад означає позбавлення всіх ваших праць за останні дні - відмова від змін, які ви внесли в скрипти, недавно встановлених плагінів, нових текстів і фотографій. Зате ви зберігаєте можливість несанкціонованого проникнення. Сумнівна тактика боротьби з вірусами.
Справа навіть не в тому, що веб-майстер недоцільно витрачає свій час, «вичерпуючи воду з дірявий човен» (як правило, власник сайту видаляє код вручну, тоді як хакер підсаджує шкідливий в автоматичному режимі) - сайт знаходиться під загрозою, він маріонетка в руках хакера.
Головне завдання в ситуації, що склалася - не просто позбутися від вірусу на сайті, але вжити необхідних заходів по ліквідації вразливостей в плагінах і скриптах. У 80 випадках з 100 повторне зараження відбувається в результаті експлуатації хакером все тих же проломів.
Найбільш популярні типи уразливості / атак, що приводять до злому сайту, можна розділити на наступні типи (повна класифікація вразливостей доступна на сайті OWASP TOP 10):
RCE (Remote Code Exection) - віддалене виконання шкідливого коду;
AFU (Arbitrary File Upload), які дозволяють завантажувати файли на хостинг, ці файли можуть бути виконуваними скриптами;
SQL-ін'єкції, за допомогою яких виконуються маніпуляції з базою даних (додавання нового адміністратора сайту, витяг паролів, вставка вірусів, "злив" бази тощо);
XSS (Cross Site Scripting) - атака, в результаті якої код впроваджується на сторінку сайту, і зловмисник отримує несанкціонований доступ до даних: «куки», сесійним ключам, значенням полів і т. П
Як захиститися:
• Віддалене виконання коду виправляється в вихідному коді скриптів (установкою патчів безпеки, виправлення помилок розробника). Частково проблему можна виправити, використовуючи віртуальний патчінга засобами WAF (Web Application Firewall), який блокуватиме запити, що містять виконуваний код або шкідливі фрагменти.
• Проблем з AFU можна уникнути шляхом заборони виконання PHP-скриптів в каталогах завантаження. Для цього розміщується спеціальний конфігураційний файл .htaccess, який буде блокувати доступ до файлів, крім довірених, або відключає обробку PHP-сценаріїв.
• Питання з SQL-ін'єкціями вирішується за допомогою віртуального або реального патчінга вихідного коду (виправлення помилок розробника, який недостатньо добре фільтрує вхідні дані скрипта). Для віртуального патчінга також підійде WAF, який відфільтрує запити з SQL ін'єкціями.
• Для захисту від XSS необхідно прописати набір правил в .htaccess файлі або налаштувати веб-сервер, щоб в HTTP заголовках містилися спеціальні параметри, які блокують можливість проведення атаки.
Небезпечне розміщення сайтів на хостингу
Чи не використовуєте сайт в роботі, немає часу на його перевірку і захист? Заблокуйте або видаліть його з хостингу. Можливо, це позбавить вас від великих проблем з безпекою в майбутньому.
Ну, і останнє, не забувайте про елементарні правила безпеки при роботі з сайтами. Вони прості і зрозумілі, але, на жаль, часто ігноруються початківцями веб-майстрами:
Регулярно перевіряйте комп'ютери, з яких виконуєте адміністрування сайту, комерційними антивірусами;
Не забувайте міняти паролі від хостингу і адміністративної панелі сайту, використовуйте складні комбінації;
Не зберігайте паролі в програмах (ftp-клієнтів, браузері, електронною поштою);
Зберігайте резервні копії сайту не тільки на хостингу, а й локального на комп'ютері;
Працюйте в відкритих мережах через захищене з'єднання (VPN);
Відмовтеся від небезпечного FTP - переходите на безпечні SFTP і SCP протоколи.
Завжди пам'ятайте, краще захистити сайт превентивно, не чекаючи, коли слабка ланка на вашому сайті знайде хакер.
