Is your site under attack? What to do in the first hour

First: confirm it is an attack

An attack and a failure look alike from outside — the site does not respond — and differ from inside. Before touching anything, look at the traffic pattern in your network provider’s dashboard or in the server logs. An attack usually leaves a recognizable signature: volume spikes with no campaign, promotion, or press mention to explain it; requests concentrate on a few URLs, most often the login form, the internal search, or a public API; they arrive from regions where you have no customers; and the server degrades progressively rather than falling over at once.

A failure, by contrast, tends to be abrupt and even: everything breaks at the same time, with no change in traffic. Telling one from the other in the first minutes avoids the worst possible waste of time, which is repairing what is not broken.

What to do in the first minutes

Order matters more than speed. These four steps can run in parallel if there is more than one person, but none should be skipped.

Turn on your network provider’s protection mode. If your site sits behind a content delivery network or a protection service, nearly all of them offer a hardened mode that challenges visitors before letting the request through. It is the measure that stops the most automated traffic with the least risk to legitimate visitors.

Do not restart the server. It is the first thing instinct asks for and the least helpful. If the attack saturates capacity before reaching your application, restarting only adds boot time to the outage; and in any case it wipes memory, connections, and sometimes logs you will later need to understand what happened and show what was done.

Preserve the evidence. Save the server and network logs from before the incident started. They are what lets you reconstruct the attack, tune the rules so it does not recur, and, if the case calls for it, support a report to the authorities. Logs usually rotate on their own: if nobody sets them aside, within hours they are gone.

Tell whoever deals with customers. Sales and support will get the calls before you do. An agreed sentence — what is known, what is being done, when there will be news — keeps everyone from improvising their own.

What to do, by type of attack

Not every attack is contained the same way, and applying the wrong measure costs time.

Denial of service (DDoS). The goal is to exhaust your capacity, not to get in. It is contained upstream, on the network in front of your infrastructure, not on your server: anything your machines do arrives too late, because the traffic already reached them. If your site is not behind a network that can absorb that volume, putting it behind one is the fix — and it is worth doing before the next attack, not during this one.

Bots and credential stuffing. Here the volume can be modest and the damage larger: someone is testing leaked usernames and passwords against your login form. The signals are failed attempts above the norm, many different users from few addresses — or one user from a great many — and successful logins from geolocations that do not fit. Containment means rate-limiting attempts, requiring verification at login, and forcing a password reset on any account already taken.

Attacks against the application. SQL injection, cross-site scripting, path traversal, attempts to run code. These are careful requests, not massive ones, which is exactly why they go unnoticed among normal traffic. They are stopped with a web application firewall whose rules are tuned to what your application actually does; out-of-the-box generic rules either block legitimate customers or let through the ones that matter.

Signs that they are already in. If your application starts generating outbound traffic it never generated before — connections to unknown addresses, large transfers outside business hours — the problem is no longer the attack: it is the access it gained. At that point the priority changes entirely, from containing to isolating, and it is worth involving someone experienced in incident response before touching the system further.

What is better left undone

Three common reactions that make things worse:

Blocking entire countries as a first move. It cuts the noise and feels like doing something, but serious attacks arrive distributed — including from inside your own country — and geo-blocking cuts off legitimate customers who are travelling or on a VPN. It buys minutes while the real measure is prepared.

Scaling up the server during the attack. If the attacker can generate more traffic than your budget can absorb, this is a race you lose by paying. Capacity is sized for your business, not for whoever is attacking it.

Closing the incident when traffic drops. The attack stopping does not mean the problem is solved. If nothing was adjusted, the only thing that changed is that the attacker got bored, and they usually come back.

How Lynxsource responds

Lynxsource deploys protection on Cloudflare, monitors its logs from its Security Operations Center on Microsoft Sentinel around the clock, and responds when an attack happens, with in-house teams in Ecuador, Colombia, Bolivia, the United States, and Canada.

In practice, what a managed service changes is the clock. Alerts reach the SOC and are classified and prioritized in under a minute; an analyst picks up the case the AI flagged in four minutes on average, contains the attack, and afterwards explains what happened, what was done, and what is worth adjusting. The difference from a firewall that is switched on and unwatched is not the tool: it is that someone is looking at three in the morning.

If you want the detail of the service — what it covers, what it runs on, and how it differs from switching on a WAF yourself — it is on the managed WAF and web protection page. And if what you have right now is an attack in progress, the assessment form is not the way: call the numbers in the footer of this page.