DDoS Protection Basics for Small Business Websites

A distributed denial-of-service attack, or DDoS attack, tries to make a website or service unavailable by overwhelming it with traffic from many sources at once. The traffic usually comes from a network of compromised devices, called a botnet. The goal is rarely to steal data; it is to disrupt, to extort money, or sometimes just to cause trouble.

Small sites are targeted less often than big brands, but they are not immune, and a single attack can take a small server offline. This guide explains the types of attack and sensible, realistic preparation.

The main types of DDoS attack

Type	What it targets	Example
Volumetric	Network bandwidth	Floods of packets that fill the connection
Protocol	Network and server resources such as connection tables	SYN floods that leave connections half-open
Application layer	The web application itself	Large numbers of requests to search pages or login forms

Volumetric and protocol attacks are mostly handled by network infrastructure. Application-layer attacks look like real visitors, so they are harder to filter and are the type small sites are most likely to meet in a form they can do something about.

Why attacks work against small sites

A low-end server has a finite number of connections, processes and CPU. A modest flood of requests that each require PHP and database work can exhaust it, even if the bandwidth is fine. Uncached search pages, XML-RPC endpoints, login forms and expensive filters are favourite targets for exactly this reason.

How mitigation works

• Absorb: large networks with huge capacity soak up floods before they reach your server.
• Filter: traffic is inspected, and requests that match attack patterns, bad reputations or known botnets are dropped.
• Challenge: suspicious visitors get a JavaScript check or a challenge page that real browsers pass and simple bots fail.
• Rate limit: a single client may only make so many requests in a given time.
• Cache: serving pages from cache means attack requests never reach your application.

A CDN or reverse proxy in front of your site combines most of these. Visitors, and attackers, connect to the provider's network, not to your server directly. Protection levels differ between providers and plans, so read what your plan actually includes.

What you can do

1. Put a CDN or protective proxy in front of your site and make sure your origin server only accepts traffic from it where possible. Hiding the real IP address helps, but check that DNS records, mail headers or old subdomains do not reveal it.
2. Cache aggressively. Page caching turns many requests into cheap file reads.
3. Rate limit expensive endpoints, such as search, login and password reset.
4. Disable what you do not use, for example XML-RPC on WordPress if no tool needs it.
5. Keep software updated, since some application-layer attacks exploit slow or inefficient code paths.
6. Monitor. An uptime monitor and alerts on traffic or resource spikes tell you quickly when something is wrong.
7. Have a plan. Know who to contact at your host, how to enable stricter protection mode at your CDN, and where your latest backup is.

Recognising an attack

Not every traffic spike is an attack. A post going viral also raises load. Warning signs of an attack include huge numbers of requests from unusual locations, many requests to one URL, identical user agents, a spike without a matching rise in orders or genuine engagement, and slowdowns that do not match marketing activity. Server logs and CDN analytics show which URLs and countries are involved.

During an attack

1. Contact your hosting support early so they can look at network-level options.
2. Enable your CDN's stricter security or "under attack" mode if it offers one.
3. Block or challenge the specific patterns you can identify, such as one endpoint or country that gets no genuine traffic.
4. Serve a static version of the site if possible while the application recovers.
5. Do not pay extortion demands. Paying does not guarantee the attack stops.
6. Afterwards, review logs and strengthen weak points.

Limits of protection

No provider can promise that an attack will never affect your site. Very large floods can strain even well-prepared infrastructure, and an attack that hits your application logic may get through basic filtering. What good preparation does is reduce the likelihood and shorten the recovery.

Application-layer examples to harden

Because application-layer floods look like normal visitors, it pays to know your expensive URLs. Think about which pages cost the server most: search results, product filters, calendar and booking widgets, unpaged archives, login and password reset endpoints, and anything that calls a database several times. For each one, ask three questions. Can it be cached? Can it be rate limited per visitor? Can it be removed or simplified if it is not important?

For example, a WordPress search that queries many tables can be limited to a small number of requests per minute per address. An archive page that lists every post can be paginated. A script that regenerates a report on each view can store its result for an hour. Each change cuts the amount of work an attacker gets from a single request, which is what makes a small server hard to knock over.

Plan communication too

If your site takes orders or bookings, decide in advance how customers will reach you if it goes down: a phone number, a social profile, or a status message. Being able to say "we are aware and working on it" keeps trust intact while you recover.

Where Zebra Hosting fits

Cloudflare CDN is available on hosted sites with Zebra Hosting Cloud, giving you a protective layer in front of your origin. For a summary of security measures across the platform, see the security page.