Databases, Systems & Networks

Homemade DDoS Protection Using IPTables SYNPROXY

First off, if you want the real deal and get your service DDoS protected from even the most complex types of DDoS attacks by security specialists today, don’t bother reading about SYNPROXY and instead check out our Anti DDoS Hosting and Remote DDoS Protection. If you feel confident that you can use SYNPROXY as an addition to your current DDoS mitigation strategy and are an experienced system or network admin, continue reading.

It’s nothing new that DDoS attacks are increasing constantly in size and quantity over the years, making them more likely to affect you personally every month passing by. Apart of DNS Amplifictation Attacks, SYN Floods are one of the most common DDoS attack types today. Until recently Linux systems were very bad at handling SYN Floods properly compared to *BSD, which has a SYN Proxy feature built into its default firewall « PF » for quite a while now, which is a good approach for SYN Flood DDoS mitigation. The Linux default firewall « IPTables » hasn’t had a similar feature for a long time and the only approach to mitigate SYN Floods was the Kernel’s « syncookie » feature, which isn’t by far as performant as one would wish when under SYN Flood.

Finally, after years of lacking appropiate SYN Flood mitigation options under Linux, the new « SYNPROXY » target was introduced with the 3.12 kernel and IPTables version 1.4.21 trying to fill that gap quite successfully. Although it’s not a cure for every SYN Flood, because most ISPs are likely to nullroute your IP before the attack clogs your TCP/IP stack and probably your NIC will cause interrupts before your kernel, but tests have shown that there is a major increase of performance when under SYN Flood, SYN-ACK Flood or ACK Flood.

While a Linux kernel with default settings usually starts to cause software interrupts and starts dropping packets at as little as 200.000 packets per second (PPS), it can handle multiple millions of packets per second with the strategy explained in this tutorial. The number of SYN packets it can handle per second increases by a factor of 10 and the number of ACK packets it can handle per second even increases by a factor of 20, which can be a major advantage when you have to handle large amounts of packets (read: you’re under SYN or ACK Flood).

IPTables « SYNPROXY » on Debian Wheezy
In this example we’ll use a Debian Wheezy system for our setup. I can imagine this being used on Vyatta boxes in the future to effectively protect whole network segments with very cheap hardware. The first things we’ll have to do is to upgrade our kernel and iptables version.

Lire la suite…

Source: Digital Point

After a few days of being attacked by a 25,000 zombie botnet, believe me i have tried almost everything possible to make it stop. The best thing that helped was this script, thought it could help here when it’s your turn getting those script-kiddies attackers visiting your servers.

#!/bin/sh
#------------------------------------------------------------------------------
#
# File: SIG-antiDDoS.sh
#
# Compiler: Ruslan Abuzant <[email protected]>
#           PS> Collected From Lots Of Sources
#           PS> Credits: Real Authors (no idea)
#
# URL: http://www.liteforex.org/
#
# License: GNU GPL (version 2, or any later version).
#
# Configuration.
#------------------------------------------------------------------------------

# For debugging use iptables -v.
IPTABLES="/sbin/iptables"
IP6TABLES="/sbin/ip6tables"
MODPROBE="/sbin/modprobe"
RMMOD="/sbin/rmmod"
ARP="/usr/sbin/arp"


# Logging options.
#------------------------------------------------------------------------------
LOG="LOG --log-level debug --log-tcp-sequence --log-tcp-options"
LOG="$LOG --log-ip-options"


# Defaults for rate limiting
#------------------------------------------------------------------------------
RLIMIT="-m limit --limit 3/s --limit-burst 8"

Lire la suite…

Nodaways seems that every script kid is able to produce a soft DDOS attack, happily they are small and limited so they cant saturate your DNS unless they really know what they are doing.

This is a more or less step by step guide intended for begginers to help stabilize the linux server and prevent further attacks.

There are some basic settings you should have already implemented in your linux server as part of security 101 but this is not always the case and also it is not enough.

Questions and Answers:

• Limiting the ammount of concurrent connections from the same IP address to your Server.
• Identifying the offending IP.
• And kill the Ongoing TCP Connections with TCPKILL.
• Or use Cutter to kill the connections on any port/Network interface.
• Drop it With Iptables.
• Make the DROP Persistant after a reboot. (iptables save and restore)
• Basic Iptables-save trouble shoot.
• Stop Start Iptables

This article assumes you have root access to your linux BOX / Server, the IP addresses shown in this guide are randomly generated and in no case are offending connections.

Lire la suite…

IP fragmentation attacks are a common form of denial of service attack, in which the perpetrator overbears a network by exploiting datagram fragmentation mechanisms.

Understanding the attack starts with understanding the process of IP fragmentation, a communication procedure in which IP datagrams are broken down into small packets, transmitted across a network and then reassembled back into the original datagram.

Fragmentation is necessary for data transmission, as every network has a unique limit for the size of datagrams that it can process. This limit is known as the maximum transmission unit (MTU). If a datagram is being sent that is larger than the receiving server’s MTU, it has to be fragmented in order to be transmitted completely

Example of how an IP datagram is fragmented and reassembled

The IP header in every datagram contains flags detailing whether fragmentation is allowed to take place. In cases where a « don’t fragment » flag is attached to the IP header, the packet is dropped and the server sends out a message saying that the ICMP datagram is too big to transmit. The offset explains to the recipient device the exact order the fragments should be placed in for reassembly.

Attack Types

IP fragmentation attacks can take several forms. While they all exploit the breakdown of datagrams in order to overbear the target networks, there are some notable differences in how different attack vectors are executed.

• UDP and ICMP fragmentation attacks – These attacks involve the transmission of fraudulent UDP or ICMP packets that are larger than the network’s MTU, (usually ~1500 bytes). As these packets are fake, and are unable to be reassembled, the target server’s resources are quickly consumed, resulting in server unavailability.
• TCP fragmentation attacks (a.k.a. Teardrop) – Also known as Teardrop attacks, these assaults target TCP/IP reassembly mechanisms, preventing them from putting together fragmented data packets. As a result, the data packets overlap and quickly overwhelm the victim’s servers, causing them to fail.Teardrop attacks are a result of an OS vulnerability common in older versions of Windows, including 3.1, 95 and NT. While patches were thought to have put a stop to these attacks, a vulnerability resurfaced in Windows 7 and Windows Vista, making Teardrop attacks once again a viable attack vector.The vulnerability was re-patched in the latest version of Windows, but operators should keep an eye out to ensure that it stays patched in all future versions.

Methods of Mitigation

IP fragmentation attacks are mitigated in several different ways, depending on the type and severity of the attack. Most mitigation methods ensure that malicious data packets never reach their target destinations. The most common one involves inspecting incoming packets for violations of fragmentation rules (e.g., using a router or a secured proxy).

At Incapsula, these inspections are augmented by dedicated DDoS protection hardware. On top of leveraging our on-edge position to observe fragmentation rules, Incapsula also employs blacklisting/whitelisting mechanisms that filter traffic based on factors such as IP reputation and rate patterns. Using these methods, our platform provides complete immunity from all types of IP fragmentation attacks.

Source: incapsula

I am using GUI tool to setup firewall rules for my home computer connected to ADSL (DSL/Cable) network. However, after reboot my rules are not saved. Is there any way I can save and load all firewall rules again?

You need to use the iptables-save command, which is used to dump the contents of an IP Table in easily parseable format to screen. Using I/O-redirection provided by your shell you can save iptables firewall rules to a file.

To restore iptables rules use the iptables-restore command. It is used to restore an IP Tables from data specified from file. Use I/O redirection provided by your shell to read from a file.

Examples: Saving and Restoring Iptables Rules

In this example, save current iptables firewall rules to a file called /root/dsl.fw, enter:
# iptables-save > /root/dsl.fw

To restore iptables rules, enter:
# iptables-restore < /root/dsl.fw

To restore rules automatically upon Linux system reboot add following command to your /etc/rc.local file, enter:
# vi /etc/rc.local

Append the line:
/sbin/iptables-restore < /root/dsl.fw

Save and close the file. Please note that under Red Hat enterprise Linux (RHEL) / CentOS / Fedora Linux you can use following commands to save and restore firewall rules. To Save the rules to /etc/sysconfig/iptables file:
# /etc/init.d/iptables save

To restore the rules from /etc/sysconfig/iptables file:
# /etc/init.d/iptables start

If you are using Debian / Ubuntu Linux open /etc/network/interfaces:
# vi /etc/network/interfaces

Append the line to eth0 section:
post-up iptables-restore
Close and save the file. Reboot the system.

Source: nixCraft