Nmap Development mailing list archives

Re: Ncrack discussion


From: jah <jah () zadkiel plus com>
Date: Thu, 14 May 2009 20:53:20 +0100

Hi ithilgore, my comments inline:

1) Target-Service Specification

Ex1: $ ncrack 10.0.0.*, 192.168.1.1, www.google.com -p22, 23

This will try to crack the default services on ports 22, 23 (ssh, telnet) for
hosts 10.0.0.0-255, 192.168.1.1 and www.google.com
  
I like that.  The user can specify a bunch of default services on a
group of targets.  And, like Nmap, -p should take service names as well
as port numbers.
What happens if the user knows that the above hosts' services listen on
non-default ports? He should be able to specify that like this:

Ex2: $ ncrack 10.0.0.*, 192.168.1.1, www.google.com -p399, 4531 -s ftp, svn
  
I agree with Kris, this seems tedious and is likely to cause errors in
service specification. Kris' idea of proto:port seems the most natural
way to do this.
Fyodor also suggested a url-like scheme like this:

Ex3: $ ncrack ssh://scanme.nmap.org:22, ftp://foo.bar.org:3000, bar.acme.org:21,
ftp://scanme.nmap.org
  
This could be OK (it's certainly intuitive), but what If I want to
specify several different services at more than one host as well as a
few services common to all hosts.  Maybe something like the following:

ncrack  scanme.nmap.org[21,22,ftp:9000] 
foo.bar.com[telnet:9000,ssh:9001]  -p 110

which would do:
pop, ftp and ssh on the default ports and ftp on 9000 at scanme
pop on the default port and telnet and ssh on ports 9000 and 9001
respectively at foo.bar.com

Having said that, Fyodor's url scheme would be a nicer way to specify
http basic auth at the /members section of example.com:
ncrack http://example.com/members
2) Ncrack Input from Nmap Output

Ncrack is probably going to be used after a Nmap scanning has taken place. This
means that being able to parse Nmap's output and trying to crack all the
services that Ncrack can handle is a good idea. iirc they are already some
parsers out there that do the job? Could someone point me to them? Additionally,
should we be able to support every output format parsing (surely the grepable
one should be the easiest).
I think it should handle normal, xml and grepable output, but definitely
xml so it works with zenmap output.

Regards,

jah

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


Current thread: