Atviras SQL Server internete – tiesus kelias į ransomware incidentą?

Kodėl TCP/1433 atidarymas į internetą yra pavojingas?

SQL Server dažnai saugo apskaitos, ERP, gamybos, sandėlio, klientų ir kitų verslo sistemų duomenis. Tačiau praktikoje vis dar pasitaiko konfigūracija, kai standartinis TCP/1433 prievadas atidaromas tiesiai į internetą.

Jeigu ugniasienėje leidžiama Internet → TCP/1433 → SQL Server, serverį gali pasiekti ne tik jūsų programa ar administratorius. Viešus servisus nuolat skenuoja automatizuotos sistemos, ieškančios atvirų SQL, RDP, SSH, VPN ir kitų paslaugų.

CVE-2024-21335 – kodėl SQL Server pataisos svarbios?

Vienas iš pavyzdžių – CVE-2024-21335, su Microsoft SQL Server Native Client OLE DB Provider susijęs nuotolinio kodo vykdymo (RCE) pažeidžiamumas.

RCE klasės pažeidžiamumai yra pavojingi todėl, kad tam tikromis sąlygomis jų išnaudojimas gali leisti vykdyti kodą pažeidžiamoje sistemoje. Todėl ilgai nediegti SQL Server, Windows Server ir susijusių komponentų saugumo atnaujinimų yra rimta rizika.

Serveris gali metų metus veikti stabiliai ir tuo pačiu turėti viešai žinomų saugumo spragų. „Veikia – nelieskime“ nėra saugumo strategija.

Nuo SQL Server iki visos infrastruktūros

Duomenų bazės kompromitavimas nebūtinai yra galutinis užpuoliko tikslas. SQL Server gali turėti ryšių su Active Directory, aplikacijų serveriais, failų saugyklomis, bendrais katalogais, atsarginių kopijų sistemomis ar kitais vidinio tinklo resursais.

INTERNETAS
    ↓
Viešai pasiekiamas SQL Server
    ↓
Pažeidžiamumo / paskyros kompromitavimas
    ↓
Kodo vykdymas serveryje
    ↓
Privilegijų didinimas ir tinklo žvalgyba
    ↓
Kiti serveriai ir administravimo paskyros
    ↓
Backup paieška / naikinimas
    ↓
RANSOMWARE
    ↓
ĮMONĖS DUOMENŲ UŽŠIFRAVIMAS

Vieno netinkamai apsaugoto serverio problema gali tapti visos organizacijos incidentu.

O jeigu SQL Server leidžia vykdyti OS komandas?

SQL Server turi galingų administravimo mechanizmų. Gerai žinomas pavyzdys – xp_cmdshell, leidžiantis inicijuoti operacinės sistemos komandų vykdymą SQL Server tarnybos saugumo kontekste.

xp_cmdshell nėra CVE-2024-21335 dalis ir jo nereikia painioti su šiuo pažeidžiamumu. Tačiau jeigu užpuolikas gauna pakankamas SQL privilegijas, nereikalingai įjungti tokio tipo mechanizmai gali dar labiau padidinti kompromitavimo pasekmes.

„Bet SQL turi labai stiprų slaptažodį“

Stiprus slaptažodis yra būtinas, bet jis nėra programinės įrangos pataisų, ugniasienės ar tinklo segmentavimo pakaitalas. Pažeidžiamumo išnaudojimas ir slaptažodžio atspėjimas yra skirtingi atakos keliai.

SQL Server apsauga negali remtis vien argumentu, kad sa ar kita administratoriaus paskyra turi sudėtingą slaptažodį.

Kaip SQL Server turėtų būti pasiekiamas?

SQL Server neturėtų būti be būtinybės publikuojamas visam internetui. Nutolusiai prieigai saugiau naudoti VPN, pavyzdžiui, WireGuard ar IPsec:

Darbuotojas / padalinys
        ↓
   WireGuard / IPsec
        ↓
     Ugniasienė
        ↓
     SQL Server

Jeigu VPN konkrečioje architektūroje naudoti negalima, prieigą reikėtų apriboti tik konkrečiais patikimais šaltinio IP adresais. Dar geriau – SQL Server laikyti atskirame serverių VLAN ir leisti ryšį tik toms aplikacijoms bei sistemoms, kurioms jis realiai būtinas.

Atnaujinimai turi būti proceso dalis

Produkcinio SQL Server nereikia aklai atnaujinti be pasiruošimo. Saugus procesas turėtų būti: įvertinti → testuoti → patikrinti backup → diegti → patikrinti veikimą.

Tačiau mėnesiais ar metais nediegti saugumo pataisų vien todėl, kad sistema šiuo metu veikia, reiškia sąmoningai palikti žinomus atakos kelius.

Ransomware atveju paskutinė gynybos linija – backup

Net ir gerai apsaugota infrastruktūra nėra absoliučiai nepažeidžiama. Todėl būtina ruoštis scenarijui, kai užpuolikui vis dėlto pavyksta patekti į sistemą.

Jeigu kompromituotas serveris ar administratoriaus paskyra gali ištrinti visas atsargines kopijas, ransomware operatorius gali tai padaryti dar prieš pradėdamas šifravimą.

Didelį incidentą dažniausiai sukuria ne viena klaida

Atviras SQL Server
+
Neįdiegtos saugumo pataisos
+
Per didelės teisės
+
Silpna tinklo segmentacija
+
Nepakankamas monitoringas
+
Pasiekiamos atsarginės kopijos
=
RANSOMWARE INCIDENTO RIZIKA

Kiekvienas papildomas saugumo sluoksnis turi vieną tikslą – nutraukti šią grandinę dar iki galutinio etapo.

Ką rekomenduoja INsec?

• Nepublikuoti SQL Server tiesiogiai visam internetui.
• Nuotolinei prieigai naudoti VPN.
• Jeigu vieša prieiga būtina – griežtai riboti šaltinio IP adresus.
• Reguliariai diegti Windows Server, SQL Server ir susijusių komponentų saugumo pataisas.
• Laikytis mažiausių būtinų teisių principo.
• Nereikalingus pavojingus mechanizmus, įskaitant xp_cmdshell, laikyti išjungtus.
• Segmentuoti serverių infrastruktūrą VLAN ir ugniasienėmis.
• Stebėti Windows, SQL Server, autentifikacijos ir tinklo įvykius.
• Naudoti SIEM / XDR įtartinai veiklai aptikti.
• Turėti izoliuotas arba immutable atsargines kopijas ir reguliariai testuoti atkūrimą.

Patikrinkite SQL Server prieš tai padarant užpuolikams

Nežinote, ar jūsų Microsoft SQL Server pasiekiamas iš interneto? Neaišku, kada paskutinį kartą buvo diegtos saugumo pataisos? SQL Server veikia daug metų ir niekas nebenori jo liesti?

Tai yra priežastys atlikti saugumo patikrą, o ne ją atidėti.