IGMP broadcasts. Why are SAIX doing this?

Karnaugh

Banned
Joined
Jul 23, 2003
Messages
1,575
Reaction score
4
Location
Durban, South Africa
On the 28th of November I noticed the security log files on azrael rotating at an alarming rate. When I viewed the security logs I noticed large amounts of multicast data being blocked. This surprised me as it was coming from my own RAS, ndn-ip-nas-1.telkom-ipnet.co.za.

Nov 28 12:53:11 azrael kernel: ipfw: 33910 Deny P:2 155.239.193.254 224.0.0.1 in via tun0
Nov 28 12:53:29 azrael kernel: ipfw: 33910 Deny P:103 155.239.193.254 224.0.0.13 in via tun0
Nov 28 12:53:59 azrael kernel: ipfw: 33910 Deny P:103 155.239.193.254 224.0.0.13 in via tun0

Closer inspection of the packets revealed they were IGMP router multicasts.

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote">18:45:06.323780 155.239.193.254 &gt; 224.0.0.1: igmp query v2 [tos 0xc0] [ttl 1]
0x0000 45c0 001c bccd 0000 0102 be63 9bef c1fe E..........c....
0x0010 e000 0001 1164 ee9b 0000 0000 .....d......
18:45:22.343766 155.239.193.254 &gt; 224.0.0.13: pim v2 Hello (Hold-time 1m45s) (Genid: 0x000006c0) (bidir-capable) (DR-Priority: 1) (State Refresh Capable; v1) [tos 0xc0] [ttl 1]
0x0000 45c0 003a c933 0000 0167 b16e 9bef c1fe E..:.3...g.n....
0x0010 e000 000d 2000 d774 0001 0002 0069 0014 .......t.....i..
0x0020 0004 0000 06c0 0016 0000 0013 0004 0000 ................
0x0030 0001 0015 0004 0100 0000 .......... <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
I checked this information with various other people who said they had had this for a long time. This surprised me for a few reasons.

1) I was receiving it at a rate of 3 to 4 packets every minute (Resulting in noticeable decreases in throughput on analysis with trafshow). Most people's logs only showed 1 packet every minute at most.
2) This had to have been a new policy (or mistake) because I have had the same set of firewall logs for over 6 months and I'm very sure I would have noticed that level of log activity.

I had dropped just over 12000 packets that day, when I decided to contact SAIX to find the reason for this.

SAIX replied that this was "just normal Multicast".

This leaves me with some unanswered questions. For what purpose are SAIX broadcasting IGMP to their dialup and ADSL users?

From what I know, this should *never* happen and is recent. It also coincidently coincides with peoples complaints about spiky latency.

<hr noshade size="1">iActive internet services
http://www.iactive.co.za
 
<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote">
Dear Sir/Madam,
Your SAIX Fault/Query has been resolved. The resolution description
follows:
Good day, Multicast is not broadcasted but requested. The reason for the
Multicast on the POP's is For BigBrother and such streams. You either decide
to join the stream or not, and your Computer decide how often it will
request an 'join' to the stream. The stream is always available. We never
remove the configurations off the routers. Regards Thys.
Thank-you
SAIX HelpDesk
0800 222 772
<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

Well thats encouraging. My FreeBSD firewall (even when isolated from my network) is watching BigBrother apparently.

Code:
02:27:45.313348 155.239.193.254 &gt; 224.0.0.13: pim v2 Hello (Hold-time 1m45s)
(Genid: 0x00000059) (bidir-capable) (DR-Priority: 1) (State Refresh Capable;
v1) [tos 0xc0]  [ttl 1]
0x0000   45c0 003a 1ca5 0000 0167 5dfd 9bef c1fe        E..:.....g].....
0x0010   e000 000d 2000 dddb 0001 0002 0069 0014        .............i..
0x0020   0004 0000 0059 0016 0000 0013 0004 0000        .....Y..........
0x0030   0001 0015 0004 0100 0000                       ..........
02:28:10.694194 155.239.193.254 &gt; 224.0.0.1: igmp query v2 [tos 0xc0]  [ttl
1]
0x0000   45c0 001c 26b7 0000 0102 547a 9bef c1fe        E...&.....Tz....
0x0010   e000 0001 1164 ee9b 0000 0000                  .....d......
02:28:14.943428 155.239.193.254 &gt; 224.0.0.13: pim v2 Hello (Hold-time 1m45s)
(Genid: 0x00000059) (bidir-capable) (DR-Priority: 1) (State Refresh Capable;
v1) [tos 0xc0]  [ttl 1]
0x0000   45c0 003a 2879 0000 0167 5229 9bef c1fe        E..:(y...gR)....
0x0010   e000 000d 2000 dddb 0001 0002 0069 0014        .............i..
0x0020   0004 0000 0059 0016 0000 0013 0004 0000        .....Y..........
0x0030   0001 0015 0004 0100 0000                       ..........
02:28:44.063543 155.239.193.254 &gt; 224.0.0.13: pim v2 Hello (Hold-time 1m45s)
(Genid: 0x00000059) (bidir-capable) (DR-Priority: 1) (State Refresh Capable;
v1) [tos 0xc0]  [ttl 1]
0x0000   45c0 003a 33d0 0000 0167 46d2 9bef c1fe        E..:3....gF.....
0x0010   e000 000d 2000 dddb 0001 0002 0069 0014        .............i..
0x0020   0004 0000 0059 0016 0000 0013 0004 0000        .....Y..........
0x0030   0001 0015 0004 0100 0000

One can see quite clearly that my PC has not even sent any data at all, let alone IGMP/PIMv2 requests between the packets.

<hr noshade size="1">iActive internet services
http://www.iactive.co.za
 
Not to mention all the other traffic one gets without asking for it. I wonder what they'd respond to issues such as portscanning.

There are a few IGMP attacks out there, this might quite possible be some compromised system scanning. The source adresses are quite interesting, and as you said, it's odd that it even gets into your PPP channel. Most routers would drop it.
 
I'm also seeing these on my firewall. IGMP is used to join, or leave multicast groups, so his explanation does carry some value.

Might just be regular polling by the routers to see if there are any upstream nodes that provide services.
 
For reference, I'm getting only one "Hello" packet (destination 224.0.0.1) every minute, nothing like the flood that Karnaugh is getting.

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote">There are a few IGMP attacks out there, this might quite possible be some compromised system scanning. The source adresses are quite interesting, and as you said, it's odd that it even gets into your PPP channel. Most routers would drop it.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
That's extremely unlikely. In fact, the only possible source for those packets (regardless of the source IP) is the router; there's no way a packet with a destination of 224.0.0.1 or similar could get delivered across the internet; just like the only person that could send you a packet with a destination IP of 10.0.0.1 is someone else on your local network (modulo VPNs and tunnels and whatnot, obviously)

mithrandi
 
<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote">Might just be regular polling by the routers to see if there are any upstream nodes that provide services<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

Well that's usualy its use, but in actual fact their statement is not correct. IIRC steaming video does not use multicast over the internet.

It holds no value for a dialup/ADSL customer to recive such data. If a computer does not respond to 3 join advertisements the the router is supposed stop sending them.

It seems clearly this is a router configuration error, especaily the PIM packets.

SAIX claim this is normal and they wont change the configuration.

So there you go folks. Oh magic conch, what should we do? "Nothing!", Praise the magic conch shell!

<hr noshade size="1">iActive internet services
http://www.iactive.co.za
 
FYI...

SAIX:
<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote">This is not a broadcast.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote">You either decide to join the stream or not, and your Computer decide how often it will request an 'join' to the stream<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

but...

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote">224.0.0.1 All Systems on this Subnet [RFC1112,JBP]<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

SAIX:
<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote">just normal Multicast<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

Ya...
<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote">224.0.0.13 All PIM Routers [Farinacci]<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

Only thing I can explain from my side is Zebra IPv6 routing, and GRE 4in4 tunnelling, none of which broadcasts with PIM or would join multicast sessions. Otherwise, all is firewalled - thus not so possible that I just suddenly start receiving IGMP.

Multicast address assignments courteousy of IANA http://www.iana.net/assignments/multicast-addresses

<hr noshade size="1">iActive internet services
http://www.iactive.co.za
 
Yeah, the "Hello" packets are possibly understandable, but there's absolutely no reason to get packets directed at other routers.

mithrandi
 
<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote">I wonder what they'd respond to issues such as portscanning.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

Well, one run in with them I had they refused to reveal the identity of the atacker from their network because they had "could not find any logs for that time period".

Other times its been fine. Like when ADSL first rolled out, one of their wonderfull customers decided to use his line for sending "ATH+++" DoS attacks. Kudos to Baspnet as well for taking care of that on their side.

Their service and response times etc honestly ranges 50/50 from awesome to downright shocking.

<hr noshade size="1">iActive internet services
http://www.iactive.co.za
 
Bah. Going after someone sending ATH+++ "DoS" attacks is just a stupid waste of time; rather educate your customers on how to prevent the attack, then there's no DoS to worry about.

mithrandi
 
<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote"><i>Originally posted by mithrandi</i>
<br />
<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote">There are a few IGMP attacks out there, this might quite possible be some compromised system scanning. The source adresses are quite interesting, and as you said, it's odd that it even gets into your PPP channel. Most routers would drop it.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
That's extremely unlikely. In fact, the only possible source for those packets (regardless of the source IP) is the router; there's no way a packet with a destination of 224.0.0.1 or similar could get delivered across the internet; just like the only person that could send you a packet with a destination IP of 10.0.0.1 is someone else on your local network (modulo VPNs and tunnels and whatnot, obviously)
<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

This is the same as ICMP broadcast traffic of olden days. If badly configured, a router can launch just such an IGMP DOS attack against nodes that live underneath it, and it might be initiated upstream. Win98, and Win2k also have vulnerabilities.

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote">
Description
------------

The IGMP report suppression mechanism can be exploited for launching
an insider denial of service attack against a host connected to a
Multicast group.

Instead of sending a IGMP membership report to the Multicast group
ethernet address as is the norm, an attacker sends the report addressed to
the victim's ethernet address. The victim host on seeing the IGMP report
suppresses its own IGMP report as per the IGMP standard. The querier
router then never gets an IGMP report effectively cutting off traffic
from that group.
<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

I'm wondering whether what Karnaugh wasn't possibly the victim of such an attack, considering the amount of traffic he reported. The few odd packets here and there is fine, but it sounds like he received quite a lot of this in a short space of time.
 
<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote">If badly configured, a router can launch just such an IGMP DOS attack against nodes that live underneath it, and it might be initiated upstream.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
Initiated upstream, yes, but that precise packet can only be generated by the router, and thus could only result from a !@#$-up on SAIX's part.

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">quote:<hr height="1" noshade id="quote">I'm wondering whether what Karnaugh wasn't possibly the victim of such an attack, considering the amount of traffic he reported. The few odd packets here and there is fine, but it sounds like he received quite a lot of this in a short space of time.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
That DoS attack can only be performed across the local network; the only way to get the packets delivered is sending directly across the network to the victim's ethernet address (as your quote states). The point of the IGMP DoS you quoted is to effectively disconnect a host from a multicast group it is a member of, not to flood the host; it is a DoS specifically against multicast services on that host, not just using up the host's bandwidth.

In any event, the problem is SAIX's fault, and only SAIX can solve it.

mithrandi

[EDIT: Note to self, 'reply' != 'quote']
 
I was contacted by a guy from SAIX today, seems they have fixed the problem.. [:D][:D][:D]

Dont really care what it was, just happy its now sorted.

Code:
Rule Number    Packets    Bytes   Rule
33910          0          0       deny igmp from any to any via tun0
34010          0          0       deny pim from any to any via tun0


<hr noshade size="1">
"Since light travels faster than sound, people appear bright until you hear them speak."

NetLink Research
 
Top
Sign up to the MyBroadband newsletter
X