[thelist] Apache on Win32

[David Altherr]

As for the blocking ports via software: here is a review of ZoneAlarm with
links to several other software options:
http://www.zdnet.com/products/stories/reviews/0,4161,2576071,00.html


Also, if you have not yet set the password for root in MySQL, make sure you
do so; use the following syntax (can be used to set the password of any
user, providing the current user has acces to the mysql database) :

SET PASSWORD FOR 'root' = PASSWORD('foorootpwd');
or to specify against a specific host:
SET PASSWORD FOR 'root'@'localhost' = PASSWORD('foorootpwd');

and you may want to setup seperate users for accessing the database via the
PHP scripts depending on the functionality of your site/application:

GRANT SELECT,INSERT,UPDATE,DELETE ON db_name.* TO 'phpadmin'@'localhost'
IDENTIFIED BY 'fooadminpwd' WITH GRANT OPTION;

GRANT SELECT ON db_name.* TO 'phpuser'@'localhost' IDENTIFIED BY
'foouserpwd';

The former statement is useful if you have seperate forms for admin of the
system.  Of course the privileges specified in the both statements will
vary, again, depending on the functionality of your site/application; you
may want to specify the INSERT parameter if there is intended user
interaction with the data or you may have various levels of users and
admins: explicitly specifying the privileges in MySQL can catch some script
security holes depending on your user and data management systems. You can
drop the "IDENTIFIED BY 'foopwd'" clause in either of the statements to
allow the scripts access without a password, if you like: said clause is the
equivalent of using the SET PASSWORD statement on the user.

In the event that you do store database passwords in plaintext within files
or scripts (not recommended, but sometimes necessary) and ever intend for
the scripts to run on a shared filesystem or public server, then it is
imperative, IMO, that you set up limited privilege accounts.  The security
hole is that anyone else running PHP on that same filesystem may be able to
view the source of your scripts, get any plaintext logins and passwords, and
then upload potentially desctructive scripts with access to your database as
per the privileges of the users in the scripts.  If they grab the password
for rootuser, then they can probably destroy your database, but if they can
only grab the password for phpuser, their scripts will only be able to read
from the database, or perform limited interaction with the data (e.g. INSERT
if granted); the most they could hope for is to annoy your host, fill your
database with a lot of foobar, or create a temporary denial of service, but
little chance for destruction of data.

In such a situation, a more secure route might be to have, on the remote
host's database, a 'phpuser' validated only against 'localhost' and a
'phpadmin' validated only against your local IP address (if static), or
against any IP in the same class B or class C subnet (if not static: e.g.
validate against '216.178.%' or '216.178.156.%', typically unchanging for a
given ISP), thus allowing the admin functions to be performed only from
scripts running on your local machine.  In that situation you would want to
validate your IP in PHP or Apache when running the local admin scripts (only
use Apache for validation if you do not plan on serving anything else to
outside machines from the local machine).  The only problem is that some
hosts will allow databases running on their servers to be accessed only from
'localhost'. Also note that some hosts have disabled certain PHP functions;
the one's that your host has disabled may or may not close some security
holes; check with your host: good info to know, regardless.

-David Altherr
www.davidaltherr.net


> I've deleted all the entries in the host table except the one where
> host=localhost and user=root.
>
> How safe am I against someone with a port scanner? Does anyone know if
there
> is a way to block outside access to all my ports with ZoneAlarm? Or should
I
> invest in a LinkSys Router/Firewall?
>
> Thanks for everyone's help,
>
> Beau
>

> Or, avoiding the REVOKE syntax, even simpler solutions would be:
>
> to set all the host to localhost:
> UPDATE mysql.user SET host='localhost';
>
> or to simply remove the users not validated against localhost (REVOKE does
> not remove the user):
> DELETE FROM mysql.user WHERE host!='localhost' AND host!='127.0.0.1';
>
> be careful with the last one; make sure you have your user or root user
> explicitly validated against 'localhost' before running 'FLUSH
PRIVILEGES';
>
> -David Altherr