1

Let's assume there are no vulnerabilities in the application layer, one disk, and no physical firewall (just iptables rules in the server itself), hence in this case all the DDoS attack does is to overload processor, RAM, and the disk file system by eventually causing huge amounts of log data from the server firewall (I am not sure if this would happen in an ordinary scenario).

Hypothetical (in my eyes) examples of stored data inconveniences:

  • Disk overloaded by firewall log data caused by DDoS.

  • The need to move the disk to another system in order to clean the log files.

  • Disk overload causing damage or loss of stored data.

That's to illustrate a bit the range of inconveniences, known or hypothetical, that I am talking about (storage and data integrity and conservation specifically), when the conditions are as decribed priorly.

Coming back to the original question, is it mandatory to add a physical firewall to prevent such kind of inconveniences? Or are there other kind of alternative solutions while keeping the same physical setup?

2

If your firewall (iptables) can filter out DDoS and the only problem are firewall logs, the only problem might be disk (partition) size and write speed. If your services are also hit by DDoS, firewall logs are not a problem, as you mentioned you probably run out of resources like RAM and CPU (causing hude system slowdown) much sooner. If you run out of disk space, it's up to particular apps how they handle this situation. Additionally huge disk write will slow down apps from reading data, so there will be a slow down. But it will not damage your disk, it will not destroy any stored data etc. And if the system is running, there should be no reason to move disk to another machine only to clean the log files (at least in any common situation there shouldn't be).

EDIT: As for your final question - physical/box firewall runs in many cases exactly the same software you already have - iptables + rules. So everything you can do on your own server, you can also do with physical firewall, but it's not necessary. Separate firewall will limit firewall logs to separate machine, but it's not a huge difference. DDoS can operate on many layers and ie Web App Firewall (WAF) is not exactly the same type of firewall like the one working on TCP/IP level - in many cases they don't work as expected because on other layers it's much harder to filter out traffic for all types of existing web apps.

Bottom line - DDoS is not easy to filter out in generic way, working for everyone.

Oh, and there is already great answer How do major sites prevent DDoS?

0

If too much log data get written the disk gets full and the next thing you see is either that the system will malfunction because of the full disk and/or log data get lost. Because to write new logs it must have space on disk which it has not.

Apart from that it might be that the events happen faster then they can be written to disk. This means that either the system slows down to prevent loss of log data or it will loose log data.

As how to prevent this: reduce the amount of log data, i.e. either by disabling logging specific events or by making sure the events don't happen, for example by using a firewall. The firewall can be "physical" (i.e. outside the local machine) or it can be the built-in firewall - this depends on the use case (the kind of events which should be filtered) and on the capabilities of the firewall.

-1

I am not really big expert to this topic, but apps usually compress the log files to free up some space, now if you can make less then 100Mb from 2Gb it would take quiet some time to make the disk run out of space just by "spamming" the log files.

  • 1
    Here's a big question: do firewalls compress their logs? I don't know of any. – schroeder Apr 13 '17 at 16:08
  • Good, but it doesn't hurt tobmake a clean up script – ITry Apr 13 '17 at 18:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.