1

Does anybody know what is the best way to secure bash scripts. I have a script which creates database and source code backup and ftp it to other server. And login/password for destination ftp are plain text. I need somehow encrypt it or hide it in case of website hacking. Or should i create script written on C to create bash file then run it and delete ? Thanks.

Thanks for the answers and I am sorry, i wasn't clear enough. I would like to clarify my question in the following items.

  1. We are storing the data in Rackspace Cloud files.
  2. We can't pull as Cloud files doesn't allow you run a script.
  3. We can write the script to run on Server A and pull FTP and MySQL data on servers B, C, D, etc. And we want to protect the passwords on A from the situation where A is hacked. Can we compile our script file to hide them?

Thanks

minnur
  • 115
  • 7
  • 2
    I think the question needs to be better defined. Which end needs to be more secure? Is the script which creates databases on the more secure system or is it a CGI which runs on the web server? As it is, there are too many possibilities to answer your question. A re-write would help, where you say what is going on with Server A, and then what is going on on Server B, and which one you are more concerned with securing. Do you already know about scp, ssh keys and chmod? – labradort Nov 30 '09 at 20:28
  • I agree here, in that more info is required. Is this script to be run unattended (which is what I assume) or by a person? What are you trying to protect, the backed-up data or the ftp password? In reality, if the server gets hacked, both are in trouble. Do you have any control over the remote FTP server (can you pull from there, rather than push, as someone else suggested)? Too many unknowns at this time to give a decent answer. – Geoff Fritz Dec 01 '09 at 00:03

4 Answers4

3

You can't "secure" credentials when they have to be available in plaintext for use. Obfuscation and encoding (or "encrypting", if you'd like to use that term) them isn't anything except security-by-obscurity (which isn't actually security, and is arguably worse than nothing since it can give you a false sense of security).

You're better off re-thinking your strategy to perform some type of "pull" of the data from a less exposed machine than trying to "hide" credentials "in plain sight".

(See also: credit card fraud, ACH fraud, identity "theft", and other stupid real-world examples of security-by-obscurity not working particularly well. "Secrets" that have to be shared openly aren't secret, by definition.)

Evan Anderson
  • 141,071
  • 19
  • 191
  • 328
2

I've used the following approach to secure the password in bash scripts. The same approach would work for username as well if you wish to keep that hidden. This approach isn't encryption but assuming the permissions on the files in question are set correctly it will keep the average system user from seeing the details which you want to be hidden. If you're system is hacked however then this approach will not do much since they probably would have root access at that point.

At the top of the script setup a variable that looks like so.

MY_PASS=`cat /path/securepasswordfile`

Create a text file with just the password in it and then secure it with file permissions so that only the account that runs the script can read this file.

Then to access this in your script just use something like the following.

$MYSQL_DUMP -A --host=$SERVER -u root -p$MY_PASS > $BACKUP_DIR/database/backup.sql
3dinfluence
  • 12,409
  • 2
  • 27
  • 41
  • 1
    Why not just make the script readable only to the user who will be executing it -- won't that achieve the same level of 'security'? – Gegtik Nov 30 '09 at 21:17
  • Yeah that will have the same affect. I answered this question based on our messed up environment here at work where all the scripts live in a global bin folder. This was done before I started. This has been my work around for a layer of security in case someone chmod/chown the directory. There may be some weird dependencies involved that requires this but I can't think of any. I bet this was started out of habit and stuck when it should have been rethought. Thanks for the comment b/c it's making me think about how our environment is setup and how it should probably change. – 3dinfluence Nov 30 '09 at 22:40
  • You do realize that even using this convoluted method of sending the password to bash results in the password being viewable with a `ps` command? – Joel G Mathew Jun 10 '13 at 10:53
1

Quoting 3dinfluence, above:

$MYSQL_DUMP -A --host=$SERVER -u root -p$MY_PASS > $BACKUP_DIR/database/backup.sql

Note that on some distros, this will result in the password showing up in the output of 'ps'.

woodw096
  • 11
  • 1
0

No matter what you try, you cannot do what you are trying to do, as you are trying to do it. If you think about it, no matter how hard you try to encrypt the data, ultimately all the data there is available.

Perhaps the better option is to have the remote side ssh in and run those commands? That is what we do at work -- one very secure machine ssh's into clients and backs them up. The backup machine itself does not allow remote ssh, etc.

BTW, if you're using FTP, your password is transmitted in plaintext already...

Michael Graff
  • 6,588
  • 1
  • 23
  • 36
  • Not necessarily - there's this magic thing called "FTP over SSL". And yes it can be used for data streams too. (I don't think the poster uses SSL though.) – user1686 Nov 30 '09 at 20:34
  • FTP over SSL is a royal PITA compared to simply using SFTP or SCP. First off, you must configure it correctly to encrypt the control channel (where your username & password travels). Secondly, configuring a firewall to pass FTPS/FTPES is much more involved and likely to be problematic since the normal method that hardware firewalls use to identify the data channel (by snooping the control channel) is unavailable. – Greeblesnort Nov 30 '09 at 21:36