Lockin Down 11.0 machine

[Dave La Mar]

In order to conform to an audit, we have been in a process of locking down our unix boxes.
Below is a short explanation of where we are and the current problem we are facing.

Any relevent input would be greatly appreciated.
Scenario:
1. Eliminate use of any generic login to the machine. => Done
2. Remove the ability to overlay code via ftp. => Done
3. Do not allow an ftp job to place an executable script on the machine. => Done

Problem:
1. Tar file is sent via ftp.
2. Extraction of tar file overlays existing code and is executable.
3. Restricting use of the tar command is not an option.

I have yet to find a solution for not allowing tar files to be sent via ftp.
Restricting ftp use, or destination is not an option as our environment does an Inordinate
amount between different platforms and is a requirement of doing business.

Best regards,

dl

[A. Clay Stephenson · Accepted solution]

There is really no reliable way to recognize a file as a tar file -- especially if it is also compressed using whatever mechanism. You mention tar but the same arguments apply to cpio, frecover, pax, and dump. This is a case where you really have to rely upon the underlying permissions of the directories that house the files. If you are restoring as root then this too is doomed.

I can think of one scheme (but it does restrict you to tar only, not cpio et al). Get the source from the Gnu version of tar. It's fully compatible with standard tar. Modify the source code so that restores of executables are not allowed unless the uid = 0. You would then replace the standard tar with this version.

Restores of data, by their very nature, are inherently dangerous. The permissions on your existing system files and directories should prevent a regular user from causing too much damage but from root there is no protection.

[Dave La Mar]

Thanks A. Clay.
No problem with root, only two people have root login.
I focused on tar because we are a very inexperienced shop on the developers side, exception being two dba's.
Let me say, the lock down is currently only on a development box. It will be incorporated on the production side once all the bugs are worked out.
Outside of the dba's and the SA & SA1/2 no one has a login to the production machine. The execption is a generic login for all the scripts that are run (do to environment variables +).
This was done because we were in a conversion project moving to HP-UX from a different platform and it made the process smoother. It is now time to put more effort into security.
Any other tape type restores are already locked down to two people.
Again, thanks for the input. GNU tar should be a viable solution.

AND congrate's on your milestone!

Warmest regards,

dl

[generic_1]

Speaking of security you may want to turn off ftp alltogether :), and if you need such a tool install ssh/scp. That way you are not sending your password and data unencrypted accross the network where it can be sniffed. SSH is free. It is nice to installed the random number generator too with it, because it will speed up connections.
As far as security goes on tar. You could setup sudo for tar and lock down the permissions on the exe. Perhaps this would at least give you better accounting of whos running tar :)

[Steven E. Protter]

Take way write priviledges to files that the tar files can overlay.

You could also alias the tar command and not allow xvf or whatever paramters you don't like. This problem should be solvable by permissions.

You could create a program that runs in cron and does a find -name *.tar and puts the output in the delete command.

If the ftp filesystem is limited and thats the only place ftp users can upload files( can you say chroot? ) then you should be able to achieve your goal.

Be careful choosing the frequency of the runs on the cron job, it can slow a system down.

If there is a firewall involved, you can program it to not allow tar files through. That would be the easiest. I have no idea how to do it with ipfilters if it can even be done. I don't know how to do it with Linux iptables, but bet it can be done there.

We do that very thing with symmantec in email. It could be applied to port 20/21 as well

SEP

[Dave La Mar]

Jeff and Steven,
Thanks for the input, but
1. Disabling ftp is not an option.
2. Disabling tar use is not an option.
3. Restricting file permissions would create more problems than currently encountered.
4. Secure ftp not required, all ftp jobs are internal to the network between different platforms and not the problem at hand.

I was looking more to what other shops are doing for a scenario I described.

So far, as with any security implementation, all we have accomplished is "making the developers job more difficult".

Appreciate the input.

As a note for others that may respond, points will not be assigned until I feel I have exhausted the ITRC well.
Your patience is appreciated.

Best regards,

dl

[RAC_1]

I think I have got something that can help you. Check man page ftpaccess. Use of this file is enabled by spcifying -a option on ftpd daemon(/etc/inetd.conf)

The man page talked about some compress and tar option. check it. I could not get it.

Also have look at example file for ftpaccess.

/usr/newconfig/etc/ftpd/examples/ftpaccess

Hope this helps you.

Anil

[Hazem Mahmoud_3]

Dave,
The only solution I can think of at this point is to write a script that does the following:

file
: tar file
grep for all files that have "tar file" as output to file command
remove those files

Now the best way to implement this is to have it invoked whenever ftpd is invoked. Maybe some type of wrapper. This is not COMPLETELY secure, but what is really completely secure. In the sense, that the file will actually reside on the system for that split second until it gets removed.
Without getting into too many details, because it would depend on how your system is set up and how you want this set up, but it gives you an overall concept that may be helpful. Just a thought.

-Hazem

[Dave La Mar]

Thanks Anil and Hazem.
As noted,
1. Restricting ftp is not an option for the problem. FTP is used extensively in our environment and the process involved here is only on internal ftp jobs. FTP is not the security concern. Not allowing overwrite and puts of executables is. I have the overwrite covered execpt when someone sends a tar file and extracts the contents.
2. Taking tar away would be detrimental to all in our environment. Tar is an essential for the user. The intent is not to eliminate the ftp of a tar file, but rather to restrict the ability to untar and overwrite an executable. (code protection without being overly restrictive)

Thanks for the input.

Best regards,

dl

[RAC_1]

alias tar='tar -w'

Confirm eacho tar action before proceeding.

man tar.

Anil

[Dave La Mar]

Anil, Anil,
You have the wheels turning. The suggestion will not prevent what I desire, but I can see as A.Clay and others have hinted, a wrapper may be an option.
If we cannot prevent this, due to productivity issues, at least we can track the use and list of files acted upon.
This would create an audit trail and may be enough to discourage the action in question.
We currently are capturing "illegal" logins and sending immediate notification to the SA and the culprit which has pretty much discouraged anything out of SOP we want.

Much appreciated.

Best regards,

dl

[Paula J Frazer-Campbell]

Dave

Lateral thinking - this a system that I have used in the past.

1. Create on the devel server a pickup dir.

2. Disable ftp for average user on the devel server.

3. On the target server create a destination dir.

4. On the destination server write a small script that does an ftp pickup from the devel server and cron it for say 5 min.

5. This script should be run as root and when it ftps a file accross it should chmod it to 000.

You will then have a system in which the devel team can get their files accross to the live server, but you will have complete control of them once they arrive.

HTH

Paula

[Dave La Mar]

Paula -
While your suggestion has definite merit, I would have to set up the default directory for each dev user. Presently, we have 100's of ftp jobs to/from different platforms with our unix servers.
Most all of them (jcl, dos batch, etc.) use a single user login with restrictions. What is not restricted for this single user is the directory in UNIX due to the fact that we - Put different data into different subdirs and allow script execution based on conditions met.
Note that that "one user" is locked down to no
direct login other than ftp.

I certainly am getting some good feedback.

Thanks all.

Best regards,

dl

[RAC_1]

Just a advise.

1. move tar to some location.
2. script named tar in tar's location.
3. script checks command line and then checks contents of tar file (with tar -tvf) with contents of dir. If same alerts and does not run actual tar.

Anil

[Dave La Mar]

O.K. Here is what I have settled upon.
We will script a log file of the tar command usage as well as files involved.
Those not abiding by the SOP, that will be published, will be advised and reprimanded as required.

There has been a great deal of fine input here so, again, I thank all contributors.

dl