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 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