Всі ми так чи інакше хотіли б бути впевнені в тому, що наш сайт чи блог ніхто не зможе зламати. Але на жаль, реальність така, що будь-яка система вразлива, як би сильна вона не була б захищена. Все впирається лише в ресурси і в завзятість зломщика... Хм... Щось мене не туди потягнуло... Вважатимемо це передмовою =)
Нещодавно я писав про те як. Але припустимо ви взяли вже готову CMS і не знаєте, як там реалізована завантаження, та й взагалі весь захист. Звичайно, особливо допитливі та грамотні розробники вивчать код цієї ЦМС перш ніж поставлять на свій сайт. Але що робити тим, хто не має стільки часу?
Добре, або припустимо ви з тих хто вважає що безпека та правильне налаштуваннясервера зайвої не буває? Якщо так то ласкаво просимо під кат.
Ні, у статті ви не знайдете якийсь супер пупер плагін, що фільтрує всі дані, який потрібно приєднати до всіх файлів. Моя ідея полягає у використанні директиви auto_prepend_fileта спорудження списку дозволених файлів… Але загалом читайте самі…
Дана ідея у мене давно сиділа в голові, але нарешті у мене дійшли руки, хоч нічого складного тут і нема, і я зміг цю систему реалізувати та написати статтю.
Принцип роботи
Як я вже говорив вище, система заснована на роботі директиви auto_prepend_fileв php.ini. Відповідає вона за встановлення скрипта, який буде виконуватись ПЕРЕД виконанням основного.
Наприклад, ви відкрили index.php, а перед його виконанням запускається файл, зазначений у auto_prepend_file. Суть у тому, що у цьому скрипті ми зможемо контролювати подальшу роботуінших скриптів. Грубо кажучи, продовжити роботу та запустити запитаний скрипт, або завершитися відразу ( die()).
Наприклад ситуація - зловмисник залив на ваш сайт шелл через якусь вразливість і намагається його відкрити в браузері. А замість його шелла, йому, без жодних причин, віддається, ось така ось помилка:
Мене б подібне ввело б у ступор.
Для роботи моєї системи, потрібен список дозволених файлів, доступ до файлів, відсутнім у цьому списку буде блокуватися.
(Не знаю чи потрібна ця діаграма, начебто б і так все має бути зрозумілим…)
Звичайно складати такий список вручну — справа не шляхетна, тому я дійшов висновку, що має сенс реалізувати так званий режим навчання. Режим у якому всі звернення до всіх скриптів будуть заносити автоматично до списку дозволених файлів.
Що дає? Ви можете запустити цю систему в режимі навчання та продовжити користуватися своїм сайтом. У міру того як ви ним користуватиметеся, ваша база буде поповнятися тими сторінками, якими ви користуєтеся (вибачте за каламбур). І допустимо через місяць - інший у вас у списку будуть утримуватися всі файли які мають відношення до вашого сайту (до яких ви безпосередньо зверталися).
Причому зауважте, у списку будуть лише ті файли, з якими ви безпосередньо працюватимете. Звичайний середньостатистичний движок сайту має купу файлів, що підключаються (з класами, з функціями, бібліотеки, модулі та інше), ці файли в цей список не потраплять, і доступ до них надалі буде блокуватися на рівні нашого захисту (звичайно середньостатистичні движки мають захист від прямого запуску, але раптом десь цей захист пропущено).
Що вміємо
Так як це концепт, то й уміємо ми небагато.
- Блокування невирішених скриптів (власне основна функція). Але знову ж таки це налаштовується, можна не блокувати з'єднання, а тільки повідомляти адміна по email
- Повідомлення про нелегітимні запити адміністратору по email (короткий звіт або повний звіт, останній включає заголовки пакета та дані POST запитуякщо такі є)
- Можна вказати IP адміністратора, який матиме доступ до будь-яких скриптів, тобто. дана системайого не зачіпатиме (ці IP не братимуть участі в режимі навчання). Наприклад, тепер не треба закривати .htaccess-ом софтини типу PhpMyAdmin, SupexDumper та інші системні утиліти.
- Ксаті IP адреси підтримують простенькі маски =)
- Повністю прокоментований код, і детально описана кожна директива конфігурації
- Хз, що ще…
Налаштування
Тепер про те, як вбудувати цей захист у ваш сайт.
Для цього вам потрібний доступ до файлу php.ini
- Спочатку скачуємо сам скрипт: PrependSecuritySystem
- Розпаковуємо вміст архіву (data.txt і main.php) в якусь папку на сервері, бажано в папку не доступну з Інтернету (не обов'язково, тому що працювати буде в будь-якій, це має сенс щоб прибрати скрипт подалі від очей хакера)
- Відкриваємо файл main.php та редагуємо налаштування. Необхідно обов'язково поміняти ip адресу та email адміну. Інші налаштування ж - за вашим бажанням.
- Встановлюємо права доступу до розпакованих файлів. Під ніксами бажано змінити власника для обох файлів, відмінного від користувача з якого працює веб сервер. Для файлу main.phpпотрібно заборонити запис для всіх. Для файлу data.txtнеобхідно встановити права на читання та на запис для всіх (це тимчасово, на період навчання)
- Відкриваємо php.iniі вписуємо наступне:
auto_prepend_file=[шлях до розпакованого файлу main.php] - З даного моментупочинається навчання системи. Чекаємо певну кількість часу, достатню, на вашу думку, для повного навчання даної системи.
- Після закінчення навчання відкриваємо файл main.phpі редагуємо доостанку PSS_STATUS_BLOCK, встановлюємо її значення в true, зберігаємо
- Змінюємо права доступу до файлу data.txt. Забороняємо редагування даного файлудля всіх.
- Тепер система перейшла в режим блокування невирішених скриптів.
Багато кроків, звичайно, але з цим, як мені здається, впорається навіть дитина.
Якщо вам необхідно перенавчити систему (з нуля або доповнити), вам необхідно:
- Дозволити запис до файлу data.txt
- Очистити вміст data.txt (ТІЛЬКИ якщо вам необхідно перенавчити систему з нуля)
- Відредагувати доостанку PSS_STATUS_BLOCKу файлі main.php, встановивши її значення в false
- Проводимо перенавчання.
- Після закінчення перенавчання редагуємо константу PSS_STATUS_BLOCKвстановлюючи її значення назад true
- Забороняємо запис файлу data.txt
Ну а тепер про сумне
Лукавити я не буду, і тепер розповім про недоліки.
- Мабуть, головний недолік порівняно з яким меркнуть всі інші, це те, що цю систему можна обійти. Ви спитаєте: як же так? Все дуже просто, директиву auto_prepend_fileможна вказати і в .htaccess. І якщо підійти тверезо то якщо зловмисник раптом зміг залити шелл, то, напевно, він зможе залити і свій .htaccessде він може відключити оригінальну директиву.
Це працює тільки під apache, Але наприклад під nginxцей трюк не вийде (у nginx немає файлів. htaccess). АЛЕ! Під Nginx можна взагалі залити. - Зловмисник може відредагувати «дозволений» скрипт, якщо є допустимі права на це, і з цим наша система нічого, на жаль, зробити не зможе. Хіба що необхідно встановлювати правильні права на всі файли, що виконуються.
- Крім PHP є ще всякі perl, cgi та інше… з ними дана система не працює.
- Додаткове навантаження. Але це навантаження буде відчутним.
Саме тому, начебто така оригінальна система, неспроможна називатися ідеальної. Але вона цілком підійде як простий превентивний захід, який зупинить не самих упертих упертих зломщиків. Принаймні ця система зможе забрати час у зломщика на проведення атаки. Наприклад, система повідомить адміністратора про спробу злому, давши тим самим адміністратору можливість усунути вразливість, доки зловмисник розбереться з причиною його невдач.
Висновок
Все ж таки, так чи інакше, це концепт, можливо ви зможете придумати на її основі щось краще. А може вас влаштує моя система.
На мій погляд, розумного захисту багато не буває. Використовувати щось подібне чи ні, у вас на веб-сайтах вирішувати вам.
фуф. Та й написав я, майже цілий день пішов. Вибачте якщо описав дещо сумбурно. Загалом ставте ваші запитання в коментарях, я постараюся відповісти.
PS: хоч і кодив максимально адекватно, скрипт може мати баги. Тестувалося на win/apache/php 5.2 - все було прибл.
У всьому світі в аеропортах можна знайти гасло "Security is not a joking matter" (Безпека – перш за все). Таке ж гасло кожне системний адміністратормав би закріпити поряд зі своїм сервером PHP. А будь-хто, хто підключається до сервера, що знаходиться в Інтернеті, повинен вживати належних заходів захисту або ризикувати втратою даних і навіть грошей через те, що зловмисні зломщики програмного забезпеченнязможуть завдати шкоди, користуючись клавіатурою свого комп'ютера.
Розробник сайту, стурбований проблемами захисту, повинен постійно повторювати: "Не довіряйте мережі". Якщо ви турбуєтеся про захист вашого сайту, повторюйте цей вислів, розробляючи код майбутніх сторінок сайту. Будь-яка інформація, що передається на сервер по мережі (будь то URL, дані з форми HTMLабо дані, що надходять через якусь іншу мережевий порт), повинна розглядатися як потенційно небезпечна. У цій статті запропоновано кілька методів, що дозволяють убезпечити інформацію, що надходить. Необхідно не лише застосовувати ці методи, а й приділяти визначений часдля того, щоб виявити інші потенційні небезпеки та знайти способи їх запобігання.
Другим емпіричним правилом створення захищеного сайту є таке: "Мінімізуйте шкоду". Що буде, якщо написана вами програма, яка, на вашу думку, є цілком надійною, фактично виявиться вразливою? Навіть просто для того, щоб залишатися в повної безпеки, обмежуйте збитки, які міг би завдати порушник, скориставшись цією вразливістю.
Коли на ваш сайт приходять відвідувачі, вони сподіваються, що сайт містить дійсну інформацію, яка не завдасть шкоди ні їм, ні комп'ютерам, і що надана інформація буде оброблятися належним чином. Для відвідувача завжди є певний ризик порушення захисту при взаємодії з будь-яким сайтом, незалежно від того, чи це розважальний сайт, інформаційний або електронної комерції. Обов'язки захисту відвідувачів від таких ризиків покладені на проектувальника сайту. Це означає, що ви зобов'язані не тільки надійно зберігати на своєму сервері інформацію, надану відвідувачами, але й вжити заходів щодо захисту інформації, що надається, під час її передачі з комп'ютерів відвідувачів на ваш сервер.
Але ці міркування не повинні перешкоджати вашим намірам, наприклад, що стосуються виведення свого сайту електронної комерції в оперативний режим.
Можливі напади
Підключення сервера до Інтернету можна порівняти з відкриттям магазину на вулиці. Ви хотіли б мати багато відвідувачів, але, не вживаючи запобіжних заходів, можете зіткнутися з тим, що вашою безтурботністю скористаються не звичайні відвідувачі, а вельми небажані гості.
Зазвичай хакераминазивають тих, кого було б правильніше назвати зломщиками програмного захисту . У комп'ютерній спільноті хакерами захисту називають фахівців, які, користуючись вдалим збігом обставин або своїми навичками, долають захист комп'ютерних системі завдають шкоди. А хакери - це програмісти, які вміють віртуозно складати програми і здатні не тільки розумітися на складному коді, але й самостійно писати ефективний (і часто недоступний для розуміння сторонніх) код багатьма мовами. Для програміста придбання звання хакера є честю, а звання зломщика програмного забезпечення, мабуть, означає, що його власник повинен стежити за нотатками у рубриці "Розшукується".
Не розуміючи того, наскільки принизливим є звання зломщика програмного забезпечення, багато програмістів-початківців вступають на цей шлях, вдаючись до використання інструментальних засобів і сценаріїв, які вони знаходять у веб. Таких початківців зломщиків називають script-kiddie або по нашому кулхацкерами. Ці люди часто самі майже не розуміють, що роблять. Зазвичай саме така категорія порушників стоїть за примітивними атаками, такими як компрометація сайту, XSS та SQL-ін'єкції.
Компрометація сайту та атаки XSS
Випадки компрометації сайту, які частіше бувають більшою мірою неприємними, ніж дійсно шкідливими, досить поширені, оскільки багато сайтів відкривають для зломщика програмного захисту можливість оголосити всьому світу про те, що він зумів досягти своєї мети. Для компрометації неправильно спроектованого веб-сайту іноді достатньо скористатися одним лише веб-браузером. Розглянемо, наприклад, таку програму:
Сторінка із простою формою додавання коментарів ".$row["text"].""; } } ?>Ця програма реалізує систему коментарів у дуже примітивній формі (якщо ви вивчаєте мій посібник з PHP з початку, то можливо ви ще не знайомі з операціями роботи з базами даних; якщо це так, то рекомендую вам повернутися до цієї статті після ознайомлення з відповідним матеріалом з MySQL).
Читаючи цей код, досвідчений програміст починає почуватися не зовсім впевнено (пам'ятаєте – "Не довіряйте мережі"). Така програма набуває даних форм, які, згідно з очікуваннями, повинні містити текст коментаря. Цей текст надається змінною $comment і зберігається у базі даних для відображення перед наступними відвідувачами. Якщо введені дані будуть такими, на які ми очікуємо, то проблеми не виникнуть.
А тепер поставте себе на мить на місце кулхацкера і уявіть, що станеться, якщо у вхідних даних будуть дескриптори HTML. Ця проста програмамеханічно вставить такі дескриптори у сторінку, що формується, і ця спотворена сторінка розгортатиметься в браузерах інших відвідувачів замість звичайної. Одним із дескрипторів, які можуть виявитися особливо небезпечними з точки зору захисту даних, є дескриптор.
Завантаження...