You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The format has served us well, but it could stand to be improved in ways that will help users better choose what checks to run. Some ideas:
Provide a simplified interface to vulns library, probably a "vuln" key that holds a vuln table as described there.
Support logical AND of matches, perhaps by making the matches.match element optionally be a table.
Recategorize. Existing categories are mostly descriptive of the finding, not of the action: printer, security, database, general. Would prefer categories like our NSE categories: discovery, vuln, exploit, dos.
Add a way to filter fingerprints based on service detected. This is imperfect, but could be used to support a "fast mode" that doesn't run unlikely checks
Support a more full description of the fingerprint that could be printed in a postrule or used with a substring search to select/filter fingerprints. Keeping primary output 1-line makes sense given the number of potential findings here, but some things would benefit from further description.
Related to 3. above, it'd be nice if http-enum could know what script categories were requested and run the appropriate categories based on that, but there's not currently an API for that.
The text was updated successfully, but these errors were encountered:
The format has served us well, but it could stand to be improved in ways that will help users better choose what checks to run. Some ideas:
matches.match
element optionally be a table.Related to 3. above, it'd be nice if http-enum could know what script categories were requested and run the appropriate categories based on that, but there's not currently an API for that.
The text was updated successfully, but these errors were encountered: