Problems w/scanning XP SP2 again
I know I have previously done an extensive scan & sniff session for scanning an XP SP2 system with SD+
I documented the firewall logs, analyzed network traffic with and without the firewall up and with exceptions made for firewall rules.
I put all that documentation up here in the forums, and watched as several other people complained that despite my hints or the hints of the SD+ support people or tricks from others, that there seemed to be continued problems with scanning SP2 systems.
Now, I don't know if "Patch Tuesday" closed off anything new, or what.. But I tried to scan my system today. My system would NOT get scanned! (which has ALREADY been scanned back on April 4th after I made a number of changes to the firewall exception rules to get it to work.)
So I'm going through the steps again that I did before, and what puzzled me in the past was that on April 4th, port 2640 that seemed to be used for scanning before. Why that port? I looked over my traffic today from the server, and no such port is being used. Instead ANOTHER port is being used!!! (2736 on the server to 1796 on my client)
The problem seems to be that SD+ is using DIFFERENT ports to scan systems for traffic. I don't know what the rationale is for doing so, and don't know if it has to do with having brought the server down and back up, and it assigns some new port off the top of its head for scanning from then on or what.
Maybe it's uncontrollable, and a byproduct of RPC, WMI and DCOM and whatever else allocating a "dynamic" communication channel. I'm not a windows system architect. But we need to find a way to consistently be able to scan XP SP2 (and beyond) systems.
But us admin folk need to have a consistent means by which to open a firewall port and allow JUST SERVICE DESK + scans to happen WITHOUT dropping the ENTIRE firewall!!!
Can you SD+ techs find out WHY a new port is being used to scan? And find out HOW to lock it down to just 1 port? Port 135 is known. Fine.
Whatyasay SD+ folks? Can we get this fixed??
Justin
I documented the firewall logs, analyzed network traffic with and without the firewall up and with exceptions made for firewall rules.
I put all that documentation up here in the forums, and watched as several other people complained that despite my hints or the hints of the SD+ support people or tricks from others, that there seemed to be continued problems with scanning SP2 systems.
Now, I don't know if "Patch Tuesday" closed off anything new, or what.. But I tried to scan my system today. My system would NOT get scanned! (which has ALREADY been scanned back on April 4th after I made a number of changes to the firewall exception rules to get it to work.)
So I'm going through the steps again that I did before, and what puzzled me in the past was that on April 4th, port 2640 that seemed to be used for scanning before. Why that port? I looked over my traffic today from the server, and no such port is being used. Instead ANOTHER port is being used!!! (2736 on the server to 1796 on my client)
The problem seems to be that SD+ is using DIFFERENT ports to scan systems for traffic. I don't know what the rationale is for doing so, and don't know if it has to do with having brought the server down and back up, and it assigns some new port off the top of its head for scanning from then on or what.
Maybe it's uncontrollable, and a byproduct of RPC, WMI and DCOM and whatever else allocating a "dynamic" communication channel. I'm not a windows system architect. But we need to find a way to consistently be able to scan XP SP2 (and beyond) systems.
But us admin folk need to have a consistent means by which to open a firewall port and allow JUST SERVICE DESK + scans to happen WITHOUT dropping the ENTIRE firewall!!!
Can you SD+ techs find out WHY a new port is being used to scan? And find out HOW to lock it down to just 1 port? Port 135 is known. Fine.
Whatyasay SD+ folks? Can we get this fixed??
Justin
