Linux - DDoS Deflate To Block DDoS Attack

(D)DoS Deflate is a shell script developed by Zaf, originally for use on MediaLayer servers to assist in combating denial of service attacks. However, it was seen to be very effective for our purpose and It is a lightweight bash shell script designed to assist in the process of blocking a denial of service attack. It utilizes the command below to create a list of IP addresses connected to the server, along with their total number of connections. It is one of the simplest and easiest to install solutions at the software level.

# netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n

IP addresses with over a pre-configured number of connections are automatically blocked in the server's firewall, which can be direct iptables or Advanced Policy Firewall (APF). (We highly recommend that you use APF on your server in general, but deflate will work without it.)

Notable Features:

It is possible to white-list IP addresses, via /usr/local/ddos/ignore.ip.list.

Simple configuration file: /usr/local/ddos/ddos.conf

IP addresses are automatically unblocked after a preconfigured time limit (default: 600 seconds)

The script can run at a chosen frequency via the configuration file (default: 1 minute)

You can receive email alerts when IP addresses are blocked.

Installation:

# wget http://www.inetbase.com/scripts/ddos/install.sh
# chmod 0700 install.sh
# ./install.sh

Uninstallation:

# wget http://www.inetbase.com/scripts/ddos/uninstall.ddos
# chmod 0700 uninstall.ddos
# ./uninstall.ddos

If you start receiving mails like "Quote:Banned the following ip addresses on xxx xxx time xxx with xxx connections"

A fix is here,

which it requires that you replace the netstat command in the ddos.sh file (located in /usr/local/ddos directory if you installed in the default fashion).

In the original script line 117 reads…

Code:

# netstat -ntu | awk ‘{print $5}’ | cut -d: -f1 | sort | uniq -c | sort -nr > $BAD_IP_LIST

this should be rewritten to read as follows…

Code:

# netstat -ntu | grep ‘:’ | awk ‘{print $5}’ | sed ‘s/::ffff://’ | cut -f1 -d ‘:’ | sort | uniq -c | sort -nr > $BAD_IP_LIST

How To Check The Number Of Connected Ips:-

# sh /usr/local/ddos/ddos.sh

How To Edit Configuration File:-

# vi /usr/local/ddos/ddos.conf

How To Restart DDos Deflate:-

# sh /usr/local/ddos/ddos.sh -c

Cheers!!!

Comments

Post a Comment

Popular posts from this blog

Resolved: DOCKER: Error response from daemon: Could not attach to network / rpc error: code = 7 desc = network not manually attachable.

Image
I got this error: 'docker: Error response from daemon: Could not attach to network <nw-name>: rpc error: code = 7 desc = network <nw-name> not manually attachable.' when i try to create the container on the overlay network on swarm mode enabled, In docker 1.12 with swarm mode enabled, "Swarm" scoped networks (see the "SCOPE" column) cannot be used for docker run, only for services and now it has been rectified. I'm using updated version of docker, but still why i'm experiencing the error ? because the network just created but not manually attachable. To fix the issue we gonna use --attachable flag while creating network. [ --attachable             Enable manual container attachment ] (Need to create service on the overlay network, so that the overlay network will available / list on the worker node) docker inspect attnw (attnw is our test network)should show your own c
Read more

yum failed 6 times. Cannot continue!

Error while cPanel installation: (ERROR): - ssystem [EXIT_CODE] '/usr/bin/yum' exited with 1 (ignored) (DEBUG): - ssystem [END] (FATAL): yum failed 6 times. Cannot continue! fix: It looks like you have some name resolution issues on the server. Just run the following commands on your server and it will resolve the name resolution issues. #echo "nameserver 8.8.8.8" >> /etc/resolv.conf #echo "nameserver 8.8.4.4" >> /etc/resolv.conf if it is not working properly still facing same error, then here we go, # rpm -e --nodeps bind-chroot # rpm -e --nodeps bind # yum install bind
Read more

unexpectedly shrunk window (repaired) in dmesg log - TCP Peer

Don't Panic, This normally occurs when a client decides to reduce its TCP window size, without the server expecting it. This can be the case when fragmentation is an issue, or when the client is using an embedded device with very little NIC buffer memory. This is a completely normal behaviour, and you’re likely to see quite a few such packets in your log. The messages are informational only, and are used to debug networking issues. I’d be worried if you saw hundreds of thousands of these packets, since there are attacks that involve packet fragmentation and small window sizes, but otherwise it’s just the normal sort of noise you should expect to see on any internet-facing network. In fact, the “repaired” part of your message is showing that your network driver fixed the issue, which is usually done by concatenating the payloads of two fragmented packets together. Shouldn’t be an issue at all. … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … 
Read more