PHP4/MySQL security on public server 
Author Message
 PHP4/MySQL security on public server

Hi,

I need to deploy PHP4/MySQL on a public OpenBSD3.2 server as soon as
possible. I've researched this in the manuals, on the web, and in the
newsgroups and am somewhat bewildered. (It's all installed, but not yet
enabled.)

There are clearly two aspects:
   - General server security: for instance I will only be running PHP
scripts locally, so will disable e.g. remote MySQL access. Likewise I figure
on putting the PHP scripts themselves outside of ftp space, as I currently
do with all CGI.
   - Specific database security: setting up users and permissions on a
dbase/table basis within MySQL. Presumably application-specific.

So far so good, but I've now read so much I've made my head spin. Perhaps
this is inevitable. Is there a fast-start guide or a checklist (ideally
relevant to doing this under OpenBSD) anywhere? Is "best practice"
documented somewhere that I'm missing?

All responses (even if only RTFM) gratefully received. I'd like to get this
right - my server is otherwise as secure as I can make it, and I'd hate to
compromise it through my ignorance.

TIA,

Steve
--
http://www.*-*-*.com/ - SFD: Solutions by Design
http://www.*-*-*.com/ - ecommerce for independent musicians



Sat, 30 Jul 2005 23:39:16 GMT  
 PHP4/MySQL security on public server

Quote:
> There are clearly two aspects:
>    - General server security: for instance I will only be running PHP
> scripts locally, so will disable e.g. remote MySQL access. Likewise I figure
> on putting the PHP scripts themselves outside of ftp space, as I currently
> do with all CGI.

Also, make sure you turn on safe mode in 'php.ini'. It's not perfect, but
it stops users readfile()ing each others scripts and database
passwords.  If you give them shell access, things get even more
complicated, because the file has to be readable by the web server.
Playing around with group permissions can fix this problem.

Safe mode does stop some things working, and make others very
difficult, that you might ordinarily want to do (file uploads, for
example), but unless you trust every user, every script owner, on the
server, it's definitely a trade-off worth paying.

If I've misunderstood you a bit, and you aren't going to let users put
scripts up directly (or you *are* the only user), then you can
probably keep safe mode off.

Quote:
>    - Specific database security: setting up users and permissions on a
> dbase/table basis within MySQL. Presumably application-specific.

Yep.  Try and keep the priviliges of the database users to a minimum.
Don't give any of them the FILE privilige (read data into table from a
file) unless you trust them, because that can circumvent safe mode.
This probably worth doing even if you're the only user, so in case the
MySQL server gets compromised it can't compromise anything else as easily.

Quote:
> So far so good, but I've now read so much I've made my head spin. Perhaps
> this is inevitable. Is there a fast-start guide or a checklist (ideally
> relevant to doing this under OpenBSD) anywhere? Is "best practice"
> documented somewhere that I'm missing?

There's various security guides about.  The MySQL manual has a good
section on database priviliges and setting them up, which you
definitely need to read if you haven't already.

Likewise, there's a bit in PHP on safe-mode and other security.

Hope this helps

--
Chris



Sat, 30 Jul 2005 23:53:43 GMT  
 PHP4/MySQL security on public server

Quote:

> There are clearly two aspects:
>    - General server security: for instance I will only be running PHP
> scripts locally, so will disable e.g. remote MySQL access. Likewise I
> figure on putting the PHP scripts themselves outside of ftp space, as I
> currently do with all CGI.
>    - Specific database security: setting up users and permissions on a
> dbase/table basis within MySQL. Presumably application-specific.

> So far so good, but I've now read so much I've made my head spin. Perhaps
> this is inevitable. Is there a fast-start guide or a checklist (ideally
> relevant to doing this under OpenBSD) anywhere? Is "best practice"
> documented somewhere that I'm missing?

It sounds like you've got your system pretty well locked down already.  I
think the best path is to continue reading the manuals as you are doing --
after all, there is a possibility that a list might not cover 100%.  If you
know the systems you're administrating very well, then you've got less
chance of it going tits-up.

Important thingd to note:

* ensure MySQL uses UNIX sockets instead of the network (--skip-networking)
* all users have to use passwords (root starts with no password)
* don't run the MySQL daemon as root (duh), create a mysql user.
* don't support symlinks to tables (--skip-symlink)
* ensure permissions for mysql data dir are rw for mysql user only
* use IP rather than hostnames in grant tables

I advise you to pick up a copy of the MySQL Reference Manual (0596002653)
from O'Reilly Community Press, which is where most of the above tips come
from.

NOTE: as of MySQL 4.0 it is possible to use SSH to encrypt internal
connections [PARANOIA] :).

Regards,

David

--
David Jonathan Grant
http://www.davidjonathangrant.info/



Sat, 30 Jul 2005 23:57:28 GMT  
 PHP4/MySQL security on public server

Quote:
> Also, make sure you turn on safe mode in 'php.ini'. It's not perfect, but
> it stops users readfile()ing each others scripts and database
> passwords.  If you give them shell access, things get even more
> complicated, because the file has to be readable by the web server.
> Playing around with group permissions can fix this problem.

Noted.

Quote:
> If I've misunderstood you a bit, and you aren't going to let users put
> scripts up directly (or you *are* the only user), then you can
> probably keep safe mode off.

I will indeed be the only guy with script access. I don't let my users
upload scripts directly (not just a trust issue, it's an ftp-accessibility
issue). So safe mode sounds like a Good Plan.

Quote:
> Yep.  Try and keep the priviliges of the database users to a minimum.
> Don't give any of them the FILE privilige (read data into table from a
> file) unless you trust them, because that can circumvent safe mode.
> This probably worth doing even if you're the only user, so in case the
> MySQL server gets compromised it can't compromise anything else as easily.

Again noted and sensible.

Thanks a lot - just the kind of input I was hoping for.

Steve
--
http://www.sfdesign.co.uk - SFD: Solutions by Design
http://www.fivetrees.com - ecommerce for independent musicians



Sun, 31 Jul 2005 00:23:47 GMT  
 PHP4/MySQL security on public server


Quote:

> It sounds like you've got your system pretty well locked down already.  I
> think the best path is to continue reading the manuals as you are doing --
> after all, there is a possibility that a list might not cover 100%.  If
you
> know the systems you're administrating very well, then you've got less
> chance of it going tits-up.

Yes, you're right, of course. I know the rest of my system very well
(OpenBSD rocks! ;)). And I've been running PHP4/MySQL on my home server,
behind a firewall (two, actually) for quite a while. But am now under
pressure to deploy in public and exposed... and am daunted by the amount of
reading material I need to assimilate in no time. As I said, am conscious
that I could be opening a can of worms...

Quote:
> Important thingd to note:

> * ensure MySQL uses UNIX sockets instead of the network

(--skip-networking)

Yes, I'd grokked that one. Vital!

Quote:
> * all users have to use passwords (root starts with no password)

Erm... not sure about this. The only access I figure on giving users is via
web pages, running scripts outside of ftp space. Given that the password(s)
is(are) stored in cleartext within the PHP, this doesn't seem like strong
security - or at least not as strong as keeping the scripts out of
userspace. I will not be giving users script access - is this what you
meant?

Quote:
> * don't run the MySQL daemon as root (duh), create a mysql user.

Indeed. OpenBSD (did I mention it rocks?) does this by default.

Quote:
> * don't support symlinks to tables (--skip-symlink)

Excellent point. Noted.

Quote:
> * ensure permissions for mysql data dir are rw for mysql user only

Noted.

Quote:
> * use IP rather than hostnames in grant tables

Presumably because hostnames can be spoofed?

Quote:
> I advise you to pick up a copy of the MySQL Reference Manual (0596002653)
> from O'Reilly Community Press, which is where most of the above tips come
> from.

I seem to have an excess of books on PHP/MySQL, and an excess of books from
O'Reilly, and have become wary of anything other than reference books (too
often 95% is about the author's pet project). But since this one is a
reference book, I've added it to my Amazon wanted list ;). Thanks for the
tip. Sounds like the angle might (finally!) be right for someone like me.

Quote:
> NOTE: as of MySQL 4.0 it is possible to use SSH to encrypt internal
> connections [PARANOIA] :).

I stick to the ports/packages system provided with OpenBSD, therefore I'm
sticking to the MySQL version supplied with OBSD3.2 (3.23.49, IIUC). Where
they lag behind the mainstream release, they usually do so for good reasons.
So, despite the fact that [PARANOIA] definitely applies to me, MySQL 4.0
does not.

Fab! Thanks for the input.

Steve
--
http://www.sfdesign.co.uk - SFD: Solutions by Design
http://www.fivetrees.com - ecommerce for independent musicians



Sun, 31 Jul 2005 00:46:20 GMT  
 PHP4/MySQL security on public server

Quote:

> > * all users have to use passwords (root starts with no password)

> Erm... not sure about this. The only access I figure on giving users is via
> web pages, running scripts outside of ftp space. Given that the password(s)
> is(are) stored in cleartext within the PHP, this doesn't seem like strong

MySQL users rather than web users.

MySQL encrypts passwords with an irreversible method (though not
crypt() or md5() based, as far as I can tell).  You need this somewhat
less if only local connections are allowed.  In fact, if you have a
database that's *supposed* to be site-readable, then creating a
'guest' user with no password and SELECT privilige only on that table
isn't so bad a way to go about it.  Though creating a guest user with
a password and telling the appropriate people the password is probably
better if there isn't an unfeasible number of them.

--
Chris



Sun, 31 Jul 2005 00:54:05 GMT  
 PHP4/MySQL security on public server

Quote:
> MySQL users rather than web users.

Yes, understood, but the only MySQL users will be PHP scripts which I'll
have moved out of ftp space, and (probably) it'll be me that adds the
db_connect part. IOW, the only person who needs to know this is me.

Quote:
> MySQL encrypts passwords with an irreversible method (though not
> crypt() or md5() based, as far as I can tell).  You need this somewhat
> less if only local connections are allowed.  In fact, if you have a
> database that's *supposed* to be site-readable, then creating a
> 'guest' user with no password and SELECT privilige only on that table
> isn't so bad a way to go about it.  Though creating a guest user with
> a password and telling the appropriate people the password is probably
> better if there isn't an unfeasible number of them.

Also understood - see above. Hopefully this covers it; if I have
misunderstood, please let me know! ;)

Thanks.

Steve
--
http://www.sfdesign.co.uk - SFD: Solutions by Design
http://www.fivetrees.com - ecommerce for independent musicians



Sun, 31 Jul 2005 01:00:56 GMT  
 PHP4/MySQL security on public server

Quote:

> (OpenBSD rocks! ;)).

I promise to switch when my Debian box gets comprimised.. :P

Quote:
>> * use IP rather than hostnames in grant tables

> Presumably because hostnames can be spoofed?

Indeed.

Just thought of another one.  When logging into MySQL to do maintenance,
make sure you don't start it up with the password on the command line.  Use
the following instead:

mysql -h 127.0.0.1 -u root -p

To get yourself a password prompt.  It'd be a shame to be so careful just
to lose it to a ps -ef | grep mysql :)

Regards,

David

--
David Jonathan Grant
http://www.davidjonathangrant.info/



Sun, 31 Jul 2005 01:10:55 GMT  
 PHP4/MySQL security on public server

Quote:

> MySQL users rather than web users.

Beat me to it! :)

Quote:
> MySQL encrypts passwords with an irreversible method (though not
> crypt() or md5() based, as far as I can tell).  You need this somewhat
> less if only local connections are allowed.  In fact, if you have a
> database that's *supposed* to be site-readable, then creating a
> 'guest' user with no password and SELECT privilige only on that table
> isn't so bad a way to go about it.  Though creating a guest user with
> a password and telling the appropriate people the password is probably
> better if there isn't an unfeasible number of them.

You could skip the part about telling users the passwords by forcing them
to include a file outside the area where the web files are served from.

Regards,

David

--
David Jonathan Grant
http://www.davidjonathangrant.info/



Sun, 31 Jul 2005 01:04:23 GMT  
 PHP4/MySQL security on public server

Quote:
> You could skip the part about telling users the passwords by forcing them
> to include a file outside the area where the web files are served from.

Oh, and tangentially to that, you'll either have to educate users not
to put passwords in files called 'header.inc', or modify your server
not to serve .inc files out (at least, not before passing them through
the PHP processor).

--
Chris



Sun, 31 Jul 2005 01:22:40 GMT  
 PHP4/MySQL security on public server


Quote:
> Just thought of another one.  When logging into MySQL to do maintenance,
> make sure you don't start it up with the password on the command line.
Use
> the following instead:

> mysql -h 127.0.0.1 -u root -p

> To get yourself a password prompt.  It'd be a shame to be so careful just
> to lose it to a ps -ef | grep mysql :)

Heh! Understood.

However on my box here I just type "mysql" as root...

On that subject: I presume command-line utilities such as mysql & mysqldump
need not be any more tied down? I'm the only login user on the system ATM,
and I always login via SSH...

Steve
--
http://www.sfdesign.co.uk - SFD: Solutions by Design
http://www.fivetrees.com - ecommerce for independent musicians



Sun, 31 Jul 2005 01:23:59 GMT  
 PHP4/MySQL security on public server

Quote:
> Oh, and tangentially to that, you'll either have to educate users not
> to put passwords in files called 'header.inc', or modify your server
> not to serve .inc files out (at least, not before passing them through
> the PHP processor).

Again, my script policy is strict and this won't arise. As with all CGI, the
only place that PHP files will exist (and be recognised as such by the
server) will be outside of userspace, effectively in a cgi-bin jail.

Steve
--
http://www.sfdesign.co.uk - SFD: Solutions by Design
http://www.fivetrees.com - ecommerce for independent musicians



Sun, 31 Jul 2005 03:27:18 GMT  
 PHP4/MySQL security on public server
On Tue, 11 Feb 2003 17:10:55 +0000, David Jonathan Grant

Quote:

>> (OpenBSD rocks! ;)).

>I promise to switch when my Debian box gets comprimised.. :P

>>> * use IP rather than hostnames in grant tables

>> Presumably because hostnames can be spoofed?

>Indeed.

>Just thought of another one.  When logging into MySQL to do maintenance,
>make sure you don't start it up with the password on the command line.  Use
>the following instead:

>mysql -h 127.0.0.1 -u root -p

>To get yourself a password prompt.  It'd be a shame to be so careful just
>to lose it to a ps -ef | grep mysql :)

A decent OS will hide the password

If you start mysql as

  mysql -uroot -pWHATEVER

"ps -ef | grep mysql" should give you

  mysql -uroot -pXXXX

It does on all our systems at work.



Sun, 31 Jul 2005 06:08:23 GMT  
 PHP4/MySQL security on public server

Quote:

> A decent OS will hide the password

> If you start mysql as

>   mysql -uroot -pWHATEVER

> "ps -ef | grep mysql" should give you

>   mysql -uroot -pXXXX

> It does on all our systems at work.

Just noticed:  It does on mine as well. :)  Still, you *shouldn't* rely on
that.

Regards,

David

--
David Jonathan Grant
http://www.davidjonathangrant.info/



Sun, 31 Jul 2005 08:28:51 GMT  
 PHP4/MySQL security on public server

Quote:


>> A decent OS will hide the password

>> If you start mysql as

>>   mysql -uroot -pWHATEVER

>> "ps -ef | grep mysql" should give you

>>   mysql -uroot -pXXXX

>> It does on all our systems at work.

> Just noticed:  It does on mine as well. :)  Still, you *shouldn't*
> rely on that.

When mysql starts, it looks at the command line to see if you've specified
the password there. If you have, *then* it overwrites it with X's.

It's possible that someone doing a ps between startup and overwrite will see
your password. More in the manual...

--
Nick Grimshaw



Mon, 01 Aug 2005 23:11:53 GMT  
 
 [ 18 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Any public postgresql/mysql server on Internet?

2. PHP4 & MySQL webdevelopment chp:29 Forms

3. MySQL locally vs. MySQL on server

4. Need some MySQL and PHP security advice

5. microsoft.public.security.virus

6. Security Issues of Labview Web Server?

7. Using remote MySQL server with PHP via HTTP

8. Connecting to mySQL on Unix server

9. Ruby DBI, MySQL and Win2K Server

10. Executing a dump of a remote mysql server

11. Connection to remote server with MySQL under Win/2K

12. MySQL/PHP with redundant slave servers

 

 
Powered by phpBB® Forum Software