Re: rules for skype

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Grant,

My company requires me to block Skype too. There are 3 ways I have found after a lot of research:

- Block the authentication servers' IPs. The last I knew there were only 2 servers for authentication. Their IPs are given in that pdf document. I am not aware if they have added new servers now.
- Use Layer-7 pattern. Again, the layer-7 pattern has worked for some and not worked for many. It has worked for me.
My network scenario: The network I manage has private addresses throughout. I think it has something to do with NAT and private addressing because in my case when the client tries to authenticate with the server the hex-pattern of those UDP packets stays the same throughout every session. This has not been true in every case. You can give it a shot.
- Use *tc* to choke the skype traffic. I have a list of apps to allow through the network. The rest go into a default pipe of 2 Kbps. This deteriorates the performance of the application. I think text chatting will still go through but voice chatting, file sharing and all gets choked.
NOTE: I have had better success not blocking its default ports. That way I can keep it away from the standard Internet ports and thus easily classify it into the default pipe.


Now given the nature of this application, some things might work for you and some might not. I thought I would share my knowledge on this ....

Good luck,
Deepak


----- Original Message ----- From: "Taylor, Grant" <gtaylor@xxxxxxxxxxxxxxxxx>
To: <netfilter@xxxxxxxxxxxxxxxxxxx>
Sent: Monday, May 02, 2005 11:58 AM
Subject: Re: rules for skype



I can also block https by blocking port 443 that´s not the point. The point is to block "bad" 443 port traffic and let "good" traffic pass.

One thing that might be able to be done is to limit on the amount of traffic that can pass through any given HTTPS (443) connection. Namely if an HTTPS connection is on going and has carried a meg of data or more (any thing that would be more than any legitimate HTTPS web submit would be) you could probably know that the traffic was not standard HTTPS traffic and thus safe to shut down. This might trap some STunnel (?) (SSL tunneling) but then you would know the IP of the other end and you could explicitly allow ongoing HTTPS connections to that IP. This amount of data match could possibly be matched via the "connbyes" match extension from Patch - O - Matic Extra Repository.




Grant. . . .





[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux