[Dshield] Bad Dest IP reported using CVTWIN and RouterLog

John Duksta john at duksta.org
Fri Mar 14 16:04:53 GMT 2003

I agree that the Src IP/Port and Dest Port are the important data to 
capture. As David inferred below, I was thinking along the lines of 
having the correct data for FightBack. I also agree that getting the 
correct destination address in place could be difficult to do 
automatically and does introduce much opportunity for user error if 
allowed to be a manual entry field.

I just like to make sure that the data I am reporting is accurate.

Thanks for the feedback.


Wayne Larmon wrote:
> 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
> DShield.org
>>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