[unisog] When is traffic 'abuse'?

Harris, Michael C. HarrisMC at health.missouri.edu
Fri Jul 27 15:23:27 GMT 2001

I just had an event yesterday that really makes your question hit home.  I
wish I had a definitive answer based upon published policy, a man must
A host sent a message to our abuse line including FTP logs that we were
intruding upon his host.  in reading the logs he sent, it seems it was an
anonymous ftp site, and he was complaining because one of out users tried to
write a file to pub incoming.  to me it was not abuse. in further discussion
with the remote admin all he was asking for was user education about the
rules of his system.  if every remote system demanded this level of response
we would be drowning in security events even worse than we currently are.  

I wish we could limit our security events to troublesome traffic and abuse
on the wire but many events are behavioral.

so is abuse a rating of my pain threshold or yours when dealing with events?

Michael C Harris
System Security Analyst - Expert
ITS / Research Education and Support
University of Missouri Health Center
Phone: 573-882-3392 

harrismc at health.missouri.edu
This e-mail is sent with 99.73% recyclable electrons

-----Original Message-----
From: Tim O'Connor [mailto:oconnort at nyu.edu]
Sent: Thursday, July 26, 2001 11:18 PM
To: unisog at sans.org
Subject: Re: [unisog] When is traffic 'abuse'?

> That said, I'd write off non-flooding pings to a high-profile box as
> noise. For instance, if I found an ADSL user pinging one of our
> high-profile public machines -- say, the main University webserver --
> slowly but regularly, I'd assume they wanted to keep their connection
> non-idle by pinging /something/ and put in the first hostname that
> came to mind. 

I have a box that has a flaky TCP/IP stack.  I found through trial and
error that if it is idle, it goes deaf.  The machine is up, it can
connect out, but it simply rejects all incoming packets.  I haven't
had the energy to debug it, because there are about a million places
to look and I found a very simple solution: every fifteen minutes, I
have it send a single ping packet out to a well-known, high-profile,
virtually-always-up host.  Voila!  The stack remains alive.  I arrived
at this as a solution after one night of frantically thinking the box
dead, walking to work (20 minutes each direction) and finding it up.
I would use it to make a connection, and it would work.  Then I'd
connect in and that would work.  And it was after a couple of times
this happened that I guessed I could keep the IP stack listening if it
sent out traffic on a regular basis.  Once per hour was too
infrequent, because I found myself on more than one occasion with a
dead box, and I had to wait for that hour to roll around and then the
cron job would send out my single ping packet, and everything would
work perfectly.

Ever since I put my crude fix in place, the box has behaved
flawlessly.  And I can devote my energies to more important things
that need doing.

Obviously I could still spend who-knows-how-many hours in debugging
this, rebuilding the kernel, and on and on.  But having the machine
send its ping packet out every fifteen minutes means that the box
NEVER goes dead, ever.  And all it's doing is sending out four pings
an hour, which is not exactly overwhelming anything.  It keeps the
maching talking on the network, everyone is happy, and I no longer
have a periodically dead box.

Certainly this is a case where a purist would fault the solution,
which is as low-tech as can be, but it does the job, and it doesn't
set off traffic alarms.  Of course I'd rather choose the purist 
solution and find out what's wrong and fix it, but to be realistic, 
it's unlikely that I'll discover the cause of the problem in a
reasonable amount of time.  So I'm sticking with the simplistic 
approach, and it works, and it doesn't bother anyone.  It's about as
far from "a flood" as can be, and it works 100% of the time.

Anyhow, that's one person's 2 cents on the topic....

--tim o'connor

More information about the unisog mailing list