Nome server compromesso e numero di porta di un server DB SQL Server

Question

Nome server compromesso e numero di porta di un server DB SQL Server

#1 da (3 voti)
#2 da (3 voti)

0

Vorrei avere un'opinione di esperti su quanto sia pericoloso avere il nome del server database e l'istanza e il numero di porta del server SQL compromessi accidentalmente esponendolo nello snippet di codice sorgente pubblicato su Internet.

Una stringa di connessione è stata accidentalmente pubblicata su Internet con il nome utente e la password mascherati, ma il nome del server e il numero di porta sqlserver rimangono in testo aperto. Le informazioni pubblicate contenevano quanto segue:

sub.server.domain.tld/SqlServerXXXX;12345; User Id="MASKED" Password="MASKED" Initial Catalog="MASKED"

Questo server Windows si trova su un grande dominio di Active Directory della rete aziendale e non è rivolto al pubblico, quindi è protetto da un set standard di firewall, ecc. Attualmente ospita un database di sviluppo per un sito Web intranet interno. Domain.tld è uguale all'indirizzo web dell'azienda.

Quindi fondamentalmente un potenziale aggressore sa che esiste un server denominato "sub.server.domain.tld" con i database di SQLServer in ascolto sulla porta 12345 sulla rete aziendale di proprietà della società "domain.tld".

Cosa possono fare con questo tipo di informazioni?
Quanto è pericoloso questo server? Dovrebbe essere disconnesso e bruciato immediatamente?
C'è un pericolo per altri computer sulla rete?

sql-server active-directory windows-server ports network-access-control

posta Paceman 12.09.2016 - 07:22

fonte

2 risposte

Leggi altre domande sui tag sql-server active-directory windows-server ports network-access-control

Crittografia della risposta dell'API in un'applicazione singola ssh ricorda la mia chiave

score 3 · Answer 1

Poiché si tratta di un server interno, il potenziale qui è che sono state fornite alcune informazioni su come la tua organizzazione configura i server DNS e SQL interni.

Questo non è un pericolo per questo particolare server (non c'è bisogno di masterizzarlo) ma dà uno sguardo al funzionamento interno della tua azienda.

Se un utente malintenzionato si trovava già nella rete, tali informazioni sarebbero comunque esposte, ma potrebbe (potenzialmente) aiutare un determinato utente malintenzionato ad accedere alla rete.

È una buona idea mantenere riservati questi tipi di informazioni, ma esporre queste informazioni non significa che tu abbia aperto la porta agli "hacker".

score 3 · Answer 2

Mi sembra che ciò che è trapelato sia solo l'informazione ottenibile da una semplice scansione nmap.

Se la sicurezza del tuo sistema dipendesse da quella permanenza privata, potresti comunque avere un problema nel tuo approccio.

Fintanto che le credenziali non sono trapelate e il tuo server db ha delle buone regole di controllo degli accessi, non mi preoccuperei.

Voglio dire, pensaci: se il db dovesse essere sfruttato da diversi servizi all'interno della tua azienda, allora le informazioni "trapelate" non sono comunque segrete. Se il db viene utilizzato solo da servizi specifici, l'accesso ad esso dovrebbe essere esplicitamente limitato a quegli IP o sottoreti autorizzati.