HPE 9000 and HPE e3000 Servers
1845486 Members
2508 Online
110244 Solutions
New Discussion

Shell scripts for the following

 
SOLVED
Go to solution
ShivKumar_1
Frequent Advisor

Shell scripts for the following

Hi
I need a shell script to monitor the following. Thanks
in advance

ShivKumar


Each system must generate a security alaram by which to alert the administrator of a potential security or
suspicious activity Eg: High volumes of bad packet data or corrupted data.
The alarm must be activated by the following events

1) Five consecutive unsucessful login attempts during a single session
2) Sucessful modification of critical system or application files
3) Sucessful and unsucessful attempts to gain permission or assume identitiy of another user
4) Upon sucessful login the system must display the date and time of last sucessful logins
5) Each system must maintain a list of security files which is accesible by the administrator of the following events

a) Sucessful and unsucessful events
b) Sucessful and unsucessful attempts to switch to another user's
account
c) All changes to system security ,including adding users
d) Operating system configuration changes
e) Logoffs
f) Inactive user sessions

6) Disabling inactive userids which were inactive for more than 15 days
7) No reuse of the same password used in the past
4 REPLIES 4
Bill Hassell
Honored Contributor
Solution

Re: Shell scripts for the following

This is a large task and needs a lot more details to complete. Details such as:
What is an alarm? Is it email? Or a pager message? Does the alarm require acknowledgement? Is there a high security machine available to log the alarms? and so on

> 1) Five consecutive unsucessful login attempts during a single session

It's a bit confusing using the term 'session' when the user cannot login successfully. Do you mean 5 consecutive login attempts in less than 5 minutes? The command to use is lastb but handling the time window will be tricky.

> 2) Sucessful modification of critical system or application files

It will be very hard to define what are critical system or application files. You might start with all files owned by root but applications will require a lot of research. Modification of files should include not only configuration files but also exectuables and libraries.

> 3) Sucessful and unsucessful attempts to gain permission or assume identitiy of another user

This is not a clear objective. An attempt to gain permission of another user is not something obvious--it might be cat of a file without read permission, etc. Otherwise, assuming the identity of another user is done by stealing or guessing another user's password. The sulog file will have some of this information.

> 4) Upon sucessful login the system must display the date and time of last sucessful logins

(this is standard with conversion to a Trusted System) Add the following line to /etc/passwd:

/usr/bin/last -R -5 $(/usr/bin/id -un)

> 5) Each system must maintain a list of security files which is accesible by the administrator of the following events

> a) Sucessful and unsucessful events

Again,, this is quite ambiguous and might mean hardware events, security processes, or simply application problems. The normal location for this is /var/adm/syslog/syslog.log but you'll have to decide what to read and report.

For login events, the files are:
/etc/wtmp and /etc/btmp
However, these are in binary so you must use last and lastb to read them.

b) Sucessful and unsucessful attempts to switch to another user's
account

This is all kept in sulog

> c) All changes to system security ,including adding users

Again, quite ambiguous. SAM keeps a log of adding users but that is not the only way to add a user. A hacker can use vi to create a new user.

> d) Operating system configuration changes

SAM's logfile is a start but just as in adding users, SAM is not the only way to modify the system.

> e) Logoffs

last wil report this information.

> f) Inactive user sessions

A very difficult task. If you mean a user that logged in and is sitting at a shelll prompt, the ps command can help. However, there are many other ways to run programs on the system (sockets for client/server such as email, remsh, ftp, and so oon)

> 6) Disabling inactive userids which were inactive for more than 15 days

This will be easy or difficult dpending on whether you are running Trusted Systems.

> 7) No reuse of the same password used in the past

Standard HP-UX does not keep any records of previous passwords.

--

In summary, it would appear that you have concerns about security on your system(s). I would strongly recommend converting to Trusted Systems first, then if you are running HP-UX 11.0, install IDS/9000 (Intruder Detection System).

And most important: no one gets the root password unless they are directly responsible (and accountable) for the administration of the system. And get a good book on Unix security.


Bill Hassell, sysadmin
ShivKumar_1
Frequent Advisor

Re: Shell scripts for the following

Hi Bill
Thanks for the reply. I have a NIS environtment and NIS doesnt support trusted systems. I cannot turn the auditing on as the client doesnt want to do that.
So I was wondering if there werw nay specific shell scripts to fix this. I know that there are 3rd party doftware tools like TRIPWIRE, BIGBROTHER, AXENT available. But my client wants to solve this thru scripting
Bill Hassell
Honored Contributor

Re: Shell scripts for the following

NIS and security don't go together at all. It's convenient, but unless every system is using NIS+ then passwords are being broadcast across the network.

Most everything I described can be scripted but in some cases, the effort will be quite significant. The tools you mentioned are good starting points...it would be a mistake to try to recreate rewrite COPS or TRIPWIRE from scratch unless you have a lot of time (several weeks) and lots of experience in computer security.


Bill Hassell, sysadmin
Kevin Moore_2
Occasional Advisor

Re: Shell scripts for the following

Hi,

The easiest way to detect unsuccessful logins is in the /etc/files/auth directory. There is a sub directory for each letter, which contain files for the user with the first letter of the directory.
You can grep these files for u_numunsuclog*
If this is present, then there has been at least 1 unsuccessful login. It is then a matter of using awk to pull out the number immediately after this string, which is the number of successive unsuccessful logins. You can then have your script notify you by whatever means you want.

Hope this helps in one of your problems.
Kevin
Never put something off, for it may be your last chance