Netscape server startup/shutdown in rc2.d/rc0.d - how?

Netscape server startup/shutdown in rc2.d/rc0.d - how?

Post by Arin Komin » Fri, 24 Apr 1998 04:00:00



:Starting/stopping the admin servers is easy enough, but there are two
:problematic cases:
:1. what are the best solutions for starting the servers themselves (we
:run the whole gamut of Netscape stuff: certif, mail, web, news,
:calendar, etc.).  Some of these require passwords.  How do you handle
:this, cleartext password w/ file redirection, cleartext password and
:expect, or ....

I wrote scripts for rc3.d/rc0.d.  The servers that do not require passwords
are easy...just check to make sure the start command exists, then start it,
else fail and send email about it.

For my servers that require passwords (eg. ssl-enabled servers), I wrote
expect scripts to start them.  Unfortunately, I didn't figure out
a good method of encrypting the passwords, so I'm sending 'em cleartext.
Just be sure to have those files readable/writable only by root.

You might be able to write something using one of netscape's APIs to be
able to start the sucker with an encrypted password, but I never had
the time to figure that out.

:2. The webmaster claims some server startup procedures have no command
:line equivalents that he is aware of, namely:  Calendar Server.  Any
:work arounds/solutions?

Start all of the uni* demons in the proper order.

netscape might have some info available at



University of Chicago/GSB                       tel: (773)702-0333
1101 E. 58th St. #309 Chicago, IL 60637         fax: (773)702-0233


Netscape server startup/shutdown in rc2.d/rc0.d - how?

Post by Jim Denni » Sun, 26 Apr 1998 04:00:00

: Arin,

: Between expect and starting the Calendar server, looks like you and I
: are on the same page as far as solutions go.  I do wish there were a
: more secure way, but I guess if I can't trust my file permissions then
: I can't trust /etc/shadow, etc....

        There is.

        You can have an expect script run via ssh from a backend
        system (behind your firewall).

        Let's assume that your exposed system has been hacked.  The
        attacker may have gained root/shell access and be interested
        in intercepting transactions destined for this system.

        If you're using an expect script that's stored on the same
        host the attacker can find it and waltz off with your password
        (no muss, no fuss).  Given the extreme naivete of many IS
        departments with which I've worked it is likely that this
        password is also used on various other systems and subsystems
        --- or variants of it.  So the attacker also has gained
        valuable info to use in further exploits.

        If you're starting these scripts remotely (via some
        rsh or telnet expect script) the attacker job is easier
        in some ways (all they need is promiscuous access to that
        LAN wire to gain access to your server and to sniff your

        If you use expect over an ssh link they need to catch your
        password on the exposed host, while it is being used.
        (probably they will need to intercept it in /dev/kmem or
        they'll need to replace one of the involved programs,
        sshd or the server daemons) with a trojan/wrapper).

        This is the key.  You want the attacker to be forced to
        change files.  This increases your chances of detection
        (tripwire) and prevention (securelevel and/or read-only
        hardware for base system and executable files).

        You might still be vulnerable to /dev/kmem snooping even
        if the attacker can't gain further control.  However this is
        more difficult than simple file traversal, or even the
        trojan wrapper attacks.

        So, although there is only a marginal improvement in
        security it is possible to rely on something more than
        your filesystem/permissions.  It probably only really
        helps if the attacker's exploit requires a file change
        *and* a reboot or server/daemno restart.

        (And it only works if you have a trustworthy 'tripwire'
        process in place; one that is not remotely assailable).

        (As usual, real intrusion detection is HARD).

Jim Dennis,
Starshine Technical Services