Re: Nsock port scanning

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

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

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