[Dshield] Reporting of Fightback out of order?
Johannes B. Ullrich
jullrich at sans.org
Wed Feb 18 18:26:54 GMT 2004
> Are there other users having the same problem?
I am still changing fightback almost daily. Once I figured out how
I exactly want it to work, I will document it ;-). Some of the
issues you are seeing are due to this transition.
Essentially, there are now two types of fightback:
- Individual email. This is the "traditional fightback". One
e-mail per incident. As you can imagine, this doesn't scale
all that well (we got about 500,000 distinct sources each day,
where at least 100,000 qualify for fightback).
- Bulk notification. I am having some success with bulk
notification. Reports in these system are mailed in daily
mailings. One issue however was that this only works well
if reports are received without much delay (and this is
the part I am working on now...)
One problem with the 'bulk' system is that I can't assign a
fightback report to a particular user. Target IPs are not
released in this system, so all reports received go into it,
even if you don't explicitly participate.
Also, in order to avoid duplicate notification, I need to filter
the fightback requests a user may trigger individually (which is
kind of a third fightback system..)
What this all amounts to is that the current user interface
does not reflect very well how fightback was sent, and if a
response was received. For bulk-fightback, ISPs will not respond
(or just with a single acknowledgment).
One thing I am working on now is a performance based fightback
response system. Overall, I don't care how nice the reply is
we receive based on a fightback. What I am interested in is
how long after a fightback do we still get reports against this
IP. The new system I am working on should reflect this (hopefully).
CTO SANS Internet Storm Center http://isc.sans.org
phone: (617) 837 2807 jullrich at sans.org
contact details: http://johannes.homepc.org/contact.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://www.dshield.org/pipermail/list/attachments/20040218/cb6dfe91/attachment.bin
More information about the list