It's a complelling case, but that doesn't answer the question about including UDP port scan results within a single Nessus scan though - the one point og contact so to speak where complete scans can be run?
A. ---- On Tue, 19 Sep 2006, Renaud Deraison wrote: > > On Sep 19, 2006, at 7:25 PM, A User wrote: > > > > > > Is there a way to enable "find_service" to use UDP results? > > UDP services do not send out a banner, and most of them do not send > anything back when they receive what they consider to be a "malformed > packet" (I'm leaving aside services such as SNMP which won't reply to > properly formed packets which do not contain the proper "secret" [the > community string in the case of snmp]). So doing service recognition > actually requires sending nearly as many probes as there are services > which the find_udp_service plugin would recognize, and coming up with > good probes would be a non-trivial task when dealing with obscure > services. > > To make things worse, a lot of UDP services are single-threaded/ > processed and tend to be extremely fragile -- so sending a fairly > large number of probes will either crash the service, stall it into > an infinite loop, or just prevent it from replying to other > legitimate requests. > > So we do not do full service recognition for UDP ports -- this is not > really doable, this is extremely slow and this will disrupt many, > many things, for very little actual benefits (the biggest class of > UDP services which could 'easily' be reconignized are MS/SUN RPC > services -- and you can get their list provided that you can talk to > the portmapper) -- we have probes for tons of them which run on fixed > ports, though. > > > -- Renaud > _______________________________________________ > Nessus mailing list > [email protected] > http://mail.nessus.org/mailman/listinfo/nessus > _______________________________________________ Nessus mailing list [email protected] http://mail.nessus.org/mailman/listinfo/nessus
