Indipendentemente dal fatto che questo debba applicarsi specificamente a Unix, direi che non è sicuro presumere che non vi sia accesso solo perché non ci sono porte aperte.

In altre parole, ICMP viene solitamente ascoltato, anche se non sono disponibili porte TCP o UDP.
E prima che tu dica: "Ma ICMP è solo un semplice Ping! È irrilevante attaccare usando quello! " dai un'occhiata a questi:

• Ping of Death
• Smurf attack
• e ovviamente , Ping flood

E sebbene questi siano tutti più o meno storici (ad eccezione dell'ultimo), non escluderei ulteriori attacchi futuri.

Inoltre, ci sono gli attacchi indiretti, come quelli che attaccano l'infrastruttura a cui il sistema chiuso stesso avrebbe accesso, ad es. Avvelenamento da DNS ...

Che tipo di attacchi ci sono che non utilizzano porte TCP aperte o UDP aperte?

Questa è una domanda troppo generica. Rispondo molto letteralmente, non per essere un idiota, ma perché nella sicurezza è meglio non dare per scontato nulla. Di seguito sono riportate alcune classi di attacchi che non utilizzano porte TCP o UDP aperte:

• Ingegneria sociale: fai in modo che qualcuno si connetta 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 di IP (vulnerabilità dello stack IP)
• NTP: di solito è attivato per impostazione predefinita e potrebbe non essere privo di bug
• 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.

È lecito ritenere che nessuna porta aperta significhi nessun accesso remoto?

• I download drive-by che vengono eseguiti potrebbero richiamare (incluso il ping in uscita e l'acquisizione di dati ctrl tramite risposta ping)
• I gestori di pacchetti potrebbero rimuovere il software trojan configurazione di malware per chiamate in uscita
• Accesso Bluetooth

Penso che la tua vera domanda dovrebbe essere: "Quali tipi di exploit remoti possono essere usati per eseguire il root della mia macchina se ha nessuna porta TCP o UDP aperta? "

Gli attacchi possono avere un significato qualsiasi per le persone, incluso 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 attendibile (o meno attendibile) e progettazione e / o QA difettosi all'interno di dette applicazioni .

Se il tuo server esegue applicazioni che elaborano l'input da una fonte che non ha lo stesso livello di fiducia del tuo server e non disponi di un solido processo di QA per dette applicazioni, sono vulnerabili.

Ad esempio, sebbene diversi buffer overflow si siano presentati tramite comunicazioni di pre-autenticazione con applicazioni che sono in ascolto sulle porte TCP e UDP, possono essere altrettanto facilmente presentati in routine che leggono dati da una risorsa di rete che non implica una connessione in 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 fa con il programma socket amming. In base alla mia esperienza, è qui che si trova il frutto a bassa pendenza.

Secondo me, stai cercando un unicorno e l'unico modo per ottenere il risultato attualmente desiderato è partire il tuo server in una stanza pulita e chiusa a chiave senza alcuna connessione di rete. L'obiettivo principale di un server è la funzionalità, non la sicurezza, e devono essere fatti compromessi per quanto riguarda l'input non attendibile. Il modo per mitigare questo rischio, pur continuando a fornire funzionalità, è abilitare solo la funzionalità necessaria e compensare i servizi richiesti dai processi di controllo qualità / audit come 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, il tuo 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 vera vulnerabilità ha molti requisiti:

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

Se si consente il DNS, si consente l ' IP su DNS.

Se puoi assicurarti che il tuo hardware di rete non abbia porte aperte per nessun protocollo, allora non sarà in grado di ricevere pacchetti - questo renderà molto improbabile che venga attaccato attraverso la rete, tuttavia se volessi chiudere tutte le porte, Consiglierei di scollegare il cavo di rete perché posso pensare a un potenziale problema:

• potresti avere un rootkit che segnala le porte chiuse quando in realtà ce n'è una aperta

Non è assolutamente sicuro. Ecco un semplice esempio: un utente della macchina naviga nel Web, visita siti Web imprecisi e fa clic su vari collegamenti. Ciò può facilmente causare la compromissione della sicurezza della macchina (ad esempio, tramite download drive-by o dal social engineering per indurre l'utente a installare malware). Questo è vero anche se il sistema operativo non ha porte aperte su cui è in ascolto.