Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Re: [nmap-svn] r32114 - nmap-exp/d33tah/ncat-lua-callbacks/ncat/test
From: Jacek Wielemborek <wielemborekj1 () gmail com>
Date: Fri, 30 Aug 2013 19:04:15 +0200

I believe that depends on the use case. Since you can handle both
encoding and decoding side of such proxy, it'd be easy to for example
encrypt whole proxy session or obfuscate it in any way for example to
do some IDS evasion. Perhaps it'd be better to leave the behavior
there, just optional?

2013/8/30 David Fifield <david () bamsoftware com>:
On Fri, Aug 30, 2013 at 12:48:29PM +0200, Jacek Wielemborek wrote:
The new addition to the tests uncovered a weird, probably unwanted
behavior introduced in r32028. The problem is that when you do -L
scripts/filters/rot13.lua on both proxy server and proxy client, the
target through which we're proxying to also needs to be run with -L
rot13.lua. Should I revert r32028 to make the ultimate destination
host receive the decoded data?

Does --load-lua-socket-file affect proxy negotiation? My impression is
that it shouldn't, neither in connect nor listen mode. The proxy stuff
should always be unmodified by Lua. Only the traffic that goes through
the proxy (after negotiation) should be changed. In other words, you
should have to specify base64 on the client and the server, but not on
the proxy in between. The -L modification should be strictly between the
client and the server.

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


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault