🥇Non aprire porte al mondo — verrai compromesso (rischi)

Ancora e ancora, dopo aver condotto un audit, mi imbatto in una barriera di incomprensione riguardo alla mia raccomandazione di nascondere le porte dietro una white-list. Anche i più bravi admin/DevOps chiedono: «Perché?!?»

Propongo di esaminare i rischi in ordine decrescente di probabilità e danno.

Errore di configurazione
DDoS per IP
Brute force
Vulnerabilità dei servizi
Vulnerabilità dello stack del kernel
Intensificazione degli attacchi DDoS

Errore di configurazione

Situazione tipica e pericolosa. Come accade. Lo sviluppatore deve rapidamente verificare un’ipotesi, solleva un server temporaneo con mysql/redis/mongodb/elastic. La password, ovviamente, è complessa, la utilizza ovunque. Apre il servizio al mondo — gli è comodo connettersi dal proprio PC senza quei VPN. E ricordare la sintassi di iptables è una seccatura, il server è comunque temporaneo. Altri giorni di sviluppo — è venuto benissimo, possiamo mostrarlo al cliente. Al cliente piace, non c’è tempo per modifiche, lo attiviamo in produzione!

Un esempio volutamente esagerato per toccare tutti i punti critici:

Non c’è nulla di più permanente del temporaneo — non mi piace questa frase, ma per sensazioni soggettive, il 20-40% di questi server temporanei rimane attivo a lungo.
Una password complessa utilizzata in molti servizi è un male. Perché uno dei servizi in cui è stata utilizzata può essere stato compromesso. In un modo o nell'altro, i database dei servizi compromessi si accumulano in uno solo, che viene utilizzato per [brute force]*.
Vale la pena aggiungere che redis, mongodb ed elastic sono generalmente accessibili senza autenticazione dopo l'installazione, e spesso alimentano la raccolta di database aperti.
Può sembrare che in pochi giorni nessuno scansionerà la tua porta 3306. Questo è un equivoco! Masscan è un ottimo scanner e può scannerizzare a una velocità di 10 milioni di porte al secondo. E in Internet ci sono solo 4 miliardi di IPv4. Di conseguenza, tutte le porte 3306 in rete vengono trovate in 7 minuti. Carl!!! Settimana di minuti!
«A chi importa?» — risponderete. Anch'io sono sorpreso, guardando le statistiche dei pacchetti scartati. Da dove provengono 40.000 tentativi di scansione in un giorno da 3.000 IP unici? Ora tutti stanno scannerizzando, dai hacker delle mamme ai governi. Controllare è molto semplice: prendi qualsiasi VPS per $3-5 da qualsiasi** lowcost provider, attiva il logging dei pacchetti scartati e dai un'occhiata al log dopo un giorno.

Attivazione del logging

In /etc/iptables/rules.v4 aggiungere in fondo:
-A INPUT -j LOG —log-prefix «[FW — ALL] » —log-level 4

E in /etc/rsyslog.d/10-iptables.conf
:msg,contains,»[FW — » /var/log/iptables.log
& stop

DDoS per IP

Se un malintenzionato conosce il tuo IP, può DDoSare il tuo server per diverse ore o addirittura giorni. Non tutti i lowcost hosting hanno protezione DDoS e il tuo server sarà semplicemente disconnesso dalla rete. Se hai nascosto il server dietro a un CDN, non dimenticare di cambiare IP, altrimenti l'hacker lo troverà con Google e DDoSarà il tuo server aggirando il CDN (un errore molto comune).

Vulnerabilità dei servizi

In tutto il software popolare, prima o poi vengono trovati errori, anche nei più testati e critici. Nell'ambiente degli specialisti in sicurezza, c'è una sorta di battuta — la sicurezza di un'infrastruttura può essere valutata in modo sicuro dal tempo dell'ultimo aggiornamento. Se la tua infrastruttura ha porte esposte al mondo e non l'hai aggiornata da un anno, qualsiasi esperto di sicurezza ti dirà senza esitazione che sei vulnerabile e probabilmente già compromesso.
Vale anche la pena menzionare che tutte le vulnerabilità note sono state un tempo sconosciute. Immagina un hacker che ha trovato una vulnerabilità e ha scannerizzato tutto Internet in 7 minuti per verificarne la presenza... Ecco che nasce una nuova epidemia virale ) Devi aggiornarti, ma ciò potrebbe danneggiare il prodotto, direte voi. E avrete ragione, se i pacchetti non provengono dai repository ufficiali del sistema operativo. Dalla mia esperienza, gli aggiornamenti dai repository ufficiali raramente rompono un ambiente di produzione.

Brute force

Come descritto sopra, c'è un database con mezzo miliardo di password, che è facile digitare da una tastiera. In altre parole, se non hai generato una password, ma hai digitato simboli vicini sulla tastiera, stai certo* — verrai brutalmente attaccato.

Vulnerabilità dello stack del kernel.

Ci sono casi**** in cui non importa quale servizio apre la porta, quando la vulnerabilità riguarda il stack della rete del kernel. Cioè, qualsiasi socket tcp/udp su un sistema di due anni fa è soggetto a vulnerabilità che porta a DDoS.

Intensificazione degli attacchi DDoS

Non porterà danni diretti, ma potrebbe saturare la tua connessione, aumentare il carico sul sistema, il tuo IP potrebbe finire in qualche black-list*****, e riceverai contestazioni dal provider.

Hai davvero bisogno di tutti questi rischi? Aggiungi il tuo IP di casa e di lavoro alla white-list. Anche se è dinamico — accedi tramite la console di amministrazione del tuo provider e aggiungi semplicemente un altro.

Mi occupo di costruzione e protezione dell'infrastruttura IT da 15 anni. Ho sviluppato una regola che raccomando vivamente a tutti — nessuna porta dovrebbe essere esposta al mondo senza una white-list..

Ad esempio, il server web più sicuro*** è quello che ha aperti solo le porte 80 e 443 per CDN/WAF. Le porte di servizio (ssh, netdata, bacula, phpmyadmin) devono essere protette almeno da una whitelist, e sarebbe meglio se fossero dietro una VPN. Altrimenti, rischiate di essere compromessi.

Ho finito. Tenete le vostre porte chiuse!

(1) UPD1: Qui puoi controllare se la tua super password universale (non farlo senza sostituire questa password con delle randomizzate su tutti i servizi) è stata esposta in un database leak. E qui puoi vedere quanti servizi sono stati compromessi in cui il tuo email è stato coinvolto e, di conseguenza, scoprire se la tua super password universale è stata compromessa.
(2) A onor del vero, Amazon - su LightSail ci sono pochi scans. Evidentemente filtrano in qualche modo.
(3) Un server web ancora più sicuro è quello protetto da un firewall dedicato, il proprio WAF, ma stiamo parlando di VPS/Dedicated pubblici.
(4) Segmentsmak.
(5) Firehol.

Solo gli utenti registrati possono partecipare al sondaggio. Accedi, per favore.