Re: ncat: using UDP with --chat

[David Fifield <david () bamsoftware com>]

On Wed, Nov 18, 2009 at 10:29:54PM +0100, clemens fischer wrote:
> (Sorry for being late again, I am busy with something else.)
>
> > On Mon, Nov 09, 2009 at 12:28:21AM +0100, clemens fischer wrote:
> >
> > >                       sender/
> > >   client message      response        Ncat behaviour
> > >   ------------------------------------------------------------
> > >   c-1    temp1: 33C   <N><S1><ok>     register c-1 as sender
> > >   c-2    :            <N><S2><ok>     register c-2 as observer
> > >   c-3    sick: yes    <N><S3><ok>     register c-3 as sender
> > >   c-4    temp1:       <C1><S1>33C     register c-4 as
> > >                                       interested in temp1
> > >   c-5    :            <C2><S2>temp1,  don't register c-5,
> > >                       sick            just make it aware
> > >   c-2    ::           <N><S4><ok>     unregister c-2
> > >   c-6    :            <N><S5><ok>     register c-6 as observer
> > >   c-7    :            <timeout>       nothing, expects c-6 to answer
> > >   c-6    ::           <N><S5><ok>     unregister c-6
> > >
> > >   legend:
> > >
> > >   <N>       sending party is Ncat
> > >   <Cn>      sending party is client-n
> > >   <timeout> nothing is sent, no state change, an error
> > >   <Sn>      sequence number, relates messages and clients
> > >   <ok>      no response text, but no error either
> >
> > Thank you. This helps me understand better what you want to
> > accomplish.  I think this kind of thing, which amounts to a new
> > network protocol, is more than Ncat brokering should do. I think it
> > should, as much as possible, be a transparent pipe that doesn't have
> > to process data above the TCP or UDP layer.
> >
> > Have you thought about using TCP brokering mode for this? What you've
> > described above could be implemented with all the intelligence in the
> > clients. The : and :: messages would just be the beginning and end of
> > TCP connections. The hard part of all this is managing connections,
> > and TCP does that.
>
> Sounds reasonable.  But.  Can brokering be made to work over unix local
> sockets in reliable datagram mode, like TCP?  What I mean is mentioned
> in unix(7):  "unix_socket = socket(AF_UNIX, type, 0);" where type would
> preferably be SOCK_STREAM or even SOCK_SEQPACKET (portability?) and
> allow nice tricks with passing SO_PASSCRED!  I had experimented with
> "socat" much earlier than 1.7.x and never got anything useful to work.

Ncat can't do that, I'm sure. It is an interesting idea.

> In short:  the TCP brokering is fine, but I'd like it to be local to the
> machine, without the overhead and the security-problem (firewalling just
> for this application).

If you give the Ncat server a source address, it will listen only on
that interface. It will be local to the machine if you do this:

ncat --broker 127.0.0.1

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