How to Defend From a Distributed Denial of Service (DDoS) Attack

[kiwi]

Distributed Denial of Service (DDoS) attacks are all too common in today's internet of things. It's very cheap to rent an army of infected hosts — including infected refrigerators and home thermostats! — to lay siege to a network of your choosing.

Because it has gotten so easy to organize a DDoS attack, the reasons behind such attacks have gotten more diverse as well. In the past one needed skill and determination — so attacks were ideological or for massive profit. Today, disgruntled employees or upset neighbors with a little internet savvy could set up a DDoS on their target of choice.

Luckily, defending against these sorts of attacks is not that difficult and can be enabled with just a few clicks. I'm going to highlight some of the available options below.

One important thing to note before we get started is that Zone Protection provides protection at the ingress zone, the zone where traffic enters the firewall. So if you want to protect your DMZ from traffic originating from the internet (untrust), you will need to add a protection profile on the untrust interface.

The first tab of the zone protection profile (under Network > Network Profiles > Zone Protection) lands you on the settings you need:

Network > Network Profiles > Zone Protection

The SYN Flood Protection has 2 types of protection available: Random Early Drop and SYN cookies. Both require a slightly different approach to the Activate and Alert threshold:

• Random Early Drop (RED) - SYN packets will be dropped to mitigate a flood attack.
  • Alarm rate is reached - an alarm is generated
  • Activate rate is reached - the firewall drops individual SYN packets randomly to restrict the flow
  • Maximum rate is reached - 100% of incoming SYN packets are dropped.

NOTE: This method indiscriminately discards SYN packets so it is recommended to set the activate rate as high as possible and some research might be required to determine your network's baseline.

• SYN cookies: my personal preference is SYN cookies where the firewall acts as a handshake proxy: incoming syn packets are not immediately put into the session table but rather a cookie is generated and sent back to the source. If the sender fails to respond with an appropriate ACK containing the cookie, or at all, the SYN packet is dropped and no session gets created. If the source does reply, the syn is passed along to the internal server and a session is created.

NOTE: Using SYN cookies might seem the 'smarter' solution but it consumes more resources than RED. If SYN Cookies consumes too many resources, switch to RED. If you don’t have a dedicated DDoS prevention device in front of the firewall (at the internet perimeter), it's recommended to use RED.

Furthermore, you can activate a additional other protections:

Reconnaissance Protection prevents culprits from scanning your resources:

Packet Based Attacks Protection blocks malformed (malicious or otherwise) packets from entering your network:

Protocol Protection allows you to integrally block any protocols you might not like (for example PPP or GRE):

Ethernet SGT Protection allows you to create a list of Layer 2 Security Group Tags (SGTs) that you want to exclude. Apply the Zone Protection profile to a Layer 2, virtual wire, or tap interface. If an incoming packet with an 802.1Q (Ethertype 0x8909) header has an SGT that matches an SGT in your list, the firewall drops the packet.

NOTE: Zone Protection as the name indicates, covers a whole 'zone' which may include several different client-server permutations. And the total throughput for the zone may not correspond to what one single server is able to endure: a more subtle version of DDoS may target a single server to just bring it to the brink of failure, but not trigger the whole Zone Protection.

To protect a single resource, DoS Protection Profiles can be created to apply finely tuned micro-profiles:

Objects > Security Profiles ? DoS Protection

Note that you can choose between aggregate or classified DoS Protection Profiles :

• Aggregate: Applies the DoS thresholds configured in the profile to all packets that match the rule criteria on which this profile is applied. For example, an aggregate rule with a SYN flood threshold of 10000 packets per second (pps) counts all packets that hit that particular DoS rule.
• Classified: Applies the DoS thresholds configured in the profile to all packets satisfying the classification criterion (source IP, destination IP or source-and-destination IP).

The principles for DoS Protection Profiles are the same as Zone Protection Profiles, except the values are tuned to the server's limits. Also a block duration was added to put any offending source IP addresses on a block list for a duration of time, and the maximum concurrently active sessions (under Resources Protection) can also be regulated, not to oversubscribe a server.

Please share if you know an admin that could use a quick refresher or hasn't bothered implementing these extra layers of protection.

Share your experience on how you protected your network from DDoS attacks !

Thank you for taking time to read this blog!

Don't forget to hit the Like (thumbs up) button and to Subscribe to the LIVEcommunity Blog area.

As always, we welcome all questions, comments and feedback in the comments section below.

Kiwi out!

[kiwi]

Distributed Denial of Service (DDoS) attacks are all too common in today's internet of things. It's very cheap to rent an army of infected hosts — including infected refrigerators and home thermostats! — to lay siege to a network of your choosing.

Because it has gotten so easy to organize a DDoS attack, the reasons behind such attacks have gotten more diverse as well. In the past one needed skill and determination — so attacks were ideological or for massive profit. Today, disgruntled employees or upset neighbors with a little internet savvy could set up a DDoS on their target of choice.

Luckily, defending against these sorts of attacks is not that difficult and can be enabled with just a few clicks. I'm going to highlight some of the available options below.

One important thing to note before we get started is that Zone Protection provides protection at the ingress zone, the zone where traffic enters the firewall. So if you want to protect your DMZ from traffic originating from the internet (untrust), you will need to add a protection profile on the untrust interface.

The first tab of the zone protection profile (under Network > Network Profiles > Zone Protection) lands you on the settings you need:

Network > Network Profiles > Zone Protection

The SYN Flood Protection has 2 types of protection available: Random Early Drop and SYN cookies. Both require a slightly different approach to the Activate and Alert threshold:

• Random Early Drop (RED) - SYN packets will be dropped to mitigate a flood attack.
  • Alarm rate is reached - an alarm is generated
  • Activate rate is reached - the firewall drops individual SYN packets randomly to restrict the flow
  • Maximum rate is reached - 100% of incoming SYN packets are dropped.

NOTE: This method indiscriminately discards SYN packets so it is recommended to set the activate rate as high as possible and some research might be required to determine your network's baseline.

• SYN cookies: my personal preference is SYN cookies where the firewall acts as a handshake proxy: incoming syn packets are not immediately put into the session table but rather a cookie is generated and sent back to the source. If the sender fails to respond with an appropriate ACK containing the cookie, or at all, the SYN packet is dropped and no session gets created. If the source does reply, the syn is passed along to the internal server and a session is created.

NOTE: Using SYN cookies might seem the 'smarter' solution but it consumes more resources than RED. If SYN Cookies consumes too many resources, switch to RED. If you don’t have a dedicated DDoS prevention device in front of the firewall (at the internet perimeter), it's recommended to use RED.

Furthermore, you can activate a additional other protections:

Reconnaissance Protection prevents culprits from scanning your resources:

Packet Based Attacks Protection blocks malformed (malicious or otherwise) packets from entering your network:

[kiwi]

Protocol Protection allows you to integrally block any protocols you might not like (for example PPP or GRE):

Ethernet SGT Protection allows you to create a list of Layer 2 Security Group Tags (SGTs) that you want to exclude. Apply the Zone Protection profile to a Layer 2, virtual wire, or tap interface. If an incoming packet with an 802.1Q (Ethertype 0x8909) header has an SGT that matches an SGT in your list, the firewall drops the packet.

[kiwi]

NOTE: Zone Protection as the name indicates, covers a whole 'zone' which may include several different client-server permutations. And the total throughput for the zone may not correspond to what one single server is able to endure: a more subtle version of DDoS may target a single server to just bring it to the brink of failure, but not trigger the whole Zone Protection.

To protect a single resource, DoS Protection Profiles can be created to apply finely tuned micro-profiles:

[kiwi]

Objects > Security Profiles ? DoS Protection

Note that you can choose between aggregate or classified DoS Protection Profiles :

• Aggregate: Applies the DoS thresholds configured in the profile to all packets that match the rule criteria on which this profile is applied. For example, an aggregate rule with a SYN flood threshold of 10000 packets per second (pps) counts all packets that hit that particular DoS rule.
• Classified: Applies the DoS thresholds configured in the profile to all packets satisfying the classification criterion (source IP, destination IP or source-and-destination IP).

The principles for DoS Protection Profiles are the same as Zone Protection Profiles, except the values are tuned to the server's limits. Also a block duration was added to put any offending source IP addresses on a block list for a duration of time, and the maximum concurrently active sessions (under Resources Protection) can also be regulated, not to oversubscribe a server.

Please share if you know an admin that could use a quick refresher or hasn't bothered implementing these extra layers of protection.

Share your experience on how you protected your network from DDoS attacks !

Thank you for taking time to read this blog!

Don't forget to hit the Like (thumbs up) button and to Subscribe to the LIVEcommunity Blog area.

As always, we welcome all questions, comments and feedback in the comments section below.

Kiwi out!