Defending from DDoS

[adripillo]

Hello,

If I have DDoS attacks can I add a list of allowed IPs to connect to the server and set the firewall to reject "the rest"? Can this work?

 

[ShelLuser]

If I have DDoS attacks can I add a list of allowed IPs to connect to the server and set the firewall to reject "the rest"? Can this work?

Yes and no, my favourite answer, because it heavily depends on what you consider "working".

It will most certainly stop the attacking processes from connecting to any of your services, but unfortunately it will not "nullify" the effects of the DDoS itself. Your server will remain to be hardly reachable, or worse.

Because even though you may now block the incoming packets it doesn't make those packets suddenly go away. Even if you tell the firewall to ignore them they still need to be processed, thus will also continue to gobble up precious resources. With all the nasty and unwanted side effects.

Hope this helps shed some light on this.

 

[adripillo]

Yes and no, my favourite answer, because it heavily depends on what you consider "working".

It will most certainly stop the attacking processes from connecting to any of your services, but unfortunately it will not "nullify" the effects of the DDoS itself. Your server will remain to be hardly reachable, or worse.

Because even though you may now block the incoming packets it doesn't make those packets suddenly go away. Even if you tell the firewall to ignore them they still need to be processed, thus will also continue to gobble up precious resources. With all the nasty and unwanted side effects.

Hope this helps shed some light on this.

Yes I was thinking same thing, It does not "lag" the connection so bad but still is a pain. Any other idea of how to stop it or at least get the connection more stable for the IPs that are allowed?

 

[ShelLuser]

Any other idea of how to stop it or at least get the connection more stable for the IPs that are allowed?

The best way is to contact the "upper layer". So if we're talking about a home server then you should contact your Service Provider ("ISP"), if this is a hosted server then it's time to talk to the hosting provider, and so on.

Avoiding this stuff is always better than having to fight it, because depending on your situation it's very hard to figure out where it's coming from.

"Back in the day" (Grandpa Shell talking :e) I used to get into trouble from time to time during or after visits on certain IRC channels. The worst part: even normally legit channels. Only because some "unfriendly people" were giving the channel a hard time. Stuff like that can be avoided (to a certain extend) by using IPv6.

Even if your Internet or server connection doesn't support IPv6 there are quite a few so called tunnel brokers available which can provide a gateway to go from IPv4 to IPv6. To my knowledge DDoS on IPv6 is still pretty rare.

And the other nice thing: even if you do manage to attract nastyness; there are so many available addresses that it's normally easy to simply switch to another and turn one off.

However: there is an important detail to keep in mind here... Some brokers (or providers) assign you with a "subnet" (say a small network within their own network) and will then route all the data for that subnet to your tunnel. SO in those cases you'd basically in the same situation you are now: although the DDoS can't affect your system because no data is being accepted or processed, you still need to deal with the burden of having an overload of packets to process.

The better ones (in my opinion) assign a subnet but then require you to activate any additional addresses you're going to use. That's a much better design because this basically means that they only reserved the subnet for you but aren't sending everything through. So if you are having problems on one IPv6 address you could unassign it after which no data can reach your box any longer.

If you'd consider such a setup I think it's a good idea to warn said brokers up front, that way you'll avoid any risk of them turning nasty on you due to unexpected traffic increases.

 

[adripillo]

Thanks a lot! Will have to read about IPv6 tunneling.

 

[gkontos]

Unfortunalty in this case IPv6 will not help if you are using DNS for your service. Also, most consumer ISP's still don't provide IPv6 yet.

Your best defense is to block the attackers at the firewall level. This can be done either static or dynamic.

Static means that you have identified the offensive networks or IP's and you block them. Example, I have a certain server that the firewall blocks all incoming connections from China.

Dynamic means that you create a script that searches a log file based upon certain criteria and identifies IP addresses. Those IP addresses are then added to a table. You can flush the table on an hourly basis.

--

 

[adripillo]

Thank you.

 

[ShelLuser]

Unfortunalty in this case IPv6 will not help if you are using DNS for your service. Also, most consumer ISP's still don't provide IPv6 yet.

I think I may have been a little unclear above.. When talking IPv6 I'm merely reflecting on that as a valid option to easily avoid nastiness as a client. If we're talking about hosting a (web)server which provides several features for clients or customers then IPv6 obviously is not a feasible solution just yet, because at this time the best option is to provide both (IPv4 and IPv6).

Sorry if that part was a bit unclear in my previous post.

Your best defense is to block the attackers at the firewall level. This can be done either static or dynamic.

And that's where I don't fully agree.

In my opinion the best defence is to contact the "layer above"; either hosting or service provider. Simply because they will have a lot more bandwith than the OP has (this is a bit of an assumption on my part, but in general this holds true). And depending on the provider they should (or "might") be able to totally nullify the DDoS effects.

 

[kpa]

I also disagree about using only a firewall to block attackers. A firewall will not stop the packets arriving at the firewall, all it does is to deny access to any further. In case of a large DDoS a firewall isn't a solution at all, only the upstream that is your ISP can do anything about it.

 

[gkontos]

I also disagree about using only a firewall to block attackers. A firewall will not stop the packets arriving at the firewall, all it does is to deny access to any further. In case of a large DDoS a firewall isn't a solution at all, only the upstream that is your ISP can do anything about it.

You don't always have the luxury of having an upstream that is willing to do that for you. In most cases they will shut you down until you "fix" the problem.

Blocking the attacker in the firewall level might increase your CPU but this is nothing compared to the usage that an DOS attack can bring to a web server in regards to CPU & Bandwidth.

 

[kpa]

You don't always have the luxury of having an upstream that is willing to do that for you. In most cases they will shut you down until you "fix" the problem.

Blocking the attacker in the firewall level might increase your CPU but this is nothing compared to the usage that an DOS attack can bring to a web server in regards to CPU & Bandwidth.

The firewall is useful only when your connection can take the brunt of the attack, when it starts to choke under the load the firewall becomes irrelevant.

 

[adripillo]

Thanks all for reply, all info you give is very useful for me.

 

[gkontos]

The firewall is useful only when your connection can take the brunt of the attack, when it starts to choke under the load the firewall becomes irrelevant.

Just FYI, a network firewall works in layers 3-4. Most DOS attacks are aimed at services running at layer 7.

There are many ways to examine the logs of a service that is being attacked and use scripts that can extract the offending IP addresses. Those IP addresses can then be added dynamically to a table.

If you your firewall reaches to the point that it drops legitimate connections then you should really look at alternative hosting / security solutions.

 

[ShelLuser]

Just FYI, a network firewall works in layers 3-4. Most DOS attacks are aimed at services running at layer 7

I'm not sure what you're trying to say here. Especially considering that the firewalls provided by FreeBSD are basically application firewalls, thus spanning the application layer with the network and transport layer.

There are many ways to examine the logs of a service that is being attacked and use scripts that can extract the offending IP addresses. Those IP addresses can then be added dynamically to a table.

And now you completely lost me.

Because such a setup is just as bad as having to let a webserver (or any other application) handle the load of the problems. I dare to argue that it's even worse because this process is two folded; one process to extract the information and another to apply this to the firewall. Taken a "common" DDoS onslaught into account I can only shudder at the sheer idea.

Also; you now mention DOS but the OP mentioned DDoS, there is a significant difference because the latter will have a lot more magnitude. Easily surpassing the abilities of one single server.

Once again I don't agree here. In fact; I think in comparison the OP's initial suggestion of following the concept "Allow some, deny the rest" would actually be a more preferable approach.

 

[gkontos]

I'm not sure what you're trying to say here. Especially considering that the firewalls provided by FreeBSD are basically application firewalls, thus spanning the application layer with the network and transport layer.

PF, IPFW, etc. block packets at the network layer. They can not filter in the application layer.

And now you completely lost me.

Because such a setup is just as bad as having to let a webserver (or any other application) handle the load of the problems. I dare to argue that it's even worse because this process is two folded; one process to extract the information and another to apply this to the firewall. Taken a "common" DDoS onslaught into account I can only shudder at the sheer idea.

If you have ever experienced a DOS attack you would know that it always has certain patterns. That said it is quite common for people to confuse DDoS and DOS attacks. Again, defining the scale of DDoS is a very important factor.

Every service should log any type of access. By examining certain behavior we can create effective scripts that can dynamically manipulate a firewall. Therefore, without stressing the service we collect data and we feed with that data our packet filtering mechanism.

Also; you now mention DOS but the OP mentioned DDoS, there is a significant difference because the latter will have a lot more magnitude. Easily surpassing the abilities of one single server.

True, but like I said before it is quite common for people to use the term DDoS without taking into account the scale. 90% of the attacks that happen on web servers and game servers can be successfully prevented using open source utilities and host based firewalls.

If you reach to the point were your horsepower is not enough then you need to accommodate other layers of defense.

Once again I don't agree here. In fact; I think in comparison the OP's initial suggestion of following the concept "Allow some, deny the rest" would actually be a more preferable approach.

As long as you know what to allow yes. But again if your criteria is based upon countries you are going to end up with huge access lists that can really slow down the packet filtering. I know because I am doing this type of filtering.

Relying on an upstream for anti DOS protection is the next layer of managed outsourced defense that you must pay a considerable amount of money for it. That upstream could be a provider charging you for this or a CDN.

Depending on the bandwidth you consume it night not be even possible to rely on a CDN.

 

[throAU]

Bear in mind: firewall rules increase processing overhead and can not do anything about the traffic "on the wire" being sent to you. Hence, blocking traffic on your firewall may not help - the traffic already arrived, and consumed your bandwidth.

Additionally, having your firewall inspect and process all those packets may lead to other performance issues due to processing overhead. So whilst you may prevent an intrusion (which your rule-set should already try to do DDoS or not), you'll still be under DDoS. Even if you drop ALL traffic from the IP ranges in question on your firewall and you have the processing resources available to process every incoming packet, the traffic already filled your uplink's bandwidth. You are still denied service.

As above, the only real solution is to get the traffic blocked upstream at the network backbone if necessary, before the point where the network connectivity fans out to low bandwidth circuits.

I.e., if you are getting hit with 1-10 gigabit worth of DDoS, whatever filtering or shaping you try to do on the end of your 10 or 100 megabit customer connection is going to have little effect on the actual availability of your link.

 

[Savagedlight]

If your firewall deny rules consume more resources than accepting the incoming connection attempts, you have a very very bad firewall. But you're right about the bandwidth consumption; Once it has arrived at your firewall, it has already consumed parts of your download capacity. All you can do with your system at that point is to make sure your system don't respond to it, as that would consume more local resources and upload capacity.

 

[Chris_H]

Bear in mind: firewall rules increase processing overhead and can not do anything about the traffic "on the wire" being sent to you. Hence, blocking traffic on your firewall may not help - the traffic already arrived, and consumed your bandwidth.

Additionally, having your firewall inspect and process all those packets may lead to other performance issues due to processing overhead. So whilst you may prevent an intrusion (which your rule-set should already try to do DDOS or not), you'll still be under DDOS. Even if you drop ALL traffic from the IP ranges in question on your firewall and you have the processing resources available to process every incoming packet, the traffic already filled your uplink's bandwidth. You are still denied service.

As above, the only real solution is to get the traffic blocked upstream at the network backbone if necessary, before the point where the network connectivity fans out to low bandwidth circuits.

I.e., if you are getting hit with 1-10 gigabit worth of DDOS, whatever filtering or shaping you try to do on the end of your 10 or 100 megabit customer connection is going to have little effect on the actual availability of your link.

Quite right! I've had the displeasure too many times in the past dealing with (D)DoS. While the "block in quick" available in pf(4) is a real godsend, it has absolutely no effect on your CPE, and perhaps even your switch (depending on it's location in relation to your firewall). So, bandwidth, is bandwidth. They consume it whether you're "firewalled", or not. You can only effectively defend against CPU cycle consumption, at best.

--chris

 

[gkontos]

Please do keep in mind that bandwidth consumption happens only on ESTABLISHED connections.

If you are blocked in layer 3 level then I could not care less about your bandwidth. Anyone who has seriously experienced a DDos attack knows that it is not the bandwidth that will bring down your filtering device but the frequency and the spread of the attack.

Now, in my previous posts I tried to explain that there are certain techniques that you can apply in order to defend as much as you can from an attack when you combine the information that you extract from the layer 7 and you simply filter it in layer 3.

Yes, the CNN portal uses different approaches to defend against those types of attacks.

 

[Chris_H]

Greetings @gkontos,

I've been subject to several serious attacks. The last three I was able to track to telcoms, who were aware, and struggling with finding its source -- as the attacks were being "deflected" off their block. I was able to determine the source, and gave them the information they needed. But to my earlier point. A CPE is still vulnerable to attack(s), and many, if not most, are virtually defenseless. Given that they are, for all practical purposes, the gateway. This will choke communication -- both incoming, and outgoing.

So unless I've completely misunderstood you; there is no fault in my previous comment.

Best wishes.

--chris