HipCheck mobile system monitoring service available for SCO UNIX
jlsels...@my-deja.com
a lot of work has been happening in the Me Inc. line of
mobility-based services and products.
Of immediate interest here is the HipCheck service, which allows
you to monitor what's going on on your SCO UNIX systems
(OpenServer 5, OpenServer 6, UnixWare 7) from your
mobile phones (see system information, CPU and memory
usage, printers status, users logged in, hardware profiles, etc.),
receive SMS alerts on your phone if certain event conditions that
you define happen (critical service stops running, key filesystem
getting low on space, etc.) and in some cases, take actions on
your phone to correct those situations.
HipCheck can also monitor Microsoft Windows systems.
See http://hipcheck.me-inc.com/ for more and for setting up
a trial account to try it out.
Jonathan Schilling
Joe Dunning
On Mon, 23 Oct 2006, jlsels...@my-deja.com wrote:
> For those of you wondering what SCO has been up to,
> a lot of work has been happening in the Me Inc. line of
> mobility-based services and products.
>
> Of immediate interest here is the HipCheck service, which allows
Interpreting the installation instructions, the system listens on port
8080 or 8081. Furthermore, the instructions discuss checking the service
is running by opening a browser to:
# For an SCO OpenServer or SCO UnixWare system:
http://<Agent-IPaddress>:8080/axis/services/SCOUnixAgentService
# For a Windows system:
http://<Agent-IPaddress>:8081/HIPcheck.asmx
Neither of these is apparently using SSL. Does the system use unencrypted
sessions across the Internet to monitor and control the server?
jlsels...@my-deja.com
There are a variety of options depending upon how the HipCheck Mobility
Server
is configured and what level of security is desired by the customer.
See
https://hipcheck.sco.com/hipcheck-files/doc/HipCheckUG/HipCheckUG.htm,
Chapter 5, "Configuring the proxy, https, and certificates". The most
typical
production mode arrangements have agents running on 8080 or 8081 being
guarded by the Proxy Relay Service, which sits inside the customer's
firewall listening on a dedicated firewall hole connecting it to the
HipCheck
Mobility Server; traffic between that Server and the Proxy Relay
Service
is done via HTTPS/SSL with a certificate. But other arrangements are
possible as well, as the doc explains.
Jonathan Schilling
Joe Dunning
I think most security professionals would suggest that, these days, it's
never a good idea to have root passwords travelling over the Internet,
production or not. The document describes forwarding port 8080 or 8081 in
the NAT router. If someone can sniff passwords, that makes access to the
LAN behind the firewall possible.
And I think your "But other arrangements are possible as well" is a little
disingenuous, since the document describes the http mode as default and
the https mode is really one of the "other arrangements".
jlsels...@my-deja.com
Joe Dunning wrote:
>
> I think most security professionals would suggest that, these days, it's
> never a good idea to have root passwords travelling over the Internet,
> production or not. The document describes forwarding port 8080 or 8081 in
> the NAT router. If someone can sniff passwords, that makes access to the
> LAN behind the firewall possible.
People send root passwords over the Internet every day, working from
home
over a VPN and doing "su" inside an xterm or putty or whatever. So it
all
depends upon the comfort level someone has with the level of security
in place.
It's important to note here that HipCheck only asks for the root
password
once, when adding a system to be monitored (or later if you modify the
system's
characteristics). The root password isn't sent on every transaction
with the
monitored system and it isn't held on the HipCheck Mobility Server.
But there is a HipCheck deployment arrangement in which root passwords
*never* go out over the Internet. If you deploy the HipCheck Mobility
Server
within your own enterprise's intranet, then the web browser
admininstration
page that collects the root password upon system add will only be
sending
it within the intranet, never outside. Only the mobile phone
subscribers send
data in from the outside, and they only submit their own subscriber
password
from the phone, never the root password of the system being monitored.
> And I think your "But other arrangements are possible as well" is a little
> disingenuous, since the document describes the http mode as default and
> the https mode is really one of the "other arrangements".
In the actual administrative UI, it's a drop-down list, so it doesn't
have a default.
The documentation explains the http mode first merely in the interest
of
starting with the simple case and then moving to the more complex ones.
Jonathan Schilling