Re: ncat usage

[Dave Henderson <dhenderson () digital-pipe com>]

On 05/15/2012 11:07 AM, Dave Henderson wrote:
> On 05/14/2012 08:56 AM, Dave Henderson wrote:
> > On 05/11/2012 11:36 AM, Dave Henderson wrote:
> > > On 05/11/2012 11:10 AM, David Fifield wrote:
> > > > On Fri, May 11, 2012 at 07:03:31AM -0400, James Rogers wrote:
> > > > > OK, you can only use ncat to serve a single page at a time to one web
> > > > > browser, using ncat on the command line like you are. Which means you
> > > > > cannot embed any images from that same server in the page you are
> > > > > serving.  Because every image is a separate connection.
> > > > >
> > > > > The reason for this is that every connection in to ncat would need
> > > > > it's own separate handles for each send and receive, but you just have
> > > > > two handles, so everything you send goes into the stream for the first
> > > > > client that connects and nothing is ever sent to the second
> > > > > simultaneous connection.
> > > > >
> > > > > This is why the image shows up in the middle of your first web page as
> > > > > text.  If 5 clients connected simultaneously the first connection
> > > > > would get 5 pages randomly mixed together.
> > > > >
> > > > > There might be a way using nse scripting to make ncat work like a full
> > > > > featured web server, but at that point I would recommend just using a
> > > > > small web server like boa or lighthttp.
> > > > Also I should mention that anything you do in this case that does not
> > > > involve --exec or --sh-exec is the wrong answer. What you are trying to
> > > > do--handle multiple clients independently--is exactly what those options
> > > > are for. Putting a while loop around a single invocation of Ncat reading
> > > > from stdin is wrong for a number of reasons, including the one James
> > > > just mentioned.
> > > >
> > > > If you need to support getting different URLs, then it's up to you to
> > > > write a small program capable of parsing the URL from the HTTP stream
> > > > and responding appropriately. Just sending back a block of HTTP
> > > > responses without even looking at requests is not robust or correct.
> > > > Instead of reinventing a minimal web server, why don't you use something
> > > > likehttp://www.acme.com/software/mini_httpd/?
> > > >
> > > > David Fifield
> > >
> > > Thanks for the help David!  I looked over the man pages for those 
> > > two parameters and have a few questions.
> > >
> > > 1. Should one of those parameters be used instead of, or in 
> > > conjunction with, the named pipes?
> > >
> > > 2. Would it be possible to provide example syntax to use based on 
> > > the code already provided?
> > >
> > > 3. I can see that --sh-exec uses /bin/sh to run the command, what 
> > > does --exec use (I assume whatever the shebang is)?
> > >
> > > I have to mention, as I did in one of the prior replies, that this 
> > > project is _not_ for handling multiple clients.  It's a single 
> > > instance of a server, serving one person.  There are other aspects 
> > > (and flexibility) of the project that would make it better to use 
> > > the script I'm working on instead of other servers such as boa, 
> > > lighttpd, mini_httpd, or other web servers.
> > >
> > > I have tried using ncat in the 'while' loop (restarting each 
> > > iteration) as well as a 'keep-open' connect outside of the 'while' 
> > > loop.  In both instances, the connection does not close (which I'm 
> > > assuming is because I wasn't using an --exec or --sh-exec 
> > > parameter).  It's not the number of named pipes (given the 
> > > scenario), it's that they don't get closed once the entire data has 
> > > been sent.  This explains why the headers and raw contents of the 
> > > graphics file get added as part of the HTML.  If the original 
> > > connection closed after sending the .html file contents, ncat (and 
> > > it's associated named pipes) would be free to serve the request from 
> > > the browser for the graphic file contents and any other "embedded" 
> > > documents that would need to be sent in order to render the page 
> > > correctly.
> > >
> > > Also, part of the script (the procRequest function call), not 
> > > provided in any messages so far, actually parses and handles the URI 
> > > request, so that part is handled and will be expanded as needed.  
> > > Thanks for the tip though. :)
> > >
> > > Dave
> >
> > bump for help
>
> bump for help

Any thoughts on this Fyodor?  It appears as though I've stumped the 
other members of this mailing list too, unfortunately. :(  Any help 
would greatly be appreciated!

Thanks,
Dave

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