Одного разу хакери атакують ваш сайт

З вами такого не станеться? DDDDDDDD

Керуючи понад 300 веб-сайтами, час від часу трапляються різні нештатні ситуації. Іноді вони досить гарячі, але часто це повна банальність. Якщо ви, як і я, в минулому спокушалися програмуванням, а також знаєте, що [програмування - це біль] (http://borisovo.cz/programming-sucks-cz.html), ви напевно зі мною погодитеся.

У лещатах злих хакерів

Коли веб-додаток стає популярним, він стає спокусливою мішенню для хакерів. Їх мотивація, як правило, полягає не в тому, щоб зруйнувати весь веб-сайт, а навпаки. Насправді, хакери хочуть, щоб ви, як адміністратор сервера, про них нічого не знали. Хороший хакер вичікує місяцями, спостерігає за веб-сервером і отримує найцінніше - ваші дані.

Щоб захистити своїх користувачів, необхідно шифрувати всі дані та мати кілька рівнів захисту. Для паролів використовуйте одну з повільних функцій, таких як Bcrypt + salt, Argon2, PBKDF2 або Scrypt. Міхал Спечек вже писав про [рейтинг безпеки] (https://pulse.michalspacek.cz/passwords/storages/rating#slow…), і я дякую йому за доповнення до статті. Як власник сайту, ви повинні наполягати на правильному хешуванні пароля при обговоренні з програмістом. Інакше ви будете плакати, як багато людей до вас, які також обманювали себе, що їх це не стосується.

Чи можете ви сказати, коли вас атакують?

Я помітив, що коли веб-сервер досягає певного порогу відвідуваності (в Чехії це близько 50+ відвідувачів на день), на нього починається серія атак, спрямованих на нього з нізвідки. Зробити це непросто, зловмисник завжди має перевагу, адже він може обрати, з якої частини інфраструктури почати атаку, а ви - як власник веб-сервера - маєте вчасно це розпізнати, захиститися і бути краще підготовленими до цього наступного разу.

Скільки нападів було здійснено на Вас, наприклад, за останній місяць? Ви точно знаєте? Скільки з них ви захистили? Чи має хтось ще доступ до вашого сервера?

Що робити, якщо на вас прямо зараз хтось нападає? А тепер... а тепер ще й...?

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

Те, що найкраще працювало для мене останнім часом:

• Коли зловмисник не знає, де фізично знаходяться ваші сервери, він опиняється в набагато складнішому становищі. Інформація про фізичну архітектуру може бути дуже добре прихована за допомогою [Cloudflare] (https://www.cloudflare.com/), який забезпечує проксі-сервер (і двостороннє шифрування) всієї мережевої комунікації. Він також має низку інших переваг, таких як більш швидке отримання інформації з-за кордону, автоматичний захист від DDOS-атак, стиснення ресурсів і, не в останню чергу, автоматичне блокування несанкціонованих відвідувачів. Я використовую Cloudflare для всіх своїх сайтів (і майже кожен проект використовує різні технології).
• Логування помилок. Завжди і в усьому. Швидше за все, ваш додаток містить багато помилок, допущених вашим програмістом. Будь то неперехоплені виключення, помилки програми, SQL-ін'єкції і так далі. Якщо ви програмуєте на PHP і не розбираєтеся в логуванні, є достатньо проблем, які вловлять Tracy (і, можливо, інші інструменти, такі як Sentry) і логи доступу на самому сервері. Логування помилок - це не просто приємно, це обов'язково. Я реєструю помилки на всіх сайтах, які я активно підтримую, і інформація про нові помилки надходить на мою електронну пошту, щоб я одразу ж про це дізнався.
• Безпечна та оновлена платформа**. Чи є у вас на сайті WordPress? Чи знаєте ви, як його правильно оновити? Чи знаєте ви всі ризики, з якими стикаєтесь? Коли щось є безкоштовним, це майже завжди відбувається за рахунок чогось іншого. Особисто я для розробки додатків використовую Nette framework версії 3, яку щотижня оновлюю і активно шукаю вразливості безпеки для виправлення. Подібно до того, як ви регулярно обслуговуєте свій автомобіль, ви повинні регулярно обслуговувати свій веб-сайт, принаймні раз на місяць. Обслуговування сайту включає оновлення всіх зовнішніх бібліотек та постійний моніторинг журналів. Якщо ви використовуєте стару версію бібліотеки, дуже ймовірно, що зловмисник знає про уразливість і спробує її використати. Питання в тому, коли Велика кількість людей в моєму регіоні неймовірним чином недооцінюють безпеку і виставляють в Інтернет контент, який дуже легко зламати і використовувати.

Насправді, навіть великі компанії припускаються помилок, навіть у таких дрібницях, як XSS (міжсайтова скриптова атака).

Питання не в тому, чи зламає хтось коли-небудь ваш сайт. Питання в тому, коли це станеться і чи будете ви достатньо підготовлені до цього. Можливо, хакер має доступ до вашого сервера місяцями, а ви про це не знаєте (поки що).

Що робити, коли трапилася біда

Коли ви дізнаєтеся про роботу хакера, зазвичай буває занадто пізно, і хакер вже зробив все, що йому потрібно було зробити. Дуже ймовірно, що він розмістив шкідливе програмне забезпечення по всьому серверу і має принаймні частковий контроль над машиною.

Це хаотичний тип проблеми і діяти потрібно швидко.

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

Якщо ми вирішимо повернути на сервер останню робочу резервну копію, ми дуже допоможемо зловмиснику. Він вже знає, як зламати ваш сервер і ніщо не заважає йому зробити це знову через кілька годин. Крім того, резервна копія, ймовірно, містить шкідливе програмне забезпечення або якийсь інший тип вірусу.

Хоча це дуже непопулярний варіант серед моїх клієнтів, особисто я завжди рекомендую спочатку повністю видалити сайти на WordPress, або будь-які системи, які клієнт не оновлює і які мають багато загроз безпеці. Наприклад, якщо ви розміщуєте на одному сервері 30 сайтів, яким більше 2 років, то практично гарантовано, що хоча б один з них містить ту чи іншу форму вразливості.

Якщо Ви не розумієте питання, краще звернутися до відповідного фахівця на ранній стадії, який має глибокі знання з Вашого питання і розуміє речі в широкому контексті.

Етична примітка:.

Якщо ви керуєте веб-сайтом клієнта, у якого стався інцидент з безпекою, ви зобов'язані проінформувати його про це. У разі витоку будь-яких даних (таких як паролі, але часто набагато більше), ви також повинні повідомити кінцевих користувачів про те, що їхній пароль є публічною інформацією і вони повинні змінити його скрізь. Якщо ви використовуєте повільну функцію хешування (наприклад, Bcrypt + salt), ви значно ускладните зловмиснику злам паролів (на жаль, Bcrypt-паролі можна зламати). Якщо ви бажаєте регулярно отримувати інформацію про те, чи не був зламаний ваш обліковий запис, рекомендую зареєструватися на сервісі Have I been pwned?. Для отримання додаткової інформації про [порушення безпеки] (https://m.uoou.cz/vismo/zobraz_dok.asp?id_ktg…), будь ласка, відвідайте веб-сайт OOO.

Атомні звички

За останні півроку я закінчив читати книгу [Atomic Habits] (https://www.melvil.cz/kniha-atomove-navyky/), яка відкрила мені очі. Він описує процес поступового поліпшення на 1% щодня, що в довгостроковій перспективі принесе багато користі.

Оскільки до мене звертаються компанії та приватні особи на різних стадіях технологічної заборгованості, то хотілося б узагальнити найгірше:

• FTP для зв'язку з сервером не має сенсу. Це незахищений протокол, який контролюється паролем. Якщо ви хочете надати комусь доступ, вони повинні знати пароль і можуть робити те ж саме, що і ви. Якщо ви хочете забрати у нього доступ, то не зможете, єдиний спосіб - змінити пароль. Краще повністю перейти на SSH і використовувати ключі RSA. Досить часто я дивуюся, що сьогодні навіть компанії вирішують цю проблему. Ніколи не складайте одну таблицю всіх паролів. І вже точно ніколи не спільний для всієї команди!
• Вихідний код знаходиться в Git**, дані в базі даних та статичний контент (зображення, PDF, ...) у файлах на диску. Вибір неправильного сховища даних погіршує дизайн і безпеку програми. URL-адреса до PDF-файлу (наприклад, з рахунком-фактурою) повинна містити випадково згенерований вміст, який відомий лише одержувачу. Для надзвичайно чутливого контенту (наприклад, банківської виписки) важливо зашифрувати вміст на диску і надавати його тільки після входу в систему.
• Непублічні частини сайту повинні містити МЕТА-заголовок noindex та nofollow, щоб уникнути індексації Google. Конфіденційний контент, який не повинен бути відомий вашим конкурентам, повинен бути захищений паролем.
• Вимкніть на своєму сервері лістинг вмісту каталогу. Якщо його налаштувати неправильно, весь сайт може бути обстежений машиною з метою пошуку конфіденційних файлів.
• Проект "Корінь"! Ніколи не повинно бути прямого посилання на конфігураційні файли. Наприклад, [Nette does it right] (https://doc.nette.org/cs/3.0/quickstart/getting…) з першого підручника. Те ж саме стосується і [загальнодоступних git-репозиторіїв] (https://smitka.me/open-git/). Цей тип вразливості надзвичайно легко недооцінити, а наслідки, як правило, трагічні.
• Помилка також може виникнути внаслідок ненавмисної помилки розробників. Дуже важливо, щоб на кожну зміну жива людина робила код-рецензію. Багато помилок виявляються PHPStan або подібними інструментами ще до того, як людина побачить код.
• Ніколи не надсилайте паролі в читабельному вигляді електронною поштою, завжди є інший спосіб вирішити цю проблему.
• Проблеми безпеки в старих версіях бібліотек та програмного забезпечення. Роботи щосекунди сканують Інтернет та атакують відомі дірки в безпеці (SQL ін'єкції, XSS, CSRF, ...). Багато відомих дірок мають старіші версії WordPress.

Існує набагато більше вразливих місць, і проблеми варіюються від проекту до проекту. Якщо вам потрібно зробити швидкий аудит сервера, я рекомендую використовувати [Maldet] (https://www.rfxn.com/projects/linux-malware-detect/), а потім найняти відповідного фахівця, який допоможе вам зробити [повний аудит сайту] (https://baraja.cz/audit-webu), і не тільки з міркувань безпеки.

Інженери з безпеки як пластик в океані - тільки назавжди. Звикайте до цього.

Принцип дії і реакції природи

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

Як мисляча людина (проектувальник, розробник, консультант) ви маєте велику перевагу - бути дієвим, тобто заздалегідь знати певну частину великих ризиків і активно запобігати їхньому настанню в першу чергу. Ви ніколи не зможете запобігти всім помилкам, але ви можете принаймні пом'якшити їх наслідки або створити механізми контролю, які виявлятимуть проблеми на ранній стадії, щоб у вас був час відреагувати.

Більшість атак відбуваються протягом тривалого періоду часу, і якщо ви ведете журнал, у вас, як правило, буде достатньо часу, щоб виявити проблему.