IP whitelisting не працює: підмінені адреси та хибні блокування
Зворотний проксі або балансувальник перед веб-сервером ламає фільтрацію за ip — і це найчастіша причина, через яку IP whitelisting поводиться непередбачувано.
З'єднання до застосунку встановлює посередник, тому в правилах доступу замість клієнта опиняється адреса за проксі: одна й та сама для всіх відвідувачів — адреса шлюзу або балансувальника.
Наслідки симетричні й обидва погані. Білий список або пропускає всіх підряд, бо кожен запит приходить з однієї «довіреної» адреси, або відмовляє кожному — якщо посередника в списку немає.
Чорний список жорсткіший: заблокувавши одну адресу, ви закриваєте доступ цілому пулу клієнтів за цим балансувальником, і хибне блокування клієнта перетворюється на відмову всій площадці.
Другий шар проблеми — довіра до заголовків. Клієнт підставляє заголовок з адресою вручну, і якщо сервер приймає його без перевірки, підмінена ip адреса обходить і білий, і чорний список заодно.
Правило тут одне: заголовкам віримо лише від відомих посередників і розбираємо ланцюжок з кінця — перша адреса належить клієнту лише тоді, коли всі попередні входять до довірених діапазонів мережі.
Тому фільтрація за ip будується не на тому, що видно в сокеті, а на відновленій адресі клієнта.
Далі розбираємо, як це закривається: які діапазони оголосити довіреними, у якому порядку читати ланцюжок за кількох хопів і як перевірити політику так, щоб вона не пускала зайвих і не різала своїх.
Що змінюється після впровадження фільтрації на периметрі
Поки фільтрація живе лише на балансувальнику, реальна адреса клієнта губиться: у журналах усі запити приходять з адреси самого проксі. Правила за джерелом починають працювати наосліп — під відмову потрапляють легітимні користувачі за спільним проксі, а небажаний трафік проходить.
Лікується це на рівні конфігурації: довірені проксі перелічуються явно, заголовок з вихідною адресою приймається лише від них — у nginx це задається директивами модуля realip, в Apache — аналогічним механізмом.
Після налаштування рахуємо три величини, за якими видно, що змінилося на периметрі.
- Частка хибних спрацювань — запити, відсічені правилом за легітимного джерела. Тримаємо її нижче відсотка й розбираємо кожну подію: правило уточнюється, а не вимикається цілком.
- Час відновлення доступу — якщо список усе-таки зачепив співробітника або підрядника, адреса повертається за хвилини, без правки конфігурації й перезапуску сервісу.
- Частка запитів з коректно визначеним джерелом — після налаштування прямує до повної. На цих даних працюють розбір інцидентів, обмеження частоти й точкові блокування.
Ефект тримається, поки списки живі. Лічильники на відмови й на зміни списків дають алерт за сплеску, а раз на тиждень склад переглядається: застарілі адреси підрядників ідуть, тимчасові доступи закриваються. Контроль джерел трафіку стає регламентом, а не разовим налаштуванням.
IP whitelisting: рівні фільтрації трафіку та їхні обмеження
Правило фільтрації можна вмикати на кількох рівнях: на мережевому екрані або балансувальнику, на зворотному проксі, у зовнішньому фільтрувальному шарі й у самому застосунку.
Чим ближче правило стоїть до джерела трафіку, тим дешевше відсікається сміття, але тим менше контексту доступно для рішення: на нижніх рівнях видно лише адресу, а не домен, шлях або обліковий запис.
Зворотний бік — правила на балансувальнику не розрізняють сервіси за однією адресою, тому для різних застосунків часто потрібен свій шар і свій список довірених вузлів.
| Рівень | Коли підходить | Обмеження |
|---|---|---|
| Мережевий екран, балансувальник | Потрібно відсікти трафік до потрапляння в застосунок | Видно лише адресу: немає домену, шляху й методу; один список на всі сервіси |
| Зворотний проксі (nginx, Apache) | Правила залежать від домену або шляху, потрібна реальна адреса клієнта | Потребує переліку довірених проксі, інакше адреса в журналі підмінюється |
| Код застосунку | Потрібні роль, права й контекст запиту, облік у журналі аудиту | Запит уже пройшов мережу й чергу, правило дублюється в кожному сервісі |
| Зовнішній фільтрувальний шар | Інфраструктура змінюється, потрібен єдиний список довірених вузлів | Залежність від зовнішнього контуру й затримка на погодження правил |
Рівні не замінюють, а доповнюють одне одного: мережевий відсікає явне сміття, проксі приводить адресу клієнта до реальної, застосунок ухвалює рішення за ролями.
Головне обмеження будь-якої фільтрації — спільна адреса: за одним вузлом може стояти й офіс цілком, і мобільний оператор, тому список довірених вузлів на мережевому рівні не розмежовує користувачів усередині. Ці обмеження приймають усвідомлено, а не обходять.
Порядок впровадження фільтрації: від аудиту трафіку до передачі
Порядок робіт важливіший за інструмент: правило IP whitelisting, увімкнене до інвентаризації джерел, відсікає живих партнерів і внутрішні сервіси. Тому йдемо від карти трафіку до конфігурації й на кожному кроці звіряємо результат з реальними запитами, а не з припущеннями.
-
Інвентаризація джерел трафіку. Збираємо всі точки входу: зовнішні інтеграції, офісні й хмарні адреси, службові роботи, моніторинг. На виході — список підмереж із позначкою «блокувати», «обмежити за частотою», «не чіпати».
-
Схема проходження трафіку. Розбираємо ланцюжок до застосунку: де стоїть балансувальник, скільки вузлів проксують запити, з якого заголовка читається адреса клієнта. Без цього фільтр бачить адресу проксі й ріже або всіх, або нікого.
-
Налаштування правил доступу. Описуємо білий і чорний списки, окремо закриваємо адміністративні розділи. Довірені проксі налаштовуються в зв'язці з правилами — інакше вихідна адреса підмінюється першим же вузлом на шляху.
-
Прогін у режимі логування. Правила вмикаємо так, що заборонені запити пишуться в журнал, але пропускаються. За кілька діб видно всю картину хибних спрацювань — їх вичищають до інциденту, а не після.
-
Перевірка на бойовому контурі. Робочий режим вмикаємо спочатку на одному вузлі: звіряємо частку відсічених запитів і доступність сервісів. Відкат — правка одного файлу конфігурації й перезавантаження.
-
Передача в експлуатацію. Віддаємо схему, конфігурації, порядок додавання нових адрес і розбір типових помилок. Підтримка розуміє, де змінювати список, а не шукає це по журналах у момент блокування.
Що замовник отримує на руки: конфігурації, схеми й регламенти
Ми передаємо роботу не описом «що зробили», а набором артефактів: їх можна перевірити, віддати іншій команді й оновлювати без нашої участі. Нижче — комплект, який залишається у вас після впровадження IP whitelisting на nginx і Apache.
- Файли конфігурації — готові блоки для обох серверів: правила
allow/deny, довірені проксі для відновлення реальної адреси клієнта, порядок застосування директив і точки, куди вставляти нові записи. З коментарями до кожного рядка, щоб правку вніс черговий, а не лише автор схеми. - Політика доступу — які контури закриті фільтрацією, кого пускаємо за замовчуванням, що робимо з рештою трафіку й де закінчується зона відповідальності мережі, а починається застосунку.
- Схема проходження запитів — шлях від клієнта через балансувальник і проксі до застосунку: на якому вузлі видно справжню адресу, де вона підмінюється й як це перевірити однією командою.
- Списки довірених вузлів — окремо за кожним контуром, з власником запису, датою додавання й позначкою, чи можна її знімати.
- Інструкція для чергової зміни — сценарії на кожен випадок: додати адресу, зняти блокування, переконатися, що правило застосувалося, і що робити за хибного спрацювання поза робочими годинами.
- Регламент перегляду правил — періодичність ревізії, хто підтверджує запис, як фіксується причина виключення й коли адреса видаляється автоматично.
Комплект розрахований на те, щоб правила жили без автора: інженер зміни може пояснити, чому конкретна адреса в списку і що буде, якщо її прибрати.
Кейс: як прибрали хибні блокування клієнтів за одну ітерацію
До: правила блокували не тих
Портал клієнта стояв за балансувальником і мережею доставки контенту Cloudflare: на бекенд усі запити приходили з адрес периметра, а не з адрес відвідувачів.
Блокувальні правила спрацьовували на адресу периметра, і під відсічення потрапляла ціла гілка трафіку довіреного клієнта, а не джерело аномалії. Пікові години стабільно давали 6–8% відмов довіреним клієнтам, і кожен такий випадок виглядав як «сайт працює, але не в мене».
Розбір інциденту впирався в журнали: у записах стояла одна й та сама адреса, логи доводилося зіставляти з вивантаженням із панелі мережі доставки, і пошук винуватця займав до 40 хвилин.
Частка запитів з коректною вихідною адресою не перевищувала 12% — статистика з фільтрації була непридатна для рішень.
Що змінили і що стало
Відновили вихідну адресу на обох фронтах: у nginx — модуль real_ip з явним списком довірених підмереж і заголовком X-Forwarded-For, в Apache — модуль RemoteIP з довіреними проксі.
Ланцюжок заголовків валідуємо за довжиною й за довірою до джерела, інакше підставлений вручну X-Forwarded-For обійшов би фільтр.
Порядок правил перевернули на користь білого списку: довірені підмережі й службові адреси периметра перевіряються раніше за блокування, а блокування рознесені за класами — парсери, сканери уразливостей, аномальна частота запитів.
У журнал тепер пишеться вихідна адреса, ланцюжок проксі й ідентифікатор клієнта — інцидент розбирається за одним записом. Відмови довіреним клієнтам припинилися, частка запитів з коректною адресою виросла до 100%, пошук винуватця в журналах скоротився з 40 хвилин до 2–3.
Нові правила перед викатом проганяємо на копії бойових логів у тіньовому режимі — регресію видно до того, як її побачить клієнт.
Чим фільтрація на балансувальнику відрізняється від перевірки в застосунку
Правило на балансувальнику спрацьовує до того, як запит дійде до застосунку: з'єднання відсікається на вході, шифрований канал не піднімається, воркери не займають пам'ять і з'єднання з пулу.
Це і є раннє блокування — воно дешевше за будь-яку перевірку в коді, бо гасить навантаження в найвищій точці. Даних на цьому рівні мало: адреса клієнта, порт, ім'я вузла, лічильники частоти звернень.
Перевірка в застосунку бачить більше — токен, сесію, роль, ідентифікатор орендаря, шлях і тіло запиту. Зате платить повною вартістю обробки: запит уже прийнято, розібрано, піднято контекст.
Звідси й порядок перевірок: фільтр за адресою — на вході, пороги частоти — на балансувальнику, рішення за особистістю — уже в коді.
Головна пастка — дублювання правил. Якщо один і той самий список адрес живе і в конфігурації балансувальника, і в обробнику застосунку, вони розійдуться: правку внесуть в одне місце, друге залишиться з попередньою версією.
Гірше те, що відмова приходить без контексту — у логах застосунку запиту просто немає, і розбір починається з питання, чи був він взагалі.
Окремо про реальну адресу. За проксі клієнтська адреса підмінюється адресою посередника, і правило починає пропускати або різати не того.
Лікується це довірою до заголовка X-Forwarded-For лише від відомих проміжних вузлів і явним розбором ланцюжка — інакше адреса підробляється одним заголовком, і фільтр перестає щось значити.
Часті технічні сумніви під час налаштування доступу
Питання, які задають до старту, майже завжди стосуються не синтаксису правил, а поведінки системи під навантаженням і після змін. Нижче — короткі відповіді, які знімають більшу частину сумнівів до початку робіт.
Клієнти приходять із підміненою адресою — фільтр спрацює невірно?
Якщо трафік проходить через балансувальник або мережу доставки, у сокеті видно адресу посередника, а не клієнта. Реальну адресу відновлюємо за заголовком пересилання й директивами real_ip_header і set_real_ip_from, інакше правила застосовуються до проміжного вузла. Далі списки працюють уже за справжньою адресою.
Чи можемо ми заблокувати живих клієнтів?
Ризик є лише за різкого переходу в режим «заборонено все, крім списку». Тому спочатку вмикаємо запис без блокування, збираємо фактичний трафік і за ним формуємо білий список. Вимкнення — одним рядком конфігурації, без перезапуску сервісу.
У нас уже розгорнуто проксі — схема змінюється?
Змінюється вузол, на якому застосовуються правила: він має бути першим, хто приймає з'єднання. Якщо фільтр поставити після посередника, він побачить одну й ту саму адресу для всіх і або заблокує весь трафік, або не заблокує нічого.
Як часто переглядати списки?
За подіями — новий офіс, зміна провайдера в партнера, виведення сервісу з експлуатації. Плюс планова звірка раз на квартал і автоматичне старіння тимчасових записів, щоб список не перетворювався на звалище історичних виключень.
Як зрозуміти, що фільтр відсікає зайвих?
Ведемо лічильники відмов за кожним правилом і виводимо їх у моніторинг: зростання частки відмов на конкретному шляху — сигнал переглянути запис, а не чекати звернень. Хибні спрацювання розбираємо за логами з адресою, шляхом і часом.
Обговоримо вашу задачу фільтрації та повернемося з планом робіт
Щоб фільтрація працювала передбачувано, починаємо зі схеми проходження трафіку: де стоїть балансувальник, на якому вузлі завершується шифрування і в якій точці губиться реальна адреса клієнта.
На цій картині відразу видно, які заголовки доходять до nginx і Apache, де список дозволених адрес спрацює хибно, а де список заборонених залишить обхід.
Далі визначаємо склад етапів впровадження та межі робіт. План робіт з доступів погоджуємо до правок конфігурації — з порядком викату, точками відкату й відповідальними на вашому боці.
- Схема проходження трафіку з точками, де визначається реальна адреса клієнта.
- Правила для nginx і Apache з пріоритетами, виключеннями й порядком застосування.
- Налаштування довірених проксі й заголовків, щоб реальну адресу не можна було підмінити ззовні.
- Регламент оновлення списків доступу й порядок додавання нових адрес.
- Перевірки на тестовому стенді й на бойовому трафіку, включно з відкатом правил.
- Документація з конфігурації та передача вашій команді підтримки.
Опишіть задачу фільтрації: що вже налаштовано, де стоять проксі й які адреси потрібно пускати або блокувати. Повернемося з оцінкою робіт і планом, де за кожним етапом зазначено строки й результат.
