Re: Bittorrent - utorrent

[Tremaine Lea <focus-ids () ddiction com>]

On 19-Mar-07, at 8:39 AM, David J. Bianco wrote:

> Ove Dalgård Hansen wrote:
> > I am in a bit of trouble,
> >
> > On a network where i am configuring IDS - using ASA5510 + SSM  
> > module, we try to deny access to Bittorrent downloads - it  
> > consumes quite a bit of bandwith and is not allowed by the  
> > company's policy.
> > We try to filter bittorrent which succedes - but the utorrent  
> > changes protocol and goes by the SSL port 443 and thereby  
> > circumvent the IDS, since its not possible to see the encrypted  
> > traffic.
> >
> > Does anyone out there have a good idea of how i am to solve the  
> > issue?
>
> Hi, Ove.  I see that you've gotten quite a few responses, but I  
> have to
> say that they all seem pretty impractical.  Decrypting SSL?  Um...


Uhm what?  I think I've provided a pretty clear description of how  
it's done, and it provides a lot more benefit to the administrator  
than just looking for encrypted P2P traffic.



> Anyway, it turns out that P2P traffic is actually pretty easy to  
> detect
> if you have the right monitoring tools.  Most of the other posters  
> here
> have been assuming that you'd want to use a signature based IDS like
> snort or some gateway content inspection device, but by now you've  
> already
> figured out that they don't work well for this.

Snort or a similar IDS/IPS would indeed be a poor choice for dealing  
with is particular problem.  A content inspection appliance however  
is a different story and is ideally suited to this.




> The trick is to look for intrinsic characteristics of P2P traffic.
> Specifically, BitTorrent works by contacting a lot of different peers
> to download small portions of the larger file.  What you need to do is
> to look for individual systems on your network that talk to lots of
> different externals hosts.  The more hosts they talk to, the more  
> likely
> that they're running some P2P application.  Most BitTorrent transfers
> stand out quite clearly when you create a list of your own hosts,  
> sorted
> by the number of external hosts they've talked to in the last 24  
> hours.
>
> The advantages to this are that it doesn't matter if they use SSL or
> not, since you're not reading the bits, just the session data records.
> Also, they can change ports all they like, since you're only concerned
> with the number of unique IPs they talk to.




> There are two disadvantages, though.  First, you have to set up some
> infrastructure to monitor session records.  I'm using Sguil, so I
> already have this information handy in a SQL database, but you  
> could use
> something like NetFlow or SFlow if your routers support it.  There
> are also a number of standalone tools like Argus or SANCP that would
> do the job, albeit with a bit of scripting work on your part.
>
> The second disadvantage is that you can't tell *exactly* what P2P  
> traffic
> you're seeing.  I do sometimes see Skype traffic, for example, that
> looks a bit like BitTorrent when you're just seeing the session  
> records.
> However, for larger transfers (TV shows, movies, ISOs), the BitTorrent
> stands out because it often involves a thousands of unique IPs, more
> than would be expected in a typical Skype session.

Those are not insignificant disadvantages, and is certainly not  
scalable.  If you deal with a small network this may work just fine.   
If you have ~10,000 users and a lot of infrastructure it's not nearly  
so feasible.



> Anyway, I hope this helps answer your question.  This is a good  
> example
> of how using the right tool for the job can really simplify things.
> Not all monitoring is done via signature matching!
>
>         David



Effective monitoring that results in an audit trail you can take to  
HR requires more than a 'best guess'  or 'highly educated guess'.   
You need to be able to prove it.  You also need to be able to prevent  
it.  A combination of a technical solution and an enforceable user  
policy should be preferred.

I could make some pretty educated guesses about traffic patterns on  
my network using Peakflow and similar tools.  And they are often a  
good starting point for a lot of things.  Ultimately though, we want  
to be able to see inside *all* of the traffic on the network we  
administrate.

If the traffic can't be inspected and isn't part of an otherwise  
authorized connection, it should be dropped.

Tremaine Lea
Network Security Consultant
------------------------------------------------------------------------
Test Your IDS

Is your IDS deployed correctly?
Find out quickly and easily by testing it
with real-world attacks from CORE IMPACT.
Go to http://www.coresecurity.com/index.php5?module=Form&action=impact&campaign=intro_sfw
to learn more.
------------------------------------------------------------------------