How to stop a ICMP attack?

Question

We are under a heavy icmp flood attack. Tcpdump shows the result below. Altough we have blocked ICMP with iptables tcpdump still prints icmp packets. I've also attached iptables configuration and "top" result. Is there any thing I can do to completely stop icmp packets?

[root@server downloads]# tcpdump icmp -v -n -nn
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
03:02:47.810957 IP (tos 0x0, ttl  49, id 16007, offset 0, flags [none], proto: ICMP (1), length: 56) 80.227.64.183 > 77.92.136.196: ICMP redirect 94.201.175.188 to host 80.227.64.129, length 36
        IP (tos 0x0, ttl 124, id 31864, offset 0, flags [none], proto: ICMP (1), length: 76) 77.92.136.196 > 94.201.175.188: [|icmp]
03:02:47.811559 IP (tos 0x0, ttl  49, id 16010, offset 0, flags [none], proto: ICMP (1), length: 56) 80.227.64.183 > 77.92.136.196: ICMP redirect 94.201.175.188 to host 80.227.64.129, length 36
        IP (tos 0x0, ttl  52, id 31864, offset 0, flags [none], proto: ICMP (1), length: 76) 77.92.136.196 > 94.201.175.188: [|icmp]
03:02:47.811922 IP (tos 0x0, ttl  49, id 16012, offset 0, flags [none], proto: ICMP (1), length: 56) 80.227.64.183 > 77.92.136.196: ICMP redirect 94.201.175.188 to host 80.227.64.129, length 36
        IP (tos 0x0, ttl 122, id 31864, offset 0, flags [none], proto: ICMP (1), length: 76) 77.92.136.196 > 94.201.175.188: [|icmp]
03:02:47.812485 IP (tos 0x0, ttl  49, id 16015, offset 0, flags [none], proto: ICMP (1), length: 56) 80.227.64.183 > 77.92.136.196: ICMP redirect 94.201.175.188 to host 80.227.64.129, length 36
        IP (tos 0x0, ttl 126, id 31864, offset 0, flags [none], proto: ICMP (1), length: 76) 77.92.136.196 > 94.201.175.188: [|icmp]
03:02:47.812613 IP (tos 0x0, ttl  49, id 16016, offset 0, flags [none], proto: ICMP (1), length: 56) 80.227.64.183 > 77.92.136.196: ICMP redirect 94.201.175.188 to host 80.227.64.129, length 36
        IP (tos 0x0, ttl 122, id 31864, offset 0, flags [none], proto: ICMP (1), length: 76) 77.92.136.196 > 94.201.175.188: [|icmp]
03:02:47.812992 IP (tos 0x0, ttl  49, id 16018, offset 0, flags [none], proto: ICMP (1), length: 56) 80.227.64.183 > 77.92.136.196: ICMP redirect 94.201.175.188 to host 80.227.64.129, length 36
        IP (tos 0x0, ttl 122, id 31864, offset 0, flags [none], proto: ICMP (1), length: 76) 77.92.136.196 > 94.201.175.188: [|icmp]
03:02:47.813582 IP (tos 0x0, ttl  49, id 16020, offset 0, flags [none], proto: ICMP (1), length: 56) 80.227.64.183 > 77.92.136.196: ICMP redirect 94.201.175.188 to host 80.227.64.129, length 36
        IP (tos 0x0, ttl  52, id 31864, offset 0, flags [none], proto: ICMP (1), length: 76) 77.92.136.196 > 94.201.175.188: [|icmp]
03:02:47.814092 IP (tos 0x0, ttl  49, id 16023, offset 0, flags [none], proto: ICMP (1), length: 56) 80.227.64.183 > 77.92.136.196: ICMP redirect 94.201.175.188 to host 80.227.64.129, length 36
        IP (tos 0x0, ttl 120, id 31864, offset 0, flags [none], proto: ICMP (1), length: 76) 77.92.136.196 > 94.201.175.188: [|icmp]
03:02:47.814233 IP (tos 0x0, ttl  49, id 16024, offset 0, flags [none], proto: ICMP (1), length: 56) 80.227.64.183 > 77.92.136.196: ICMP redirect 94.201.175.188 to host 80.227.64.129, length 36
        IP (tos 0x0, ttl 120, id 31864, offset 0, flags [none], proto: ICMP (1), length: 76) 77.92.136.196 > 94.201.175.188: [|icmp]
03:02:47.815579 IP (tos 0x0, ttl  49, id 16025, offset 0, flags [none], proto: ICMP (1), length: 56) 80.227.64.183 > 77.92.136.196: ICMP redirect 94.201.175.188 to host 80.227.64.129, length 36
        IP (tos 0x0, ttl  50, id 31864, offset 0, flags [none], proto: ICMP (1), length: 76) 77.92.136.196 > 94.201.175.188: [|icmp]
03:02:47.815726 IP (tos 0x0, ttl  49, id 16026, offset 0, flags [none], proto: ICMP (1), length: 56) 80.227.64.183 > 77.92.136.196: ICMP redirect 94.201.175.188 to host 80.227.64.129, length 36
        IP (tos 0x0, ttl  50, id 31864, offset 0, flags [none], proto: ICMP (1), length: 76) 77.92.136.196 > 94.201.175.188: [|icmp]
03:02:47.815890 IP (tos 0x0, ttl  49, id 16027, offset 0, flags [none], proto: ICMP (1), length: 56) 80.227.64.183 > 77.92.136.196: ICMP redirect 94.201.175.188 to host 80.227.64.129, length 36

iptables configuration:

[root@server etc]# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ofis       tcp  --  anywhere             anywhere            tcp dpt:mysql
ofis       tcp  --  anywhere             anywhere            tcp dpt:ftp
DROP       icmp --  anywhere             anywhere

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
DROP       icmp --  anywhere             anywhere

Chain ofis (2 references)
target     prot opt source               destination
ACCEPT     all  --  OUR_OFFICE_IP        anywhere
DROP       all  --  anywhere             anywhere

top:

top - 03:12:19 up 400 days, 15:43,  3 users,  load average: 1.49, 1.67, 2.61
Tasks: 751 total,   3 running, 748 sleeping,   0 stopped,   0 zombie
Cpu(s):  8.2%us,  1.0%sy,  0.0%ni, 87.9%id,  2.1%wa,  0.1%hi,  0.7%si,  0.0%st
Mem:  32949948k total, 26906844k used,  6043104k free,  4707676k buffers
Swap: 10223608k total,        0k used, 10223608k free, 14255584k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
   36 root      39  19     0    0    0 R 100.8  0.0  17:03.56 ksoftirqd/11
10552 root      15   0 11408 1460  676 R  5.7  0.0   0:00.04 top
 7475 lighttpd  15   0  304m  22m  15m S  3.8  0.1   0:05.37 php-cgi
 1294 root      10  -5     0    0    0 S  1.9  0.0 380:54.73 kjournald
 3574 root      15   0  631m  11m 5464 S  1.9  0.0   0:00.65 node
 7766 lighttpd  16   0  302m  19m  14m S  1.9  0.1   0:05.70 php-cgi
10237 postfix   15   0 52572 2216 1692 S  1.9  0.0   0:00.02 scache
    1 root      15   0 10372  680  572 S  0.0  0.0   0:07.99 init
    2 root      RT  -5     0    0    0 S  0.0  0.0   0:16.72 migration/0
    3 root      34  19     0    0    0 S  0.0  0.0   0:00.06 ksoftirqd/0
    4 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 watchdog/0
    5 root      RT  -5     0    0    0 S  0.0  0.0   1:10.46 migration/1
    6 root      34  19     0    0    0 S  0.0  0.0   0:01.11 ksoftirqd/1
    7 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 watchdog/1
    8 root      RT  -5     0    0    0 S  0.0  0.0   2:36.15 migration/2
    9 root      34  19     0    0    0 S  0.0  0.0   0:00.19 ksoftirqd/2
   10 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 watchdog/2
   11 root      RT  -5     0    0    0 S  0.0  0.0   3:48.91 migration/3
   12 root      34  19     0    0    0 S  0.0  0.0   0:00.20 ksoftirqd/3
   13 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 watchdog/3

uname -a

[root@server etc]# uname -a
Linux thisis.oursite.com 2.6.18-238.19.1.el5 #1 SMP Fri Jul 15 07:31:24 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux

arp -an

[root@server downloads]# arp -an
? (77.92.136.194) at 00:25:90:04:F0:90 [ether] on eth0
? (192.168.0.2) at 00:25:90:04:F0:91 [ether] on eth1
? (77.92.136.193) at 00:23:9C:0B:CD:01 [ether] on eth0

I've never used tcpdump so I'm a little lost looking at the output but are you sure that the ICMP redirects are not in response to your server trying to connect to, ping, or traceroute to 94.201.175.188? — joeqwerty, Oct 01 '12 at 02:30

score 8 · Accepted Answer · answered Oct 01 '12 at 00:11

8

Contact your ISP and give them this information. They'll need to drop the traffic on the backbone. Once the traffic hits your firewall, the resources are already being consumed on your end. The only way to stop this is to drop it on the backbone.

answered Oct 01 '12 at 00:11

MDMarra

100,183
32
195
326

score 2 · Answer 2 · answered Oct 01 '12 at 00:25

2

These appear to be ICMP Redirects.

These are typically only on a local network segment.

Which IP is yours? 80.227.64.183 > 77.92.136.196: ICMP redirect 94.201.175.188 to host 80.227.64.129

I read (possibly incorrectly) this to say that a gateway on your network segment 80.227.64.183 is telling you (77.92.136.196) to reach 94.201.175.188 via 80.227.64.129??

It looks like there's likely some overlapping VLAN traffic on your network segment. (what do you arp tables look like? arp -an)

answered Oct 01 '12 at 00:25

Joel K

5,765
2
29
34

77.92.136.196 is our ip. But I don't think that redirect messages are legit. We recevice hundreds of thousands of them every minute. – cumhur onat Oct 01 '12 at 00:35
I added arp -an result to the bottom of the question – cumhur onat Oct 01 '12 at 00:36

score 1 · Answer 3 · answered Oct 01 '12 at 00:38

You most likely don't want to accept ICMP redirects on your border router. I wouldn't recommend dropping ICMP altogether, though. Try adding these rules:

iptables -N ICMP
iptables -A ICMP -p icmp --icmp-type destination-unreachable -j ACCEPT
iptables -A ICMP -p icmp --icmp-type source-quench -j ACCEPT
iptables -A ICMP -p icmp --icmp-type parameter-problem -j ACCEPT
iptables -A ICMP -p icmp --icmp-type time-exceeded -j ACCEPT
iptables -A ICMP -p icmp --icmp-type echo-reply -j ACCEPT
iptables -A ICMP -p icmp --icmp-type echo-request -j ACCEPT

iptables -A INPUT -p icmp -j ICMP

And as @MDMarra already said, you probably want to contact your ISP about this.

Actually, no, I won't. `fragmentation-needed` messages are covered by the rule for ICMP type 3 `destination-unreachable`. And there are perfectly valid reasons for not allowing just any kind of ICMP traffic into your LAN (or out of it for that matter). — Ansgar Wiechers, Oct 01 '12 at 01:00

score 0 · Answer 4 · edited Oct 01 '12 at 03:31

0

Go to /etc/csf/csf.conf

On ICMP ping state to 0 and forbid foreign ping .

edited Oct 01 '12 at 03:31

EEAA

108,414
18
172
242

answered Oct 01 '12 at 00:24

Nemanja Djuric

19
4

Forgot to mark please install CSF Firewall first if you dont have. – Nemanja Djuric Oct 01 '12 at 00:25
1

How is this going to help? If this is a deflection attack, then the ICMP traffic will already be filling the pipe as it hits the software firewall. This will cut down on some of the traffic, since the server will not respond, but the inbound traffic will still consume resources. This isn't going to solve anything against any decent sized attack. – MDMarra Oct 01 '12 at 00:27
As per any half decent DoS attack, there is no need for the target system to respond for the attack to be effective. Blocking or dropping the traffic at the firewall simply means the firewall is now the target, instead of the server. The end result is the same. – John Gardeniers Oct 01 '12 at 06:19

How to stop a ICMP attack?

4 Answers4