{"id":3890,"date":"2026-01-01T15:38:18","date_gmt":"2026-01-01T12:38:18","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/ddos-protection-strategies-for-small-and-medium-websites\/"},"modified":"2026-01-01T15:38:18","modified_gmt":"2026-01-01T12:38:18","slug":"ddos-protection-strategies-for-small-and-medium-websites","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/ddos-protection-strategies-for-small-and-medium-websites\/","title":{"rendered":"DDoS Protection Strategies for Small and Medium Websites"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>Distributed denial-of-service (DDoS) attacks are no longer a problem only for banks and global platforms. In capacity planning calls with our own customers at dchost.com, we routinely see small WordPress sites, local e\u2011commerce stores and SaaS side\u2011projects hit by automated floods of traffic. The goal is simple: exhaust your bandwidth, CPU, RAM or connection limits so real visitors cannot load your site. The good news is that you do not need an enterprise security budget to defend yourself. With a well\u2011designed mix of Cloudflare, smart rate limiting and sensible server tuning, small and medium websites can withstand a surprising amount of malicious traffic.<\/p>\n<p>In this article, we\u2019ll walk through a practical, layered DDoS protection strategy you can actually deploy. We\u2019ll focus on three main pillars: using Cloudflare intelligently, designing effective rate limiting at the edge and on your origin, and hardening your server so it behaves predictably under stress. All examples and recommendations are written from the perspective of how we protect real customer workloads on shared hosting, <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a>, <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a>s and colocation at dchost.com.<\/p>\n<div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#1_What_DDoS_Really_Looks_Like_for_Small_and_Medium_Sites\"><span class=\"toc_number toc_depth_1\">1<\/span> 1. What DDoS Really Looks Like for Small and Medium Sites<\/a><ul><li><a href=\"#11_Types_of_DDoS_attacks_youre_likely_to_see\"><span class=\"toc_number toc_depth_2\">1.1<\/span> 1.1 Types of DDoS attacks you\u2019re likely to see<\/a><\/li><li><a href=\"#12_Constraints_specific_to_small_and_medium_websites\"><span class=\"toc_number toc_depth_2\">1.2<\/span> 1.2 Constraints specific to small and medium websites<\/a><\/li><\/ul><\/li><li><a href=\"#2_A_Layered_DDoS_Defense_Model_for_RealWorld_Sites\"><span class=\"toc_number toc_depth_1\">2<\/span> 2. A Layered DDoS Defense Model for Real\u2011World Sites<\/a><\/li><li><a href=\"#3_Using_Cloudflare_Effectively_for_DDoS_Protection\"><span class=\"toc_number toc_depth_1\">3<\/span> 3. Using Cloudflare Effectively for DDoS Protection<\/a><ul><li><a href=\"#31_Put_your_site_fully_behind_Cloudflare\"><span class=\"toc_number toc_depth_2\">3.1<\/span> 3.1 Put your site fully behind Cloudflare<\/a><\/li><li><a href=\"#32_Enable_and_tune_Cloudflare_WAF\"><span class=\"toc_number toc_depth_2\">3.2<\/span> 3.2 Enable and tune Cloudflare WAF<\/a><\/li><li><a href=\"#33_Cloudflare_rate_limiting_for_expensive_endpoints\"><span class=\"toc_number toc_depth_2\">3.3<\/span> 3.3 Cloudflare rate limiting for expensive endpoints<\/a><\/li><li><a href=\"#34_Bot_management_and_challenge_modes\"><span class=\"toc_number toc_depth_2\">3.4<\/span> 3.4 Bot management and \u201cchallenge\u201d modes<\/a><\/li><li><a href=\"#35_Protect_the_origin_with_Authenticated_Origin_Pulls_and_mTLS\"><span class=\"toc_number toc_depth_2\">3.5<\/span> 3.5 Protect the origin with Authenticated Origin Pulls and mTLS<\/a><\/li><\/ul><\/li><li><a href=\"#4_Designing_Smart_Rate_Limiting_at_Edge_and_Origin\"><span class=\"toc_number toc_depth_1\">4<\/span> 4. Designing Smart Rate Limiting at Edge and Origin<\/a><ul><li><a href=\"#41_Edge_rate_limiting_vs_origin_rate_limiting\"><span class=\"toc_number toc_depth_2\">4.1<\/span> 4.1 Edge rate limiting vs origin rate limiting<\/a><\/li><li><a href=\"#42_Web_server_level_rate_limiting_Nginx_Apache_LiteSpeed\"><span class=\"toc_number toc_depth_2\">4.2<\/span> 4.2 Web server level rate limiting (Nginx, Apache, LiteSpeed)<\/a><\/li><li><a href=\"#43_Application-level_rate_limiting\"><span class=\"toc_number toc_depth_2\">4.3<\/span> 4.3 Application-level rate limiting<\/a><\/li><li><a href=\"#44_Avoiding_false_positives_when_limiting_rates\"><span class=\"toc_number toc_depth_2\">4.4<\/span> 4.4 Avoiding false positives when limiting rates<\/a><\/li><\/ul><\/li><li><a href=\"#5_Server-Side_Hardening_and_Tuning_Against_DDoS\"><span class=\"toc_number toc_depth_1\">5<\/span> 5. Server-Side Hardening and Tuning Against DDoS<\/a><ul><li><a href=\"#51_Kernel_and_network_stack_tuning\"><span class=\"toc_number toc_depth_2\">5.1<\/span> 5.1 Kernel and network stack tuning<\/a><\/li><li><a href=\"#52_Firewall_configuration_and_basic_DDoS_protections\"><span class=\"toc_number toc_depth_2\">5.2<\/span> 5.2 Firewall configuration and basic DDoS protections<\/a><\/li><li><a href=\"#53_Web_server_and_PHP-FPM_tuning\"><span class=\"toc_number toc_depth_2\">5.3<\/span> 5.3 Web server and PHP-FPM tuning<\/a><\/li><li><a href=\"#54_Logging_and_retention_during_attacks\"><span class=\"toc_number toc_depth_2\">5.4<\/span> 5.4 Logging and retention during attacks<\/a><\/li><\/ul><\/li><li><a href=\"#6_Monitoring_Detection_and_an_Incident_Playbook\"><span class=\"toc_number toc_depth_1\">6<\/span> 6. Monitoring, Detection and an Incident Playbook<\/a><ul><li><a href=\"#61_Metrics_to_watch\"><span class=\"toc_number toc_depth_2\">6.1<\/span> 6.1 Metrics to watch<\/a><\/li><li><a href=\"#62_Basic_DDoS_incident_playbook\"><span class=\"toc_number toc_depth_2\">6.2<\/span> 6.2 Basic DDoS incident playbook<\/a><\/li><\/ul><\/li><li><a href=\"#7_Hosting_Architecture_Choices_and_How_dchostcom_Can_Help\"><span class=\"toc_number toc_depth_1\">7<\/span> 7. Hosting Architecture Choices and How dchost.com Can Help<\/a><\/li><\/ul><\/div>\n<h2><span id=\"1_What_DDoS_Really_Looks_Like_for_Small_and_Medium_Sites\">1. What DDoS Really Looks Like for Small and Medium Sites<\/span><\/h2>\n<h3><span id=\"11_Types_of_DDoS_attacks_youre_likely_to_see\">1.1 Types of DDoS attacks you\u2019re likely to see<\/span><\/h3>\n<p>DDoS is a broad term. In practice, small and medium websites usually face three main categories:<\/p>\n<ul>\n<li><strong>Volumetric attacks<\/strong>: The attacker sends huge amounts of traffic (Gbps or more) to saturate your network connection or your provider\u2019s upstream capacity.<\/li>\n<li><strong>Protocol\/transport attacks<\/strong>: SYN floods, UDP floods or malformed packets that consume resources in your TCP\/IP stack, firewall or load balancer.<\/li>\n<li><strong>Application\u2011layer attacks (Layer 7)<\/strong>: Seemingly legitimate HTTP(S) requests to expensive endpoints (search, cart, login, API) designed to exhaust PHP, database and disk I\/O.<\/li>\n<\/ul>\n<p>Most smaller sites are hit by a mix of low\u2011to\u2011medium volumetric traffic plus very targeted Layer 7 requests. A few thousand requests per second to a slow PHP page can bring down an under\u2011tuned VPS as effectively as a giant network flood.<\/p>\n<p>If you want a conceptual refresher on attack types, you can also read our dedicated article <a href='https:\/\/www.dchost.com\/blog\/en\/ddos-nedir-web-sitenizi-ddos-saldirilarindan-nasil-korursunuz\/'>explaining what DDoS is and how it works at the network and application layers<\/a>.<\/p>\n<h3><span id=\"12_Constraints_specific_to_small_and_medium_websites\">1.2 Constraints specific to small and medium websites<\/span><\/h3>\n<p>Smaller sites face distinct limitations compared to huge platforms:<\/p>\n<ul>\n<li><strong>Limited bandwidth<\/strong> and connection limits on shared hosting or entry\u2011level VPS plans.<\/li>\n<li><strong>Constrained CPU\/RAM<\/strong>, especially if you run a CMS like WordPress, WooCommerce or a heavy PHP framework.<\/li>\n<li><strong>Single-region hosting<\/strong> without globally distributed infrastructure.<\/li>\n<li><strong>Minimal on\u2011call capacity<\/strong>: no 24\/7 security team watching graphs.<\/li>\n<\/ul>\n<p>Because of these constraints, your strategy cannot only be \u201cadd more hardware\u201d. Instead, you need to filter and shape malicious traffic as far away from your origin as possible, then tune the origin to fail gracefully if something slips through.<\/p>\n<h2><span id=\"2_A_Layered_DDoS_Defense_Model_for_RealWorld_Sites\">2. A Layered DDoS Defense Model for Real\u2011World Sites<\/span><\/h2>\n<p>At dchost.com, we design DDoS protection as a stack of layers that complement each other:<\/p>\n<ul>\n<li><strong>DNS and edge layer (Cloudflare)<\/strong>: hides your origin IP, absorbs large floods, blocks obvious attacks and bots before traffic even touches your server.<\/li>\n<li><strong>Edge rate limiting<\/strong>: limits how many requests per IP (or per token) can reach your origin for specific endpoints.<\/li>\n<li><strong>Origin firewall and kernel<\/strong>: iptables\/nftables\/ufw, connection tracking and TCP tuning to handle surges without collapsing.<\/li>\n<li><strong>Web server and application tuning<\/strong>: Nginx\/Apache\/LiteSpeed, PHP\u2011FPM and database settings that prevent a few heavy requests from starving everything else.<\/li>\n<li><strong>Monitoring and incident playbook<\/strong>: metrics, logs and predefined actions so your response during an attack is calm and repeatable.<\/li>\n<\/ul>\n<p>This layered approach is crucial. Cloudflare alone cannot protect a badly tuned origin from every Layer 7 pattern. Conversely, a perfectly tuned server can still be overwhelmed if you let an attacker throw millions of requests per second directly at it. You need both.<\/p>\n<h2><span id=\"3_Using_Cloudflare_Effectively_for_DDoS_Protection\">3. Using Cloudflare Effectively for DDoS Protection<\/span><\/h2>\n<p>Cloudflare is one of the most accessible DDoS mitigation tools for small and medium websites, because it sits in front of your existing hosting without any code changes. But configuration matters a lot: an un\u2011tuned Cloudflare setup can still leak large amounts of malicious traffic to your origin.<\/p>\n<p>For a more detailed configuration walkthrough, you can also check our dedicated guide on <a href='https:\/\/www.dchost.com\/blog\/en\/cloudflare-guvenlik-ayarlari-rehberi-kucuk-isletme-siteleri-icin-waf-rate-limit-ve-bot-korumasi\/'>Cloudflare security settings, WAF, rate limiting and bot protection for small business sites<\/a>. Below we\u2019ll focus on the DDoS\u2011specific pieces.<\/p>\n<h3><span id=\"31_Put_your_site_fully_behind_Cloudflare\">3.1 Put your site fully behind Cloudflare<\/span><\/h3>\n<ul>\n<li><strong>Use proxied DNS (orange cloud)<\/strong>: Make sure A\/AAAA records for your web host are proxied, not DNS\u2011only. Otherwise Cloudflare cannot filter traffic.<\/li>\n<li><strong>Do not leak your origin IP<\/strong>: Avoid publishing your server IP in additional DNS records, test subdomains, or email banners. Once the origin IP is known, attackers can bypass Cloudflare entirely.<\/li>\n<li><strong>Use Cloudflare-friendly DNS architecture<\/strong>: Our guide on <a href='https:\/\/www.dchost.com\/blog\/en\/cloudflare-dns-mi-hosting-dnsi-mi-en-dogru-nameserver-stratejisi\/'>choosing between Cloudflare DNS and hosting DNS<\/a> explains how to structure nameservers and records safely.<\/li>\n<\/ul>\n<h3><span id=\"32_Enable_and_tune_Cloudflare_WAF\">3.2 Enable and tune Cloudflare WAF<\/span><\/h3>\n<p>The Web Application Firewall (WAF) is your first defense against Layer 7 attacks:<\/p>\n<ul>\n<li><strong>Turn on Managed Rules<\/strong> for common attack categories (SQL injection, XSS, common CMS exploits).<\/li>\n<li><strong>Enable CMS\u2011specific rulesets<\/strong> (e.g. WordPress, Magento) if you run those platforms.<\/li>\n<li><strong>Add custom rules<\/strong> for sensitive endpoints like <code>\/wp-login.php<\/code>, <code>\/xmlrpc.php<\/code>, <code>\/cart<\/code>, <code>\/checkout<\/code>, <code>\/api\/<\/code>, using conditions such as URI, request method and user agent.<\/li>\n<\/ul>\n<p>If you are primarily fighting WordPress bots and credential stuffing, our article <a href='https:\/\/www.dchost.com\/blog\/en\/cloudflare-waf-kurallari-ve-oran-sinirlama-ile-wordpressi-botlardan-nasil-korursun\/'>on using Cloudflare WAF rules and rate limiting specifically to stop WordPress bots<\/a> walks through real rule examples.<\/p>\n<h3><span id=\"33_Cloudflare_rate_limiting_for_expensive_endpoints\">3.3 Cloudflare rate limiting for expensive endpoints<\/span><\/h3>\n<p>Cloudflare\u2019s rate limiting should be applied surgically, not globally. Focus on high\u2011cost actions:<\/p>\n<ul>\n<li>Login endpoints (<code>\/wp-login.php<\/code>, <code>\/user\/login<\/code>, <code>\/signin<\/code>)<\/li>\n<li>Search and filtering (<code>\/search<\/code>, <code>?s=<\/code>, filter parameters)<\/li>\n<li>Checkout, cart and payment pages<\/li>\n<li>Public APIs (e.g. <code>\/api\/v1\/<\/code>)<\/li>\n<\/ul>\n<p>Good starting points per IP (you can adjust later):<\/p>\n<ul>\n<li><strong>Login pages<\/strong>: 5\u201310 requests per minute; block or challenge after that.<\/li>\n<li><strong>Search endpoints<\/strong>: 20\u201360 requests per minute; throttle (rate\u2011limit) further bursts.<\/li>\n<li><strong>APIs<\/strong>: depends heavily on your app, but often 60\u2013120 requests per minute per IP is enough for human\u2011driven traffic.<\/li>\n<\/ul>\n<p>When tuning these rules, watch Cloudflare analytics to spot false positives. Be especially careful with shared office IPs, VPNs and mobile carrier NATs where many legitimate users share one public IP.<\/p>\n<h3><span id=\"34_Bot_management_and_challenge_modes\">3.4 Bot management and \u201cchallenge\u201d modes<\/span><\/h3>\n<p>Cloudflare\u2019s bot scoring is useful against low\u2011effort DDoS bots:<\/p>\n<ul>\n<li><strong>Challenge high\u2011risk bots<\/strong> (JS challenge\/captcha) instead of immediately blocking. Challenges are lighter than serving a full PHP page but still filter out unsophisticated tools.<\/li>\n<li><strong>Raise security level temporarily<\/strong> during an active attack. This increases the likelihood that suspicious visitors are challenged.<\/li>\n<li><strong>Use country\u2011based rules<\/strong> if your business is very local and you consistently see attacks from regions you never sell to.<\/li>\n<\/ul>\n<h3><span id=\"35_Protect_the_origin_with_Authenticated_Origin_Pulls_and_mTLS\">3.5 Protect the origin with Authenticated Origin Pulls and mTLS<\/span><\/h3>\n<p>Another important step is ensuring only Cloudflare can speak to your origin:<\/p>\n<ul>\n<li><strong>Restrict your server firewall<\/strong> to accept HTTP\/HTTPS only from Cloudflare\u2019s IP ranges.<\/li>\n<li><strong>Use Authenticated Origin Pulls or mutual TLS (mTLS)<\/strong> so the origin verifies that incoming connections actually belong to Cloudflare.<\/li>\n<\/ul>\n<p>We explained this model in detail in our article about <a href='https:\/\/www.dchost.com\/blog\/en\/origini-korumak-cloudflare-authenticated-origin-pulls-ve-mtls-ile-gercek-kaynak-dogrulamasi\/'>protecting your origin with Cloudflare Authenticated Origin Pulls and mTLS<\/a>. This is especially powerful against attackers who somehow discover your raw server IP.<\/p>\n<h2><span id=\"4_Designing_Smart_Rate_Limiting_at_Edge_and_Origin\">4. Designing Smart Rate Limiting at Edge and Origin<\/span><\/h2>\n<p>Rate limiting is about fairness: preventing a single client (or small group of bots) from consuming your entire capacity. The trick is to <strong>apply limits as close to the attacker as possible<\/strong> while being gentle with legitimate bursty traffic.<\/p>\n<h3><span id=\"41_Edge_rate_limiting_vs_origin_rate_limiting\">4.1 Edge rate limiting vs origin rate limiting<\/span><\/h3>\n<p>You can (and usually should) combine:<\/p>\n<ul>\n<li><strong>Edge rate limiting (Cloudflare)<\/strong>: stops floods out on the internet, saves your bandwidth and keeps origin connection counts low.<\/li>\n<li><strong>Origin rate limiting (web server\/firewall\/application)<\/strong>: provides a second line of defense if malicious traffic gets through, and gives you more granular control using internal signals.<\/li>\n<\/ul>\n<h3><span id=\"42_Web_server_level_rate_limiting_Nginx_Apache_LiteSpeed\">4.2 Web server level rate limiting (Nginx, Apache, LiteSpeed)<\/span><\/h3>\n<p>At the web server layer you can rate limit per IP, per URL or even per cookie or header. Common strategies:<\/p>\n<ul>\n<li><strong>Connection limiting<\/strong>: cap the number of simultaneous connections per IP.<\/li>\n<li><strong>Request rate limiting<\/strong>: restrict how many requests an IP can make per second\/minute.<\/li>\n<li><strong>Burst handling<\/strong>: allow short spikes beyond the limit, but queue or drop if they continue.<\/li>\n<\/ul>\n<p>Examples of policies that work well for small sites:<\/p>\n<ul>\n<li>Maximum 10\u201320 concurrent connections per IP.<\/li>\n<li>Average 5\u201310 requests per second per IP on dynamic endpoints.<\/li>\n<li>More relaxed limits or no limits on static assets (CSS, JS, images) because they are cheap to serve and often aggressively cached.<\/li>\n<\/ul>\n<p>If you are comfortable at the firewall level, you can implement advanced patterns using nftables. Our cookbook on <a href='https:\/\/www.dchost.com\/blog\/en\/nftables-ile-vps-guvenlik-duvari-rehberi-rate-limit-port-knocking-ve-ipv6-kurallari-nasil-tatli-tatli-kurulur\/'>nftables\u2011based rate limiting and IPv6 rules for VPS servers<\/a> shows how to combine connection caps and rate filters directly in the kernel.<\/p>\n<h3><span id=\"43_Application-level_rate_limiting\">4.3 Application-level rate limiting<\/span><\/h3>\n<p>Some attacks are best handled inside the application itself:<\/p>\n<ul>\n<li><strong>Login attempts per username or email<\/strong>, not just per IP.<\/li>\n<li><strong>API tokens or user IDs<\/strong> with their own per\u2011minute limits.<\/li>\n<li><strong>Per\u2011session constraints<\/strong> so one compromised session cannot hammer your backend indefinitely.<\/li>\n<\/ul>\n<p>For APIs and microservices, we have a separate article on <a href='https:\/\/www.dchost.com\/blog\/en\/api-ve-mikroservisler-icin-rate-limiting-stratejileri-nginx-cloudflare-ve-redis-ile-trafik-kontrolu\/'>rate limiting strategies with Nginx, Cloudflare and Redis<\/a>. Many of those ideas can be adapted to smaller monolithic web apps as well.<\/p>\n<h3><span id=\"44_Avoiding_false_positives_when_limiting_rates\">4.4 Avoiding false positives when limiting rates<\/span><\/h3>\n<p>The biggest fear with rate limiting is blocking real customers. Some practical safeguards:<\/p>\n<ul>\n<li><strong>Start in log\/monitor mode<\/strong> if your platform supports it, so you can see who would be blocked before enforcing.<\/li>\n<li><strong>Use higher limits for HTML pages than for API calls<\/strong>, because browsers will naturally open parallel connections and request multiple assets.<\/li>\n<li><strong>Whitelist known monitoring IPs<\/strong> (uptime checkers, payment gateways) so health checks do not trigger rules.<\/li>\n<li><strong>Implement separate rules for authenticated users<\/strong>, who may legitimately make more requests than anonymous visitors.<\/li>\n<\/ul>\n<h2><span id=\"5_Server-Side_Hardening_and_Tuning_Against_DDoS\">5. Server-Side Hardening and Tuning Against DDoS<\/span><\/h2>\n<p>Even with Cloudflare in front and good rate limiting, some abnormal traffic will still reach your origin. Your operating system, firewall and web stack should be tuned so they degrade gracefully instead of collapsing.<\/p>\n<h3><span id=\"51_Kernel_and_network_stack_tuning\">5.1 Kernel and network stack tuning<\/span><\/h3>\n<p>Linux has many sysctl parameters that influence how it handles large numbers of connections, SYN packets and buffer usage. Key areas to review:<\/p>\n<ul>\n<li><strong>Connection tracking limits<\/strong>: ensure <code>net.netfilter.nf_conntrack_max<\/code> is set high enough for expected traffic but not so high that you run out of RAM during a flood.<\/li>\n<li><strong>SYN flood protection<\/strong>: tune <code>net.ipv4.tcp_syncookies<\/code> and related settings to mitigate SYN floods without excessive resource use.<\/li>\n<li><strong>Backlog queues<\/strong>: parameters like <code>net.core.somaxconn<\/code> and <code>net.ipv4.tcp_max_syn_backlog<\/code> control how many pending connections your server can hold.<\/li>\n<li><strong>Buffer sizes<\/strong>: adjust TCP buffer settings so long\u2011lived connections do not exhaust memory.<\/li>\n<\/ul>\n<p>We have a detailed, real\u2011world walkthrough of these parameters in our article on <a href='https:\/\/www.dchost.com\/blog\/en\/yuksek-trafikli-wordpress-laravelde-linux-tcp-tuning-sysctl-ayarlari-udp-bufferlari-ve-syn-flooda-karsi-sakin-kalmak\/'>Linux TCP tuning for high\u2011traffic WordPress and Laravel<\/a>. Even if your site is smaller, applying the same principles at a smaller scale will help during bursts.<\/p>\n<h3><span id=\"52_Firewall_configuration_and_basic_DDoS_protections\">5.2 Firewall configuration and basic DDoS protections<\/span><\/h3>\n<p>Your firewall is the last network gate before the web server. On a VPS or dedicated server, you should at minimum:<\/p>\n<ul>\n<li><strong>Allow only required ports<\/strong> (80, 443, SSH on a non\u2011standard port, plus any needed service ports).<\/li>\n<li><strong>Limit new connection rates per IP<\/strong> at the firewall level for HTTP and HTTPS.<\/li>\n<li><strong>Drop malformed packets<\/strong> and obvious scans (e.g. invalid TCP flag combinations).<\/li>\n<li><strong>Consider Fail2ban<\/strong> or similar tools to temporarily ban IPs that trigger many errors or authentication failures.<\/li>\n<\/ul>\n<p>If you prefer a checklist, our guides on <a href='https:\/\/www.dchost.com\/blog\/en\/vps-guvenlik-sertlestirme-kontrol-listesi-sshd_config-fail2ban-ve-root-erisimini-kapatmak\/'>VPS security hardening (including Fail2ban and SSH best practices)<\/a> and <a href='https:\/\/www.dchost.com\/blog\/en\/vps-sunucularda-guvenlik-duvari-yapilandirma-ufw-firewalld-ve-iptables\/'>firewall configuration with ufw, firewalld and iptables<\/a> give you step\u2011by\u2011step starting points.<\/p>\n<h3><span id=\"53_Web_server_and_PHP-FPM_tuning\">5.3 Web server and PHP-FPM tuning<\/span><\/h3>\n<p>DDoS attackers love to exploit weak spots in your PHP and database stack. Some tuning basics:<\/p>\n<ul>\n<li><strong>Limit PHP\u2011FPM workers<\/strong> (<code>pm.max_children<\/code>) so they fit in RAM; otherwise, a spike will cause swapping and the entire server slows down.<\/li>\n<li><strong>Set sane timeouts<\/strong> for fastcgi\/proxy connections. You do not want stuck requests tying up resources for minutes.<\/li>\n<li><strong>Enable caching<\/strong> (FastCGI cache, LiteSpeed cache, plugin\u2011level cache) so many requests are served without hitting PHP at all.<\/li>\n<li><strong>Graceful resource limits<\/strong> (max execution time, memory limits) to prevent a single heavy request from consuming everything.<\/li>\n<\/ul>\n<p>We have covered PHP\u2011FPM and OPcache tuning in several articles, for example our deep dives on <a href='https:\/\/www.dchost.com\/blog\/en\/wordpress-ve-woocommerce-icin-php-fpm-ayarlari-pm-pm-max_children-ve-pm-max_requests-hesaplama-rehberi\/'>PHP\u2011FPM settings for WordPress and WooCommerce<\/a> and on OPcache configuration. Applying those same optimizations makes DDoS traffic much less effective at exhausting your CPU and RAM.<\/p>\n<h3><span id=\"54_Logging_and_retention_during_attacks\">5.4 Logging and retention during attacks<\/span><\/h3>\n<p>Heavy DDoS traffic can also fill your disk via logs. Basic precautions:<\/p>\n<ul>\n<li><strong>Use logrotate aggressively<\/strong> with compression and size\u2011based rotation for access and error logs.<\/li>\n<li><strong>Consider sampling<\/strong> logs during extreme attacks if disk I\/O becomes a bottleneck.<\/li>\n<li><strong>Forward critical logs<\/strong> (e.g. firewall drops, HTTP 5xx) to external log storage if you need long\u2011term retention.<\/li>\n<\/ul>\n<p>This ensures your server does not die with a \u201cno space left on device\u201d error in the middle of an attack.<\/p>\n<h2><span id=\"6_Monitoring_Detection_and_an_Incident_Playbook\">6. Monitoring, Detection and an Incident Playbook<\/span><\/h2>\n<p>Protection is only half the story; you also need to <strong>notice attacks quickly<\/strong> and know what to do when they happen. Even small teams can set up lightweight monitoring that makes a big difference.<\/p>\n<h3><span id=\"61_Metrics_to_watch\">6.1 Metrics to watch<\/span><\/h3>\n<p>At minimum, keep an eye on:<\/p>\n<ul>\n<li><strong>Requests per second<\/strong> at the edge (Cloudflare analytics) and at the origin (web server metrics).<\/li>\n<li><strong>CPU, RAM and load average<\/strong> on the server.<\/li>\n<li><strong>Network bandwidth<\/strong> in\/out on the interface.<\/li>\n<li><strong>HTTP status code distribution<\/strong>: spikes in 5xx or 429 often accompany attacks or misconfigured rate limits.<\/li>\n<\/ul>\n<p>Tools like Netdata, Prometheus, Grafana or even simpler dashboards can help. We have a step\u2011by\u2011step guide on <a href='https:\/\/www.dchost.com\/blog\/en\/vps-izleme-ve-alarm-kurulumu-prometheus-grafana-ve-uptime-kuma-ile-baslangic\/'>setting up VPS monitoring and alerts with Prometheus, Grafana and Uptime Kuma<\/a> if you want a repeatable setup.<\/p>\n<h3><span id=\"62_Basic_DDoS_incident_playbook\">6.2 Basic DDoS incident playbook<\/span><\/h3>\n<p>During an attack, you do not want to improvise. A simple, written checklist already helps a lot:<\/p>\n<ol>\n<li><strong>Confirm it is a DDoS<\/strong>: check Cloudflare and origin metrics for sudden RPS\/bandwidth spikes or abnormal patterns.<\/li>\n<li><strong>Identify target endpoints<\/strong>: Is traffic hitting <code>\/wp-login.php<\/code>, <code>\/search<\/code>, <code>\/api\/<\/code>, or random URLs?<\/li>\n<li><strong>Tighten Cloudflare rules<\/strong>: raise security level, enable more aggressive WAF rules, add or strengthen rate limits and country\/IP ranges if appropriate.<\/li>\n<li><strong>Scale down non\u2011essential workloads<\/strong> on the same server (background jobs, heavy cron tasks) to free CPU and RAM.<\/li>\n<li><strong>Adjust origin rate limits<\/strong> and timeouts to protect the database and PHP\u2011FPM.<\/li>\n<li><strong>Log key details<\/strong> (time, IP ranges, user agents, URIs) for later analysis and longer\u2011term rule improvements.<\/li>\n<\/ol>\n<p>After the incident, review what worked, what caused false positives and what can be automated for next time. Over a few iterations, your incident playbook becomes much smoother.<\/p>\n<h2><span id=\"7_Hosting_Architecture_Choices_and_How_dchostcom_Can_Help\">7. Hosting Architecture Choices and How dchost.com Can Help<\/span><\/h2>\n<p>No DDoS strategy is complete without a realistic look at your hosting architecture and capacity. You do not need a giant cluster for every project, but some patterns significantly improve resilience:<\/p>\n<ul>\n<li><strong>Right\u2011sized VPS or dedicated server<\/strong>: enough CPU\/RAM to handle your normal peaks with margin, so small attacks do not instantly push you to 100% usage.<\/li>\n<li><strong>Separation of concerns<\/strong>: for higher\u2011traffic sites, consider splitting web and database servers or at least isolating background workers.<\/li>\n<li><strong>Global DNS\/CDN layer<\/strong> in front of your origin (e.g. Cloudflare) so large volumetric attacks are absorbed away from your server.<\/li>\n<li><strong>Backup and disaster recovery<\/strong>: regular backups, tested restores and clear RPO\/RTO targets so even in the worst case, you can rebuild.<\/li>\n<\/ul>\n<p>At dchost.com, we support these patterns across shared hosting, VPS, dedicated servers and colocation. Our team can help you choose a plan with sufficient bandwidth and resources, configure Cloudflare DNS\/proxy on top, and apply the server\u2011side tuning we use internally for high\u2011traffic customers.<\/p>\n<p>If you already host with us and want to harden an existing site against DDoS, a practical sequence is:<\/p>\n<ol>\n<li>Enable Cloudflare in front of your domain and proxy all public web records.<\/li>\n<li>Apply our Cloudflare WAF and rate limiting recommendations from the articles linked above.<\/li>\n<li>Implement kernel, firewall and web server tuning based on our Linux TCP and firewall guides.<\/li>\n<li>Set up basic monitoring and an incident checklist so you are not surprised by the next traffic spike.<\/li>\n<\/ol>\n<p>You do not have to do everything at once. Each step you implement \u2013 edge protection, smarter rate limits, better server tuning \u2013 makes DDoS traffic less effective and keeps your real customers online. If you need help choosing the right hosting plan or reviewing your current stack from a DDoS resilience perspective, our team at dchost.com is ready to work through it with you.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>Distributed denial-of-service (DDoS) attacks are no longer a problem only for banks and global platforms. In capacity planning calls with our own customers at dchost.com, we routinely see small WordPress sites, local e\u2011commerce stores and SaaS side\u2011projects hit by automated floods of traffic. The goal is simple: exhaust your bandwidth, CPU, RAM or connection limits [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":3891,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-3890","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3890","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=3890"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3890\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/3891"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=3890"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=3890"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=3890"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}