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.
-john
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 10.0.0.0 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.
>