DDoS and malicious bots: Recognize and reduce unwanted traffic
· PoolByte Technology
If your site suddenly slows down or reaches hosting resource limits, it does not always mean a DDoS attack. A successful campaign, a name mentioned on television, or a widely read newsletter can also bring immediate traffic. On the other hand, a significant portion of the visits to your site are from bots, not humans. Search engine bots are useful; Bots that copy content, try passwords or search for vulnerabilities consume resources and pose risks.
A DDoS (distributed denial of service) attack is an attempt to make a service inaccessible with requests from multiple sources. In this article, we discuss how to classify traffic growth and what you can do on the website side for DDoS protection.
Classify traffic growth
The first question is who is the increase coming from? Look for these marks in access logs:
- Do most requests go to the same address, or are they spread across the site?
- Is user-agent information inconsistent or always the same?
- Is there a concentration on costly addresses such as the home page,
xmlrpc.phpor search results? - Do you see a lot of requests to non-existent pages, i.e. heavy 404 registrations?
- Is a local business receiving heavy traffic from unexpected countries?
Actual user traffic can often be attributed to a campaign or content share, is distributed naturally across pages, and also shows up in conversion metrics. Bot traffic often repeats a single pattern.
Two main types of DDoS attacks
Attacks at the network layer work by sending more data to the server or network connection than it can handle. These types of attacks cannot be resolved by website settings; must be met at the data center, hosting provider or CDN level.
Attacks at the application layer are made through normal-looking HTTP requests. The attacker specifically targets pages that tax the server: addresses that run a database query on every request, such as search, filtering, cart or login. These types of website-side measures make a significant difference.
What you can do on the application side
Reducing the load of costly pages works both in real traffic and at the time of attack. Caching pages that are displayed the same to everyone ensures that the majority of requests never reach the application; Details are in our CDN and cache guide.
Other measures include:
- Apply per-IP rate limits to login, search and form addresses.
- Turn off endpoints you are not using; for example, in WordPress, if remote publishing is not required, block XML-RPC access.
- Protect the login screen with two-step verification and trial limit.
- Add invisible bot controls to forms; We explained the methods in our form spam protection guide.
Know the role of WAF
A web application firewall (WAF) inspects incoming HTTP requests with rules and stops known attack patterns before they reach your application. SQL injection, malicious script attempts, scans for known plugin vulnerabilities, and requests from reputable sources are typical targets of these rules.
Imunify360, included in PoolByte hosting packages, provides server-level firewall, WAF rules, and malware scanning. This layer does not compensate for the lack of updates in your application; but eliminates most auto-attacks at an early stage.
Stay calm during an attack
When an attack is suspected, changing every setting at the same time makes it difficult to understand the problem. Instead, follow these steps: note in the logs which addresses and sources the requests are coming from, notify hosting support with time range and sample requests, temporarily limit heavy features such as searching or filtering if necessary. If you use CDN, you can activate the strict protection modes offered in case of attack.
Once the attack is over, review the logs and update the persistent rate limit and WAF rules. Even if there is no attack, if your resource usage is constantly close to the limit, evaluate your package for hosting CPU, RAM and I/O limits.
Frequently asked questions
Is it enough to block offensive IP addresses one by one?
Usually no. DDoS attacks come from multiple and constantly changing addresses. Individual blocks may provide short-term relief; The permanent solution is behavior-based rules and overlay protection.
Should I block search engine bots?
No, blocking real search engine bots makes it harder for your site to show up in searches. However, there are fake bots that pose as Googlebot. For a suspicious request, you can verify whether the bot actually belongs to the relevant search engine with a reverse DNS query.