Porte router

[XalienX]

Mi sono sempre chiesto una cosa. In ufficio/casa ho sempre ustao router con firewall integrato dove ho sempre dovuto specificare che porte aprire.

Anche non aprendo quelle assegnate ai programmi di p2p o simili c'è un effettivo dw e upload (più limitato ma c'è) sopratutto in ufficio dove avendo la porta chiusa scarico in ogni caso a velocità molto alte.

Detto questo, perchè un'applicazione con una porta specifica riesce in ogni caso a usare la banda anche se sul firewall la suddettta non è aperta?

[lupotto]

Originariamente inviato da XalienX

Mi sono sempre chiesto una cosa. In ufficio/casa ho sempre ustao router con firewall integrato dove ho sempre dovuto specificare che porte aprire.

Anche non aprendo quelle assegnate ai programmi di p2p o simili c'è un effettivo dw e upload (più limitato ma c'è) sopratutto in ufficio dove avendo la porta chiusa scarico in ogni caso a velocità molto alte.

Detto questo, perchè un'applicazione con una porta specifica riesce in ogni caso a usare la banda anche se sul firewall la suddettta non è aperta?

Molto spesso i firewall lasciano passare il traffico in uscita sulle porte alte dalla 1024 in poi, salvo diverse indicazioni, inoltre almeno per quelli che conosco io di solito hanno una regola che permette di accettare connessioni in ingresso, se queste hanno uno stato di relazione con connessioni già instaurate o comunque permesse dal firewall stesso, tipico scenario con i server ftp passivi, dove il client apre la sessione con il server sulla porta 21 e trasmette i comandi al server, dopodichè quando deve essere effettuato il download è il server ad aprire verso il client il canale dati su una porta random tcp, in questo caso il firewall accetterà la connessione in ingresso, perchè è associata ad una preesistente (che parte dal tuo client verso la porta 21 del server) e in relazione con essa

Spero che era questo che volevi sapere, inoltre le porte possono essere viste lato sorgente ( chi apre la connessione) e lato destinazione ( chi riceve la connessione )

[nuovoUtente86]

tipico scenario con i server ftp passivi, dove il client apre la sessione con il server sulla porta 21 e trasmette i comandi al server, dopodichè quando deve essere effettuato il download è il server ad aprire verso il client il canale dati su una porta random tcp, in questo caso il firewall accetterà la connessione in ingresso, perchè è associata ad una preesistente (che parte dal tuo client verso la porta 21 del server) e in relazione con essa

Non è esattamente cosi: l' FTP passivo si utilizza in presenza di firewall, in quanto il client gestisce solo inizializzazioni uscenti (prima sulla 21 e poi su una random aperta dal server). Nella modalità attiva è invece il server ad instaurare un socket dalla proprio porta 20 alla random (in verità, in accordo con gli rfc, alla remota+1) del client. Ovviamente in presenza di un firewall ciò non funziona, a meno di utilizzare regole di triggering (che in ogni caso non relazionano connessioni ma eventi). Va inoltre tenuto conto, in presenza di NAT, del tipo dello stesso e agire di conseguenza....ma questo sarebbe un discorso troppo lungo e tecnico.

[lupotto]

Originariamente inviato da nuovoUtente86

Non è esattamente cosi: l' FTP passivo si utilizza in presenza di firewall, in quanto il client gestisce solo inizializzazioni uscenti (prima sulla 21 e poi su una random aperta dal server). Nella modalità attiva è invece il server ad instaurare un socket dalla proprio porta 20 alla random (in verità, in accordo con gli rfc, alla remota+1) del client. Ovviamente in presenza di un firewall ciò non funziona, a meno di utilizzare regole di triggering (che in ogni caso non relazionano connessioni ma eventi). Va inoltre tenuto conto, in presenza di NAT, del tipo dello stesso e agire di conseguenza....ma questo sarebbe un discorso troppo lungo e tecnico.

Si hai ragione ho confuso l'attivo/passivo come funzionamento

Quanto alle NAT mi interessa.......c'entrano con questo discorso? ti riferisci al fatto che se sono DNAT sono processate nella catena di prerouting e sono SNAT in quella di postrouting?

[nuovoUtente86]

Originariamente inviato da XalienX

Mi sono sempre chiesto una cosa. In ufficio/casa ho sempre ustao router con firewall integrato dove ho sempre dovuto specificare che porte aprire.

Anche non aprendo quelle assegnate ai programmi di p2p o simili c'è un effettivo dw e upload (più limitato ma c'è) sopratutto in ufficio dove avendo la porta chiusa scarico in ogni caso a velocità molto alte.

Detto questo, perchè un'applicazione con una porta specifica riesce in ogni caso a usare la banda anche se sul firewall la suddettta non è aperta?

Scusa ma mi sono dimenticato di rispondere al post principale: il tutto funziona, seppur con delle limitazioni, perchè il/i protocolli p2p hanno previsto anche l' assenza di porte inbound raggiungibili. Se cosi non fosse stato non ci sarebbe stato traffcio. Banalmente il tutto funziona perchè si passa da una architettura p2p ad una client/server.

[nuovoUtente86]

Originariamente inviato da lupotto

Si hai ragione ho confuso l'attivo/passivo come funzionamento

Si è un po fatto un minestrone.
FTP ATTIVO

Client Server

random*--------------------> 21
random <--------------------- 21
random+1 <-------------------20 (ed è qui che nascono i problemi)
random+1 ------------------->20

FTP Passivo
Client Server
random*--------------------> 21
random <--------------------- 21
random+1-------------------->random_server
random+1<--------------------random_server



* (>49151 come prescrive la IANA, anche se solo windows Vista e successivi rispettano questa regola )

Quanto alle NAT mi interessa.......c'entrano con questo discorso? ti riferisci al fatto che se sono DNAT sono processate nella catena di prerouting e sono SNAT in quella di postrouting?

Non è tanto importante in che fase il routing avviene ma di che tipo lo stesso è (da Full Cone a restricted fino a simmetrico).
In generale si affronta l' argomento circa il SNAT.
Ciò che è importante notare e sapere è che in base al tipo di NAT, utilizzato, è possibile instaurare connessioni lecitamente (ma anche sfruttarne le intrinseche vulnerabilità) in maniera più o meno restrittiva anche semplicemente conoscendo l' ip pubblico. Ad esempio in caso di FULL Cone è possibile rediriggere verso un host interne tutto il traffico inbound, semplicemente sapendo il primo mapping effettuato, mentre con un IP spoof è possibile accedere al NAT ristretto. Un mansione va fatta anche al fenomeno del dinamic triggering, cui accennavi, avvero la capacità di firewall e Natter di negoziare le porte, andando a leggere le direttive di protocollo. Questa è una pratica da non utilizzare nella configurazione, in quanto con dei semplici pacchetti malformati è possibile condurre un attacco di tipo NAT-pinning.

[lupotto]

Originariamente inviato da nuovoUtente86

Si è un po fatto un minestrone.
FTP ATTIVO

Client Server

random*--------------------> 21
random <--------------------- 21
random+1 <-------------------20 (ed è qui che nascono i problemi)
random+1 ------------------->20

FTP Passivo
Client Server
random*--------------------> 21
random <--------------------- 21
random+1-------------------->random_server
random+1<--------------------random_server



* (>49151 come prescrive la IANA, anche se solo windows Vista e successivi rispettano questa regola )


Non è tanto importante in che fase il routing avviene ma di che tipo lo stesso è (da Full Cone a restricted fino a simmetrico).
In generale si affronta l' argomento circa il SNAT.
Ciò che è importante notare e sapere è che in base al tipo di NAT, utilizzato, è possibile instaurare connessioni lecitamente (ma anche sfruttarne le intrinseche vulnerabilità) in maniera più o meno restrittiva anche semplicemente conoscendo l' ip pubblico. Ad esempio in caso di FULL Cone è possibile rediriggere verso un host interne tutto il traffico inbound, semplicemente sapendo il primo mapping effettuato, mentre con un IP spoof è possibile accedere al NAT ristretto. Un mansione va fatta anche al fenomeno del dinamic triggering, cui accennavi, avvero la capacità di firewall e Natter di negoziare le porte, andando a leggere le direttive di protocollo. Questa è una pratica da non utilizzare nella configurazione, in quanto con dei semplici pacchetti malformati è possibile condurre un attacco di tipo NAT-pinning.

Grazie davvero interessante l'ultima parte della spiegazione, mi vado a cercare un pò di documentazione in giro, soprautto perchè è la prima volta che sento parlare del NAT-pinning