Add support for scanning multiple IPs

[claudijd]

Compliments of @leighalytle.

It should support scanning more than one host at a time.

1.) -t switch should support NMAP syntax targeting
2.) should add a -f switch to accept targeting info via file (should support NMAP style syntax)

[claudijd]

Requirements:

1.) Need a native mechanism to detect open ports
2.) Need better exception/error handling/output
3.) Need parsing logic and classes for NMAP-style targeting info

[claudijd]

+1 (ran into a need for this again today)

[claudijd]

4.) Have a way to detect SSH protocol (go a step beyond just knowing a service has port 22 open before we attempt to scan) <= an SSH protocol fingerprinter

[jinankjain]

@claudijd When doing a request over multiple IPs do you want result for each ip in different array or final result to get combined in one result array

[claudijd]

@jinankjain I would like the resultant output of a multi-ip scan to be a single JSON document and an array of what we normally get from a scan seems like the right fit.

[jinankjain]

@claudijd so results for all the IP would be combined that single json array?

[claudijd]

@jinankjain is making some progress on IP comma separated targeting in #65.

Other syntax we should consider supporting could include....

192.168.1.0/24 (== 192.168.1.1 thru 192.168.1.255)
192.168.1.1-255 (== 192.168.1.1 thru 192.168.1.255)
192.168.1.1,2 (== 192.168.1.1 && 192.168.1.2)

To gain the above, we'll probably need to implement some sort of IP parsing logic (at least for the CIDR notation). Consider Ruby IPAddr and CIDR gems to help with that. Might consider some customer parsing logic for the others.

[claudijd]

Perhaps we should also have a command-line switch to load targets from a file. Looks like -f it still open. Might also consider having a -o flag for writing our JSON documents to disk.

[claudijd]

@jinankjain yes, a single JSON array.

[jinankjain]

@claudijd I have implemented -f for loading targets via file but waiting for #65 to land so that could use that piece of code 😄

[claudijd]

Re-opening this issue, because it includes more than what was added in #65 I also realized we might consider updating the -h output to include an example of multi-ip usage.

[claudijd]

@jinankjain sounds great about the -f stuff, looking forward to seeing/reviewing it.

[claudijd]

#65 and #69 are getting us closer and closer to the eventual end state desire for this issue. What remains are the following...

• Support for NMAP style targeting
• Some better error handling and usage when specifying -f file that doesn't exist or has bad targeting info
• Expand on -f to include multi-line file input support

[jinankjain]

@claudijd In the above list we need one more thing:

• Update README example

[claudijd]

@jinankjain exactly, thanks for adding that

[claudijd]

Partial NMAP-style targeted added in #76

[claudijd]

Remaining todo's include:

• Finish for NMAP style targeting via custom targeting parser
• Some better error handling and usage when specifying -f file that doesn't exist or has bad targeting info
• Expand on -f to include multi-line file input support
• Need a fast way to detect open-ports/protocol fingerprint and timeout when we don't see what we expect
• Update README example to make sure it's fully up to date with above changes

[claudijd]

Also, added threading concept, but I think it's out of scope for this issue.

[jinankjain]

Remaining TODO's include:

• Finish for NMAP style targeting via custom targeting parser
• Need a fast way to detect open-ports/protocol fingerprint and timeout when we don't see what we expect

[jinankjain]

@claudijd I don't think so we would be able to support 192.168.1.1,2 (== 192.168.1.1 && 192.168.1.2) this syntax as we are using comma as separator for different IP address or HostName or Ranges. If we want this then we can do this under some another flag but not -t

[claudijd]

I'm fine with dropping 192.168.1.1,2 syntax as a requirement for the custom parser if it makes it easier, it's certainly one of the less common use cases with IP, CIDR, and "-" notation being preferred.

[jinankjain]

@claudijd We can close this now

[claudijd]

@jinankjain I think we're still missing a fast way to detect open services, there is a pending PR for this in #92 but it's not mergable because a lot of the dependent code changed recently.

[jinankjain]

@claudijd Let's see I will try to rebase that PR hope that works

[claudijd]

@jinankjain it likely needs a re-write because a lot of that code changed in the past couple days

[jinankjain]

@claudijd I looked at the code and felt the same as we have completely refactored scan_engine so it needs a rewrite

[jinankjain]

@claudijd This can also be closed now with #92

[claudijd]

@jinankjain thanks for all your help with this, I really appreciate you championing this much needed feature set and hunting it down!