All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Taylor, Grant" <gtaylor@riverviewtech.net>
To: netfilter@lists.netfilter.org
Subject: Re: [SPAM] Re: rules for skype
Date: Mon, 02 May 2005 12:09:59 -0500	[thread overview]
Message-ID: <42765EE7.7040205@riverviewtech.net> (raw)
In-Reply-To: <BAY107-DAV7808D3CABD608123BCF2CB7270@phx.gbl>

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


  reply	other threads:[~2005-05-02 17:09 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20050502150901.DAEF39E9F4@dd6816.kasserver.com>
2005-05-02 15:36 ` rules for skype Daniel Lopes
2005-05-02 15:58   ` Taylor, Grant
2005-05-02 16:48     ` Taylor, Grant
2005-05-02 17:01     ` Deepak Seshadri
2005-05-02 17:09       ` Taylor, Grant [this message]
2005-05-02 17:42         ` Deepak Seshadri
2005-05-02 19:33           ` [SPAM] " Taylor, Grant
2005-05-03  7:17       ` Victor Yeo
2005-05-03  7:50         ` John A. Sullivan III
2005-07-13  2:52           ` Fajar Priyanto
2005-07-13 10:53             ` Daniel Lopes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=42765EE7.7040205@riverviewtech.net \
    --to=gtaylor@riverviewtech.net \
    --cc=netfilter@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.