- Community Home
- >
- Servers and Operating Systems
- >
- Legacy
- >
- HPE 9000 and HPE e3000 Servers
- >
- Shell scripts for the following
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-20-2001 12:08 PM
02-20-2001 12:08 PM
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
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-24-2001 05:13 PM
02-24-2001 05:13 PM
SolutionWhat 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-24-2001 08:28 PM
02-24-2001 08:28 PM
Re: Shell scripts for the following
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-25-2001 11:58 AM
02-25-2001 11:58 AM
Re: Shell scripts for the following
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-14-2001 06:30 AM
03-14-2001 06:30 AM
Re: Shell scripts for the following
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