Un pacchetto alieno dell'interruttore spegne la mia scheda ethernet quando si usa Nessus?

0

Sono bloccato tra un pessimo mix di cocktail di due tecnologie molto disperate. Uno è Nessus e altro è un Juniper EX2200. Quando eseguo i due insieme, la scheda NIC sul mio HP MiniTower 6200 Pro si spegne completamente. Questo accade circa 2-3 minuti nella scansione Nessus.

Il mio ambiente è che ho installato un interruttore Juniper insieme a SSG-5, che fornisce il gateway per l'ambiente di test di laboratorio. Il firewall funziona in modalità NAT.

La descrizione approssimativa dell'ambiente del mio problema è:

Juniper ---> uplink
|
SWITCH ---> vlan 20 > connected via trunk cable
|
PC - Gigbait Ethernet card (belongs to vlan20)

Quando la scheda Ethernet si spegne, il dump del pacchetto mostra (se non ricordo male):

Juniper84:91:12  ........ 52 RST spanning tree

È un messaggio di protocollo del livello di collegamento proveniente dallo switch di Juniper.

Inoltre, se eseguo la scansione utilizzando uplink direttamente connesso alla mia scheda NIC, non ho alcun problema.

Penso che ci sia un qualche tipo di aggiornamento inviato dallo switch alla mia porta di accesso che spegne la scheda NIC, qualcosa come gli aggiornamenti STP. Al momento, non ho disattivato tali aggiornamenti perché davvero non so cosa lo stia causando.

Inoltre, suggerire eventuali passaggi / comandi per la risoluzione dei problemi che posso eseguire sullo switch device.

Aggiornamento

Ho appena risolto il problema in quanto ho appena scoperto che il servizio di rete VMware stava inviando aggiornamenti VTP attraverso la mia porta di accesso alla macchina, facendo in modo che lo switch principale mettesse la mia porta in modalità di blocco.

Con questo risolto, c'è un modo per evitare che ciò accada a livello di switch invece di disabilitare i servizi VMWare?

    
posta Saladin 09.05.2012 - 16:43
fonte

3 risposte

1

Quali politiche hai abilitato nella scansione di Nessus? Se i plug-in Juniper e / o switch sono abilitati, è possibile che venga attivata una risposta STP dallo switch.

Prova a disabilitare i plugin, per vedere se il problema persiste.

    
risposta data 09.05.2012 - 23:37
fonte
1

Da quanto sopra, non sei in grado di eseguire una scansione usando Nessus quando ti colleghi a EX2200 (ssg pure?) ma quando ti connetti direttamente all'uplink, puoi eseguire / completare la scansione - è quella corretta ?

Supponendo che, quando dici che l'interfaccia "si spegne", puoi confermare a quale livello l'interfaccia si spegne? Ad esempio, si tratta di una porta fisica verso il basso (ad esempio, le luci di collegamento si spengono) o è logico (l2 o superiore)? In entrambi i casi, è probabile che tu sia sulla strada giusta. Ex220 (o forse anche ssg) potrebbe disabilitare / arrestare una porta se rileva alcune violazioni delle policy. A seconda di come la porta è disabilitata / chiusa, è possibile capire quale sia la causa del comportamento. Supponendo che tu stia utilizzando JUNOS 12.1, ecco un link a una pagina con documentazione per l'interruttore della serie EX. EX può essere eseguito come un UTM (e altri moduli di sicurezza), quindi è possibile che l'arresto fisico o l'disabilitazione della porta venga avviato da qualche modulo su EX. In un'azienda, si sarebbe preoccupati se alcune porte iniziassero in modo casuale ad avviare comportamenti sospetti (spoofing degli indirizzi IP, spoofing degli indirizzi mac, controllo delle tempeste, ecc.).

Consiglierei di controllare prima le funzionalità di sicurezza su ex2200 per determinare se (o quale) funzione di sicurezza si sta avviando. In caso contrario, potrebbe essere il ssg (il diagramma sopra non era chiaro se avevi avviato la scansione interna o esterno allo ssg).

    
risposta data 09.05.2012 - 20:39
fonte
0

Sospetto i problemi hardware con il tuo mini tower HP. Suggerimento: prova a eseguire la scansione da un'altra macchina con hardware diverso.

Probabilmente non vale il tuo tempo per risolvere i problemi di questo tipo di hardware. È un nido di topi e potresti passare giorni o settimane e, anche in quel caso, forse non identificare in modo affidabile la causa del problema.

Se si esegue la scansione Nessus da una macchina diversa, è stato fatto un grande progresso. Puoi continuare a utilizzare l'altra macchina e ora hai raggiunto i tuoi obiettivi (esegui con successo la scansione Nessus).

Oppure, se per qualche motivo vuoi veramente diagnosticare la causa principale del problema, hai fatto dei progressi in questo senso, perché ora hai un caso in cui è noto che il problema non si pone. In ogni caso, se vuoi veramente diagnosticare la causa principale, il primo passo sarà quello di assicurarti di avere un ambiente in cui funzioni in modo affidabile e un ambiente in cui non funzioni in modo affidabile, e quindi iniziare a ridurre le differenze tra i due fino a restringere giù per la causa. Quindi provare una macchina diversa con hardware diverso è probabilmente il primo passo, indipendentemente dall'obiettivo finale.

    
risposta data 09.05.2012 - 18:43
fonte

Leggi altre domande sui tag