I think you're complicating an already quite simple thing.
1. Most major databases support permissions. Use these liberally to
seperate those who only need access to the database to view contents on
a single table and those who should be able to alter one table or one
database and ONLY that table/database.
Fixes: People from looking at, or modifying things which are not theirs.
2. Throw scripts with passwords in them (i.e. $password = 'foo') into a
directory which has the following properties:
a. it is readable only by the owner of the script, directory, and the
scripting language.
b. it is not writable by anybody but the owner.
c. it has an .htaccess file or is dissallowed access without a
password using an Apache directive in the main Apache config file.
Fixes: Several things:
i. Random users on the server who have shell access can't just:
$ less ./script
Nor can they:
$ cd ./directory
Unless they *have a reason* to.
ii. Even users who have access to the cgi-bin directory don't
necessarily have access to the directory to the script's directory. So
they can just tell the program to execute the file but not read it.
(Note: I think clever users could figure out a way to read in the
script. Perhaps you could make the script executable only, or nested --
i.e.:
#! /usr/bin/perl
`./protected_dir/script`
)
3. Tell the database to only accept connections from localhost (or
127.0.0.1 -- or the domain names you need to access it)
Fixes: Let them get the password. If they're not on the right IP
address (which they obviously won't be if they don't have access in the
first place). To prove the point to you try accessing the mySQL
database on mathjunkies.com with username: perlbeginner password:
beginner and database: perlbeginner . It won't work. Why? Because
mathjunkies.com (my server) only accepts connections from localhost.
4. Run the database on a port or socket other then it's default.
Fixes: Any script kiddies port scanning your server won't be able to
readily identify the port on your server's function. (Of course any
bonafide hackers could probably figure out its function by watching the
traffic into and out of the port, or something similarly clever -- but
that's a different issue)
5. Encrypt database transmissions -- mySQL, and Postgresql, (and
probably Oracle and some others) allow you to use SSL certificates to
keep your transmissions private. Use them if you plan on accessing the
database from anywhere other then localhost.
Fixes: Anybody sniffing your packets will get garbage.
All of this stuff is fairly basic and outlined in the various manuals of
the respective programs I have mentioned. It won't make you
impenetrable -- but it will go a long way towards making your box
secure.
-Dan
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
