<div id="docs-body">
 <div class="section">
  <div class="titlepage">
   <div>
    <div>
     <h4 class="title">
      <a name="mysql-cluster-security-networking-issues">
      </a>
      25.6.21.1 NDB Cluster Security and Networking Issues
     </h4>
    </div>
   </div>
  </div>
  <a class="indexterm" name="idm46045087112944">
  </a>
  <p>
   In this section, we discuss basic network security issues as
        they relate to NDB Cluster. It is extremely important to
        remember that NDB Cluster
   <span class="quote">
    “
    <span class="quote">
     out of the box
    </span>
    ”
   </span>
   is not
        secure; you or your network administrator must take the proper
        steps to ensure that your cluster cannot be compromised over the
        network.
  </p>
  <a class="indexterm" name="idm46045087109856">
  </a>
  <p>
   Cluster communication protocols are inherently insecure, and no
        encryption or similar security measures are used in
        communications between nodes in the cluster. Because network
        speed and latency have a direct impact on the cluster's
        efficiency, it is also not advisable to employ SSL or other
        encryption to network connections between nodes, as such schemes
        cause slow communications.
  </p>
  <p>
   It is also true that no authentication is used for controlling
        API node access to an NDB Cluster. As with encryption, the
        overhead of imposing authentication requirements would have an
        adverse impact on Cluster performance.
  </p>
  <p>
   In addition, there is no checking of the source IP address for
        either of the following when accessing the cluster:
  </p>
  <div class="itemizedlist">
   <ul class="itemizedlist" style="list-style-type: disc; ">
    <li class="listitem">
     <p>
      SQL or API nodes using
      <span class="quote">
       “
       <span class="quote">
        free slots
       </span>
       ”
      </span>
      created by
            empty
      <code class="literal">
       [mysqld]
      </code>
      or
      <code class="literal">
       [api]
      </code>
      sections in the
      <code class="filename">
       config.ini
      </code>
      file
     </p>
     <p>
      This means that, if there are any empty
      <code class="literal">
       [mysqld]
      </code>
      or
      <code class="literal">
       [api]
      </code>
      sections in the
      <code class="filename">
       config.ini
      </code>
      file, then
            any API nodes (including SQL nodes) that know the management
            server's host name (or IP address) and port can connect
            to the cluster and access its data without restriction. (See
      <a class="xref" href="mysql-cluster-security-mysql-privileges.html" title="25.6.21.2 NDB Cluster and MySQL Privileges">
       Section 25.6.21.2, “NDB Cluster and MySQL Privileges”
      </a>
      ,
            for more information about this and related issues.)
     </p>
     <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
      <div class="admon-title">
       Note
      </div>
      <p>
       <a class="indexterm" name="idm46045087098528">
       </a>
       <a class="indexterm" name="idm46045087096624">
       </a>
       <a class="indexterm" name="idm46045087094720">
       </a>
       You can exercise some control over SQL and API node access
              to the cluster by specifying a
       <code class="literal">
        HostName
       </code>
       parameter for all
       <code class="literal">
        [mysqld]
       </code>
       and
       <code class="literal">
        [api]
       </code>
       sections in the
       <code class="filename">
        config.ini
       </code>
       file. However, this also
              means that, should you wish to connect an API node to the
              cluster from a previously unused host, you need to add an
       <code class="literal">
        [api]
       </code>
       section containing its host name
              to the
       <code class="filename">
        config.ini
       </code>
       file.
      </p>
      <p>
       More information is available
       <a class="link" href="mysql-cluster-api-definition.html#ndbparam-api-hostname">
        elsewhere in this
              chapter
       </a>
       about the
       <code class="literal">
        HostName
       </code>
       parameter. Also see
       <a class="xref" href="mysql-cluster-quick.html" title="25.4.1 Quick Test Setup of NDB Cluster">
        Section 25.4.1, “Quick Test Setup of NDB Cluster”
       </a>
       ,
              for configuration examples using
       <code class="literal">
        HostName
       </code>
       with API nodes.
      </p>
     </div>
    </li>
    <li class="listitem">
     <p>
      Any
      <a class="link" href="mysql-cluster-programs-ndb-mgm.html" title="25.5.5 ndb_mgm — The NDB Cluster Management Client">
       <span class="command">
        <strong>
         ndb_mgm
        </strong>
       </span>
      </a>
      client
     </p>
     <p>
      This means that any cluster management client that is given
            the management server's host name (or IP address) and
            port (if not the standard port) can connect to the cluster
            and execute any management client command. This includes
            commands such as
      <a class="link" href="mysql-cluster-mgm-client-commands.html#ndbclient-stop">
       <code class="literal">
        ALL
            STOP
       </code>
      </a>
      and
      <a class="link" href="mysql-cluster-mgm-client-commands.html#ndbclient-shutdown">
       <code class="literal">
        SHUTDOWN
       </code>
      </a>
      .
     </p>
    </li>
   </ul>
  </div>
  <p>
   <a class="indexterm" name="idm46045087079488">
   </a>
   <a class="indexterm" name="idm46045087077568">
   </a>
   For these reasons, it is necessary to protect the cluster on the
        network level. The safest network configuration for Cluster is
        one which isolates connections between Cluster nodes from any
        other network communications. This can be accomplished by any of
        the following methods:
  </p>
  <div class="orderedlist">
   <ol class="orderedlist" type="1">
    <li class="listitem">
     <p>
      Keeping Cluster nodes on a network that is physically
            separate from any public networks. This option is the most
            dependable; however, it is the most expensive to implement.
     </p>
     <p>
      We show an example of an NDB Cluster setup using such a
            physically segregated network here:
     </p>
     <div class="figure">
      <a name="fig-mysql-cluster-hardware-firewall">
      </a>
      <p class="title">
       <b>
        Figure 25.7 NDB Cluster with Hardware Firewall
       </b>
      </p>
      <div class="figure-contents">
       <div class="mediaobject">
        <img alt="Content is described in the surrounding text." src="images/cluster-security-network-1.png" style="width: 100%; max-width: 700px;"/>
       </div>
      </div>
     </div>
     <br class="figure-break"/>
     <p>
      This setup has two networks, one private (solid box) for the
            Cluster management servers and data nodes, and one public
            (dotted box) where the SQL nodes reside. (We show the
            management and data nodes connected using a gigabit switch
            since this provides the best performance.) Both networks are
            protected from the outside by a hardware firewall, sometimes
            also known as a
      <span class="firstterm">
       network-based
            firewall
      </span>
      .
     </p>
     <p>
      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.
     </p>
     <div class="important" style="margin-left: 0.5in; margin-right: 0.5in;">
      <div class="admon-title">
       Important
      </div>
      <p>
       With regard to potential security vulnerabilities, an SQL
              node is no different from any other MySQL server. See
       <a class="xref" href="security-against-attack.html" title="8.1.3 Making MySQL Secure Against Attackers">
        Section 8.1.3, “Making MySQL Secure Against Attackers”
       </a>
       , for a
              description of techniques you can use to secure MySQL
              servers.
      </p>
     </div>
    </li>
    <li class="listitem">
     <p>
      <a class="indexterm" name="idm46045087060768">
      </a>
      <a class="indexterm" name="idm46045087058896">
      </a>
      Using one or more software firewalls (also known as
      <span class="firstterm">
       host-based firewalls
      </span>
      )
            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.
     </p>
     <p>
      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.
     </p>
     <p>
      This type of network setup for NDB Cluster is illustrated
            here:
     </p>
     <div class="figure">
      <a name="fig-mysql-cluster-software-firewalls">
      </a>
      <p class="title">
       <b>
        Figure 25.8 NDB Cluster with Software Firewalls
       </b>
      </p>
      <div class="figure-contents">
       <div class="mediaobject">
        <img alt="Content is described in the surrounding text." src="images/cluster-security-network-2.png" style="width: 100%; max-width: 500px;"/>
       </div>
      </div>
     </div>
     <br class="figure-break"/>
     <p>
      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
            are not part of the cluster. Applications using the cluster
            and user of those applications must
      <span class="emphasis">
       <em>
        not
       </em>
      </span>
      be permitted to have direct access to the management and
            data node hosts.
     </p>
     <p>
      To accomplish this, you must set up software firewalls that
            limit the traffic to the type or types shown in the
            following table, according to the type of node that is
            running on each cluster host computer:
     </p>
     <div class="table">
      <a name="idm46045087046176">
      </a>
      <p class="title">
       <b>
        Table 25.40 Node types in a host-based firewall cluster configuration
       </b>
      </p>
      <div class="table-contents">
       <table>
        <colgroup>
         <col style="width: 25%"/>
         <col style="width: 75%"/>
        </colgroup>
        <thead>
         <tr>
          <th>
           Node Type
          </th>
          <th>
           Permitted Traffic
          </th>
         </tr>
        </thead>
        <tbody>
         <tr>
          <td>
           SQL or API node
          </td>
          <td>
           <div class="itemizedlist">
            <ul class="itemizedlist" style="list-style-type: disc; ">
             <li class="listitem">
              <p>
               It originates from the IP address of a
                        management or data node (using any TCP or UDP
                        port).
              </p>
             </li>
             <li class="listitem">
              <p>
               It originates from within the network in which
                        the cluster resides and is on the port that your
                        application is using.
              </p>
             </li>
            </ul>
           </div>
          </td>
         </tr>
         <tr>
          <td>
           Data node or Management node
          </td>
          <td>
           <div class="itemizedlist">
            <ul class="itemizedlist" style="list-style-type: disc; ">
             <li class="listitem">
              <p>
               It originates from the IP address of a
                        management or data node (using any TCP or UDP
                        port).
              </p>
             </li>
             <li class="listitem">
              <p>
               It originates from the IP address of an SQL or
                        API node.
              </p>
             </li>
            </ul>
           </div>
          </td>
         </tr>
        </tbody>
       </table>
      </div>
     </div>
     <br class="table-break"/>
     <p>
      Any traffic other than that shown in the table for a given
            node type should be denied.
     </p>
     <p>
      The specifics of configuring a firewall vary from firewall
            application to firewall application, and are beyond the
            scope of this Manual.
      <span class="command">
       <strong>
        iptables
       </strong>
      </span>
      is a very
            common and reliable firewall application, which is often
            used with
      <span class="command">
       <strong>
        APF
       </strong>
      </span>
      as a front end to make
            configuration easier. You can (and should) consult the
            documentation for the software firewall that you employ,
            should you choose to implement an NDB Cluster network setup
            of this type, or of a
      <span class="quote">
       “
       <span class="quote">
        mixed
       </span>
       ”
      </span>
      type as discussed
            under the next item.
     </p>
    </li>
    <li class="listitem">
     <p>
      <a class="indexterm" name="idm46045087028400">
      </a>
      <a class="indexterm" name="idm46045087026496">
      </a>
      It is also possible to employ a combination of the first two
            methods, using both hardware and software to secure the
            cluster—that is, using both network-based and
            host-based firewalls. This is between the first two schemes
            in terms of both security level and cost. This type of
            network setup keeps the cluster behind the hardware
            firewall, but permits incoming packets to travel beyond the
            router connecting all cluster hosts to reach the SQL nodes.
     </p>
     <p>
      One possible network deployment of an NDB Cluster using
            hardware and software firewalls in combination is shown
            here:
     </p>
     <div class="figure">
      <a name="fig-mysql-cluster-combination-firewalls">
      </a>
      <p class="title">
       <b>
        Figure 25.9 NDB Cluster with a Combination of Hardware and Software Firewalls
       </b>
      </p>
      <div class="figure-contents">
       <div class="mediaobject">
        <img alt="Content is described in the surrounding text." src="images/cluster-security-network-3.png" style="width: 100%; max-width: 500px;"/>
       </div>
      </div>
     </div>
     <br class="figure-break"/>
     <p>
      In this case, you can set the rules in the hardware firewall
            to deny any external traffic except to SQL nodes and API
            nodes, and then permit traffic to them only on the ports
            required by your application.
     </p>
    </li>
   </ol>
  </div>
  <p>
   Whatever network configuration you use, remember that your
        objective from the viewpoint of keeping the cluster secure
        remains the same—to prevent any unessential traffic from
        reaching the cluster while ensuring the most efficient
        communication between the nodes in the cluster.
  </p>
  <p>
   <a class="indexterm" name="idm46045087014448">
   </a>
   <a class="indexterm" name="idm46045087012544">
   </a>
   Because NDB Cluster requires large numbers of ports to be open
        for communications between nodes, the recommended option is to
        use a segregated network. This represents the simplest way to
        prevent unwanted traffic from reaching the cluster.
  </p>
  <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
   <div class="admon-title">
    Note
   </div>
   <p>
    <a class="indexterm" name="idm46045087010112">
    </a>
    <a class="indexterm" name="idm46045087008240">
    </a>
    If you wish to administer an NDB Cluster remotely (that is,
          from outside the local network), the recommended way to do
          this is to use
    <span class="command">
     <strong>
      ssh
     </strong>
    </span>
    or another secure login
          shell to access an SQL node host. From this host, you can then
          run the management client to access the management server
          safely, from within the cluster's own local network.
   </p>
   <p>
    Even though it is possible to do so in theory, it is
    <span class="emphasis">
     <em>
      not
     </em>
    </span>
    recommended to use
    <a class="link" href="mysql-cluster-programs-ndb-mgm.html" title="25.5.5 ndb_mgm — The NDB Cluster Management Client">
     <span class="command">
      <strong>
       ndb_mgm
      </strong>
     </span>
    </a>
    to manage a Cluster directly from
          outside the local network on which the Cluster is running.
          Since neither authentication nor encryption takes place
          between the management client and the management server, this
          represents an extremely insecure means of managing the
          cluster, and is almost certain to be compromised sooner or
          later.
   </p>
  </div>
 </div>
 <br/>
</div>
