Byron,
Have you contacted the admin at
charcot.neurology.washington.edu? I'm sure they would
want to know that one of their machines is being used
for this purpose.
Registrant:
University of Washington (WASHINGTON-DOM)
4545 15th Ave NE
Seattle, WA 98105-4527
US
Domain Name: WASHINGTON.EDU
Administrative Contact, Technical Contact:
UW Network Operations Center (UW-NOC)
[EMAIL PROTECTED]
University of Washington
Networks and Distributed Computing
4545 15th Avenue NE, 354841
Seattle, WA 98105-4527
US
(206) 543-5128
Fax- (206) 685-4044
Billing Contact:
InterNIC Billing (IB173-ORG)
[EMAIL PROTECTED]
University of Washington
Computing and Communications
Networks&Distributed Computing
4545 15th Ave NE
Seattle, WA 98195
206-685-6233
Record last updated on 06-Mar-2000.
Record created on 04-Sep-1986.
Database last updated on 5-Nov-2001 19:06:00 EST.
Domain servers in listed order:
HANNA.CAC.WASHINGTON.EDU 140.142.5.5
MARGE.CAC.WASHINGTON.EDU 140.142.5.13
NS.UNET.UMN.EDU 128.101.101.101
John Hebert
--- john beamon <[EMAIL PROTECTED]> wrote:
> portmap is a service associated with NFS, and I
> *think* a few RPC calls.
> It's a necessary element in NFS, though. This looks
> like some sort of bot
> or script that's been left running in the background
> until you screw up
> and turn this service on. I can recommend a couple
> things. You might
> want to add a black hole route for this guy, saying
> that the path to his
> box is through 127.0.0.1. You might want to start a
> little scripting
> project to remove lines containing "blah", listed in
> a conf file
> somewhere, from your logs on a periodic basis. I
> have a set of tools for
> removing all the "C:\...\winnt\" requests from my
> web server logs,
> courtesy of CR and nimbda. It'd be neat to expand
> that to something like
> a conf_file loaded into a Perl hash, then export
> each line that doesn't
> match anything in the hash to a tmp file, then copy
> the tmp file back to
> the original. I don't really "do" Perl yet, but I'm
> a little familiar
> with the vocab.
>
> Any request blocked by an ipchains firewall, which
> is "doing its job",
> goes to logs. The idea is not to prevent logging,
> but to prune it and
> acclimate it once a harmless but persisten intruder
> has been identified.
> If someone spends a week scanning a port I don't
> have open, I figure
> they've left it running the background and waiting
> for a reply. It likely
> won't go away. I had a guy scan a particular port
> of mine several times a
> minute for over three months. I eventually just
> started "grep -v"
> removing his IP from my logs, but the firewall was
> doing its job.
>
> --
> -j
>
> On Mon, 5 Nov 2001, Byron Como wrote:
>
> > Date: Mon, 05 Nov 2001 23:42:31 -0600
> > From: Byron Como <[EMAIL PROTECTED]>
> > Reply-To: [EMAIL PROTECTED]
> > To: [EMAIL PROTECTED]
> > Subject: [brluglist] Sombody at my front door.
> >
> > The attached text file has the ip addresses that
> are interesting. I
> > personally don't think there is a problem because
> it seems like some
> > kind of automated script kiddie attack that is
> mindlessly plodding
> > along. Although my log files have rolled over, I
> did write down the name
> > of the machine that appeared in an earlier logfile
> from which there were
> > attempted connects:
> charcot.neurology.washington.edu. Anybody care to
> > characterize what these logfile entries mean?
> >
>
> ================================================
> BRLUG - The Baton Rouge Linux User Group
> Visit http://www.brlug.net for more information.
> Send email to [EMAIL PROTECTED] to change
> your subscription information.
> ================================================
__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com
================================================
BRLUG - The Baton Rouge Linux User Group
Visit http://www.brlug.net for more information.
Send email to [EMAIL PROTECTED] to change
your subscription information.
================================================
