[Spread-users] Spread broadcast spam?

[Jan Mulders]

Hello all.

I'm setting up Spread in a datacenter environment where I have multiple
boxes, on multiple subnets, all needing to transmit to one machine (fdc2)
for the purpose of collecting logs.

I recently recieved a ticket claiming that one of my log transmitting
machines - the only active one - was performing a broadcast DDOS attack on
its entire subnet. Upon further investigation, Spread was located as the
culprit.

Here is my spread configuration file for your reference.

Spread_Segment xx.yy.zz.255:4803
{
        fdc2    xx.yy.zz.108
        fdc33   xx.yy.zz.175
}
Spread_Segment aa.bb.cc.255:4803
{
        fdc27   aa.bb.cc.241
}

DebugFlags = { PRINT EXIT }
EventLogFile = /var/log/spread.log
#EventLogFile = /var/log/spread_%h.log
EventTimeStamp = "[%a %d %b %Y %H:%M:%S]"
DangerousMonitor = false
#SocketPortReuse = AUTO
RuntimeDir = /var/run/spread
DaemonUser = spread
DaemonGroup = spread

fdc33 is sending the logs, and fdc2 is recieving the logs.

Here is the output of spmonitor:

Monitor> Monitor: send status query

============================
Status at fdc33 V 3.17. 4 (state 1, gstate 1) after 1016 seconds :
Membership  :  2  procs in 1 segments, leader is fdc2
rounds   :    2383      tok_hurry :    1991     memb change:       1
sent pack:    6027      recv pack :       2     retrans    :    5956
u retrans:    5956      s retrans :       0     b retrans  :       0
My_aru   :    6029      Aru       :    6029     Highest seq:    6029
Sessions :       1      Groups    :       2     Window     :      60
Deliver M:    6025      Deliver Pk:    6029     Pers Window:      15
Delta Mes: -2969904     Delta Pack:       0     Delta sec  : -112811
==================================

Monitor>
============================
Status at fdc2 V 3.17. 4 (state 1, gstate 1) after 113837 seconds :
Membership  :  2  procs in 1 segments, leader is fdc2
rounds   :    2383      tok_hurry : 2435800     memb change:      13
sent pack:      15      recv pack : 5864749     retrans    :      13
u retrans:      13      s retrans :       0     b retrans  :       0
My_aru   :    6029      Aru       :    6029     Highest seq:    6029
Sessions :       1      Groups    :       2     Window     :      60
Deliver M: 2975929      Deliver Pk: 3024892     Pers Window:      15
Delta Mes: 2969904      Delta Pack:       0     Delta sec  :  112821
==================================

When I run 'tcpdump -i eth0 -n src xx.yy.zz.175 or dst xx.yy.zz.175' and run
spflooder on fdc33, I get the following output on a machine within the
xx.yy.zz subnet, which is not listed in the Spread configuration:

14:27:04.175277 IP xx.yy.zz.175.32877 > xx.yy.zz.255.4803: UDP, length 1112
14:27:04.175379 IP xx.yy.zz.175.32877 > xx.yy.zz.255.4803: UDP, length 1112
14:27:04.175473 IP xx.yy.zz.175.32877 > xx.yy.zz.255.4803: UDP, length 1112
14:27:04.175574 IP xx.yy.zz.175.32877 > xx.yy.zz.255.4803: UDP, length 1112
14:27:04.175669 IP xx.yy.zz.175.32877 > xx.yy.zz.255.4803: UDP, length 1112
14:27:04.175762 IP xx.yy.zz.175.32877 > xx.yy.zz.255.4803: UDP, length 1112
14:27:04.175857 IP xx.yy.zz.175.32877 > xx.yy.zz.255.4803: UDP, length 1112
14:27:04.175963 IP xx.yy.zz.175.32877 > xx.yy.zz.255.4803: UDP, length 1112
14:27:04.176149 IP xx.yy.zz.175.32877 > xx.yy.zz.255.4803: UDP, length 1192

So, my question is this:

Why is Spread spamming the entire subnet?

Why doesn't it list 'b retrans' as a number more than 0 in spmonitor? Why
doesn't Spread notice that Multicast and Broadcast don't work, and fall back
to Unicast on a per-session rather than (presumably) per-packet basis?

Is there an option to change this behaviour?

Thanks,

Jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.spread.org/pipermail/spread-users/attachments/20070618/258c00cb/attachment.html