Brute Force and DDoS Basics: What You Can Stop Yourself and When to Call Your Host
A brute force attack guesses passwords to break into an account, while a DDoS attack floods a site with traffic to knock it offline. You can stop most brute force attempts yourself with multi factor authentication, strong passwords, and login limits. You can reduce some DDoS traffic with a CDN and firewall rules, but large floods need your hosting provider, because they hit the network before they reach your site.
This guide explains how each attack works, which warning signs to look for, what you can safely do on your own, and what to send your host when you need help. No tool or provider can promise to stop every attack, and we will not pretend otherwise.
We have hosted more than 700,000 websites over 20+ years, and the same pattern repeats. Owners lose time guessing which kind of attack they face, then apply the wrong fix. Sorting the two apart first saves hours.
What Is the Difference Between a Brute Force Attack and a DDoS Attack?
A brute force attack targets a login, trying many passwords to take over an account. A DDoS attack targets availability, sending so much traffic that real visitors cannot get through. One tries to get in, and the other tries to keep everyone out.
How Brute Force Attacks Target Website Logins and Server Access
In a brute force attack, software tries password after password until one works. Common targets are the WordPress login page, control panel logins, SSH, and email accounts. Attackers use automated tools, so they can try thousands of guesses an hour.
A related attack is credential stuffing. Instead of guessing, the attacker takes usernames and passwords leaked from other websites and tries them on yours. Each account may get only one or two attempts, so the pattern looks different.
The difference matters for defense. Login limits help against brute force, but they work less well against credential stuffing, which spreads attempts across many accounts and addresses. Unique passwords and multi factor authentication help against both.
Neither attack needs your site to be special. Bots scan the internet for any login page they can find.
How Distributed Denial of Service Attacks Overwhelm Websites and Servers
A distributed denial of service attack uses many machines at once, often a botnet of infected devices, to flood a target. The goal is to use up bandwidth, processing power, or memory, so real visitors get errors or nothing at all.
The attacker usually does not want your data. They may want to extort money, damage a competitor, or cause disruption. Some attacks are simply tests by people running attack tools.
Most attacks are small and short. Cloudflare’s H1 2026 report says 96.62 percent of the network layer attacks it saw stayed under 500 Mbps, and 90.60 percent ended within 10 minutes.
That matters for your plan. An attack can be over before a support ticket is answered, so automated protection helps more than a fast human reply.
Understanding Application-Layer and Network-Layer Attacks
Attacks work at different levels. Network layer attacks flood the connection itself with raw traffic, such as DNS or UDP floods. Application layer attacks send requests that look like normal visits, such as thousands of page loads or searches a second.
You can often handle application layer attacks yourself, because they hit your website. A firewall, rate limits, or a CDN can filter requests that look wrong.
Network layer attacks are different. They can fill the pipe to your server before your own rules ever see the traffic. Only the host or the upstream network can stop those.
Attackers also mix both types. Cloudflare reports multi vector campaigns that shift methods during an incident, which is another reason to expect layers of defense, not one fix.
Recognizing the Warning Signs of Suspicious Login Activity
Brute force attacks leave traces in your logs and inbox. Look for many failed logins in a short time, logins for usernames that do not exist, and attempts from many unfamiliar locations.
You may also see lockout emails from security plugins, password reset emails you did not request, or a new administrator account you did not create. The last one means someone may already be in.
As an illustration, fifty failed logins from one address in a minute is a clear brute force pattern. One failed login from you after a typo is not.
Check your authentication logs weekly. Early warning gives you time to react calmly.
Identifying Traffic Spikes, Slow Responses and Unexpected Downtime
DDoS attacks show up as sudden slowdowns, errors such as 503, or a site that stops loading. Resource graphs may show CPU, memory, or bandwidth climbing far above normal.
Be careful before you call it an attack. A viral post, a newsletter, a backup job, or a runaway plugin can also cause spikes. Check what changed, and look at where the traffic comes from.
A real attack often shows many requests for the same page, odd user agents, or traffic from regions you do not serve. As an example, a site used to 20 requests a second that suddenly receives 2,000 deserves a closer look.
Compare with your normal baseline. Without one, every spike looks the same.
How Can You Protect Your Website From Brute Force Attacks Yourself?
Turn on multi factor authentication, use strong unique passwords, remove unused accounts, limit login attempts, protect the login page, and watch your logs. These steps stop most brute force attempts and need no deep technical skill.
Enabling Multi Factor Authentication for Administrative Accounts
Multi factor authentication asks for a second proof, such as a code from an app, after the password. Even if an attacker guesses or steals a password, they cannot log in without the second factor.
Turn it on for every administrator account first. That includes your CMS, control panel, hosting account, domain registrar, and email.
Prefer app based codes or hardware keys over text messages where you can. Store recovery codes safely, since losing your phone without them can lock you out.
This single step defeats most brute force and credential stuffing attacks. If you do one thing from this guide, do this.
Using Strong Passwords and Removing Unused User Accounts
Use long, unique passwords for every login. A password manager makes that practical. Reused passwords are what make credential stuffing work.
Remove accounts you no longer need. Old staff accounts, test users, and forgotten admin logins are easy targets, because nobody is watching them.
Avoid the username admin. Attackers try it first.
Check your passwords against known breach lists. A password manager or a service such as Have I Been Pwned can tell you if an address appeared in a leak, which is a signal to change those passwords.
Give each person only the permissions their job needs. A writer does not need administrator rights.
Applying Login Rate Limits and Failed Attempt Restrictions
A rate limit slows or blocks repeated attempts. After a few failures, the address is locked out for a while. This makes guessing thousands of passwords impractical.
On cPanel hosting, cPHulk offers brute force protection at the server level, and your host may already run it. For WordPress, plugins can limit login attempts per address.
Set sensible numbers. Too strict, and you lock out your own staff. Too loose, and the limit does little.
Remember that limits work best against simple brute force. Credential stuffing spreads attempts across many addresses, so pair limits with multi factor authentication.
Protecting WordPress Login Pages With Appropriate Security Controls
WordPress login pages are a favorite target. Useful controls include a login limiting plugin, a CAPTCHA on the login form, and a web application firewall that blocks known bad bots.
Some owners restrict the login page to known IP addresses. That is strong, but it only works if your own address stays stable.
Also review the XML-RPC feature, which some attackers abuse for repeated login guesses. Disable it if you do not need it, and test your site afterward, since some apps depend on it.
Keep WordPress, themes, and plugins updated. If you install through the Softaculous auto installer, check regularly that updates are applied.
Monitoring Authentication Logs for Repeated Suspicious Activity
Logs show what is happening. Control panels and security plugins record failed logins with times and addresses. Read them weekly, not only after a problem.
Look for repeated failures from one source, or a slow trickle from many. The slow trickle is a sign of credential stuffing.
Set up alerts for events that matter, such as a new admin account or a successful login after many failures. Alerts beat manual checking.
Keep logs for long enough to investigate. Short retention erases the evidence you need.
What Can You Do Yourself When Your Website Experiences a DDoS Attack?
Confirm that it is an attack, turn on CDN and firewall protection, filter bad requests, limit heavy requests carefully, and record everything. These steps can reduce application layer attacks, but they cannot guarantee protection against every DDoS attack.
Checking Traffic Patterns and Confirming Whether an Attack Is Occurring
First, confirm. Check your analytics, server stats, and logs. Look for a sudden jump in requests, many hits on one page, or odd traffic sources.
Rule out innocent causes. Did you send a newsletter, launch a sale, or run a backup? Is a plugin looping?
Check your host’s status page too. The problem may be on the host’s side, not an attack on you.
Do not make big changes until you know what you are dealing with. Hasty changes can make things worse.
Enabling CDN and Web Application Firewall Protection
A CDN sits between visitors and your server. It can absorb and filter traffic, and a web application firewall can block requests that look malicious. A CloudFlare CDN is one option we offer.
Many CDNs offer a stricter mode for emergencies. Cloudflare calls its version Under Attack Mode, which adds a check before visitors reach your site. It adds friction for real visitors, so turn it off when the attack ends.
A CDN can help a lot against application layer attacks, but it is not a guarantee. It also needs setup, and attackers who find your real server address can bypass it.
Limit direct access to your server to the CDN’s addresses where possible, and keep your origin address private.
Filtering Malicious Application-Level Requests With Appropriate Rules
Firewall rules can block patterns, such as requests to a certain page from certain countries, or with certain user agents. ModSecurity on a server and rules in a CDN can both do this.
Write narrow rules based on what you see in the logs. Broad rules block real customers.
Test each rule on your own traffic first, if you can. Roll back anything that causes errors.
If you are unsure, ask your host. A wrong rule on a live site can cause more downtime than the attack.
Limiting Resource-Intensive Requests Without Blocking Legitimate Visitors
Some attacks target expensive pages, such as search, login, or checkout. Rate limits on those pages can protect your server without blocking the whole site.
Caching helps. If your homepage is served from a cache, a flood of requests costs the server far less.
Aim at the pattern, not at everyone. Blocking an entire country may stop real customers.
Set a fallback message. If a search or checkout page must be limited, show a friendly note that explains the delay, so customers know to try again.
Check your analytics after each change. If legitimate visitors drop, loosen the rule.
Preserving Logs and Recording Attack Times and Symptoms
Keep a record from the first minute. Note when it started, what you saw, and what you changed. Save error messages and take screenshots of traffic graphs.
Download logs before they rotate away. Access logs and error logs show the sources and targets.
This record helps your host and any specialist you bring in. It also helps you learn afterward.
Note what you changed and when. A change log shows whether a fix helped or made things worse.
A simple text file with times is enough. Accuracy matters more than neatness.
Which Brute Force and DDoS Problems Require Your Hosting Provider?
Your host needs to handle network level floods, attacks that exhaust the server’s CPU, memory or bandwidth, repeated attacks on SSH or mail ports, and anything that needs upstream filtering. If the traffic hits the server before your rules can, only the provider can act.
Recognizing Network-Level Attacks That Exceed Your Server’s Capacity
Signs of a network attack include a site that disappears entirely, a server that does not respond even to the host’s tools, and bandwidth graphs hitting the ceiling. Your own firewall rules will not help, because the traffic fills the connection first.
You cannot fix this from inside the server. If the road to your house is blocked, nothing you do in the living room helps.
Contact your host at once. Speed matters, since the provider may need to reroute or filter traffic upstream.
Be honest about limits. No host can promise to stop every attack, and larger attacks can overwhelm even strong providers.
Requesting Upstream Traffic Filtering and Network-Level DDoS Mitigation
Upstream filtering means blocking bad traffic before it reaches your server, at the provider’s network edge or with a partner. It is often the only way to stop a large flood.
Ask what your host can do. Options may include rate limiting, blackholing a target address for a short time, or routing traffic through a scrubbing service. Each has trade offs.
Blackholing protects the network by dropping all traffic to an address, which also drops real visitors. Ask about it before agreeing.
Our dedicated servers and USA VPS plans suit sites that need more headroom. Ask us about current mitigation options on any plan.
Escalating Attacks That Exhaust CPU, Memory or Bandwidth Resources
When an attack uses up your account’s CPU, memory, or bandwidth, you may see errors like 508 or 503. On shared hosting, it can also affect neighbors, so the host has its own reasons to act.
Tell support what resources are being used and when. They can see server level data you cannot.
They may suspend a site briefly or move it to protect others. That can feel harsh, but it protects every customer on the server.
If attacks keep coming, you may need a plan with dedicated resources.
Reporting Repeated Attacks Against SSH, Mail Services and Other Server Ports
Attacks are not limited to websites. SSH, mail, FTP, and control panel ports also get hammered with login attempts. These are server level services, so your host usually manages the protection.
Report repeated attacks with the dates and addresses. Hosts often run tools that block abusive addresses automatically.
If you manage your own VPS, restrict SSH to keys, limit who can connect, and consider a tool that blocks repeat offenders. Email attacks also target mail accounts, and our MailChannels corporate email helps keep outgoing mail clean, though you should confirm what it covers.
Use strong mailbox passwords everywhere, since compromised mail accounts often send spam.
Understanding the Difference Between Hosting Support and Specialized Security Response
Hosting support looks after the service: the server, the network, and the account. A specialized security team investigates breaches, cleans malware, and analyzes attacks. These are different jobs.
Our team handles tickets 24/7, and you can read how end user support works. Support can help with mitigation, resource problems, and server level blocks. A hacked site needing forensic cleanup usually needs a specialist.
Ask your provider where its responsibility ends. A clear answer helps you plan before an emergency.
If you run a reseller hosting business, agree who handles which tasks with your own customers, too.
How Should You Contact Your Hosting Provider During a Website Attack?
Send your domain, server IP, and start time, share graphs, errors, and logs, say whether the site is slow, down, or partly working, ask what mitigation is available, and coordinate changes so you do not undo each other. Clear details get faster help.
Providing the Affected Domain, Server IP and Incident Start Time
Start with the basics. Give the domain, the account name, the server or IP address, and the time the problem began, with your time zone.
Those four facts let support find the right server in seconds. Without them, they must ask, and minutes pass.
Say if the issue is ongoing or has stopped. Add the time of any earlier incident, too.
Put the facts at the top of the ticket, not in the middle of a long story.
Sharing Traffic Graphs, Error Messages and Relevant Log Entries
Attach evidence. Screenshots of traffic graphs, exact error messages, and a few relevant log lines help support see what you see.
Pick the useful parts. A short excerpt with the pattern is better than a huge file.
Include your analytics view if it shows a spike. It confirms timing and scale.
Include the time range each graph covers, and mark when the problem started. A graph without times is hard to use. Send what you have, even if it is incomplete, since a first report beats waiting for perfect evidence.
Remove passwords and private data from anything you send.
Explaining Whether the Website Is Slow, Unavailable or Partially Functional
Describe the symptom precisely. Is the site slow, fully down, or working for some people but not others? Do some pages load, such as the homepage, while others fail?
Say if email, the control panel, and SFTP also fail. That points toward the server or network rather than one site.
Mention who is affected, such as visitors from one country or all of them.
Add what you have already tried. If you cleared caches or disabled a plugin, say so, so support does not repeat your steps.
Precise symptoms narrow the cause fast.
Asking About Available DDoS Mitigation and Firewall Capabilities
Ask direct questions. What filtering is in place? Can you apply rate limits? Is upstream mitigation available, and at what cost or condition?
Ask what your plan includes, and what needs an upgrade. Do not assume.
Request a plain explanation of any action they take, such as suspending a site or blocking traffic.
Ask about urgent contact too. Is there a way to reach someone after hours? Knowing this before an attack saves time, so write the answers into your incident plan.
A good provider answers openly, including what it cannot do.
Coordinating Mitigation Without Making Conflicting Security Changes
Two people changing security settings at once can undo each other’s work. Before you change firewall rules, DNS, or CDN settings, tell support what you plan to do.
Ask who is doing what. One owner for each layer avoids chaos.
Log every change with its time. If something breaks, you can trace it.
After the attack ends, agree which temporary rules to remove. Emergency settings left on can quietly hurt your site for months.
Avoid making DNS changes in the middle of an attack unless advised. They can slow things further.
How Can You Reduce the Risk of Future Brute Force and DDoS Attacks?
Keep software updated, restrict administrator access, set up backups and alerts, write down an incident plan, and review your defenses after each attack. Prevention will not stop every attack, but it makes each one smaller and shorter.
Maintaining Updated CMS Software, Plugins and Server Components
Updates close known holes. Keep your CMS, themes, plugins, and any server software current, and remove what you do not use.
Old software is often how attackers get in after a login attack. A stolen password plus a flaw is far worse than either alone.
Use automatic updates for minor releases where you can, and test major ones first.
Check what protections your hosting plan already includes, since that can reduce the work you carry yourself.
Restricting Administrative Access and Reviewing User Permissions
Fewer administrators means fewer targets. Give admin rights only to people who need them, and review the list every quarter.
Restrict the admin area by IP address or a VPN where practical. Put sensitive tools behind extra checks.
Remove access the day someone leaves. Delays create risk.
Consider separate accounts for daily work and for administration. A person who writes posts all day does not need to be logged in as an administrator.
Keep separate logins for each person, so you can trace actions. Billing and client logins are targets too. If you run WHMCS, which comes free with our reseller plans, turn on two factor authentication for staff accounts, and confirm current plan details.
Configuring Backups, Monitoring and Security Notifications
Backups limit the damage of any incident. Keep copies away from your server, and test restoring them.
Add uptime monitoring so you know when the site goes down. Add alerts for failed logins and new admin accounts.
Set alerts that you will actually read. Too many cause fatigue, and you start to ignore all of them.
Check that alerts reach more than one person. If the only person who gets them is on holiday, they are not working.
A short, reliable list of alerts is better than a long, noisy one.
Documenting an Incident Response and Hosting Escalation Procedure
Write a one page plan. List who to call, in what order, what to check first, and what information support will need.
Include your host’s contact methods and any account PINs. Store the plan where your team can reach it when the site is down.
Define what counts as an emergency. A calm plan beats improvising at midnight.
Include a short list of decisions already made, such as when to turn on emergency mode and who may approve it. Decisions made in advance save minutes during an attack.
Practice it once. A short drill exposes missing details.
Reviewing Security Controls After Every Significant Attack
After an incident, hold a short review. What happened, what worked, what did not, and what will you change?
Look at gaps in logging, slow response, and unclear roles. Fix the biggest one first.
Update your plan and rules. Remove temporary measures that are no longer needed, such as strict emergency modes.
Each attack, handled well, makes the next one easier. If you want infrastructure with security and uptime built in, compare plans on our reseller features page and confirm current plan details.
