Ghost Solution Suite

Hello:

Recent changes to our enterprise security policy have rendered GhostCast Server (GhostSrv.exe) unusable for us. There is a blanket exclusion for all processes on TCP and UDP ports 6660-6669. This is preventing the clients from locating the server. Is there anyway to change the discovery port? If not, is there any documentation you have that status such, beyond the page below?
http://service1.symantec.com/SUPPORT/ghost.nsf/ppfdocs/2002101612025325

GSS 2.5.1
OS - Windows 2003 R2 SP2 x86

I hearty thank you to anyone who can help get us imaging in volume again!

Regards,

Joe M.

I suppose beating your Enterprise Security guys over the head and shoulders with a baseball bat is not an option?  Surely IT should be an enabling process and not a disabling process.....???

On the other hand, if they block every port in existence, you have total security and nothing more to do, so maybe that's the route to follow for a quiet life?

Check this document,

http://www.symantec.com/docs/TECH108194

Actually, my security group is great. The actually "get it". They understand buisness still has to get done and do not just willy nilly shut things down for policy infractions. Also, security policy is evaluated beyond just security impacts. In a business environment, is there really a need for IRC? While 6666 is not a registered port, it is definately well known to be used for IRC, long before ghostcast became a product. Block, log, and monitor log levels of IRC port activity is an good way to get clued in that a worm has made it into your environment and limit the damage (block a common avenue of C&C) once there. A blanket allow of 6666 across the enterprise would be a non-starter. I want to be sure that all possibilities of makeing ghost not look like IRC have been exhausted before working out minimum levels of exception for either specific hosts or a blanket on ghostsrv.exe.

Not so much having a clear answer here, I may have to open a ticket. I am suspecting the answer is no, but need something clearer than the two copies of the same tech doc.

Best of luck,

~joe

I never thought I would see the day. Congratulations on having a security group that actually thinks about what they are doing. Yours is indeed a rare group!!

You may need to open a ticket unless Nigel Bree spots this thread as he knows the product inside out, being one of the main developers before the group was shut down.

It's not possible to change this port; the 6666 and 7777 values are hardcoded into the GhostCast clients, and there are no protocol elements which negotiate it to allow it to be changed (this isn't what I would have done, but I didn't get to write the first version of GhostCast, even though that was what I was nominally moved over to Binary Research to help with in 1997).

I do sympathise with any customer caught in the clutches of such facepalmingly-stupid IT departments; Symantec's corporate IT was filled with this kind of idiocy too, especially during the years when IT was inside the Finance organization and thus totally unaccountable, and setting idiotic policy defaults - during those years, R&D staff were forced to do all their work on self-managed parallel networks on self-managed machines to do our jobs at all.

If you're stuck dealing with people who really can't understand there's a difference between boundary security, host security and intra-zone traffic, GhostCast traffic is enough to recognize and distinguish from IRC traffic in ACL-capable switch equipment (which will be where this policy is getting enforced) if you arrange to permit traffic between controlled IP ranges, as all GhostCast traffic addressing port 6666 will originate from one of a small handful of hosts, and won't involve any external IP ranges, so the GhostCast server IPs can be matched in switch rules. It's inconvenient, but it's the price of wrongheaded policies like this.

Nigel:

Thank you for taking the time to respond, knowing the answer difinatively is helpful. Is there any documentation that affirmatively states this? It would help me drive the policy change. 

I must disagree with your security assessment. I will say that you are making incorrect assumptions and that in light of all the considerations in play, you may think differently. I have tremendous respect for the security apparatus in question here and in my opinion they do an exceptional job of finding a good balance between security and and other concerns often in opposition.

Regards,

Joe M.

Is there any documentation that affirmatively states this?

None other than the already-linked ones that I am aware of. We only ever had to deal with a few inquiries over the years along these lines, and they were easily dispatched (although none were as amusing as the German industrial concern who complained to us that GhostCast was slow and could we fix it, and by the way they had disabled all multicast and all broadcast connectivity both inside and between every subnetwork in their enterprise, and would not enable either "for security" - dealing with malware by preemptively destroying your own network isn't just in the Onion).

If you want someone with an @symantec.com e-mail to check that the port numbers are all hardcoded #define's in the header files, then you'll probably need to raise an official support ticket and they'll forward it to the maintenance guys who can verify it for you.

I must disagree with your security assessment

Hey, it's your network. Given that I am well-versed in these kind of security issues, I nonetheless felt it worthwhile to make an informed contrarian point.

Serious Network Situational Awareness tools easily distinguish between the kinds of traffic being talked about at very large scales, and even if the primary threats being defended against are insider ones (rather than ones originating externally, where filtering *is* an important tool) it should be clear that in general a policy of actually using such situational-awareness tools is more valuable than preemptive network-level filtering of only the most easily-detected traffic which *might* be illegitimate (and has the advantage of not just diverting the threat traffic to harder-to-monitor channels than something as "hey! look at me!" than botnet control via IRC in plain text).