NDB Cluster Security Issues This network setup is safest because no packets can reach the cluster’s management or data nodes from outside the network—and none of the cluster’s internal communications can reach the outside —without going through the SQL nodes, as long as the SQL nodes do not permit any packets to be forwarded. This means, of course, that all SQL nodes must be secured against hacking attempts. With regard to potential security vulnerabilities, an SQL node is no different from any other MySQL server. See Section 6.1.3, “Making MySQL Secure Against Attackers” , for a description of techniques you can use to secure MySQL servers. The host-based option is the least expensive to implement, but relies purely on software to provide protection and so is the most difficult to keep secure. This type of network setup for NDB Cluster is illustrated here: Using this type of network setup means that there are two zones of NDB Cluster hosts. Each cluster host must be able to communicate with all of the other machines in the cluster, but only those hosting SQL nodes (dotted box) can be permitted to have any contact with the outside, while those in the zone containing the data nodes and management nodes (solid box) must be isolated from any machines that 4603 Important 2. Using one or more software firewalls (also known as  host-based firewalls ) to control which packets pass through to the cluster from portions of the network that do not require access to it. In this type of setup, a software firewall must be installed on every host in the cluster which might otherwise be accessible from outside the local network. Figure 23.29 NDB Cluster with Software Firewalls