Ability to disable dirbusting via --dirbuster.tool=none argument

[ShyftXero]

I was always hitting tarpits dirbusting http-based services that didn't need to be dirbusted.

Something like tcp/5357 is less useful to dirbust than 5000 or the like. (might consider avoiding known HTTP services that don't do much or killing dirbuster if no new dirs found in a given amount of time? idk... for another time)

--dirbuster.tool=none or --dirbuster.tool none

poetry run autorecon shyft.us --dirbuster.tool none -vvv

---

Also a slight deviation from the way the choices are passed into argparse.
It was helpful to have the tools tied to an attribute of the plugin and then referenced in the configure method.

[Tib3rius]

You can disable the plugin using the tagging system by doing --exclude-tags=dirbuster

Is there a reason why adding a "none" tool option would be better? Your point about only running dirbuster against specific ports, or excluding ports is an interesting feature idea though.

[ShyftXero]

Well, had I taken the time to read or understand the docs thoroughly I might have gotten that...

I was thinking about the plugin devs having the list upfront and making that a valid option.

It might be useful to allow a different dirbuster binary to be specified.

--dirbuster.tool='somesuper1337dirbtool -u %url% -o %output_file%'
That way you wouldn't have to write a plugin to support a new tool dirb tool.
Bit of a new set of params that are passed via those %something% vars.
I feel like that's feature creep, but as I'm thinking about that it feels useful.

[ShyftXero]

I think it might require something of a community survey to collect "Top 10 useless http ports to dirbust on a pentest" so there'd be some community guidance about "useless/not useless".

Or not... It's your project. Pick whatever ports you want. Lol

[Tib3rius]

I think adding a disabled-by-default --dirbuster.onlyports would be worth implementing. Then users could choose their own ports to include, e.g. --dirbuster.onlyports=80,443,8080,8443 etc.

As for writing a plugin to support a new tool, I have no issue with doing that, it's kinda the point of the plugin system, which replaced the config file based system in v1. Going back to passing full commands either via a config file or on the command line would be something I'd be against, since ideally you could easily just create a plugin.

Heck, you could create a plugin which matched all services and then ran commands based off a config file it loaded in if you wanted to.