Database Security Issue: users from any domain allowed even if remote access off

Discussion in 'Installation/Configuration' started by winsbury, Dec 15, 2020.

  1. winsbury

    winsbury Member

    On a Ubuntu 'Perfect' server with MariaDB under ISPconfig, if the database name, user and password is known then any local domain can access any local database even if the databases are specifically configured not to allow remote access.

    This has very serious security implications if one either knows the credentials for one of the other domain's databases ( or can guess /hack them ) or can get hold of an account on shared server that has hosts the victim's database.

    Is there a configuration that prevents this 'feature' ? I would like to lock down the database such that sql can only be run from the named domain that owns that particular database and not from ANY other domain whether on the local server or via remote access.

    I stumbled on this when I restored a website to a fresh tld on the same server only to find the clone logged itself into the original database !
     
  2. till

    till Super Moderator Staff Member ISPConfig Developer

    There is no security issue here and no security implications at all. What prevents another user from accessing a database on the same server is the username and password of that database, that's why a username and password is used. Btw, this is the case for any hosting or IT system, not depending on ISPConfig and not even depending on a specific database system. If you want to prevent that other users which have the correct login credentials for a database can access that database, then you must install a separate server for each user.
     
    ahrasis likes this.
  3. till

    till Super Moderator Staff Member ISPConfig Developer

    This assumtion makes no sense at all, that's as if you say: All locks are insecure, you only need the right key to open it ;)
     
    ahrasis likes this.
  4. winsbury

    winsbury Member

    On the contrary, it caused a major headache today and wasn't immediately obvious the database was being accessed from outside the domain but from the same server especially since the option to disallow remote connections was enabled. Such a scenario could occur on any production system that has a clone taken for dev purposes. There absolutely should be a way of ring fencing access to databases to the owner only. It is quite conceivable ( though would be numpty to do so, but it's not unheard of ) for someone to create a database 'mydatabase' with user 'user' password 'password' so I disagree that passwords are inherently secure.
     
  5. Jesse Norell

    Jesse Norell ISPConfig Developer Staff Member ISPConfig Developer

    Another way to phrase the original concern is, "even if I prohibit remote access, local access is still allowed," which of course makes perfect sense when stated that way.

    What you want is effectively to limit which linux use can use a given mysql user; to my knowledge there is no way to restrict that within mysql, so any solutions would involve a separate mysql server for each website as @till said. Possibly you could find an sql relay to use which could enforce that? I haven't looked for one, but such a thing might exist.
     
  6. till

    till Super Moderator Staff Member ISPConfig Developer

    MySQL and MariaDB have the following access restrictions:

    1) Host or IP. All scripts and programs that run on the same server, share the same IP and host, that's why all websites on the same server can access a database when the other 3 parameters are correct.
    2) database name.
    3) Username.
    4) password.

    MySQL lets you log in to a database only if all 4 requirements match.
     
    ahrasis likes this.
  7. winsbury

    winsbury Member

    yes, exactly.

    Maybe naive of me but I thought that was the purpose of stating the site to which a database is allocated during creation of the database within ISPconfig3. If it has no effect then why is this field even there ?
     
  8. Jesse Norell

    Jesse Norell ISPConfig Developer Staff Member ISPConfig Developer

    Not naive, simply a misunderstanding of what it does.
    I've not exhaustively searched what all the field does, but in a quick look at adding database users and databases, the database user ties to a client, and a database is assigned to a website, and assigned a database user. With that you can enforce client limits, limit what database servers are available, automate the removal of databases when the website or the client is deleted, ensure only the correct client can display database usage or change info, etc. So it certainly does have a purpose, but creating and enforcing a new layer of permissions on top of what the database server itself provides is not it.
     
  9. till

    till Super Moderator Staff Member ISPConfig Developer

    That's not related to database access permissions. The site has to be selected to be able to assign the database to the correct ISPConfig client and apply client limits like database size quota plus this automates the process to grant access to the right host system when you are in a multiserver system.
     
  10. winsbury

    winsbury Member

    I guess this goes to underline that setting unique database names and strong usernames and passwords is crucial. I am still unconvinced that it is wise not have some kind of 'firewall' internally on a server to prevent one tld being able to use database resources of another and it would certainly make it easier to restore content from one domain to another to create duplicates ( for live and dev for example ) without interference.
     
  11. till

    till Super Moderator Staff Member ISPConfig Developer

    I would say that is common knowledge for IT administrators.

    Then you should dig deeper into the topic and learn more about the technology behind the scenes when a php script on a web server connects to a database via a TCP/IP connection to understand why 'a tld' in an apache or nginx vhost file does not matter at all here when the websites are on the same server. I've explained already in post #2 what you have to do to achieve that kind of 'firewall' that you want to get, you need a dedicated server or virtual server with a dedicated database system on it for each website.
     
  12. winsbury

    winsbury Member

    Indeed, that seems to be the logical conclusion and the entire point of this thread.
     
  13. Jesse Norell

    Jesse Norell ISPConfig Developer Staff Member ISPConfig Developer

    A quick search found one relay that you could probably use, http://sqlrelay.sourceforge.net/sqlrenterprise/modules/configure_mysql_frontend.html

    It supports native mysql clients, but doesn't appear to match system user IDs, so you would just have to set it up so that each website had a dedicated port or socket location. The socket could be protected with regular filesystem permissions, or dedicated ports could be protected with iptables (I believe there is a module that matches the system user of the connections process). If course the actual mysql socket and/or port needs similarly protected so only sql relay can access it.

    You would probably also want to disable the global phpmyadmin install.
     
  14. winsbury

    winsbury Member

    Interesting. I like that it can be used as a middleware to scale to distributed systems and allow use of other rdms backends and adds the feature you point out about giving each domain the option of choosing a dedicated port but I imagine there will be performance effects. IIUIC the list of limitations states it doesn't support tls so db passwords and query data would be sent in the clear which might be okay behind a firewall or run within a single machine (subject to logs not containing any sensitive data) but that is not good on a public facing server so at first glance it may introduce more weak points than it fixes. Even small ecommerce sites are often exchanging sensitive customer information and the penalties nowadays are extreme for data breaches.
     

Share This Page