Re: rules for skype

Re: rules for skype

[Taylor, Grant]

> But hey.. why do you want to stop skype?

As a consultant / network administrator some of my clients have sensitive environments where they need to control what goes in to and out of their network.  As such for in house instant messaging I'm going to implement Jabber.  There is no need for such as Skype for their day to day business needs.  If they ever do need any thing like it we will address that need when it arises.  I also have other clients who only want people to use the net for research and do not want to have to pay for the bandwidth that things such as Skype would use.  I'm more after blocking the P2P file sharing capability of Skype than I am the voice apps.  If people do need to communicate via VoIP I'll probably end up installing Asterisk and handing out soft phones.



Grant. . . .

rules for skype

[Mofizul Hoq]

Hi Mr. Deepak,
I have read your post on the list.
I a linux newbie.
I am working in a company which has very limited uplink bandwidth. I need the iptables scriptlet for blocking skype as it is consuming all of my uplink bandwidth. To sustain with this limited uplink bandwitdth we must block skype voice chat. Clintes are complaining about uploading files etc.
 
Please help me
 
Mofizul Hoq

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: rules for skype

[Daniel Lopes]

Seferovic Edvin schrieb:
> I think that you can stop ALL https connections with squid.. if you want of
> course... but then, I dont know if there is such way as you described it. A
> very good ACL implementation is squidGuard.
> 
> But hey.. why do you want to stop skype?
> 
> Regards,
> 
> Edvin Seferovic
> 
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.

Re: rules for skype

[Taylor, Grant]

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

Re: rules for skype

[Taylor, Grant]

> What about for example online browsing the Netfilter Mailinglist? It 
> uses https too and the meg of data could fast be reached.

Hmm.  Maybe filtering would have to be done based on duration.  Hmm, the more that I look at it the more that I think that you would have to limit the number of times that the rule did natch.  You would probably want to set a limit (limit, dstlimit, connlimit, hashlimit, etc) on on the number times (per some duration) that a person is allowed to have an HTTPS connection that is larger than 1 MB.



Grant. . . .

Re: rules for skype

[Deepak Seshadri]

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@riverviewtech.net>
To: <netfilter@lists.netfilter.org>
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. . . .

Re: [SPAM] Re: rules for skype

[Taylor, Grant]

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

*nod*  I had thought of this one as well.  Though I don't know how long lived this will be before Skype gets around this too.

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

Is there any way that you could share with us the layer 7 filters that you use?

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

Interesting.  I would not have thought of allowing just enough of the traffic so that you could identify it and sort of attempt to control it.  However this would not be acceptable to some of my clients.  I'll keep that in mind as a technique to deal with vicious protocols in the future.  Thanks.  :)

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

*nod*  This is unfortunately the very nature of these troublesome protocols.  I'd also appreciate seeing your config if you could show it to us.



Grant. . . .

Re: rules for skype

[Deepak Seshadri]

>> - 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.
>
> *nod*  I had thought of this one as well.  Though I don't know how long 
> lived this will be before Skype gets around this too.
>
>> - 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.
>
> Is there any way that you could share with us the layer 7 filters that you 
> use?

For the layer-7 patterns to work with iptables, you have to patch iptables. 
Here is the layer7 project URL:
http://l7-filter.sf.net

Note: They have a skype pattern matching only the voice traffic. For some 
reason they don't have the one that matches the authentication packets.

Here is the one I use:
------- begin-----
skype
^\x16\x03\x01$|^\x17\x03\x01$
-------end-------

Copy-paste the section between begin & end to a file named skype.pat.
Follow the instructions provided on the layer-7 filter webpage on how to use 
the pattern in your rule-set.

>
>> - 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.
>
> Interesting.  I would not have thought of allowing just enough of the 
> traffic so that you could identify it and sort of attempt to control it. 
> However this would not be acceptable to some of my clients.  I'll keep 
> that in mind as a technique to deal with vicious protocols in the future. 
> Thanks.  :)
>
>> 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 ....
>
> *nod*  This is unfortunately the very nature of these troublesome 
> protocols.  I'd also appreciate seeing your config if you could show it to 
> us.

Sorry. Could you please tell me what config you are talking about?

>
>
> Grant. . . .

Deepak 

Re: rules for skype

[Victor Yeo]

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

Where can i find more information on *tc* ? thanks for any reply.

Rgds,
Victor

----- Original Message ----- 
From: "Deepak Seshadri" <d_s123@hotmail.com>
To: "Taylor, Grant" <gtaylor@riverviewtech.net>;
<netfilter@lists.netfilter.org>
Sent: Tuesday, May 03, 2005 1:01 AM
Subject: Re: rules for skype


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

Re: rules for skype

[John A. Sullivan III]

On Tue, 2005-05-03 at 15:17 +0800, Victor Yeo wrote:
> > - 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.
> 
> Where can i find more information on *tc* ? thanks for any reply.
> 
> Rgds,
> Victor
> 
<snip>
You can try 'man tc' and take a look at
http://lartc.org/howto/index.html

Good luck - John

-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@opensourcedevel.com

If you would like to participate in the development of an open source
enterprise class network security management system, please visit
http://iscs.sourceforge.net

Re: rules for skype

[Fajar Priyanto]

On Tuesday 03 May 2005 14:50, John A. Sullivan III wrote:
> On Tue, 2005-05-03 at 15:17 +0800, Victor Yeo wrote:
> > > - 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

I've blocked tcp 443, but it seems that skype can go through tcp 80?
http://www.skype.com/help/guides/firewall.html

This is really annoying an unethical, don't you think?
-- 
Fajar Priyanto | Reg'd Linux User #327841 | http://linux2.arinet.org
Ubuntu Hoary 5.0.4
public key: https://www.arinet.org/fajar-pub.key

Re: rules for skype

[Daniel Lopes]

Fajar Priyanto schrieb:
> On Tuesday 03 May 2005 14:50, John A. Sullivan III wrote:
> 
>>On Tue, 2005-05-03 at 15:17 +0800, Victor Yeo wrote:
>>
>>>>- 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
> 
> 
> I've blocked tcp 443, but it seems that skype can go through tcp 80?
> http://www.skype.com/help/guides/firewall.html
> 
> This is really annoying an unethical, don't you think?


You can send all port 80 traffic through a proxy like Squid this should 
prevent Skype from getting through port 80.

Re: rules for skype

[Leonardo Rodrigues Magalhães]

    Skype is able of connect using squid throw HTTPS connections, which 
makes it harder to block using squid ACLs, as when HTTPS is used, squid 
sees nothing only the hostname that you're connecting and NOT the whole URL.


    Sincerily,
    Leonardo Rodrigues


Seferovic Edvin escreveu:

>DEVIL_MODE = 1;
>You can stop it by blocking incoming high ports ;) 
>
>DEVIL_MODE = 0;
>Why should you block all incoming high ports? Hm.. maybe you want to allow
>only web traffic that comes and goes through a squid proxy ;)
>
>Regards,
>
>Edvin Seferovic
>
>-----Original Message-----
>From: netfilter-bounces@lists.netfilter.org
>[mailto:netfilter-bounces@lists.netfilter.org] On Behalf Of Taylor, Grant
>Sent: Montag, 02. Mai 2005 00:00
>To: netfilter@lists.netfilter.org
>Subject: Re: rules for skype
>
>  
>
>>iptables -A FORWARD -p tcp --dport SKYPEPORT -j ACCEPT
>>    
>>
>
><devilish @^*% eating grin> He, Skype does not have a port (per say).
></devilish @^*% eating grin>
>
>Skype will use just about any port that it can use (all the standards you
>would think for internet traffic) to connect to any ""super node that it can
>connect to.  unfortunately what qualifies as a Super Node is any node /
>computer that is running Skype that is directly connected to the internet
>with out a firewall that would inhibit other systems from connecting
>directly to it.  Do a Google for "Skype Protocol" and see what you find.  I
>have a PDF on it at the office that I'd be happy to send you.  (If you want
>this PDF I'll find the URL to it and post it to the list or email
>individually as I don't think the list would like a PDF sent to it.)  The
>only way that I've heard to even slow down Skype is to force it to pass
>through a proxy, beyond that nothing, that I have heard of or read about,
>will stop it.
>
>
>
>Grant. . . .
>
>
>
>
>  
>

Re: rules for skype

[Daniel Lopes]

Leonardo Rodrigues Magalhães schrieb:
> 
>    Skype is able of connect using squid throw HTTPS connections, which 
> makes it harder to block using squid ACLs, as when HTTPS is used, squid 
> sees nothing only the hostname that you're connecting and NOT the whole 
> URL.
> 
> 
>    Sincerily,
>    Leonardo Rodrigues
> 
> 
> Seferovic Edvin escreveu:
> 
>> DEVIL_MODE = 1;
>> You can stop it by blocking incoming high ports ;)
>> DEVIL_MODE = 0;
>> Why should you block all incoming high ports? Hm.. maybe you want to 
>> allow
>> only web traffic that comes and goes through a squid proxy ;)
>>
>> Regards,
>>
>> Edvin Seferovic
>>
>> -----Original Message-----
>> From: netfilter-bounces@lists.netfilter.org
>> [mailto:netfilter-bounces@lists.netfilter.org] On Behalf Of Taylor, Grant
>> Sent: Montag, 02. Mai 2005 00:00
>> To: netfilter@lists.netfilter.org
>> Subject: Re: rules for skype
>>
>>  
>>
>>> iptables -A FORWARD -p tcp --dport SKYPEPORT -j ACCEPT
>>>   
>>
>>
>> <devilish @^*% eating grin> He, Skype does not have a port (per say).
>> </devilish @^*% eating grin>
>>
>> Skype will use just about any port that it can use (all the standards you
>> would think for internet traffic) to connect to any ""super node that 
>> it can
>> connect to.  unfortunately what qualifies as a Super Node is any node /
>> computer that is running Skype that is directly connected to the internet
>> with out a firewall that would inhibit other systems from connecting
>> directly to it.  Do a Google for "Skype Protocol" and see what you 
>> find.  I
>> have a PDF on it at the office that I'd be happy to send you.  (If you 
>> want
>> this PDF I'll find the URL to it and post it to the list or email
>> individually as I don't think the list would like a PDF sent to it.)  The
>> only way that I've heard to even slow down Skype is to force it to pass
>> through a proxy, beyond that nothing, that I have heard of or read about,
>> will stop it.
>>
>>
>>
>> Grant. . . .
>>
>>
Yes this 443 port thing is the only reason why it seems that Skype is 
unstoppable. You could block connections to that port but then you would 
also cut off https based websites :(.

Re: rules for skype

[Taylor, Grant]

> Yes this 443 port thing is the only reason why it seems that Skype is 
> unstoppable. You could block connections to that port but then you would 
> also cut off https based websites :(.

Would it be possible to ACL via Squid (or the likes) to control what host a client is initiating an SSL connection to?  I have not done much filtering on the application (HTTP) level beyond blocking basic requests for a domain on standard HTTP (80).  I wonder if it would be possible to write an extension for Squid that would not allow connections to IP addresses that don't (forward) resolve back to what they reverse resolve to.  I'm grasping at straws here, but then again Skype is going to be hard to stop.



Grant. . . .

RE: rules for skype

[Seferovic Edvin]

I think that you can stop ALL https connections with squid.. if you want of
course... but then, I dont know if there is such way as you described it. A
very good ACL implementation is squidGuard.

But hey.. why do you want to stop skype?

Regards,

Edvin Seferovic

-----Original Message-----
From: netfilter-bounces@lists.netfilter.org
[mailto:netfilter-bounces@lists.netfilter.org] On Behalf Of Taylor, Grant
Sent: Montag, 02. Mai 2005 16:41
To: netfilter@lists.netfilter.org
Subject: Re: rules for skype

> Yes this 443 port thing is the only reason why it seems that Skype is 
> unstoppable. You could block connections to that port but then you would 
> also cut off https based websites :(.

Would it be possible to ACL via Squid (or the likes) to control what host a
client is initiating an SSL connection to?  I have not done much filtering
on the application (HTTP) level beyond blocking basic requests for a domain
on standard HTTP (80).  I wonder if it would be possible to write an
extension for Squid that would not allow connections to IP addresses that
don't (forward) resolve back to what they reverse resolve to.  I'm grasping
at straws here, but then again Skype is going to be hard to stop.





Grant. . . .

rules for skype

[varun_saa]

Hello,
     My server is on Mandriva 10.1
eth0 is WAN with static IP connected to 512K DSL
eth1 is LAN - 192.168.0.0/24 and 192.168.21.0/24

I am doing a nat/masq on eth0.

Some of clients are going to using Skype.

Any rules to be included for skype ?

Thanks

Varun

Re: rules for skype

[Askar]

It depends, if you have "iptables -P FORWARD DROP" at the top of your
rules set then you have to allow skype ports (any) with something like
this

iptables -A FORWARD -p tcp --dport SKYPEPORT -j ACCEPT

and if you have ""iptables -P FORWARD ACCEPT" , then you don't have to
do anything fanncy.

regards

Askar

On 5/1/05, varun_saa@vsnl.net <varun_saa@vsnl.net> wrote:
> Hello,
>      My server is on Mandriva 10.1
> eth0 is WAN with static IP connected to 512K DSL
> eth1 is LAN - 192.168.0.0/24 and 192.168.21.0/24
> 
> I am doing a nat/masq on eth0.
> 
> Some of clients are going to using Skype.
> 
> Any rules to be included for skype ?
> 
> Thanks
> 
> Varun
> 
> 


-- 
I love deadlines. I like the whooshing sound they make as they fly by.
Douglas Adams

Re: rules for skype

[Taylor, Grant]

> iptables -A FORWARD -p tcp --dport SKYPEPORT -j ACCEPT

<devilish @^*% eating grin> He, Skype does not have a port (per say). </devilish @^*% eating grin>

Skype will use just about any port that it can use (all the standards you would think for internet traffic) to connect to any ""super node that it can connect to.  unfortunately what qualifies as a Super Node is any node / computer that is running Skype that is directly connected to the internet with out a firewall that would inhibit other systems from connecting directly to it.  Do a Google for "Skype Protocol" and see what you find.  I have a PDF on it at the office that I'd be happy to send you.  (If you want this PDF I'll find the URL to it and post it to the list or email individually as I don't think the list would like a PDF sent to it.)  The only way that I've heard to even slow down Skype is to force it to pass through a proxy, beyond that nothing, that I have heard of or read about, will stop it.



Grant. . . .

RE: rules for skype

[Seferovic Edvin]

DEVIL_MODE = 1;
You can stop it by blocking incoming high ports ;) 

DEVIL_MODE = 0;
Why should you block all incoming high ports? Hm.. maybe you want to allow
only web traffic that comes and goes through a squid proxy ;)

Regards,

Edvin Seferovic

-----Original Message-----
From: netfilter-bounces@lists.netfilter.org
[mailto:netfilter-bounces@lists.netfilter.org] On Behalf Of Taylor, Grant
Sent: Montag, 02. Mai 2005 00:00
To: netfilter@lists.netfilter.org
Subject: Re: rules for skype

> iptables -A FORWARD -p tcp --dport SKYPEPORT -j ACCEPT

<devilish @^*% eating grin> He, Skype does not have a port (per say).
</devilish @^*% eating grin>

Skype will use just about any port that it can use (all the standards you
would think for internet traffic) to connect to any ""super node that it can
connect to.  unfortunately what qualifies as a Super Node is any node /
computer that is running Skype that is directly connected to the internet
with out a firewall that would inhibit other systems from connecting
directly to it.  Do a Google for "Skype Protocol" and see what you find.  I
have a PDF on it at the office that I'd be happy to send you.  (If you want
this PDF I'll find the URL to it and post it to the list or email
individually as I don't think the list would like a PDF sent to it.)  The
only way that I've heard to even slow down Skype is to force it to pass
through a proxy, beyond that nothing, that I have heard of or read about,
will stop it.



Grant. . . .

Re: rules for skype

[Mogens Valentin]

Taylor, Grant wrote:
>> iptables -A FORWARD -p tcp --dport SKYPEPORT -j ACCEPT
> 
> 
> <devilish @^*% eating grin> He, Skype does not have a port (per say). 
> </devilish @^*% eating grin>
> 
> Skype will use just about any port that it can use (all the standards 
> you would think for internet traffic) to connect to any ""super node 
> that it can connect to.  unfortunately what qualifies as a Super Node is 
> any node / computer that is running Skype that is directly connected to 
> the internet with out a firewall that would inhibit other systems from 
> connecting directly to it.

No wonder, since Skype is based upon the methods as used for Kazaa.
Damn thing to deny too, as is many other sharing apps...
AFAIR I found it slightly easier blocking such using ipchains explicit 
in/out/forward rules, than with iptables and ESTABLISHED,RELATED rules.

> Do a Google for "Skype Protocol" and see 
> what you find.  I have a PDF on it at the office that I'd be happy to 
> send you.  (If you want this PDF I'll find the URL to it and post it to 
> the list or email individually as I don't think the list would like a 
> PDF sent to it.)  The only way that I've heard to even slow down Skype 
> is to force it to pass through a proxy, beyond that nothing, that I have 
> heard of or read about, will stop it.

Mind adding me to that list? If so, thanks a lot!

-- 
Kind regards,
Mogens Valentin

Re: rules for skype

[Daniel Lopes]

Mogens Valentin schrieb:
> Taylor, Grant wrote:
> 
>>> iptables -A FORWARD -p tcp --dport SKYPEPORT -j ACCEPT
>>
>>
>>
>> <devilish @^*% eating grin> He, Skype does not have a port (per say). 
>> </devilish @^*% eating grin>
>>
>> Skype will use just about any port that it can use (all the standards 
>> you would think for internet traffic) to connect to any ""super node 
>> that it can connect to.  unfortunately what qualifies as a Super Node 
>> is any node / computer that is running Skype that is directly 
>> connected to the internet with out a firewall that would inhibit other 
>> systems from connecting directly to it.
> 
> 
> No wonder, since Skype is based upon the methods as used for Kazaa.
> Damn thing to deny too, as is many other sharing apps...
> AFAIR I found it slightly easier blocking such using ipchains explicit 
> in/out/forward rules, than with iptables and ESTABLISHED,RELATED rules.
> 
>> Do a Google for "Skype Protocol" and see what you find.  I have a PDF 
>> on it at the office that I'd be happy to send you.  (If you want this 
>> PDF I'll find the URL to it and post it to the list or email 
>> individually as I don't think the list would like a PDF sent to it.)  
>> The only way that I've heard to even slow down Skype is to force it to 
>> pass through a proxy, beyond that nothing, that I have heard of or 
>> read about, will stop it.
> 
> 
> Mind adding me to that list? If so, thanks a lot!
> 
Mhm Kazaa can be blocked by IPP2P for example. But Skype´s payload is 
encrypted what makes it way more difficult or impossible. But what about 
NUFW doesn´t it authenticate upon application? I would like to receive a 
copy of that PDF too please :).

Re: rules for skype

[Taylor, Grant]

> ... I have a PDF on it at the office that I'd be happy to 
> send you.  (If you want this PDF I'll find the URL to it and post it to 
> the list or email individually as I don't think the list would like a 
> PDF sent to it.)...