Message-ID: <20050125030523.GC16639@ait.ac.th>
From: alain at ait.ac.th (Alain Fauconnet)
Subject: blocking SkyPE?

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@...inter.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@...tracers.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@...il.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@...il.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@...mail.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_

Powered by blists - more mailing lists