Detecting BitTorrent

[Elof via Argus-info]

I second that.

I let argus log to a file which is moved to a 48h directory every 5 
minutes. Most analysis is done near real-time, with the possibility to 
compare the same time yesterday and the day before.

A cron job then move >48h old 5min-files to archive/ and append 
it to hourly files there. (I used to have daily files, but storing them hourly 
is better when you need to do post analysis over many days but a specific 
hour, or simply using 'ls -l' to see roughly at what time the mirrored 
traffic suddenly vanished or increased).

/Elof

On Wed, 11 Nov 2015, Harry Hoffman via Argus-info wrote:

> So, Carter will be able to speak to this authoritatively but I wanted to add one additional recommendation: rotate more frequently then daily.
>
> We used to do it hourly but switched to 5min rotations. The benefit here is that you can search very small individual files and get results quickly but you can also run the client tools over a grouping of files to get results for longer durations.
>
> Cheers,
> Harry
>
>
> From:  Argus-info <argus-info-bounces+hhoffman=ip-solutions.net at lists.andrew.cmu.edu> on behalf of Carter Bullard via Argus-info <argus-info at lists.andrew.cmu.edu>
> Reply-To:  Carter Bullard <carter at qosient.com>
> Date:  Tuesday, November 10, 2015 at 10:04 AM
> To:  Argus-info <argus-info at lists.andrew.cmu.edu>
> Subject:  Re: [ARGUS] Detecting BitTorrent
>
> All excellent advice !!  Port number may have been NAT'd so may not be a good indicator, they didn't say if it was the src or dst port ...  but you want to look none-the-less.   Time is the best clue in this case, and limiting searches to a small time range should help a lot.  If the archive file is huge, and you have MySQL, running rasqltimeindex.1 may be helpful.  But that is a heavy tool, so best to go through the gargantuan file once with ra.1 to generate a subset of records using a time filter (say 5m before and 5m after) and then work with that sub file to find what you're looking for, and ratop is a good tool to browse that smaller file, using 'vi' navigation, '/' searching, and display filtering.
>
> Also, the notification of the rights violation maybe generated by the end system advertising availability to the file, not actual file transfer, so, ..., maybe more fruitful to look for bit torrent banners in the flow records, if you were collecting user data.  "-e torrent" or just "-e bit" may find mesh insertion and advertisement flows, which are more important than the file ...
>
> Since you, as a bit torrent node may only contribute a part of the file, the flows may not be as big as you expect ????
>
> Carter
>
>
> Carter Bullard • CTO
> 150 E 57th Street Suite 12D
> New York, New York 10022-2795
> Phone +1.212.588.9133 • Mobile +1.917.497.9494
>
> On Nov 10, 2015, at 8:40 AM, John Gerth via Argus-info <argus-info at lists.andrew.cmu.edu> wrote:
>
> Remember that a large transfer can take awhile to complete and is
> will comprise more than one argus record if it spans multiple
> reporting intervals.  Tbat said, if you use the "-t" and "port" options
> as recommended previously, you'll be focused on the right time
> interval and will see a series of large transfers involving
> the suspect local IP.
>
>
> -----Oprindelig meddelelse-----
> Fra: Argus-info [mailto:argus-info-bounces+jesper.skou.jensen=statens-it.dk at lists.andrew.cmu.edu] På vegne af Monah Baki via Argus-info
> Sendt: 10. november 2015 04:44
> Til: Harry Hoffman
> Cc: Argus
> Emne: Re: [ARGUS] Detecting BitTorrent
>
> Hi Harry,
>
> We are running Argus off a span port monitoring our internal core
> switches, so we do see our internal IP flows.
>
> Is there a way to just display downloads > 700MB??
>
> Our logs are rotated on a daily basis, so we are looking at a 9GB size file
>
> Thanks
> Monah
>
>
>
>