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.

[Keith Buck · Accepted solution]

First, I'll say that there is usually a permissions-based solution to these kinds of problems. However, it may be the application that needs to change and you may not have control over that. The general idea would be to restrict write access to only the data files (and separate these on a per-user basis), and not allow write access to the application files itself.

Second, I'd suggest HIDS (aka IDS/9000)

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

which can be used to monitor files realtime and tell you which user changed them. Unfortunately, it sounds like the user would be the "application/database" user, so that may not be as helpful as you would like, but at least it can alert you as soon as it happens.

Third, another option would be to store a read-only backup of the real 'production' files and simply 'restore' them on a regular basis. Soon, the programmers will realize that their efforts to overwrite the production code are not doing what they expect and they'll complain and then you'll know who did it :)

I don't really recommend the third option...if you can determine the 'production' files that you would overwrite, then you can restrict the write access on those files without the elaborate procedure.

-Keith

[Jean-Luc Oudart]

It seems to me you need a proper procedure for accessing / promoting application/files in production.
If this is too open you'll get some headache

In another words, be proactive on the subject.

Also a rollback procedure should be part of your app. rollout procedure.
Anything like "testing and overwritting in production", very scary !

Rgds,
Jean-Luc

[John Jimenez]

Rod,
A new lead here in IT had reccomended PVCS solution. I was kind of skeptical on how that would work. Maybe that is worth a try. The only RCS I found is freeware, and I would like to purchase one so I can have piece of mind with support. Any recomendation on PVCS or RCS product?

[John Jimenez]

Jean-LUC it is pretty scary. When I am asked to put it in production, I make sure I copy the old version to my home directory. It is a headache when we find out months later that a change enhanced something, but at the same time cause other problems that go a long time undected because of not all deparments tested or were notified

[Rodney Hills]

I'm not real familiar with PVCS or RCS (I just remember they are change control systems).

At our site we have a development database system where the programmers make their changes, and the change control system keeps track of which programs/screens/menus/reports have been changed. Then the programmer requests the database administrator to "roll" the updated items into production (programmers do not have direct write access to production). This allows us to keep track what has changed and for what reason a set of changes was made.

This probabily won't help your situation if the database system does not have its own change control system.

We are running a database system called uniVerse and an application called Avante. The changed control system is named PRC.

You may want to post your question to a forum that deals with the database system you are using.

Sorry can't be of more help...

-- Rod Hills

[John Jimenez]

Keith,
You are right, I guess the users need write access to the Data which is in a separate Directory then the Programs (which right now is the problem). I will begin modifying the rights in one of the test environments program directory to make sure the application still works okay. Also the HIDS sounds like something I really need too. I really liked your 3rd recomendation; it would quickly teach them a lesson, but would probably cause other issues that I would then be responsible for...

[John Jimenez]

Rod,
We are running a database called Basis PRO5 which is not really a database at all, more like a flat file. There are not many utilities. But for kicks, I will check with our application and Database support...

Thanks for all your support!!!

[Mark Greene_1]

John,

You can go here:

http://hpux.cs.utah.edu/hppd/search.html

and do a search on rcs and you will find a version in .depot format.

However, I would also stress communication. Let your co-workers know a file is getting overwritten without proper backup. Let them know you are working on hardening both your revision control and your auditing. And let them know that they are ultimately hurting themselves by not following the process.

Good luck with it

mark

[Bill Thorsteinson]

I use CVS to manage the project source. It makes release control easy. It provides a good history of who changed what when. We label our test releases and copy those into production if they pass.

CVS is open-source, but there is good documentation on using it. It's security model is a little strange, but works better than other products I have used. Being open-source there isn't a problem giving all developers a copy. There are GUI tools for all environments. It also seems to integrate with more development tools than any of the commercial tools. Jalindi Igloo provides good integration with tools using the MSS protocol.

Developers and testers should not have write access to the production source. The recommendation of per user data directories is a good one and should be persued.

We have development, testing, and production environments. This has several benefits including resolving the problems you appear to have.

[Thomas Buck_1]

Don't know if this will be feasible for your situation, but what we did here is to provide the programmers with their own test environment, which is a duplicate copy of the application with a sampling of test data. That way, they can have write authority to any object in TEST, but not have any authority to production.

When programs are ready to move into production, an administrator (or other designated person) moves the new/updated programs into the production environment.

[John Jimenez]

Yes you are right. We at least have a script now that let us know when something has been changed. I plan to chmod to lock down changes soon. Thanks again for all your help

[Jerry Anderson_5]

Don't know if this is still an open problem for you, but you could also create shell frontends to the standard copy/move commands and place them earlier in the user's search path than the standard copy/move commands. Then when the user enters the command:

$ cp /scratch/a /production/a

The shell would log the action and then call the actual cp command to carry out the request. This is conceptually along the lines of TCP Wrappers - sticking some additional functionality in front of a command you want to lock down. You could also add some logic so that only movement to/from specific directories is logged rather than all movement.

[John Jimenez]

Do you know where I might find a sample of the script?

[John Jimenez]

Jerry,
We wrote a script that notifies us if the time stamp of a program changes. This has been working out pretty good for the programs. I at least know if a program was changed. But a few weeks ago the hugest data file on production was blown away.... Luckily it was not that important. I restored it from tape... But I am still wondering what or who made it dissapear....

[Bill Giannotti]

Symark's PowerBroker can be used to delegate privileged activity without giving the ROOT out.
Also, allows you to log all activity down to the keystroke level.