E' vero, non ci avevo pensato!Mai sentito parlare di ttl?
Avevo infatti specificato "soltanto per quanto concerne questi due aspetti" sicuro che una qualche scappatoia sarebbe saltata inevitabilmente fuori.![]()
E' vero, non ci avevo pensato!Mai sentito parlare di ttl?
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.
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).Originariamente inviato da maiosyet_2
Mai sentito parlare di ttl? (:
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.
Uhm... sei sicuro che questo avvenga? Io sinceramente non lo so.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
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.
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.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).
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.
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.
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.
Ti sei fregatoOriginariamente 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
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[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
cvd
Il NAT non è routing ma serve un routing altrimenti che cosa 'natti'?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.
Quindi un router con NAT scala lo stesso il TTL.
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.
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?Allora, lo standard dice che i valori tipici di TTL usati sono 64,128 e 255. Quindi si parte da 255.
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.
spy@1[~]$ traceroute -I google.itOriginariamente 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.
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
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.
![]()
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.