Cross Server Job Security

In a big data center with many UNIX/Linux servers running critical applications, like customer bank account database, payment system, etc. any security risk if not managed properly could cause big financial loss to your company. To manage security risk properly, first you have to know where the risks are and then search for solution to control/eliminate them. Don't give malicious person any chance, especially when he/she already finds your system's security hole while your security officers still don't know.

So what are the risks in cross server jobs on UNIX/Linux platforms?

Lets assume there is an UNIX server called alpha which is running a financial application and another one called delta running Oracle database holding customer accounts. Every week day, the application server generates a data file, which will then need to be uploaded to delta, and then a DBA will load the data into the database, and once that's done, run a data analysis tool to generate a report.

Very naturally, you won't want to use ftp to do the file transfer, because everybody know it's not secure, not just because it transfers the data in clear text, but also the authentication info.

How about use NFS? Same issue for the data transfer, not encrypted.

So, sftp or scp should be your choice, right?

Based on common sense, this is the right choice.

Now lets see what could be the security risks associated with using sftp to do the data transfer job.

First, lets assume you won't use null pass phrase in public key based authentication for sftp/ssh, because this is so dangerous: a malicious person who can access your private key is able to copy it to somewhere else and use it.

Now it's either you will use the password of an account on delta for the file transfer or you will create a key pair with pass phrase protection for the private key and then put the public key to the ~/.ssh/authorized_keys of the account on delta, and enter the pass phrase when running the sftp for connection.

When the file which needs be transferred from alpha to delta contains customers' financial information, or account password information, how could you prevent the person, who will do the file transfer job, see them?

Malicious person could use 3 ways to steal your secret pass phrase when you type it even when that person is not at your side watching you type it: if that person is logged on to the same system using same account as yours or as root, he/she could use system call tracer, like truss on AIX,Solaris, strace on Linux, to steal your pass phrase. If that person has access to root account on the system, he/she could also replace the sftp program with a Trojan Horse, record the pass phrase when you type it. Or on Solaris 10+, running a dtrace script to steal your pass phrase when you type it.

These are the risks for the pass phrase security.

There is one more big problem here: when the person or a group of people who will do the data transfer is able to transfer the data through an DBA account on delta, then how could you control this data transfer capability won't be used for something else, such as changing the DBA account's .profile to add a false transaction into the database?

Think about this also even you are using other way for the task.

Now lets see our WZIS Software's solution to this problem:

On the application server alpha:

As root:
1. Create an account in the same group as the application owner, called dataadm. And make sure this account has access to the data file generated by the application.
2. Create a normal account not in any privileged groups, called jobdoer.
3. create a script /usr/local/bin/job1
    #!/bin/sh
    cat /path/to/data/file | asshc Sam@delta "cat >datafile; command to load datafile; command to analyze data and generate report"
4. su - dataadm
5. ssh-keygen -t rsa   // to generate a key pair with pass phrase dual-controlled.
6. Put the public key into the authorized_keys file of the DBA account (assume it's Sam) on delta.
7. ssh Sam@delta ls    // make sure it works.
8. asshckey Sam@delta   // this is to create an encrypted pass phrase file.

9. cd .ssh
10. mv id_rsa asshc.key
11. mv id_rsa.pub asshc.pub
12. asshc Sam@delta ls   // make sure the asshc works.
13. /usr/local/secbin/cacl -a jobdoer /usr/local/bin/job1
14. exit
15. Change the dataadm account's shell to /bin/false, if you know how, make the account's password invalid.

OK, now the jobdoer is able to do the job:
/usr/local/secbin/cacl -e dataadm /usr/local/bin/job1

With this solution:
1. The jobdoer account is able to do the job, including loading data into database and run analysis command to generate report.
2. This account is not able to do any other things: not even to access the data file, and not even running the data loading command separately.
3. Our asshc has built-in capability to detect Trojan Horse attack and system call tracer attack, so the pass phrase security issue also fixed.

And the encrypted pass phrase file is not usable by other accounts on the same system or on different system.

So, this is a very very secure solution for implementing cross server jobs on UNIX/Linux platform.

Buy our products, your systems will be more secure!