Re: Nsock port scanning

[Henri Doreau <henri.doreau () gmail com>]

2014-04-04 21:28 GMT+02:00 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?
At least I'm in the pool! :)

> > 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.
Yes, or a new version from scratch. I'm not really worried about
performance, only a thin layer of high level logic would be lua and
most operations could be handled by the underlying libraries. Context
switches would be limited. NSE is already quite efficient. A scanning
pipeline can also be implemented by moving _everything_ to NSE. It's a
big and long-term design decision to take, indeed, but the ability to
port-scan from within NSE leaves every door open and let us evaluate
whether it would be relevant. As such, I think it would be a good
first step.

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

I don't know yet either, this is something to be thought of and
designed carefully.

Regards


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