IBANK2RU MITIGATOR CLOUD LLC sells hosted capacity that still depends on racks, transit and repair windows

Summary

• The public identity trail is strong. RIPE ties ORG-IL186-RIPE to MITIGATOR CLOUD LLC in Moscow, AS51464 is named IBANK2RU, AS43048 is named mitigator-cloud, and the current RIPEstat views show both ASNs announced on 12 July 2026.
• The public service trail points to DDoS-cleaning capacity, not ordinary self-service VPS. Mitigator Cloud describes a Russian 24/7 service for corporate clients, banks, IT companies and service providers, with traffic diversion by A-record change, constant or attack-time BGP announcement, provider prefixes, L2 tunnel and reverse-proxy delivery.
• The main dependency risk is physical and operational. Customers are relying on scrubbing nodes, router ports, upstream capacity, prefix policy, DNS or BGP changes, clean-traffic delivery paths, support authority, update windows, backup procedures and the availability of engineers during attacks.
• The evidence grade is Medium. Routing identity and service claims are well supported by public sources; facility, rack, spare-capacity, restore-test and customer portability evidence remain thin in the public record.

The useful question starts with iBank2.RU

The title of this profile uses the strange combined name IBANK2RU MITIGATOR CLOUD LLC because the public evidence does the same. The autonomous system assigned in 2010 is not named after a modern cloud brand. The RIPE aut-num record for AS51464 calls the network IBANK2RU, ties it to ORG-IL186-RIPE, and lists an AS set named AS-IBANK2RU. A route object for 109.232.248.0/21 describes the prefix as IBANK2.RU, Ltd. at 46 Nizhnyaya Pervomayskaya Street in Moscow, with origin AS51464. The same address appears in the RIPE organisation trail for MITIGATOR CLOUD LLC.

That older iBank2.RU trail matters because the service now marketed as Mitigator Cloud presents itself as the successor to a traffic-cleaning function, not as a blank-slate cloud platform. The Mitigator Cloud home page says a competence center for DDoS protection was created in 2009, a traffic-cleaning center named iBank2.RU was created in 2010, and in 2015 the iBank2.RU cleaning center was moved onto an internally developed MITIGATOR solution and renamed Mitigator Cloud. Those are company-authored claims, so they should not be treated as independent proof of every operating detail. They are still central to understanding what the hosted capacity is supposed to be: a place where customer traffic can be diverted, inspected, filtered and sent back cleanly.

In other words, the risk is not only whether a virtual machine can boot. The risk is whether a protected service remains reachable when hostile traffic appears and traffic steering is changed under pressure. A customer may rely on Mitigator Cloud because an application is protected by reverse proxy, because a prefix can be announced toward the cleaning service, because an A record can be switched, because a tunnel delivers cleaned traffic back to the customer, or because a service provider uses Mitigator capacity behind its own customer contract.

Each model turns a cloud promise into a chain of physical assets: routers, links, servers, licenses, packet processors, storage, monitoring, support desks and repair windows.

The public record supports treating IBANK2RU MITIGATOR CLOUD LLC as a real networked service dependency. It does not support treating it as a fully transparent, independently verified multi-site cloud. That distinction is the heart of the article. The company can be important even when public sources do not expose its racks. The absence of rack-level evidence is not evidence of absence; it is a buyer due-diligence problem.

Legal and network identity are clearer than rack identity

The legal-network identity is the strongest part of the file. The RIPE organisation entity ORG-IL186-RIPE identifies MITIGATOR CLOUD LLC, country RU, with the Moscow address at Nizhnyaya Pervomayskaya str. 46, postal code 105203, and phone number +7 495 965 15 64. The entity names EXH1-RIPE as the abuse contact and points to MNT-IBANK2RU as one of the maintainers. The record was created in November 2009 and last modified in May 2026.

The MNT-IBANK2RU maintainer entity is also useful because it shows continuity. It was created in November 2009 and last modified in May 2026. The EXH1-RIPE role entity is named iBank2RU Admin, gives the same Moscow address, and lists [email protected] as the abuse mailbox. These are not marketing details. They are registry details that connect the old iBank2.RU naming, the current Mitigator Cloud legal name and the public Internet-number-resource trail.

AS51464 is the narrower iBank2.RU network. RIPE shows it assigned, created on 31 August 2010 and last modified in June 2022. Its import and export policy mentions the Moscow route server AS8631, AS42861, AS29226, AS43048 and AS207104. The RIPE RDAP record for AS51464 confirms the AS name IBANK2RU, the single-AS allocation range, the 2010 registration date and the registrant links to ORG-IL186-RIPE and MNT-IBANK2RU.

AS43048 is the broader Mitigator network. The RIPE aut-num record for AS43048 uses the AS name mitigator-cloud, ties it to ORG-IL186-RIPE, and lists policy with RETN AS9002, SpaceWeb AS202984, COMCOR AS8732, the Moscow route server AS8631, AS51464 and several customer- or peer-looking ASNs. Its last modified date is 18 June 2026, which is recent enough to make the entity relevant to current routing analysis while still requiring BGP telemetry for current state.

The two-AS structure is important. AS51464 carries the old iBank2.RU identity and a small but live IPv4 footprint. AS43048 appears to carry the bigger mitigation-cloud routing posture, with more observed neighbors and IPv6. The AS-MITIGATOR-CLOUD as-set includes AS43048, AS51464 and several other ASNs. That supports a broader routing policy surface, but it should not be misread as an ownership chart. AS-set membership can reflect customers, peers, downstreams or routing policy needs. A protected service customer should care about which exact AS and which exact prefix carry its traffic, not only the brand name on the service page.

What Mitigator Cloud publicly says it sells

The clearest customer-facing evidence is the Mitigator Cloud page. It describes the service in Russian as comprehensive 24/7 DDoS protection for corporate clients, banks, IT companies and service providers, with round-the-clock monitoring. It claims protection against L3-L7 attack types, an individual approach, attack auto-detection with a reaction time up to five seconds, and attack notifications by email, Telegram, Vestochka push and SMS. The page also says the service is based on the MITIGATOR software, which it describes as Russian software registered in the domestic software register under number 4063 and certified by FSTEC under certificate number 5059.

This is not a neutral audit. It is company-authored service copy. Its value is that it defines the service surface a customer is being asked to buy. Mitigator Cloud is not merely claiming "cloud" in the abstract. It describes concrete traffic-steering options: replacing an A record, permanent BGP announcement, BGP announcement during an attack and use of Mitigator Cloud prefixes. It also describes delivery options for cleaned traffic: L2 tunnel, TCP reverse proxy and HTTP/HTTPS reverse proxy. Those details change the risk analysis from a generic hosting profile to a routing-and-cleaning profile.

The product site mitigator.ru/maineng describes MITIGATOR as DDoS protection software for corporate clients, state companies and security service providers. It says the product detects and suppresses L3-L7 DDoS attacks and contains more than 50 countermeasures using challenge-response, reputation, rate-based, regular-expression, validation, limiting, IP-list and application-behavior logic. The about page adds product claims around access control, policy-level protection, API control, dashboards, Docker-container delivery, x86-64 processor and network-card support, GRE tunneling and hardware bypass support. The services page describes implementation, support, expert assistance, training and live help during attacks.

There is an important boundary here. The product site metadata presents AO BIFIT as the software organisation behind MITIGATOR, while the cloud service page names LLC Mitigator Cloud in the footer and gives [email protected] plus the same Moscow phone number seen in RIPE. This article does not infer a corporate ownership relationship beyond what the public pages and registry records say. It treats the product pages as evidence for how the service technology is described, and the RIPE and cloud pages as evidence for the Mitigator Cloud network-service identity.

For customers, the service claims imply several dependency questions. If protection is done by A-record replacement, how fast can DNS be changed and what TTLs are in effect? If protection is done by permanent BGP announcement, what latency and routing changes are normal even without an attack? If protection is done only during attacks, who authorizes the announcement and how are existing sessions affected? If clean traffic is delivered by tunnel or proxy, where does encryption terminate, who holds secrets, what logs are stored, and what happens when the tunnel endpoint fails? These are not academic questions.

They are the places where a promised cleaning service becomes a real operating dependency.

AS51464 is live, small and IPv4-only in the current snapshot

RIPEstat gives a stronger signal than a website because it shows observed routing state. The AS overview for AS51464 showed the holder as IBANK2RU MITIGATOR CLOUD LLC and marked the AS as announced on 12 July 2026. The routing-status view showed first observation in August 2010, current visibility on 12 July 2026, full IPv4 visibility across the RIPE RIS peers sampled, no IPv6 visibility, six announced IPv4 prefixes, 2,304 IPv4 addresses and thirteen observed neighbors.

The announced-prefixes view for AS51464 listed current announcements including 109.232.248.0/21, 109.232.252.0/24, 109.232.253.0/24, 109.232.254.0/24, 109.232.255.0/24 and 185.6.47.0/24. The exact list can change, and the snapshot should not be treated as a permanent inventory. It is enough to prove that AS51464 is not a dormant label. It was visible in BGP at the time checked.

The AS routing-consistency view for AS51464 adds useful nuance. It showed several prefixes that were both in BGP and in RIPE routing registry data, including 109.232.248.0/21, 109.232.252.0/24 and 109.232.253.0/24. It also showed policy relationships where some peers were present in both BGP and whois views and others were only visible in one view. For example, AS43048 appeared in both BGP and whois for imports and exports, while several observed peers were in BGP without matching whois policy in that output. That does not make the routing wrong. It means customers should verify the exact route objects, filters and upstream acceptance for the prefixes they will use.

RPKI is not a visible strength in the sampled AS51464 data. The RIPEstat RPKI validation call for AS51464 and 109.232.248.0/21 returned unknown, with no validating ROAs. The similar check for 185.6.44.0/22 also returned unknown. Unknown is not invalid. It simply means route-origin authorization was not visible for those sampled combinations in the validator output. A customer whose uptime depends on upstream filtering should ask whether the exact service prefix has a valid ROA, which route objects exist, which upstreams accept them, and what happens if a route-origin policy changes during an attack.

The operational meaning of AS51464 is therefore bounded. It is live, small, IPv4-only in the current telemetry and strongly tied to the iBank2.RU name. It can support protected-service dependencies, but it does not by itself prove the scale, room layout or spare capacity behind the service.

AS43048 is the broader mitigation surface

AS43048 looks more like the current mitigation-cloud routing surface. The RIPEstat AS overview for AS43048 showed the holder as mitigator-cloud MITIGATOR CLOUD LLC and marked the AS as announced on 12 July 2026. The routing-status view showed first observation in July 2007, current visibility in July 2026, seven IPv4 prefixes, 2,304 IPv4 addresses, one IPv6 prefix, 65,536 IPv6 /48s and forty-three observed neighbors. The IPv6 entry is large because the observed prefix is a /32, not because every /48 is necessarily used by customers.

The announced-prefixes view for AS43048 showed announcements including 185.6.44.0/22, 91.209.119.0/24, 109.232.248.0/22, several 109.232.248.0/24 through 109.232.251.0/24 routes, and 2a02:4f40::/32. The route6 object for 2a02:4f40::/32 describes it as IBANK2.RU with origin AS43048. The RPKI validation call for AS43048 and 2a02:4f40::/32 also returned unknown with no validating ROAs.

AS43048 has a richer policy entity than AS51464. Its RIPE aut-num lists transit or policy relationships with AS9002, AS202984, AS8732 and AS8631, along with several ASNs for which AS43048 accepts the named AS and announces any routes back. The RIPEstat routing-consistency view shows AS9002, AS202984, AS8732, AS207104, AS52016, AS206955 and AS51464 present in both BGP and whois for import/export rows, while it also shows observed BGP neighbors not present in the whois policy output. Again, that is not automatically a problem.

It is a reason to ask which relationships are production transit, which are customers, which are private, and which carry cleaning traffic during an attack.

PeeringDB is much thinner. The PeeringDB network query for AS43048 returns a network named MITIGATOR CLOUD LLC, created in June 2025 and updated shortly after, but it gives no disclosed traffic level, no general peering policy, no public website, and no IX or facility counts in the returned fields. The PeeringDB organisation entry is similarly sparse. The netixlan and netfac API views for that PeeringDB network return empty lists.

That PeeringDB gap should be read carefully. Many real networks do not maintain complete PeeringDB facility data. Empty IX or facility rows do not prove that Mitigator Cloud lacks exchange ports, racks or carrier sites. They do mean that a public reader cannot use PeeringDB to verify where the service sits, whether there are independent sites, which facilities host routers, or how many places can clean traffic at once. For a buyer, the public record shifts the burden to contract evidence, diagrams, route tests and incident procedures.

Hosted capacity here is cleaning capacity

The assignment calls this a hosted-capacity profile, but the public evidence points to a specialized kind of hosted capacity: DDoS-cleaning capacity and protected-service delivery. That capacity is still physical. Packets have to enter a network port. Scrubbing appliances or servers have to inspect them. Legitimate traffic has to leave through another port, tunnel or proxy. DNS and BGP have to send traffic to the right place at the right time. Engineers have to distinguish attack traffic from customer traffic without creating a second outage.

The Mitigator deployment documentation explains why this is not a simple website-proxy product. It describes symmetric and asymmetric deployments, always-on and on-demand defense, inline, on-a-stick and common-LAN physical connection models, L2-transparent and L3-router modes, horizontal scaling by LACP or ECMP, VRRP, GRE tunneling and BGP announcement examples. It also states that always-on protection filters attacks as soon as they appear but can affect route optimality and load, while on-demand protection reduces normal background load but increases the interval before traffic reaches protection and may reset established sessions.

That is a remarkably practical source for customer risk. If a protected customer uses always-on mode, Mitigator capacity becomes part of the normal path even on quiet days. Every maintenance window, countermeasure change, route change and packet-processor limitation can affect real users. If a customer uses on-demand mode, the normal path may be cleaner until an attack begins, but the customer then depends on detection thresholds, signaling, route propagation and clean-traffic return under stress. In both models, the service is only as resilient as the physical and routing path behind it.

The BGP signaling documentation is equally relevant. It describes MITIGATOR using BGP to signal upstream telecom operators or managed security providers, with prefixes added to a signaling list when auto-detection thresholds are exceeded. It warns that if the external scrubbing service is not configured to continue scrubbing while high traffic is observed, rate drops after scrubbing starts can cause prefixes to be removed and scrubbing to stop, creating flapping risk. For a customer, this means the cleaning service is not simply "on" or "off." It is a state machine involving thresholds, announcements, neighbor configuration, communities, next hops, upstream behavior and timing.

The price page explains another hidden capacity constraint: MITIGATOR licenses limit the rate of traffic entering the system, counting both attack traffic and legitimate traffic. The page says the minimum licensed bandwidth available for purchase is 100 Mbps, with a minimum assignment step of 50 Mbps to a device, and that pricing is calculated on request. A customer buying a cloud-protection service may never see those license knobs, but the economics still apply. Attack traffic consumes capacity. Legitimate traffic consumes capacity. Overprovisioning costs money. Underprovisioning turns an attack into dropped legitimate traffic.

This is why the public routing footprint cannot be converted directly into customer capacity. AS51464 and AS43048 show live networks. They do not show how much scrubber throughput is installed, how much is licensed, how much is reserved, how much is already sold, how much is available in a specific city or how quickly capacity can be increased. For a bank, IT company or service provider, the key commercial question is not just "does the AS announce routes?" It is "what attack size and normal traffic level are contractually covered, where, and through which return path?"

The rack and facility story remains mostly off-record

Facility opacity is the biggest public weakness. RIPE gives a Moscow legal and contact address. The route object gives the same Moscow address. The cloud service gives a Russian phone number and mail address. Those details anchor the entity in Russia, but they do not identify the data halls, colocation providers, rack footprints, power topology, carrier meet-me rooms, remote-hands arrangements or spare-parts inventory used by the cleaning service.

PeeringDB does not fill the gap. AS43048 has an entry, but its public IX and facility lists are empty. AS51464 did not return a usable PeeringDB network entry in the query used for this review. Again, that is not proof of no infrastructure. It is proof that the public directory most operators use for facility and exchange disclosure does not currently answer the buyer's practical questions.

For a DDoS mitigation provider, the facility question is more severe than it is for ordinary hosting. A normal hosted service can sometimes tolerate a short maintenance window if it has backup and customer communication. A scrubbing service is often needed during the exact moment when capacity and staff are under the most stress. If traffic has been diverted by BGP or DNS, the scrubbing nodes, edge routers and clean-traffic return links become part of the customer production path.

If those nodes lose power, if a top-of-rack switch fails, if a router line card saturates, if a tunnel endpoint is down or if a facility access delay prevents replacement, the protected customer may be worse off than before diversion.

Customers should therefore ask for site-specific evidence. Where are the cleaning nodes used for this contract? Are there two physically independent cleaning sites or only two routing options into one fault domain? Which carriers enter each site? Are the return tunnels terminated in the same room as the scrubbing nodes? Which components have local spares? Which activities require facility remote hands? What happens if the customer is under attack during the provider's own maintenance window?

The public record cannot answer those questions. It can only justify asking them. The combination of live ASNs, company claims and sparse facility disclosure points to a real service with a public verification gap. That gap is manageable for a sophisticated buyer, but only if the buyer treats facility independence as evidence to obtain, not a promise to assume.

Transit and route policy are customer-facing dependencies

The public route policy suggests useful diversity, but it does not by itself prove resilience. AS43048 lists several upstream and peer relationships in RIPE, and RIPEstat observes forty-three neighbors. AS51464 observes thirteen neighbors. The routing-consistency outputs show both documented and undocumented live relationships. The AS set includes a broader group of ASNs. All of that says Mitigator Cloud has a meaningful routing surface.

It does not say every customer service can survive every upstream failure. DDoS mitigation relies on where hostile traffic enters, what routes are preferred by remote networks, how quickly BGP changes propagate, and whether return traffic follows a viable path. A customer using permanent BGP announcement through Mitigator Cloud needs to know which upstreams carry the prefix in normal operation and whether any single provider or local route choice creates a choke point.

A customer using attack-time BGP announcement needs to know how fast remote networks converge, whether more-specific routes are accepted, and whether the customer's upstreams will permit the steering action.

The RPKI unknown status for sampled prefixes is also a real due-diligence item. Unknown is not a failure, and many networks still operate with unknown status. But route-origin validation increasingly affects filtering decisions, troubleshooting and incident confidence. A customer that wants a prefix protected by Mitigator Cloud should verify the exact origin AS, route object, ROA status and upstream filter plan before the first attack. It should also test route withdrawal and restoration during a quiet period. Testing during an attack is a poor way to learn how the path behaves.

The product documentation's distinction between always-on and on-demand modes makes this even more important. Always-on mode may give faster filtering but can make Mitigator Cloud part of steady-state latency and failure exposure. On-demand mode may preserve the normal path but depends on detection, signaling and route change speed. Neither model is universally better. The right answer depends on the protected service, tolerance for latency, customer network skill, attack profile, TLS handling and the cost of dropped sessions.

One practical buyer test is prefix-level traceability. Ask Mitigator Cloud to identify the exact AS path expected before, during and after an attack. Ask which communities or next hops are used. Ask whether clean traffic returns through L2 tunnel, GRE, TCP reverse proxy or HTTP/HTTPS reverse proxy. Ask whether customer egress traffic is symmetric or asymmetric. Ask what logs prove that a route event happened. If the answer stays at brand level, the customer has not yet mapped the operational dependency.

Support is part of the product, not an accessory

The Mitigator Cloud page promises 24/7 monitoring and notifications. The product services page describes implementation support, vendor expertise, training, closed customer streams and expert help during attacks. These are meaningful claims because DDoS protection is human-assisted infrastructure. Automated detection and countermeasures are valuable, but customer survival often depends on who can authorize the next step.

During a real incident, many teams may need to act: the customer application team, the customer's DNS operator, the customer's network team, Mitigator Cloud's support team, upstream providers, facility remote hands and possibly the software vendor. If the customer uses reverse proxy, support may also touch TLS, headers, source IP restoration, WAF-like behavior and log sharing. If the customer uses BGP, support may touch prefix announcements, communities, route filters and tunnel endpoints. If the customer uses HTTP log streaming, support may need the protected server to send useful telemetry while under stress.

The public evidence does not show incident-history statistics, support-response logs, service-credit terms or escalation charts. That is normal; many providers keep those private. It means customers should ask explicitly. Who can change a protection policy outside business hours? Who can announce or withdraw a prefix? Who can add an emergency countermeasure? Who can replace a failed server or network adapter? Who can approve a tunnel change? Who can roll back an update? Who can speak to the customer's upstream provider? The person who answers the support phone must have a path to someone with authority.

The documentation reinforces this because the system itself has state. Cluster data, instance data, metrics, policies, thresholds, BGP neighbors, tunnel settings and version state all matter. A support team that understands only the web interface may not be enough during a severe outage. A support team with deep network authority but no access to customer application context may also be limited. The customer should know where the boundary sits before the service is live.

Updates, backups and cluster design create repair windows

The product documentation is unusually helpful on repair windows because it describes the operational cost of running the technology. The cluster mode page says common databases for all MITIGATOR instances are physically stored on one server in the base-instance design, and that other instances access the database of the base instance. If a cluster is assembled from previously independent instances, the page warns that existing policies, incident data, graphs and other stored information on non-leader instances are deleted unless saved first. That is not a customer service failure; it is a normal systems-administration reality that must be planned.

The internal fault-tolerant storage page describes a stronger model in which synchronized database copies are physically stored on different servers. It also describes streaming replication, pgfailover, promotion of a standby when the primary is unavailable, the need for reliable communication between nodes, and split-brain behavior if connectivity partitions the cluster. The page explicitly warns not to use domain names because connectivity will break in case of DNS failure. For customers, that one detail is gold: the vendor documentation itself recognizes that names, node reachability and storage state can become part of the failure mode.

The backup page says backups are possible only to the same MITIGATOR version with which the backup was made. It distinguishes cluster data, instance data and metrics, and describes full and lightweight backup forms. It also says recovery requires deleting the existing PostgreSQL volume and restoring data, and that support may need restore logs if errors appear. This is normal engineering. It also means a customer should not ask only "do you have backups?" The better question is "when was the last restore tested on the version running the service I use?"

The versions page lists current, supported and unsupported version statuses. The v26.04 update page says updates to v26.04 require Linux kernel 5.0 or higher for full MITIGATOR functionality, must be performed from a v25.12.5 or later minor version, and require a full backup because the PostgreSQL version changes and the database must be restored. This is the maintenance-window reality behind a protection service. Even if the customer never sees the product admin screen, the provider's ability to maintain, back up and restore its protection platform affects customer uptime.

Customers should ask how Mitigator Cloud handles these windows in its hosted service. Are customer policies stored in a multi-node fault-tolerant arrangement? Are metrics and incident logs retained after restore? Are updates performed site by site? Is clean-traffic delivery drained before maintenance? Are route announcements withdrawn or kept? Are customers notified when the protection platform itself is being upgraded? Public documentation explains the technology's operating constraints. It does not prove how the cloud service applies them.

Data locality is Russian, but data handling is a separate question

The assignment region is RU, and the public evidence supports Russia as the operating context. RIPE lists MITIGATOR CLOUD LLC in Moscow. The cloud page describes a Russian service and names Russian regulatory certifications. The phone number is Russian. The service is framed around Russian corporate clients, banks, IT companies and service providers. AS51464 and AS43048 are RIPE-region number resources tied to the Russian organisation.

That supports a Russian locality thesis, but it does not answer every data-handling question. DDoS mitigation can expose sensitive operational material even when it does not host the customer's application database. Reverse-proxy protection may see HTTP metadata and possibly decrypted traffic, depending on the model. HTTPS protection can involve no decryption, certificate/key transfer or log streaming, according to the Mitigator Cloud page. BGP-based protection may expose prefix lists, traffic telemetry, attack signatures and customer network design. Tunnels may carry cleaned production traffic back to the customer.

For regulated or sensitive customers, the question is not simply "is the provider Russian?" It is where traffic is inspected, where logs are stored, whether TLS keys are transferred, who can read packet captures, where telemetry and reputation data are processed, how long attack data is retained, and whether any support or monitoring function crosses a jurisdictional boundary. The public service page indicates options; it does not publish a full data-handling contract.

Data sovereignty is therefore best understood as a due-diligence topic rather than an automatic benefit. A Russian bank or service provider may prefer a Russian DDoS service for procurement, latency, support language or regulatory reasons. That preference does not remove the need to document where clean traffic flows, who has operational access and how evidence is retained after an incident.

Who is affected when this capacity fails

The affected population follows the customer list on the Mitigator Cloud page: corporate clients, banks, IT companies and service providers. For a bank, failure may mean a customer login page, online-banking interface, payment-adjacent service or public website becomes slow or unreachable during an attack. For an IT company, failure may mean SaaS endpoints, customer portals, APIs or dashboards lose reachability. For a service provider, failure may cascade into downstream customers who believe they bought protection from their own provider, not from Mitigator Cloud directly.

The impact mechanism depends on the service model. If A-record switching is used, DNS delay and stale resolver caches can keep some users on the unprotected path while others move through Mitigator Cloud. If permanent BGP announcement is used, Mitigator Cloud is always in the data path, so provider-side outages can affect normal traffic. If attack-time BGP is used, route convergence time, filter acceptance and announcement stability become part of the incident. If clean traffic is returned by L2 tunnel, TCP reverse proxy or HTTP/HTTPS reverse proxy, the return path can fail independently of the inbound scrubbing path.

False positives can be as damaging as missed attacks. A countermeasure that blocks hostile clients but also blocks legitimate mobile networks, corporate NATs, payment callbacks or API clients can turn protection into self-inflicted downtime. The product pages emphasize many countermeasure types and policy-level controls. That flexibility is valuable only if the provider and customer can tune it fast enough and verify legitimate traffic during an incident.

The same is true for capacity exhaustion. A license or physical port sized for ordinary traffic plus moderate attacks can be overwhelmed by a larger attack. Because the price page says incoming traffic includes both attack and legitimate traffic for licensing purposes, the economic pressure is visible even if the customer does not see the provider's internal numbers. The customer should know whether the protected service has a committed clean bandwidth, a burst policy, an emergency upgrade path and a clear behavior when traffic exceeds the agreed level.

What a customer should verify before relying on the service

The first verification is identity and scope. The customer should confirm whether its service will be carried on AS51464, AS43048, a customer AS, or Mitigator Cloud prefixes. It should confirm the exact prefixes, route objects, ROA status, upstreams, communities and normal AS paths. It should not accept an AS-set name as sufficient proof of the production path.

The second verification is traffic-steering mode. The customer should know whether protection is always-on or on-demand, whether DNS, BGP or provider prefixes are used, and who has authority to activate each method. If on-demand protection is used, the customer should run a controlled route or DNS exercise before production risk appears. If always-on protection is used, the customer should baseline latency, failure domains and maintenance behavior during normal traffic.

The third verification is site independence. The customer should ask how many independent scrubbing sites are in the specific service, where they are at a city or facility class level, whether they share upstream routers, storage, power, DNS, control services or support teams, and what part of the service still depends on one room. Public PeeringDB data does not answer this.

The fourth verification is clean-traffic return. For tunnels, ask how endpoints are protected and monitored, how keys are rotated, what bandwidth is committed and what happens when the tunnel is impaired. For reverse proxy, ask how source IPs are preserved, how TLS is handled, what logs are collected and what customer changes are required. For HTTP/HTTPS protection without decryption, ask which detection methods remain effective and which attack classes require logs or key material.

The fifth verification is maintenance and restore. Ask when platform backups are taken, whether restores are tested on the running version, how updates are staged, whether route announcements change during maintenance, how customer policy state is protected, and what incident logs survive a restore. The MITIGATOR documentation shows that version, storage and backup details matter; the hosted-service contract should translate those details into customer-facing commitments.

The sixth verification is support authority. Confirm the 24/7 path from customer alarm to engineer action. Ask who can add a countermeasure, change a BGP announcement, update a tunnel, inspect logs, talk to upstreams, roll back a software change and approve an emergency capacity increase. DDoS mitigation is not only a packet-processing product. It is a decision service under time pressure.

Evidence grade and bottom line

The evidence grade is Medium. The identity evidence is strong: RIPE organisation, maintainer, role, aut-num, route, route6 and RDAP records consistently connect iBank2.RU, MITIGATOR CLOUD LLC, AS51464 and AS43048. The network evidence is strong enough to show current routing: RIPEstat marks both ASNs announced on 12 July 2026, with AS51464 visible as a smaller IPv4-only network and AS43048 visible as the broader mitigation network with IPv4, IPv6 and many more observed neighbors.

The service evidence is also meaningful. Mitigator Cloud publicly describes 24/7 Russian DDoS protection for corporate clients, banks, IT companies and service providers, with concrete traffic-steering and clean-traffic delivery options. MITIGATOR product documentation explains the mechanics behind those claims: BGP signaling, always-on and on-demand modes, tunnels, clusters, fault-tolerant storage, backups, version support and update requirements.

The weak part is physical and operational verification. Public sources do not identify the facilities, racks, spare capacity, installed scrubber throughput, license allocation, restore tests, incident history, support escalation chart or customer portability terms. PeeringDB is sparse rather than reassuring. RPKI status for sampled prefixes is unknown. The public record supports a real dependency, but not a fully audited resilience claim.

For customers, the practical conclusion is simple. Treat IBANK2RU MITIGATOR CLOUD LLC as a live Russian protected-service capacity provider whose cloud promise depends on routers, scrubbing nodes, transit, support and repair windows. Buy the service only after verifying the exact route, room, tunnel, backup, support and capacity commitments for the workload that will depend on it.