> > "%" means any host OTHER THAN localhost.

Actually, % _IS_ a wildcard. What you should be doing is:

GRANT SELECT,INSERT,DELETE,UPDATE on my_new_database.* to
'appuser'@'%' identified by 'uJ8xFkBTe';

To allow connections from any host. The underscore (_) is a wildcard
limited to one character. Avoid it.

If you do a grant like this:

GRANT SELECT,INSERT,DELETE,UPDATE on my_new_database.* to
'appuser'@'localhost' identified by 'uJ8xFkBTe';

Then open your connection using 127.0.0.1, it will fail. "127.0.0.1" !
= "localhost"
If you grant using a host name, use the hostname in your connection.
If you grant using an IP, then use an IP in your connection.

>
> localhost is NOT the same as "%"!
>
> "%" means any host OTHER THAN localhost.
>

And to confirm, that is not accurate. Issuing a grant using "%" as the
host name will allow a connection from ANYWHERE. Internet, localhost,
DNS-based name or IP-based name. It's a wildcard meaning to match any
characters, for any duration.

You can also do things like:

GRANT ... TO 'myuser'@'%.mynetwork.com' to allow connections from
things like alpha.mynetwork.com, beta.mynetwork.com, etc.

Can also do:

GRANT .. TO 'myuser'@'%.mynetwork.%' to allow the
'alpha.mynetwork.com', 'alpha.mynetwork.net', etc.

Michael Martinek wrote:
>> And as Peter indicated - MySQL creates a default user account at %. You
>> really shouldn't delete this for security reasons.
>
> The only "security reason" a default and anonymous user would exist is
> to assist in preventing random people from brute forcing connections.
> So this is to assume that your firewall has failed to prevent remote
> connections as it may be misconfigured.
>

Not necessarily. Sometimes you need to be able to connect remotely. I
do it on my servers regularly. And since I travel, I can't limit it to
one or two IP addresses or hosts.

There are many reasons for allowing remote connections.

> Even allowing a successful connection from anyone can be deemed a
> security risk, and you may fail many security assessments by allowing
> an anonymous connection to your server from an unknown source. How
> would it go down in the news if you could connect to an AOL internal
> database, even if you are just an anonymous user with absolutely no
> rights to do anything? How long would it be before a hacker found an
> exploit in the server running because they were able to open a
> connection and issue commands?
>

Not if you have things configured correctly. And let's see you connect
to a properly configured MySQL server anonymously and find an exploit.
The folks who develop MySQL are quite good with security - much better
than some other rather popular companies.

> One example reason you wouldn't want anonymous connections is in the
> connection string:
>
> Server version: 5.1.22-rc-log Source distribution
>

So? How many exploits do you know of for recent versions?

>
>> You deleted it, so you suffer the consequences.
> Well, I'd hardly consider security a consequence to be suffered.
> Normally, I don't allow connections from '%'.. the configuration was
> modified to show you that it is in fact very possible to connect using
> '%' as a host name; and that '%' does NOT mean accept anything EXCEPT
> 'localhost'. Advising that '%' means anything EXCEPT localhost can
> pose a security risk for anyone who believes that and implements it.
> Basic rule of securing: Deny all, allow exceptions.
>

You deleted it, and now you suffer the consequences. You've just
broadened access to your site.

>
>> And as he also said:
>>
>> Maybe those message boards are populated by people that A) can't read
>> and/or B) don't experiment.
>
> Not sure why this keeps coming up. It's just blatantly ignorant to
> claim that they aren't able to read. In fact, everything they state in
> the forum on that page is accurate. You're arguing that it is not..
> which brings us to B, which I have demonstrated for you that the
> messages on the forums are indeed accurate. Even by adding an
> anonymous account account again, which yielded no change in results.
> Before, you argued that using '%' as a hostname meant everything
> EXCEPT 'localhost', which is not the case. Now it is apparently a
> "consequence to suffer" by removing anonymous access?
>

Because it's the truth. And to use your words, it is just blatantly
ignorant to claim something when you are wrong.

And yes, it is. I was referring to the default configuration, which is
there for INCREASED security.

> There's nothing wrong with removing the anonymous user. If your system
> isn't already properly firewalled and secured, you're going to look
> like a fool as soon as someone connects to it, does a SELECT
> UNIX_TIMESTAMP() or SELECT VERSION() and goes screaming to the world
> that they connected to your database server (which may stored secure
> information), and was able to issue SQL commands to the database
> without providing a username or password; and that they can detect
> what version you're running to help pin-point known security exploits.
> Then again, maybe I'm just looking at this from the perspective of a
> company. Certifications like CISP would also require you to disable
> anonymous user accounts.
>

Only if you want to further expose your server, there isn't. MySQL has
networking because there is a need for it. The whole world does not,
nor can they, firewall their servers.

And no, CISP certification does not require you to disable anonymous
accounts. It requires you limit their actions.


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Jerry Stuckle wrote:
> Michael Martinek wrote:

<snipped>

>>
>> Using a host name of '%' works to allow connections from any host.
>>
>
> And as Peter indicated - MySQL creates a default user account at %. You
> really shouldn't delete this for security reasons.
>
> You deleted it, so you suffer the consequences.
>
> And as he also said:
>
> Maybe those message boards are populated by people that A) can't read
> and/or B) don't experiment.
>

Jerry,
May want to check this link:
http://dev.mysql.com/doc/refman/4.1/...rivileges.html

....it seems to say what Michael is saying but with a lot of variables
depending on OS. Most of the important stuff can be read without
scrolling. Scrolling down to 'Anonymous Account Removal' it explains how
this is a security improvement -on Windows-.

It seems to me that you are both right but Micheal is leaving out
some important points.

Norm

On Nov 27, 4:09 am, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> And no, CISP certification does not require you to disable anonymous
> accounts. It requires you limit their actions.
>

Applicable CISP/PCI requirements (headers from the PCI doc, off VISA's
site, https://www.pcisecuritystandards.org...dss_v1-1.pdf):

Requirement 1: Install and maintain a firewall configuration to
protect cardholder data
Requirement 2: Do not use vendor-supplied defaults for system
passwords and other security parameters
Requirement 8: Assign a unique ID to each person with computer access

Anonymous accounts allowing access without a user name and/or password
meets the criteria for a vendor-supplied default. It would also allow
users to connect to the database without identifying themselves.

My databases store credit card information and other extremely
sensitive information. Of course, not the ones I changed the hosts
on.. but after working with MSPs, and having been an employee a
leading payment gateway for a couple years. I'm familiar with what is
being looked for in PCI compliance.. and also being familiar with
cryptography and digital forensics, what damage you can actually do
just by having basic anonymous access to a database server. Even if
you're only able to determine system time, server version, etc., which
are basic privileges on built-in methods.

In my opinion, the best route to go is to rid of the anonymous
account. In absolutely any situation. There's no reason to set up a
default and anonymous account and continue to use it.. if you need
monitoring, you should set up a user login and password just for that
purpose. By leaving a blank username, an attacker would only need to
figure out the password. A username and password combination makes it
so much more difficult to attack the server; if they bypass the
firewall and ACL with the running service.

On Nov 27, 5:18 am, Captain Paralytic <paul_laut...@yahoo.com> wrote:
> > Norm, good find. Honestly, I had never seen this document before
> It is the MySQL Reference Manual for heavens sake. You have really
> never come across the Reference Manual!!!!

Ok, I'll bite.. ... That document specifically. NOT the entire MySQL
documentation.

On 27 Nov, 13:36, Michael Martinek <michael.marti...@gmail.com> wrote:
> On Nov 27, 5:18 am, Captain Paralytic <paul_laut...@yahoo.com> wrote:
>
> > > Norm, good find. Honestly, I had never seen this document before
> > It is the MySQL Reference Manual for heavens sake. You have really
> > never come across the Reference Manual!!!!
>
> Ok, I'll bite.. ... That document specifically. NOT the entire MySQL
> documentation.

Ahh, I would call that a chapter or a section.

On Nov 26, 2:34 pm, Michael Martinek <michael.marti...@gmail.com>
wrote:
>
> Actually, % _IS_ a wildcard. What you should be doing is:
>
> GRANT SELECT,INSERT,DELETE,UPDATE on my_new_database.* to
> 'appuser'@'%' identified by 'uJ8xFkBTe';
>
> To allow connections from any host. The underscore (_) is a wildcard
> limited to one character. Avoid it.
>
> If you do a grant like this:
>
> GRANT SELECT,INSERT,DELETE,UPDATE on my_new_database.* to
> 'appuser'@'localhost' identified by 'uJ8xFkBTe';
>
> Then open your connection using 127.0.0.1, it will fail. "127.0.0.1" !
> = "localhost"
> If you grant using a host name, use the hostname in your connection.
> If you grant using an IP, then use an IP in your connection.

I won't claim to be any kind of MySQL expert or to have any interest
beyond the academic in the tangent this message seems to have
followed :-), but I will offer this:

I tried:
GRANT SELECT,INSERT,DELETE,UPDATE on mynewdatabase.* to
appuser@localhost identified by 'uJ8xFkBTe'; (no underscores in db
name)
GRANT SELECT,INSERT,DELETE,UPDATE on mynewdatabase.* to appuser
identified by 'uJ8xFkBTe'; (implied host)
GRANT SELECT,INSERT,DELETE,UPDATE on mynewdatabase.* to 'appuser'@'%'
identified by 'uJ8xFkBTe'; (quoted user/host values)
GRANT SELECT,INSERT,DELETE,UPDATE on mynewdatabase.* to appuser@%
identified by 'uJ8xFkBTe'; (unquoted user/host values)

Nothing worked until I created two users - one for localhost and one
for "%". I can offer no explanation for that, only the empirical
observation resulting from hours (hours, I tell you) of frustration.
Now I'll go try to read the rest of this thread (and the docs it
references) more carefully and see whether it helps me figure out why
that's the case...

Thanks, all.

Michael Martinek wrote:
>> ...it seems to say what Michael is saying but with a lot of variables
>> depending on OS. Most of the important stuff can be read without
>> scrolling. Scrolling down to 'Anonymous Account Removal' it explains how
>> this is a security improvement -on Windows-.
>>
>
> Norm, good find. Honestly, I had never seen this document before as I
> tend to just follow a "Deny all, allow exceptions" rule. But I'm
> curious as to why this would be an improvement on only Windows. The

Just to make things clear, I am no expert. I can only write what I
find. I simply meant to state the difference between Windows and Linux
(Ubuntu - me too) in that both accounts on linux are set up local only
whereas in Windows one is allowed from anywhere.

> anonymous accounts on Unix are limited only to localhost, according to
> this document. Removing this access is only an improvement, regardless
> of operating system, as it limits who can access the database for any
> reason. Since some encryptions used are based on system time, being
> able to determine the exact time of the server can be considered a
> security problem.
>
> There are instructions for removing the anonymous accounts (Which is
> the step I always go with, both on an operating system level, as well
> as any installed servers, clients, etc). The one part that really
> catches my attention is:
>
> " As noted, none of the initial accounts have passwords. This means
> that your MySQL installation is unprotected until you do something
> about it:
> * If you want to prevent clients from connecting as anonymous
> users without a password, you should either assign a password to each
> anonymous account or else remove the accounts. "
>
> So by this document, it sounds to me like MySQL's standpoint is "Turn
> the anonymous account into a user account which has no name by setting
> a password, or just delete the account."
>

I believe they mean for an admin to set up passwords for those
accounts (rather than delete) so that you always have an account to use
that has root (all) privileges. Could you change your own privileges to
the point that you could not restore them without logging in as root to
fix. I don't know.

> To clarify, all the tests I did earlier were on an Ubuntu
> distribution. The only involvement of Windows was a MySQL connection
> from a system in my network.
>
> These are the discussions I really enjoy. Hopefully we can keep a
> friendly one going and share our points of view. To that, I apologize
> to you, Jerry, if I came off as being rude. I certainly respect your
> point of view and am interested in hearing anything you're willing to
> bring to this security, configuration, and usage discussion.. even if
> we ended up hi-hacking a completed thread.
>
> Regards,
> Michael Martinek

Norm

Michael Martinek wrote:
>> ...it seems to say what Michael is saying but with a lot of variables
>> depending on OS. Most of the important stuff can be read without
>> scrolling. Scrolling down to 'Anonymous Account Removal' it explains how
>> this is a security improvement -on Windows-.
>>
>
> Norm, good find. Honestly, I had never seen this document before as I
> tend to just follow a "Deny all, allow exceptions" rule. But I'm
> curious as to why this would be an improvement on only Windows. The
> anonymous accounts on Unix are limited only to localhost, according to
> this document. Removing this access is only an improvement, regardless
> of operating system, as it limits who can access the database for any
> reason. Since some encryptions used are based on system time, being
> able to determine the exact time of the server can be considered a
> security problem.
>
> There are instructions for removing the anonymous accounts (Which is
> the step I always go with, both on an operating system level, as well
> as any installed servers, clients, etc). The one part that really
> catches my attention is:
>
> " As noted, none of the initial accounts have passwords. This means
> that your MySQL installation is unprotected until you do something
> about it:
> * If you want to prevent clients from connecting as anonymous
> users without a password, you should either assign a password to each
> anonymous account or else remove the accounts. "
>
> So by this document, it sounds to me like MySQL's standpoint is "Turn
> the anonymous account into a user account which has no name by setting
> a password, or just delete the account."
>
> To clarify, all the tests I did earlier were on an Ubuntu
> distribution. The only involvement of Windows was a MySQL connection
> from a system in my network.
>
> These are the discussions I really enjoy. Hopefully we can keep a
> friendly one going and share our points of view. To that, I apologize
> to you, Jerry, if I came off as being rude. I certainly respect your
> point of view and am interested in hearing anything you're willing to
> bring to this security, configuration, and usage discussion.. even if
> we ended up hi-hacking a completed thread.
>
> Regards,
> Michael Martinek

....further thought puts me in Jerrys' camp. 'localhost', '127.0.0.1',
etc. are all local (or loop-back), I don't believe '%' is, thereby
making it everything except local.

Norm