Sergey. [Status Report 02/17]

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Sergey. [Status Report 02/17]

Sergey Khegay
[Report 02/17]
Hello Nmap Community,

Accomplishments:
- Read and (hopefully) understood how Lua C API works. 
  Studied related code in the NSE implementation.
- Conducted minor performance testing and enhanced the testing script.
- Came up with two probable approaches of how to change the brute.lua for the
  best. From my correspondence with Fotis:
  > I did learn more about internals of the brute library. So far I have two ideas 
  > in my mind. As I said before, right now two restrictions are:
  > - there is no any kind of feedback for RST messages, protocol specific messages
  > - the number of threads running is always constant, 10. Can be altered by the 
  >  script argument, but any way constant during the runtime.
  >
  > So my ideas:
  > - Transform brute so that it worked internally like Ncrack.
  >  For this approach I think I will have to implement Lua binding to 
  >  Nsock. For example for nsock_write, nsock_read methods.
  >  
  >  The bad thing about this approach is that I will have to rewrite all
  >  *-brute scripts.
  >
  > - Use error codes as mediators. The script will send specific error messages to the 
  >  library upon which the latter will make controlling decisions (increase/decrease
  >  the number of threads running, delays, etc.)

Goals:
o: This time conduct comprehensive performance testing.
o: Code the implementation of the second idea (error codes) at least for ftp-brute
   and see how it goes.
o: Submit further reports on time, since now the official schedule is set up.

Best regards,
Sergey.

_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/
Reply | Threaded
Open this post in threaded view
|

Re: Sergey. [Status Report 02/17]

Henri Doreau
2016-05-10 21:35 GMT+02:00 Sergey Khegay <[hidden email]>:

> [Report 02/17]
> Hello Nmap Community,
>
> Accomplishments:
> - Read and (hopefully) understood how Lua C API works.
>   Studied related code in the NSE implementation.
> - Conducted minor performance testing and enhanced the testing script.
> - Came up with two probable approaches of how to change the brute.lua for
> the
>   best. From my correspondence with Fotis:
>   > I did learn more about internals of the brute library. So far I have two
> ideas
>   > in my mind. As I said before, right now two restrictions are:
>   > - there is no any kind of feedback for RST messages, protocol specific
> messages
>   > - the number of threads running is always constant, 10. Can be altered
> by the
>   >  script argument, but any way constant during the runtime.
>   >
>   > So my ideas:
>   > - Transform brute so that it worked internally like Ncrack.
>   >  For this approach I think I will have to implement Lua binding to
>   >  Nsock. For example for nsock_write, nsock_read methods.
>   >
>   >  The bad thing about this approach is that I will have to rewrite all
>   >  *-brute scripts.
>   >
>   > - Use error codes as mediators. The script will send specific error
> messages to the
>   >  library upon which the latter will make controlling decisions
> (increase/decrease
>   >  the number of threads running, delays, etc.)
>
> Goals:
> o: This time conduct comprehensive performance testing.
> o: Code the implementation of the second idea (error codes) at least for
> ftp-brute
>    and see how it goes.
> o: Submit further reports on time, since now the official schedule is set
> up.
>
> Best regards,
> Sergey.

Hello Sergey,

I have a few questions about your project; although I understand that
you're still in the early phase.

- Can you clarify what you mean by: "transform brute so that it works
internally like Ncrack"? What do you want to change and why? (I am not
familiar at all with ncrack's internals)
- What kind of bindings over nsock IO methods are needed that differ
from the existing ones?

Regards

--
Henri
_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/
Reply | Threaded
Open this post in threaded view
|

Fwd: Sergey. [Status Report 02/17]

Sergey Khegay
Hello Henri,

Absolutely! Thank you for asking.

- Can you clarify what you mean by: "transform brute so that it works
internally like Ncrack"?
 
Please allow me to answer on this part with an excerpt from my discussion with Fotis.

...
Let me summarize here a bit to check if I understand everything correctly.

- The main logic of the Ncrack is implemented in ncrack.cc. That is adaptivity
  to network conditions by tracking RSTs, timeouts, protocol specifics. Things
  that give Ncrack advantage over similar tools.

- For every service there is a corresponding module (http, rdp, ssh, etc.).

- Ncrack's Core Engine (CE) is a layer between a module and the Nsock library.

- For every module the communication with the Nsock library is happening through
  the core engine. 
  
  To clarify: whenever a module needs to read/write from/to a socket it calls
  a corresponding Nsock's method, BUT instead of handling the result (successful, 
  failed, timeouted) of the operation itself it delegates this work to the Core 
  Engine (CE). This, in turn, allows the CE track the the information about the 
  connection state and pass the data back to the module. Upon collected
  information CE may decide to increase/decrease rate of attempts, delay time 
  between attempts, number of connections.

  This part (especially the chart in your slides about Ncrack) looks very
  similar to TCP congestion control mechanism (Rhino, I guess).
 ...

What do you want to change and why? (I am not
familiar at all with ncrack's internals)
 
The reason is because I like Nsock's idea, which is event-driven approach. 

What kind of bindings over nsock IO methods are needed that differ
from the existing ones?  
 
So as described above Ncrack modules, say ftp, use Nsock's functions, like 
nsock_write, as a callback Core Engine's nsock_write_handler(.) is passed.

I would like to have the same functionality in Lua bindings, because for now
we have functions like l_send (nse_nsock.cc), which uses internal, hidden
from the user callback function.

Recently Fotis sent me a email, saying that probably event driven approach
would not benefit much to NSE. So I will focus on the second idea, with the error
messages.

Best regards,
Sergey.


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