Frequently Asked Questions

DDoS (Distributed Denial of Service) is when a large number of compromised devices send simultaneous traffic to the same target, making a service unreachable. The goal is not to steal data but to bring the service down; so even though your server appears to be running during an attack, your users cannot connect. Because the traffic comes from thousands of different addresses, blocking a single IP is no solution. Attacks arrive either as volume-based Layer 3/4 traffic or as a flood of requests generated at the application layer (Layer 7).

Protection is not built with a single device but in layers: anycast and CDN routing that distributes traffic, scrubbing centers that clean suspicious traffic before it reaches the target, WAF and rate-limiting rules running at the application layer, and IP- or country-based filters when needed. None of them is sufficient on its own; what matters is the combined capacity of these layers and how quickly they engage once an attack begins. inDDoS measures exactly these thresholds: it makes visible which rule engages at what intensity and where the protection breaks down.

Having purchased a protection solution does not mean it works. Device limits, misconfiguration or an attack that exceeds capacity only surfaces under real traffic. Testing makes the intensity at which your protection breaks, the time it takes to engage and the amount of downtime that reaches users measurable. This directs investment to the right layer and the right capacity, so no trial and error happens during an incident. The test report also lets you document your resilience in audits and customer contracts.

The symptoms are usually the same: response times suddenly lengthening or the service becoming completely unreachable, bandwidth and processor usage reaching saturation, the same request being repeated from many different addresses, traffic arriving from unexpected geographies. If any of these signs is observed, the traffic source and destination ports should be examined first, and the logs of the protection layers compared with the period before the attack. Reproducing the same scenario under controlled conditions conclusively shows whether the situation is an attack and whether the protection has engaged.

DDoS tests can only be carried out legally with the written permission of the owner or authorized administrator of the target system. Any test performed without permission falls within the scope of a cybercrime. inDDoS enforces this rule technically as well: a test cannot be defined until the target assets are proven to belong to you, and starting the test requires separate approval from both the operator and your organization. The entire process is carried out under a signed authorization document and an NDA.

For the test to be meaningful, it is usually performed in a live environment, in a controlled manner. The starting intensity is kept low and increased gradually. Because the Monitor component measures the target's response time in real time, the approach to the breaking point is visible live. The test can be ended with a single touch using the emergency stop button; in addition, every vector shuts down automatically at the end of its defined duration. For business-critical systems, a maintenance window or a mirror environment may be preferred.

It depends on the number of bots. With 50 bots you can reach 3 Gbps and 500,000 concurrent L7 users; with 600 bots, up to 36 Gbps and 6,000,000 concurrent users. The platform can scale up to 4,000 bots; capacity at that level is planned on a request basis. Bandwidth per bot ranges from 1–60 Mbps depending on the attack type.

Yes. Specific regions can be included in or excluded from the bot distribution. This way, you can test whether your geographic filtering rules, CDN routing and regional scrubbing configuration actually work.

Yes. Real attackers do not use a single vector; they combine different vectors to increase the impact and make mitigation harder. inDDoS can run multiple vectors simultaneously to mimic this behavior. For example, SYN Flood and HTTP/S GET Flood can be run together to stress both the network and the application layer at the same time.

The report is generated automatically as soon as the test ends. It includes graphical verification that the test was carried out, the operator identity, the bandwidth used, PPS values and the target's response time. It can be converted to PDF, archived and shared. Nesil Teknoloji also interprets this raw data, adding a prioritized findings matrix and a remediation roadmap.

The target's response time before the test is compared with its response time during the test to produce an empirical value on a 1–10 range; the higher the value, the greater the resilience. When tests are repeated, these values are compared and the effect of the fine-tuning made to the defense mechanisms can be tracked as a trend.

Yes. Tests can be initiated directly by your organization or by an authorized and trained operator. In the platform license model, portal access is assigned to your organization and your team plans the tests itself after training. In the managed service model, the Nesil Teknoloji team takes over the entire operation.

Yes. When the bot level falls short of your needs, you can move up to a higher package. You only need to contact our sales team for a change to the license period and scope.

Yes. After the report is delivered, we make a presentation with your technical team, answer your questions about the report for 30 days and provide consulting during the remediation process. We offer a discounted retest option to measure whether the improvements actually work.

The active execution of a test typically takes from a few minutes to a couple of hours per scenario. The duration is driven by the number of bots, the chosen vector combination and the ramp-up plan, and every vector shuts down automatically at the end of its defined window. The end-to-end project (pre-assessment, authorization, execution and reporting) usually spans a few business days.

Not necessarily; the test is run in a controlled way to find the breaking threshold without forcing an outage. Intensity starts low and increases gradually, and because the Monitor component measures the target's response time in real time, you see the breaking point being approached live. The emergency stop ends the test with one touch and every vector times out automatically. For business-critical systems, a maintenance window or mirror environment can be used.

Yes; systems behind these providers can be tested, and that is precisely how you verify whether the provider's DDoS mitigation layer actually engages. Real attack traffic reaches the cloud or CDN edge, so the behavior of scrubbing, rate limiting and WAF rules is observed directly. However, most of these providers require prior notification or authorization for load and DDoS testing, so we confirm the provider's testing policy with you before the test.

In most cases, yes; many providers such as AWS and Cloudflare require advance notification or written authorization for simulated attack or load testing. While defining the test scope, we identify which provider expects which notice and complete the required filings on time. This step keeps the test compliant with both your contract and the provider's rules.

A load test measures how a system performs under legitimate, expected user traffic, whereas a DDoS test simulates malicious attack traffic designed to exhaust resources and defeat protection. inDDoS validates not just capacity but whether the scrubbing, WAF, rate-limiting and filtering layers actually engage under attack. The output is not a performance curve but a DDoS Resilience Score from 1 to 10.

It is recommended at least once a year, and in addition whenever there is a significant change in infrastructure, protection configuration or provider, and before high-traffic events such as campaigns, launches, elections or peak seasons. A retest after any remediation is important to measure the change in the resilience score. With Autopilot, tests can be scheduled periodically and run automatically without waiting for an operator.

The Turkish Standards Institution classifies the penetration testing firms it audits under TS 13638/T2 according to their competence; Class A is the highest tier. Nesil Teknoloji holds this certificate under number TSE-STF-065, valid until 03.04.2027.

Under Regulation No. 31881, firms must hold an authorization issued by the Republic of Türkiye Ministry of Industry and Technology to take part in public-sector penetration testing tenders. Nesil Teknoloji’s penetration testing authorization is STB03-250; the company also holds the public IT authorization STB01-3242.

Yes. Both certificates are issued by Sigmacert Global (SQR) under IAF and TÜRKAK accreditation and can be checked on the document verification screen at asist.turkak.org.tr.

CREST (Council of Registered Ethical Security Testers) is an accreditation body regarded as the international reference in penetration testing and ethical security testing. Nesil Teknoloji holds Member Company status within CREST.

Our technical team includes 9 TSE-certified penetration testing specialists: 2 senior, 3 certified and 4 registered. The team also includes experts holding OSCP/OSCP+, CEH, GPEN, CISM, CISA, CISSP and CIPP/E certifications and the CMB Information Systems Independent Audit License.