"Aborted_connects" Increasing Mysteriously

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

Hi everyone

I'm using the "MySQL Administrator" program to keep tabs on the health of a
web system i am developing.  I think it's nice to have quick (gui) feedback
on the query cache, memory variables, and other status variables.

I've noticed that one of the status variables, "Aborted_connects" has been
increasing steadily.  This is defined by MySQL as "Number of tries to
connect to the MySQL server that failed".  I googled around a bit, and the
only reference I found was a suggestion to double-check php code.  So, I
double-checked my php code but everything closes the mysql connection

Since the system is in development, and I am the only person who knows the
IP of where to log in and test it, I decided to restart the MySQL server,
not visit the website at all, and use MySQL Administrator to monitor
whether or not any status variables changed.  Sure enough,
"Aborted_connects" is increasing by one every ten minutes or so despite no
activity on the website (it's been 30 minutes and I have three aborted
connects).  To double-check that the website hasn't been used, I can see
under Performance that no "SELECTS" have been made since restarting the

What could be causing this?  Is someone *really* trying to hack into my
MySQL server (once every ten minutes?!)?  Is it something in the MySQL
Administrator program itself that is causing the aborted connects?  Is it
something to be concerned about?  "Connections" (number of connection
attempts) has also been increasing...

I should mention that port 3306 is open, it's running Red Hat Linux, and
it's MySQL 4.1.x (Can't remember)

Any ideas appreciated!  

Re: "Aborted_connects" Increasing Mysteriously

Among the wreckage we found a fragment on which Good Man had scratched:

Quoted text here. Click to load it

Why not run ethereal and see for yourself?

Re: "Aborted_connects" Increasing Mysteriously

Quoted text here. Click to load it

Tis a fact of modern life that there are scads of computers out there
dedicated to the discovery of live IP addresses and when found, to bang away
with usr/pwd combinations. The human scoundrels behind this activity are
only awakened when the automation discovers an IP/usr/pwd combo that scores
a hit.

If you have an IP address that sends/receives packets over the Internet,
then you are most certainly not "the only person who knows the IP..".
Quoted text here. Click to load it

The unauthorized entry attempts are a given.  And it will take some
vigilance on your part to verify that these are not successful.

Quoted text here. Click to load it

Not a "someone".  It's a computer program run by an usncrupulous "someone"
and the answer is yes.  It's probably nothing personal.  As I said, any and
every IP address that both sends/receives is a target.

Quoted text here. Click to load it

Quoted text here. Click to load it
You need to get over the fact that the attempts are being made but you do
need to put mechanisms in place to see that they are not successful. And you
*especially* need to know when someone is successful in gaining unauthorized

Quoted text here. Click to load it
The longer your IP is up, the more it becomes known as a "live" IP and the
more unauthorized entry attempts it will attract.

It is becoming increasingly popular to dedicate entire computers to serve as
a firewall.  These spend all their cpu horsepower on rejecting unauthorized
entry attempts and passing along the few legitimate ones to the server.

Quoted text here. Click to load it

Difficult and non-obvious user names and passwords.
Eternal vigilance.
Rapid discovery of unauthorized access followed immediately by new user
names and passwords.

Thomas Bartkus

Re: "Aborted_connects" Increasing Mysteriously

Quoted text here. Click to load it

it just seems like a weird way to hack into a database.  when i look at my
apache server attacks, they last for about an hour with 5-10 login attempts
each minute.  now that's an attack!  that's the way *i* would try to break
in - not by trying a mysql database with one password and moving on.   so
it seems like a weird way of trying to break into the server, and i'm still
not convinced its an automaton/person with nefarious desires.

Quoted text here. Click to load it

you know, the site is being hosted (managed hosting) by Rackspace, and
they're offering a hardware firewall for $200/month.  That seems like a
totally outrageous price - i'd rather ship them a crappy pc from my house
and have them set up a firewall with that.   do you really think a firewall
is needed?  how would it know what an unauthorized attempt is?  surely it
will need to be open to the MySQL & Apache servers anyways?


Re: "Aborted_connects" Increasing Mysteriously

Quoted text here. Click to load it

Well, I would agree.
All you can say is that at such and such a time, some one tried to log on
with an invalid usr/pwd.  How often do I miskey my own password? - very

Still - I think you see that your IP address is never a secret and that it
will there will be many knocks on the door by people simply looking for a
(any) door that will open for them.

Quoted text here. Click to load it

It depends.  How much cpu does your server/software firewall spend fending
off unauthorized entry?
The only thing I really *know* is that this sort of thing tends to increase
over time.  The longer your IP is out there, the more it becomes known as a
hack target.  Will it level off eventually?  Is it degrading performance
I wish I could give you answers but we are struggling with this issue

Quoted text here. Click to load it
I don't have the answer for MySQL.  I wish someone else would jump in here
because I would like to look at a log myself that shows me "who" was trying
and failing.  I don't know where to find that kind of record for MySQL like
I can for the apache server.

I am scrupulously looking over the logs at the successful log ons and trying
to verify them.  Kind of like the way your credit card company will
(hopefully!) detect suspicious charge activity and give you a call when they
record a charge in Las Vegas after you just charged a tank of gas in NJ five
minutes ago.

I'm looking for software myself!
Thomas Bartkus

Quoted text here. Click to load it

Re: "Aborted_connects" Increasing Mysteriously

Quoted text here. Click to load it

This description of the "Aborted_connects" status variable is misleading.
I get log messages in hostname.err often:

Date time [Warning] Aborted connection NNNN to db: database, user:
username ost: host.do.main (Got an error reading communication packets).
and at the same time, Aborted_connects gets incremented.

This does not mean that someone is trying to hack into your database.
(nor does it mean that they aren't, but this message is not a sign
of it).  The given database,username,host.do.main logged in
SUCCESSFULLY, then killed the connection.  And it is one of the
logins I created.

I'm running MySQL 5.0.6, but this particular issue has been going
on since the early 3.23.* versions.

At first the real meaning of this appeared to be:  ONE OF YOUR PHP
PAGES FORGOT TO CALL mysql_close(), DUMMY!  After I fixed that on
several pages, it turns out that the remaining offenders are mail
transport programs using the database for spam filtering, which
open up a connection, make some queries, and just abruptly die
rather than closing (mysql_close()) the connection cleanly.  I
haven't been able to find a hook to make them close the connection
cleanly, so for error messages mentioning the logins used for that
purpose, I ignore them.

Quoted text here. Click to load it

If you think about it a little, everyone with even a small amount
of knowledge about the Internet knows a complete list of *ALL* IP
addresses, even if they don't bother writing out each individual
one.  There aren't any secret ones, like the alleged phone numbers
with * and # in the area code used by the government for tin foil
hat distribution.  There's plenty of scanning going on for MySQL
servers; my firewall blocks a lot of them (typically a couple an
hour, 24x7).  If you avoid giving out any MySQL user logins valid
from ANY host, you may not really need a firewall; absent major
security holes, MySQL can protect itself, and dictionary attacks
don't work from hosts not allowed to log in at all.

                        Gordon L. Burditt

Site Timeline