Hur man säkrar ClusterControl-servern

I vårt tidigare blogginlägg visade vi hur du kan säkra dina databaser med öppen källkod med ClusterControl. Men hur är det med själva ClusterControl-servern? Hur säkrar vi det? Detta kommer att bli ämnet för dagens blogg. Vi antar att värden endast är avsedd för ClusterControl-användning, utan att andra applikationer körs på den.

Brandvägg och säkerhetsgrupp

Först och främst bör vi stänga ner alla onödiga portar och bara öppna de nödvändiga portarna som används av ClusterControl. Internt, mellan ClusterControl och databasservrarna, är det bara netcat-porten som spelar roll, där standardporten är 9999. Denna port behöver endast öppnas om du vill lagra säkerhetskopian på ClusterControl-servern. Annars kan du stänga detta.

Från det externa nätverket rekommenderas det att endast öppna åtkomst till antingen HTTP (80) eller HTTPS (443) för ClusterControl UI. Om du kör ClusterControl CLI som heter 's9s', måste CMON-TLS-slutpunkten öppnas på port 9501. Det är också möjligt att installera databasrelaterade applikationer ovanpå ClusterControl-servern, som HAProxy, Keepalived, ProxySQL och liknande. I så fall måste du också öppna nödvändiga portar för dessa också. Se dokumentationssidan för en lista över portar för varje tjänst.

För att ställa in brandväggsregler via iptables, gör du på ClusterControl-noden:

$ iptables -A INPUT -p tcp --dport 9999 -j ACCEPT
$ iptables -A INPUT -p tcp --dport 80 -j ACCEPT
$ iptables -A INPUT -p tcp --dport 443 -j ACCEPT
$ iptables -A INPUT -p tcp --dport 9501 -j ACCEPT
$ iptables -A OUTPUT -p tcp --dport 22 -j ACCEPT

Ovanstående är de enklaste kommandona. Du kan vara strängare och utöka kommandona för att följa din säkerhetspolicy - till exempel genom att lägga till nätverksgränssnitt, destinationsadress, källadress, anslutningstillstånd och vad inte.

I likhet med att köra installationen i molnet, är följande ett exempel på regler för inkommande säkerhetsgrupp för ClusterControl-servern på AWS:

Olika molnleverantörer tillhandahåller olika säkerhetsgruppsimplementeringar, men de grundläggande reglerna är likartade.

Kryptering

ClusterControl stöder kryptering av kommunikation på olika nivåer för att säkerställa att automatisering, övervakning och hanteringsuppgifter utförs så säkert som möjligt.

Körs på HTTPS

Installationsskriptet (install-cc.sh) kommer som standard att konfigurera ett självsignerat SSL-certifikat för HTTPS-användning. Om du väljer den här åtkomstmetoden som huvudslutpunkt kan du blockera den vanliga HTTP-tjänsten som körs på port 80 från det externa nätverket. ClusterControl kräver dock fortfarande åtkomst till CMONAPI (ett äldre Rest-API-gränssnitt) som körs som standard på port 80 på den lokala värden. Om du vill blockera HTTP-porten överallt, se till att du ändrar ClusterControl API URL under Cluster Registrations sida för att använda HTTPS istället:

Det självsignerade certifikatet som konfigurerats av ClusterControl har 10 år (3650 dagar) giltighet. Du kan verifiera certifikatets giltighet genom att använda följande kommando (på CentOS 7-servern):

$  openssl x509 -in /etc/ssl/certs/s9server.crt -text -noout
...
        Validity
            Not Before: Apr  9 21:22:42 2014 GMT
            Not After : Mar 16 21:22:42 2114 GMT
...

Observera att den absoluta sökvägen till certifikatfilen kan vara annorlunda beroende på operativsystem.

MySQL klient-serverkryptering

ClusterControl lagrar övervaknings- och hanteringsdata i MySQL-databaser på ClusterControl-noden. Eftersom MySQL i sig stöder klient-server SSL-kryptering, kan ClusterControl använda den här funktionen för att upprätta krypterad kommunikation med MySQL-servern när du skriver och hämtar dess data.

Följande konfigurationsalternativ stöds för detta ändamål:

• cmondb_ssl_key - sökväg till SSL-nyckel, för SSL-kryptering mellan CMON och CMON DB.
• cmondb_ssl_cert - sökväg till SSL-certifikat, för SSL-kryptering mellan CMON och CMON DB
• cmondb_ssl_ca - sökväg till SSL CA, för SSL-kryptering mellan CMON och CMON DB

Vi tog upp konfigurationsstegen i det här blogginlägget för en tid sedan.

Det finns dock en hake. I skrivande stund har ClusterControl-gränssnittet en begränsning när det gäller åtkomst till CMON DB via SSL med hjälp av cmon-användaren. Som en lösning kommer vi att skapa en annan databasanvändare för ClusterControl UI och ClusterControl CMONAPI som heter cmonui. Denna användare kommer inte att ha SSL aktiverat på sin behörighetstabell.

mysql> GRANT ALL PRIVILEGES ON *.* TO 'cmonui'@'127.0.0.1' IDENTIFIED BY '<cmon password>';
mysql> FLUSH PRIVILEGES;

Uppdatera ClusterControl UI och CMONAPI konfigurationsfiler som finns på clustercontrol/bootstrap.php respektive cmonapi/config/database.php med den nyskapade databasanvändaren, cmonui :

# <wwwroot>/clustercontrol/bootstrap.php
define('DB_LOGIN', 'cmonui');
define('DB_PASS', '<cmon password>');

# <wwwroot>/cmonapi/config/database.php
define('DB_USER', 'cmonui');
define('DB_PASS', '<cmon password>');

Dessa filer kommer inte att ersättas när du utför en uppgradering via pakethanteraren.

CLI-kryptering

ClusterControl kommer också med ett kommandoradsgränssnitt som kallas 's9s'. Den här klienten analyserar kommandoradsalternativen och skickar ett specifikt jobb till kontrolltjänsten som lyssnar på port 9500 (CMON) eller 9501 (CMON med TLS). Den senare är den rekommenderade. Installationsskriptet kommer som standard att konfigurera s9s CLI att använda 9501 som slutpunktsport för ClusterControl-servern.

Rollbaserad åtkomstkontroll

ClusterControl använder rollbaserad åtkomstkontroll (RBAC) för att begränsa åtkomst till kluster och deras respektive distributions-, hanterings- och övervakningsfunktioner. Detta säkerställer att endast auktoriserade användarförfrågningar är tillåtna. Tillgång till funktionalitet är finkornig, vilket gör att åtkomst kan definieras av organisation eller användare. ClusterControl använder ett behörighetsramverk för att definiera hur en användare får interagera med hanterings- och övervakningsfunktionerna, efter att de har blivit auktoriserade att göra det.

RBAC-användargränssnittet kan nås via ClusterControl -> Användarhantering -> Åtkomstkontroll :

Alla funktioner är självförklarande, men om du vill ha ytterligare beskrivning, kolla in dokumentationssidan.

Om du har flera användare inblandade i databasklustret, rekommenderas det starkt att du ställer in åtkomstkontroller för dem i enlighet med detta. Du kan också skapa flera team (organisationer) och tilldela dem noll eller fler kluster.

Körs på anpassade portar

ClusterControl kan konfigureras för att använda anpassade portar för alla beroende tjänster. ClusterControl använder SSH som huvudkommunikationskanal för att hantera och övervaka noder på distans, Apache för att tjäna ClusterControl UI och även MySQL för att lagra övervaknings- och hanteringsdata. Du kan köra dessa tjänster på anpassade portar för att minska den attackerande vektorn. Följande portar är de vanliga målen:

• SSH - standard är 22
• HTTP - standard är 80
• HTTPS - standard är 443
• MySQL - standard är 3306

Det finns flera saker du måste ändra för att köra ovanstående tjänster på anpassade portar för att ClusterControl ska fungera korrekt. Vi har täckt detta i detaljer på dokumentationssidan, Running on Custom Port.

Tillstånd och äganderätt

ClusterControl-konfigurationsfiler innehåller känslig information och bör hållas diskret och väl skyddad. Filerna måste endast vara tillåtna för användare/grupprot, utan läsbehörighet för andra. Om behörigheten och ägandet har ställts in felaktigt, hjälper följande kommando att återställa dem till rätt tillstånd:

$ chown root:root /etc/cmon.cnf /etc/cmon.d/*.cnf
$ chmod 700 /etc/cmon.cnf /etc/cmon.d/*.cnf

För MySQL-tjänst, se till att innehållet i MySQL-datakatalogen är tillåtet för "mysql"-gruppen, och att användaren kan vara antingen "mysql" eller "root":

$ chown -Rf mysql:mysql /var/lib/mysql

För ClusterControl UI måste ägandet vara tillåtet för Apache-användaren, antingen "apache" för RHEL/CentOS eller "www-data" för Debian-baserat OS.

SSH-nyckeln för att ansluta till databasvärdarna är en annan mycket viktig aspekt, eftersom den innehar identiteten och måste hållas med rätt tillstånd och äganderätt. Dessutom tillåter SSH inte användningen av en osäkrad nyckelfil när fjärrsamtalet initieras. Kontrollera att SSH-nyckelfilen som används av klustret, inuti de genererade konfigurationsfilerna under katalogen /etc/cmon.d/, är inställd på tillåten för osuser endast alternativ. Tänk till exempel på osuser är "ubuntu" och nyckelfilen är /home/ubuntu/.ssh/id_rsa:

$ chown ubuntu:ubuntu /home/ubuntu/.ssh/id_rsa
$ chmod 700 /home/ubuntu/.ssh/id_rsa

Använd ett starkt lösenord

Om du använder installationsskriptet för att installera ClusterControl, uppmuntras du att använda ett starkt lösenord när installationsprogrammet uppmanas att göra det. Det finns högst två konton som installationsskriptet kommer att behöva konfigurera (beroende på din inställning):

• MySQL cmon-lösenord - Standardvärdet är 'cmon'.
• MySQL root-lösenord - Standardvärdet är 'lösenord'.

Det är användarens ansvar att använda starka lösenord i dessa två konton. Installationsskriptet stöder ett gäng specialtecken för ditt lösenordsinmatning, som nämnts i installationsguiden:

=> Set a password for ClusterControl's MySQL user (cmon) [cmon]
=> Supported special password characters: [email protected]#$%^&*()_+{}<>?

Verifiera innehållet i /etc/cmon.cnf och /etc/cmon.d/cmon_*.cnf och se till att du använder ett starkt lösenord när det är möjligt.

Ändra MySQL 'cmon'-lösenordet

Om det konfigurerade lösenordet inte uppfyller din lösenordspolicy finns det flera steg som du måste utföra för att ändra MySQL cmon-lösenordet:

1. Ändra lösenordet i ClusterControls MySQL-server:

   $ ALTER USER 'cmon'@'127.0.0.1' IDENTIFIED BY 'newPass';
   $ ALTER USER 'cmon'@'{ClusterControl IP address or hostname}' IDENTIFIED BY 'newPass';
   $ FLUSH PRIVILEGES;

2. Uppdatera alla förekomster av 'mysql_password'-alternativ för kontrolltjänsten i /etc/cmon.cnf och /etc/cmon.d/*.cnf:

   mysql_password=newPass

3. Uppdatera alla förekomster av 'DB_PASS' konstanter för ClusterControl UI inuti /var/www/html/clustercontrol/bootstrap.php och /var/www/html/cmonapi/config/database.php:

   # <wwwroot>/clustercontrol/bootstrap.php
   define('DB_PASS', 'newPass');

   # <wwwroot>/cmonapi/config/database.php
   define('DB_PASS', 'newPass');

4. Ändra lösenordet på varje MySQL-server som övervakas av ClusterControl:

   $ ALTER USER 'cmon'@'{ClusterControl IP address or hostname}' IDENTIFIED BY 'newPass';
   $ FLUSH PRIVILEGES;

5. Starta om CMON-tjänsten för att tillämpa ändringarna:

   $ service cmon restart # systemctl restart cmon

Kontrollera om cmon-processen startas korrekt genom att titta på /var/log/cmon.log. Se till att du har något liknande nedan:

2018-01-11 08:33:09 : (INFO) Additional RPC URL for events: 'http://127.0.0.1:9510'
2018-01-11 08:33:09 : (INFO) Configuration loaded.
2018-01-11 08:33:09 : (INFO) cmon 1.5.1.2299
2018-01-11 08:33:09 : (INFO) Server started at tcp://127.0.0.1:9500
2018-01-11 08:33:09 : (INFO) Server started at tls://127.0.0.1:9501
2018-01-11 08:33:09 : (INFO) Found 'cmon' schema version 105010.
2018-01-11 08:33:09 : (INFO) Running cmon schema hot-fixes.
2018-01-11 08:33:09 : (INFO) Schema auto-upgrade succeed (version 105010).
2018-01-11 08:33:09 : (INFO) Checked tables - seems ok
2018-01-11 08:33:09 : (INFO) Community version
2018-01-11 08:33:09 : (INFO) CmonCommandHandler: started, polling for commands.

Köra det offline

ClusterControl kan hantera din databasinfrastruktur i en miljö utan internetåtkomst. Vissa funktioner skulle inte fungera i den miljön (säkerhetskopiering till moln, distribution med offentliga repor, uppgraderingar), de viktigaste funktionerna finns där och skulle fungera utmärkt. Du kan också välja att till en början distribuera allt med Internet och sedan stänga av Internet när installationen är testad och redo att servera produktionsdata.

Genom att ha ClusterControl och databasklustret isolerade från omvärlden har du tagit bort en av de viktiga attackvektorerna.

Sammanfattning

ClusterControl kan hjälpa till att säkra ditt databaskluster men det blir inte säkrat av sig självt. Ops-team måste se till att ClusterControl-servern också är härdad ur säkerhetssynpunkt.