PCI-DSS richiede che il client telnet sia disinstallato da un server

Question

PCI-DSS richiede che il client telnet sia disinstallato da un server

#1 da (1 voti)
#2 da (0 voti)

2

Spesso (non sempre) vedo con le valutazioni di vulnerabilità PCI dei miei clienti il client telnet che viene installato in arrivo come segnalato, sia per i server basati su Windows che per quelli Linux.

Capisco perché un server telnet viene contrassegnato ma il client viene installato ma non utilizzato per le comunicazioni basate su telnet effettive. Non vedo perché lo dovrebbero contrassegnare.

Per la risoluzione dei problemi di connettività di rete ci sono altri strumenti di terze parti che è possibile utilizzare, ma quando gli utenti remoti eseguono la risoluzione dei problemi in un ambiente senza un set standard di strumenti installati a volte questo può essere un salvataggio. Ho appena avuto questo elemento sul mio elenco per un po 'e vorrei avere qualche input / prospettiva esterna.

Modifica: per chiarire questo si intende nel contesto dell'utilizzo del client telnet come strumento di risoluzione dei problemi per verificare l'accesso alla porta, non per utilizzare effettivamente il protocollo telnet. Ci sono strumenti "migliori" per questo, ma come affermato in precedenza si può spesso finire in una situazione in cui l'utilizzo di un controllo telnet rapido può fornire le informazioni necessarie, prendendo il tempo necessario per scaricare un'utilità di terze parti più pesante. Un server "OpenSSH" non è un sostituto adatto per questo caso d'uso.

pci-dss

posta Bobby 21.07.2016 - 09:19

fonte

2 risposte

Leggi altre domande sui tag pci-dss

Qualche exploit ha sfruttato un difetto di Video Driver in WebGL? Unità SSD crittografata con hardware bruteforcing

score 1 · Answer 1

Non riesco a capire perché vorresti un programma / protocollo insicuro come telnet quando è facile utilizzare un'alternativa sicura sotto forma di un server SSH aperto.

Telnet è stato spesso usato per compromettere un sistema anche quando i normali operatori di rete non lo usavano. Semplicemente non c'è modo di proteggere una sessione telnet.

Poiché il client telnet di windows può essere utilizzato attraverso il sistema COM, è stato persino utilizzato per creare callback remoti a un server attacker. (per esempio, è facile per qualcuno fare qualcosa con un host compromesso). Solo quando è completamente rimosso il rischio viene mitigato.

Aggiornamento:

Edit: To clarify this is meant in the context of using the telnet client as a troubleshooting tool to verify port access, not to actually use the telnet protocol. There are "better" tools for this, but as previously stated you can often wind up in a situation where using a quick telnet check can give you the info you need versus taking the time to download a heavier 3rd party utility. An "OpenSSH" server is not a suitable replacement for this use case.

Per questo caso d'uso sarebbe più opportuno uno cUrl strumento. dato che puoi ottenere tutti i dettagli (a differenza di alcuni con telnet) ed è persino più leggero di telnet senza gli elementi COM collegati che telnet supporta (sì hai la libreria, ma è abbastanza piccola da mettere dentro un exploit e lì per non una barriera per gli attaccanti).

Il OpenSSH sostituisce tutte le funzionalità di telnet come strumento di gestione (e accesso remoto) e lo sostituisce con un alternativa sicura.

score 0 · Answer 2

Non penso che PCI DSS proibisca il client Telnet, ma posso vedere come un ASV potrebbe interpretare 2.3.b come indicato in questo modo:

2.3.b Review services and parameter files on systems to determine that Telnet and other insecure remote-login commands are not available for non-console access.

Da un lato, afferma che "... i comandi di accesso remoto non sono disponibili per l'accesso senza console." L'uso di comando invece di servizio , daemon o listener in questa frase può essere facilmente letto come implicante che Il software client Telnet dovrebbe essere reso non disponibile.

D'altra parte, quando dice "Controlla servizi e file di parametri significa chiaramente che è incentrato sull'assicurarsi che il servizio non sia configurato per l'esecuzione e l'ascolto delle connessioni - il client Telnet è non un servizio e interpreto che file di parametri significa cose come inetd.conf , non .telnetrc .

Personalmente, trovo che Telnet sia sempre più deprecato di default ... Windows 7 e RHEL 6 non lo installano. Francamente, trovo più preoccupante che le distribuzioni Linux stiano iniziando a installare nc di default (RHEL lo ha come dipendenza da qualche stupido programma o altro).

E sono d'accordo con te sul fatto che Telnet è un utile strumento di debug rapido e sporco. Quando devi determinare se i firewall o il routing confondono una delle tue connessioni e vuoi solo vedere cosa succede, telnet va bene e meglio che rendere nc o nmap disponibili. (E non sono d'accordo con @LvB in quanto gli strumenti specifici del protocollo falliscono quando vengono utilizzati protocolli non comuni - database, protocolli proprietari, ecc.)

Alla fine, puoi respingere il tuo ASV, chiedendo loro di citare il loro ragionamento e poi (se è come ho immaginato sopra) discutendo con loro a riguardo. Per un punto così banale, puoi vincere senza nemmeno dover combattere molto.