Score:0

What would initiate MariaDB to start to resolve IP addresses?

in flag

In my Windows Logs > Application I see these Warnings

IP address 'xxx.xxx.xxx.xxx' could not be resolved: No such host is known.

The IP is unknown to me. These Warnings get logged as:

Log Name: Application
Source: MariaDB
Event ID: 100
Level: Warning

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  - <System>
      <Provider Name="MariaDB" /> 
      <EventID Qualifiers="49152">100</EventID> 
      <Version>0</Version> 
      <Level>3</Level> 
      <Task>0</Task> 
      <Opcode>0</Opcode> 
      <Keywords>0x80000000000000</Keywords> 
      <TimeCreated SystemTime="2021-12-16T23:32:07.8659376Z" /> 
      <EventRecordID>2182760</EventRecordID> 
      <Correlation /> 
      <Execution ProcessID="0" ThreadID="0" /> 
      <Channel>Application</Channel> 
      <Computer>vm-white</Computer> 
      <Security /> 
    </System>
  - <EventData>
      <Data>IP address 'xxx.xxx.xxx.xxx' could not be resolved: No such host is known.</Data> 
    </EventData>
</Event>

I am hosting WordPress sites and also Matomo (an open source web analytics application.) Could this be somehow trying to use MariaDB to go look up rDNS entries to bind to?

What else would do that? A malicious WordPress plugin?

I am confused.


I tried

[mysqld]
bind-address = 127.0.0.1

to see if it would influence these logged Warnings; but somehow my websites took longer to load. So I undid it. All my users are set-up to use localhost and not 127.0.0.1. Based on this skip-name-resolve info I probably would be better off disabling name resolving -- and it could explain why I do get these Warnings if they go away.


Bob suggested to check my firewall setting. I made some adjustments and will keep checking the logs for any changes.

firewall settings for MariaDB


Now, just got this Warning

IP address '34.96.130.11' has been resolved to the host name '11.130.96.34.bc.googleusercontent.com', which resembles IPv4-address itself.

cn flag
Bob
At first glance the root of your problem is that you expose the database server to the internet at large, when it is intended as an internal service rather than a public one. Check and adjust your firewall settings for the default port 3306 or whatever port MariaDB is configured to use.
MeSo2 avatar
in flag
@Bob I changed my firewall settings, but just got another DNS resolver _Warning_. Should I add a firewall outbound setting to prevent MariaDB from connecting outwards as well?
Nikita Kipriyanov avatar
za flag
As to your last warning, it's "too suspicious". Someone added a code which compares the IP address as dotted quad and the result of the PTR query, and produces this warning. I don't need think this is very useful. PTR could be set to anything, that is up to the IP address owner discretion, you can never rely on it, so one should never assume it is correct, official, polite, nice and so on, therefore the comparison is silly. Ignore this warning as useless.
Nikita Kipriyanov avatar
za flag
`bind-address = 127.0.0.1` is a *most correct and secure* way to set it up if you don't need to connect to DB from other hosts. Actualy that also should appear *faster*. How do you specify DB server in the applications? The best way would be to use just `localhost` or even `127.0.0.1` as DB host name in the applications.
MeSo2 avatar
in flag
@NikitaKipriyanov at first I was connecting using `localhost` with my asp code app via MariaDB ODBC driver, like this `DRIVER={MariaDB ODBC 3.1 Driver};TCPIP=1;SERVER=localhost;UID=____;PWD=____;DATABASE=____;PORT=3306;CONN_TIMEOUT=120;CHARSET=utf8mb4;READ_TIMEOUT=20;WRITE_TIMEOUT=5;Option=3`. Now having changed it to `127.0.0.1` made it very responsive. Nice!
Score:1
za flag

While it is possible to restrict access to the DBMS server using the firewall, it is better to not to make it accessible from the Internet in the first place. That way it would be most secure.

You tried it the correct way:

[mysqld]
bind-address = 127.0.0.1

It is strange it appeared unresponsible when connected using localhost. Instead, it should appear faster, because OS communicating via loopback interface hopefully avoids some layers in the network stack. This may mean some name resolution (e.g. DNS or hosts) problem on the machine. It is wise to avoid name resolution in this case, using the literal localhost IP address 127.0.0.1. Just specify it in the connector as the DBMS server address.


The last warning about the hostname "which resembles IPv4-address itself" is useless. The hostname is the result of the DNS query, and the value of the host name in the PTR record is completely controlled by the IP address owner. They can put anything into it, it can be made similar to the IP address itself, or similar to some other IP address (for greater confusion), or be a joke, or a poem line, or be rough and crude. It conveys no valid information for you to consider in the context of security. Just ignore this warning, or better yet, turn off such warnings entirely and don't waste resources on such silly comparisons.

MeSo2 avatar
in flag
Having changed my Users to `127.0.0.1` had an unexpected positive side effect to this other question I had: https://serverfault.com/questions/1086062/stop-event-id-4625-remote-logon-request-over-logon-process-ntlmssp Very nice! This answer is not really what I was after, but it made my day.
Nikita Kipriyanov avatar
za flag
I feel that was an example of XY problem, resolved, because you explained for what you need this and we closed the root cause, instead of solving the problems you've got with listening on public address. As to the formal answer, I feel you didn't configured the firewall correctly. I never trusted those "profiles" of domain/private/public. Are you completely sure about what is "private" in this case? The explicit rule would work better and more reliable, where you were to list all allowed IP addresses, both of them (the server public IP and localhost).
MeSo2 avatar
in flag
I did not know that MariaDB would (or could) start resolve IP addresses. And so the part I am still not clear about is what would trigger this behavior. All I am doing is host a simple web application. It just is a strange behavior for a database to do this on every visitors call. I also do not trust these "profile" settings much; I do prefer using "Interface Types" to block things. FYI "Private" is defined as: _The private profile is a user-assigned profile and is used to designate private or home networks_. Why would I include the server's public IP (my DNS is also hosted locally.)
Nikita Kipriyanov avatar
za flag
No, this is not strange in case of MySQL. Remember you specify hostnames when you create users and assign privileges, e.g. `GRANT privileges ON \`db.table\` TO 'username'@'hostname' IDENTIFIED BY 'password'`. It really records this hostname into `mysql.user.Host` field and checks the reverse DNS to match during authentication. Usually `localhost` or `%` is used, e.g. access is given ether to only the server itself or to any address (using MySQL wildcard) but you can have tighter control. I use this feature on one cluster.
MeSo2 avatar
in flag
Am I right to assume that this would now indicate that I am experiencing [SQL injection attacks](https://en.wikipedia.org/wiki/SQL_injection)? I have nothing (to my knowledge) in my code that would request an outside connection.
Nikita Kipriyanov avatar
za flag
No. SQL Injection is always done through some breach in the application. It injects a malicious query into application's valid one, so from the database standpoint that'll be the application is connecting in its full right, but doing some nasty things. The log you've seen shows an attempt to connect to the database directly. It's like SSH/FTP/RDP/whatever passwords scanning, only with MySQL/MariaDB.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.