Esiste un significato solo nel consentire la porta 80 e 443 oggi?

Question

Esiste un significato solo nel consentire la porta 80 e 443 oggi?

#1 da (32 voti)
#2 da (22 voti)
#3 da (11 voti)
#4 da (3 voti)

33

È diventato una tariffa standard per le organizzazioni orientate alla sicurezza per bloccare tutto tranne 80 e 443. Come risultato, sempre più applicazioni (oltre ai browser Web) stanno imparando a utilizzare queste porte anche per le loro esigenze.

Anche i programmi dannosi fanno altrettanto, il che significa che per avere una vera sicurezza, i firewall devono effettivamente esaminare il flusso di dati e bloccare in base ai dati dell'applicazione invece delle sole porte ...

Questo sembra indicare che il blocco basato sulla porta era un approccio miope per cominciare, un po 'come la validazione dell'input solo sul client ...

In tal caso, non dovremmo interrompere il blocco del blanking delle porte non standard e, in primo luogo, optare per un filtraggio più fine ...? O ci sono altri motivi per mantenere l'approccio di port-whitelist?

network firewalls ports

posta Milind R 23.12.2014 - 19:38

fonte

4 risposte

Leggi altre domande sui tag network firewalls ports

Perché alcuni siti impediscono agli utenti di riutilizzare le vecchie password? Il trasferimento di dati sensibili attraverso l'ambiente di processo è sicuro?

score 32 · Answer 1

Il blocco di tutte le porte tranne 80 e 443 può essere parte di una buona strategia di difesa in profondità. Se è la tua unica strategia, allora hai ragione, sarà un errore.

Un potenziale approccio stratificato può essere

Blocca tutte le porte sul firewall esterno meno 80/443
Avere un IPS in linea (o come parte del firewall) esegue l'analisi dei pacchetti
Disinfetta l'input di app Web con un firewall di applicazione Web
Disinfetta l'input db con un firewall db
registra tutto e inseriscilo in un sistema di gestione dei log (con avvisi)
Backup su tutto (qualunque sia la tua strategia di disponibilità)
Indurisci ogni SO in base a qualsiasi linea di base / benchmark che scegli (ad esempio Org SOP, CIS / DISA STIGS, ecc.)

Questo è solo un esempio molto semplice. Una buona strategia di difesa in profondità ha molti livelli che insieme creano un sistema sicuro.

score 22 · Answer 2

Hai assolutamente ragione. Non c'è nulla di magico nella porta 80 o nella porta 443. Non c'è nulla di intrinsecamente sicuro su una porta o su un'altra, o persino un protocollo o un altro. Se blocchi tutto tranne HTTP, ognuno inizierà semplicemente a utilizzare HTTP. Gli attaccanti possono e si muovono sempre più velocemente di qualsiasi altra cosa. Non sono limitati mantenendo la vecchia infrastruttura.

In sostanza, i protocolli e le porte non sono sicuri o insicuri. Bloccarli è solo un'altra forma di teatro della sicurezza.

score 11 · Answer 3

L'elenco in bianco è generalmente preferibile alla lista nera. Se apri solo le porte effettivamente necessarie, e se limiti queste porte nella misura del possibile, hai ridotto la superficie di attacco e limitato il traffico che devi guardare.

Sì, 80 e 443 possono ancora essere sfruttati per traffico dannoso. Ma stai anche alzando la barra per gli attacchi (almeno un po ') forzandoli attraverso una finestra molto più piccola, e una che puoi tenere più facilmente d'occhio.

score 3 · Answer 4

I numeri di porta non contano. Le applicazioni che sono in ascolto o in connessione su qualsiasi porta contano. Usa la rete per limitare i vettori di attacco delle applicazioni.

Alcuni suggerimenti:

I nodi dell'applicazione devono essere accessibili su più reti con diversi scopi e profili di traffico: una rete di applicazioni e una rete di gestione.
Evita applicazioni sulle porte < 1024, ad es. usa 8080 o qualche altra porta casuale. NAT alle porte delle applicazioni ai limiti della rete dell'applicazione (al LB).
Utilizzare iptables per consentire solo il traffico delle applicazioni (80, 443) da specifici IP di bilanciamento del carico (se non si utilizza LB a route diretta) o ai servizi interni (il DB).
Limita SSH (22) e altro traffico (registrazione) a una rete di gestione.
Separare fisicamente le reti, se possibile.
Non fare affidamento su DNS per la configurazione del nodo dell'applicazione.
Segrega reti aziendali e di sviluppo dalle reti di produzione.
Monitora le reti segregate per il traffico non approvato. ad es .: il traffico SSH sulla rete dell'applicazione indica un problema.