Hi John, I'm curious what problem you are trying to solve by performing a scan with Nessus. Is it general scanning, new host discovery, vulnerability enumeration, patch auditing, .etc, .etc?
If you are performing a full scan, you may want to cut back to just a credentialed patch audit to avoid the bug you describe with the Altiris agent. If only part of your network has Altiris agents you could try to scan the non-agent systems with a full scan and cut back to a less scan that targeted less ports with Nessus for those with agents. Something like the dynamic asset list functionality can do this for you automatically with the Security Center. I really don't want to get into a discussion about how to fix the Altiris agent here, but perhaps there is a configuration option to ignore connections from IP addresses other then their management console, or a way to 'trust' the Nessus scanner IP. I'm also a bit suspect about the impact of scanning. It sounds like scanning can cause an issue with the client, but I would imagine your user's (or server's) normal web serving, network activity, patch updates and so on also are causing these open connections. I think the shutdown idea is an interesting idea, but could be complex to implement on a network, especially if it required to be operational for your IT group. If you have access to monitor network traffic, a tool like the Passive Vulnerabiltiy Scanner could report on a good portion of your vulnerabilites on those systems just by watching their applications interact over the network. Ron Gula Tenable Network Security Olson, John (CTECH) wrote: > Two years ago I submitted a bug to Altiris regarding the fact that when a > machine running the Aclient is scanned by Nessus (or any other port scanner > for that matter), the Altiris client software spawns process after process > without closing the connection(s) opened by the scanner (doesn't seem to > matter if it's a SYN scan or a Connect scan). As a result, you end up with > what amounts to be a DoS for the computer running the Aclient because it > keeps eating up resources until it becomes so sluggish the end user has to > reboot. Because the software chooses a random port each time the computer is > booted (or the service is stopped/restarted), I cannot simply exclude a port > (or even range) when scanning. Altiris support does not have a solution > other than to switch to a different client (Dagent?) which "should" allow us > to pick a fixed port. Personally, I think they should fix the program logic > in their software to at least "time out" or not spawn additional > processes....I am posting this publicly now since they have had ample time to correct this but have not chosen to do so. > > So far, the only thought I have for a workaround is to somehow shutdown the > Altiris service(s) on each machine prior to scanning it, perform the scan, > then restart the Altiris services. Does anyone know of a clean way to do > this? I suppose all of our Windows machines running Altiris could have a > scheduled script that shuts down the services at a specific time, and another > to start them back up at a specific time, leaving me with a "scan window" but > that is not very good since I prefer to scan during the day when I know the > majority of machines will be on the network and available for scanning. > Daytime is also when our Helpdesk personnel need that Altiris software the > most so there is a conflict here. > > Any ideas are welcomed! > > > John Olson, CISSP > > Sr. Security Analyst > > BI > _______________________________________________ Nessus mailing list [email protected] http://mail.nessus.org/mailman/listinfo/nessus
