Server UNIX: possibili intrusioni o attacchi che non utilizzano nessuna delle socket di ascolto aperte

Indipendentemente dal fatto che questo dovrebbe applicarsi specificamente a Unix, direi che è non sicuro di non avere accesso solo perché non ci sono porte aperte.

Per wit, di solito viene ascoltato ICMP , anche se non sono disponibili porte TCP o UDP.
E prima che tu dica: "Ma ICMP è solo un semplice Ping ! È irrilevante attaccare usando quello!" controllali:

• Ping of Death
• Attacco puffo
• e, naturalmente, Inondazione ping

E mentre questi sono tutti abbastanza storici (con l'eccezione dell'ultima), non escluderei ulteriori attacchi futuri.

Inoltre, ci sono gli attacchi indiretti, come quelli che attaccano l'infrastruttura a cui accederà il sistema chiuso-es. Avvelenamento DNS ...

What type of attacks are there that do not use open TCP or open UDP ports?

Questa è una domanda troppo generica. Sto rispondendo letteralmente a questo, non per essere un cretino, ma perché in sicurezza è meglio non assumere nulla. Ecco alcune classi di attacchi che non utilizzano porte TCP o UDP aperte:

• Social engineering: chiedi a qualcuno di connetterti in uscita dalla macchina a un sito di attacco (o allega una pen drive o un supporto non valido)
• Accesso fisico, keylogger, ecc.
• Un attacco a livello IP (vulnerabilità dello stack IP)
• NTP: solitamente attivato per impostazione predefinita e potrebbe non essere privo di errori
• DHCP: dhcp è disattivato? un utente malintenzionato sulla rete locale potrebbe inviare un'immagine di avvio PXE alla scheda Ethernet e caricare il proprio sistema operativo.

Is it safe to assume that no open ports means no remote access?

• I download drive-by che vengono eseguiti possono richiamare (incluso il ping out e ottenere i dati ctrl via risposta ping)
• I gestori di pacchetti possono scaricare software trojan che configurano malware di richiamo
• Accesso Bluetooth

Penso che la tua vera domanda dovrebbe essere: "Quali tipi di exploit remoti possono essere usati per fare il root della mia macchina se non ha porte TCP o UDP aperte?"

Gli attacchi possono significare un numero qualsiasi di cose tra cui Van Eck Phreaking.

Il problema fondamentale di queste classi di attacchi non è all'interno dei protocolli TCP o UDP stessi, è con il requisito delle applicazioni di elaborare i dati da una fonte non affidabile (o meno affidabile) e progettazione difettosa e / o QA all'interno di dette applicazioni .

Se il tuo server esegue applicazioni che elaborano input da un'origine che non ha lo stesso livello di affidabilità del tuo server e non hai un strong processo di QA in atto per tali applicazioni, sei vulnerabile.

Ad esempio, sebbene diversi overflow di buffer si siano presentati tramite le comunicazioni di pre-autenticazione con le applicazioni che si trovano ad ascoltare sulle porte TCP e UDP, possono essere presentati in routine che leggono i dati da una risorsa di rete che non coinvolge una connessione di ascolto, o anche in funzioni che leggono da risorse locali come file e database, in molti di questi casi il programmatore non ha la mentalità ostile ai dati che fanno con la programmazione di socket. È la mia esperienza che è qui che si trova il frutto a bassa attaccatura.

A mio parere, stai cercando un unicorno e l'unico modo per ottenere il risultato desiderato è lasciare il server in una stanza pulita e chiusa senza alcuna connessione di rete. L'obiettivo principale di un server è la funzionalità, non la sicurezza, e devono essere presi dei compromessi per quanto riguarda l'input non attendibile. Il modo per mitigare questo rischio, pur continuando a fornire funzionalità, è quello di abilitare solo le funzionalità necessarie e di compensare i servizi richiesti da QA / processi di revisione quali revisione del codice e test di penetrazione, processi operativi come monitoraggio e risposta agli incidenti e infrastruttura per prevenire o rilevare input e connettività indesiderati.

Anche se il tuo sistema operativo è completamente sicuro, l'hardware potrebbe essere vulnerabile. Molte schede di rete rispondono a vari protocolli di amministrazione remota ( Wake-on-LAN , Alert-on-LAN , ASF , ...).

In pratica, una vulnerabilità reale ha molti requisiti:

• almeno una di queste funzioni deve essere supportata;
• la funzione deve essere abilitata almeno a un certo livello (di solito è disattivata come spedita);
• il sistema operativo non deve aver disattivato la funzione al momento dell'avvio (questo è un caso in cui un computer è più vulnerabile quando è spento);
• l'autore dell'attacco deve trovarsi sul lato destro di qualsiasi firewall che si rispetti (la maggior parte di queste funzioni utilizza UDP);
• e ovviamente il firmware deve essere vulnerabile (esempio: CVE , FAQ )
.

Se uno consente il DNS, allora si consente IP su DNS .

Se si riesce a garantire che l'hardware di rete non abbia porte aperte per alcun protocollo, non sarà in grado di ricevere pacchetti - questo renderà molto improbabile che venga attaccato attraverso la rete, tuttavia se si desidera chiudere tutte le porte, Vorrei consigliare di scollegare il cavo di rete perché posso pensare a un potenziale problema:

• potresti avere un rootkit che segnala porte chiuse quando in realtà ce n'è uno aperto

Non è assolutamente sicuro. Ecco un semplice esempio: un utente della macchina naviga sul Web, visita siti Web abbozzati e fa clic su vari collegamenti. Ciò può facilmente compromettere la sicurezza della macchina (ad es. Tramite download drive-by o social engineering per ingannare l'utente nell'installazione di malware). Questo è vero anche se il sistema operativo non ha nessuna porta aperta in ascolto.