[VOIPSEC] FWD: Blocking Skype

Mon Nov 14 11:33:36 CST 2005

 >Date: Sun, 13 Nov 2005 23:35:41 +0400
 >From: dsluser at emirates.net.ae
 >To: full-disclosure at lists.grok.org.uk
 >Cc:
 >Subject: [security] [Full-disclosure] Blocking Skype
 >Sender: security-bounces at lists.seifried.org
 >
 >
 >Blocking Skype Using Squid and OpenBSD
 >---------------------------------------
 >
 >
 >Abstract :
 >
 >After much digging online for an effective way to stop this pesky app
 >that is highly de-centralised and a big pain to blocked, I finally found
 >a way
 >to do quite nicely. It has been working perfectly fine on our corporate
 >network, and we have had no complaints of users being denied access to
 >legitimate web destinations (that are in compliance with our security
 >policy of course). I used Squid-proxy running on an OpenBSD server to
 >carry out the below. The choice of OS to run the proxy on is subjective
 >(I chose OpenBSD as my network OS of choice for its proven security
 >record and excellent reliability) and has no effect over the actual
 >blocking mechanism. The same can be accomplished on any other BSD or Linux
 >flavour.
 >
 >
 >Background :
 >
 >This basic write-up will not delve deeply into the operation of Skype,
 >but will quickly highlight the main challenges of blocking this
 >application. As
 >mentioned, the below is not an accurate study of how Skype operates, and
 >is not be 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 Squid-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
 >
 >
 >I have had no problems at all with the above setup, and as a result,
 >only Skype is blocked, as most(if not all) companies serious about
 >having a web presence
 >have registered domains and hence are referenced by their FQDN URLs.
 >
 >The blocking was so effective, that one user told me days later, he had
 >not bothered calling me the first 2 days to complain about lost Skype
 >connectivity
 >because he thought there was an actual problem with Skype. Apparently,
 >Skype is so good at getting around firewalls. On the third day however,
 >the user called
 >to inquire whether Skype had effectively been blocked. The answer was a
 >efinitive yes :)
 >
 >
 >Should you find the above useful, I would appreciate all comments emailed to
 >vi_cipher at yahoo.com. Enjoy !
 >
 >
 >
 >Written by rootn0de
 >November 13th - 2005
 >_______________________________________________
 >Full-Disclosure - We believe in it.
 >Charter: http://lists.grok.org.uk/full-disclosure-charter.html
 >Hosted and sponsored by Secunia - http://secunia.com/
 >
 >_______________________________________________
 >Get your free port scan here: http://www.seifried.org/freescan2/
 >
 >security mailing list
 >security at lists.seifried.org
 >https://lists.seifried.org/mailman/listinfo/security
 >
Robert Moskowitz
Senior Technical Director
ICSA Labs, a division of Cybertrust, Inc.
W:      248-968-9809
F:      248-968-2824
VoIP:   248-291-0713
E:      rgm at icsalabs.com

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit