Full Disclosure mailing list archives
Re: blocking SkyPE?
From: Alain Fauconnet <alain () ait ac th>
Date: Tue, 25 Jan 2005 10:05:23 +0700
Hello list, Thanks to all the tips and suggestions about my question on how to block SkyPE traffic. I'll summarize and reply below: * "Brenno J.S.A.A.F. de Winter" <brenno () dewinter com>:
You had the technical answer already. I just wanted add this: How certain are you that Skype is really something you want to block. Have you asserted there is a problem to solve?
Well, not sure I have an usable answer yet (see replies below). Why do I want to block it? Because it's part of our policies to prohibit entertainment-related usage of the IT facilities on campus. We can't afford the b/w (mind you, b/w is *expensive* in developing nations, and especially here in Thailand due to a state monopoly on telecoms). SkyPE is definitely used for such as of now, on computers we don't control (dorms & housing especially).
Is the solution really what you want? If you want to block John Doe that will be okay. If you have legions of techies walking around I'd rethink your approach. Using OpenVPN it is easy tunnel all protocols that one wants to use.
I would certainly not call our users a legion of techies (sometimes I wish they'd be more techies than they are). Setting up a VPN would require having control of a box outside of our campus, which is not likely for the vast majority of them. Even if some can still get through, blocking 80+% of the current SkyPE users is good enough for me. * Bryan K. Watson <lists-security () nettracers com>:
Commercial, Off-The-Shelf: 1)Fortinet stops this and I have used it for such...for T1 speeds you can keep the cost under $1K and can be installed in bridge/transparent/inline mode so as not to disturb your existing infrastructure. 2)Checkpoint will do application/layer-7 inspection as well, but will cost quite a bit more to purchase and implement.
Thanks for the tip, I'll look into Fortinet if the big guys here are willing to open their wallets to reach the goal. A whole bunch of products do L7 inspection actually, but the real question is: can they detect SkyPE specifically? If you look into Cisco's NBAR L7 detection, it can certainly detect a lot of P2P (e.g. Kazaa - we're using it already), but to the best of my knowledge, not SkyPE at this time. There have been rumours around a SkyPE NBAR module, but none is available to the common mortal as of now.
Roll-your-own: Probably will cost you more in time to do this,
That's OK, my time is cheap :-( I've been already spending quite some time on this actually.
but you can use Snort to detect and control an IPTables firewall...I have seen but not tried this updated implementation of a dynamic IPTables config tool based on Snort Rulesets: http://www.cipherdyne.com/ http://www.cipherdyne.com/fwsnort/
Oh yeah, this and the dozen of sibling open-source project (e.g. http://l7-filter.sourceforge.net/). Again, I'm afraid the issue is not the tool, the issue is the existence of patterns for L7 detection of SkyPE. However, using lsad to detect traffic patterns that are likely to relate to SkyPE (e.g. ICMP ping, then UDP to some high port at the same address with a packet size within a given range) then dynamically blacklist the target IP would be a track to explore. I'm afraid that the risk of false positive is quite high, though. * Graham Bignell <bignell () gmail com>
Why are you needing to restrict the protocol? I've tried and found it was just easier to manage bandwith on a per-IP basis. Ye olde QoS.
Hrm.. you mean source or target IP? Neither seems quite manageable at first sight in our case. Of course giving a high QoS to identifiable and (mostly) desirable traffic and a lower QoS to all the rest is the usual way. How would you differentiate real HTTPS traffic from SkyPE using port 443 though? (SkyPE can run completely over port 443 if nothing else is available). * James Tucker <jftucker () gmail com>
[1] How about an application level policy, whilst it isn't the 'block' that you are looking for it may be appropriate?
Can you elaborate please? Is that a "don't install SkyPE" policy? or are you talking about L7 classification of traffic again?
[2] SuperNodes of the network typically run on a single port, although IIRC they may change their bindings if necessary / by explicit request. If you are having problems blocking it with due to dynamic port bindings, then you may find it easier to maintain a ban list of supernode ip's. This is somewhat heavy handed and a brute force approach but it should work.
Been there, tried that. The shared.xml file in C:\Documents and Settings\All users\Application Data\SkyPE has a list of SNs (supernodes) this machine uses. So I've tried having a test box feed its shared.xml file to a Linux-based gateway that generates a dynamic set of iptables rules to blacklists all these IPs. It only had marginal effectiveness, because there doesn't seem to be a centralised list of SNs. Each clients gets a list from the first SN it manages to connect to, but that list varies vastly from SN to SN.
[3] There was a suggestion at one time, (from Skype themselves IIRC) that blocking 80.160.91.5 & 80.160.91.13 will prevent the bootstrap nodes from authenticating properly with the client. I have not verified this, (...)
This is no longer true. I've also tried to build a list of SkyPE login servers and blacklist them, but I'm now almost sure that clients can authenticate through any SN (that basically tunnels the authentication to a login server).
[4] - The potentially expensive option; using a deep packet inspection firewall you could check for skype authentication and network control data, if found the connection could then be terminated and banned. There are few firewalls which are capable of doing this at speed.
See above on L7 detection. Not much to hook onto in an encrypted protocol that has obviously been engineered to evade signature-based detection. * "morning_wood" <se_cur_ity () hotmail com>
sorry.. i found a simple dump ( refered to in the main paper I sent ) d.w [03:49:01.714 - 01.06.2004] Proto: UDP len: 46 195.182.78.24:10696 -> 4.65.228.218:42119
(...) I've made dozens of dumps as well, more or less matching your observations.
hi, i did some testing some months ago... my enclosed paper is unpublished and only based on some simple observation and testing. if you find it of some use please credit it in any presentation/research release.
Thanks a lot for the paper.
Donnie Werner June 1, 2004 http://zone-h.org
http://80.160.91.13/index.php/peerenabler/developers/ http://80.160.91.13/index.php/peerenabler/developers/documentation
Skype claims some "magical" things..
based on evidence we can dedude what skype is doing. upon inspection skype operates as follows...
(edited out for brievety) I have been unable to confirm that there's an identifiable set of central servers SkyPE needs to communicate to. This may have been true months ago (I think it was) but in its current incarnation, the product seems to happily live with only connectivity to supernodes, which may be a too fast moving target for practical blacklisting. At this time, it seems to me that the only track that is worth exploring, pending the availability of usable L7 detection protocol signatures for any open-source L7 traffic classification engine, and putting aside Fortinet which I have to look into, is the detection of "stateful traffic *patterns*" (as mentioned above) and dynamic blocking of targets. This doesn't look sexy, though. Thanks again for all the input, Greets, _Alain_ _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Current thread:
- blocking SkyPE? Alain Fauconnet (Jan 24)
- RE: blocking SkyPE? lists-security (Jan 24)
- RE: blocking SkyPE? Brenno J.S.A.A.F. de Winter (Jan 24)
- Message not available
- Re: blocking SkyPE? Alain Fauconnet (Jan 24)
- Re: blocking SkyPE? Valdis . Kletnieks (Jan 24)
- Message not available
- Re: blocking SkyPE? Alain Fauconnet (Jan 24)
- RE: blocking SkyPE? lists-security (Jan 25)
- Re: blocking SkyPE? Alain Fauconnet (Jan 25)
- RE: blocking SkyPE? lists-security (Jan 25)
- Re: blocking SkyPE? Alain Fauconnet (Jan 25)
- Re: blocking SkyPE? Alain Fauconnet (Jan 24)
- RE: blocking SkyPE? lists-security (Jan 24)