|
|
|
|
Strumenti |
02-01-2020, 10:50 | #1 |
Senior Member
Iscritto dal: Apr 2001
Città: Milano
Messaggi: 3594
|
[C] scanner internet
scrivere uno scanner per testare indirizzi IP su internet oggi è alla portata di molti però, fatti due conti mi sono detto: se testo un indirizzo ad esempio sulla porta 80 ed impiego 1 secondo, per 2^32 indirizzi impiegherei 136 anni circa e allora, come risolvere un simile problema se si vuole concludere una intera scansione in poco tempo?
Se usassi 136 PC impiegherei 1 anno, improponibile in quanto costoso. Se usassi n thread su un singolo PC sino a saturare la banda della scheda di rete, dovrei stabilire quanti thread ci vogliono per arrivare a saturzione ma credo sempre meno di 136 quindi, impiegherei oltr 1 anno. Idee? |
07-01-2020, 13:37 | #2 |
Senior Member
Iscritto dal: Apr 2005
Messaggi: 2993
|
Scusa ma cosa pensi di saturare facendo una socket.open ? passano 4 byte in croce ( o meglio, 28 byte se prendi un pacchetto udp).
Diciamo quindi che hai banda da 1 Megabit -> 1024 KBytes = 1.024.024 bytes -> /28= 36 mila pacchetti circa (pacchetto più pacchetto meno). Questo per quanto concerne la banda ovviamente. Diciamo pure che un secondo va bene come limite superiore, ma anche da considerare che una chiamata possa rispondere in pochi millisecondi, facciamo una media a 500 ms e manteniamo valido un valore di 30.000 pacchetti (check) al secondo. 2^ 32 sono circa 4 miliardi di ip, che diviso 30.000 fa 143mila secondi e spicci, ovvero circa 40 ore. Che non mi sembra male come tempo. Ma poniamo che 30.000 pacchetti siano troppi e facciamone invece un quarto, quindi 7.500 avremo come stima 160 ore che è nemmeno una settimana. Se vuoi un test molto più empirico che teorico, fai qualche test con nmap e metti dentro una classe IP e vedi come si comporta / quanto tempo impiega. |
07-01-2020, 14:01 | #3 |
Moderatore
Iscritto dal: Nov 2006
Messaggi: 20825
|
purtroppo il calcolo non è così semplice o meglio non bisogna calcolare di saturare la banda ma bensì calcolare sulla base del tempo e del numero di connessioni concorrenti che il tuo s.o. supporta (mi pare 20 per windows 7 / 8.1)
inanzitutto un'apertura di socket impiega pochissimo tempo, altro che 500 ms direi molto più plausibile 5-10 ms ma le connessioni concorrenti comunque rimangono quindi secondo me il tuo sistema deve usare un numero di thread leggermente inferiore al massimo consentito dal tuo s.o. 19 ad esempio per windows 7 per aumentare l'efficienza non puoi assegnare a priori un numero di ip ad ogni thread visto la notevole differenza di tempo tra apertura e timeout ma direi che puoi sviluppare il tuo software con un ulteriore thread di dispatcher che carichi gli indirizzi ip nei vari thread di esecuzione bilanciandone il carico
__________________
"WS" (p280,cx750m,4790k+212evo,z97pro,4x8GB ddr3 1600c11,GTX760-DC2OC,MZ-7TE500, WD20EFRX) Desktop (three hundred,650gq,3800x+nh-u14s ,x570 arous elite,2x16GB ddr4 3200c16, rx5600xt pulse P5 1TB)+NB: Lenovo p53 i7-9750H,64GB DDR4,2x1TB SSD, T1000 |
07-01-2020, 15:40 | #4 |
Senior Member
Iscritto dal: Apr 2005
Messaggi: 2993
|
Mi ripeto: dai un occhio all'implementazione di nmap su questa cosa.
Ad ogni modo, non mi risulta proprio che il numero di thread massimo sia 19. Giusto il primo link saltato fuori: https://eknowledger.wordpress.com/20...ndows-process/ |
08-01-2020, 09:35 | #5 | |
Moderatore
Iscritto dal: Nov 2006
Messaggi: 20825
|
Quote:
__________________
"WS" (p280,cx750m,4790k+212evo,z97pro,4x8GB ddr3 1600c11,GTX760-DC2OC,MZ-7TE500, WD20EFRX) Desktop (three hundred,650gq,3800x+nh-u14s ,x570 arous elite,2x16GB ddr4 3200c16, rx5600xt pulse P5 1TB)+NB: Lenovo p53 i7-9750H,64GB DDR4,2x1TB SSD, T1000 |
|
08-01-2020, 12:39 | #6 |
Senior Member
Iscritto dal: Apr 2005
Messaggi: 2993
|
Guarda che secondo me confondi. Sono 20 e riguardo le connessioni in ingresso (rif: https://community.spiceworks.com/top...nection-limits )
Interessante come il problema quindi sia più nel file descriptor che non nello stck tcp ( https://stackoverflow.com/questions/...t-a-modern-lin ) |
08-01-2020, 12:48 | #7 |
Senior Member
Iscritto dal: Apr 2001
Città: Milano
Messaggi: 3594
|
grazie ad entrambi per i vostri interventi.
Quindi istanziare più di 20 thread non avrebbe senso, viste le limitazioni imposte dall'SO. |
08-01-2020, 13:21 | #8 | ||
Senior Member
Iscritto dal: Apr 2005
Messaggi: 2993
|
Quote:
I thread sono una cosa, le connessioni TCP/UDP un altra. Thread puoi averne diciamo "quanti ne vuoi", finchè non finisci la memoria Quote:
|
||
08-01-2020, 13:46 | #9 | |
Senior Member
Iscritto dal: Apr 2001
Città: Milano
Messaggi: 3594
|
Quote:
mi riferivo appunto alle licenze di microsoft. Se al massimo posso avere 20 connessioni TCP contemporaneamente è inutile istanziare più di 20 thread, giusto? |
|
08-01-2020, 13:59 | #10 |
Senior Member
Iscritto dal: Apr 2005
Messaggi: 2993
|
Scusa ma leggi quello che scrivo?
Si parla di CONNESSIONI IN INGRESSO, non in uscita. |
08-01-2020, 14:02 | #11 | |
Moderatore
Iscritto dal: Nov 2006
Messaggi: 20825
|
Quote:
1 dispatcher che carica e bilancia il carico sui diversi thread di scansione 19 thread di scansione 1 thread che raccoglie e analizza i risultati sulla base di quello che vuoi fare devi gestire bene le strutture di memoria e i lock per aumentare l'efficienza
__________________
"WS" (p280,cx750m,4790k+212evo,z97pro,4x8GB ddr3 1600c11,GTX760-DC2OC,MZ-7TE500, WD20EFRX) Desktop (three hundred,650gq,3800x+nh-u14s ,x570 arous elite,2x16GB ddr4 3200c16, rx5600xt pulse P5 1TB)+NB: Lenovo p53 i7-9750H,64GB DDR4,2x1TB SSD, T1000 |
|
08-01-2020, 14:04 | #12 |
Senior Member
Iscritto dal: Apr 2001
Città: Milano
Messaggi: 3594
|
|
08-01-2020, 14:12 | #13 | |
Senior Member
Iscritto dal: Apr 2001
Città: Milano
Messaggi: 3594
|
Quote:
Embarcadero ha un thread principale e se si vogliono usare i metodi che mette a disposizione tra i quali send e receive dei socket, questi devono essere sinconizzati per evitare eccezioni in maniera randomica. Poi di problemi ne ho individuati anche molti altri, ma un passo alla volta. Grazie 1000 |
|
08-01-2020, 17:28 | #14 |
Member
Iscritto dal: Jul 2011
Messaggi: 246
|
Domanda: ma se bypassi del tutto l'interfaccia dei socket fornita dal SO e spari direttamente i pacchetti nella scheda di rete (ovviamente devi generarti a mano i vari header necessari per generare un ping).
In questo modo hai più libertà ma devi interfacciarti col driver di più basso livello (anche per leggere tutto il traffico di risposta che arriva)...
__________________
Non c'è cosa peggiore nella vita di un programmatore di un errore che si presenta solo ogni tanto. CONCLUSO POSITIVAMENTE CON: oldfield |
08-01-2020, 18:50 | #15 | |
Senior Member
Iscritto dal: Apr 2001
Città: Milano
Messaggi: 3594
|
Quote:
intendi con le winsock? forse intendeva by-passando l'SO e magari usando direttamente il driver della scheda. Ultima modifica di misterx : 20-01-2020 alle 11:59. |
|
25-01-2020, 19:13 | #16 | |
Senior Member
Iscritto dal: May 2001
Messaggi: 12580
|
Quote:
In primis, di che protocollo stiamo parlando? Come vorresti testare le porte? Sia su UNIX che su Windows puoi usare le RAW socket per bypassare un po' di stack di rete e forse ti conviene (nota che tipicamente per usarle hai bisogno dei privilegi di root). Proverei prima un prototipo con uno/due thread e proverei ad usare socket non bloccanti, ovvero intanto spari tutte le richieste senza aspettare, dopodiché vedi chi risponde. Ad esempio nel caso di TCP, usando le raw socket puoi mandare pacchetti SYN a raffica con un thread e usarne un altro per leggere chi risponde (oppure banalmente usare lo stesso dopo aver finito di sparare i SYN). Chiaramente qui non stiamo considerando eventuali monitor di sicurezza che beccano questi scanner. Ultima modifica di WarDuck : 25-01-2020 alle 19:16. |
|
27-01-2020, 09:35 | #17 | |
Senior Member
Iscritto dal: Apr 2001
Città: Milano
Messaggi: 3594
|
Quote:
il protocollo che sto usando è TCP. Uso socket bloccanti in quanto nel caso di socket non bloccanti poi dovrei gestire anche gli eventi. A quanto ne ho capito, usando socket bloccanti il processo, nel mio caso il thread, si ferma sino a quando non arriva un qualche dato ma poi devo continuare a leggere sino alla fine di quello che mi interessa, ad esempio, nel caso di una pagina http. sino a "\r\n\r\n\". Se istanzio fino a 30 thread e relative socket con ovviamente 30 IP diversi, mi arrivano dati, se vado oltre non mi arriva più nulla. Non mi è chiaro cosa o chi blocchi i dati in arrivo visto che sono client e gà mi è stato detto che non ci sono limitazioni in questo senso. Quando apro una connessione invio un semplice "GET / \r\n" ed attendo risposta, se non arriva si ha timeout. Anche l'invio dei dati non è banale, si deve capire se e quanti dati sono stati inviati ed in caso contrario inviare nuovamente. Insomma, un bel programmino banale solo in apparenza e che fa spremere le meningi Ultima modifica di misterx : 27-01-2020 alle 09:40. |
|
27-01-2020, 11:17 | #18 | |||
Senior Member
Iscritto dal: May 2001
Messaggi: 12580
|
Quote:
Effettivamente più che usare socket non bloccanti una alternativa potrebbe essere quella di usare select(), poll() o nel caso di Linux epoll() che ti consentono di monitorare contemporaneamente più socket, quindi ti viene restituito il descrittore di una delle socket pronte per leggere ad esempio. Tieni presente che è proprio quello che fanno i web server più avanzati come lighttpd o nginx per gestire le connessioni. Quote:
Quote:
Quello che in generale ti consiglio è dato un set di connessioni attive (connesse) è di mandare quante più "GET" senza aspettare la risposta, in maniera da aumentare il throughput. Ad esempio, dato un array di socket descriptor connessi: Codice:
int num_sockets; /* numero effettivo di socket connesse */ int opened_socket[NUM_SOCKETS]; for (int i = 0; i < num_sockets; ++i) write(opened_socket[i], "GET ...", sizeof..); Non ho ben chiaro lo scenario comunque, devi scoprire quali porte diverse dalla 80 hostano HTTP? Oppure basta semplicemente provarti a collegare alla 80 e vedere cosa ti rispondono? Tieni presente anche che ad oggi credo che la maggioranza dei server web usi HTTPS, che sarebbe un altro bel casino. Ultima modifica di WarDuck : 27-01-2020 alle 11:22. |
|||
27-01-2020, 11:41 | #19 |
Senior Member
Iscritto dal: Apr 2001
Città: Milano
Messaggi: 3594
|
sto programmando in Windows con Borland Builder.
Inviando quel GET desidero scoprire quanti server HTTP attivi ci sono in internet e di quale tipologia, una sorta di censimento/esperimento web. Ero partito col singolo thread usando un solo socket ma il tempo per risolvere il problema legato ai 2^32 indirizzi IP mi ha fermato, è eccessivo; da questo limite calcolato in 136 anni è nato questo 3d. |
27-01-2020, 12:25 | #20 | |
Senior Member
Iscritto dal: May 2001
Messaggi: 12580
|
Quote:
In ogni caso sarebbe interessante capire se e dove puoi arrivare prima di saturare la banda, quindi appoggio comunque la pazzia . In realtà di quei 2^32 indirizzi ne dovresti esplorare un po' di meno perché dal mio punto di vista andrebbero escluse tutte le classi private (ad esempio il range di indirizzi tipicamente assegnati alle reti LAN). Diciamo ti risparmi poco più di 16 milioni di indirizzi, certo non sono niente in confronto ai 4 miliardi, ma comunque sempre meglio di niente. Dopodiché partirei più in piccolo ad esempio restringendo gli IP a quelli Italiani o presunti tali. Inutile fare un censimento degli IP cinesi anche perché più ti allontani e più ti costa in termini di tempo. Io procederei poi per passi, ad esempio, se tanto pensi di connetterti alla porta 80, tanto vale fare prima un censimento di quanti ti rispondono su quella porta. Dal momento che tipicamente la connect() aspetta che il 3-way handshake di TCP sia completato, forse potrebbe valere la pena usare i socket raw per mandare prima un arbitrario numero di TCP SYN e vedere quanti rispondono con SYN ACK. Cioè dal mio punto di vista come ti dicevo prima, la strategia migliore è quella di generare ed avere un numero di pacchetti in volo molto alto. Per fare questo non devi necessariamente aspettare che ti rispondano subito, ma lanciarne quanti più ne puoi e aspettare in seguito. Il tempo di risposta del server non dipende da te, ma il tempo di generazione del pacchetto e l'invio si. In alternativa, più semplice che usare i socket raw, puoi fare quello che ti dicevo prima quindi avere in volo tante "GET". Non ho memoria dei socket Windows ma penso esistano funzioni che ti permettano di ascoltare gli eventi da più socket in contemporanea, stile select() o poll(). PS: mi sembra di ricordare che Windows abbia un limite per le connessioni half-opened (ovvero connessioni con SYN in attesa di SYN-ACK) quindi potrebbe essere per questo che hai problemi con più di 30 threads. |
|
Strumenti | |
|
|
Tutti gli orari sono GMT +1. Ora sono le: 03:49.