[C] scanner internet

[misterx]

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?

[Kaya]

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.

[!fazz]

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

[Kaya]

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/

[!fazz]

Originariamente inviato da Kaya

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/

non ho parlato di un limite nei thread ma di un limite nel numero di connessioni tcp concorrenti

[Kaya]

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 )

[misterx]

grazie ad entrambi per i vostri interventi.
Quindi istanziare più di 20 thread non avrebbe senso, viste le limitazioni imposte dall'SO.

[Kaya]

Originariamente inviato da misterx

Quindi istanziare più di 20 thread non avrebbe senso, viste le limitazioni imposte dall'SO.

Scusa ma non hai capito ciò che abbiamo scritto.
I thread sono una cosa, le connessioni TCP/UDP un altra.
Thread puoi averne diciamo "quanti ne vuoi", finchè non finisci la memoria

https://superuser.com/questions/1469...-in-windows-10
My system runs out of memory a little after testlimit64 -t passes 270,000 threads created.

Il limite di 20 è un limite di LICENZA che impone Microsoft e riguarda solo le connsessioni in ingresso. (sotto linux non c'è https://unix.stackexchange.com/quest...a-linux-system )

[misterx]

Originariamente inviato da Kaya

Scusa ma non hai capito ciò che abbiamo scritto.
I thread sono una cosa, le connessioni TCP/UDP un altra.
Thread puoi averne diciamo "quanti ne vuoi", finchè non finisci la memoria

Il limite di 20 è un limite di LICENZA che impone Microsoft e riguarda solo le connsessioni in ingresso. (sotto linux non c'è https://unix.stackexchange.com/quest...a-linux-system )

mi riferivo appunto alle licenze di microsoft.
Se al massimo posso avere 20 connessioni TCP contemporaneamente è inutile istanziare più di 20 thread, giusto?

[Kaya]

Scusa ma leggi quello che scrivo?
Si parla di CONNESSIONI IN INGRESSO, non in uscita.

[!fazz]

Originariamente inviato da misterx

mi riferivo appunto alle licenze di microsoft.
Se al massimo posso avere 20 connessioni TCP contemporaneamente è inutile istanziare più di 20 thread, giusto?

dipende come imposti l'architettura del software io di thread ne farei ad esempio 21 se lavorassi su windows 7
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

[misterx]

Originariamente inviato da Kaya

Scusa ma leggi quello che scrivo?
Si parla di CONNESSIONI IN INGRESSO, non in uscita.

ops, colpa mia: pensavo in generale.
Quindi il limite è per un applicativo server e non client.
Ok, meglio così, grazie.

[misterx]

Originariamente inviato da !fazz

dipende come imposti l'architettura del software io di thread ne farei ad esempio 21 se lavorassi su windows 7
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

ci sto già lavorando e per lo sviluppo sto usando Embarcadero di Borland. Ho già scritto tempo fa un applicativo server ma mai uno Client che istanziasse n thread quindi, devo capire bene come sincronizzare le risorse comuni.
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

[Mettiu_]

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)...

[misterx]

Originariamente inviato da Mettiu_

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)...

intendi con le winsock?

forse intendeva by-passando l'SO e magari usando direttamente il driver della scheda.

[WarDuck]

Originariamente inviato da misterx

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?

Beh messo così il problema è abbastanza vago.

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.

[misterx]

Originariamente inviato da WarDuck

Beh messo così il problema è abbastanza vago.

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.

ciao,
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

[WarDuck]

Originariamente inviato da misterx

ciao,
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 stai usando socket SOCK_STREAM normali con TCP, funzioni come read() e write() sono bloccanti. Ad esempio read() blocca se il buffer della socket è vuoto quindi non hai effettivamente dati da leggere, mentre write() non blocca mai a meno che il buffer di scrittura della socket non sia pieno.

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.

Originariamente inviato da misterx

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.

Non mi è chiaro se stai usando Windows o Linux, comunque io credo che ai thread bisognerebbe arrivarci il più tardi possibile, perché solo con quelli la vedo difficile scalare più di tanto. Io proverei ad usare 1 thread solo e funzioni come select(), poll() o epoll() per capire quante socket riesci a gestire con tempi ragionevoli.

Originariamente inviato da misterx

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

Quindi deduco tu stia in realtà cercando di scansionare se dall'altro lato ci sono server HTTP, quindi è un po' più complicato di un semplice port scanner.

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:

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..);

E poi aspettare le risposte in batch con una delle funzioni che ti ho indicato prima.

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.

[misterx]

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.

[WarDuck]

Originariamente inviato da misterx

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.

Mi sembra un po' ambizioso in effetti farlo con una singola macchina usando la semplice forza bruta.

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.