Script to find out who is moving files into production?

[John Jimenez]

These days we have more and more programmers testing and overwriting program into production, some of these programmers are contractors coming in via VPN. I would like to get a handle on this? I have a programmer that works with me who is writing a program to find out when a program file is over written. We are trying to find out whose login is doing the copy or move, but we are having trouble with this part. Does anyone have a script, procedure, or maybe a program that will help with this security problem?

[John Jimenez]

Or even a good Security book that will help? Right now we only have a couple of groups set up. I would like to prevent programmers from moving files from their test environments to production. These programmers need write permisions in the production environments because they need to log into the application to test. But I only want them changing things via the application, so that leave things wide open when they are at a UNIX prompt.

[James A. Donovan]

You may want to take a look at a package like TripWire, or something similar...

[Steven E. Protter]

Tripwire is designed to spot changes in system configuration tha effect security, show signs of hackers invading as such.

Its a great tool, I recommend it, but not for this application. Unless these folks are overwriting root access configuraiton files. Which means root password security is an issue.

You might want to harden your system with Bastille.

http://software.hp.com/portal/swdepot/displayProductInfo.do?productNumber=B6849AA

Thus far I've skillfully avoided actually answering your question.

Because users are coming in via a vpn, there may not be enough data on the hp system to figure out who did what.

inetd -l

Enhances logging of all internet connections including ftp and secure shell.

Start analyzing the /var/adm/syslog/syslog.log file for the transactions you care about.

Run them agains the vpn log if you are getting the vpn ip address in syslog.log

When you see an important file has changed, you should be able to match its time stamp against syslog and trace it back to the offender.

Thats the best I can think of so far.

SEP

[Mark Grant]

The only suggestion I might had is to keep some records from the users .sh_history files. As an example, you might put a command at the end of their .profile to look for "cp" and "mv" command and compile a report from them somehow.

It's not great but it's a thought.

[Rodney Hills]

First, lock down production (no one can add/replace programs) except "root".

Second, develop a script-
1) To copy from the programmers workbench to production. You could use "sudo" to give the script permissions to do the actual copy.
2) To make a backup of the original prior to copying.
3) To track who copied what when.

You may want to look into some type of change control system (RCS or PVCS) so the programmers have to "check-out" a programmer before changins (so 2 programmers don't try to change the same program at the same time).

HTH

-- Rod Hills

[John Jimenez]

Thanks for giving me a starting poing. I will take a look at all 3 ideas. I will see if any other ideas come through and assign you guys your well deserved points...

[John Jimenez]

Rod,
Thats just it. They need write permisions when they log into the application. The application then does security. These programs are owned by the Database and everyone is part of the group staff. so I can't take these permissions away. We are already trying to do your 3 steps, but are having trouble with step 3. because because people copy the program over with a -pf so the owner still the database user. So what do we use in the script which will show who actually moved the program into production?

[John Jimenez]

The Tripware software sounds like something I should look into, but Steven was write it does not address my currentl problem.

The Bastille looks like a possible answer. But after reading up on it, we are not running popular products, and there are warnings to use extreme caution because very few products have be tested. I do not have a seperate test server to try.I will start to analyze my syslog.log closer to match times.

We have a script ready to run daily that will show us what program files were touched, to at least know when they are changed. I will then have to do some detective work to find out who-did-it. Maybe after catching a few culprits they will begin to follow the procedure to notify me. I can then ask any departments who mya possibly be effective; to notify and verify that it has been tested in the test environment.

In the past places I have worked in there were few programmers with such privilages. But here we have in house programmers and out side consultants fixing and changing things. I hope to some how get some control.

[John Jimenez]

Mark,
Your idea to add something in the .profile is very interesting. It may work as long as at the end of the day command is still in the history. I am still unsure exactly how to set up, but I will see what I can find.