[473] in winnt
APC - Powerchute update...
daemon@ATHENA.MIT.EDU (Leonard Kimble Jr)
Fri Feb 4 09:24:00 2000
Message-Id: <200002041423.JAA25774@melbourne-city-street.MIT.EDU>
Date: Fri, 04 Feb 2000 09:23:27 -0500
To: ntpartners@mit.edu
From: Leonard Kimble Jr <lkimble@MIT.EDU>
Cc: support-dept-computing@mit.edu
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Hello Partners.
As I wrote in our last NT Partners meeting notes...
3. APC - Powerchute software.
The Powerchute service broadcasts within the subnet searching for other
powerchute services and tries repeatedly to gain administrator access to
any system found with the powerchute service. The is a minor nuisance that
can clog up a victim system's Security event log. I've received no word
yet from APC about this problem yet.
---
After receiving one wrong response (in email) from an APC Tech, I called
and escalated the problem. (FYI: The APC technical support line number is
800-800-4272)
On the machine being constantly "attacked", edit the pwrchute.ini file,
which should be in the powerchute application directory, as follows: Add
the lines...
[ Communication ]
TcpIp = No
I was told to add this section after the "[ UPS ]" section. Adding these
lines and then stopping and restarting the UPS service will get rid of the
problem. In actuality, what this does is prevent the subject machine from
listening for connections from the Powerchute application anywhere on the
network (not just your subnet). It doesn't stop it's on broadcasting or
any other machine's broadcasting. It just stops listening.
This also means that valid connection attempts cannot be made to the
subject machine with the Powerchute software. So, an administrator would
no longer be able to remote maintain the UPS system -- no scheduling
shutdowns, no remote testing, no remote battery monitoring, etc.
I asked the second APC Tech person if there was a way to regulate the rate
at which machines broadcast looking for some Powerchute services to listen
to them. He told me no. But I suspect further escalation could yield some
apologetic "Yes-we-should-have-thought-of-that-and
will-fix-it-in-a-future-version" response.
Thanks,
Leonard
---------------------------------------------------------------------------
Leonard Kimble Jr MIT - Information Systems
lkimble@mit.edu Departmental Computing Support
E40-329, 258-7932 Consultant
http://web.mit.edu/lkimble/www/
---------------------------------------------------------------------------
