ASA5520 allowing/blocking Skype

Question

I have the following:
redundant ASA5520s on v8.2(1)
proxy server/web filter for blocking access to websites for staff/students
users who want to use Skype
Cisco Catalyst 4507 core
a dozen VLANs for staff/student/WiFi etc
Cisco core policy that routes 80/443 to transparent proxy on a WiFi VLAN
Windows desktops have direct proxy settings in IE
Pretty much all outbound ports are closed with 80/443 and a handful of specifics for various things open. Because of this Skype attempts to use 80/443 which are sent to the proxy server but bnecause they're not HTTP/HTTPS they cannot be understood. Skype attitude is to open 1024-65535 which is just plain stupid!
There's no way to specify which port(s) Skype uses for outbound. I tried opening 33000-33099 which worked perfectly for 2-3 devices (Win laptop, iPad) but others failed all the time.
I've seen people mention using an AIP-SSM module in the ASA for blocking Skype (and other things eg torrents). Is it possible to use this module to allow Skype eg on ports 1024-65535 whilst blocking any other application from using those ports?
Any advice on the handling of Skype in this configuration would be appreciated.

Answer 1

Hi Steve,
To block skype is not that easy i am sharing a piece of work which i did some time ago. Hope it might be helpful in case you need to block skype.
Its just a workaround and you may decide your course of action
these are skype login servers:
"dir1.sd.skype.net:9010", "dir2.sd.skype.net:9010",  "dir3.sd.skype.net:9010", "dir4.sd.skype.net:9010",  "dir5.sd.skype.net:9010", "dir6.sd.skype.net:9010",  "dir7.sd.skype.net:9010", "dir8.sd.skype.net:9010"  "http1.sd.skype.net:80", "http2.sd.skype.net:80",  "http3.sd.skype.net:80", "http4.sd.skype.net:80",  "http5.sd.skype.net:80", "http6.sd.skype.net:80",  "http7.sd.skype.net:80", "http8.sd.skype.net:80" Skype-SW connects  randomly to 1-8.
if you want to block skype totally and dont want to spend alot on your firewall. you can use Squid proxy running on OpenBSD.
The below is not an accurate but near by or approximate study of how Skype operates, and is not a comprehensive analysis of its behaviour :
1) Skype will initially attempt to contact supernodes, the IPs of which are in a file stored along with the other files that Skype installs. The first method of contact is direct. The source ports that Skype attempts to connect from are non-default ports. From my observations I could see that the UDP source port 1247 is the initial control channel. Once the connection is established, the rest of the communications is done in TCP over non-default source ports with ranges sweeping from 2940-3000. In general, any company that is serious about its security policy would have strict egress filtering rules, which makes identifying the non-default source/destination ports that Skype uses irrelevant since they would be blocked anyway.
2) If the above fails, Skype will use the proxy server specified in Internet Explorer, and attempt to tunnel the traffic over port 443 using the SSL protocol. The destination IPs are of course random as above, which makes destination blocking out of the question. The only option left is to block SSL, which is not really a solution, unless you want to end up excluding all legal SSL destinations.Deleting the user's proxy settings would also disallow Skype from connecting. That would however leave the user without internet access. Even if the user had no proxy settings, and the proxying was done transparently (which would definitely include proxying http and https traffic), the Skype traffic (SSL) would again be transparently proxied, which puts us back at square one.
The Alternative That Works :
Internet access services in our corporate workplace are provided by our proxy servers. The setup is basically quid-proxy running over OpenBSD. PF (packet filter, OpenBSD's built-in firewall) takes care of all the egress/ingress filtering, and the rest of the content filtering is done in Squid using custom-written accesslists. Blocking Skype's default operation was a no-brainer, as our strict egress filtering rules block all outgoing traffic. The problem was with Skype detecting the user's proxy server, and tunneling its traffic over Squid. Upon checking Squid's access logs, all we could see was requests made by the user's machines using the 'Connect' method to random destination IPs.
As mentioned above, blocking SSL or the 'Connect' method, means blocking access to all legitimate websites that use SSL (Hotmail, Yahoo,E-banking, E-commerce websites, e.g any website that is secured by SSL).Should you go down that road, you would have to explicitly allow all permitted destinations (an ongoing technical nightmare).
The catch in successfully blocking Skype given all of the above, would be to block access to requests made by clients, to destination specified by their numeric IP address, AND using the 'Connect' method to tunnel the Skype data. I have done that simply by writing an access list in Squid that achieves just that. The access-list is in regex (regular expression) format that identifies numeric IP addresses. The access-list further specifies the connection method that the client is using. In Squid the 'Connect' method is conveniently called 'Connect' as well.
The access list then is of the following form :
# Your acl definitions
acl numeric_IPs urlpath_regex ^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+
acl connect method CONNECT
# Apply your acls
http access deny connect numerics_IPs all
Regards
Anim Saxena
*Rate helpful posts*