[Snort-sigs] Could someone test a rule for me please?

Jamie Riden jamie.riden at ...2420...
Wed Jul 9 17:01:52 EDT 2014


OK, what I've got in this packet - uTorrent - is:

|13|BitTorrent protocol |0000000000100005|

The last 8 bytes are "reserved" and were meant to be zero according to
my first reference, but are clearly not.

So your first rule should have matched. Is the
flow:to_server;established bit working properly? I can't remember the
UDP stuff of the top of my head.

cheers,
Jamie

On 9 July 2014 21:38, Charlie Egan <chas5873 at ...2420...> wrote:
> I'll look into the checksum issue, cheers Joel.
>
> Thanks Jamie also for the reply, much appreciated. Out of curiosity, I'm
> assuming if the |13| wasn't included in the rule, that there's no reason why
> it shouldn't work? I'm assuming it's just added in to make it more specific?
> Also could you please tell me why you've doubled up the 0000's to 16 rather
> than 8 which were in my initial rule?
>
> Also could somebody explain to me what the "depth:20" means from the rule
> taken from the BitTorrent community ruleset? I know that depth means how
> many bytes into a packet Snort should look for the specific pattern, but how
> was the depth of 20 determined in the first place? How am I able to find out
> myself that information? I'm guessing my WireShark screenshot doesn't
> provide enough information to get the '20' that's in the rule.
>
> Sorry for all the questions, I'm trying to get to grips with all this but
> it's taking some time!
>
> Cheers guys.
>
>
> On Wed, Jul 9, 2014 at 9:25 PM, Jamie Riden <jamie.riden at ...2420...> wrote:
>>
>> On 2 July 2014 18:20, Charlie Egan <chas5873 at ...2420...> wrote:
>> > Hi guys,
>> >
>> > I'm trying to test out a rule, however I can't test it out since the
>> > only
>> > computer that I have access to Snort on is at my University campus. The
>> > rule
>> > is to detect the BitTorrent P2P handshake, and unfortunately the P2P
>> > ports
>> > on the campus are blocked so I have no way of testing it - torrents just
>> > get
>> > stuck on the 'connecting to peers' stage. My laptops broken as of a
>> > couple
>> > of weeks ago and I unfortunately can't test it out anywhere else.
>> >
>> > The rule is;
>> >
>> > alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"P2P BitTorrent
>> > handshake"; flow:to_server,established; content:"BitTorrent
>> > protocol|0000
>> > 0000|"; classtype:policy-violation; sid:1000006; rev:1;)
>>
>> Looks like
>>
>> |13|BitTorrent protocol|0000000000000000|
>>
>> should match to me, given the spec. I don't have time to do a pcap
>> test right now I'm sorry - maybe in an hour or two.
>>
>> "pstrlen: string length of <pstr>, as a single raw byte
>> pstr: string identifier of the protocol
>> reserved: eight (8) reserved bytes. All current implementations use
>> all zeroes. Each bit in these bytes can be used to change the behavior
>> of the protocol. An email from Bram suggests that trailing bits should
>> be used first, so that leading bits may be used to change the meaning
>> of trailing bits.
>> info_hash: 20-byte SHA1 hash of the info key in the metainfo file.
>> This is the same info_hash that is transmitted in tracker requests.
>> peer_id: 20-byte string used as a unique ID for the client. This is
>> usually the same peer_id that is transmitted in tracker requests (but
>> not always e.g. an anonymity option in Azureus).
>>
>> In version 1.0 of the BitTorrent protocol, pstrlen = 19, and pstr =
>> "BitTorrent protocol"."
>>
>> --
>> Jamie Riden / jamie at ...3509... / jamie.riden at ...2420...
>> http://uk.linkedin.com/in/jamieriden
>
>



-- 
Jamie Riden / jamie at ...3509... / jamie.riden at ...2420...
http://uk.linkedin.com/in/jamieriden




More information about the Snort-sigs mailing list