È comunque consigliabile evitare di utilizzare le porte predefinite per SQL Server?

Storicamente, è stato consigliato di non utilizzare le porte predefinite per le connessioni a SQL Server, come parte delle migliori pratiche di sicurezza. Su un server con una singola istanza predefinita, le seguenti porte verrebbero utilizzate per impostazione predefinita:

• Servizio SQL Server - Porta 1433 (TCP)
• Servizio browser SQL Server - Porta 1434 (UDP)
• Connessione amministrativa dedicata - Porta 1434 (TCP)

DOMANDE:

• Questo consiglio è ancora pertinente?
• TUTTE le porte di cui sopra devono essere modificate?

Storicamente, è stato consigliato di non utilizzare le porte predefinite per le connessioni a SQL Server, come parte delle migliori pratiche di sicurezza.

Che era asinina allora e ancora asinina ora. La sicurezza attraverso probabilmente l' oscurità non è affatto sicurezza.

Questo consiglio è ancora pertinente?

IMHO non è mai stato rilevante. È stato richiesto per alcuni scopi di conformità perché le persone che redigevano tali conformità non capivano cosa stavano facendo, di nuovo, IMHO.

TUTTE le porte di cui sopra devono essere modificate?

Non cambierei nessuno.

Anche se la sicurezza attraverso l'oscurità non è la vera sicurezza, non dirò che non ci sono casi in cui sia d'aiuto.

Se un utente malintenzionato vuole sapere dove è in ascolto il tuo servizio, può facilmente scoprirlo, ma in caso di stupido attacco automatico potresti essere fortunato se cambi porta.

L'unica volta che ricordo dove è stato effettivamente d'aiuto è durante il periodo di SQL Slammer in cui SQL Server 2000 era vulnerabile e si diffondeva un worm generando IP casuali e connettendosi alla porta del browser SQL Server predefinita.

Se ricordo bene, al momento era un consiglio ufficiale cambiare le porte fino a quando non potevi patchare il tuo server (o perché non c'era una patch disponibile immediatamente o perché non avevi una finestra)

Affinché quel worm entrasse nella tua rete nel momento in cui dovevi avere un SQL Server connesso a Internet invece che dietro un firewall, cosa che non avresti dovuto, ma comunque un numero di porta non predefinito avrebbe potuto aiutare in quel caso specifico.

Concordo tuttavia sul fatto che se si dispone di un'adeguata sicurezza, la complessità che si aggiunge probabilmente non supera le possibilità che prevenga un incidente.

Storicamente, è stato consigliato di non utilizzare le porte predefinite per le connessioni a SQL Server, come parte delle migliori pratiche di sicurezza

No, non lo era. Alcune persone fuorviate potrebbero averlo presentato come tale, ma ho fatto la sicurezza per oltre 20 anni e cambiare le porte predefinite è sempre stato una specie di "ecco qualcosa che puoi fare se vuoi, che a volte in circostanze molto specifiche fornisce un un po 'di sicurezza aggiuntiva contro alcune minacce molto specifiche "cosa.

Questo consiglio è ancora pertinente?

In circostanze molto specifiche, a seconda del modello di minaccia e dell'analisi del rischio, potrebbero esserci alcuni casi in cui si tratta di validi consigli. Nella stragrande maggioranza dei casi, no, non è rilevante né lo è mai stato.

SÌ , è ancora utile.

La modifica delle porte predefinite ha solo un reale scopo: difendersi da scansioni / attacchi automatizzati, se il server del database è aperto agli host che potrebbero essere compromessi.

Anche se potrebbe non sembrare un grosso problema, ricorda che:

• qualsiasi host potrebbe essere compromesso (o il server del database potrebbe essere esposto a Internet in generale a causa di un errore)
• la maggior parte degli attacchi in quei giorni sono attacchi automatici e molti di loro tenteranno solo le porte predefinite (poiché puntare su frutti a bassa pendenza è più efficiente).

Quindi, sì, mentre di per sé non ti aiuterà molto se sei sotto attacco mirato , l'uso di porte casuali (e / o farlo ascoltare solo su un indirizzo IPv6 casuale) lo renderà molto meno visibile, dandoti almeno più tempo per eseguire l'upgrade prima che la scansione dell'exploit automatizzato 0day ti colpisca (e potrebbe persino proteggerti completamente da tale scansione automatizzata da sola!)

Inoltre (questo aiuterà non solo contro tutti gli attacchi automatici contro, ma anche contro alcuni attacchi mirati) quando gli attaccanti cercano di trovare la porta del tuo database per sfruttarla da portali bruteforce, può essere rilevato e difeso (inserendo nella lista nera gli intervalli IP degli attaccanti e avvisando gli amministratori se un host interno è stato rilevato come fonte dell'attacco)

Si noti inoltre che cambiare la porta predefinita per server e client (specialmente se vengono distribuiti automaticamente) è una quantità banale di lavoro e anche rilevare scansioni di bruteforce è facile; quindi dovresti davvero farlo (non solo per i server di database; ma per tutti i servizi in cui il sovraccarico di configurarlo non è proibitivo a causa di problemi di usabilità: come cambiare la porta predefinita per il web da 80non è raccomandato, come alcune persone (e bot) rovinerà tutto e i firewall casuali in tutto il mondo potrebbero non consentire di stabilire una connessione. Ma RDP è un ottimo obiettivo, ad esempio per una porta non predefinita)

Non cambierei la porta, ma non esporrei mai il servizio di database direttamente su Internet. Solo attraverso un tunnel sicuro come SSH. Cambiare la porta di SSH potrebbe essere una buona idea per ridurre al minimo il traffico degli scanner.