Detecting it is doable with the MPF and IPS signature. Due to the nature of the adaptable protocol of skype which can tunnel iself into http, https and so forth. You can start blockign skype server's ip's but the race will be hard and it will autoadapt. I would focus on detection and use manual slap on the head tactic :-)
More info's on the practicals that can be applied in the AIC engine of the IPS or modular policfy framework in ASA, here explained for openbsd:
Skype is a tough protocol to block, they continuously keep updating it to bypass protection. I think some people actually analyzed it as a Masters/Phd thesis topic at Columbia University, so that gives you an idea about its complexity:
Find a list of the login servers, IP or DNS, and then block access to those? If it's a DNS name, you could create a blackhole entry for that.
Never tried it, but that seems the most effective way to combat this.
Looks like the PDF that happs linked to shows what is needed to break login.
Just make sure your block the access to the local hosts file, otherwise it has higher priority and basically ruins the whole DNS blackholing bit. Also block access to external DNS servers from the user machines.
Thanks for the link .. I will read it today. According to Cisco .. NBAR running on an ISR should be able to clasify Skype http://www.cisco.com/en/US/docs/ios/qos/configuration/guide/clsfy_traffic_nbar.html#wpxref1140292
.. should NBAR also be able to block it ..?
Any ideas ..?
The exact same restrictions applies: detection is ok because you will not force skype to adapt and go via tunneled HTTPs connection. If you start blocking it, it will adapt and change port / network behavior.
If you were able to block access to the login servers, then tunneled HTTPS wouldn't matter. They'd never be able to use Skype, because they couldn't login.
Just a theory, I'll try testing it sometime soon.
Besides, it's been my experience that NBAR doesn't work very well for advanced applications like P2P or Skype.
From the link above:
"Skype was introduced in Cisco IOS Release 12.4(4)T. As a result of this introduction, Skype is now native in (included with) the Cisco IOS software and uses the NBAR infrastructure new to Cisco IOS Release 12.4(4)T. Cisco supports Skype 1.0, 2.5, and 3.0. For Cisco IOS XE Release 2.1, Skype is supported in the TCP type only. "
TCP only, and version dependent. Not a very reliable solution if you ask me.
thanks for your comments .. blocking the login servers ..? I can use a skype client and mirror the session (SPAN) .. but should the login servers IP addresses be always the same ..? Do you know whether the login is IP or DNS dependent ..? In any case I guess the best approach is to give it a try .. I will do that as soon as I can.
We have ASA5540 with SSM20. I used the Cisco IDM to configure signatures 11251/0 7216/0 which are both Skype related. I set the action to "block host" and did the rest of the appropriate configurations to allow the SSM to communicate with the ASA and do blocking. It appears to work as I do see messages and have logs showing users running the Skype application being blocked (I set the block for about 5 minutes). I can't verify that all Skype is being blocked, but can verify that some of it is.
Have you actually tested with a client to see if it will connect? It seems the behavior of Skype is to "wait it out" and then connect via a different port to a different server.
We have done some testing (not a lot). With a block of 5 minutes, this appears to be long enough to block some of the skype connections. With clients that have Skype set to run automatically when the PC boots, we have seen the IPS continually put the block onto the ASA over and over again for days. I can't confirm that it is 100% effective, but it is doing some blocking.
Hi .. I agree, installing skype and trying to login will be the only test that will verify whether the ASA and SSM signature are actually working.
I have been doing some captures of the login process .. and noticed that skype keeps adapting and eventually successfully logs in. I am still trying to figure out the 'login' server's IP that the doco posted by Happs is talking about. Apparently a colleague has successfully blocked skype in the past by only allowing a proxy to connect out on ports 80 and 443. Then he upstream this to a sophos content filter device which was configured to block any request containing the IP address on the URL request.
I've not got enough time to dedicate to figuring it out right now. I plan on setting aside a few days next month to do so. But in the mean time, there are is a lot more and updated information about Skype located here:
The other link is kinda old.
Paul the link posted by you contains 'exactly' the same version of the whitepaper as the one posted by me earlier, so "The other link is kinda old." bit does not really hold true.
However it does mention a nice FAQ question to meet the requirement, so 5 points from my side.
The document you posted is kinda old, in the title it says it's from 2004.
I didn't mean to offend, there are updated documents on the link I posted that have more information. That was my point. Not that what you posted was invalid, it's just that there have been newer versions since then so some updated information would be good.
I haven't had time to mess with this, I want to try it in a couple of weeks. I'm thinking a custom meta signature would be the best bet.