slacky.eu

ragazzi aiutatemi: non capisco una cosa temo abbastanza fondamentale.
ogni servizio per connettersi al pc usa una porta. la mia domanda èil fatto che le porte in un sistema siano chiuse significa semplicemente che nn c'è nessun servizio in esecuzione, e che le porte sono per così dire "in attesa" oppure significa proprio che bisogna prima aprirle per poter usare un determinato servizio? se è così come si fa ad aprirle?

forse non ho capito come funzionano le cose e tendo ad assimilare il comportamento dell'os a quello di un firewall...

potete chiarirmi le idee?

infine.. una scansione cn nmap localhost cosa mi dice? i risultati sono diversi da quelli che otterrei se la scansione venisse fatta da remoto?

grazie mille"!!!

Beh... vediamo.
Bisogna vedere cosa intendi per servizio intanto. In ogni caso per darti un'idea, una porta può essere chiusa indipendentemente dal fatto che qualcuno voglia usarla.
Tant'è appunto che se attivi ad esempio un server di posta e non dici al firewall di aprire la porta (ovviamente precedentemente giustamente tenuta chiusa), questo server non riuscirà a far ciò per cui l'hai installato.

La scansione di nmap teoricamente ti dà le stesse informazioni in entrambi i casi.

Dimenticavo... per le porte dipende da che firewall usi.
Su linux c'è iptables che è di default e puoi far riferimento alla sua documentazione.

(man iptables e tutti gli howto di slacky e della rete!)

sinteticamente: quando un processo vuol ricevere pacchetti tcp o udp via rete, fa una chiamata di sistema al kernel, che si chiama bind(), con essa dice al kernel che tutti i pacchetti che arrivano e che hanno in un campo dell'header ip un determinato ip e in un campo dell'header tcp un determinato numero (la porta di destinazione), devono essere recapitati al processo che ha fatto la suddetta bind().

come si fa ad aprirle?

Che significa "aprire"? le "porte" sono solo dei numeretti usati per associare un certo tipo di traffico ad un dato processo; non c'e' nulla da "aprire", se un dato numeretto (porta) viene associato ad un processo tramite una bind(), la porta (su un dato ip) e' allocata per un processo, altrimenti no.
Ti consiglio un buon testo sul networking, in particolare su tcp/ip (lo Stevens e' molto buono, ma ce ne sono a pacchi di libri che trattano l'argomento)

Pensa a delle porte socchiuse. (chiuse, ma apribili)
Quando avvii un'applicazione o un servizio sceglie una porta e un indirizzo, ci mette il suo nome (bind), si piazza davanti e la apre aspettado di 'ricevere qualcuno' (listen)

Quando si parla di aprire le porte si vuole intendere invece a disabilitare il firewall su quella porta o se sei dietro router si intende forwardare le richieste dall'esterno alla porta del tuo pc.
Per verificare se una porta è aperta (c'è qualche programma che la sta usando e non c'è nessun firewall che blocca l'accesso e non c'è nessun router che devia la tua richiesta) puoi provare a collegarti con
telnet indirizzo porta


nmap da locale o da remoto danno risultati diversi. Ad esempio il demone di freepops di default fa il bind solo su 127.0.0.1:2000 ovvero è accessibile solo se richiamata dallo stesso pc su cui gira.Chiaro no?

nmap da locale o da remoto danno risultati diversi. Ad esempio il demone di freepops di default fa il bind solo su 127.0.0.1:2000 ovvero è accessibile solo se richiamata dallo stesso pc su cui gira.Chiaro no?

Solo per una precisazione mia: effetivamente quando inizialmente dissi che davano le stesse informazioni, escludevo a priori casi tipo questo

masalapianta:

Che significa "aprire"? le "porte" sono solo dei numeretti usati per associare un certo tipo di traffico ad un dato processo; non c'e' nulla da "aprire", se un dato numeretto (porta) viene associato ad un processo tramite una bind(), la porta (su un dato ip) e' allocata per un processo, altrimenti no.
Ti consiglio un buon testo sul networking, in particolare su tcp/ip (lo Stevens e' molto buono, ma ce ne sono a pacchi di libri che trattano l'argomento)

scusa se ti faccio un appuntino... siccome sono termini che in gergo si usano ed hanno un loro significato, penso sia bene spiegarli a chi non li conosce come ha fatto dapuzz, senza contare che lo Stevens non ha né un costo contenuto né è for dummies

Che significa "aprire"? le "porte" sono solo dei numeretti usati per associare un certo tipo di traffico ad un dato processo; non c'e' nulla da "aprire", se un dato numeretto (porta) viene associato ad un processo tramite una bind(), la porta (su un dato ip) e' allocata per un processo, altrimenti no.

bene chiaro: la porta serve per associare ad un processo i dati che gli servono!! ci sono!! ora è più chiara la cosa!! è un firewall come iptables non fa altro che impedire che arrivino dati ai processi associati alle porte che cn iptables vengono chiuse (scusa il termine ma nn ne so altri).

mentre per qwuanto riguarda il router il discorso è diverso ed intuitivamente capisco che il traffico debba essere rediretto!!

bene.. spero di aver capito bene!!

grazie mille a tutti!! questa è una bellissima community che mi "sopporta" anche nelle mie domande niubbe! grazie mille!


ma a questo punto mi nasce una nuova domanda: quello che ho detto sopra è chiaro per un demone... ma prendiamo il router in particolare... supponiamo che io mi voglia collegare ad una pagina internet attraverso un browser.. in quel caso nn serve redirigere la porta.. perchè? non c'è traffico anche verso l'interno??

Ermes1 ha scritto: ma a questo punto mi nasce una nuova domanda: quello che ho detto sopra è chiaro per un demone... ma prendiamo il router in particolare... supponiamo che io mi voglia collegare ad una pagina internet attraverso un browser.. in quel caso nn serve redirigere la porta.. perchè? non c'è traffico anche verso l'interno??

Traffico si, ma non connessione. La connessione la apre il tuo browser verso l'esterno, una volta aperta il traffico puo' andare indifferentemente nelle due direzioni, perche' viaggia sempre sulla connessione che tu hai aperto.

bene! ora dunque mi spiego in modo più chiaro i due modi di traferimento ftp: l'attivo e il passivo!! grazie di nuovo a tutti!

red ha scritto: scusa se ti faccio un appuntino... siccome sono termini che in gergo si usano

nel gergo di chi? c'e' anche gente che sbaglia i congiuntivi, dice "a me mi" e usa il termine hacker in luogo di cracker, non per questo son cose da usare; "aprire una porta" non ha sensoin informatica.

ed hanno un loro significato

no

penso sia bene spiegarli a chi non li conosce come ha fatto dapuzz

infatti gli ho spiegato cosa realmente si intende per porte

senza contare che lo Stevens non ha né un costo contenuto né è for dummies

infatti non esiste il "networking for dummies", o conosci la materia o non la conosci, meglio non conoscerla, che pensare di conoscerla avendo letto qualcosa che, usando analogie errate e semplificando troppo, in realta' ti da concetti sbagliati; lo stevens (come qualsivoglia buon testo sul tcp/ip) non presuppone troppe conoscenze pregresse ed e' alla portata di tutti.

Ermes1 ha scritto: ma a questo punto mi nasce una nuova domanda: quello che ho detto sopra è chiaro per un demone... ma prendiamo il router in particolare... supponiamo che io mi voglia collegare ad una pagina internet attraverso un browser.. in quel caso nn serve redirigere la porta.. perchè? non c'è traffico anche verso l'interno??

innanzitutto parli di router genericamente, il che non e' del tutto corretto, in quanto il problema del nat nasce nel caso tu dietro al router abbia una classe di ip privati, il che ti obbliga al nat (che sotto gnu/linux e' l'ip masquerading); le cose vanno piu' o meno cosi' (sempre semplificando):
se ad esempio tu in una rete sotto nat, apri firefox vuoi visualizzare http://www.google.it, firefox manda un pacchetto con il flag syn settato verso http://www.google.it, il pacchetto arriva al router che fa nat nella tua rete, il router sostituisce l'ip sorgente (a layer 3 negli header ip del pacchetto) privato con il suo pubblico, aggiorna il checksum dell'header ip di quel pacchetto e si segna in una tabella che ha fatto nat per quel pacchetto, a quel punto http://www.google.it risponde con un pacchetto con flag syn e ack settate, il pacchetto arriva al router (perche' avendo sostituito l'ip sorgente privato con quello pubblico del ruouter nel pacchetto syn, http://www.google.it usera' come ip di destinazione per il pacchetto syn/ack l'ip pubblico del router), il quale lo accetta perch' l'ip di destinazione appartiene a lui, ma nel contempo controlla nella suddetta tabella se quel pacchetto si riferisce a del traffico iniziato da una macchina sotto nat, se e' cosi' allora fa il processo inverso a quello fatto prima e cioe' sostituisce ip di destinazione con quello della macchina sotto nat e ricalcola il checksum della testata ip, dopodiche' fa normale routing del pacchetto verso la sottorete cui appartiene la macchina nattata.
Diventa a questo punto ovvia la risposta alla tua domanda, nel caso del demone (nella tua rete nattata) che non inizia la connessione, c'e' bisogno di fare port forward perche' il kernel del router non ha modo di ricondurre il pacchetto di un client esterno destinato al demone all'ip privato della macchina su cui gira il demone; mentre a parti invertite, essendo iniziato il traffico da dentro la rete nattata, il kernel del router ha modo di segnarsi in una tabella i riferimenti necessari per ricondurre quel traffico ad un particolare ip privato nella sua rete nattata.

syaochan ha scritto:

Ermes1 ha scritto: ma a questo punto mi nasce una nuova domanda: quello che ho detto sopra è chiaro per un demone... ma prendiamo il router in particolare... supponiamo che io mi voglia collegare ad una pagina internet attraverso un browser.. in quel caso nn serve redirigere la porta.. perchè? non c'è traffico anche verso l'interno??

Traffico si, ma non connessione. La connessione la apre il tuo browser verso l'esterno, una volta aperta il traffico puo' andare indifferentemente nelle due direzioni, perche' viaggia sempre sulla connessione che tu hai aperto.

dal punto di vista del nat il fatto che ci sia connessione o meno e' irrilevante, altrimenti quel che dici non varrebbe per protocolli connectionless come udp (invece il nat su udp funziona egregiamente)

masalapianta ha scritto: dal punto di vista del nat il fatto che ci sia connessione o meno e' irrilevante, altrimenti quel che dici non varrebbe per protocolli connectionless come udp (invece il nat su udp funziona egregiamente)

Io parlavo di nat/firewall che blocca le connessioni tcp in entrata, mi risulta che http si appoggi su tcp, non ho nominato udp.

più o meno mi avete abbozzato la cosa.. ora vedrò di prendere qualche buon libro per capire meglio come funziona!
x masalapianta: mi rendo conto di quello che dici è che è estremamente sbagliato semplificare troppo le cose: d'altra parte però capiscimi... non ho alcuna esperienza seria con il pc.. ho messo linux da 4 mesi e con Windows le cose che si imparano sono nulle!! un pò alla volta, con un pò di impegno vedrai che diventerò bravo anche io e potrò dare il mio aiuto a questa community!!!

syaochan ha scritto:

masalapianta ha scritto: dal punto di vista del nat il fatto che ci sia connessione o meno e' irrilevante, altrimenti quel che dici non varrebbe per protocolli connectionless come udp (invece il nat su udp funziona egregiamente)

Io parlavo di nat/firewall che blocca le connessioni tcp in entrata, mi risulta che http si appoggi su tcp, non ho nominato udp.

aridaje, il nat se ne frega se usi un protocollo connectionless o meno