Модуль 30

Обмеження доступу за IP

Ось готовий урок, створений у стилі CS50, спеціально для тебе. Пристебни ремені, ми починаємо! 🚀

🛡️ Урок: Обмеження доступу за IP

(Або: Як не пустити чужинців на вечірку)

1. 🔥 Вступ: Проблема та мотивація

Привіт, друзі! 👋

Уявіть ситуацію. Ви створили геніальний стартап. У вас є "Адмінка" — панель керування, де можна бачити всіх користувачів, видаляти замовлення і, скажімо, нараховувати собі мільйони бонусів.

Звісно, ви захистили її паролем. Пароль складний: Tr0ub4dor&3. Але ось питання: чи хотіли б ви, щоб хакер з іншого кінця світу взагалі мав можливість побачити поле для введення цього пароля?

Навіщо давати комусь шанс підбирати ваш пароль, якщо ви точно знаєте, що ви (адміністратор) сидите зараз у своєму офісі в Києві, а не в інтернет-кафе в Ріо-де-Жанейро?

Це як домофон у під'їзді. * Логін/Пароль — це ключ від квартири. * IP-обмеження — це консьєрж, який навіть не пустить підозрілого незнайомця до ліфта, бо "його немає в списку мешканців".

Сьогодні ми навчимося бути цим консьєржем. Ми побудуємо цифровий фейс-контроль.

2. 🧠 Теоретична база (без нудних лекцій)

Давайте розберемося, як це працює "під капотом".

Кожен пристрій у мережі має адресу — IP-адресу (Internet Protocol Address). Це як поштова адреса вашого будинку, тільки цифрова (наприклад, 192.168.1.1 або 203.0.113.5).

Коли ви стукаєтесь на сервер (відкриваєте сайт), сервер бачить, звідки ви прийшли. Він знає ваш IP.

Два головні підходи (запам'ятайте їх):

  1. Whitelist (Білий список) ⚪️:
    • Логіка: "Заборонено всім, КРІМ ось цих друзів".
    • Використання: Для найважливіших зон (адмінки, бази даних, внутрішні API). Це найбезпечніший метод.
  2. Blacklist (Чорний список) ⚫️:
    • Логіка: "Дозволено всім, КРІМ ось цього хулігана".
    • Використання: Щоб заблокувати спамерів, ботів або конкретних шкідників.

Як це працює технічно?

Уявіть, що ваш веб-сервер (наприклад, Nginx або Apache) — це охоронець на вході в клуб. 1. Приходить запит. 2. Охоронець дивиться на бейдж відвідувача (IP-адресу). 3. Звіряє зі списком. 4. Якщо IP "зелений" — пропускає. Якщо "червоний" — каже 403 Forbidden (Доступ заборонено) і навіть не будить вашу програму.

💡 Інтуїтивно зрозумійте: Обмеження за IP — це перший ешелон оборони. Це не замінює паролі, це доповнює їх.

3. 🧪 Приклади (від простого до реального)

Ми будемо використовувати синтаксис Nginx, оскільки це найпопулярніший веб-сервер у світі, але логіка однакова всюди.

Приклад 1: "Мій приватний бункер" (Whitelist)

Припустимо, ми хочемо закрити доступ до папки /admin для всіх, крім вашого комп'ютера (IP: 1.2.3.4).

location /admin {
    allow 1.2.3.4;  # Пускаємо тільки мене
    deny all;       # Всім іншим — "до побачення"
}

🛑 Питання до вас: Що станеться, якщо я поміняю рядки місцями? Спочатку напишу deny all, а потім allow 1.2.3.4?

(Подумайте секунду...)

Відповідь: Вас заблокує! Сервер читає правила зверху вниз. Як тільки він бачить deny all, він блокує запит і припиняє читати далі. Порядок має значення!

Приклад 2: "Блокуємо настирливого бота" (Blacklist)

У вас публічний сайт, але якийсь один IP (5.6.7.8) постійно намагається зламати вашу форму реєстрації.

location / {
    deny 5.6.7.8;   # Ти не пройдеш!
    allow all;      # Всі інші — заходьте
}

Тут ми спочатку відсіюємо поганого хлопця, а всім іншим дозволяємо вхід (хоча allow all у Nginx часто йде за замовчуванням, але краще бути явним).

Приклад 3: "Весь офіс у справі" (Підмережі/CIDR)

Що, якщо у вашій компанії 100 співробітників? Вписувати 100 IP-адрес — це пекло. Зазвичай офісні мережі мають спільний діапазон (підмережу). Наприклад, 192.168.1.0/24.

location /internal-wiki {
    allow 192.168.1.0/24; # Пускаємо будь-який IP від 192.168.1.1 до 192.168.1.254
    deny all;
}

Це як сказати охоронцю: "Пускай усіх, хто приїхав на корпоративному автобусі".

4. 🛠 Практична частина

Час розім'яти пальці! Уявіть, що ви налаштовуєте безпеку для банку.

🔹 Завдання 1: "Фортеця самотності" Напишіть конфігурацію (псевдокод або Nginx), яка дозволяє доступ до ресурсу /vault тільки з двох IP-адрес: вашої (10.10.10.5) та вашого напарника (10.10.10.6). Всім іншим — заборона.

🔹 Завдання 2: "Робота над помилками" Junior-розробник написав такий код для захисту адмінки:

deny all;
allow 123.123.123.123;

Чому адміністратор з IP 123.123.123.123 дзвонить вам у сльозах і каже, що не може увійти? Виправте код.

🔹 Завдання 3: "Забанити конкурента" Ваш сайт доступний усьому світу, але конкуренти з підмережі 45.45.0.0/16 парсять ваші ціни. Заблокуйте тільки їх, залишивши сайт доступним для інших.

🔹 Завдання 4: Міні-кейс (Python/JS логіка) Уявіть, що ви пишете не конфіг сервера, а код на Python (Flask/Django) або Node.js. До вас приходить запит request. У об'єкта request є поле remote_addr. Напишіть функцію check_access(request), яка повертає True, якщо IP починається на 192.168., і False в інших випадках.

🔹 Питання "А що, якщо..." Ви налаштували "Білий список" для свого домашнього IP. Ви поїхали у відпустку до готелю і намагаєтесь зайти в адмінку. Що станеться? Як вирішити цю проблему заздалегідь? (Підказка: VPN).

5. 💡 Мислення як у розробника

Ось тут ми відокремлюємо новачків від профі. У чому підступ?

1. Динамічні IP

Більшість провайдерів дають звичайним людям динамічні IP. Сьогодні у вас 85.10.10.10, ви перезавантажили роутер — і у вас 85.10.20.20. * Помилка новачка: Жорстко прописати свій домашній IP в whitelist. * Результат: Зранку ви самі себе заблокуєте. * Рішення профі: Використовувати VPN зі статтичною IP-адресою для входу в адмінку. Ви підключаєтесь до VPN, стаєте "своїм", і система вас пускає.

2. Проблема "X-Forwarded-For" (Дуже важливо!)

Якщо ваш сайт стоїть за Cloudflare або балансувальником навантаження (Load Balancer), то для вашого сервера всі запити будуть приходити від IP-адреси Cloudflare, а не від реального користувача. * Як думає профі: Треба дивитися не на пряму IP-адресу з'єднання, а на спеціальний заголовок X-Forwarded-For, де записано ланцюжок реальних IP.

3. IP можна підробити (спуфінг)

Це складно для TCP-з'єднань (бо треба отримати відповідь), але можливо. Тому пам'ятайте: IP-обмеження — це не заміна аутентифікації. Це лише стіна навколо замку, але замок на дверях все одно потрібен.

6. 🧩 Підсумок

Отже, що ми сьогодні зробили? 1. Зрозуміли, що Whitelist (впускаємо обраних) надійніший за Blacklist (блокуємо поганих). 2. Навчилися налаштовувати "фейс-контроль" на рівні сервера (на прикладі Nginx). 3. Засвоїли правило: порядок правил має значення (спочатку винятки, потім загальне правило). 4. Дізналися, що реальний світ складніший через проксі та динамічні IP.

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

📢 Тизер наступного уроку: Добре, ми відсіяли чужинців. Але що, якщо "свої" почнуть поводитися погано? Що, якщо користувач почне надсилати 1000 запитів за секунду, намагаючись покласти базу даних? На наступному уроці ми поговоримо про Rate Limiting (Обмеження частоти запитів). Готуйтеся, будемо вчитися казати "Досить!"

Це був CS50... тобто, ваш урок! Побачимось! 🎬

← До списку уроків Наступний урок →