Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

I think I was sniffed?



Since I answer the "abuse" account for various ISPs and domains, you might
be interested to know that I would regard this as VERY unlikely evidence
of a password compromise.  It is fairly difficult to determine exactly who
had control of an IP address when a message was sent.  Assuming that the
spammer did not relay the message through the ISP's own mail server, which
seems likely, the only timestamp evidence on the header is affixed by the
recipient.  That means that the best estimate of the time of the actual
event is absolutely dependent upon the accuracy with which the recipient
machine maintains its time of day clock.

Now, on the one extreme, there are fanatics like me who run NTP daemons on
all of our mail servers and keep every machine synchronized within a few
milliseconds of its peers.  If you are looking at a "Received" timestamp
from a mail server that I administer, you can be sure that it is dead
accurate to far better than the stated one-second resolution, and you can
also be certain that the timezone is correct.

An analogous problem arises in connection with the machine which logs
authentication events from the dial-up servers.  What an ISP usually gets
is a login record which contains a session sequence number, and then
somewhere later in the log a logout record with the same session sequence
number.  Sometimes the login and logout will cross a time boundary that
causes them to be in different log files.  We also synchronize these
machines by NTP, but that is just our choice to do so.

In theory, it should always be possible to determine who was in control of
an IP address when a message was sent.  In practice, this depends upon
very accurate timestamping of all of the log files.  It is not only fairly
common for people to have clocks as much as ten minutes off, even on
important server machines, but it is often the case that at least one of
the machines in question is misconfigured as to time zone.  If any of the
machines are very far away from the United States, say in the Far East,
then the likelihood of error and the difficulty of detecting it increases.  
Microsoft Windows defaults to the PST/PDT time zone, and many people --
even system administrators running NT mail servers -- forget to fix this.

The end result is that the person handling the "abuse" account is going to
have to make what amounts to a guess about the most likely source of a
problem.  This guess will probably be correct three out of four or even
four out of five times.  However, quite often the guess will be minutes or
even hours off, and the wrong login account will be accused.  Since the
entire process depends upon the validity of the recipient's timestamp,
there is little confidence that should be placed on it.

-- Mike


On 2000-07-10 at 16:03 -0400, Ron Peterson wrote:

> Here's the skinny from HarvardNet.  They recieved notification from
> someone that some kind of SPAM originated from their network.  They were
> sent the SPAM headers.
> 
> Then they compare the IP address in the SPAM header to logfile of who
> was logged in and assigned that IP address (via DHCP) at the time the
> message's timestamp says the message was sent.  Which was me.
> 
> So, unless someone has another theory, looks like someone got my
> password.  Yuck.  I'm assuming someone sniffed my POP login, but just to
> be safe, I'll be doing some security auditing also.


-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org