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

Charlie Egan chas5873 at ...2420...
Wed Jul 9 16:38:15 EDT 2014


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-sigs/attachments/20140709/2eb595d1/attachment.html>


More information about the Snort-sigs mailing list