I am very frustrated with ISPConfig3. While I like the test system once installed, I cannot get the real one to work in the very basic way needed. I need it to work the way that is standard practice for any companies with IPS, needing PCI compliance, or with any need for security beyond the basic home user. Please tell me how to connect an ISPConfig3 server with a remove MySQL server. Or please point me toward a HowTo that I have missed.I have been working on this problem on and off for over a year! I posted this thread which has basically been ignored: https://www.howtoforge.com/community/posts/344072/ I have modified the install script and can get it to tell me that the install is complete and successful, but then it cannot run. Further checking reveals the database is empty. Populating the database from a working test system does not work - ISPConfig3 cannot connect to the fully populated MySQL server either. PLEASE, I have tried to be patient. I have tried to be courteous. But I (we) NEED help with this problem. I CANNOT be the only one who needs this. I beg for the developers and community not to continue to overlook this basic requirement. Thanks, Kyle
PCI compliance does not requiere to disable the mysql-server. Just make sure, that the server is not reachable from the outsided (if this is a master-server just allow connections from the slave).
It has bee described in several threads that ISPConfig uses a local MySQL database as config cache to make the system scalable and fault tolerant, this local database does not has to be accessible from outside as Florian pointed out. So your request is basically to remove scalability, fault tolerance and security from ISPConfig by using a central database server, you might understand that these aspects are important for all the large ISP setups that run ISPConfig and we will not downgrade the software to be less stable, secure and fault tolerant just because this is not important for you and I doubt that pci compliance forbids to setup a scalable, secure and fault tolerant system. Using a local MySQL database as config cache like ISPConfig is doing it is just a way to write files to disk on the server, please point out where PCI compliance forbids a server system to write data to its local harddisk.
AMaybe as addition, please do not mix up the ispconfig local database which is used for ispconfig internally only with the databases for websites, which can be on one or more dedicated MySQL servers off course, see multiserver tutorials.
Actually there are two PCI DSS requirements in play here that require what Kyle is trying to do. The first one has to do with the network segmentation requirements for PCI. There has to be a dedicated DMZ where Internet accessible hosts are, and any PCI auditor will tell you that you can't store data in the DMZ. If an auditor sees that you are running a DB server in the DMZ, that is an automatic finding, and a double finding if it doubles as a web server. The second one has to do with the separation of functions. Here is a direct quote from the DSS document: "Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. (For example, web servers, database servers, and DNS should be implemented on separate servers.)"
I see that you and Kyle don't understand how ISPConfig works and therefore think that it's default multiserver setup does not comply with pci while there is no problem at all. ISPConfig does not store data in the local database of a multiserver setup, What ISPConfig stores there is just the configuration for the local services of this one node as this is required for fast access and fault tolerance. Data for websites is stored in a central database in multiserver setups anyway as I pointed out and as it is described in the ISPConfig multiserver guide. So the rule that you may not store data in the DMZ does not apply to ispconfig here, or does the rule forbids to store the config for the hosted services like apache on the node that runs the apache service? Beside that, the local config cache on an ispconfig server can be restricted to localhost, so it's not accessible from outside anyway. That's exactly what ISPConfig is doing, you should really read the Multiserver tutorial. The guide describes how to run a central MySQL database server, dedicated web server and DNS server and all websites use the central db server as data storage, no data is stored o the other nodes, the other nodes just contain the config which is essential to run the dedicated service on that specific node. You can also separate the controlpanel interface from the web server, add more web servers that use one or more dedicated database servers and so on.
You are correct in that I don't know the internals of ispconfig, but I have been through enough PCI audits to know that a database server in the DMZ will not pass an audit, especially when that database stores unencrypted credentials to other critical areas where data is kept. So essentially what I am reading here is that ispconfig will break if the config DB is not local on the frontend server, correct? That is hard-coded somewhere?
Great, so another point where the ISPConfig setup passes PCI as ISPConfig does not store any unencrypted passwords like some other panels do. It just means that it is not supported and not tested. But the source code is open, feel free to modify your local copy in the way you want. Just we will not remove or alter features in a way that lower the security, reliability, or scalability of ISPConfig.
What you can do without modifying the ispconfig sources is: 1) Install it locally. 2) Move the database to an exteral server and find all occurrences of the database details in /etc and /usr/local/ispconfig and change them to the external DB server. But be aware if you addslave nodes then, the external DB server will become the master server so you have to use the hostname of the db server then as master server name when you install slaves.
Reversible encryption is insecure as it is possible to get the cleartext passwords back for anyone who has the key, as this key would have to be placed on all nodes that need to verify passwords, a hack of one node would allow it to get all cleartext passwords. Thats why ISPConfig does not use it and hashes the passwords with an individual salt for each password instead, so even if you get all passwords from the database, it is very unlikely you ever get the cleartext password back and even if you break one password, the other passwords are still protected..
