Re: Nsock port scanning

[Jacek Wielemborek <d33tah () gmail com>]

List,

Yesterday David contacted me about my GSoC project, asking to 
describe my plans. I figured that I could as well post my thoughts 
on the dev maling list and gather some feedback from other 
developers as well. Just a quick reminder - my project is about 
porting Nmap's port scanning engine to Nsock. You can find details 
here: 
https://secwiki.org/w/User:D33tah/GSoC_2014_Nsock_proposal#V._Project_Proposal

I can think of three approaches right now. The first one is 
"bottom up", as David taught me last year. Basically, I'd build a 
prototype and keep expanding it until any of the design choices 
turns out to be messy, at which point I'd try to re-design it, 
building another prototype. Actually, the first prototype is 
already there, I introduced it in this post: 
http://seclists.org/nmap-dev/2014/q1/16 . The first thing I'd like 
to work on is timing - my current implementation is quite naive 
and would only work for a very small number of probes. Since this 
might already be a too big task to design it in advance, I think 
I'll start with sending probes in batches so that nmap -p- 
localhost/8 would not crash due to file descriptor limits.

The second approach is to "top-down". I'd analyze Nmap's port 
scanning algorithm and design an asynchronous version of it that 
would be possible to implement with Nsock. Another way to realize 
this approach would be by trying to convert scan_engine.cc to 
Nsock in small chunks, so that for example:

foo();
sleep(3);
bar();

Would become:

foo();
nsock_event_id bar_event = nsock_timer_create(nsp, bar_func_ptr, 
3000, NULL);

I'm not sure if it's a good idea, but inituition tlls me that it 
might be possible. Either way, the second approach involves a lot 
more planning with no guarantee that I'd avoid rewriting the code 
as I'll most likely be doing in the first approach. I still 
believe that it's worth considering though.

The third option is actually an Henri's idea. Instead of 
implementing the Nsock port scanning in C/C++, expose a Lua 
interface and build port scanning algorithm there. This would be 
much easier to develop and would definitely be hackable more 
easily, but I am worried about the performance. Since standard 
Lua has no JIT, I believe that the VM would impose quite a lot of 
overhead which would slow down massive port scans. I'd like to 
stress though that I hadn't tested the performance of this 
approach yet and it might turn out to be good enough. Other than 
that, I absolutely love this idea, especially that the diff for 
Henri's prototype changes only 400 lines of code.

So, what are your thoughts on that?

Yours,
Jacek Wielemborek

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/