Il blocco di UDP e TCP è sufficiente per prevenire attività di rete indesiderate?

Hai detto "Voglio essere sicuro al 100% che la mia macchina si connetta solo dove e quando voglio", ma hai una strategia per coprire che è stato inviato?

Il blocco delle porte è sempre una buona idea, ma per navigare sul Web dovresti riuscire a connetterti alla porta 80 ea quel punto il malware ha un modo per comunicare. Ti rendi conto di questo, quindi blocchi tutte le destinazioni degli indirizzi IP eccetto quelle che permetti; fantastico, dovrebbe farlo. Ti piace lo stackexchange e vuoi postare lì, così ti apri ai server SE e probabilmente vuoi Google e altri. A questo punto sei già vulnerabile perché il malware potrebbe inviare dati dalla tua macchina a un account su stackexchange, google o altrove effettuando l'accesso a un account specifico e memorizzando i dati crittografati di 64 secondi nel profilo dell'account per l'estrazione successiva. Avere il filtro dei contenuti potrebbe funzionare, ma potrebbe essere difficile da configurare. Naturalmente sarai alla ricerca del firewall che avvisa i trasferimenti alla volta che non ti aspetti, ma il malware intelligente potrebbe attendere fino a quando non vedrà l'invio o la ricezione di dati da stackexchange, ad esempio, e inviare i dati allo stesso tempo sembrare parte del tuo traffico. Noteresti quindi la connessione e il traffico extra, o presumi semplicemente che il tuo browser aprisse più di una connessione, che tenderà a fare comunque?

Ho deliberatamente dipinto un quadro desolante che, sebbene improbabile, è interamente possibile, e quindi la risposta alla tua domanda deve essere un "No". L'unica cosa sicura per il fuoco è non collegarla mai a Internet.

Quanto segue è valido solo se un utente malintenzionato non è in grado di controllare parti di la tua rete, ad es. Server o router DNS; se è così, sei condannato comunque:)

If I use a firewall that blocks all UDP and TCP packets but those that I explicitly allow to pass, can I be 100% sure that my machine does not connect anywhere without my approval?

Sebbene tu possa essere sicuro che la tua macchina non si connetta a server / porte che non hai permesso, non puoi essere certo che non esistano canali secondari per gli aggressori. Se le tue macchine hanno il permesso DNS, il foot-in-the-door potrebbe essere un canale DNS nascosto, anche se permetti solo i tuoi server DNS.

Per un'introduzione ai canali nascosti, vedi "Rilevamento dei tunnel DNS" e "Canali nascosti" di SANS Reading Room.

For example, if I did not know about UDP at all and only specified TCP rules on the firewall, I would still be vulnerable to malware and nasty spyware exploiting UDP packets. So technically speaking, is there any other means/protocols apart from UDP and TCP that can be used to communicate with a computer using wired/wireless network connections?

Vedi SCTP , ma questo deve essere disponibile sulla tua macchina (non sapere i valori predefiniti).

Also, can UDP and TCP packets bypass firewalls?

Di solito no, ma se hai IPv4 e IPv6 abilitati e hai configurato il tuo firewall solo per IPv4, allora i pacchetti potrebbero uscire tramite IPv6.

Altrimenti, non conosco un modo per aggirare un filtro di pacchetti.

cat /etc/protocols (su Linux) mostrerà tutti i possibili protocolli; sebbene sia probabile (?) il tuo kernel non li supporterà tutti.

Tuttavia, la buona notizia è che iptables, per impostazione predefinita, agisce su tutti i protocolli. Quindi questa linea, che spesso arriva alla fine di iptables.rules,

-A FIREWALL-INPUT -j REJECT --reject-with icmp-host-prohibited

rifiuta i pacchetti non solo su tutte le porte tcp / udp che non erano esplicitamente consentite, ma su tutti i protocolli che non erano esplicitamente consentiti.

Questo non presuppone alcuna errata configurazione o bug del kernel. Inoltre, non considera i dispositivi che non sono controllati dal kernel. Per esempio. una chiavetta USB potrebbe sembrare un filesystem per l'O / S, ma usare bluetooth o wifi sotto la superficie. (Sia come una caratteristica pubblica, o senza la vostra conoscenza.) (Altre persone hanno già menzionato il tunneling.)

Un sacco di disinformazione in queste risposte.

Se il firewall sta bloccando TCP per IPv4 / UDP per IPv4, tutto ciò che sta prestando attenzione sono i pacchetti IPv4 in cui sono specificati TCP o UDP. La maggior parte dei firewall richiede ulteriori impostazioni per bloccare TCP e UDP per IPv6.

Quindi sappiamo di TCP e UDP, e del resto dei protocolli IP? Bene, ecco un elenco di altri protocolli che il tuo firewall potrebbe consentire che tutti utilizzino l'IP e siano validi per il router da inviare .

Sicuro TCP e UDP sono i più comuni, ma anche se blocchi tutti gli altri protocolli IP conosciuti, cosa mi impedisce di usare un altro protocollo? Che ne dici del protocollo IPv4 253, il protocollo di Matthew. Finché c'è una destinazione IP valida, andrebbe comunque all'indirizzo IP corretto.

Saltare nel mondo dei cappelli di stagnola, diciamo che blocchi IPv4 e IPv6 sul tuo Firewall (sei preoccupato per il protocollo Matthew e tutti gli altri protocolli IP). Infine, cosa mi impedisce di creare un'app che mandi dati arbitrari dalla tua scheda di rete e che abbia qualcos'altro sulla tua rete che lo interpreti? Cosa mi impedisce di creare un driver di scheda di rete che scrive 0s e 1s grezzi che decodificherò in un altro punto del cavo? Oppure scrivendo frame Ethernet. Realisticamente per superare il router ovviamente dovrebbe parlare di una forma di IPv4 o IPv6 in quanto i router tendono a far cadere tutto (oltre a rispondere ad alcuni frame Ethernet ARP).

Recentemente ho avvistato Broadcomm usando i loro bizzarri frame ARP sul mio adattatore locale (presumibilmente per le funzionalità di teaming di rete) ma strano non meno.

Ti sei imbattuto nel motivo per cui i sistemi sono a tenuta d'aria. Il punto principale è quello di impedire a qualcuno di sottrarre dati dalla rete, ed è più facile classificare i metodi in generale e capire che un approccio olistico sarebbe meglio.

1. Identificazione degli endpoint: include la whitelist degli endpoint, la coerenza DNS / IP
2. Correttezza del protocollo wire - tunneling, porta / protocollo non standard, dimensioni del pacchetto incoerenti, segnalazione tramite mezzi non standard
3. Correttezza dell'applicazione - comportamento coerente dell'applicazione.
4. Modelli di utilizzo degli utenti - pattern utente coerenti

Il principale takeaway è: bloccare è solo la punta dell'iceberg. Dovrai decidere quale posizione adottare in base alla quantità di tempo / sforzi / soldi che vuoi applicare.

Il blocco di tutto il traffico TCP e UDP equivale a estrarre il cavo di rete dal retro del computer.

Sì, il blocco di TCP e UDP impedirà l'esecuzione di connessioni indesiderate .... ma interromperà molte connessioni che desideri.