DDoS attacks and website protection: a great guide for business and VPS

07.09.202620 min read

To protect your site from DDoS, you need to stop malicious traffic before it exhausts the channel, connections, or application resources. This is usually a combination of external filtering, secure DNS, a closed application server, and restrictions on expensive operations. The settings depend on what the company is running: a WordPress site, an online store, an API, a personal account or its own network.

Such an architecture can also be organized on a separate VPS. An option with a lower operational load: place the site behind a cloud anti-DDoS proxy. An option with more control: move Nginx to a separate protected VPS and connect it to the application server via a private network or tunnel. In both cases, volumetric attacks must be cleared by the provider before the external channel fills.

Below we look at the main classes of attacks, Russian and foreign services, connection schemes, Nginx configuration and actions during an incident. Supplier capabilities were verified against official materials in September 2026; the price and coverage of a specific tariff must be confirmed upon connection.

What happens during a DDoS attack

DDoS, distributed denial of service, means distributed denial of service: many sources create a load due to which a legitimate user cannot use the service. Sources can be infected devices, servers, proxies, and third-party services that reflect traffic.

Overload has several possible points:

the external channel stops passing useful packets;
network equipment spends resources processing packets or connections;
the web server is holding too many pending requests;
the application runs expensive computations;
the database is limited by locks, the processor, or the connection pool;
external SMS, payment or AI service reaches its quota.

Load is measured in different quantities. Bit/s shows the volume of traffic, packets/s - packet processing load, RPS - requests per second, and the number of connections and active requests - occupied resources. A small stream of heavy requests is sometimes more dangerous than a large volume of cached pages.

B OWASP DoS methodology The network, connection status, and application are considered separately. Each surface requires its own measures; The failure of one component can make the entire user chain inaccessible.

Types of DDoS attacks and suitable protection

It is impossible to list all possible implementations of attacks: methods are combined, and new vulnerabilities appear in the software. For design, it is enough to cover the main classes and check the specific protocols of the project. The designations L3/L4/L7 in commercial descriptions are often used in aggregate: for example, UDP refers to L4, although large-scale UDP flooding is usually sold as a problem for L3/L4 network protection.

Class and examples	What resource is being consumed?	Where should protection work?
Volume UDP/ICMP flood	Bandwidth, network throughput per packet	Hoster network, operator network or cleaning center
Reflection/amplification: DNS, NTP, SSDP, CLDAP, memcached	The victim's channel is filled with responses from third-party services	Upstream filtering; shutting down our own open UDP services
SYN flood	TCP connection establishment queues	Network anti-DDoS, SYN proxy/cookies based on topology
ACK/RST flood, anomalous and fragmented packets	Batch processing and network devices	ISP, router and firewall filters
Connection/state exhaustion	NAT/firewall tables, memory and connections	Network filter, proxy, limits and timeouts
TLS handshake flood	CPU and TLS setup resources	Secure TLS proxy, control of new connections
HTTP GET/POST flood	Workers, CPU, database, outgoing traffic	L7 anti-DDoS, anti-bot, cache, route limits
Cache-busting and random URLs	Cache misses and requests to origin	Cache key policy, normalization and dynamics restrictions
Slow headers/body/read	Long busy connections and buffers	Timeouts, buffering and resource control on the proxy
HTTP/2 stream/reset abuse	Resources for processing threads within a connection	Corrected protocol implementation and edge filtering
Expensive APIs, GraphQL, search, export	CPU, memory, database and queues	Client quotas, query complexity, concurrency limits
WebSocket flood	Connections, memory and message processing	Session limits, message frequencies and authentication
DNS query flood, random subdomains	Authoritative DNS servers	Distributed Secure DNS
Multi-vector attack	Multiple resources simultaneously or sequentially	Consistent network, DNS, HTTP, and application security

What is reflection and amplification

When reflected, third-party servers send responses to the victim's address. In amplification scenarios, the size of the response is larger than the original request. This explains why blocking several addresses in the site panel usually does not stop the attack: the sources change, and the channel is already busy.

The public VPS should also not become a reflection participant. Don't leave open recursive DNS, memcached, or UDP administrative services available to the entire Internet. The composition of open ports is checked separately from the site settings.

Why are attacks on HTTP/2 and HTTP/3 dangerous?

In HTTP/2, a single TCP connection serves multiple request streams. Therefore, the TCP connection limit does not describe the entire application load. Historical examples are Rapid Reset and MadeYouReset. B Cloudflare posts about MadeYouReset We are talking about certain unpatched implementations of HTTP/2, and not about the vulnerability of any site with this protocol.

Check your proxy and HTTP libraries for updates, stream processing policies, and your provider's security. For HTTP/3, separately consider QUIC/UDP and protocol support by the selected service. Disabling a protocol may be a temporary measure for a specific advisory, but it does not replace the overall security architecture.

Attacks on business logic and cost

Bulk registrations, SMS sending, PDF generation, image processing and LLM queries can exhaust resources or budget. Not every such case is a DDoS, but availability protection must take these dependencies into account.

Solution: account and organization limits, maximum transaction cost, sensitive action confirmation, limited queues and external API budgets. An indefinite queue only postpones the refusal to a later time.

How to distinguish an attack from an influx of visitors

No single sign proves DDoS. Legitimate advertising also creates a burst from different networks, and attackers are able to imitate user sessions.

Observation	What to check
Traffic has increased sharply	Advertising launches, mailings, referrals, geography and share of successful actions
One route has become very popular	Client error, endless retries, integration, cacheability and request cost
Channel is full, CPU is free	Hoster telemetry: bits/s, packets/s, protocols and losses
Grow 502/504 with a small stripe	Application workers, database, locks and external dependencies
Many requests from one IP	Enterprise NAT, proxy/CDN, real client and log correctness
Requests pass WAF, but the site is unavailable	Expensive legitimate business logic and direct access to origin

Start with the time of symptom onset. Map it to releases, rule changes, campaigns, and infrastructure errors. To conclude, use application logs and network data at the same time: the web server will not see packets that did not reach it.

What layers should you use to protect your site?

User -> protected DNS -> external anti-DDoS / CDN
     -> WAF + anti-bot + rate limits
     -> origin: Nginx / application
     -> cache, database, queues and external APIs

Anti-DDoS L3/L4 clears the network flow to your channel and equipment. CDN reduces server calls due to cache and distributed delivery. WAF checks HTTP requests for signs of exploitation of vulnerabilities. Anti-bot evaluates automation and suspicious behavior. Rate limiter sets the permissible frequency. These features may be sold together but enabled by different settings.

If a VPS channel conditionally supports 1 Gbps, and more has reached its input, local packet drop will not free this channel. Additional memory and processor will not increase its capacity either. Defense needs to be moved higher up the route.

There are also restrictions on other layers: WAF is not required to block expensive but correct search; CDN does not cache your personal account without special rules; CAPTCHA will break the server API. Every scenario needs a suitable policy.

How to connect anti-DDoS

Protection via DNS and reverse proxy

The domain points to the external security network. It accepts HTTP/HTTPS, analyzes traffic and forwards requests to origin - the application's original server. The scheme is suitable for most sites and HTTP APIs, including those hosted on a VPS from another hoster.

Check TLS on both legs, valid ports, WebSockets, file uploads, and timeouts. Only connected domains and protocols are protected. VPN, mail and other services on the same IP require a separate solution.

Network scrubbing via BGP and tunnel

For a proprietary network, traffic is routed to a scrubbing center, for example via a BGP address space advertisement, and the scrubbed stream is returned via GRE/IPIP or a direct connection. This scheme allows you to protect not only the web.

For a typical single VPS, the native BGP scheme is often redundant. It’s easier to get a protected address from your provider or use their cleared traffic delivery service. Before connecting, they negotiate routing, MTU, return route and protocol support.

Cloud and hybrid protection

In the cloud, filtering is tied to the balancer, public IP, WAF, and platform logs. The hybrid option combines external network cleaning, application filtering and local restrictions.

When mode always-on traffic passes through the protection constantly. When on-demand detection and switching required; Degradation is possible before these actions are completed. Compare the cost with the acceptable downtime.

Own equipment and software filters

Hardware complexes, nftables, XDP/eBPF and local filters are useful within the limits of network and server bandwidth. For large networks, ACLs, BGP FlowSpec and other operator mechanisms are used. RTBH, or blackhole, completely cuts off traffic to an address: this is a way to limit damage to the infrastructure, in which the service itself becomes unavailable.

Reservations and automatic scaling increase margin, but are useful when combined with filtering and cost containment. Otherwise, the attack could scale up the infrastructure bill.

Russian companies and protection services

Below are options for different architectures. The tables do not rank quality: the public description of a product does not prove its performance against a specific attack. Selection criteria - protocols, connection, operation and contractual restrictions.

Service	Which scenario to consider	What to clarify
Yandex Cloud Smart Web Security	Web and API, cloud infrastructure or external origin via domain protection	Preview status for external domain, cost of requests, proxies and logs
CURATOR	Web and network protection; individual products anti-DDoS, WAF, CDN, anti-bot and DNS	What combination is included; DNS/BGP connection and emergency support
StormWall	Web protection or network cleaning for your own infrastructure	The network product and WAF are purchased for the required scenario; traffic delivery method
Kaspersky DDoS Protection	Networks, data centers and corporate services	Monitoring, enabling cleaning, protocols, own team roles
Selectel	The project is already running with this provider	Basic L3/L4 protection does not include full L7 filtering; expansion conditions and RTBH

For Russia, check delays from the desired regions, the legal entity in the contract, the location of log processing and the access procedure for engineers. If a project has specific placement or certification requirements, the specific service and architecture are verified, not just brand recognition.

Foreign companies and protection services

Service	Which scenario to consider	What to clarify
Cloudflare	Protection of proxied sites and APIs; There are separate products for the network	Plan features, access to settings, origin support and protection
AWS Shield	AWS Infrastructure and Supported Resources	Standard/Advanced differences; AWS WAF is used for application rules
Google Cloud Armor	Applications behind supported Google Cloud balancers	Resource type, HTTP policy, and advanced feature availability
Azure DDoS Protection	Public IP and Azure Network	Resources covered; for L7 you need a WAF separately
Akamai Prolexic	Network protection of your own or hybrid infrastructure	Connectivity and individual products for web applications/APIs
Fastly DDoS Protection	Applications and APIs served through Fastly	Connection conditions, operating mode and tariffs

The foreign provider is separately checked for the possibility of concluding a contract and payment, actual accessibility to the audience, data requirements and the ability to receive support. Connecting a domain to a web CDN does not mean protecting all public server ports.

How to compare offers and prices

In your request to the vendor, include domains, IP, protocols, geography, typical and peak RPS/bps, momentum share, file sizes, and critical integrations. If there are no measurements, start with hoster statistics and access logs.

Compare offers under the same conditions:

Continuous protection or switching after detection.
Coverage L3/L4/L7, DNS, API and WebSocket.
Limits on cleared traffic, requests and proxy resources.
Payment for attack traffic, WAF requests, logs and outgoing bandwidth.
TLS management, real IP transfer and proxy authentication to origin.
Engineer reaction time and procedure for changing rules.
Access to events, API and false positive log.
SLA, exceptions, blackhole and emergency connection procedures.

For your own circuit, the cost consists of a VPS proxy, network protection, traffic, monitoring and engineer work. For the cloud scheme, rules for charging requests, balancer and WAF are added. It is impossible to name the exact price without these introductory information.

How to protect one VPS behind a cloud proxy

This is a suitable starting scheme for a corporate website, WordPress and a small store. The application remains on its server, input traffic passes through an external service.

1. Save current settings

Save the DNS zone, Nginx/firewall configuration, TLS settings and list of integrations. Prepare the hoster console and backup administrative access. Find out what the hoster does when an IP is attacked: clears the stream, limits the bandwidth, or turns on a blackhole.

2. Connect the domain to the protection service

Add origin and certificate, configure HTTPS to origin server with certificate verification. Check the domain and www variant if used. It makes sense to lower the TTL in advance: it does not cancel the existing DNS cache.

Before switching, check the login, forms, payment, webhook, files and API through the test mode provided by the provider. After checking, change the DNS and make sure that requests actually pass through the protection.

3. Close direct access to origin

On the firewall, allow the desired web port only from official proxy networks. IPv6 requires the same policy: an open AAAA record can bypass protection. Please note separate health-check addresses if they are provided for in the documentation.

Remove technical subdomains that reveal IP. If the address is already known, discuss changing it or disabling the public address. A closed port does not save a known IP from saturating the external channel, so origin's network protection also matters.

Shared CDNs may have other clients. Where possible, supplement the IP list with authentication of your proxy to origin: mTLS or the mechanism provided by the provider. The secret service header only makes sense if the proxy overwrites the input value and origin checks it.

4. Separate management and service ports

Allow SSH from the administrative network/VPN. Place the database, Redis and metrics on a loopback or private interface. After changing the firewall, open a second administrative test session before closing the first one.

Don't forget to update your certificates. Once port 80 is closed, ACME HTTP inspection may stop working; Select a supported check route or DNS challenge in advance.

Is it possible to do protection on a separate VPS proxy?

Yes. This scheme is suitable when you need your own Nginx, your own rules, multiple origins, or an application-independent input server.

Internet -> provider L3/L4 traffic scrubbing
         -> VPS A: HTTPS proxy, filtering, rate limits
         -> private network / WireGuard
         -> VPS B: application and data

Website DNS -> public IP address of VPS A
Application on VPS B -> private interface only

VPS A provider must support the expected network security. A regular cheap VPS with Nginx becomes a new congestion point. Complex HTTP flooding will also require a managed L7 service or your own application filtering with constant support.

Private channel between servers

If the servers are on different networks, you can use WireGuard. Address plan example: VPS A receives 10.77.0.1, VPS B - 10.77.0.2. Application on B is listening 10.77.0.2:8080, and the firewall allows this port only from 10.77.0.1 on the tunnel interface.

Implementation sequence:

Select a private subnet that does not overlap with existing routes.
Create separate keys on each server and exchange only public keys.
Specify narrow AllowedIPs: the address of the second node, without redirecting the entire Internet to the tunnel.
Raise the channel and check the application at a private address.
Set up proxying on VPS A and then close the public application port on B.
Check node restart, MTU, connection after downtime and origin availability monitoring.

The location of the public endpoint of the tunnel is agreed upon with the firewall. If B needs to be hidden and is behind a NAT, B can communicate with A; The need for keepalive depends on the network. The very fact of using a VPN does not hide an already known public IP and does not protect its channel from flooding.

What to provide for reliability

One VPS A remains the only point of failure. For stricter availability, a second proxy and a proven switching mechanism are needed; two A-records by themselves do not guarantee correct failover. Monitor the health of the application, free log disk, updates and resource reserves of the proxy itself.

Your stack may include Nginx/HAProxy, ModSecurity with OWASP Core Rule Set, Coraza with a suitable connector or CrowdSec. Each tool requires compatibility checks and rules. Their installation does not automatically create a distributed cleaning network. For a project with a small team, managed L7 protection often reduces the operational burden.

Example of Nginx restrictions for an application

Below is a snippet for Nginx, which proxies requests to the application. It is added to an existing configuration with working TLS. Paths, limits and origin are adapted to the project; Surveillance without blocking works first.

Limit zones and application address

This block is placed inside an existing http { ... }, out server:

limit_req_zone $binary_remote_addr zone=web_ip:10m rate=10r/s;
limit_req_zone $binary_remote_addr zone=login_ip:10m rate=1r/s;
limit_conn_zone $binary_remote_addr zone=active_ip:10m;

upstream protected_app {
    server 10.77.0.2:8080;
}

log_format protection '$remote_addr $request_method $uri $status '
                      'rt=$request_time urt=$upstream_response_time '
                      'req=$limit_req_status conn=$limit_conn_status';

Address 10.77.0.2:8080 corresponds to a scheme with two VPS and an encrypted tunnel. For an application on the same machine, its local address is used, for example 127.0.0.1:3000.

Virtual Host Limitations

The following fragment is placed inside server { ... } the selected site where the domain has already been set, listen and certificates. Existing location needs to be combined with the rules, not duplicated:

access_log logs/protection.log protection;

limit_req_status 429;
limit_conn_status 429;
limit_req_dry_run on;
limit_conn_dry_run on;
limit_conn active_ip 30;

client_header_timeout 10s;
client_body_timeout 15s;
keepalive_timeout 30s;
client_max_body_size 10m;

proxy_connect_timeout 3s;
proxy_read_timeout 30s;
proxy_request_buffering on;

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;

location / {
    limit_req zone=web_ip burst=30 nodelay;
    proxy_pass http://protected_app;
}

location = /api/login {
    limit_req zone=login_ip burst=5 nodelay;
    proxy_pass http://protected_app;
}

Here the proxy intentionally rewrites the IP passed to the application after checking it. The application should only trust this proxy. The protocol header is appropriate for the case where HTTPS is terminated on a given Nginx; with a different TLS chain, the original scheme must be correctly transmitted.

Frequency and burst the example illustrates the mechanics limit_req. They are selected according to normal load and permissible peak. Static files behind the cache, login and heavy API require different budgets. A large office and mobile operator can send many people from one IP; for authorized customers, additional quotas per account or token are more useful.

limit_conn takes into account requests after reading the header, and in HTTP/2 and HTTP/3 active threads are counted separately. This limitation does not replace protection against incomplete headers and network attacks. The body read timeout specifies the data waiting interval, not the general download deadline. Long downloads, streaming and WebSocket require separate settings.

Real IP behind cloud CDN

If there is also a CDN in front of Nginx, without configuring real IP, the limit will be applied to CDN addresses. First close origin on the firewall and configure realip module according to the provider's documentation: trusted CIDR, its header and proxy order.

Do not indicate credibility 0.0.0.0/0 or ::/0. When logging directly from the Internet, an arbitrary client can spoof X-Forwarded-For. In your own VPS A, which accepts users directly, rewriting the IP from such a header is not required at all.

Checking and enabling the lock

Before use, save the previous configuration, then run:

sudo nginx -t
sudo systemctl reload nginx

Reboot is allowed only after successful nginx -t. At the dry run stage, look for solutions in the log REJECTED_DRY_RUN and DELAYED_DRY_RUN, compare them with legitimate sessions. After calibration, switch the desired limit_req_dry_run or limit_conn_dry_run in off and check the configuration again.

Make sure the normal request passes, the restricted one gets a 429, and the login and API remain functional. In case of false positives, return the corresponding rule to dry run and apply the tested configuration. Don't disable all protection for one route.

Yandex Cloud Smart Web Security for external site

Yandex SWS can be connected to supported cloud resources or to an external application through domain protection. As of the audit date September 7, 2026 protection of external domains marked as Preview. For critical production, agree on this status, restrictions and support conditions.

By official management the order is:

Create a proxy and domain, specify origin and certificate.
Direct DNS to the proxy and check the availability of origin.
Connect a security profile using a template.
Start with logging; the basic allow rule must allow observed traffic.
For the API, select the “API Protection” rule, which does not send clients to CAPTCHA.
Configure Advanced Rate Limiter and, if necessary, WAF.
Close direct access to origin and check integrations.
Enable blocking after checking events.

In this implementation, the WAF rule already contains L7 DDoS protection: duplicate Smart Protection for the same traffic is not necessary. This is a feature of the product. Before connecting, calculate the cost of requests, proxies, logs and the balancer used; surveillance mode may also be charged.

Protecting WordPress, Store and Public API

WordPress and other CMS

For anonymous visitors, configure caching of public pages. Eliminate personal account, cart and personal replies: the shared cache should not reveal other people's data. Separately check the search, filters, statistics and file generation plugins.

Limit login and password recovery, keep an eye on CMS and plugin updates. XML-RPC is disabled only after verifying that existing integrations do not need it. admin-ajax.php can serve front-end functions: rules are selected based on actions, rather than blocking the entire path.

WAF alone does not fix a heavy SQL query. When a typical workload is already exhausting resources, it is useful to understand where a business needs a high-load architecture, and measure the bottleneck.

API and mobile applications

Use authentication, client and method quotas, login size and concurrency limits. Check the webhook signature before accessing expensive dependencies. Do not acknowledge a task until it is securely recorded; otherwise, attempting to offload the endpoint will result in data loss.

Set limits on pagination, GraphQL depth/complexity, and reporting. Limit queues and repetitions; use backoff and idempotency. CAPTCHA for machine clients is usually unusable, so browser pages and APIs are separated by policies.

Features you can temporarily disable

For a store, it is more critical to save browsing, cart and checkout than recommendations and complex searches. For a B2B system, receiving requests may be more important than synchronously uploading a report. These priorities turn into degradation mode and individual limits.

To evaluate such a chain, you can start with analysis of backend and high-load systems: The application, data, integrations, and external security must withstand a consistent scenario together.

How to monitor security and not lose clients

See network, latency, response codes and resource constraints simultaneously. Minimum for the dashboard: bit/s and packets/s from the host, RPS by routes, new connections, cache hit ratio, origin time, application queue, database and filtering solutions.

Separately track applications, authorizations and payments. A drop in business metrics after enabling WAF may indicate a false block even with a green availability graph. Check legitimate robots in the manner provided by the provider; User-Agent alone is not enough for trust.

Limit the period and volume of log storage, eliminate passwords, tokens and unnecessary personal data. During an attack, an uncontrolled access log can fill the disk. Maintain representative events and counters needed for investigation.

What to do if an attack is already underway

Record the onset, symptoms and critical services. Check releases and common causes of failure.
Open an incident with the hoster/anti-DDoS provider: addresses, protocols, schedules and acceptable operating modes.
Enable a pre-prepared enhanced filtering profile.
Reduce the load on origin: cache, limiting expensive routes, disabling non-essential functions.
Check legitimate sessions and integrations after each change.
Save events, time and owner of each change; keep status for clients outside the attacked circuit.
After stabilization, return the modes step by step and disassemble the first point of failure.

Changing IP, geo-blocking and disabling the protocol only makes sense if there is a clear reason. During an attack, DNS switching will not be instantaneous due to the cache. Access to the registrar, DNS and support should work regardless of the site being attacked.

If origin is exposed, find the leak channel before the next address change. After an incident, update rules, monitoring and regulations. This can be included in technical support of the site with designated persons responsible for the application, server and external providers.

How to check readiness before an attack

Carry out only agreed inspections of your own infrastructure with limits and stopping criteria. A typical load test shows the application's limit; confirmation of the quality of external anti-DDoS requires separate agreement with the supplier.

Acceptance plan:

the domain is protected, and direct access to origin is closed via IPv4 and IPv6;
the application correctly sees the real IP, HTTPS scheme and domain;
forms, login, API, payments, files and certificates work;
normal requests pass, the test exceeding the specified quota receives the expected status;
administrative console, logs and emergency contacts are available;
private channel checked, proxy restarted and rules rolled back;
monitoring shows not only blocking, but also successful user actions.

It is convenient to prepare scenarios and metrics according to load testing checklist. Performance margin and attack protection are tested separately, although they use part of the overall measurements.

FAQ

Is it possible to stop DDoS for free?

Free tools provide useful local restrictions, cache and monitoring. Some services offer basic protection as part of their tariff. But network capacity, tracking, and advanced filtering have limitations. Opportunities need to be assessed for a specific site and channel.

Will Fail2ban or CrowdSec help?

They can reduce certain types of abuse and duplicate requests, especially when the IP is transmitted correctly. Their capabilities depend on the connected scripts and the blocking mechanism. The local solution does not free up the already saturated external channel.

Is it possible to put a second VPS in front of the main server?

Yes: a secure VPS accepts HTTPS, filters requests and forwards them to the application over a private network or tunnel. Public web access is closed on the main server. An external VPS must have network protection and sufficient resources; For complex L7 attacks, additional measures are required.

Will WireGuard protect against DDoS?

WireGuard protects the connection between nodes and allows you to avoid publishing the application port. It is not a traffic cleaning network. The public address and channel of the VPN node still need to be protected by the provider.

If the origin port is closed, why protect its IP?

The firewall discards packets after they reach its filtering point. An attack on a known address can still fill the channel earlier. The solution is cleaning up the network or eliminating the public route to origin, if the architecture allows it.

Why did the site stop working after enabling limits?

Possible problems include an incorrect real IP, a shared NAT quota that is too strict, a rule conflict, or a service route limitation. Check the decision log, return the problematic rule to watch mode, and retry the custom script.

Is WAF enough for an online store?

Network protection, caching, bot control, and search, cart, login, and API restrictions are also needed. WAF may miss a valid but too expensive request. Personal replies and the cart cannot be placed in the general cache.

Is it possible to protect an external VPS via Yandex Cloud?

SWS provides protection for external applications via domain and proxy. As of September 7, 2026, the documentation marks this option as Preview. Before implementation, check the status, restrictions and support, then connect the DNS, certificate, profile and origin restrictions.

Is it necessary to hide a site from search robots during an attack?

Blocking robots completely should not be the standard measure. Configure checking for known robots and control access to public pages, robots.txt and sitemap. A spoofed User-Agent provides no reason to bypass filtering.

Will increasing server power help?

It provides headroom where CPU, memory, or application processing are limited. When the channel is full, you need to filter the traffic from the provider. Before scaling, establish which resource runs out first and limit the overhead.