Allow combining individual scans using flags

[caribpa]

As mentioned in #44, usually, the purpose of flags is to enable optional functionality.

Also, in #44, it was learned that preserving compatibility with the current way of calling the script (--host and --type flags need to be preserved) is mandatory.

Still, this doesn't prevent future development from making these flags optional (offering the same functionality as of now when used), while moving towards a more standardized way of calling the script.

Because of this, I propose to make the --host and --type flags optional (as long as what was proposed in #44 is considered and implemented), and allow specifying the current --type functionality in separate, and accumulative, flags, for example:

$ ./nmapAutomator.sh -b -u 10.1.1.1              # Performs Basic and UDP scan

$ ./nmapAutomator.sh --recon --vulns 10.1.1.1    # Performs Recon (+ Basic) and Vulns scan

$ ./nmapAutomator.sh 10.1.1.1                    # Performs by default the Basic scan

$ ./nmapAutomator.sh --type All --host 10.1.1.1  # This is still possible and works as expected

[21y4d]

This was requested before, but the reason I never did this is because other scans are automatically run together when needed.

However, the script is evolving, do I guess we may need to do something like you suggested.

[caribpa]

I guess you may be referring to #15. AFAIK, you cannot currently run something like Recon and Vulns (+ Quick and Basic, run as dependencies), or Full + UDP (or individual combinations of them) without performing an All scan.

Of course, I'm more than happy to help in the implementation for this matter 🙂

[caribpa]

As you said, the script is evolving (and I'm pretty sure you have many awesome things in mind), so these changes are also suggested from the implementation POV, for easing the addition of features, parsing of flags, etc 🚀

[21y4d]

Yeah you're right. We need to make it dynamic to allow for more flags, and to enable scanning multiple hosts.

Pull requests are always welcome of course ;)

I'll work on merging the current ones in the weekend, and will start working on host/port discovery without nmap for remote scanning.

[21y4d]

I've added this as an upcoming feature, so that we can start working on it. I'm closing the issue to keep the repo clean.

[caribpa]

We need to make it dynamic to allow for more flags, and to enable scanning multiple hosts.

Pull requests are always welcome of course ;)

I'll work on implementing this incredibly genius way of flag parsing (with some improvements), as it is future-proof and hassle-free. In a nutshell:

1. A header, with the content of the expected help command, is added to the file
2. The functions, which are called by specific flags, are named after the long version of these flags
3. When the script is called, it reads itself, parsing the content of such header to detect if the given flags are valid
4. When all the flags are valid, the only thing left to do is to eval the name of the flags, calling the associated functions

From the development POV, adding a new flag will only resort to:

1. Adding a new line in the header with the flag variants and explaining its purpose (help style)
2. Creating a function named after the long version of the flag with the functionality

Easy, right? 🙂

[21y4d]

Wow.. looks really promising, and will make it much easier to add more flags in the future. Since we already have functions for each type of scan, perhaps like you suggested we should use each scan type as a flag, instead of putting the type in the --type flag.

We should probably also refactor the case statement in the main function, as this may take its place.

[caribpa]

Since we already have functions for each type of scan, perhaps like you suggested we should use each scan type as a flag, instead of putting the type in the --type flag.

We should probably also refactor the case statement in the main function, as this may take its place.

Refactoring the case in favor of the automagically-flag parsing is the main idea. Of course, this would still support the --type and --host flags (by creating functions named after the flag as well) if you want to preserve compatibility, the only thing is that these functions shall undefine themselves when called as they shadow the type (used as which POSIX replacement in the Recon scan), and host (not used for now) commands. For example:

type() {
  # unsets itself
  unset -f type

  # Performs what the current `main` function does
  ...
}

[21y4d]

I see.. that could work.. host is actually being used as well for DNS recon.

[caribpa]

Regarding the footer function, we just add it in a trap (trap footer EXIT) after making sure the parsed flags are correct, and it will always be executed when the script exits.

[21y4d]

yeah that's a great idea.. i guess this would show even if a user cancel's with ^c, which is great as well, so that the tee output would always have the footer.

[caribpa]

That would only work if main is run inside a subshell (main is defined with parentheses instead of curly braces) with the trap defined inside, and tee is immunized against SIGINT (and forced to be run inside another subshell to avoid making the trap global):

main() (
  trap footer EXIT
  ...
)
...
main | (trap '' INT; tee "nmapAutomator_${HOST}_${TYPE}.txt")

The way I would do it is by piping to tee in the exit trap, so that the two extra subshell processes are avoided:

trap 'footer | tee "nmapAutomator_${HOST}_${TYPE}.txt"' EXIT

# And this one to record that the operation was interrupted
trap 'echo "[Operation interrupted by the user]" | tee "nmapAutomator_${HOST}_${TYPE}.txt"' INT

[21y4d]

I guess the second option would work. There's no need to tee that the script was interrupted. The only thing we need to add to the output on user interruption is the footer. So i guess this line should do the trick:

trap 'footer | tee "nmapAutomator_${HOST}_${TYPE}.txt"' EXIT