La mia comprensione è che i gateway a livello di applicazione limitano il traffico proxy su base di porta e protocollo, ad esempio HTTP sulla porta 80 o MQTT sulla porta 1883. Entrambi i tipi di traffico utilizzano TCP come trasporto ma un protocollo diverso. C'è qualche vantaggio in termini di sicurezza a questo? Non riesco a pensare in alcun modo che limitando il protocollo su una porta sia più sicuro.
Questa è una domanda successiva a questo che capisco di dire che non ci sono vantaggi.
Ispezione del traffico (in particolare per il filtro delle applicazioni).
Se sono un datore di lavoro e tengo registri proxy HTTP dei siti Web visitati (e blocco alcuni degli indesiderabili in orario di lavoro come Facebook), non voglio che ti colleghi a un VPN o altro proxy SOCKS e ignorando le mie restrizioni o caricando le mie informazioni commerciali riservate è per questo che mi sono preso la briga di bloccare quali porte TCP / UDP possono essere utilizzate in primo luogo perché capita di sapere che la porta TCP 80 è un free-for-all sul nostro firewall .
Quindi, mentre su un firewall, in genere posso bloccare tutto dalle workstation a Internet oltre alla porta 80. ma poi vai a cercare un proxy che sta girando sulla porta 80 per connettersi a .. assicurandoti che il solo traffico in corso attraverso è un traffico HTTP valido assicura che posso ispezionare e il malware lo scannerizza.
Inoltre, non voglio che ti colleghi ai client BitTorrent sulla porta TCP 80 e utilizzi la mia connessione di rete per BitTorrent.
Sono d'accordo con il commentatore che Application Layer Inspection non è molto comune. Ci sono troppe porte per le varie applicazioni in uso ora (in particolare sui dispositivi mobili) e troppi protocolli proprietari fluttuanti (che io suppongo sia uno dei motivi per cui Microsoft ha deciso di bin Forefront TMG, probabilmente si annoiano a scrivere i filtri dell'applicazione ) che Application Layer Inspection è spesso troppo restrittivo per la maggior parte degli ambienti e causa più problemi di supporto di quanti ne valga la pena (in confronto al piccolo numero di persone che potrebbero provare e avere le conoscenze tecniche per sfruttare le mie regole del firewall).
What'sApp proverà a connettersi sulla porta TCP 443 (tipicamente utilizzata da TLS) tramite il proprio protocollo bizzarro (ovvero TLS NOT) per ignorare in modo specifico eventuali firewall che non consentono la normale porta della porta TCP 5222.
Infine, le connessioni crittografate in genere non rivelano quale sia l'applicazione (la mia connessione TLS è una a un server Web o al mio server di posta o a una VPN TLS?) e una cieca "Consenti tutto il traffico TLS su La porta TCP 443 "continua a comportare l'abuso, a meno che tu non abbia qualche dispositivo di visibilità TLS.
Potresti anche voler consultare la sezione Filtri a livello di applicazione dell'articolo Stateful Firewall e i suoi associati Articolo Application Firewall su Wikipedia.
... never open a socket to "any" protocal,...
Un socket viene aperto da un'applicazione per accettare i dati per un protocollo specifico, perché questo è il modo in cui funzionano le applicazioni. Nessuna applicazione accetterebbe "qualsiasi" dato perché semplicemente non sa come gestire questi dati, cioè ha implementato solo uno specifico protocollo di comunicazione come HTTP, SMTP, ecc. La porta per il socket è simile al numero della casa nel street, cioè è semplicemente parte dell'indirizzo completo di un servizio.
Se si sta invece parlando di firewall: semplicemente i firewall di filtraggio delle porte non utilizzano affatto socket ma semplicemente passano o bloccano i pacchetti in base alla porta indicata nel pacchetto TCP / UDP. E i gateway a livello di applicazione (proxy) utilizzano socket, ma il compito è quello di filtrare il traffico per un protocollo specifico, quindi ancora una volta sono in grado di parlare solo questo specifico protocollo e non "nessuno".