Pagina 2 di 3 primaprima 1 2 3 ultimoultimo
Visualizzazione dei risultati da 11 a 20 su 22

Discussione: Fastweb con + di 4 pc

  1. #11
    Mai sentito parlare di ttl?
    E' vero, non ci avevo pensato!
    Avevo infatti specificato "soltanto per quanto concerne questi due aspetti" sicuro che una qualche scappatoia sarebbe saltata inevitabilmente fuori.
    Rilasciata Python FTP Server library 0.5.1
    http://code.google.com/p/pyftpdlib/

    We'll be those who'll make the italian folks know how difficult can be defecating in Southern California without having the crap flying all around the house.

  2. #12
    Originariamente inviato da maiosyet_2
    Mai sentito parlare di ttl? (:
    Il ttl viene azzerato (nel senso che viene messo quello di default di partenza col nat). Non ci si può accorgere di un natting neanche dal ttl. Il nat è semplicemente (come ha detto giustamente billijoex) una tabella che fa un match di connessioni su due interfaccie. Addirittura il sistema di natting va a modificare eventuali header a livello applicativo (vedi intestazione dei pacchetti ftp. senza il corretto modulo ad esempio sotto linux te lo scordi il natting delle connessione ftp).
    Indi per cui non mi pare che sia "sgamabile" il natting se non spulciando in quei protocolli applicativi che magari mantengono certi header spuri e che non vengono toccati dal nat.
    A forza di seguire la corrente si finisce in qualche fogna
    -- M.Connelly

    http://www.syn-ack.it

  3. #13
    Il ttl viene azzerato (nel senso che viene messo quello di default di partenza col nat). Non ci si può accorgere di un natting neanche dal ttl
    Uhm... sei sicuro che questo avvenga? Io sinceramente non lo so.
    Bisognerebbe vedere se esistono delle rfc che dettino delle precise specifiche a riguardo.
    Secondo me "a naso" il valore di TTL dovrebbe gia essere variato sul NAT. Dopotutto esso rappresenta a tutti gli effetti un "nodo" (il primo) che i client devono attraversare. In questo caso il provider potrebbe determinare se il suo cliente utilizza o meno un NAT a seconda dei differenti valori di TTL che gli pervengono.
    Addirittura il sistema di natting va a modificare eventuali header a livello applicativo (vedi intestazione dei pacchetti ftp. senza il corretto modulo ad esempio sotto linux te lo scordi il natting delle connessione ftp).
    Vero. Sono impazzito per una mezza giornata prima di capire che dovevo caricare il modulo "ip_nat_ftp" per permettere ai client di collegarsi a server ftp su internet.
    Rilasciata Python FTP Server library 0.5.1
    http://code.google.com/p/pyftpdlib/

    We'll be those who'll make the italian folks know how difficult can be defecating in Southern California without having the crap flying all around the house.

  4. #14
    codice:
    [prometeus@helvete:~/Desktop]$ traceroute -I google.it
    traceroute: Warning: google.it has multiple addresses; using 216.239.39.104
    traceroute to 216.239.39.104 (216.239.39.104), 30 hops max, 38 byte packets
     1  router (10.0.0.2)  0.341 ms  0.306 ms  0.299 ms
     2  192.168.100.1 (192.168.100.1)  45.255 ms  45.564 ms  47.218 ms
     3  r-mi225-vl19.opb.interbusiness.it (80.20.7.12)  70.034 ms  68.987 ms  85.606 ms
     4  r-mi258-mi225.opb.interbusiness.it (80.17.211.93)  69.061 ms
    [prometeus@helvete:~/Desktop]$ ping 80.20.7.12
    PING 80.20.7.12 (80.20.7.12) 56(84) bytes of data.
    64 bytes from 80.20.7.12: icmp_seq=1 ttl=253 time=87.8 ms
    64 bytes from 80.20.7.12: icmp_seq=2 ttl=253 time=57.2 ms
    64 bytes from 80.20.7.12: icmp_seq=3 ttl=253 time=97.6 ms
    
    --- 80.20.7.12 ping statistics ---
    3 packets transmitted, 3 received, 0% packet loss, time 2002ms
    rtt min/avg/max/mdev = 57.293/80.915/97.608/17.174 ms
    [prometeus@helvete:~/Desktop]$ ping 10.0.0.1
    PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
    64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=0.211 ms
    64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.203 ms
    64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=0.186 ms
    
    --- 10.0.0.1 ping statistics ---
    3 packets transmitted, 3 received, 0% packet loss, time 2000ms
    rtt min/avg/max/mdev = 0.186/0.200/0.211/0.010 ms

    direi che questi valori sono esplicativi.
    Il nat è differente dal routing. Ogni qual volta passi da un router viene scalato il ttl del pacchetto, ma il nat non è un router. E' una cosa differente.
    A forza di seguire la corrente si finisce in qualche fogna
    -- M.Connelly

    http://www.syn-ack.it

  5. #15
    come dice billiejoex, a livello IP non c'è nulla che resti "in mano al pacchetto", nsel senso che il gateway/router/chicazzè si occupa dell'instradamento in base a delle sue proprie tabelle.
    Ovvio che come usciamo fuori dallo strato IP ci sono una miriade di tracce, come esempio l'http che nelle request si porta l'IP, o il telnet che manda un'autenticazione, o un fottìo di protocolli che non sto nemmeno ad enumerare.

    insomma, tutto sommato per controllare che effettivamente uno non usi più di 4 pc si dovrebbero veramente mettere lì a farsi i ca22i tuoi....
    Ci sono cose che non si possono sapere. Per tutto il resto c'è man

    Prima di fare domande stupide: 1) googla 2) leggi le manpages 3) sparati.

  6. #16
    Utente di HTML.it
    Registrato dal
    Jul 2001
    Messaggi
    1,003
    Originariamente inviato da prometeus
    [CODE][prometeus@helvete:~/Desktop]$ traceroute -I google.it
    traceroute: Warning: google.it has multiple addresses; using 216.239.39.104
    traceroute to 216.239.39.104 (216.239.39.104), 30 hops max, 38 byte packets
    1 router (10.0.0.2) 0.341 ms 0.306 ms 0.299 ms
    2 192.168.100.1 (192.168.100.1) 45.255 ms 45.564 ms 47.218 ms
    3 r-mi225-vl19.opb.interbusiness.it (80.20.7.12) 70.034 ms 68.987 ms 85.606 ms
    4 r-mi258-mi225.opb.interbusiness.it (80.17.211.93) 69.061 ms
    Ti sei fregato

    Allora, lo standard dice che i valori tipici di TTL usati sono 64,128 e 255. Quindi si parte da 255.

    80.20.7.12 manda un echo reply (TTL 255), passa a 192.168.100.1 che lo gira a router con TTL 254 che lo gira al client con TTL 253

    Infatti:
    [prometeus@helvete:~/Desktop]$ ping 80.20.7.12
    PING 80.20.7.12 (80.20.7.12) 56(84) bytes of data.
    64 bytes from 80.20.7.12: icmp_seq=1 ttl=253 time=87.8 ms
    64 bytes from 80.20.7.12: icmp_seq=2 ttl=253 time=57.2 ms
    64 bytes from 80.20.7.12: icmp_seq=3 ttl=253 time=97.6 ms
    Inoltre 255-253= 2 hop, ovvero router e 192.168.100.1
    cvd

    direi che questi valori sono esplicativi.
    Il nat è differente dal routing. Ogni qual volta passi da un router viene scalato il ttl del pacchetto, ma il nat non è un router. E' una cosa differente.
    Il NAT non è routing ma serve un routing altrimenti che cosa 'natti'?
    Quindi un router con NAT scala lo stesso il TTL.

  7. #17
    Appunto, come pensavo.
    Sempre che questo non comporti eventuali disfunzionamenti (tia86: ne comporta, che tu sappia?) esiste una regola in iptables che permette di evitare che il valore di TTL venga decrementato per tutti i pacchetti routati dal gateway?
    Qualcuno ne sa qualcosa?
    Se cosi fosse, in questo modo, a parte al già citato (da stai_tranquillo) nonchè improbabile controllo ad application layer, il provider non dovrebbe avere apparentemente alcun modo di determinare un eventuale masquerading.

    Allora, lo standard dice che i valori tipici di TTL usati sono 64,128 e 255. Quindi si parte da 255.
    Questi parametri da chi sono decisi? Dal kernel della piattaforma? Posso andare a modificarli a mano magari ricompilando il kernel? Chiedo questo perchè se cosi fosse si potrebbero eludere i sistemi di os fingerprinting basati su TTL, come ad esempio quello incluso in nmap, il che non sarebbe male. Linux mi permette di mettere mano a tali parametri di cosi basso livello?
    Rilasciata Python FTP Server library 0.5.1
    http://code.google.com/p/pyftpdlib/

    We'll be those who'll make the italian folks know how difficult can be defecating in Southern California without having the crap flying all around the house.

  8. #18
    Utente di HTML.it L'avatar di giomazz
    Registrato dal
    Dec 2001
    Messaggi
    255
    Originariamente inviato da prometeus
    codice:
    [prometeus@helvete:~/Desktop]$ traceroute -I google.it
    traceroute: Warning: google.it has multiple addresses; using 216.239.39.104
    traceroute to 216.239.39.104 (216.239.39.104), 30 hops max, 38 byte packets
     1  router (10.0.0.2)  0.341 ms  0.306 ms  0.299 ms
     2  192.168.100.1 (192.168.100.1)  45.255 ms  45.564 ms  47.218 ms
     3  r-mi225-vl19.opb.interbusiness.it (80.20.7.12)  70.034 ms  68.987 ms  85.606 ms
     4  r-mi258-mi225.opb.interbusiness.it (80.17.211.93)  69.061 ms
    [prometeus@helvete:~/Desktop]$ ping 80.20.7.12
    PING 80.20.7.12 (80.20.7.12) 56(84) bytes of data.
    64 bytes from 80.20.7.12: icmp_seq=1 ttl=253 time=87.8 ms
    64 bytes from 80.20.7.12: icmp_seq=2 ttl=253 time=57.2 ms
    64 bytes from 80.20.7.12: icmp_seq=3 ttl=253 time=97.6 ms
    
    --- 80.20.7.12 ping statistics ---
    3 packets transmitted, 3 received, 0% packet loss, time 2002ms
    rtt min/avg/max/mdev = 57.293/80.915/97.608/17.174 ms
    [prometeus@helvete:~/Desktop]$ ping 10.0.0.1
    PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
    64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=0.211 ms
    64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.203 ms
    64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=0.186 ms
    
    --- 10.0.0.1 ping statistics ---
    3 packets transmitted, 3 received, 0% packet loss, time 2000ms
    rtt min/avg/max/mdev = 0.186/0.200/0.211/0.010 ms

    direi che questi valori sono esplicativi.
    Il nat è differente dal routing. Ogni qual volta passi da un router viene scalato il ttl del pacchetto, ma il nat non è un router. E' una cosa differente.
    spy@1[~]$ traceroute -I google.it
    traceroute: Warning: google.it has multiple addresses; using 216.239.57.104
    traceroute to google.it (216.239.57.104), 30 hops max, 40 byte packets
    1 192.168.1.1 (192.168.1.1) 0.708 ms 0.545 ms 0.522 ms
    2 192.168.100.1 (192.168.100.1) 44.009 ms 43.214 ms 41.202 ms
    3 r-fi67-5-vl19.opb.interbusiness.it (80.19.134.145) 42.859 ms 43.065 ms 41.732 ms
    4 r-fi62-fi67.opb.interbusiness.it (151.99.98.81) 43.376 ms 41.543 ms 42.783 ms
    5 r-rm215-fi62.opb.interbusiness.it (151.99.101.193) 47.011 ms 49.368 ms 46.961 ms
    6 r-rm180-vl4.opb.interbusiness.it (151.99.29.214) 47.542 ms 47.796 ms 48.507 ms
    7 rom4-ibs-resid-13-it.rom.seabone.net (213.144.177.189) 48.605 ms 48.863 ms 47.476 ms
    8 linx-lon1-racc1.lon.seabone.net (195.22.209.109) 80.405 ms 80.164 ms 101.763 ms
    9 195.66.224.125 (195.66.224.125) 81.998 ms 102.401 ms 83.840 ms
    10 72.14.236.216 (72.14.236.216) 157.295 ms 156.665 ms 154.991 ms
    11 66.249.94.235 (66.249.94.235) 160.815 ms 161.354 ms 162.320 ms
    12 66.249.95.123 (66.249.95.123) 155.595 ms 158.192 ms 156.071 ms
    13 66.249.94.233 (66.249.94.233) 173.340 ms 173.361 ms 172.746 ms
    14 66.249.95.246 (66.249.95.246) 172.814 ms 172.850 ms 172.740 ms
    15 216.239.46.44 (216.239.46.44) 220.698 ms 219.627 ms 219.707 ms
    16 72.14.236.9 (72.14.236.9) 220.325 ms 217.072 ms 72.14.236.11 (72.14.236.11) 216.198 ms
    17 216.239.47.194 (216.239.47.194) 218.188 ms 218.047 ms 216.587 ms
    18 216.239.49.93 (216.239.49.93) 222.930 ms 224.828 ms 66.249.94.25 (66.249.94.25) 225.036 ms
    19 216.239.57.104 (216.239.57.104) 217.648 ms 218.613 ms 216.239.49.2 (216.239.49.2) 226.037 ms

    a me esce questo output molto diverso
    da che deriva?
    amd 3400+ ram 1024 mb maxtor 60 giga ata 133 maxtor 80 giga atat 133
    power Slamd64 current

  9. #19
    Utente di HTML.it L'avatar di gianiaz
    Registrato dal
    May 2001
    Messaggi
    8,027
    Non sono cosi esperto come voi, ma da quel che ricordo di teoria delle reti, l'ip sorgente rimane sempre lo stesso, è il mac address che viene sostituito ogni volta dai router.

  10. #20
    Originariamente inviato da tia86
    Ti sei fregato

    Allora, lo standard dice che i valori tipici di TTL usati sono 64,128 e 255. Quindi si parte da 255.

    80.20.7.12 manda un echo reply (TTL 255), passa a 192.168.100.1 che lo gira a router con TTL 254 che lo gira al client con TTL 253

    Infatti:


    Inoltre 255-253= 2 hop, ovvero router e 192.168.100.1
    cvd



    Il NAT non è routing ma serve un routing altrimenti che cosa 'natti'?
    Quindi un router con NAT scala lo stesso il TTL.

    Comunque il ttl di 253 lo vede solo la mia macchina quando arriva il pacchetti icmp. Bisogna vedere ciò che vede il primo router del provider (il primo punto in cui il provider si può permettere di analizzare il traffico).
    In qualunque caso si può mettere sulla macchina che fa nat una regola di iptables che resetti il count del ttl. (mangle se non ricordo male).
    Stasera mi metto a fare i test con iptables per sciogliere questo dubbio .

    Per giomazz: l'output è molto differente perchè l'ho troncato. In realtà dovrebbe essere più o meno lo stesso del tuo (come lunghezza). Poi le routes dipendono da provider a provider.

    Per billiejoex:
    Si. suddetti parametri possono essere modificato agendo sul kernel, credo a livello sorgente e forse agento sul /proc filesystem. Esistono in giro dei tutorial per mettere mano alle impostazioni di tutti gli os, per modificare il proprio fingerprinting.
    Segnalo ad esempio anonymOS, una openbsd modificata appositamente per avere un fingerprinting come quello di un windows.
    A forza di seguire la corrente si finisce in qualche fogna
    -- M.Connelly

    http://www.syn-ack.it

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2026 vBulletin Solutions, Inc. All rights reserved.