[Dshield] Bad Dest IP reported using CVTWIN and RouterLog

Wayne Larmon wlarmon at dshield.org
Fri Mar 14 13:00:23 GMT 2003

The reason why our clients don't allow the user to supply a source IP that
doesn't appear in the log is because there is too much opportunity for
mistakes.  A lot of users are assigned a dynamic IP from their ISP's DHCP
server so they would probably have a different IP each time they connect.
We don't know any relible method of tracking the external IP address.

Especially for the period before CVTWIN was installed.  The first log that
is submitted will cover several days, during which there might have been
multiple DHCP IP address assignments.  So we have adopted a policy that our
clients will only extract destination IPs if they are in a log line.

Wayne Larmon

> At 05:27 PM 3/13/03 -0500, John Duksta wrote:
> >It all works quite nicely, except for the fact that CTVWIN puts my local
> >machine's IP address as the destination IP for the attacks. Since I'm
> >running RFC 1918 addressing on my internal network, this means that all
> >my reports are going to show a dest IP of 192.168.x.x instead of the
> >AT&T/Comcast IP that is assigned to the Barricade.
> >
> >Who should I contact about submitting a RFE to CVTWIN to hopefully fix
> >this issue?
> I've been submitting logs with addresses since 6/01 and don't
> really see why my destination IP matters.  I suppose it's
> possible to parse
> the SMTP headers for most CTVWIN submissions and infer a
> routeable address,
> but for what purpose?  If my reports are used for fightback, and their
> destination IP really becomes an issue, Johannes or someone at DShield can
> always ask what my IP is.  Whether I can nail down a DHCP'd address on a
> given day is a toss up, but worst-case I can't-so what?  My reports are
> unlikely to be the sole cause for a fightback and unlikely to matter if my
> reports have to be discarded.
> The focus is on the attackers.  IP's can be spoofed but if hundreds of
> reporters report an attacker's IP, chances are it's not spoofed; no
> guarantee, but chances are....  If a few hundred of us report a host as
> CodeRed.F infected, chances are it is.  Knowing my IP really
> doesn't matter
> to whoever is responsible for that host.  Cleaning it up is.  I just don't
> see what the payoff is to trying to parse SMTP headers for an IP
> that could
> have been manipulated by the SMTP server, a proxy or a firewall
> between the
> submitter and DShield.

More information about the list mailing list