Avoimet tietokantaportit: MySQL, PostgreSQL, MongoDB, Redis ja Elasticsearch internetissä

Tietokantaportti on avoinna, kun kuka tahansa internetissä voi avata siihen yhteyden. Sovelluksenne tarvitsee yhteyden tietokantaan, satunnainen tietokone toisessa maassa ei. Silti yksi palomuurisääntö, muutettu asetusrivi tai pilvipalvelun oletusasetus voi saada MySQL:n, PostgreSQL:n, MongoDB:n, Redisin tai Elasticsearchin vastaamaan koko internetille.

Avoin portti ei automaattisesti tarkoita tietomurtoa. Jos tunnistautuminen on vahva ja ohjelmisto ajan tasalla, hyökkääjän on yhä päästävä niiden ohi. Avoin portti tekee tietokannastanne kuitenkin kohteen, jota kuka tahansa voi tutkia, jonka salasanoja voi yrittää arvata ja jota voi testata tunnettujen haavoittuvuuksien varalta. Kun portti suljetaan, koko tämä riskiluokka poistuu.

Tässä artikkelissa luetellaan oletusportit, näytetään, miten tarkistus tehdään ulkoa, ja kerrotaan, miten portit suljetaan oikein.

Oletusportit, jotka kannattaa tuntea

Nämä ovat oletusportit kunkin valmistajan dokumentaation mukaan:

• MySQL: 3306 perinteiselle protokollalle, 33060 X Protocolille.
• PostgreSQL: 5432.
• MongoDB: 27017 prosesseille mongod ja mongos.
• Redis: 6379, kuten oletustiedostossa redis.conf on määritetty.
• Elasticsearch: HTTP API ensimmäisessä vapaana olevassa portissa väliltä 9200 ja 9300, yleensä 9200, ja siirtokerros vastaavasti väliltä 9300 ja 9400.

Palvelut voivat toimia myös muissa porteissa, joten pitäkää tätä luetteloa lähtökohtana, älkää kattavana tarkistuksena.

Miten tietokannat päätyvät internetiin

Useimmat näistä tuotteista ovat oletuksena turvallisempia kuin ennen:

• PostgreSQL:n listen_addresses on oletuksena localhost.
• MongoDB sitoutuu oletuksena localhostiin.
• Redis toimii versiosta 3.2.0 alkaen suojatussa tilassa (protected mode), kun se kuuntelee kaikkia liitäntöjä ilman salasanaa, ja vastaa silloin vain paikallisille asiakkaille.
• Elasticsearch 8.0 ja uudemmat ottavat tietoturvan käyttöön automaattisesti ensimmäisellä käynnistyskerralla.

Siksi altistuminen johtuu yleensä tietoisesta muutoksesta, jonka piti olla väliaikainen:

• joku asetti bind-address = 0.0.0.0, listen_addresses = '*' tai bindIpAll, jotta kehittäjä pääsisi yhteyteen kotoa,
• suojattu tila tai tietoturva kytkettiin pois, jotta asia "saataisiin toimimaan",
• pilven tietoturvaryhmä tai palomuurisääntö sallii portin osoitteesta 0.0.0.0/0,
• Dockerin -p 6379:6379 julkaisee portin isäntäkoneen jokaisessa liitännässä,
• vanhaa testi- tai staging-palvelinta omine tietokantoineen ei koskaan sammutettu.

Redisin dokumentaatio puhuu riskistä suoraan: Redis on suunniteltu luotetuille asiakkaille luotetuissa ympäristöissä, ja avoimena oleva instanssi voi menettää koko tietojoukkonsa yhdellä FLUSHALL-komennolla.

Miten tarkistus tehdään ulkoa

Tarkistus on tehtävä verkkonne ulkopuolelta, muuten testaatte vain sisäistä reittiä. Käyttäkää konetta, joka on toisen internetyhteyden takana (pilven virtuaalikone, puhelimen jaettu yhteys), ja testatkaa vain omistamianne IP-osoitteita:

for port in 3306 5432 27017 6379 9200 9300; do
  nc -z -w 3 203.0.113.10 $port && echo "$port open" || echo "$port closed"
done

Palvelimella itsellään näette, mitä osoitteita kukin palvelu kuuntelee:

sudo ss -tlnp | grep -E ':(3306|5432|27017|6379|9200|9300)\b'

127.0.0.1:5432 tai yksityinen osoite on toivottu tulos. 0.0.0.0:5432 tai [::]:5432 tarkoittaa, että palvelu kuuntelee jokaista liitäntää ja sen ja internetin välissä on vain palomuuri.

Internetiä skannaavat palvelut indeksoivat myös jokaisen internetiin näkyvän IP-osoitteen avoimet portit. Jos haluatte nopeasti nähdä, mitä ne ovat tallentaneet jostakin osoitteestanne, Shodan tarjoaa yksinkertaisen haun osoitteessa https://internetdb.shodan.io/<your-ip>.

Miten portti suljetaan oikein

Käyttäkää 2 suojakerrosta, jotta yksi virhe ei avaa tietokantaa uudelleen:

1. Sitokaa palvelu vain yksityisiin liitäntöihin. bind-address = 127.0.0.1 (MySQL), listen_addresses = 'localhost' tai yksityinen IP (PostgreSQL), net.bindIp (MongoDB), bind 127.0.0.1 yhdessä asetuksen protected-mode yes kanssa (Redis), network.host yksityiseen osoitteeseen (Elasticsearch).
2. Rajoittakaa verkkotasolla. Palomuurin tai pilven tietoturvaryhmän pitää sallia tietokantaportti vain sovelluspalvelimistanne.
3. Etäyhteys tunnelin kautta. Kehittäjät muodostavat yhteyden SSH-tunnelin tai VPN:n kautta, ei koskaan avoimen portin kautta.
4. Vaatikaa tunnistautuminen kaikkialla, myös sisäverkoissa: käyttäjät vähimmillä oikeuksilla, pitkät salasanat ja TLS koneiden välisille yhteyksille.
5. Pitäkää ohjelmisto päivitettynä, jotta vahingossa avautuneessa portissa ei samalla ole versiota, jossa on tunnettuja haavoittuvuuksia.

Jos tietokanta on ollut avoinna heikolla tunnistautumisella tai ilman sitä, käsitelkää sen tietoja mahdollisesti kopioituina: vaihtakaa tunnukset, käykää lokit läpi ja arvioikaa ilmoitusvelvollisuutenne.

Lyhyt tarkistuslista

• Listatkaa jokainen yrityksenne käyttämä internetiin näkyvä IP-osoite, myös vanhat palvelimet.
• Testatkaa yleisimmät tietokantaportit ulkoa.
• Varmistakaa, että jokainen tietokanta kuuntelee vain localhostia tai yksityistä osoitetta.
• Sallikaa tietokantaportit palomuurissa vain sovelluspalvelimista.
• Tarkistakaa uudelleen jokaisen palvelinsiirron, uuden palvelimen tai Docker-muutoksen jälkeen.

Avoimet palvelut esiintyvät harvoin yksin. Ne ovat usein samoilla unohdetuilla staging-palvelimilla, joilta vuotavat myös .env- ja varmuuskopiotiedostot.

Miten Datahorses auttaa

Datahorses valvoo yritystänne ulkoa päivittäin ja näyttää, mitkä palvelut hyökkääjä näkee osoitteissanne, mukaan lukien tietokantaportit ja etäyhteydet, kuten RDP ja SSH, sekä tunnetut haavoittuvuudet niiden paljastamille versioille. Emme mene järjestelmiinne emmekä tarvitse pääsyoikeuksia. Jokaisen havainnon mukana tulevat tarkat korjausohjeet kehittäjällenne, kuten kuvaamme kohdassa mitä tapahtuu, kun löydämme jotain. Esimerkkinäkymästä näette, miltä tällainen raportti näyttää.