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

Joel Esler (jesler) jesler at ...3865...
Wed Jul 9 16:44:09 EDT 2014


On Jul 9, 2014, at 4:38 PM, 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...<mailto:jamie.riden at ...2420...>> wrote:
On 2 July 2014 18:20, Charlie Egan <chas5873 at ...2420...<mailto:chas5873 at ...253...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...<mailto:jamie at ...3509...> / jamie.riden at ...3371...20...<mailto:jamie.riden at ...2420...>

Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
Snort-sigs mailing list
Snort-sigs at lists.sourceforge.net

Please visit http://blog.snort.org for the latest news about Snort!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-sigs/attachments/20140709/1be3db2f/attachment.html>

More information about the Snort-sigs mailing list