Re: Nsock port scanning

[Jacek Wielemborek <d33tah () gmail com>]

31/03/2014 16:29:58 Henri Doreau <henri.doreau () gmail com>:
> 2014-03-10 20:54 GMT+01:00 Jacek Wielemborek <d33tah () gmail com>:
> > 06/01/2014 22:23:12 Jacek Wielemborek <d33tah () gmail com>:
> > > List,
> > >
> > > On CCC we talked a bit about the scanning pipeline and if I understood it
> > > correctly, one of the steps we have to take first is to implement port
> > > scanning using Nsock. Yesterday I finally got around to that and created
> > > nmap-nsock-scan branch, where I wanted to experiment with adding TCP
> > > connect scanning using Nsock. I'm happy to announce that I've got a proof
> > > of concept ready and I wanted to ask you guys what should I do next.
> > >
> > > Currently, it's implement as a separate Nmap switch, -sD. This creates an
> > > nsock pool and schedules TCP connections for all specified ports for all
> > > the targets, then enters the nsock main loop, which ends when all
> > > connections had been established. It definitely doesn't feel like the
> > > most elegant solution - for example nmap -sD -p- localhost/24 will
> > > result in:
> > >
> > > libnsock nsock_make_socket(): Socket trouble: Too many open files
> > >
> > > I'm looking for a way to implement it in a more sane manner - one of my
> > > ideas is to schedule the connect() for the first port only and then in
> > > the
> > > connect handler schedule next connections. Another idea is to schedule,
> > > say, 100 connections and if the 100th gets its handler fired, schedule
> > > another bundle. BTW, I completely didn't worry about timing for now.
> > > Could
> > > you guys give any hints on how would you expect that to work?
> > >
> > > Jacek Wielemborek
> >
> > Hi again,
> >
> > I just submitted my GSoC about nsock port scanning. It can be found here:
> >
> > http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/d33tah/
> > 5885170347409408
> >
> > I'd be happy to hear some feedback about this project :)
> >
> > Jacek Wielemborek
>
> Hi Jacek,
>
> I should be ashamed for not having given you any feedback on this
> work. 

Hi Henri,

Not a problem, I can see you had been very busy recently. Are you planning to 
be a mentor for this GSoC?

> I definitely support the idea of having nsock-based port
> scanning but the first question I'd ask is whether we want it
> implemented "raw" (i.e. a reimplementation of ultrascan that would use
> nsock) or through NSE (that uses nsock already). Both have advantages
> and drawbacks. I personally appreciate NSE's versatility and its
> stable layers and libraries...

Do you mean that I should consider a continuation of your nmap-nseportscan 
branch as an alternative? I think that this could be a cool thing that could 
could make it easier to create prototype new scanning methods (including e.g. 
just querying exfiltrated.com, which I once tried to write a script for) or 
completely new ideas such as distributed port scanning. I'm worried about 
performance though. The ultra_scan porting to nsock could get us closer to 
implementing the scanning pipeline, which is what my proposal was basically 
about.

> Concerning your question about scheduling connections: as you suggest,
> a sliding window (or windowS, actually) algorithm is the way to go.
> Implementation should offer proper hooks for congestion control and
> speed limits.
>
> Regards

Thanks. I'll read up on implementing sliding window algorithm so I'd be more 
prepared for the upcoming GSoC. I'm not yet sure how such hooks should look 
like though.

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/