Blocking Kazaa traffic by ISP

I know it is very diffcult to block Kazaa traffic at the client side, it is
possible to ask the ISP the block the Kazaa traffic from passing to our
internet router.

 

:I know it is very diffcult to block Kazaa traffic at the client side, it is
ossible to ask the ISP the block the Kazaa traffic from passing to our
:internet router.

You can always -ask-, but whether they can or will do it is a different
matter. They will likely suggest that you should install a firewall
and do it yourself.


The relevant PIX entries that we have are:

: Kazaa and Morpheus -- and audiogalaxy too
access-list acl-Ginside deny ip any 64.245.58.0 255.255.255.0
access-list acl-Ginside deny ip any 64.245.59.0 255.255.255.0
access-list acl-Ginside deny ip any host 213.248.107.10
access-list acl-Ginside deny ip any 213.248.112.0 255.255.255.0
access-list acl-Ginside deny udp any any eq 1214
access-list acl-Ginside deny tcp any any eq 1214


This probably just slows people down, and doesn't help on the
peer-to-peer equivilents that use port 80. That's why we monitor
our logs.


If KaZaa and kin are noticable problems in your organization then:

1) Make sure you have a security policy that deals with the situation
(one with some teeth!);
2) Be prepared to monitor traffic; and
3) Consider installing a product from Packetteer.

 

12.3 code with NBAR will inspect for KAZAA and drop traffic, even if it is
port 80

 

Just a question. If you have policy in your company that users are not
allowed to use Kazaa, isn't it much more simple to use products like
(Peregrine Asset...something) which has agents that scan for software on
clinets? Doing that on regular basis, you can see who installed Kazaa or any
illegal software and proceed with further actions...

Ivan

 

Actually, the best solution is have a company policy regarding the the use
of this stuff, with a harsh penalty. Then just monitor it. The problem with
the PIX or router, with ACLs, is that in many cases, Kazaa and similar
programs can get around this using HTTP, or tunneling it via SOCKS. A good
monitoring program, like an IDS or other solution (even Cisco's NBAR can be
set up to do this) should flag down the rule-breakers and then you can take
the appropiate action. Also, there are scanning programs you can run on
people's desktops to look for this stuff--you might want to do this once a
week or month when they log in to verify the sterility of their desktops.

Cheers!
--

Richard A. Deal

Visit my home page at http://home.cfl.rr.com/dealgroup/

Author of CCNA Cisco Certified Network Associate Study Guide (Exam 640-801),
Cisco PIX Firewalls, CCNA Secrets Revealed!, CCNP Remote Access Exam Prep,
CCNP Switching Exam Cram, and CCNP Cisco LAN Switch Configuration Exam Cram

Cisco Test Prep author for QuizWare, providing the most comprehensive Cisco
exams on the market.

 

:Just a question. If you have policy in your company that users are not
:allowed to use Kazaa, isn't it much more simple to use products like
Peregrine Asset...something) which has agents that scan for software on
:clinets? Doing that on regular basis, you can see who installed Kazaa or any
:illegal software and proceed with further actions...

Scanning to see what software is installed can be tricky from a
policy standpoint.


The Canada Charter of Rights and Freedoms (the equivilent of the US
Constitution) contains a clause that "Everyone has the right to be
secure against unreasonable search and seizure". In the context of the
section that is in, that constrains government searches without a
search warrant, but does not apply to the same extent to private
companies (or, rather, what is "unreasonable" differs between
Government and private companies.)

The place I work happens to be part of the Canadian Federal Government,
and because of that, the full Charter clause is considered to apply:
our actions with regards to our employees have to be those permitted
between Government and Person, instead of the wider actions permitted
between Employer and Employee in private companies.

At the moment, no-one is quite sure whether using software to search
employee hard disks for forbidden programs counts as "unreasonable
search" within the meaning of the Charter. There are arguments on both
sides. Our lawyers advise us that any kind of -manual- search for such
programs would, more likely than not, be considered "unreasonable";
mechanical searches for -particular- programs are less certain.

The general policy here is that if I or the other systems
administrators happen to notice forbidden files or network activity in
the course of our regular duties, then we are to take appropriate
action; that we need a Good Reason to do routine searches over peoples'
desktop systems [and we should clear these in advance]; and that
targetting -particular- individuals for compliance searches is almost
always beyond our authority.


The policy leaves me free to examine the firewall logs (which are in IP
address/port terms), because summary information about -what- was
contacted is not considered to be a "communication" under wiretap laws;
but I had to specifically disable URL logging because the details of
the URLs can sometimes disclose the "communication" itself (think of
form parameters placed after a GET.) If I do a reverse lookup on a host
visited, and I see it is stolenxxxses-n-cardz.com or kazaa.com then I
can proceed under our usage policies; but if the IP address resolves to
a virtual hoster -mostly- known for hosting stuff we Don't Want Around
Here, I must presume that the user was accessing something acceptable
there.

 

Trying to block it is often difficult because when they can't get
their preferred port they'll try others. One helpfull suggestion is
not to block it but instead rate limit it to just a trickle.

An interesting alternative of Filtering by DNS can be found at
http://www.holland-consulting.net/tech/imblock.html

 

We deal with the search issue by having regularly scheduled software audits
for license compliance - a good idea in and of itself. Amazing what
well-meaning and law-abiding people will do with licensed software. If you
find anything that hasn't been purchased or is demonstrably not for business
purposes, out it goes.

Jonathan Wilson

 

Yep, we have similar policy and our link is much, much less congested than
before...

Ivan

 

The problem, as others have pointed out, is that kazaa, and many other
similar peer2peer protocols will use any port it can get its hands on.

Packeteer's Packetshaper (www.packeteer.com) gets around the problem as it
identifies traffic up at the application level... so it doesn't care what
port it uses, it see that it is Kazaa (or eDonkey or whatever). It will also
let you see who it is that is using that protocol.

And yes, as someone else already said, rather that stop the connection from
happening (which just makes it try again, on another port.... then on
another port....), you allow the connection, but at, say, a mere 256 bps! At
that speed, it connects quickly, but the user will soon give up.... and they
daren't complain, coz they aren't supposed to be doing it in the first place


Paul Blitz
Centia Ltd

 

You might want to check out P2PWall:

http://sourceforge.net/projects/p2pwall/


--Colin

 

Have you tried Browse Control www.browsecontrol.com this will block Kazaa

Regards
Divyesh

 

You could use the NBAR PDLM feature (PDLM download from Cisco.com) on a
Cisco
router to drop matching P2P traffic.

http://www.cisco.com/en/US/products/sw/iosswrel/ps1838/products_feature_guide09186a0080134add.html

class-map match-any p2p
match protocol fasttrack
match protocol gnutella
match protocol napster
match protocol http url \.hash=*
match protocol http url /.hash=*
match protocol kazaa2
!
!
policy-map p2p
class p2p
police cir 8000 bc 1500 be 1500
conform-action drop
exceed-action drop

And on your ethernet interface(s):

interface FastEthernet0/0
ip nbar protocol-discovery
service-policy input p2p
!
interface FastEthernet0/1
ip nbar protocol-discovery
service-policy output p2p
!

--Andrew

 

Im not quite sure why you would do it that way. If your customer wants
you to block the traffic, then block it. But its more effective to
allow a reasonable amount of bandwidth for p2p unless you have
something in your service agreement that explicitly disallows the use
of specific products. As an ISP you are a distributor of bandwidth, Im
not sure why many think that they can dictate what you can do with the
bandwidth bandwidth you are paying for. People dont sign up (usually)
for just email and im and surfing. They sign up for internet access.
P2p is internet access, so blocking it or functionally disabling it as
you suggest seems a violation of what you are advertising that you do.

Most of our customers (ISPs mostly) use our Bandwidth Management
appliance to control p2p, but most allocate a chunk just for p2p, say
128kbs, so that transfers work but they are just very slow. At least
this way you are not arbitrarily deciding what your customers can do.

And a packetshaper is a very expensive solution for something like
this. You can get something equally effective for a lot less.

Dennis
Emerging Technologies
Bandwidth Management Appliances
www.etinc.com

 

|> |> > I know it is very diffcult to block Kazaa traffic at the client side, it
|> is
|> > possible to ask the ISP the block the Kazaa traffic from passing to our
|> > internet router.


|> another port....), you allow the connection, but at, say, a mere 256 bps! At

|Im not quite sure why you would do it that way. If your customer wants
|you to block the traffic, then block it. But its more effective to
|allow a reasonable amount of bandwidth for p2p unless you have
|something in your service agreement that explicitly disallows the use

|not sure why many think that they can dictate what you can do with the
|bandwidth bandwidth you are paying for.

Dennis,

You have misread the original posting and the response you were
replying to.

If the original poster *was* the ISP, then the original poster would
not have to *ask* the ISP to do anything. Thus the original poster is
at a business which had taken a business decision about what they will
or will not allow on their company equipment.


|People dont sign up (usually)
|for just email and im and surfing. They sign up for internet access.


People should not sign up at a -job- for internet access.


|P2p is internet access, so blocking it or functionally disabling it as
|you suggest seems a violation of what you are advertising that you do.

Ah? The original poster is from centia.co.uk . What does
centia advertise that it does that you feel is being violated?
Which of their corporate emphasises are they not fulfilling?
"application deployment on demand", "secure application management",
"application appliances", "application performance", or
"professional services" ?


:Most of our customers (ISPs mostly) use our Bandwidth Management
:appliance to control p2p, but most allocate a chunk just for p2p, say
:128kbs, so that transfers work but they are just very slow. At least
:this way you are not arbitrarily deciding what your customers can do.

I don't think Centia is in the business of arbitrary deciding what
its customers can do -- but its customers are businesses (not individuals)
and those businesses are -asking- that P2P be blocked. Should
Centia be refusing such requests from its customers on the grounds
that some of the customer's employees might want to do P2P and
you feel that companies should not have the authority to limit what
their employees do with company resources?

 

One problem I see with this is it may still get you company involved
in the lawsuits filed by the RIAA. Fasttrack clients (Kazaa) transfer
their list of shared files to a supernode when they log on. It isn't a
tremdous amount of data. From that point, you shared files are
advertised and search at the supernode...not the client. This means
that even though they can't get the bandwidth to transfer files out,
they may still succesfully advertise their shares out, which could be
found by the RIAA.

I know a company that is using this trickle config and the lawyers of
the RIAA just contacted them because their IP address shared out 1000
files. Because the company NATs behind a single IP for Internet access
it could have been any of thousands of users... but the company in the
end is responsible. SO while you are controlling bandwidth, you are
not elimianting liability.

DiGiTAL_ViNYL (no email)