Honeypot ADR
Application Detection and Response. It sees and stops attacks on your application at the level of the attacker, not the level of the request.
WAF, anti-DDoS and bot protection on one platform. Traffic never leaves Uzbekistan.
What ADR is and how it differs from a WAF
ADR (Application Detection and Response) is an approach that has emerged over the past few years. It follows the same logic as EDR in endpoint protection and NDR in network protection, only the layer is different: the application layer.
A classic WAF (Web Application Firewall) answers one question: “is this request malicious?” Every request is matched against a rule set, and there are two possible answers: pass or block. Once the request is served, the WAF forgets it.
ADR answers a different question: “who is this, what are they trying to do, and what should we do about it?” Every client is tracked across the session, its behaviour accumulates, attack stages are identified, and the response is delivered in stages.
| Aspect | Classic WAF | Honeypot ADR |
|---|---|---|
| Unit of analysis | A single request | Session, client, campaign |
| Memory | None, each request stands alone | Yes, behaviour accumulates |
| Decision | Pass or block | Observe, throttle, challenge, block, deceive |
| Detection basis | Rule match | Rules, behaviour, context, reputation |
| Result | A list of blocked requests | An incident: who, when, how, at which stage |
| Question | Is this request malicious | What is this attacker doing |
Why this matters
A modern attack is not a single request. It comes in stages: first reconnaissance (which technology is in use, which paths exist), then probing (which parameter responds), then exploitation. Taken on its own, a request from any one stage can look harmless. Only when they are viewed together does the attack become visible.
A classic WAF does not see the first two stages, because it does not connect requests to each other. ADR does see them, because it remembers the session.
Why Honeypot
What sets us apart from other solutions
Traffic never leaves Uzbekistan
A foreign cloud WAF takes your traffic into its own network. It terminates TLS (the encryption between the browser and the server) abroad and sees the contents of your requests on its own servers. For banks, insurers and the public sector this is not a question of technical convenience. It is a legal one.
Honeypot is located in Uzbekistan. Traffic does not cross the border, TLS is terminated at a local point, and logs are stored locally. If you require it, the entire platform can run inside your own infrastructure.
A second effect: latency. A request from a user in Tashkent does not travel to Frankfurt or Singapore and back.
Detection at the level of grammar, not of patterns
Many WAFs look for attacks with text patterns (regular expressions). This approach has two problems: an attacker can work around the pattern, and normal traffic can match the pattern by accident and be blocked in error.
SQL injection: the text of the request is passed through an SQL tokeniser and its grammatical structure is analysed. That is, the system does not ask “is UNION SELECT written here”, it asks “is this parameter changing the structure of the SQL query”.
XSS (cross-site scripting): a DOM state machine is used. The context the input lands in inside the browser is modelled (HTML text, attribute, JavaScript, URL), and it is judged on whether it is dangerous in that context.
The practical result: obfuscated attacks are detected too, and legitimate traffic is blocked in error less often.
Blocking at the kernel level
Blocking an application-layer (L7) attack in user space still spends server resources. We block an identified source at the kernel level: the packet never reaches the application layer at all.
This is where the difference shows during high-volume attacks: the blocking does not itself become a load.
A graded response, not a binary one
“Block or allow” is a blunt instrument. Block a suspicious but unconfirmed client straight away and you lose a real customer. Let it through and you let the attacker through.
Honeypot responds in stages.
| Stage | What happens | Noticeable to the user |
|---|---|---|
| Observe | Behaviour is recorded, score accumulates | No |
| Throttle | Request rate is limited | Almost none |
| Challenge | A browser challenge is sent | A few hundred milliseconds |
| Block | The request is refused | Yes |
| Deceive | The attacker is given a fake response | They do not know they are blocked |
The last stage stands apart: an attacker who knows they are blocked will look for another way. One who does not know wastes their time.
Local threat intelligence
The threat data of global vendors is global. A campaign aimed squarely at the financial sector in Uzbekistan may not show up in it, because they have no sensor here.
We do. Every protected site on the platform also works as a sensor. An attacker profile identified at one customer is immediately scored as high risk at the others.
What you see
Three screens showing the platform's daily work: overall state, the session list, and the relation graph of a single session. Captured from a running panel; visitor IP addresses are masked.
State, request rate, blocked and challenged requests, the leading attack type and origin response time on one screen. Below: traffic distribution, p50/p95/p99 latency, attack geography and attack types. Every point leads into the request log.
Requests are folded into one trail per device: operating system, browser, DEVICE_ID and UA_HASH, network (ASN and country), request count, blocks, risk score and session duration. Above it, the expression language — for example `verdict:block AND uri contains "/admin"`.
Everything connected to one session: IP addresses, ASNs, countries, the domain, the path, the module that fired and the verdict returned. This is where one device is visibly standing behind a dozen addresses — which is what the “unmask VPN” control is for.
Web Application Firewall
Detects and stops attacks aimed at the application.
- OWASP Top 10 (the reference list of the most common web application risks): SQL injection, XSS, command injection, file inclusion, path traversal, SSRF, XXE and others
- Request body analysis: JSON, XML, multipart, form data
- Response analysis: stops information leaking through error messages and technology version strings
- Normalisation chain: against bypass attempts that use encoding
- Virtual patching: cover for a known vulnerability without changing the application
Anti-DDoS
Against distributed denial of service attacks at the network and application layers.
- L3 and L4: SYN flood, connection count limits, filtering at the kernel level
- L7: request rate limits at several layers (global, IP, session, endpoint)
- Adaptive thresholds: tuned to the site’s own traffic baseline
- Under Attack mode: a stricter policy switches on automatically during an attack
- Restriction by geography and provider (ASN, the operator’s autonomous system number)
Bot management
Separates automated traffic from human traffic.
- Search engine bots are identified by verification. The User-Agent, the label a client sends about itself, is not trusted: it is re-checked against the DNS records for that address
- Malicious bots: scanners, content scrapers, password guessers
- Challenge ladder: from a transparent check the user never sees, up to a CAPTCHA the user has to solve
- A separate policy and limit for each bot
Real-time monitoring
Seeing what is happening.
- Live traffic flow, blocks, challenges
- Breakdown by attack type
- Source country and provider
- Every metric links through to the request log
Request log
The ability to inspect every request.
- The full HTTP request and response
- Which rule fired and why
- Client details: location, provider, reputation, session history
- A query language and saved views
- CSV and JSON export
Sessions
The visible part of the ADR core.
- Every client session and its risk score
- Timeline: which request, which rule, how the score grew
- Attack stages: reconnaissance, probing, exploitation
- Manual action on a session
Policies and the builder
Fitting protection to your own application.
- A visual condition builder and a text mode
- Simulation: see in advance what a policy would do once enabled
- Versioning and rollback in one click
- Exception management: at rule, parameter, path or session level
Access lists
Setting out exactly who gets in and who does not.
- Allow and deny by IP, network, provider, country and User-Agent
- Time-limited entries
- Reason and change history
Caching and acceleration
Reducing the load that reaches the origin server.
- Static content caching
- Less load on the origin server
Reports
Reporting status on a regular basis.
- Scheduled periodic reports
- A short version for management and a detailed one for the technical team
- PDF and CSV
Administration
Team, permissions and integration.
- Multiple users, roles and permissions
- An audit log of every change
- Two-step authentication
- API (application programming interface) and webhook integration
Deployment options
- Best for
- Teams that need to start fast
- Description
- You change a DNS record and protection is live. No server required.
- Best for
- Banks, the public sector, closed networks
- Description
- The whole platform runs in your infrastructure. No data leaves it.
- Best for
- Mixed requirements
- Description
- Traffic is processed on your side, management sits in the cloud.
Who it is for
Banks and financial institutions
- Data residency requirements
- Regulatory reporting
- Internet banking protection
- Mobile application API
Insurance companies
- Customer data
- Online sales platforms
- Partner APIs
Government portals
- Public service pages
- High load
- DDoS exposure
E-commerce
- Payment flows
- Price scraping
- Account login attempts
IT and telecom
- Multi-domain infrastructure
- Resale to their own customers
Questions
Frequently asked questions
In the cloud option, changing a DNS record is enough. Most of the time goes on tuning: we prepare a policy that fits your application and start it in monitoring mode first.
A new policy does not start blocking straight away. It runs in monitoring mode first, what would be blocked is measured, exceptions are added, and only then is it switched on.
Because the platform sits locally, the path a request takes is shorter than with foreign solutions: traffic does not cross the border.
The system can be set not to stop traffic during an outage. That setting is your choice: security first, or continuity first.
You can upload a certificate or turn on automatic issuance. Expiry is flagged in advance.
Events are sent to your SIEM (security information and event management system). Webhooks and an API are available.
Do you want to see what attacks your application is under right now?
We run a free analysis: for one week we watch the automated scanning and attack attempts aimed at your domain, and give you the result as a report. Nothing is blocked at this stage and no configuration is required.
Let’s start
