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
Nessus@list.nessus.org
http://mail.nessus.org/mailman/listinfo/nessus
