APWG тільки за перший квартал 2026 року зафіксувала 971 181 фішингову атаку — це на 13,8% більше, ніж кварталом раніше. А вже в січні 2026 року Google порушив роботу того, що компанія назвала однією з найбільших у світі мереж residential-прокси, після того як з’ясувалося: за один тиждень через неї маршрутизували трафік понад 550 груп загроз. Як не дивно, проксі-інфраструктура опиняється по обидва боки фішингової боротьби.
Саме цей конфлікт більшість статей про «проксі та фішинг» просто ігнорують. Одні запевняють, що проксі — це щит (мовляв, купи наш продукт і будеш у безпеці). Інші лякають тим, що проксі — це зброя атакувальників. Насправді все набагато складніше й цікавіше.
Зловмисники використовують проксі, щоб приховати джерело трафіку, стрибати між довіреними IP-адресами та красти вже аутентифіковані сесії — навіть після MFA. Захисники застосовують проксі, щоб безпечно вивчати підозрілі посилання, дивитися, як фішингові сторінки відображаються в різних країнах, і відсікати шкідливий трафік ще до того, як він потрапить на їхні сайти. У цьому гайді розбираємо обидві сторони, а потім переходимо до практичного робочого процесу, який реально можна впровадити. Без загальних слів і без чудо-рішень.
- Складність: середня
- Час: приблизно 25 хвилин на читання й планування; реалізація залежить від етапу
- Що знадобиться: базове розуміння веб-інфраструктури вашої компанії, доступ до DNS-налаштувань домену, браузер Chrome (для кроків із Thunderbit) і, за потреби, акаунт у провайдера проксі
Що таке фішинг і чому бізнесу потрібно це враховувати?
Фішинг — це атака на обмані. Зловмисники використовують листи, SMS, підроблені сторінки входу, QR-коди або фейкові сайти, щоб змусити людей віддати облікові дані, підтвердити вхід, встановити шкідливе ПЗ або перевести гроші.
Сьогодні це вже не просто історія про «поганий лист». Сучасний фішинг включає сторінки на хмарному хостингу, підроблені форми входу Microsoft 365, крадіжку session-токенів і QR-коди.
Для бізнесу ставки цілком конкретні. У звіті IBM 2025 Cost of a Data Breach середню глобальну вартість витоку оцінюють у 4,4 млн доларів США. В Internet Crime Report 2025 ФБР зазначає, що IC3 отримав близько 453 000 скарг на кібершахрайство, а сума заявлених втрат перевищила 17,7 млрд доларів США; при цьому на business email compromise (BEC) припало понад 3 млрд доларів.
Крадіжка облікових даних, шахрайські перекази, компрометація ланцюгів постачання, штрафи регуляторів — фішинг зачіпає все це.
Далі: як проксі вписуються і в атаки, і в захист, та як насправді виглядає багатошарова оборона.
Подвійна природа проксі: ваш щит і їхня зброя
Проксі — це посередник між вашим пристроєм та інтернетом. Замість вашої реальної IP-адреси сайт бачить адресу проксі. Це схоже на службу пересилання листів: отримувач бачить адресу пересилання, а не вашу домашню адресу.
Саме ця властивість і створює проблему подвійного призначення. Команди безпеки використовують проксі, щоб вивчати загрози, не розкриваючи корпоративний IP або робочу станцію аналітика. Атакувальники застосовують ту саму технологію, щоб шкідливий трафік виглядав як запити звичайних користувачів, мешканців інших країн або довірених домашніх мереж. Аналіз Barracuda за квітень 2026 року пояснює це прямо: residential-IP виглядають справжніми, бо прив’язані до реальних домашніх або невеликих бізнес-підключень, а отже, системи антифроду рідше їх позначають.
Більшість конкурентних матеріалів описують лише один бік. Через це в читача складається неповна картина — і захист виходить таким самим неповним.
Як зловмисники використовують проксі проти вас
Для захисників бізнесу особливо важливі три напрями атак: анонімність і ротація IP, зловживання residential-проксі та обхід довірених платформ.
AiTM-фішинг: як це працює
AiTM — це атака, яка ламає припущення «MFA нас захищає» (спойлер: класична MFA не рятує від такого сценарію).
В AiTM-атаці зловмисник ставить reverse proxy між жертвою та легітимною сторінкою входу — наприклад, Microsoft 365. Користувач бачить майже справжній екран логіну. Він вводить облікові дані, проходить MFA, і справжній провайдер ідентифікації видає session cookie. Але оскільки весь трафік проходить через проксі атакувальника, той перехоплює цю cookie. Потім він може відтворити її та зайти в акаунт без пароля й без повторного запиту MFA.
Аналіз Microsoft по Tycoon2FA, одному з найпоширеніших AiTM-фішинг-китів, показує, що оператори можуть імітувати сторінки входу Microsoft 365, Outlook, SharePoint, OneDrive та Google. Кит генерує PDF і QR-коди, керує ланцюжками редиректів та відстежує використання MFA й крадіжку session cookie. У його інфраструктурі використовуються короткоживучі субдомени й розміщення на Cloudflare, щоб ускладнити блокування.
Це не теорія. AiTM-кити активно застосовуються в масштабних атаках, і саме тому фраза «у нас є MFA» не є повноцінною відповіддю на фішинг.
Зловживання residential-проксі та ротація IP
Мережі residential-проксі спрямовують трафік атакувальника через реальні домашні IP-адреси, через що фішингові запити виглядають легітимніше й проходять повз IP-базовані антифрод-системи. Багато провайдерів недостатньо жорстко перевіряють, як саме використовуються їхні IP, і це створює сіру зону.
Найпоказовіший приклад: у січні 2026 року Google Threat Intelligence Group порушила роботу residential-проксі-мережі IPIDEA, скоротивши доступний пул пристроїв на мільйони. GTIG зафіксувала понад 550 окремих груп загроз, які використовували exit-вузли IPIDEA протягом однієї семиденної доби. Розслідування показало перетин із ботнетами, зловживанням доступом до SaaS, password spray-атаками та глобальними шпигунськими операціями. У багатьох SDK для проксі відсутня явна згода користувачів.
У рекомендації ФБР 2026 року щодо residential-проксі серед кримінальних сценаріїв названі фішинг, входи зі вкраденими обліковими даними, brute force, захоплення акаунтів, спам і маскування C2-інфраструктури.
Розміщення на довірених платформах і обхід детектування фішинг-китів
Ще один спосіб обходу — розміщення фішингових сторінок на довірених платформах, таких як SharePoint, Google Docs або Azure Blob Storage, щоб користуватися їхньою репутацією домену. Аналіз Microsoft щодо загроз в Azure Blob Storage показує, що атакувальники використовують це для розміщення підроблених сторінок входу Microsoft, роблячи їх менш помітними для жертв, які судять про легітимність лише за сертифікатом.
Фішингові кити теж уміють ховатися. Розбір Cofense про фішинг-кити описує фільтрацію за геолокацією, user-agent і мовою, CAPTCHA, виявлення developer tools і редиректи на справжні сторінки. Якщо відвідувач не відповідає цільовому профілю — не та країна, не той браузер або він схожий на security scanner — сторінка покаже нешкідливий екран або 404.
Сканування з одного корпоративного IP або з хмарного дата-центру такі сторінки не знайде. Кит буквально створений, щоб ховатися від вас.
Як захисники використовують проксі, щоб дати відсіч
З оборонного боку проксі вирішують чотири практичні завдання:
-
Анонімне сканування URL і доменів. Підозрілі посилання проганяються через контрольований проксі, щоб цільовий сайт бачив IP проксі, а не ноутбук співробітника чи корпоративну мережу. Це знижує прямий ризик і робить розслідування відтворюваним.
-
Збір threat intelligence. Ротаційні проксі дають змогу збирати дані про фішингову інфраструктуру, списки доменів, публічні фіди загроз або нещодавно зареєстровані домени без блокування після кількох запитів. (Звісно, лише в межах закону й умов використання сервісів.)
-
Георозподілене виявлення фішингу. Проксі в різних регіонах дозволяють перевірити, чи поводиться підозрілий URL по-різному з США, ЄС, APAC або іншого цільового ринку. Так виявляються кити, які використовують геофенсинг або фільтрацію за user-agent — ті самі методи обходу, про які говорилося вище.
-
Reverse proxy / WAF для власних ресурсів. Reverse proxy стоїть перед вашими доменами. Він не заважає співробітникам натискати на зовнішні фішингові посилання, але захищає власні веб-ресурси від бот-трафіку, credential stuffing, шкідливих payload’ів і агресивних патернів запитів.
Чому однієї MFA недостатньо проти фішингу через проксі
Я бачив, як цей спір спалахує в десятках IT-форумів: «У нас є MFA, отже ми захищені». У системних адміністраторів, яким доводилося розбирати інцидент AiTM, погляд зазвичай зовсім інший.
Механізм простий. Жертва проходить MFA на сторінці, яка виглядає як справжній логін. Реальний провайдер ідентифікації видає session token. Атакувальник перехоплює цей токен через свій reverse proxy.
Аутентифікація формально успішна — але сесія вже у зловмисника. Простого скидання пароля може бути недостатньо, якщо активні сесії та зміни MFA, внесені атакувальником, залишаються чинними. Microsoft прямо вказує, що постраждалим організаціям потрібно відкликати session cookie й відкотити зміни MFA, зроблені атакувальником, а не обмежуватися стандартним remediation.
SMS-коди, OTP-додатки, push-підтвердження — усе це можна перехопити через фішинг, якщо користувач завершує кроки всередині потоку, контрольованого атакувальником. MFA виконала свою задачу. Проблема в тому, що зловмисник спостерігав за всім процесом.
Що насправді зупиняє AiTM-фішинг
FIDO2 / passkeys. FIDO Alliance пояснює, що passkeys за своєю архітектурою стійкі до фішингу: немає пароля, який можна вкрасти, і немає даних входу, які можна використати повторно. Криптографічна пара ключів прив’язана до origin легітимного домену, тож проксі атакувальника не може відтворити challenge. CISA підтверджує, що FIDO і PKI — це єдині широко доступні нефірмові методи MFA, які запобігають фішингу облікових даних.
Аутентифікація на основі сертифікатів. Рішення корпоративного рівня, складніше в розгортанні, але теж стійке до фішингу, оскільки спирається на сертифікати пристрою, а не на коди, введені користувачем.
Політики Conditional Access. У середовищі Microsoft Conditional Access може вимагати відповідні пристрої, довірені локації, перевірки на основі ризику або аутентифікацію з фішинг-стійким рівнем захисту — це зменшує цінність вкраденого session token, навіть якщо атакувальник його отримав.
Усе це доповнює проксі, а не замінює їх. Мета — багатошаровий захист.
Практичні варіанти для SMB з обмеженим бюджетом
Очевидне заперечення: «Intune, MDM, апаратні ключі — це бюджет рівня enterprise». Справедливо. Ось доступніший шлях:
- Passkeys у браузері. Більшість сучасних браузерів підтримують passkeys нативно. Купувати окреме обладнання не потрібно. Почніть з акаунтів адміністраторів, фінансового відділу та HR.
- Безкоштовне впровадження DMARC. Записи SPF, DKIM і DMARC можна опублікувати безкоштовно. У Google Workspace і Microsoft 365 є готові інструкції з налаштування.
- Захисна реєстрація доменів. Зареєструйте поширені опечатки та домени-двійники вашого бренду. У більшості реєстраторів це коштує 10–15 доларів на рік за домен. Для кожного такого домену увімкніть DMARC reject.
- Точкове навчання. Зробіть акцент на сценаріях AiTM: підроблені сторінки входу Microsoft 365, фейкові спільні документи, QR-коди, атаки через device code і схеми «термінова оплата / терміновий запит від постачальника».
Думайте про це як про підхід «почни тут, покращуй потім». Навіть часткове впровадження помітно знижує ризик.
Який тип проксі найкраще підходить для захисту від фішингу?
Різні типи проксі вирішують різні завдання, і помилка у виборі веде або до зайвих витрат, або до сліпих зон.
| Тип проксі | Найкращий сценарій проти фішингу | Плюси | Мінуси | Рівень витрат |
|---|---|---|---|---|
| Дата-центр | Масове сканування URL, моніторинг доменів | Швидкий, дешевий, висока пропускна здатність | Просунуті фішинг-кити легко його розпізнають | Низький |
| Residential | Геотаргетоване виявлення фішингу, тестування очима користувача | Виглядає як реальний користувацький трафік, проходить геоблокування | Повільніший, дорожчий, є серйозні етичні питання до джерела IP | Високий |
| Ротаційний | Збір threat intelligence, тривалий моніторинг | Дає змогу обходити IP-бани під час довгих сесій збору | Складніше налаштувати, змінна затримка | Середній |
| Reverse Proxy / WAF | Захист власних веб-ресурсів | Фільтрує вхідні загрози, детектує ботів, захищає від DDoS | Не допомагає з виявленням вихідного фішингу | Середній |
Примітка щодо етичного походження. Кейси Google/IPIDEA і рекомендації ФБР ясно показують: residential-проксі можуть будуватися на скомпрометованих пристроях, обманних SDK, прихованих умовах VPN або шкідливому ПЗ. Перед купівлею residential-трафіку вимагайте від провайдера прозорої згоди користувачів, механізму відмови, можливості аудиту та процедур обробки зловживань. До провайдерів, яких раніше згадували в дослідницьких звітах з безпеки (PacketStream, вже неіснуючий 911 Proxy), варто ставитися з максимальною обережністю.
Для більшості малих і середніх компаній розумніше почати з дата-центрових проксі для масового сканування та reverse proxy/WAF для власних доменів. Residential-проксі додавайте лише тоді, коли справді потрібно тестування за географією і ви можете ретельно перевірити провайдера.
Покроково: як уникнути фішингу за допомогою проксі (практичний робочий процес)
Більшість статей зупиняються на теорії. Нижче кожен крок має рекомендацію щодо інструменту й достатньо деталей, щоб передати це IT-команді або зробити самому.
Крок 1: відстежуйте нещодавно зареєстровані домени, схожі на ваш бренд
Перед запуском кампаній атакувальники реєструють домени, схожі на ваші: thunderb1t.com, thunderbit-login.com, thunderbit-support.net.
Піймати їх на ранньому етапі — одна з найцінніших захисних дій.
Як це зробити:
- Складіть список для моніторингу з назви бренду, продуктів, імен керівників і слів, пов’язаних із входом у систему (наприклад, «login», «portal», «invoice», «payment»).
- Щодня перевіряйте логи Certificate Transparency (CT) через crt.sh, де можна шукати сертифікати за доменом або назвою організації. Оскільки публічно довірені сертифікати мають потрапляти в CT, нові сертифікати для доменів-двійників там буде видно.
- Позначайте домени з невеликою відстанню редагування від вашого бренду, підозрілими TLD (.xyz, .top, .click) або словами login/payment.
- Проганяйте позначені сторінки через проксі або sandbox — ніколи не відкривайте їх із браузера співробітника.
Як тут вписується Thunderbit: Thunderbit batch extract API може обробляти до 100 підозрілих URL за одну задачу, використовуючи renderMode: "full" для рендерингу фішингових клонів із важким JavaScript. Ви задаєте JSON Schema для потрібних даних — заголовок сторінки, наявність форми входу, домен action форми, SSL issuer, ланцюжок редиректів, фінальний URL. CLI-варіант зручно вбудовується в моніторинг через cron:
thunderbit batch extract --file suspicious-urls.txt --schema phishing-signals.json --render-mode full
Для нетехнічних користувачів розширення Thunderbit для Chrome теж підходить: з його допомогою можна швидко витягнути й переглянути підозрілі сторінки буквально в кілька кліків — зручно, коли треба просто оцінити кілька URL на око, а не запускати весь пайплайн за розкладом.
Очікуваний результат: щоденний або щотижневий звіт про нові домени-двійники зі структурованими метаданими, готовими для triage.
Спробувати Thunderbit для перевірки підозрілих URL
Крок 2: проганяйте підозрілі посилання через дата-центрові проксі
Перш ніж хтось із вашої організації відкриє підозріле посилання, аналізуйте його через контрольований шлях. Видимим буде IP проксі, а не пристрій співробітника і не корпоративна мережа.
Як це зробити:
- Для швидкої перевірки використовуйте urlscan.io (web-sandbox із вибором країни сканування) або VirusTotal (перевірка URL десятками антивірусних рушіїв і blocklist’ів).
- Для внутрішніх скриптів або аналізу великого обсягу запитів спрямовуйте трафік через дата-центровий проксі:
curl -x http://proxy.example.com:8080 -I "https://suspicious.example"
- Для живих фішингових сторінок використовуйте одноразову VM або browser sandbox. Не вводьте облікові дані. Знімайте ланцюжок редиректів, заголовок сторінки, кінцеву адресу, форми, скрипти та скриншоти.
- Ніколи не надсилайте справжні корпоративні логіни й паролі. І обережно ставтеся до публічних сканів — деякі сервіси показують надіслані URL, якщо не ввімкнено приватний режим.
Очікуваний результат: безпечна оцінка призначення посилання, поведінки сторінки та ознак загрози — без ризику для корпоративного середовища.
Крок 3: використовуйте георозподілені проксі, щоб виявляти таргетовані фішингові кампанії
Деякі фішингові кити показують шкідливий контент лише відвідувачам із конкретної країни або з певним мовним профілем. Cofense зазначає, що геолокаційна фільтрація — дуже поширений прийом: відвідувачі з «не тієї» локації бачать нешкідливу сторінку або 404, а цільова аудиторія отримує форму збору облікових даних.
Як це зробити:
- Тестуйте підозрілі посилання з тих регіонів, де реально працюють ваші співробітники, клієнти й фінансова команда. Якщо компанія зі США, але є офіс у Великій Британії, перевіряйте обидва регіони.
- Порівнюйте фінальні URL, скриншоти, заголовки сторінок, форми та HTTP-коди відповіді за регіонами.
- Під час аналізу QR-кодів або мобільних приманок змінюйте user-agent і мовні налаштування — деякі кити фільтрують і за ними.
- Передавайте на ескалацію URL, де в одній локації показано безпечний контент, а в іншій — форму входу. Це сильний сигнал фішингу.
Очікуваний результат: виявлення геотаргетованих кампаній, які були б невидимими при перевірці лише з однієї локації.
Крок 4: впровадьте reverse proxy або WAF для власних доменів
Тепер переходимо від зовнішнього виявлення до внутрішнього захисту. Reverse proxy та WAF стоять перед вашими веб-ресурсами й перевіряють вхідний трафік до того, як він потрапить на сервери.
Як це зробити:
- Укажіть DNS домену на провайдера reverse proxy. Cloudflare — найзручніший варіант для SMB: DNS, CDN, WAF і правила в одному інтерфейсі. Для застосунків, розміщених в AWS, добре підійде AWS WAF, якщо ви вже використовуєте CloudFront, ALB або API Gateway.
- Увімкніть managed WAF rules. Вони блокують відомі шкідливі IP, фільтрують бот-трафік і виявляють патерни credential stuffing.
- Налаштуйте rate limit для сторінок входу, скидання пароля та контактних форм.
- Додайте bot/challenge-правила для найризикованіших endpoint’ів.
- Щотижня перевіряйте події WAF — не залишайте все без нагляду.
Очікуваний результат: вхідний шкідливий трафік відсікається ще до потрапляння на ваші сервери. Спроби credential stuffing на сторінках входу блокуються або потребують додаткової перевірки.
Крок 5: автоматизуйте й налаштуйте постійний моніторинг
Фішинг — це не разова перевірка. Нові домени, кити й інфраструктура з’являються щодня, тож моніторинг має працювати за розкладом:
- Щодня: перевірка CT на lookalike-домени й черга підозрілих доменів.
- Щодня або щогодини (для високоризикових брендів): sandbox-перевірка нових виявлених доменів.
- Щотижня: аналіз зведених DMARC-звітів і патернів підміни.
- Щотижня: перевірка подій WAF на credential stuffing і сплески ботів.
- Щомісяця: оцінка прогресу впровадження phishing-resistant MFA.
- Щокварталу: тестування процесів фінансів і HR на реалістичних сценаріях AiTM та BEC.
Як тут вписується Thunderbit: плановий збір даних і API/CLI-робочі процеси Thunderbit допомагають організувати повторюваний моніторинг для нетехнічних команд. Найкращий сценарій використання — не «Thunderbit сам захищає від фішингу», а «Thunderbit допомагає операційним командам збирати структуровані сигнали з підозрілих сторінок і джерел моніторингу доменів без написання власного скрапера з нуля». Результати можна надсилати в Google Sheets або Airtable для видимості в команді, або в Slack через просту інтеграцію.
Очікуваний результат: безперервний цикл моніторингу, який виявляє нові загрози за години, а не за тижні.
Що проксі не зловлять: захист пошти через DMARC, SPF і DKIM
Постачальники проксі не завжди говорять про це прямо: проксі — лише один шар захисту, а фішинг через email, який взагалі не проходить через proxy-layer, потребує окремого захисту.
Багато фішингових атак приходять із підроблених адрес відправника. Проксі їх не перехопить.
Налаштування SPF із жорсткою відмовою
SPF (Sender Policy Framework) — це DNS-запис зі списком IP-адрес, яким дозволено надсилати листи від імені вашого домену. Налаштовуйте -all (hard fail), а не ~all (soft fail), щоб одразу відхиляти неавторизованих відправників.
Часта помилка: забувають включити всі легітимні сервіси відправки — CRM, маркетингову платформу, провайдера транзакційних листів, helpdesk. Перед публікацією запису перевірте всі джерела відправки.
Розгортання DKIM-підпису
DKIM (DomainKeys Identified Mail) додає до вихідних листів криптографічний підпис. Отримувач перевіряє, що повідомлення не було змінене під час передавання. У Google Workspace і Microsoft 365 є вбудовані інструкції з налаштування DKIM. Зазвичай це займає близько 15 хвилин.
Примусове застосування DMARC у режимі reject
DMARC (Domain-based Message Authentication, Reporting & Conformance) повідомляє серверам, що приймають листи, що робити, якщо SPF або DKIM не пройшли перевірку. Критично важливий крок, який пропускають багато організацій: перейти з p=none (лише моніторинг) на p=reject (блокувати листи, що не пройшли перевірку) після перевірки легітимних потоків пошти.
Багато компаній залишають DMARC у p=none назавжди — видимість є, захисту немає. Це як поставити камеру безпеки, але ніколи не замикати двері.
Захисна реєстрація доменів-двійників
Заздалегідь зареєструйте поширені опечатки та домени, схожі на ваш бренд. На цих захисних доменах увімкніть DMARC reject, щоб їх не можна було використати для підробки відправника. За ціною 10–15 доларів на рік за домен це одна з найдешевших і найефективніших дій, про яку малий бізнес часто взагалі не думає.
Зводимо все докупи: багатошарова захист від фішингу
Жоден інструмент не зупиняє фішинг сам по собі. Працює саме комбінація заходів. Практичний чекліст:
Зовнішній контур (розслідування загроз):
- сканування підозрілих посилань через проксі;
- моніторинг доменів через CT-логи та batch extraction;
- георозподілене тестування кампаній, орієнтованих на конкретні регіони.
Вхідний контур (захист власних ресурсів):
- reverse proxy / WAF для ваших веб-доменів;
- DMARC/SPF/DKIM для аутентифікації пошти;
- захисна реєстрація доменів-двійників.
Аутентифікація (захист акаунтів):
- FIDO2 / passkeys як phishing-resistant MFA;
- політики Conditional Access (відповідні пристрої, перевірки на основі ризику);
- процедури моніторингу та відкликання session token.
Люди — остання лінія захисту:
- навчання, сфокусоване саме на AiTM-приманках, QR-кодах і сценаріях BEC;
- зрозуміла культура повідомлень про інциденти — зробити репорт підозрілого листа простим і без покарань;
- регулярна перевірка процесів фінансів і HR на реалістичних фішингових сценаріях.
Такий підхід відповідає принципу defense-in-depth із NIST Cybersecurity Framework: кілька незалежних рівнів, щоб збій одного не означав повний компроміс.
Для команд, яким потрібно розслідувати підозрілі URL, збирати threat data або масштабно моніторити домени, AI web scraper від Thunderbit може прискорити робочий процес — розширення Chrome для нетехнічних користувачів, API/CLI для технічних команд. Це не security-продукт сам по собі, але він заслуговує місце в наборі аналітика. Докладніше можна дізнатися про веб-скрапінг без коду або вивчити підходи до AI web scraping у нашому блозі.
Використовуйте AI web scraping для моніторингу загроз Get Started Free
Часто задавані питання
Як зловмисники використовують проксі для фішингових атак?
Зловмисники використовують residential і rotating-проксі, щоб приховати свій реальний IP, перемикатися між довіреними адресами, обходити IP-базований антифрод і розгортати AiTM reverse proxy для перехоплення вже аутентифікованих сесій — навіть після того, як жертва пройшла MFA. Операція проти IPIDEA в січні 2026 року показала, що одну residential-проксі-мережу використовували понад 550 груп загроз.
Як reverse proxy допомагає запобігати фішингу та компрометації сайту?
Reverse proxy стоїть перед вашими вебсерверами й перевіряє вхідний трафік ще до того, як він потрапить в інфраструктуру. Він блокує відомі шкідливі IP, фільтрує бот-трафік, обмежує частоту запитів до логіну та виявляє credential stuffing або дії, пов’язані з фішингом. Але співробітників від кліків по зовнішніх фішингових посиланнях він не захистить.
Чи можна повністю запобігти фішингу за допомогою проксі?
Ні. Проксі — це важливий шар, але для фішингу через email потрібні DMARC/SPF/DKIM, а для викрадення сесій через AiTM-атаки — phishing-resistant MFA на кшталт FIDO2/passkeys. Потрібен багатошаровий захист, який поєднує проксі, аутентифікацію пошти, стійкі до фішингу облікові дані та навчання співробітників.
Що таке AiTM-фішинг і чому MFA його не зупиняє?
AiTM (Adversary-in-the-Middle) фішинг використовує reverse proxy між жертвою та справжньою сторінкою входу, щоб перехопити session token після завершення MFA. Класична MFA його не зупиняє, бо атакувальник краде не пароль, а вже аутентифіковану сесію. FIDO2/passkeys стійкі до цієї атаки, оскільки криптографічний challenge прив’язаний до легітимного домену й не може бути відтворений через проксі атакувальника.
Який тип проксі найкраще підходить для виявлення фішингу?
Дата-центрові проксі найкраще підходять для масового сканування URL — вони швидкі та дешеві. Residential-проксі краще для геотаргетованого тестування — вони реалістичні, але дорожчі; провайдера потрібно ретельно перевіряти на етичність джерела IP. Reverse proxy/WAF найкраще захищають власні сайти. Найсильніший підхід — комбінація інструментів залежно від того, що саме ти хочеш виявити або захистити.
Спробуйте Thunderbit для моніторингу загроз і AI-скрапінгу Get Started Free
Докладніше
