Re: Policy around IP Phones, Skype, etc.

["Jones, Dan" <Dan.Jones () UMASSMED EDU>]

We drop Skype along with some other P-to-P protocols at the network perimeter for several reasons including the advance 
of malware through these channels, and that these protocols consume significant amounts of University computing 
resources to further the interests of users who have no University affiliation.  
 
We detect this traffic at the network perimeter with a Packeteer. A Packeteer device 'found' the Skype protocol, and 
has since been configured to drop Skype, although there has been no validation whether or not Skype is operating 
beneath the Packeteer's radar. Packeteer is supposed to detect applications at up to layer-7, so in theory it can spot 
protocols as they port hop. 
 
Interfacing an IDP with network switching electronics to effect traffic decisions at the network edge is a goal of ours 
to help control malware. I suppose that Skype can be partitioned off (dynamically detected and blocked at network 
ingress) with the rest of the riff raff. The conveyance of malware through Skype channels is serious, especially since 
these channels are encrypted. 
 
Hope this helps. 
 
 
Dan Jones
Manager, IT Security
University of Massachuserrs Medical School
________________________________

From: David Gillett [mailto:gillettdavid () FHDA EDU]
Sent: Wed 10/25/2006 6:18 PM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] Policy around IP Phones, Skype, etc.


  While in theory one can use Skype entirely "below the radar", in practice clients seem
to eventually try to connect on port 33033 or 54045, or to ui.skype.com.  You don't have
to catch *all* the traffic to detect it, just *any* of the traffic.
  What's tricky is BLOCKING it once it's detected, since it will resort to 80 and 443 if it's
not getting through on higher ports.  
 
David Gillett
 
 
________________________________

From: Bruce Barrett [mailto:bbarrett () ccri edu] 
Sent: Wednesday, October 25, 2006 12:36 PM
To: gillettdavid () fhda edu; SECURITY () LISTSERV EDUCAUSE EDU
Subject: RE: [SECURITY] Policy around IP Phones, Skype, etc.



        Does anyone know how to detect that Skype is being used on network? It doesn't look that straightforward. 
Thanks.

                                                                                                                        
                Bruce

         

        
________________________________


        From: David Gillett [mailto:gillettdavid () FHDA EDU] 
        Sent: Wednesday, October 25, 2006 2:37 PM
        To: SECURITY () LISTSERV EDUCAUSE EDU
        Subject: Re: [SECURITY] Policy around IP Phones, Skype, etc.

         

          We have concerns which currently lead us to block these:

         

        1.  Our backbone doesn't yet do QoS.

         

        2.  Skype can be used as a file delivery mechanism; I believe there have already been attempts to release 
Skype-based worms.

         

        3.  Skype clients relay for third parties; we interpret this as a violation of the ToS from our state-funded 
ISP.

         

        4.  Firewalls are policy enforcement devices.  When you engineer an application like Skype to sidestep 
firewalls, what you are building is a policy violation device.

         

        5.  We have a perfectly good campus phone system.  If a user has a need it's not meeting, we'd like them to 
talk to us and not just try to "fix" it themselves.

         

        David Gillett

         

                 

                
________________________________


                From: Sadler, Connie [mailto:Connie_Sadler () BROWN EDU] 
                Sent: Wednesday, October 25, 2006 9:55 AM
                To: SECURITY () LISTSERV EDUCAUSE EDU
                Subject: [SECURITY] Policy around IP Phones, Skype, etc.

                 

                Does anyone have thoughts - or an actual policy - regarding the use of IP Phones or software such as 
Skype, etc. that they are willing to share?

                Thanks! 

                Connie J. Sadler, CM, CISSP, CISM, GIAC GSLC 
                IT Security Officer
                Brown University Box 1885, Providence, RI 02912
                Connie_Sadler () Brown edu <mailto:Connie_Sadler () Brown edu> 
                Office: 401-863-7266
                PGP Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x91E38EFB 
<http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x91E38EFB> 
                PGP Fingerprint: DA5F ED84 06D7 1635 4BC7 560D 9A07 80BA 91E3 8EFB