MySQL impossible suspicious connections - mysql

I have a MySQL Community service binded locally to "bind-address=127.0.0.1", bind that suppose no expose it to the internet.
I can't connect externally. However i'm receiving constantly on the log this kind of errors:
[Server] IP address '194.**.16.73' could not be resolved: This is usually a temporary error during hostname resolution and means that the local server did not receive a response from an authoritative server.
[Server] Host name 'hos*<probabily a malicious site>*nnet.biz' could not be resolved: No such host is known.
With a lot of addreses supicious (including TOR exit points).
I see this thread Suspicious Connections to My Database x.x.x.x Could Not Be Resolved
But didn't respond the main question:
How is possible that kind of requests without internet access?
What does fire this? Ok i understand, server want to nslookup it, but, what are trying from that hosts? It's dangerous?
If someone can bring ligth to my life I will be very grateful.
Thanks.

Related

Error Connect MySQL Communications link failure The last packet sent successfully to the server was 0 milliseconds ago

I am trying to connect to a MySQL database from Data Fusion, but I am getting the following error. Communications link failure The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server. The database is accessed through public IP through port 3306, from my machine I can connect perfectly, but from Data Fusion I cannot.
As John Hanley pointed out in his comment, it's probably due to a connectivity issue with your SQL instance.
A possible reason would be that you have not enabled your instance to be connected via its public IP. If that's the case, go to your SQL instance and edit its configuration, adding a network (if you haven't done so previously) and providing an IP range to include your Data Fusion instance. Keep in mind that if you configure your instance to accept connections using its public IP address, also configure it to use SSL to keep your data secure. If that was the issue, now you should be able to connect properly.
Also, be sure to check that the Dataproc cluster that your data Fusion instance is using under the hood has the proper configuration (you shouldn't worry about this if you haven't changed anything about the Dataproc cluster).
This is the best advice I can give without further details. If this doesn't work for you, we're going to need more information.
My two cents:
I use one windows pc with several linux box at home.
My main station is the Windows one.
I'v been using Sqlyog just to prob tables on the remote db.
I use my class C addr. to address the server.
It works well. By design I want to access the db server
from anywhere in my home...
60% to 75%ishhh problems of that kind would be related
to the .cnt file configuration.
Regards
Steph

MySQL stuck or network issue?

we have mysql-server(5.5.47)that hosted on physical server. It listen external internet interface(with restrict user access), mysql server intensively used from different places(we use different libraries to communicate with mysql). But sometimes whole mysql server(or network) stuck and stop accept connection, and a clients failed with etimedout(connect)/timeout(recv), even direct connection from server to mysql with mysql cli not working(stuck without any response — seems to be try to establish connections).
First thought was that it is related to tcp backlog, so mysql backlog was increased — but this not help at all.
Issue not repeatable, so last time when this issue happened we sniff traffic, and what we get:
http://grab.by/STwq — screenshot
*.*.27.65 — it is client
*.*.20.80 — it is mysql server
From session we can assume that tcp connection established, but server retransmit SYN/ACK to client(from dump we see that server receive ACK, why retransmit ?), but in normal case mysql must generate init packet and send to client, after connection was established.
It is only screen from 1 session, but all other sessions mostly same, SYN -> SYN/ACK -> ACK -> and server retransmit SYN/ACK up to retries_count.
After restart mysql all get normal immediately after restart. So not sure it is related to network or mysql.
Any thoughts would be appropriate.
Thank you!

Lost connection to MySQL server at 'reading initial communication packet', system error: 0 on a windows machine

I found similar questions but none of them helped me with a windows machine.
I was able to connect to mySQL through my local machine. However, I have placed MySQL on a remote machine and when I try to connect to it, I get the following error:
Lost connection to MySQL server at 'reading initial communication packet', system error: 0
Im using SQL workbench to connect. I use the remote machine's actual name for the hostname and using port 139. I have MySQL started up as a service on the remote machine as well. When googling the error I get lots of jazz about editing a file in /etc/hosts.allow and my.cnf and whatnot. However, these locations were specified for linux machines. I have a windows 7 machine for both my local and the remote machine and therefore do not have these locations.
Any help would be greatly appreciated.
I am not going to pretend that I know what caused this problem but it could be:
1.That you need to add
AllowTcpForwarding yes
to this file: /etc/ssh/sshd_config. Obviously since you are on windows you need to find its equivalent because that's a linux filepath.
2.It could be your firewall. Try temporarily disabling it (if it is safe to do so) and see if it works. If this is the case you will need to grant MySQL access through the firewall.
3.Try writing
mysqld: ALL: allow
In the file /etc/hosts.allow again since you are on windows you need to find its equivalent because that's a linux filepath. Now this may kind of be a security whole in some ways but who cares about security when you don't have a running server?
4.Now the last this is to check /etc/hosts.deny your IP might be there denying you access to your server.
Figured it out. 'root' was pointing to the root of the local machine and the root user on the remote machine was pointing to itself. So I had it connect to an admin user and it connected fine with no errors. Thanks for for the responses and help guys.

ATTACK ON AWS RDS MySQL .static.midphase.com resembles IPv4-address itself

I'm running EC2 with MySQL RDS to serve dynamic websites' content.
The server was down due to 'too many connection' error on RDS database.
As it was urgent, I restart database server straight away and the problem gone.
However, I'm unable to see what queries produce those connection (as I didn't run SHOW PROCESS LISTS before reboot RDS).
CloudWatch show 250+ connections during period of issue which is obviously huge distinction from normal operating on other days.
I try to address the issue by see log in RDS, but there is quite a minimal message there.
The error message
2014-05-03 06:10:08 3628 [Warning] IP address '173.244.206.19' has been resolved to the host name '173.244.206.19.static.midphase.com', which resembles IPv4-address itself.
From above, 173.244.206.19 is not in our IP list both public and private. (but connection open to 0.0.0.0 secured with password which I'm going to limit IP remote in security group soon)
Questions
Is 173.244.206.19.static.midphase.com is something to do with RDS by default. I think this is obviously an attack sign but just would like to confirm.
What does 'resembles IPv4-address itself' mean? As this is RDS database server only, why server does need to resolve DNS?
Are there any way to digging into this for further detail (e.g. to see specific query).
I'm going to prevent this by only limit the IP access along with CloudWatch alarm setting for 10+ connections. Anything else I should do.
Thank you for reading through this guys. I'm the only developer in company start-up which take care for all front-end/backend/application/network. Therefore, apology if there are dummy questions out here.
However, your help would be really appreciated and will save a bit of my life writing the report.
You are maybe the target of a DDOS attack or a brute-force password discovery attempt.
I would report this to AWS support - as they can help to mitigate the effect of the attack.
As a best practice, we do not recommend to use 0.0.0.0/0 as source IP address for incoming connection rule in Security Group.
Try to restrict which IP addresses are authorised to connect to your database.
If you are accessing from on prem network, specify only your on-prem address range.
If you're accessing your database from an app server installed on EC2, use the ID of the App Server Security Group (sg-xxxx) as source authorised to connect to your database.

Connecting to remote MySQL problems

Having a bit of a problem with mysql...
Mysql 5.1 on windows 2008 server iis7
Site on windows 2003 server iis6
[sorry but can't move to linux kids! ;)]
In the process of shifting a site to a new server so I have moved the database 1st and connected the site to the new database. I tested the connection before moving but now the site is connecting to the new database I am having problems....
connecting via PDO the page hangs for an age before getting 'too many connections' error. Monitoring the server I see MANY threads of: 'unathenticated user' from the ip address of the host the site runs on.
I also see a thread for the connection with the correct user name in my config file and I am a total loss as to what is going on.
Any help would be very much appreciated
'unathenticated user' from the ip address of the host the site runs on
A stab in the dark, but this could be some script or process trying to connect to the database server with wrong or empty credentials.
Also, here's a report from somebody who had similar problems - in that case, it was the DNS lookup that caused the problem.
I had a similar situation on my setup where the database lived on a different host than
the webserver. I found the "unauthenticated users" were connections from the webserver
that were hanging on DNS lookups. Don't know if this is a mysql bug or a bug with my
firewall / other setup, but a couple of fixes I found were...
1) start mysql with --skip-name-resolve (you may have to change your mysql permission
tables to have the host's IP instead of hostname, including localhost)
or 2) add the connecting host to your /etc/hosts file.