Service identification
Michel Arboi <[email protected]>
| Newsgroups | gmane.comp.security.nessus.devel |
|---|---|
| Message-ID | <[email protected]> |
I planned to change the current way find_service & Co works. My reason for this are: - Many services are identified by find_service.nes, which is a C plugin and is not updated by nessus-update-plugins; so many users have to wait for the next release. - too slow - too intrusive - unreliable on services like FTP, NNTP or even SMTP which all use a 3 digit code to answer to queries. [any other problem?] The modifications I planned: - first open a plain TCP connection (no SSL/TLS) and try to read a banner without sending anything. If we get a banner, store it and test next port. Wrapper services are identified at this point. - Try SSL/TLS connections (if asked), then plain connection. Register the "transport" (as we do currently) Try to read a banner. If this works, register it, otherwise, register the service as "Mute". [so far, this is slower than the current behaviour. Maybe we should still send the GET request?] One or two other NASL plugins will be in charge of sending "HELP / HTTP/1.0" or "HELP" on "mute" services. One NASL plugin will parse the banners and decide if the service can be identified or if more information is needed. e.g. anything that answers with something like 3 digits followed by a space or a minus sign might be a FTP service, NNTP, SMTP etc. Requests like EHLO or HELP should avoid false identifications. This way, new services are added only in NASL plugins. Any comments? -- [email protected] http://arboi.da.ru FAQNOPI de fr.comp.securite http://faqnopi.da.ru/ _______________________________________________ Nessus-devel mailing list [email protected] http://mail.nessus.org/mailman/listinfo/nessus-devel