[ping flood] iptables permanent settings

soundlord · September 23, 2016, 9:19pm

Greetings !!

I wanted to do a little experience today with my students concerning the possibility (that is useless indeed) of mashing down the performance of a network using a flood of icmp request paquets throught the ping utility in the entire network (broadcast with option -f and -b).

The network is composed esentially of hubs with 15 computers using 13.2 opensuse. All the hubs are connected at the end of the chain to a cisco router.

My question is: this is possible using iptables to (for each computer connected to the different hubs – there are three hubs connected to 4 to 5 computers) limit the casualties of a ping flood but I don’t know how to set the changes done on iptables permanently.

Which script I have to modify to have the iptables rules set up at boot when the firewall is set up ?

For now, I have (default):


Chain INPUT (policy DROP)

ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             ctstate ESTABLISHED
ACCEPT     icmp --  anywhere             anywhere             ctstate RELATED
input_ext  all  --  anywhere             anywhere            
LOG        all  --  anywhere             anywhere             limit: avg 3/min burst 5 LOG level warning tcp-options ip-options prefix "SFW2-IN-ILL-TARGET "
DROP       all  --  anywhere             anywhere


Chain input_ext (1 references)

DROP       all  --  anywhere             anywhere             PKTTYPE = broadcast


Chain forward_ext (2 references)

ACCEPT     icmp --  anywhere             anywhere             ctstate RELATED,ESTABLISHED icmp echo-reply
ACCEPT     icmp --  anywhere             anywhere             ctstate RELATED,ESTABLISHED icmp destination-unreachable
ACCEPT     icmp --  anywhere             anywhere             ctstate RELATED,ESTABLISHED icmp time-exceeded
ACCEPT     icmp --  anywhere             anywhere             ctstate RELATED,ESTABLISHED icmp parameter-problem
ACCEPT     icmp --  anywhere             anywhere             ctstate RELATED,ESTABLISHED icmp timestamp-reply
ACCEPT     icmp --  anywhere             anywhere             ctstate RELATED,ESTABLISHED icmp address-mask-reply
ACCEPT     icmp --  anywhere             anywhere             ctstate RELATED,ESTABLISHED icmp protocol-unreachable
ACCEPT     icmp --  anywhere             anywhere             ctstate RELATED,ESTABLISHED icmp redirect
DROP       all  --  anywhere             anywhere             PKTTYPE = multicast
DROP       all  --  anywhere             anywhere             PKTTYPE = broadcast
LOG        tcp  --  anywhere             anywhere             limit: avg 3/min burst 5 tcp flags:FIN,SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix "SFW2-FWDext-DROP-DEFLT "
LOG        icmp --  anywhere             anywhere             limit: avg 3/min burst 5 LOG level warning tcp-options ip-options prefix "SFW2-FWDext-DROP-DEFLT "
LOG        udp  --  anywhere             anywhere             limit: avg 3/min burst 5 ctstate NEW LOG level warning tcp-options ip-options prefix "SFW2-FWDext-DROP-DEFLT "
DROP       all  --  anywhere             anywhere


Chain reject_func (0 references)

REJECT     tcp  --  anywhere             anywhere             reject-with tcp-reset
REJECT     udp  --  anywhere             anywhere             reject-with icmp-port-unreachable
REJECT     all  --  anywhere             anywhere             reject-with icmp-proto-unreachable

I saw many ways to limit the casualties but I don’t know how make the changes permanent.
The idea is: if each computer on the local network dropped the broadcast icmp requests it may limit the casualties as the broadcast consists to send icmp paquets to all computers those have iptables running. As we pass thru some hubs the broadcats are not filtered.

The command used was ping -f 192.168.0.0 -b using root account…

tsu2 · September 26, 2016, 7:11pm

Your post is interesting and somewhat instructive about DDOS in general, of which “Ping Flood” or “ICMP Flood” is only one variation (you can search “DDOS” to get listings of various other similar attacks using various protocols and methods to evade filters like what you’re trying to create).

These attacks have been around for a very long time, but AFAIK the mitigation methods have not changed much although the tools to recognize, analyze and perform actions are far better today.

First (and again AFAIK), what you’re trying to do has been tried since the very first attacks, and might work against a single identifiable source if the traffic from that source is unique enough. But, if you are suffering from a DDOS, the traffic becomes so chaotic that you may not see uniquely identifiable characteristics and so any filters you implement can only be “best effort” still permitting some malicious traffic through while also possibly blocking legitimate traffic… And, unfortunately if you filter <only> on a particular protocol property (like time interval) that’s all that can be done.

But, if you had a truly capable tool that could aggregate a number of characteristics like interval or events related to specific IP addresses, geographic location and a lot more, then you can start building a profile of the malicious source(s) which might provide a basis for action (like blocking IP addresses). But, even then a malicious attacker could be forging his IP address, or in the case of a DNS DDOS could be creating a “reflection” victimizing some poor innocent.

So, at least in the case of the very big, commercial websites they might contract with a major Content Provider network with enormous bandwidth so that in this “arms war” they have more capacity than the botnet so have more time to identify, analyze and deny the malicious sources.

HTH,
TSU

soundlord · September 27, 2016, 12:36pm

I want to say thank you for your enlightments.

I’m just a little frustrated reading the different sources I have concerning the subject that was first “how to add rules at boot time to iptables ?”

I have to write a script that will add rules at boot time… I only did once in my life.

It seems opensuse doesn’t grant the right to load rules at boot as other distributions seems to grant.
There is no efficient GUI or TUI frontends that talks directly to iptables in standard for the distribution (I may launch the project).

Yast is sufficient for “general” rules but when we want to be more precise or specific there is no comfort to add these rules.

I may go back once I had something working for my point of view.

With my students we tried to turn our computers in the local network into “switches” to limit the impact of the “ping/icmp flood”… I don’t know if this is a good idea.

soundlord · September 27, 2016, 10:20pm

I created a service called iptables.service, here is the description:


[Unit]
Description=additional iptables rules [tests]
After=SuSEfirewall2.service

[Service]
Type=oneshot
ExecStart=/usr/bin/iptables

[Install]
WantedBy=multi-user.target

The service has to be launched AFTER the suse firewall service otherwise the iptables will be flushed and all the rules gone with.

Concerning the script linked with I tried on my local network and it seems it is not working… the kernel seems to never drop the packets.
As I’m a real beginner in iptables rules maybe I’m not efficient or there is something fundamental I did not understood.


#! /bin/bash

iptables-save > /etc/security/backup_$(date +%Y_%m_%d).iptables
iptables -N pingflood
iptables -R INPUT 3 -p icmp -m conntrack --ctstate RELATED -j pingflood
iptables -A pingflood -p icmp --icmp-type address-mask-request -j DROP
iptables -A pingflood -p icmp --icmp-type timestamp-request -j DROP
iptables -A pingflood -p icmp --icmp-type 8 -m limit --limit 1/minute --limit-burst 1 -j DROP
iptables -A pingflood -p icmp -j ACCEPT

I tried to express this idea:

first back up the current iptables rules to a file.
create a new chain called pingflood
replace the rule number 3 that is accepting all icmp packets (-j ACCEPT) I want to first filter them before accepting them so I “change” the chain from ACCEPT to pingflood


Extract of command: iptables --list-rules INPUT

*-A INPUT -p icmp -m conntrack --ctstate RELATED -j **ACCEPT***

in the pingflood chain I try to drop all the icmp packets with given types (as seen on some security sites) without any knowledge of what is icmp address-mask-request or timestamp-request (I have to dig)

if none of the packets match with all the previous rules these ones step up to the line that I was believing efficient to drop the flood:


iptables -A pingflood -p icmp --icmp-type 8 -m limit --limit 1/minute --limit-burst 1 -j DROP

In my vision, if the packet is a icmp echo request and there is more than one packet of the same type and the request happens more than one time a minute (in the case of a flood it would be the case) then drop it (discard it).

It seems that is not working as expected :{

tsu2 · September 30, 2016, 3:02am

On openSUSE,
You can set up iptables using the SUSE FW.
SUSE FW is designed to remove the User from knowing how to manipulate iptables rules directly by offering a number of standard options, although you can also create custom rules… and depending on what you are trying to do may receive some guidance.

IIRC because SUSE FW exists, trying to create an alternative iptables.service like what you appear to have tried to do will not work (requires disabling and perhaps even removal of SUSE FW).

SUSE FW is only our standard tool to manage iptables, you can also find others in the OSS (main repository).

YAST can be accessed by GUI, either from a Desktop Menu or from a command line

sudo yast2

or as a TUI

sudo yast

The SUSE FW configuration is fairly self-explanatory, for what you are trying to do it sounds like you would create a custom rule because your creation isn’t likely a standard option.

SUSE FW is generally configured to start on boot, although you can configure to do otherwise.

TSU