Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users

Dashboard
Notifications
Mark all as read
Q&A

What actions should be performed to restore a website after a DDoS attack?

+2
−1

My shared hosting provider suffices (at least on contract) daily, weekly, and monthly automatic backups; besides that, I also routinely backup my website's filetree and database not automatically into my PC (clouded), so I am quite covered by means of backups to my website.

I never had a DDoS attack that might crash my website (I would guess, alongside the websites of all other customers which their websites are being hosted on the same shared hosting environment); and I don't really know how, if at all, it could effect the "neighboring" website's and my own website's filetrees and databases.

What actions should be performed to restore a website after a DDoS attack (while hoping the attacker would do it just once, before taking any further actions to also prevent such attacks)?

Why does this post require moderator attention?
You might want to add some details to your flag.
Why should this post be closed?

1 comment thread

General comments (3 comments)

1 answer

+4
−0

A typical DDoS (Distributed Denial of Service; which is a subtype of the broader class of Denial of Service attacks) will simply flood a host, or its network connection, with data. It's not uncommon for the data to be completely meaningless, and for it to never even reach web server software if indeed the host; the aim is normally to prevent others from reaching the system, not to cause further damage. It's not at all uncommon for the data to be transported using UDP instead of TCP; for one thing, as UDP doesn't have TCP's three-way handshake, spoofing the source of significant amounts of UDP traffic is easier.

It's a brute force approach: if the attacker can generate (possibly through the use of traffic amplification attacks) more traffic than the attacked host can soak, the attack is successful.

As such, as long as the attack is only a DDoS attack, once the overload situation is resolved (by whichever means), there would typically be no remaining issues that didn't exist before the attack began. If the server has crashed due to traffic overload it would need to be rebooted, but that's really about it, and nothing you as the customer of a shared web hosting package would need to concern yourself with.

There's a small possibility that the attack actually uses legitimate HTTP requests, in which case the web server logs will likely be oversized and could benefit from being purged. But any competent web host should be rotating logs on a recurring basis anyway for a variety of reasons, and again, it's unlikely that this is something that you as a customer will be able to control or do. You certainly shouldn't need to concern yourself with it.

There absolutely are classes of attacks that cause lasting damage and necessitate different types of repair activities, everything from restoring from backup to a complete rebuild on an updated or patched platform; but a DDoS would not typically be one of them.

Why does this post require moderator attention?
You might want to add some details to your flag.

1 comment thread

General comments (1 comment)

Sign up to answer this question »

This community is part of the Codidact network. We have other communities too — take a look!

You can also join us in chat!

Want to advertise this community? Use our templates!