The post has been translated automatically. Original language: Russian
Why IP blocking no longer saves websites: a dead end of rigid logic in modern cybersecurity
Blocking by IP address has long been considered a simple and understandable way to protect a website. But in the era of cloud providers, mobile networks, CGNAT, resident proxies, and distributed botnets, IP is increasingly no longer a reliable sign of an attacker. A modern attack can be small in scope, but complex in structure. Therefore, protecting the web infrastructure only with IP blacklists means trying to solve a multidimensional task with a one-dimensional tool.
Key topics: IP blocking, WAF, CGNAT, botnets, behavioral analysis, TLS fingerprinting,JA3, JA4, HTTP/2 fingerprinting, site protection.
Introduction: when a simple filter stops working
In the first part of the article on the hypothesis of Ai and cybersecurity, an important thesis was formulated: a small volume of traffic does not mean a small threat if this traffic has a high dimension of features. A distributed attack may not create a noticeable spike from a single address, but at the same time form a dangerous pattern at the application-wide level.
In practice, many defense systems still respond to such attacks in the simplest way.:they block the IP address, subnet, or ASN. This approach is convenient, understandable, and sometimes really useful.But if you use it as the main defense mechanism, it quickly turns into a dead end.
The problem is not that the IP address is useless at all. The problem is that the IP is only one feature. And modern threats do not live in one coordinate, but in the space of many parameters: behavior, frequency, route, headers, TLS fingerprints, HTTP version, sessions, cookies, browser features and the context of the request.
1. Historical analogy: the impasse of "rigid logic" and the crisis of copying
In the 1960s, Soviet cybernetics experienced rapid growth. Academicians Viktor Glushkov, Axel Berg and other scientists designed the OGAS (Nationwide Automated System) and worked on ambitious ideas for automated control. It is important to understand that this historical parallel does not mean that the entire Soviet digital school was wrong. On the contrary, there were many strong concepts in it. But the dominant logic of that era is useful for our topic: the belief that a complex, multidimensional dynamic system can be completely subordinated to a set of predefined, deterministic rules.
This approach was most clearly manifested in early computer translation systems such as BESM-6 or Minsk-22. For years, linguists and mathematicians have been manually encoding grammar, syntax, and contexts through rigid binary rules like IF... THEN.... However, a living language with infinite dimension and fractal structure dealt determinism a crushing blow. Metaphors, homonymy, contextual shifts, and slang generated an avalanche of exceptions. For each fixed rule, it was necessary to write down ten more describing the exceptions to it. This led to a combinatorial explosion of complexity and paralysis of computing power. An attempt to describe a living system with static logic turned out to be fundamentally impossible.
Instead of making a paradigmatic shift towards probabilistic and statistical models (the future of machine learning), the leadership of the Soviet IT industry made an administrative decision that aggravated the systemic crisis. At the turn of the 1970s, unique domestic developments were actually curtailed in favor of blind copying of the American IBM-360 architecture (EC computer series). The irony of fate was that the attempt to catch up with the West through Reverse Engineering fell into the same methodological trap: it is impossible to copy the external form of the process without understanding its internal multidimensional structure.
Soviet defense research institutes etched silicon wafers of smuggled American Intel or Motorola processors in layers, photographed the topology of the interconnects under a microscope and tried to reproduce this pattern at Zelenograd factories. But semiconductor physics did not forgive linear copying. The slightest differences in the technological tolerances of the machines, the purity of Soviet silicon and the physico-chemical properties of the materials gave rise to parasitic currents, microdefects and overheating. On circuits of hundreds of thousands of transistors, the combinatorial explosion of defects reached 90%. Engineers spent years "licking" the defects of someone else's static mold, but by the time the Soviet clone was released into the series, a fundamentally new generation of microcircuits was being produced in the West.
This dead-end path of straightforward determinism and catch-up copying predetermined the deep lag of the USSR in the global computer race, depriving the mathematical school of an adequate hardware base. And the subsequent collapse of the country in 1991 finally buried the accumulated potential: the chains of cooperation between design bureaus and factories broke, and the avalanche-like brain Drain abroad deprived the industry of an entire generation of scientists capable of developing alternative probabilistic approaches.
Modern IP filtering in cybersecurity today repeats with frightening accuracy the mistakes of the Soviet Ministry of Radio Industry fifty years ago. When a security administrator tries to protect a web resource from a distributed botnet by creating blacklists or directly limiting the frequency of requests (IP-based rate limit), he commits the classic mistake of one-dimensional "rigid logic". He tries to reduce the attacker's complex, distributed behavior to a single static feature — the source address. In the era of CGNAT, cloud providers, and resident proxies, the IP address has ceased to be a monolithic device passport, becoming an ephemeral, ever-changing token. An attempt to block a fractal, low-intensity threat with a flat binary rule inevitably leads to an avalanche of false positives, "fire on your own" and a strategic loss of the protective circuit.
Modern IP filtering often repeats the same mistake. It tries to reduce the complex behavior of a user or bot to one feature: the source address.
2. Why is an IP address no longer a reliable identity?
In the early Internet, an IP address was more often associated with a specific server, office, or home connection. The situation has changed today. The same IP can belong to thousands of users, and the same attacker can change the IP hundreds of times in a short period of time.
2.1. CGNAT: one public IP for multiple people
Due to the shortage of IPv4 addresses, telecom operators use CGNAT - Carrier-Grade NAT. With this scheme, many of the provider's subscribers access the Internet through a shared public IP address.
This creates a serious problem for the website. If a malicious request has come from one of these IP addresses, this does not mean that the entire address needs to be blocked. It can be used by ordinary users: residents of the district, employees of the business center, students of the dormitory, or customers of the mobile operator.
A hard lock on such an IP address can cause more damage to a business than the attack itself: the site will cut off not only the bot, but also real visitors.
2.2. Clouds, data centers, and CDNs
Most of today's traffic passes through cloud infrastructures, CDNs, proxies, and load balancers. The IP address may belong to Cloudflare, Amazon, Google Cloud, DigitalOcean, Hetzner, or another provider, but this fact alone does not prove that the request is malicious.
On the one hand, scanners, parsers, and bots really often come from data centers. On the other hand, legitimate services can also work there.: payment systems, accessibility monitoring, API integrations, enterprise gateways, and search robots.
2.3. Resident proxies and botnets
The attacker is no longer required to use a suspicious server from the data center. He can buy access to resident proxies or use a botnet of infected devices: routers, cameras, televisions, IoT devices, and home computers.
Each such node can make only one or two requests per hour. For the classic IP rate limit, this source looks almost perfect: a small frequency, a regular country, a regular provider.But if you put all these microqueries together, you get a distributed attack.
3. Why IP Blacklists create a false sense of security
The IP blacklist looks convincing: if there is a bad address, we have blocked it. But such protection often reacts not to the cause of the attack, but to its temporary trace.
The attacker has the advantage of changing the IP address cheaply and quickly. Defender has a problem: each new list needs to be stored, updated, synchronized, checked and applied without harming the speed of the site.
There is an economic asymmetry:
- it is easy for an attacker to change the traffic source;
- it is expensive for a defender to maintain huge lists of rules;
- A blocking error may affect real users.;
- Outdated rules continue to live in the system and create noise.;
- new IP addresses appear faster than they can be classified.
Therefore, IP blocking should not be the main solution, but only one of the layers of protection. It is useful against coarse noise, mass scanners, and obvious sources of malicious activity, but it is not sufficient against distributed and accurate attacks.
4. Mathematical view: why one IP address is not enough
Let's imagine that a security system wants to determine whether a request is malicious.It has only one feature — an IP address. Then the question arises:how much information does this IP give us about the real harmfulness of the request?
This can be described in terms of the conditional Shannon entropy:
H(Y|X) = - Σ p(x) Σ p(y|x) log₂ p(y|x)Where:
- X — multiple IP addresses;
- Y — outcome: legitimate user or bot;
- p(y|x) is the probability that a request from a specific IP is malicious.
If both ordinary users and infected devices can be located behind the same IP, and the attacker is constantly changing addresses, then knowing the IP stops dramatically reducing uncertainty. In such conditions, the system is increasingly making mistakes.:
- false positive — blocks a normal user.;
- false negative — skips the bot because its IP looks clean.
Practical conclusion: An IP address can be a useful signal, but it should not be the only basis for a final decision.
5. What should replace IP-centric protection
Modern security must evaluate not only the source of the request, but also its internal structure. It is important to look not just at where the request came from, but at how it looks, how it behaves over time, and how consistent its features are.
5.1. Global Behavioral Scoring
Instead of an IP-only limit, you need to analyze the status of the entire endpoint. For example, if thousands of rare requests from different addresses go to the authorization page, the classic rate limit may not see anything. But at the application level, the pattern is obvious: there is a distributed search going on.
In such a situation, the system should include adaptive verification mode rather than mass IP blocking.:
- session verification;
- JavaScript challenge;
- captcha is only for suspicious groups;
- temporary reinforcement of the rules for a specific endpoint;
- separate protection of the login form, search, registration and API.
This approach preserves access for real users better and at the same time makes life more difficult for bots.
5.2. Checking the consistency of features
One feature is easy to fake. It is more difficult to fake a consistent combination of features.Therefore, the system should look at the query as a vector.:
| Sign | The normal pattern | A suspicious picture |
| IP and ASN | User provider, expected country | Data center, proxy, sudden change of region |
| Accept-Language | Corresponds to the country and audience of the site | A strange combination of languages or an empty title |
| User-Agent | It looks like a real browser. | An old, rare, fake, or technical customer |
| TLS fingerprint | Similar to Chrome, Safari, Firefox, Edge | Similar to Python, Go, curl, headless-tool |
| Behaviour | There are pauses, transitions, and normal navigation. | Even intervals, direct requests, no history |
For example, an IP address from Kazakhstan may look normal by itself. But if the request has a US timezone, the language header does not match the region, the TLS fingerprint looks like an automated library, and the behavior does not look like a human, the system should increase the risk assessment.
5.3. TLS fingerprinting: JA3 and JA4
An attacker can buy a clean IP. But it is more difficult for it to completely replicate the network behavior of a real browser. During a TLS connection, the client transmits a set of parameters: protocol versions, ciphers, extensions, and other attributes. The JA3 and JA4 prints are based on them.
Such fingerprints help to distinguish a regular browser from an automated client. For example, a request can be sent via a home IP, but its TLS behavior will be similar to a Python script, a Go client, or a headless browser.
This is not a silver bullet, but a strong additional layer. Especially if you use it together with behavior analysis, cookies, HTTP headers, and session history.
5.4. HTTP/2 fingerprinting
Another level of analysis is the HTTP/2 connection parameters. Different browsers and libraries may differ in HTTP/2 settings: frame order, SETTINGS parameters, window sizes, and connection behavior.
These details are invisible to the average user. But for a security system, they can become an additional signal: the request came from a real browser or from an automated client that only pretends to be a browser.
6. Practical site protection architecture
Reliable protection should be multi-layered. Below is an example of a reasonable architecture for a site that wants to be protected not only by IP lists, but also by behavior analysis.
- Basic filtering. To filter out obvious garbage: known scanners, malicious User Agents, empty headers, direct access to technical files, suspicious query methods.
- IP as one of the factors. Consider the country, ASN, network type, reputation, and address history, but don't make a decision based on IP alone.
- The behavioral layer. Look at the frequency, sequence of pages, depth of viewing, repeatability of actions, access to forms and APIs.
- Contextual scoring. Compare IP, browser language, User Agent, TLS fingerprint, HTTP version, cookies, and session.
- Adaptive challenge. Do not block everyone in a row, but enable verification only when suspicious signs accumulate.
- Logging and feedback. Save the reasons for decisions: what exactly increased the risk, which feature worked, and whether the user was then confirmed as legitimate.
7. Important caveat: The IP lock does not need to be completely thrown away.
It would be a mistake to say that IP blocking is never needed anymore. It remains useful in a number of cases.:
- mass scanners from data centers;
- obviously malicious subnets;
- repeated attacks from a single source;
- temporary protection during an incident;
- crude DDoS patterns on the network's periphery;
- blocking technical garbage to the application level.
But IP blocking should be a first-level filter, not the basis of the entire security model. The main mistake is to consider the IP as a full—fledged identity of the user or attacker.
Conclusion: it's not the address that needs to be protected, but the behavior.
Modern cybersecurity is looking less and less like a tabulation of prohibitions and more and more like an analysis of a complex system. Attacks are becoming distributed, low-intensity, and multidimensional. They may not look dangerous at one point, but they manifest themselves as a form of behavior over time.
Therefore, the future of website protection is not in the endless expansion of IP blacklists, but in the transition to multidimensional analysis.:
- behavioral scoring;
- feature consistency analysis;
- TLS and HTTP fingerprinting;
- adaptive checks;
- contextual risk assessment;
- dynamic rules instead of static prohibitions.
The question is no longer which IP the request came from. The main question is how this query works, how it behaves inside the site, and what trajectory it forms in the overall traffic flow.
As far as I know, there is only one startup in Kazakhstan that mathematically develops the concept described above, they share some data on their pages. Others prefer to work according to the scheme: visitor - wireshark - website.
Real protection begins where the system stops seeing an identity in an IP address and begins analyzing behavior as a multidimensional digital footprint.
Почему блокировка по IP больше не спасает сайты: тупик жёсткой логики в современной кибербезопасности
Блокировка по IP-адресу долго считалась простым и понятным способом защиты сайта. Но в эпоху облачных провайдеров, мобильных сетей, CGNAT, резидентных прокси и распределённых ботнетовIP всё чаще перестаёт быть надёжным признаком злоумышленника. Современная атака может быть маленькой по объёму, но сложной по структуре. Поэтому защищать веб-инфраструктуру только чёрными списками IP —значит пытаться решить многомерную задачу одномерным инструментом.
Ключевые темы: IP-блокировка, WAF, CGNAT, ботнеты, поведенческий анализ, TLS fingerprinting,JA3, JA4, HTTP/2 fingerprinting, защита сайтов.
Введение: когда простой фильтр перестаёт работать
В первой части статьи о гипотезе Какеи и кибербезопасности был сформулирован важный тезис: малый объём трафика не означает малую угрозу, если этот трафик имеет высокую размерность признаков. Распределённая атака может не создавать заметного всплеска с одного адреса, но при этом формировать опасный паттерн на уровне всего приложения.
На практике многие защитные системы до сих пор отвечают на такие атаки самым простым способом:блокируют IP-адрес, подсеть или ASN. Этот подход удобен, понятен и иногда действительно полезен.Но если использовать его как главный механизм защиты, он быстро превращается в тупик.
Проблема не в том, что IP-адрес вообще бесполезен. Проблема в том, что IP — это только один признак. А современные угрозы живут не в одной координате, а в пространстве множества параметров: поведения, частоты, маршрута, заголовков, TLS-отпечатков, HTTP-версии, сессий, cookies,браузерных признаков и контекста обращения.
1. Историческая аналогия: тупик «жёсткой логики» и кризис копирования
В 1960-х годах советская кибернетика переживала бурный рост. Академики Виктор Глушков, Аксель Берг и другие учёные проектировали ОГАС (Общегосударственную автоматизированную систему) и работали над амбициозными идеями автоматизированного управления. Важно понимать: эта историческая параллель не означает, что вся советская цифровая школа была ошибочной. Напротив, в ней было много сильных концепций. Но для нашей темы полезна сама доминирующая логика той эпохи: вера в то, что сложную, многомерную динамическую систему можно полностью подчинить набору заранее заданных, детерминированных правил.
Наиболее ярко этот подход проявился в ранних системах машинного перевода на ЭВМ вроде «БЭСМ-6» или «Минск-22». Лингвисты и математики годами вручную кодировали грамматику, синтаксис и контексты через жесткие бинарные правила вида ЕСЛИ... ТО.... Однако живой язык, обладающий бесконечной размерностью и фрактальной структурой, нанёс детерминизму сокрушительный удар. Метафоры, омонимия, контекстуальные сдвиги и сленг порождали лавинообразный рост исключений. На каждое зафиксированное правило требовалось прописать ещё десять, описывающих исключения из него. Это привело к комбинаторному взрыву сложности (combinatorial explosion) и параличу вычислительных мощностей. Попытка описать живую систему статической логикой оказалась принципиально невозможной.
Вместо того чтобы совершить парадигмальный сдвиг в сторону вероятностных и статистических моделей (будущего машинного обучения), руководство советской ИТ-отрасли приняло административное решение, усугубившее системный кризис. На рубеже 1970-х годов уникальные отечественные разработки были фактически свернуты в пользу слепого копирования американской архитектуры IBM-360 (серия ЕС ЭВМ). Ирония судьбы заключалась в том, что попытка догнать Запад через обратную инженерию (Reverse Engineering) наступила на те же самые методологические грабли: невозможно скопировать внешнюю форму процесса, не понимая его внутренней многомерной структуры.
Советские оборонные НИИ послойно стравливали кремниевые пластины контрабандных американских процессоров Intel или Motorola, фотографировали топологию межсоединений под микроскопом и пытались воспроизвести этот рисунок на заводах Зеленограда. Но физика полупроводников не прощала линейного копирования. Малейшие различия в технологических допусках станков, чистоте советского кремния и физико-химических свойствах материалов рождали паразитные токи, микродефекты и перегрев. На схемах из сотен тысяч транзисторов комбинаторный взрыв брака достигал 90%. Инженеры тратили годы на «вылизывание» дефектов чужого статического слепка, но к моменту выхода советского клона в серию на Западе выпускалось принципиально новое поколение микросхем.
Этот тупиковый путь прямолинейного детерминизма и догоняющего копирования предопределил глубокое отставание СССР в глобальной компьютерной гонке, лишив математическую школу адекватной аппаратной базы. А последовавший в 1991 году развал страны окончательно похоронил накопленный потенциал: цепочки кооперации между КБ и заводами разорвались, а лавинообразная утечка мозгов (Brain Drain) за рубеж лишила индустрию целого поколения учёных, способных развивать альтернативные вероятностные подходы.
Современная IP-фильтрация в кибербезопасности сегодня с пугающей точностью повторяет ошибки советского Минрадиопрома пятидесятилетней давности. Когда администратор безопасности пытается защитить веб-ресурс от распределённого ботнета составлением чёрных списков или прямолинейным ограничением частоты запросов (rate limit на основе IP), он совершает классическую ошибку одномерной «жёсткой логики». Он пытается свести сложнейшее, распределённое поведение атакующего к одному статическому признаку — адресу источника. В эпоху CGNAT, облачных провайдеров и резидентных прокси IP-адрес перестал быть монолитным паспортом устройства, превратившись в эфемерный, постоянно меняющийся маркер. Попытка заблокировать фрактальную, низкоинтенсивную угрозу плоским бинарным правилом неизбежно ведёт к лавине ложных срабатываний, «огню по своим» и стратегическому проигрышу защитного контура.
Современная IP-фильтрация часто повторяет ту же ошибку. Она пытается свести сложное поведение пользователя или бота к одному признаку: адресу источника.
2. Почему IP-адрес больше не является надёжной идентичностью
В раннем интернете IP-адрес чаще ассоциировался с конкретным сервером, офисом или домашним подключением. Сегодня ситуация изменилась. Один и тот же IP может принадлежать тысячам пользователей, а один и тот же злоумышленник может менять IP сотни раз за короткий промежуток времени.
2.1. CGNAT: один публичный IP для множества людей
Из-за дефицита IPv4-адресов операторы связи используют CGNAT — Carrier-Grade NAT. При такой схеме множество абонентов провайдера выходят в интернет через общий публичный IP-адрес.
Для сайта это создаёт серьёзную проблему. Если с одного такого IP пришёл вредоносный запрос, это не значит, что весь адрес нужно блокировать. За ним могут находиться обычные пользователи: жители района, сотрудники бизнес-центра, студенты общежития или клиенты мобильного оператора.
Жёсткая блокировка такого IP может нанести бизнесу больший ущерб, чем сама атака: сайт отрежет не только бота, но и реальных посетителей.
2.2. Облака, дата-центры и CDN
Большая часть современного трафика проходит через облачные инфраструктуры, CDN, прокси и балансировщики. IP-адрес может принадлежать Cloudflare, Amazon, Google Cloud, DigitalOcean, Hetzner или другому провайдеру, но сам по себе этот факт ещё не доказывает вредоносность запроса.
С одной стороны, из дата-центров действительно часто идут сканеры, парсеры и боты. С другой стороны, там же могут работать легитимные сервисы: платёжные системы, мониторинг доступности,API-интеграции, корпоративные шлюзы и поисковые роботы.
2.3. Резидентные прокси и ботнеты
Атакующий больше не обязан использовать подозрительный сервер из дата-центра. Он может купить доступ к резидентным прокси или использовать ботнет из заражённых устройств: роутеров, камер, телевизоров, IoT-устройств и домашних компьютеров.
Каждый такой узел может сделать всего один-два запроса в час. Для классического rate limit по IPтакой источник выглядит почти идеально: маленькая частота, обычная страна, обычный провайдер.Но если собрать все эти микрозапросы вместе, получится распределённая атака.
3. Почему чёрные списки IP создают ложное чувство безопасности
Чёрный список IP выглядит убедительно: есть плохой адрес — мы его заблокировали. Но такая защита часто реагирует не на причину атаки, а на её временный след.
У атакующего преимущество: сменить IP дёшево и быстро. У защитника проблема: каждый новый список нужно хранить, обновлять, синхронизировать, проверять и применять без вреда для скорости сайта.
Возникает экономическая асимметрия:
- атакующему легко менять источник трафика;
- защитнику дорого поддерживать огромные списки правил;
- ошибка блокировки может задеть реальных пользователей;
- устаревшие правила продолжают жить в системе и создавать шум;
- новые IP появляются быстрее, чем их успевают классифицировать.
Поэтому IP-блокировка должна быть не главным решением, а только одним из слоёв защиты. Она полезна против грубого шума, массовых сканеров и очевидных источников вредоносной активности, но недостаточна против распределённых и аккуратных атак.
4. Математический взгляд: почему одного IP недостаточно
Представим, что защитная система хочет определить, является ли запрос вредоносным.У неё есть только один признак — IP-адрес. Тогда возникает вопрос:сколько информации о реальной вредоносности запроса даёт нам этот IP?
Это можно описать через условную энтропию Шеннона:
H(Y|X) = - Σ p(x) Σ p(y|x) log₂ p(y|x)Где:
- X — множество IP-адресов;
- Y — исход: легитимный пользователь или бот;
- p(y|x) — вероятность того, что запрос с конкретного IP является вредоносным.
Если за одним IP могут находиться и обычные пользователи, и заражённые устройства, а атакующий постоянно меняет адреса, то знание IP перестаёт резко снижать неопределённость. В таких условиях система всё чаще ошибается:
- false positive — блокирует нормального пользователя;
- false negative — пропускает бота, потому что его IP выглядит чистым.
Практический вывод: IP-адрес может быть полезным сигналом, но он не должен быть единственным основаниемдля окончательного решения.
5. Что должно прийти на смену IP-центричной защите
Современная защита должна оценивать не только источник запроса, но и его внутреннюю структуру. Важно смотреть не просто на то, откуда пришёл запрос, а на то, как он выглядит, как ведёт себя во времени и насколько согласованы его признаки.
5.1. Глобальный поведенческий скоринг
Вместо лимита только по IP нужно анализировать состояние всего endpoint. Например, если на страницу авторизации идут тысячи редких запросов с разных адресов, классический rate limit может ничего не увидеть. Но на уровне приложения паттерн очевиден: идёт распределённый перебор.
В такой ситуации система должна включать не массовую блокировку IP, а адаптивный режим проверки:
- проверка сессии;
- JavaScript challenge;
- captcha только для подозрительных групп;
- временное усиление правил для конкретного endpoint;
- отдельная защита формы входа, поиска, регистрации и API.
Такой подход лучше сохраняет доступ для реальных пользователей и одновременно усложняет жизнь ботам.
5.2. Проверка согласованности признаков
Один признак легко подделать. Сложнее подделать согласованную комбинацию признаков.Поэтому система должна смотреть на запрос как на вектор:
| Признак | Нормальная картина | Подозрительная картина |
| IP и ASN | Пользовательский провайдер, ожидаемая страна | Дата-центр, прокси, внезапная смена региона |
| Accept-Language | Соответствует стране и аудитории сайта | Странная комбинация языков или пустой заголовок |
| User-Agent | Похож на реальный браузер | Старый, редкий, поддельный или технический клиент |
| TLS fingerprint | Похож на Chrome, Safari, Firefox, Edge | Похож на Python, Go, curl, headless-инструмент |
| Поведение | Есть паузы, переходы, нормальная навигация | Ровные интервалы, прямые запросы, отсутствие истории |
Например, сам по себе IP из Казахстана может выглядеть нормально. Но если у запроса таймзона США, заголовок языка не соответствует региону,TLS-отпечаток похож на автоматизированную библиотеку, а поведение не похоже на человека, система должна повысить риск-оценку.
5.3. TLS fingerprinting: JA3 и JA4
Атакующий может купить чистый IP. Но ему сложнее полностью повторить сетевое поведение реального браузера. При TLS-соединении клиент передаёт набор параметров: версии протокола, шифры, расширения и другие признаки. На их основе строятся отпечатки JA3 и JA4.
Такие отпечатки помогают отличать обычный браузер от автоматизированного клиента. Например, запрос может идти через домашний IP, но при этом его TLS-поведение будет похоже на Python-скрипт, Go-клиент или headless-браузер.
Это не серебряная пуля, но сильный дополнительный слой. Особенно если использовать его вместес анализом поведения, cookies, HTTP-заголовков и истории сессии.
5.4. HTTP/2 fingerprinting
Ещё один уровень анализа — параметры HTTP/2-соединения. Разные браузеры и библиотеки могут отличатьсянастройками HTTP/2: порядком кадров, параметрами SETTINGS, размерами окон и особенностями поведения соединения.
Для обычного пользователя эти детали невидимы. Но для защитной системы они могут стать дополнительнымсигналом: запрос пришёл от реального браузера или от автоматизированного клиента, который только притворяется браузером.
6. Практическая архитектура защиты сайта
Надёжная защита должна быть многоуровневой. Ниже — пример разумной архитектуры для сайта,который хочет защищаться не только списками IP, но и анализом поведения.
- Базовая фильтрация. Отсеивать очевидный мусор: известные сканеры, вредоносные User-Agent, пустые заголовки, прямые обращения к техническим файлам, подозрительные методы запросов.
- IP как один из факторов. Учитывать страну, ASN, тип сети, репутацию и историю адреса, но не принимать решение только по IP.
- Поведенческий слой. Смотреть на частоту, последовательность страниц, глубину просмотра, повторяемость действий, обращения к формам и API.
- Контекстный скоринг. Сравнивать IP, язык браузера, User-Agent, TLS-отпечаток, HTTP-версию, cookies и сессию.
- Адаптивный challenge. Не блокировать всех подряд, а включать проверку только при накоплении подозрительных признаков.
- Логирование и обратная связь. Сохранять причины решений: что именно повысило риск, какой признак сработал, был ли пользователь потом подтверждён как легитимный.
7. Важная оговорка: IP-блокировку не нужно выбрасывать полностью
Было бы ошибкой сказать, что блокировка по IP больше никогда не нужна. Она остаётся полезной в ряде случаев:
- массовые сканеры с дата-центров;
- явно вредоносные подсети;
- повторяющиеся атаки с одного источника;
- временная защита во время инцидента;
- грубые DDoS-паттерны на периферии сети;
- блокировка технического мусора до уровня приложения.
Но IP-блокировка должна быть фильтром первого уровня, а не основой всей модели безопасности. Главная ошибка — считать IP полноценной идентичностью пользователя или атакующего.
Заключение: защищать нужно не адрес, а поведение
Современная кибербезопасность всё меньше похожа на таблицу запретов и всё больше похожа на анализ сложной системы. Атаки становятся распределёнными, низкоинтенсивными и многомерными. Они могут не выглядеть опасными в одной точке, но проявляют себя как форма поведения во времени.
Поэтому будущее защиты сайтов — не в бесконечном расширении чёрных списков IP, а в переходе к многомерному анализу:
- поведенческому скорингу;
- анализу согласованности признаков;
- TLS и HTTP fingerprinting;
- адаптивным проверкам;
- контекстной оценке риска;
- динамическим правилам вместо статических запретов.
Вопрос уже не в том, с какого IP пришёл запрос. Главный вопрос — как этот запрос устроен, как он ведёт себя внутри сайта и какую траекторию формирует в общем потоке трафика.
Насколько я знаю в Казахстане есть только один стартап, который математически разрабатывает описанную выше концепцию, кое какими данными они делятся на своих страницах. Другие предпочитают работать по схеме: посетитель - wireshark - сайт.
Настоящая защита начинается там, где система перестаёт видеть в IP-адресе личность и начинает анализировать поведение как многомерный цифровой след.
Share
