Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve http-fingerprints.lua format and organization #267

Open
dmiller-nmap opened this issue Jan 6, 2016 · 0 comments
Open

Improve http-fingerprints.lua format and organization #267

dmiller-nmap opened this issue Jan 6, 2016 · 0 comments

Comments

@dmiller-nmap
Copy link

@dmiller-nmap dmiller-nmap commented Jan 6, 2016

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:

  1. Provide a simplified interface to vulns library, probably a "vuln" key that holds a vuln table as described there.
  2. Support logical AND of matches, perhaps by making the matches.match element optionally be a table.
  3. 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.
  4. 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
  5. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant