Unix Programming - automate monthly maintenance via unix script

Author

automate monthly maintenance via unix script

debaser

2006-07-24, 7:22 pm

Hello. I have been given the task to automate the monthly maintenance
activities for our 7 HP K-series servers running hp-ux 11.0. One thing
I was asked to do was to write a UNIX script to automate the changing
of both UNIX and Oracle passwords across all servers for root and 3
other users.. I have made this attempt and run into problems. Because
changing passwords is designed as an interactive process, I have had
much difficulty within this script determining the proper 'delay' value
to set before 'print'ing a reply to an interactive prompt from unix
(passwd command) and oracle (chdbpass command). Does anyone know if
there is a way to bypass these standard interactive methods of changing
passwords and to modify the password files themselves to effect a user
password change?

Pascal Bourguignon

2006-07-24, 7:22 pm

"debaser" <gbruner@gmail.com> writes:

> Hello. I have been given the task to automate the monthly maintenance
> activities for our 7 HP K-series servers running hp-ux 11.0. One thing
> I was asked to do was to write a UNIX script to automate the changing
> of both UNIX and Oracle passwords across all servers for root and 3
> other users.. I have made this attempt and run into problems. Because
> changing passwords is designed as an interactive process, I have had
> much difficulty within this script determining the proper 'delay' value
> to set before 'print'ing a reply to an interactive prompt from unix
> (passwd command) and oracle (chdbpass command). Does anyone know if
> there is a way to bypass these standard interactive methods of changing
> passwords and to modify the password files themselves to effect a user
> password change?

You can use expect(1).
http://expect.nist.gov/

--
__Pascal Bourguignon__ http://www.informatimago.com/

This is a signature virus. Add me to your signature and help me to live.

debaser

2006-07-24, 7:22 pm

Thanks for the reply. I know about expect, however, I am not able
to get approval to install TCL because it is open source. There is a
prejudice against Open Source here because it is thought that problems
may occur through security breach or unstable versions.

I need to find some other way.

Pascal Bourguignon wrote:
> "debaser" <gbruner@gmail.com> writes:
>
>
> You can use expect(1).
> http://expect.nist.gov/
>
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
>
> This is a signature virus. Add me to your signature and help me to live.

2006-07-24, 7:22 pm

On Mon, 24 Jul 2006 20:47:34 +0200
Pascal Bourguignon <pjb@informatimago.com> wrote:

> "debaser" <gbruner@gmail.com> writes:
>
>
> You can use expect(1).
> http://expect.nist.gov/

There is also chpasswd, which is far less complex, and possibly easier
to deploy. No idea if it's available for UNIX.

--
Regards,
Ed.

Pascal Bourguignon

2006-07-24, 7:22 pm

"debaser" <gbruner@gmail.com> writes:
> Thanks for the reply. I know about expect, however, I am not able
> to get approval to install TCL because it is open source. There is a
> prejudice against Open Source here because it is thought that problems
> may occur through security breach or unstable versions.
> I need to find some other way.

Well, just re-implement it as proprietary sources!
A nice project.

--
__Pascal Bourguignon__ http://www.informatimago.com/

ATTENTION: Despite any other listing of product contents found
herein, the consumer is advised that, in actuality, this product
consists of 99.9999999999% empty space.

Stefaan A Eeckels

2006-07-24, 7:22 pm

On 24 Jul 2006 11:25:36 -0700
"debaser" <gbruner@gmail.com> wrote:

> Hello. I have been given the task to automate the monthly maintenance
> activities for our 7 HP K-series servers running hp-ux 11.0. One
> thing I was asked to do was to write a UNIX script to automate the
> changing of both UNIX and Oracle passwords across all servers for
> root and 3 other users..

Let me guess - the latest idea of a bunch of self-proclaimed security
experts who couldn't log on to a system if their life depended on it.

> I have made this attempt and run into
> problems. Because changing passwords is designed as an interactive
> process, I have had much difficulty within this script determining
> the proper 'delay' value to set before 'print'ing a reply to an
> interactive prompt from unix (passwd command) and oracle (chdbpass
> command). Does anyone know if there is a way to bypass these
> standard interactive methods of changing passwords and to modify the
> password files themselves to effect a user password change?

Oracle passwords can be scripted rather effectively through sqlplus,
but you don't want to do that. What one would do for a truly secure
approach is to expire the password and force the user to select a new
one. That way you don't have to know the password or communicate it to
the user.

ALTER USER scott PASSWORD EXPIRE;

It is however better to implement a profile with more secure parameters
than the standard Oracle password policy:

CREATE PROFILE secure_profile LIMIT
PASSWORD_LIFE_TIME 30;
ALTER USER scott PROFILE secure_profile;

You want to look at the following parameters:

* PASSWORD_LIFE_TIME - the number of days the same password can be used
for authentication

* PASSWORD_REUSE_TIME - number of days before a password can be reused

* PASSWORD_REUSE_MAX - number of password changes required before
the current password can be reused

* FAILED_LOGIN_ATTEMPTS - number of failed login attempts after which
the account is locked

* PASSWORD_LOCK_TIME - number of days an account will be locked after
the maximum failed login attempts is exceeded

* PASSWORD_GRACE_TIME - number of days after which the grace period
begins during which a warning is issued but login remains allowed

* PASSWORD_VERIFY_FUNCTION - password complexity verification script

These should remove the need for a cobbled-together script that can
fail and leave the database inaccessible.

The root password should never be changed by a script. There are
several risks associated with this approach, for example:

* The root password gets changed to the empty string (I've seen this
happening!). Result: everyone has root access and you have to rebuild
your systems.

* The root password gets changed to something else than expected, for
example through lazy quoting, or the password selected containing
special characters that have not been anticipated in the script.
Result: you have to boot the systems in maintenance mode and waste
time. If you have any kind of uptime requirements, they are shot for
the year. Remember that you should have enabled Boot Authentication for
root only, and if the root password is lost you cannot even boot in
single-user mode. Consider that in any case the new password needs to
be provided to the script, so the administrator doing so can just as
easily change the password herself.

* The script has to run with root privileges which is either not
supported (many shells refuse to run setuid scripts) or requires the
use of a setuid wrapper. Unless properly implemented, these wrappers
can be exploited.

Please get a copy of Chris Wong's HP-UX 11i Security. It covers (from
the blurb):

* Understanding and addressing your key vulnerabilities
* 10 ways to gain root access-and what to do about them
* Managing users, groups, files, and directories from a security
perspective
* Controlling access to the system and securing key services
* Safely distributing root privileges
* Using HP-UX software to enhance system security: SCM, SCR,
Restricted SAM, IDS/9000, and the Security Patch Check Tool
* Security techniques for the multi-host environment: Berkeley
programs, SSH, NIS, NIS+, LDAP, Kerberos, PAM, and IPSec/9000
* Tools and techniques for monitoring system activity and change
* Using public-domain programs: SARA, Tripwire, sudo, and logrotate

It's pretty good and it'll teach you a lot about proper security. Plus
you'll have arguments to stop computer-illiterate managers and
auditors from imposing dangerous policies.

Take care,

--
Stefaan A Eeckels
--
Modesty personified:
This was a thread between ignorant people until I jumped in.
-- richard in gnu.misc.discuss