diff options
| author | Ermal Luçi <eri@pfsense.org> | 2008-08-02 22:24:45 +0000 |
|---|---|---|
| committer | Ermal Luçi <eri@pfsense.org> | 2008-08-02 22:24:45 +0000 |
| commit | 4ae45b1093b1a2fda98b263a5cffce9689ad109a (patch) | |
| tree | c770e69156a527cbe1deb11a288dc3315c9423ca /usr/local/share | |
| parent | b5a7edb1ca42023606cde872cb8b5339d3b9837a (diff) | |
| download | pfsense-4ae45b1093b1a2fda98b263a5cffce9689ad109a.zip pfsense-4ae45b1093b1a2fda98b263a5cffce9689ad109a.tar.gz | |
Add protocol definitions needed by ipfw-classifyd. Basically they are copied from the ipfw-classifyd pfPort which inherits them from l7-filter project on sf.net.
Diffstat (limited to 'usr/local/share')
109 files changed, 2235 insertions, 0 deletions
diff --git a/usr/local/share/protocols/100bao.pat b/usr/local/share/protocols/100bao.pat new file mode 100644 index 0000000..66bb5c9 --- /dev/null +++ b/usr/local/share/protocols/100bao.pat @@ -0,0 +1,11 @@ +# 100bao - a Chinese P2P protocol/program - http://www.100bao.com +# Pattern attributes: ok veryfast fast +# Protocol groups: p2p +# Wiki: http://www.protocolinfo.org/wiki/100Bao +# +# Pattern written by www.routerclub.com's wsgtrsys. +# The author of this pattern says it works, but this is unconfirmed. + +100bao +^\x01\x01\x05\x0a + diff --git a/usr/local/share/protocols/aim.pat b/usr/local/share/protocols/aim.pat new file mode 100644 index 0000000..e26a3c4 --- /dev/null +++ b/usr/local/share/protocols/aim.pat @@ -0,0 +1,27 @@ +# AIM - AOL instant messenger (OSCAR and TOC) +# Pattern attributes: good slow notsofast +# Protocol groups: chat proprietary +# Wiki: http://www.protocolinfo.org/wiki/AIM +# +# Usually runs on port 5190 +# +# This may also match ICQ traffic. +# +# This pattern has been tested and is believed to work well. + +aim +# See http://gridley.res.carleton.edu/~straitm/final (and various other places) +# The first bit matches OSCAR signon and data commands, but not sure what +# \x03\x0b matches, but it works apparently. +# The next three bits match various parts of the TOC signon process. +# The third one is the magic number "*", then 0x01 for "signon", then up to four +# bytes ("up to" because l7-filter strips out nulls) which contain a sequence +# number (2 bytes) the data length (2 more) and 3 nulls (which don't count), +# then 0x01 for the version number (not sure if there ever has been another +# version) +# The fourth one is a command string, followed by some stuff, then the +# beginning of the "roasted" password + +# This pattern is too slow! + +^(\*[\x01\x02].*\x03\x0b|\*\x01.?.?.?.?\x01)|flapon|toc_signon.*0x diff --git a/usr/local/share/protocols/aimwebcontent.pat b/usr/local/share/protocols/aimwebcontent.pat new file mode 100644 index 0000000..af34d5b --- /dev/null +++ b/usr/local/share/protocols/aimwebcontent.pat @@ -0,0 +1,9 @@ +# AIM web content - ads/news content downloaded by AOL Instant Messenger +# Pattern attributes: good notsofast notsofast +# Protocol groups: chat document_retrieval proprietary +# Wiki: http://www.protocolinfo.org/wiki/AIM +# +# This pattern has been tested and is believed to work well. + +aimwebcontent +user-agent:aim/ diff --git a/usr/local/share/protocols/applejuice.pat b/usr/local/share/protocols/applejuice.pat new file mode 100644 index 0000000..8158bc6 --- /dev/null +++ b/usr/local/share/protocols/applejuice.pat @@ -0,0 +1,11 @@ +# Apple Juice - P2P filesharing - http://www.applejuicenet.de +# Pattern attributes: great veryfast fast +# Protocol groups: p2p +# Wiki: http://www.protocolinfo.org/wiki/AppleJuice +# +# This pattern has been tested with the Linux version (version +# 0,29,142,229). It matches search reqests and file transfers. + +applejuice +# this pattern extracted from ipp2p, by Eicke Friedrich. +^ajprot\x0d\x0a diff --git a/usr/local/share/protocols/ares.pat b/usr/local/share/protocols/ares.pat new file mode 100644 index 0000000..2e89a90 --- /dev/null +++ b/usr/local/share/protocols/ares.pat @@ -0,0 +1,62 @@ +# Ares - P2P filesharing - http://aresgalaxy.sf.net +# Pattern attributes: good veryfast fast undermatch +# Protocol groups: p2p open_source +# Wiki: http://www.protocolinfo.org/wiki/Ares + +# This pattern catches only client-server connect messages. This is +# sufficient for blocking, but not for shaping, since it doesn't catch +# the actual file transfers (see below). + +# Original pattern by Brandon Enright <bmenrigh at the server known as ucsd.edu> + +# This pattern has been tested with Ares 1.8.8.2998. + +ares +# regular expression madness: "[]Z]" means ']' or 'Z'. +^\x03[]Z].?.?\x05$ + +# It appears that the general packet format is: +# - Two byte little endian integer giving the data length +# - One byte packet type +# - data +# +# Login packets (TCP) have the following format: +# - \x03\x00 (the length appears to always be 3) +# - \x5a - The login packet type. +# The source code suggests that for supernodes \x5d is used instead. +# - Three more bytes. I don't know the meaning of these, but for me they +# are always \x06\x06\x05 (in Ares 1.8.8.2998). From the comments in IPP2P, +# it seems that they are not always exactly that, but seem to always end in +# \x05. +# +# Search packets have the following format: +# - Two byte little endian integer giving the data length +# A single two letter word make this \x0a +# The biggest I could get it was \x4f +# - Packet type = \x09 +# - One byte document type: +# - "all" = 00 +# - "audio" = 01 +# - "software" = 03 +# - "video" = 05 +# - "document" = 06 +# - "image" = 07 +# - "other" = 08 +# - \x0f - I don't know what this means, but it is always this for me +# - Two bytes of unknown meaning that change +# - Some number search words: +# - \x14 - I don't know what this means, but it is always this for me +# - One byte length of the first search word +# Between 2 and \x14 in my tests with Ares 1.8.8.2998 +# It ignores single letter words and truncates ones longer than \x14 +# - Two bytes of unknown meaning that change +# - The search word (not null terminated) +# This was all investigated by searching for strings in "all". Searches +# can also be performed in "title" and "author". I'm not going to +# bother to research these because I new realize that searches are done +# on the same TCP connection as the login packets, so there is no need +# to match them separately. +# +# File transfers appear to be encrypted or at least obfuscated. (The +# files themselves, at least, are not transmitted in the clear.) I +# haven't found any patterns. diff --git a/usr/local/share/protocols/armagetron.pat b/usr/local/share/protocols/armagetron.pat new file mode 100644 index 0000000..fb4cc1e --- /dev/null +++ b/usr/local/share/protocols/armagetron.pat @@ -0,0 +1,11 @@ +# Armagetron Advanced - open source Tron/snake based multiplayer game +# Pattern attributes: good slow notsofast +# Protocol groups: open_source game +# Wiki: http://protocolinfo.org/wiki/Armagetron + +# Contributed to protocolinfo.org, possibly by joda.bot, who says "The +# filter matches the initial transfer of configuration data. Very early +# versions might not transfer the CYCLE_ Settings (before 0.2.5.x)." + +armagetron +YCLC_E|CYEL diff --git a/usr/local/share/protocols/battlefield1942.pat b/usr/local/share/protocols/battlefield1942.pat new file mode 100644 index 0000000..1a4d9c0 --- /dev/null +++ b/usr/local/share/protocols/battlefield1942.pat @@ -0,0 +1,13 @@ +# Battlefield 1942 - An EA game +# Pattern attributes: ok veryfast fast +# Protocol groups: game proprietary +# Wiki: http://www.protocolinfo.org/wiki/Battlefield_1942 +# +# Contributed by Myles Uyema <mylesuyema AT gmail.com> +# +# This pattern has only been tested by one person. + +# tested on two original EA battlefield 1942 servers +# matches the first two packets of joining a server +battlefield1942 +^\x01\x11\x10\|\xf8\x02\x10\x40\x06 diff --git a/usr/local/share/protocols/battlefield2.pat b/usr/local/share/protocols/battlefield2.pat new file mode 100644 index 0000000..088714c --- /dev/null +++ b/usr/local/share/protocols/battlefield2.pat @@ -0,0 +1,25 @@ +# Battlefield 2 - An EA game. +# Pattern attributes: ok slow notsofast +# Protocol groups: game proprietary +# Wiki: http://www.protocolinfo.org/wiki/Battlefield_2 +# +# This pattern is unconfirmed except implicitly by a comment on protocolinfo. + +battlefield2 +# gameplay|account-login|server browsing/information +# See http://protocolinfo.org/wiki/Battlefield_2 +# Can we put a ^ on the last branch? If so, nosofast --> veryfast + +# 193.85.217.35 on protocolinfo says: +# The first part of the pattern, \x11\x20\x01\xa0\x98\x11, has to be +# modified for different version of Battlefield 2. The gameplay part of +# pattern for BF2 v1.4 is \x11\x20\x01\x30\xb9\x10\x11, and for BF2 +# v1.41 is \x11\x20\x01\x50\xb9\x10\x11 +# +# Rather than put all of those in, I've just gone with "...?" in the +# middle. + +^(\x11\x20\x01...?\x11|\xfe\xfd.?.?.?.?.?.?(\x14\x01\x06|\xff\xff\xff))|[]\x01].?battlefield2 + +# Pattern prior to 193.85.217.35's comment on protocolinfo: +#^(\x11\x20\x01\xa0\x98\x11|\xfe\xfd.?.?.?.?.?.?(\x14\x01\x06|\xff\xff\xff))|[]\x01].?battlefield2 diff --git a/usr/local/share/protocols/battlefield2142.pat b/usr/local/share/protocols/battlefield2142.pat new file mode 100644 index 0000000..6794cff --- /dev/null +++ b/usr/local/share/protocols/battlefield2142.pat @@ -0,0 +1,13 @@ +# Battlefield 2142 - An EA game. +# Pattern attributes: ok fast fast +# Protocol groups: proprietary game +# Wiki: http://protocolinfo.org/wiki/Battlefield_2142 + +# Submitted by Telsin. Not confirmed. + +battlefield2142 +# gameplay|account-login|server browsing/information +# Can't put a ^ on the last branch: it fails to match if you do. +# This branch seems to matter very rarely, though +^(\x11\x20\x01\x90\x50\x64\x10|\xfe\xfd.?.?.?\x18|[\x01\\].?battlefield2) + diff --git a/usr/local/share/protocols/bgp.pat b/usr/local/share/protocols/bgp.pat new file mode 100644 index 0000000..d7985c0 --- /dev/null +++ b/usr/local/share/protocols/bgp.pat @@ -0,0 +1,18 @@ +# BGP - Border Gateway Protocol - RFC 1771 +# Pattern attributes: ok veryfast fast +# Protocol groups: networking ietf_draft_standard +# Wiki: http://www.protocolinfo.org/wiki/BGP +# +# This pattern is UNTESTED. + +bgp +# "After a transport protocol connection is established, the first +# message sent by each side is an OPEN message." +# "If the Type of the message is OPEN, or if the Authentication Code used +# in the OPEN message of the connection is zero, then the Marker must be +# all ones." +# Then the 2 byte length field, then the 1 byte type field (1 = OPEN). +# Then the BGP version: 3 was RFC'd in 1991, 4 was RFC'd in 1995. +# Could keep going, but that should be sufficient. +^\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff..?\x01[\x03\x04] + diff --git a/usr/local/share/protocols/biff.pat b/usr/local/share/protocols/biff.pat new file mode 100644 index 0000000..7df399a --- /dev/null +++ b/usr/local/share/protocols/biff.pat @@ -0,0 +1,15 @@ +# Biff - new mail notification +# Pattern attributes: good veryfast fast undermatch overmatch +# Protocol groups: mail +# Wiki: http://www.protocolinfo.org/wiki/Biff +# +# Usually runs on port 512 +# +# This pattern is completely untested. + +biff +# This is a rare case where we will specify a $ (end of line), since +# this is the entirety of the communication. +# something that looks like a username, an @, a number. +# won't catch usernames that have strange characters in them. +^[a-z][a-z0-9]+@[1-9][0-9]+$ diff --git a/usr/local/share/protocols/bittorrent.pat b/usr/local/share/protocols/bittorrent.pat new file mode 100644 index 0000000..e5aa5bc --- /dev/null +++ b/usr/local/share/protocols/bittorrent.pat @@ -0,0 +1,27 @@ +# Bittorrent - P2P filesharing / publishing tool - http://www.bittorrent.com +# Pattern attributes: good slow notsofast undermatch +# Protocol groups: p2p open_source +# Wiki: http://www.protocolinfo.org/wiki/Bittorrent +# +# This pattern has been tested and is believed to work well. +# It will, however, not work on bittorrent streams that are encrypted, since +# it's impossible to match encrypted data (unless the encryption is extremely +# weak, like rot13 or something...). + +bittorrent + +# Does not attempt to match the HTTP download of the tracker +# 0x13 is the length of "bittorrent protocol" +# Second two bits match UDP wierdness +# Next bit matches something Azureus does +# Ditto on the next bit. Could also match on "user-agent: azureus", but that's in the next +# packet and perhaps this will match multiple clients. + +# Recently the ^ was removed from before \x13. I think this was an accident, +# so I have restored it. + +# This is not a valid GNU basic regular expression (but that's ok). +^(\x13bittorrent protocol|azver\x01$|get /scrape\?info_hash=)|d1:ad2:id20:|\x08'7P\)[RP] + +# This pattern is "fast", but won't catch as much +#^(\x13bittorrent protocol|azver\x01$|get /scrape\?info_hash=) diff --git a/usr/local/share/protocols/chikka.pat b/usr/local/share/protocols/chikka.pat new file mode 100644 index 0000000..c7259a7 --- /dev/null +++ b/usr/local/share/protocols/chikka.pat @@ -0,0 +1,16 @@ +# Chikka - SMS service which can be used without phones - http://chikka.com +# Pattern attributes: good veryfast fast superset +# Protocol groups: proprietary chat +# Wiki: http://www.protocolinfo.org/wiki/Chikka + +# Tested with Chikka Javalite on 14 Jan 2007. +# The login and chat use the same TCP connection. + +# "Kamusta" means "Hello" in Tagalog, apparently, so that will probably +# stay the same. I've only seen v1.2, but I've given it some leeway for +# past and future versions. + +# Chikka uses CIMD as part of the login process, see cimd.pat + +chikka +^CTPv1.[123] Kamusta.*\x0d\x0a$ diff --git a/usr/local/share/protocols/cimd.pat b/usr/local/share/protocols/cimd.pat new file mode 100644 index 0000000..6df274f --- /dev/null +++ b/usr/local/share/protocols/cimd.pat @@ -0,0 +1,18 @@ +# Computer Interface to Message Distribution, an SMSC protocol by Nokia +# Pattern attributes: good notsofast notsofast subset +# Protocol groups: proprietary chat +# Wiki: http://www.protocolinfo.org/wiki/CIMD + +# I don't know whether CIMD is ever found by itself in a TCP connection. +# I have only seen it myself as part of the Chikka login process, in +# which the second and third packets (at least) are CIMD. So I am not +# using a '^' at the beginning. +# +# This pretty well explains the pattern: +# http://en.wikipedia.org/w/index.php?title=CIMD&oldid=42707583 +# However, Chikka does NOT terminate the last field with a tab. +# +# Tested with Chikka Javalite on 14 Jan 2007. + +cimd +\x02[0-4][0-9]:[0-9]+.*\x03$ diff --git a/usr/local/share/protocols/ciscovpn.pat b/usr/local/share/protocols/ciscovpn.pat new file mode 100644 index 0000000..c15725e --- /dev/null +++ b/usr/local/share/protocols/ciscovpn.pat @@ -0,0 +1,10 @@ +# Cisco VPN - VPN client software to a Cisco VPN server +# Pattern attributes: ok veryfast fast +# Protocol groups: remote_access proprietary +# Wiki: http://www.protocolinfo.org/wiki/Cisco_VPN +# +# This pattern contributed by Myles Uyema <myles AT uyema.net> + +ciscovpn +^\x01\xf4\x01\xf4 + diff --git a/usr/local/share/protocols/citrix.pat b/usr/local/share/protocols/citrix.pat new file mode 100644 index 0000000..1215c22 --- /dev/null +++ b/usr/local/share/protocols/citrix.pat @@ -0,0 +1,11 @@ +# Citrix ICA - proprietary remote desktop application - http://citrix.com +# Pattern attributes: marginal notsofast notsofast +# Protocol groups: remote_access proprietary +# Wiki: http://www.protocolinfo.org/wiki/Citrix +# +# This pattern is UNTESTED. + +# This is based on decode_citrix in dsniff 2.4. + +citrix +\x32\x26\x85\x92\x58 diff --git a/usr/local/share/protocols/counterstrike-source.pat b/usr/local/share/protocols/counterstrike-source.pat new file mode 100644 index 0000000..94aa07a --- /dev/null +++ b/usr/local/share/protocols/counterstrike-source.pat @@ -0,0 +1,41 @@ +# Counterstrike (using the new "Source" engine) - network game +# Pattern attributes: good veryfast fast +# Protocol groups: game proprietary +# Wiki: http://www.protocolinfo.org/wiki/Counter-Strike +# +# By adam.randazzoATgmail.com + +counterstrike-source +^\xff\xff\xff\xff.*cstrikeCounter-Strike + +# These games use Steam, which is developed by Valve Software. +# +# This was based off of the following captured data from ethereal: +# --Source-- +# 0000 00 11 09 2a a8 79 00 13 10 2c 3f d7 08 00 45 20 ...*.y...,?...E +# 0010 00 72 b9 f6 00 00 6b 11 b6 78 18 0e 04 cc c0 a8 .r....k..x...... +# 0020 01 6a 69 87 04 65 00 5e 01 ac ff ff ff ff 49 07 .ji..e.^......I. +# 0030 54 4a 27 73 20 50 6c 61 63 65 20 6f 66 20 50 61 TJ's Place of Pa +# 0040 69 6e 00 64 65 5f 70 69 72 61 6e 65 73 69 00 63 in.de_piranesi.c +# 0050 73 74 72 69 6b 65 00 43 6f 75 6e 74 65 72 2d 53 strike.Counter-S +# 0060 74 72 69 6b 65 3a 20 53 6f 75 72 63 65 00 dc 00 trike: Source... +# 0070 08 10 06 64 77 00 00 31 2e 30 2e 30 2e 31 38 00 ...dw..1.0.0.18. +# 0080 +# +# --1.6-- +# 0000 00 11 09 2a a8 79 00 13 10 2c 3f d7 08 00 45 00 ...*.y...,?...E. +# 0010 00 8e c4 1a 00 00 76 11 b3 85 08 09 02 fa c0 a8 ......v......... +# 0020 01 14 69 91 04 37 00 7a c9 90 ff ff ff ff 6d 38 ..i..7.z......m8 +# 0030 2e 39 2e 32 2e 32 35 30 3a 32 37 30 32 35 00 49 .9.2.250:27025.I +# 0040 50 20 2d 20 43 6c 61 6e 20 73 65 72 76 65 72 00 P - Clan server. +# 0050 64 65 5f 64 75 73 74 32 00 63 73 74 72 69 6b 65 de_dust2.cstrike +# 0060 00 43 6f 75 6e 74 65 72 2d 53 74 72 69 6b 65 00 .Counter-Strike. +# 0070 0a 0c 2f 64 77 00 01 77 77 77 2e 63 6f 75 6e 74 ../dw..www.count +# 0080 65 72 2d 73 74 72 69 6b 65 2e 6e 65 74 00 00 00 er-strike.net... +# 0090 01 00 00 00 00 9e f7 0a 00 01 00 00 ............ + + +# Old pattern. (Adam Randazzo says "CS 1.6 and CS: Source are the +# only two versions that are playable on the Internet since Valve +# disabled the WON system in favor of steam.") +# cs .*dl.www.counter-strike.net diff --git a/usr/local/share/protocols/cvs.pat b/usr/local/share/protocols/cvs.pat new file mode 100644 index 0000000..d6cf503 --- /dev/null +++ b/usr/local/share/protocols/cvs.pat @@ -0,0 +1,13 @@ +# CVS - Concurrent Versions System +# Pattern attributes: good veryfast fast +# Protocol groups: version_control open_source +# Wiki: http://www.protocolinfo.org/wiki/CVS + +cvs + +# Matches pserver login. AUTH is for actually starting the protocol +# VERIFICATION is for authenticating without starting the protocols +# and GSSAPI is for using security services such as kerberos. +# http://www.loria.fr/~molli/cvs/doc/cvsclient_3.html + +^BEGIN (AUTH|VERIFICATION|GSSAPI) REQUEST\x0a diff --git a/usr/local/share/protocols/dayofdefeat-source.pat b/usr/local/share/protocols/dayofdefeat-source.pat new file mode 100644 index 0000000..1a90b4d --- /dev/null +++ b/usr/local/share/protocols/dayofdefeat-source.pat @@ -0,0 +1,10 @@ +# Day of Defeat: Source - game (Half-Life 2 mod) - http://www.valvesoftware.com +# Pattern attributes: good veryfast fast +# Protocol groups: game proprietary +# Wiki: http://www.protocolinfo.org/wiki/Day_of_Defeat:Source +# +# By Clayton Macleod <cherry twist at gmail dot com> + +dayofdefeat-source +^\xff\xff\xff\xff.*dodDay of Defeat + diff --git a/usr/local/share/protocols/dhcp.pat b/usr/local/share/protocols/dhcp.pat new file mode 100644 index 0000000..9594ea4 --- /dev/null +++ b/usr/local/share/protocols/dhcp.pat @@ -0,0 +1,35 @@ +# DHCP - Dynamic Host Configuration Protocol - RFC 1541 +# Pattern attributes: good veryfast fast +# Protocol groups: networking ietf_draft_standard +# Wiki: http://www.protocolinfo.org/wiki/DHCP +# +# Usually runs on ports 67 (server) and 68 (client) +# +# Also matches BOOTP (Bootstrap Protocol (RFC 951)) in the case that +# the "vendor specific options" are used (these options were made standard +# for DHCP). +# +# This pattern is lightly tested. + +dhcp +^[\x01\x02][\x01- ]\x06.*c\x82sc + +# Let's break that down: +# +# (\x01|\x02) is for BOOTREQUEST or BOOTREPLY +# Is there a demand for doing these seperately? The Packeteer does. +# +# [\x01-\x20] is for any of the hardware address types listed at +# (http://www.iana.org/assignments/arp-parameters) and hopefully faster +# ethernets too (100, 1000 and 10000mb) as well (do they share the 10mb +# number?). +# +# \x06 for "hardware address length = 6 bytes". Does anyone use other lengths +# these days? If so, this pattern won't match it as it stands. +# +# .* covers the hops, xid, secs, flags, ciaddr, yiaddr, siaddr, giaddr, +# chaddr, sname and file fields. While this can't really be "any number +# of characters" long, it doesn't seem worth it to count. +# Can we make this more specific by restricting the number of hops or seconds? +# +# 0x63825363 is the "magic cookie" which begins the DHCP options field. diff --git a/usr/local/share/protocols/directconnect.pat b/usr/local/share/protocols/directconnect.pat new file mode 100644 index 0000000..41631f7 --- /dev/null +++ b/usr/local/share/protocols/directconnect.pat @@ -0,0 +1,13 @@ +# Direct Connect - P2P filesharing - http://www.neo-modus.com +# Pattern attributes: good fast fast +# Protocol groups: p2p +# Wiki: http://www.protocolinfo.org/wiki/Direct_Connect +# +# Direct Connect "hubs" listen on port 411 +# http://www.dcpp.net/wiki/ +# I've verified that this pattern can be used to limit direct connect +# bandwidth using DC:PRO 0.2.3.149R11. + +directconnect +# client-to-client handshake|client-to-hub login, hub speaking|client-to-hub login, client speaking +^(\$mynick |\$lock |\$key ) diff --git a/usr/local/share/protocols/dns.pat b/usr/local/share/protocols/dns.pat new file mode 100644 index 0000000..5bc0ac0 --- /dev/null +++ b/usr/local/share/protocols/dns.pat @@ -0,0 +1,62 @@ +# DNS - Domain Name System - RFC 1035 +# Pattern attributes: great slow fast +# Protocol groups: networking ietf_internet_standard +# Wiki: http://www.protocolinfo.org/wiki/DNS + +# Thanks to Sebastien Bechet <s.bechet AT av7.net> for TLD detection +# improvements + +# While RFC 2181 says "Occasionally it is assumed that the Domain Name +# System serves only the purpose of mapping Internet host names to data, +# and mapping Internet addresses to host names. This is not correct, the +# DNS is a general (if somewhat limited) hierarchical database, and can +# store almost any kind of data, for almost any purpose.", we will assume +# just that, because that represents the vast majority of DNS traffic. + +# The packet starts with a 2 byte random ID number and 2 bytes of flags that +# aren't easy to match on. + +# The first thing that is matchable is QDCOUNT, the number of queries. +# Despite the fact that you can apparently ask for up to 65535 +# things at a time, usually you only ask for one and I doubt you ever ask for +# zero. Let's allow up to two, just in case (even though I can't find any +# situation that generates more than one). + +# Next comes the ANCOUNT, NSCOUNT, and ARCOUNT fields, which could be null +# or some smallish number, not matchable except by length (up to 6) + +# The next matchable thing is the query address. The first byte indicates the +# length of the first part of the address, which is limited to 63 (0x3F == '?'). +# The next byte has to be a letter (for domain names) or number (for reverse lookups). +# Then there can be an combination of +# letters, digits, hyphens, and 0x01-0x3F length markers. +# Then we check for the presence of a top-level-domain at some later point. +# This is indicated by a 0x02-0x06 and at least two letters, followed by no +# more than four more letters. +# Note that this will miss a very few queries that are for a TLD alone. +# i.e. "host museum" (195.7.77.17) +# +# http://www.icann.org/tlds http://www.iana.org/cctld/cctld-whois.htm + +# next is the QTYPE field, which has valid values 1-16 (although this +# could probably be restricted further since many are rare) and \x1c for +# IPv6 (and maybe more?). It should follow immediately after the TLD +# (and some stripped-out nulls) + +# next is QCLASS, which has valid values 1-4 and 255, except 2 is never used. +# I'm not sure if 3 and 4 are used, so I'll include them. 1=Internet 255=any + +# If we wanted to match queries and responses separately, there could be +# more specifics after this for the responses. + +dns +# here's a sane way of doing it +^.?.?.?.?[\x01\x02].?.?.?.?.?.?[\x01-?][a-z0-9][\x01-?a-z]*[\x02-\x06][a-z][a-z][fglmoprstuvz]?[aeop]?(um)?[\x01-\x10\x1c][\x01\x03\x04\xFF] + +# This way assumes that TLDs are any alpha string 2-6 characters long. +# If TLDs are added, this is a good fallback. +#^.?.?.?.?[\x01\x02].?.?.?.?.?.?[\x01-?][a-z0-9][\x01-?a-z]*[\x02-\x06][a-z][a-z][a-z]?[a-z]?[a-z]?[a-z]?[\x01-\x10][\x01\x03\x04\xFF] + +# If you have more processing power than me, you can substitute this for +# the [a-z][a-z][a-z]?[a-z]?[a-z]?[a-z]? +#(aero|arpa|biz|com|coop|edu|gov|info|int|mil|museum|name|net|org|pro|arpa|ac|ad|ae|af|ag|ai|al|am|an|ao|aq|ar|as|at|au|aw|az|ba|bb|bd|be|bf|bg|bh|bi|bj|bm|bn|bo|br|bs|bt|bv|bw|by|bz|ca|cc|cd|cf|cg|ch|ci|ck|cl|cm|cn|co|cr|cu|cv|cx|cy|cz|de|dj|dk|dm|do|dz|ec|ee|eg|eh|er|es|et|fi|fj|fk|fm|fo|fr|ga|gd|ge|gf|gg|gh|gi|gl|gm|gn|gp|gq|gr|gs|gt|gu|gw|gy|hk|hm|hn|hr|ht|hu|id|ie|il|im|in|io|iq|ir|is|it|je|jm|jo|jp|ke|kg|kh|ki|km|kn|kp|kr|kw|ky|kz|la|lb|lc|li|lk|lr|ls|lt|lu|lv|ly|ma|mc|md|mg|mh|mk|ml|mm|mn|mo|mp|mq|mr|ms|mt|mu|mv|mw|mx|my|mz|na|nc|ne|nf|ng|ni|nl|no|np|nr|nu|nz|om|pa|pe|pf|pg|ph|pk|pl|pm|pn|pr|ps|pt|pw|py|qa|re|ro|ru|rw|sa|sb|sc|sd|se|sg|sh|si|sj|sk|sl|sm|sn|so|sr|st|sv|sy|sz|tc|td|tf|tg|th|tj|tk|tm|tn|to|tp|tr|tt|tv|tw|tz|ua|ug|uk|um|us|uy|uz|va|vc|ve|vg|vi|vn|vu|wf|ws|ye|yt|yu|za|zm|zw) diff --git a/usr/local/share/protocols/doom3.pat b/usr/local/share/protocols/doom3.pat new file mode 100644 index 0000000..ef59ee7 --- /dev/null +++ b/usr/local/share/protocols/doom3.pat @@ -0,0 +1,9 @@ +# Doom 3 - computer game +# Pattern attributes: good veryfast fast +# Protocol groups: game proprietary +# Wiki: http://www.protocolinfo.org/wiki/Doom +# +# Thanks to Clayton Macleod (cherrytwist at gmail.com). + +doom3 +^\xff\xffchallenge diff --git a/usr/local/share/protocols/edonkey.pat b/usr/local/share/protocols/edonkey.pat new file mode 100644 index 0000000..50a072c --- /dev/null +++ b/usr/local/share/protocols/edonkey.pat @@ -0,0 +1,36 @@ +# eDonkey2000 - P2P filesharing - http://edonkey2000.com and others +# Pattern attributes: good veryfast fast overmatch +# Protocol groups: p2p +# Wiki: http://www.protocolinfo.org/wiki/EDonkey +# +# Tested recently (April/May 2006) with eMule 0.47a and eDonkey2000 1.4 +# and a long time ago with something else. +# +# In addition to matching what you might expect, this matches much of +# what eMule does when you tell it to only connect to the KAD network. +# I don't quite know what to make of this. + +# Thanks to Matt Skidmore <fox AT woozle.org> + +edonkey + +# http://gd.tuwien.ac.at/opsys/linux/sf/p/pdonkey/eDonkey-protocol-0.6 +# +# In addition to \xe3, \xc5 and \xd4, I see a lot of \xe5. +# As of April 2006, I also see some \xe4. +# +# God this is a mess. What an irritating protocol. +# This will match about 2% of streams with random data in them! +# (But fortunately much fewer than 2% of streams that are other protocols. +# You can test this with the data in ../testing/) + +^[\xc5\xd4\xe3-\xe5].?.?.?.?([\x01\x02\x05\x14\x15\x16\x18\x19\x1a\x1b\x1c\x20\x21\x32\x33\x34\x35\x36\x38\x40\x41\x42\x43\x46\x47\x48\x49\x4a\x4b\x4c\x4d\x4e\x4f\x50\x51\x52\x53\x54\x55\x56\x57\x58[\x60\x81\x82\x90\x91\x93\x96\x97\x98\x99\x9a\x9b\x9c\x9e\xa0\xa1\xa2\xa3\xa4]|\x59................?[ -~]|\x96....$) + +# matches everything and too much +# ^(\xe3|\xc5|\xd4) + +# ipp2p essentially uses "\xe3....\x47", which doesn't seem at all right to me. + +# bandwidtharbitrator uses +# e0.*@.*6[a-z].*p$|e0.*@.*[a-z]6[a-z].*p0$|e.*@.*[0-9]6.*p$|emule|edonkey +# no comments to explain what all the mush is, of course... diff --git a/usr/local/share/protocols/fasttrack.pat b/usr/local/share/protocols/fasttrack.pat new file mode 100644 index 0000000..c821ae4 --- /dev/null +++ b/usr/local/share/protocols/fasttrack.pat @@ -0,0 +1,22 @@ +# FastTrack - P2P filesharing (Kazaa, Morpheus, iMesh, Grokster, etc) +# Pattern attributes: good slow notsofast +# Protocol groups: p2p +# Wiki: http://www.protocolinfo.org/wiki/Fasttrack +# +# Tested with Kazaa Lite Resurrection 0.0.7.6F +# +# This appears to match the download connections well, but not the search +# connections (I think they are encrypted :-( ). + +fasttrack +# while this is a valid http request, this will be caught because +# the http pattern matches the response (and therefore the next packet) +# Even so, it's best to put this match earlier in the chain. +# http://cvs.berlios.de/cgi-bin/viewcvs.cgi/gift-fasttrack/giFT-FastTrack/PROTOCOL?rev=HEAD&content-type=text/vnd.viewcvs-markup + +# This pattern is kinda slow, but not too bad. +^get (/.download/[ -~]*|/.supernode[ -~]|/.status[ -~]|/.network[ -~]*|/.files|/.hash=[0-9a-f]*/[ -~]*) http/1.1|user-agent: kazaa|x-kazaa(-username|-network|-ip|-supernodeip|-xferid|-xferuid|tag)|^give [0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]?[0-9]?[0-9]? + +# This isn't much faster: +#^get (/.download/.*|/.supernode.|/.status.|/.network.*|/.files|/.hash=[0-9a-f]*/.*) http/1.1|user-agent: kazaa|x-kazaa(-username|-network|-ip|-supernodeip|-xferid|-xferuid|tag)|^give [0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]?[0-9]?[0-9]? + diff --git a/usr/local/share/protocols/finger.pat b/usr/local/share/protocols/finger.pat new file mode 100644 index 0000000..b2b59d8 --- /dev/null +++ b/usr/local/share/protocols/finger.pat @@ -0,0 +1,14 @@ +# Finger - User information server - RFC 1288 +# Pattern attributes: good slow slow undermatch overmatch +# Protocol groups: ietf_draft_standard +# Wiki: http://www.protocolinfo.org/wiki/Finger +# +# Usually runs on port 79 +# +# This pattern is lightly tested. + +finger +# The first matches the client request, which should look like a username. +# The second matches the usual UNIX reply (but remember that they are +# allowed to say whatever they want) +^[a-z][a-z0-9\-_]+|login: [\x09-\x0d -~]* name: [\x09-\x0d -~]* Directory: diff --git a/usr/local/share/protocols/freenet.pat b/usr/local/share/protocols/freenet.pat new file mode 100644 index 0000000..626acb9 --- /dev/null +++ b/usr/local/share/protocols/freenet.pat @@ -0,0 +1,9 @@ +# Freenet - Anonymous information retrieval - http://freenetproject.org +# Pattern attributes: poor veryfast fast +# Protocol groups: p2p document_retrieval open_source +# Wiki: http://www.protocolinfo.org/wiki/Freenet + +freenet +# Freenet is intentionally hard to identify... +# This is empirical, only tested on one computer, and unlikely to work anymore. +^\x01[\x08\x09][\x03\x04] diff --git a/usr/local/share/protocols/ftp.pat b/usr/local/share/protocols/ftp.pat new file mode 100644 index 0000000..a7f9e0e --- /dev/null +++ b/usr/local/share/protocols/ftp.pat @@ -0,0 +1,45 @@ +# FTP - File Transfer Protocol - RFC 959 +# Pattern attributes: great notsofast fast +# Protocol groups: document_retrieval ietf_internet_standard +# Wiki: http://protocolinfo.org/wiki/FTP +# +# Usually runs on port 21. Note that the data stream is on a dynamically +# assigned port, which means that you will need the FTP connection +# tracking module in your kernel to usefully match FTP data transfers. +# +# This pattern is well tested. +# +# Handles the first two things a server should say: +# +# First, the server says it's ready by sending "220". Most servers say +# something after 220, even though they don't have to, and it usually +# includes the string "ftp" (l7-filter is case insensitive). This +# includes proftpd, vsftpd, wuftpd, warftpd, pureftpd, Bulletproof FTP +# Server, and whatever ftp.microsoft.com uses. Almost all servers use only +# ASCII printable characters between the "220" and the "FTP", but non-English +# ones might use others. +# +# The next thing the server sends is a 331. All the above servers also +# send something including "password" after this code. By default, we +# do not match on this because it takes another packet and is more work +# for regexec. + +ftp +# by default, we allow only ASCII +^220[\x09-\x0d -~]*ftp + +# This covers UTF-8 as well +#^220[\x09-\x0d -~\x80-\xfd]*ftp + +# This allows any characters and is about 4x faster than either of the above +# (which are about the same as each other) +#^220.*ftp + +# This is much slower +#^220[\x09-\x0d -~]*ftp|331[\x09-\x0d -~]*password + +# This pattern is more precise, but takes longer to match. (3 packets vs. 1) +#^220[\x09-\x0d -~]*\x0d\x0aUSER[\x09-\x0d -~]*\x0d\x0a331 + +# same as above, but slightly less precise and only takes 2 packets. +#^220[\x09-\x0d -~]*\x0d\x0aUSER[\x09-\x0d -~]*\x0d\x0a diff --git a/usr/local/share/protocols/gkrellm.pat b/usr/local/share/protocols/gkrellm.pat new file mode 100644 index 0000000..2acf73b --- /dev/null +++ b/usr/local/share/protocols/gkrellm.pat @@ -0,0 +1,12 @@ +# Gkrellm - a system monitor - http://gkrellm.net +# Pattern attributes: great veryfast fast +# Protocol groups: monitoring open_source +# Wiki: http://www.protocolinfo.org/wiki/Gkrellm +# +# This pattern has been tested and is believed to work well. +# Since this is not anything resembling a published protocol, it may change without +# warning in new versions of gkrellm. + +gkrellm +# tested with gkrellm 2.2.7 +^gkrellm [23].[0-9].[0-9]\x0a$ diff --git a/usr/local/share/protocols/gnucleuslan.pat b/usr/local/share/protocols/gnucleuslan.pat new file mode 100644 index 0000000..2a106f4 --- /dev/null +++ b/usr/local/share/protocols/gnucleuslan.pat @@ -0,0 +1,9 @@ +# GnucleusLAN - LAN-only P2P filesharing +# Pattern attributes: good notsofast notsofast +# Protocol groups: p2p open_source +# Wiki: http://www.protocolinfo.org/wiki/GnucleusLAN +# +# This pattern has been tested and is believed to work well. + +gnucleuslan +gnuclear connect/[\x09-\x0d -~]*user-agent: gnucleus [\x09-\x0d -~]*lan: diff --git a/usr/local/share/protocols/gnutella.pat b/usr/local/share/protocols/gnutella.pat new file mode 100644 index 0000000..57a76de --- /dev/null +++ b/usr/local/share/protocols/gnutella.pat @@ -0,0 +1,33 @@ +# Gnutella - P2P filesharing +# Pattern attributes: good notsofast notsofast +# Protocol groups: p2p open_source +# Wiki: http://www.protocolinfo.org/wiki/Gnutella +# +# This should match both Gnutella and "Gnutella2" ("Mike's protocol") +# +# Various clients use this protocol including Mactella, Shareaza, +# GTK-gnutella, Gnucleus, Gnotella, LimeWire, iMesh and BearShare. +# +# This is tested with gtk-gnutella and Shareaza. + +# http://www.gnutella2.com/tiki-index.php?page=UDP%20Transceiver +# http://rfc-gnutella.sf.net/ +# http://www.gnutella2.com/tiki-index.php?page=Gnutella2%20Specification +# http://en.wikipedia.org/wiki/Shareaza + +gnutella + +# The first part matches UDP messages - All start with "GND", then have +# a flag byte which is either \x00, \x01 or \x02, then two sequence bytes +# that can be anything, then a fragment number, which must start at 1. +# The rest matches TCP first client message or first server message (in case +# we can't see client messages). Some parts of this are empirical rather than +# document based. Assumes version is between 0.0 and 2.9. (usually is +# 0.4 or 0.6). I'm guessing at many of the user-agents. +# The last bit is emprical and probably only matches Limewire. +^(gnd[\x01\x02]?.?.?\x01|gnutella connect/[012]\.[0-9]\x0d\x0a|get /uri-res/n2r\?urn:sha1:|get /.*user-agent: (gtk-gnutella|bearshare|mactella|gnucleus|gnotella|limewire|imesh)|get /.*content-type: application/x-gnutella-packets|giv [0-9]*:[0-9a-f]*/|queue [0-9a-f]* [1-9][0-9]?[0-9]?\.[1-9][0-9]?[0-9]?\.[1-9][0-9]?[0-9]?\.[1-9][0-9]?[0-9]?:[1-9][0-9]?[0-9]?[0-9]?|gnutella.*content-type: application/x-gnutella|...................?lime) + +# Needlessly precise, at the expense of time +#^(gnd[\x01\x02]?.?.?\x01|gnutella connect/[012]\.[0-9]\x0d\x0a|get /uri-res/n2r\?urn:sha1:|get /[\x09-\x0d -~]*user-agent: (gtk-gnutella|bearshare|mactella|gnucleus|gnotella|limewire|imesh)|get /[\x09-\x0d -~]*content-type: application/x-gnutella-packets|giv [0-9]*:[0-9a-f]*/|queue [0-9a-f]* [1-9][0-9]?[0-9]?\.[1-9][0-9]?[0-9]?\.[1-9][0-9]?[0-9]?\.[1-9][0-9]?[0-9]?:[1-9][0-9]?[0-9]?[0-9]?|gnutella[\x09-\x0d -~]*content-type: application/x-gnutella|..................lime) + + diff --git a/usr/local/share/protocols/goboogy.pat b/usr/local/share/protocols/goboogy.pat new file mode 100644 index 0000000..2cc93da --- /dev/null +++ b/usr/local/share/protocols/goboogy.pat @@ -0,0 +1,12 @@ +# GoBoogy - a Korean P2P protocol +# Pattern attributes: marginal slow notsofast +# Protocol groups: p2p +# Wiki: http://www.protocolinfo.org/wiki/GoBoogy +# +# This pattern is untested and likely does not work in all cases! +# +# By Adam Przybyla, modified by Matthew Strait. Possibly lifted from +# Josh Ballard (oofle.com). + +goboogy +<peerplat>|^get /getfilebyhash\.cgi\?|^get /queue_register\.cgi\?|^get /getupdowninfo\.cgi\? diff --git a/usr/local/share/protocols/gopher.pat b/usr/local/share/protocols/gopher.pat new file mode 100644 index 0000000..3f49757 --- /dev/null +++ b/usr/local/share/protocols/gopher.pat @@ -0,0 +1,24 @@ +# Gopher - A precursor to HTTP - RFC 1436 +# Pattern attributes: good slow notsofast undermatch +# Protocol groups: document_retrieval obsolete ietf_rfc_documented +# Wiki: http://www.protocolinfo.org/wiki/Gopher +# +# Gopher servers usually run on TCP port 70. +# +# This pattern is lightly tested using gopher.dna.affrc.go.jp . + +gopher +# This matches the server's response, but naturally only if it is a +# directory listing, not if it is sending a file, because then the data +# is totally arbitrary. + +# Matches the client saying "list what you have", then the server +# response: one of the file type characters, any printable characters, a +# tab, any printable characters, a tab, something that looks like a +# domain name, a tab, and then a number which could be the start of a +# port number. + +# "0About internet Gopher\tStuff:About us\trawBits.micro.umn.edu\t70" +# "\r7search by keywords on protein data using wais\twaissrc:/protein_all/protein\tgopher.dna.affrc.go.jp\t70" + +^[\x09-\x0d]*[1-9,+tgi][\x09-\x0d -~]*\x09[\x09-\x0d -~]*\x09[a-z0-9.]*\.[a-z][a-z].?.?\x09[1-9] diff --git a/usr/local/share/protocols/h323.pat b/usr/local/share/protocols/h323.pat new file mode 100644 index 0000000..d3f59c5 --- /dev/null +++ b/usr/local/share/protocols/h323.pat @@ -0,0 +1,35 @@ +# H.323 - Voice over IP. +# Pattern attributes: ok veryfast fast +# Protocol groups: voip itu-t_standard +# Wiki: http://www.protocolinfo.org/wiki/H.323 +# +# This pattern is written without knowledge of the principles of H.323. +# It has only been tested with gnomemeeting and may not work for other +# clients. +# +# Also, it has been reported that: +# "the pattern ... match[es] only first H.323 stream (conntrack for H.323 was +# enabled). Also the major chunk of traffic was of RTP which went untracked." +# +# Also, it may very well match other things that use TPKT and +# Q.931. + +# Note that to take full advantage of this pattern, you will need to +# have connection tracking of H.323 support in your kernel. This +# support is not in the stock kernel. A patch can be found at +# http://netfilter.org + +h323 +# TPKT format: http://www.ietf.org/rfc/rfc1006.txt +# \x03 = TPKT version. It was 3 in May 1987 and gnomemeeting still uses 3. +# ..? = null reserved byte and packet length field. +# Q.931 format: http://www.freesoft.org/CIE/Topics/126.htm +# \x08 = Q.931 +# . = length of call reference +# The next byte was: \x18 = message sent from originating side. +# But based on experimentation, it seems that just . is better. +# .?.?.?.?.?.?.?.?.?.?.?.?.?.?.? = call reference (0-15 bytes (0 for nulls)) +# \x05 = setup message +# +# Yup, it doesn't actually include any H.323 protocol information. +^\x03..?\x08...?.?.?.?.?.?.?.?.?.?.?.?.?.?.?\x05 diff --git a/usr/local/share/protocols/halflife2-deathmatch.pat b/usr/local/share/protocols/halflife2-deathmatch.pat new file mode 100644 index 0000000..6efe59e --- /dev/null +++ b/usr/local/share/protocols/halflife2-deathmatch.pat @@ -0,0 +1,9 @@ +# Half-Life 2 Deathmatch - popular computer game +# Pattern attributes: good veryfast fast +# Protocol groups: game proprietary +# Wiki: http://www.protocolinfo.org/wiki/Half-Life +# +# By Clayton Macleod <cherrytwist TA gmail.com> + +halflife2-deathmatch +^\xff\xff\xff\xff.*hl2mpDeathmatch diff --git a/usr/local/share/protocols/hddtemp.pat b/usr/local/share/protocols/hddtemp.pat new file mode 100644 index 0000000..31a640f --- /dev/null +++ b/usr/local/share/protocols/hddtemp.pat @@ -0,0 +1,13 @@ +# hddtemp - Hard drive temperature reporting +# Pattern attributes: great veryfast fast +# Protocol groups: monitoring open_source +# Wiki: http://www.protocolinfo.org/wiki/HDDtemp +# +# Usually runs on port 7634 +# +# You're a silly person if you use this pattern. +# +# This pattern has been tested and is believed to work well. + +hddtemp +^\|/dev/[a-z][a-z][a-z]\|[0-9a-z]*\|[0-9][0-9]\|[cfk]\| diff --git a/usr/local/share/protocols/hotline.pat b/usr/local/share/protocols/hotline.pat new file mode 100644 index 0000000..1c11c62 --- /dev/null +++ b/usr/local/share/protocols/hotline.pat @@ -0,0 +1,11 @@ +# Hotline - An old P2P filesharing protocol +# Pattern attributes: marginal fast fast +# Protocol groups: p2p +# Wiki: http://www.protocolinfo.org/wiki/Hotline +# +# This pattern is untested! +# +# This is lifted from http://oofle.com/filesharing.php?app=hotline + +hotline +^....................TRTPHOTL\x01\x02 diff --git a/usr/local/share/protocols/http-rtsp.pat b/usr/local/share/protocols/http-rtsp.pat new file mode 100644 index 0000000..3cb65fb --- /dev/null +++ b/usr/local/share/protocols/http-rtsp.pat @@ -0,0 +1,15 @@ +# RTSP tunneled within HTTP +# Pattern attributes: ok notsofast notsofast subset +# Protocol groups: streaming_audio streaming_video ietf_draft_standard +# Wiki: http://www.protocolinfo.org/wiki/RTSP +# +# Apple's documentation on what Quicktime does: +# http://developer.apple.com/quicktime/icefloe/dispatch028.html +# This is what the first part of the pattern is about +# +# The second part is based on the example in RFC 2326. For this part to +# work, this pattern MUST be earlier in the iptables rules chain than +# HTTP. Otherwise, the stream will be identified as HTTP. + +http-rtsp +^(get[\x09-\x0d -~]* Accept: application/x-rtsp-tunnelled|http/(0\.9|1\.0|1\.1) [1-5][0-9][0-9] [\x09-\x0d -~]*a=control:rtsp://) diff --git a/usr/local/share/protocols/http.pat b/usr/local/share/protocols/http.pat new file mode 100644 index 0000000..550aa0b --- /dev/null +++ b/usr/local/share/protocols/http.pat @@ -0,0 +1,27 @@ +# HTTP - HyperText Transfer Protocol - RFC 2616 +# Pattern attributes: great slow notsofast superset +# Protocol groups: document_retrieval ietf_draft_standard +# Wiki: http://protocolinfo.org/wiki/HTTP +# +# Usually runs on port 80 +# +# This pattern has been tested and is believed to work well. +# +# this intentionally catches the response from the server rather than +# the request so that other protocols which use http (like kazaa) can be +# caught based on specific http requests regardless of the ordering of +# filters... also matches posts + +# Sites that serve really long cookies may break this by pushing the +# server response too far away from the beginning of the connection. To +# fix this, increase the kernel's data buffer length. + +http +# Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF (rfc 2616) +# As specified in rfc 2616 a status code is preceeded and followed by a +# space. +http/(0\.9|1\.0|1\.1) [1-5][0-9][0-9] [\x09-\x0d -~]*(connection:|content-type:|content-length:|date:)|post [\x09-\x0d -~]* http/[01]\.[019] +# A slightly faster version that might be good enough: +#http/(0\.9|1\.0|1\.1) [1-5][0-9][0-9]|post [\x09-\x0d -~]* http/[01]\.[019] +# old pattern(s): +#(http[\x09-\x0d -~]*(200 ok|302 |304 )[\x09-\x0d -~]*(connection:|content-type:|content-length:))|^(post [\x09-\x0d -~]* http/) diff --git a/usr/local/share/protocols/ident.pat b/usr/local/share/protocols/ident.pat new file mode 100644 index 0000000..d6d89c3 --- /dev/null +++ b/usr/local/share/protocols/ident.pat @@ -0,0 +1,14 @@ +# Ident - Identification Protocol - RFC 1413 +# Pattern attributes: good fast fast +# Protocol groups: networking ietf_proposed_standard +# Wiki: http://www.protocolinfo.org/wiki/Ident +# +# Usually runs on port 113 +# +# This pattern is believed to work. + +ident +# "number , numberCRLF" possibly without the CR and/or LF. +# ^$ is appropriate because the first packet should never have anything +# else in it. +^[1-9][0-9]?[0-9]?[0-9]?[0-9]?[\x09-\x0d]*,[\x09-\x0d]*[1-9][0-9]?[0-9]?[0-9]?[0-9]?(\x0d\x0a|[\x0d\x0a])?$ diff --git a/usr/local/share/protocols/imap.pat b/usr/local/share/protocols/imap.pat new file mode 100644 index 0000000..eac620d --- /dev/null +++ b/usr/local/share/protocols/imap.pat @@ -0,0 +1,13 @@ +# IMAP - Internet Message Access Protocol (A common e-mail protocol) +# Pattern attributes: great veryfast fast +# Protocol groups: mail ietf_proposed_standard +# Wiki: http://www.protocolinfo.org/wiki/IMAP +# +# This matches IMAP4 (RFC 3501) and probably IMAP2 (RFC 1176) +# +# This pattern has been tested and is believed to work well. +# +# This matches the IMAP welcome message or a noop command (which for +# some unknown reason can happen at the start of a connection?) +imap +^(\* ok|a[0-9]+ noop) diff --git a/usr/local/share/protocols/imesh.pat b/usr/local/share/protocols/imesh.pat new file mode 100644 index 0000000..782047f --- /dev/null +++ b/usr/local/share/protocols/imesh.pat @@ -0,0 +1,14 @@ +# iMesh - the native protocol of iMesh, a P2P application - http://imesh.com +# Pattern attributes: ok notsofast notsofast +# Protocol groups: p2p +# Wiki: http://protocolinfo.org/wiki/iMesh +# +# depending on the version of iMesh (the program), it can also use fasttrack, +# gnutella and edonkey in addition to iMesh (the protocol). + +imesh +# The first branch matches the login +# The second branch matches the main non-download connection (searches, etc) +# The third branch matches downloads of "premium" content +# The fourth branch matches peer downloads. +^(post[\x09-\x0d -~]*<PasswordHash>................................</PasswordHash><ClientVer>|\x34\x80?\x0d?\xfc\xff\x04|get[\x09-\x0d -~]*Host: imsh\.download-prod\.musicnet\.com|\x02[\x01\x02]\x83.*\x02[\x01\x02]\x83) diff --git a/usr/local/share/protocols/ipp.pat b/usr/local/share/protocols/ipp.pat new file mode 100644 index 0000000..a4a4d14 --- /dev/null +++ b/usr/local/share/protocols/ipp.pat @@ -0,0 +1,11 @@ +# IP printing - a new standard for UNIX printing - RFC 2911 +# Pattern attributes: good notsofast notsofast +# Protocol groups: printer ietf_proposed_standard +# Wiki: http://www.protocolinfo.org/wiki/IPP +# +# This pattern has been tested and is believed to work well. + +ipp +# It's unlikely that anything else has this string, but I think we could +# do a bit better... +ipp:// diff --git a/usr/local/share/protocols/irc.pat b/usr/local/share/protocols/irc.pat new file mode 100644 index 0000000..2767336 --- /dev/null +++ b/usr/local/share/protocols/irc.pat @@ -0,0 +1,19 @@ +# IRC - Internet Relay Chat - RFC 1459 +# Pattern attributes: great veryfast fast +# Protocol groups: chat ietf_proposed_standard +# Wiki: http://www.protocolinfo.org/wiki/IRC +# +# Usually runs on port 6666 or 6667 +# Note that chat traffic runs on these ports, but IRC-DCC traffic (which +# can use much more bandwidth) uses a dynamically assigned port, so you +# must have the IRC connection tracking module in your kernel to classify +# this. +# +# This pattern has been tested and is believed to work well. + +irc +# First thing that happens is that the client sends NICK and USER, in +# either order. This allows MIRC color codes (\x02-\x0d instead of +# \x09-\x0d). +^(nick[\x09-\x0d -~]*user[\x09-\x0d -~]*:|user[\x09-\x0d -~]*:[\x02-\x0d -~]*nick[\x09-\x0d -~]*\x0d\x0a) + diff --git a/usr/local/share/protocols/jabber.pat b/usr/local/share/protocols/jabber.pat new file mode 100644 index 0000000..aa51c76 --- /dev/null +++ b/usr/local/share/protocols/jabber.pat @@ -0,0 +1,23 @@ +# Jabber (XMPP) - open instant messenger protocol - RFC 3920 - http://jabber.org +# Pattern attributes: good notsofast notsofast +# Protocol groups: chat ietf_proposed_standard +# Wiki: http://www.protocolinfo.org/wiki/Jabber +# +# This pattern has been tested with Gaim and Gabber. It is only tested +# with non-SSL mode Jabber with no proxies. + +# Thanks to Jan Hudec for some improvements. + +# Jabber seems to take a long time to set up a connection. I'm +# connecting with Gabber 0.8.8 to 12jabber.org and the first 8 packets +# is this: +# <stream:stream to='12jabber.com' xmlns='jabber:client' +# xmlns:stream='http://etherx.jabber.org/streams'><?xml +# version='1.0'?><stream:stream +# xmlns:stream='http://etherx.jabber.org/streams' id='3f73e951' +# xmlns='jabber:client' from='12jabber.com'> +# +# No mention of my username or password yet, you'll note. + +jabber +<stream:stream[\x09-\x0d ][ -~]*[\x09-\x0d ]xmlns=['"]jabber diff --git a/usr/local/share/protocols/kugoo.pat b/usr/local/share/protocols/kugoo.pat new file mode 100644 index 0000000..be15ad5 --- /dev/null +++ b/usr/local/share/protocols/kugoo.pat @@ -0,0 +1,14 @@ +# KuGoo - a Chinese P2P program - http://www.kugoo.com +# Pattern attributes: ok veryfast fast +# Protocol groups: p2p +# Wiki: http://www.protocolinfo.org/wiki/KuGoo +# +# The author of this pattern says it works, but this is unconfirmed. +# Written by www.routerclub.com wsgtrsys. +# +# LanTian submitted \x64.+\x74\x47\x50\x37 for "KuGoo2", but adding as +# another branch makes the pattern REALLY slow. If it could have a ^, that'd +# be ok (still veryfast/fast). Waiting to hear. + +kugoo +^(\x31..\x8e|\x64.+\x74\x47\x50\x37) diff --git a/usr/local/share/protocols/live365.pat b/usr/local/share/protocols/live365.pat new file mode 100644 index 0000000..9360892 --- /dev/null +++ b/usr/local/share/protocols/live365.pat @@ -0,0 +1,14 @@ +# live365 - An Internet radio site - http://live365.com +# Pattern attributes: marginal notsofast notsofast +# Protocol groups: streaming_audio +# Wiki: http://www.protocolinfo.org/wiki/Live365 +# +# This pattern was "contributed" (taken with permission) by the bandwidth +# arbitrator project (www.bandwidtharbitrator.com). +# +# This pattern is unconfirmed. + +live365 +# FIXME: what's going on here? +membername.*session.*player + diff --git a/usr/local/share/protocols/liveforspeed.pat b/usr/local/share/protocols/liveforspeed.pat new file mode 100644 index 0000000..17b755d --- /dev/null +++ b/usr/local/share/protocols/liveforspeed.pat @@ -0,0 +1,12 @@ +# Live For Speed - A racing game. +# Pattern attributes: poor veryfast fast +# Protocol groups: game proprietary +# Wiki: http://www.protocolinfo.org/wiki/Live_For_Speed +# +# This pattern was submitted to protocolinfo.org by 80.55.238.74 with no +# explanation. It is unconfirmed. + +# Live For Speed S2 Alpha 0.5 X10 +liveforspeed +^..\x05\x58\x0a\x1d\x03 +# The same guy came by the next day and deleted the \x03 without comment... diff --git a/usr/local/share/protocols/lpd.pat b/usr/local/share/protocols/lpd.pat new file mode 100644 index 0000000..d1b8ae7 --- /dev/null +++ b/usr/local/share/protocols/lpd.pat @@ -0,0 +1,17 @@ +# LPD - Line Printer Daemon Protocol (old-style UNIX printing) - RFC 1179 +# Pattern attributes: ok fast fast +# Protocol groups: printer ietf_rfc_documented +# Wiki: http://www.protocolinfo.org/wiki/LPD +# +# This pattern is untested. + +lpd +# print waiting jobs: ^\x01[!-~]+\x0a$ +# receive a print job: ^\x02[!-~]+\x0a.[\x01\x02\x03][\x01-\x0a -~]*\x0a$ +# Send queue state: ^[\x03\x04][!-~]+[\x09-\x0d]+[a-z][\x09-\x0d -~]*\x0a$ +# Remove jobs: ^\x05[!-~]+[\x09-\x0d]+([a-z][!-~]*[\x09-\x0d]+[1-9][0-9]?[0-9]?|root[\x09-\x0d]+[!-~]+).*\x0a$ + +# This pattern looks like it might match random data once in a while, but +# testing shows that this is not the case. + +^(\x01[!-~]+|\x02[!-~]+\x0a.[\x01\x02\x03][\x01-\x0a -~]*|[\x03\x04][!-~]+[\x09-\x0d]+[a-z][\x09-\x0d -~]*|\x05[!-~]+[\x09-\x0d]+([a-z][!-~]*[\x09-\x0d]+[1-9][0-9]?[0-9]?|root[\x09-\x0d]+[!-~]+).*)\x0a$ diff --git a/usr/local/share/protocols/mohaa.pat b/usr/local/share/protocols/mohaa.pat new file mode 100644 index 0000000..aebe47a --- /dev/null +++ b/usr/local/share/protocols/mohaa.pat @@ -0,0 +1,10 @@ +# Medal of Honor Allied Assault - an Electronic Arts game +# Pattern attributes: good veryfast fast +# Protocol groups: game proprietary +# Wiki: http://www.protocolinfo.org/wiki/Medal_of_Honor_Allied_Assault +# +# This pattern is written and tested by Krzysztof Maciejewski. + +mohaa +^\xff\xff\xff\xffgetstatus\x0a + diff --git a/usr/local/share/protocols/msn-filetransfer.pat b/usr/local/share/protocols/msn-filetransfer.pat new file mode 100644 index 0000000..5ffddfc --- /dev/null +++ b/usr/local/share/protocols/msn-filetransfer.pat @@ -0,0 +1,29 @@ +# MSN (Micosoft Network) Messenger file transfers (MSNFTP and MSNSLP) +# Pattern attributes: good veryfast fast +# Protocol groups: chat document_retrieval proprietary +# Wiki: http://www.protocolinfo.org/wiki/MSN_Messenger +# +# http://www.hypothetic.org/docs/msn/client/file_transfer.php + +# NOTE! This pattern does not catch the modern type of MSN filetransfers +# because they use the same TCP connection as the chat itself. See +# ../example_traffic/msn_chat_and_file_transfer.txt for a demonstration. + +# This pattern has been tested and seems to work well. It, does, +# however, require more testing with various versions of the official +# MSN client as well as with clones such as Trillian, Miranda, Gaim, +# etc. If you are using a MSN clone and this pattern DOES work for you, +# please, also let us know. + +# First part matches the older MSNFTP: A MSN filetransfer is a normal +# MSN connection except that the protocol is MSNFTP. Some clients +# (especially Trillian) send other protocol versions besides MSNFTP +# which should be matched by the [ -~]*. + +# Second part matches newer MSNSLP: +# http://msnpiki.msnfanatic.com/index.php/MSNC:MSNSLP +# This part is untested. + +msn-filetransfer +^(ver [ -~]*msnftp\x0d\x0aver msnftp\x0d\x0ausr|method msnmsgr:) + diff --git a/usr/local/share/protocols/msnmessenger.pat b/usr/local/share/protocols/msnmessenger.pat new file mode 100644 index 0000000..41f1075 --- /dev/null +++ b/usr/local/share/protocols/msnmessenger.pat @@ -0,0 +1,27 @@ +# MSN Messenger - Microsoft Network chat client +# Pattern attributes: good slow notsofast +# Protocol groups: chat proprietary +# Wiki: http://www.protocolinfo.org/wiki/MSN_Messenger +# +# Usually uses TCP port 1863 +# http://www.hypothetic.org/docs/msn/index.php +# http://msnpiki.msnfanatic.com/ +# +# This pattern has been tested and is believed to work well. + +msnmessenger + +# First branch: login +# ver: allow versions up to 99. +# I've never seen a cvr other than cvr0. Maybe this will be trouble later? +# Can't anchor at the beginning because sometimes this is encapsulated in +# HTTP. But either way, the first packet ends like this. +# Second/Third branches: accepting/sending a message +# I will assume that these can also be encapsulated in HTTP, although I have +# not checked. Example of each direction: +# ANS 1 quadong@hotmail.com 1139803431.29427 17522047 +# USR 1 quadong@hotmail.com 530423708.968145.366138 + +# Branches are written entirely separately for better performance. +ver [0-9]+ msnp[1-9][0-9]? [\x09-\x0d -~]*cvr0\x0d\x0a$|usr 1 [!-~]+ [0-9. ]+\x0d\x0a$|ans 1 [!-~]+ [0-9. ]+\x0d\x0a$ + diff --git a/usr/local/share/protocols/mute.pat b/usr/local/share/protocols/mute.pat new file mode 100644 index 0000000..c803090 --- /dev/null +++ b/usr/local/share/protocols/mute.pat @@ -0,0 +1,10 @@ +# MUTE - P2P filesharing - http://mute-net.sourceforge.net +# Pattern attributes: marginal veryfast fast +# Protocol groups: p2p open_source +# Wiki: http://www.protocolinfo.org/wiki/MUTE +# +# This pattern is lightly tested. I don't know for sure that it will +# match the actual file transfers. + +mute +^(Public|AES)Key: [0-9a-f]*\x0aEnd(Public|AES)Key\x0a$ diff --git a/usr/local/share/protocols/napster.pat b/usr/local/share/protocols/napster.pat new file mode 100644 index 0000000..83005b8 --- /dev/null +++ b/usr/local/share/protocols/napster.pat @@ -0,0 +1,23 @@ +# Napster - P2P filesharing +# Pattern attributes: good fast fast +# Protocol groups: p2p +# Wiki: http://www.protocolinfo.org/wiki/Napster +# +# All my tests show that this pattern is fast, but one user has reported that +# it is slow. Your milage may vary. +# +# Should work for any Napster offspring, like OpenNAP. +# (Yes, people still use this!) +# Matches both searches and downloads. +# +# http://opennap.sourceforge.net/napster.txt +# +# This pattern has been tested and is believed to work well. + +napster +# (client-server: length, assumed to be less than 256, login or new user login, +# username, password, port, client ID, link-type | +# client-client: 1, firewalled or not, username, filename) +# Assumes that filenames are well-behaved ASCII strings. I have found +# one case where this assumptions fails (filename had \x99 in it). +^(.[\x02\x06][!-~]+ [!-~]+ [0-9][0-9]?[0-9]?[0-9]?[0-9]? "[\x09-\x0d -~]+" ([0-9]|10)|1(send|get)[!-~]+ "[\x09-\x0d -~]+") diff --git a/usr/local/share/protocols/nbns.pat b/usr/local/share/protocols/nbns.pat new file mode 100644 index 0000000..d4fff4f --- /dev/null +++ b/usr/local/share/protocols/nbns.pat @@ -0,0 +1,19 @@ +# NBNS - NetBIOS name service +# Pattern attributes: good slow notsofast +# Protocol groups: networking proprietary +# Wiki: http://www.protocolinfo.org/wiki/NBNS +# +# This pattern has been tested and is believed to work well. +# +# name query +# \x01\x10 means name query +# +# registration NB +# (\x10 or )\x10 means registration +# +# release NB (merged with registration) +# 0\x10 means release + +nbns +# This is not a valid basic GNU regular expression. +\x01\x10\x01|\)\x10\x01\x01|0\x10\x01 diff --git a/usr/local/share/protocols/ncp.pat b/usr/local/share/protocols/ncp.pat new file mode 100644 index 0000000..b4788a1 --- /dev/null +++ b/usr/local/share/protocols/ncp.pat @@ -0,0 +1,22 @@ +# NCP - Novell Core Protocol +# Pattern attributes: good veryfast fast +# Protocol groups: networking proprietary +# Wiki: http://www.protocolinfo.org/wiki/NCP +# +# This pattern has been tested and is believed to work well. + +# ncp request +# dmdt means Request +# *any length +# +# *any reply buffer size +# "" means service request +# | \x17\x17 means create a service connection +# | uu means destroy service connection + +# ncp reply +# tncp means reply +# 33 means service reply + +ncp +^(dmdt.*\x01.*(""|\x11\x11|uu)|tncp.*33) diff --git a/usr/local/share/protocols/netbios.pat b/usr/local/share/protocols/netbios.pat new file mode 100644 index 0000000..8e90074 --- /dev/null +++ b/usr/local/share/protocols/netbios.pat @@ -0,0 +1,28 @@ +# NetBIOS - Network Basic Input Output System +# Pattern attributes: marginal notsofast notsofast +# Protocol groups: networking ietf_internet_standard proprietary +# Wiki: http://www.protocolinfo.org/wiki/NetBIOS +# +# As mentioned in smb.pat: +# +# "This protocol is sometimes also referred to as the Common Internet File +# System (CIFS), LanManager or NetBIOS protocol." -- "man samba" +# +# Actually, SMB is a higher level protocol than NetBIOS. However, the +# NetBIOS header is only 4 bytes: not much to match on. +# +# http://www.ubiqx.org/cifs/SMB.html +# See also RFCs 1001 and 1002. +# +# This pattern attempts to match the (Session layer) NetBIOS Session request. +# If sucessful, you may be able to match NetBIOS several packets earlier +# than if you just waited for the easier-to-match SMB header. +# +# This pattern is untested. + +netbios +# session request byte, three bytes of flags and length. Then +# there should be a big mess of letters between A and P which represent +# the NetBIOS names of the involved computers (with a null between them). +# (40ish here, damn this regexp implementation and its lack of {40,}) +\x81.?.?.[A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P] diff --git a/usr/local/share/protocols/nntp.pat b/usr/local/share/protocols/nntp.pat new file mode 100644 index 0000000..769c8a5 --- /dev/null +++ b/usr/local/share/protocols/nntp.pat @@ -0,0 +1,20 @@ +# NNTP - Network News Transfer Protocol - RFCs 977 and 2980 +# Pattern attributes: good veryfast fast +# Protocol groups: ietf_proposed_standard +# Wiki: http://www.protocolinfo.org/wiki/NNTP +# +# usually runs on port 119 + +# This pattern is tested and is believed to work well (but could use +# more testing). + +nntp +# matches authorized login +# OR +# matches unauthorized login if the server says "news" after 200/201 +# (Half of the 2 servers I tested did :-), but they both required authorization +# so it's quite possible that this pattern will miss some nntp traffic.) +^(20[01][\x09-\x0d -~]*AUTHINFO USER|20[01][\x09-\x0d -~]*news) + +# same thing, slightly more accurate, but 100+ times slower +#^20[01][\x09-\x0d -~]*\x0d\x0a[\x09-\x0d -~]*AUTHINFO USER|20[01][\x09-\x0d -~]*news diff --git a/usr/local/share/protocols/ntp.pat b/usr/local/share/protocols/ntp.pat new file mode 100644 index 0000000..a24fb05 --- /dev/null +++ b/usr/local/share/protocols/ntp.pat @@ -0,0 +1,16 @@ +# (S)NTP - (Simple) Network Time Protocol - RFCs 1305 and 2030 +# Pattern attributes: good fast fast overmatch +# Protocol groups: time_synchronization ietf_draft_standard +# Wiki: http://www.protocolinfo.org/wiki/NTP +# +# This pattern is tested and is believed to work. + +# client|server +# Requires the server's timestamp to be in the present or future (of 2005). +# Tested with ntpdate on Linux. +# Assumes version 2, 3 or 4. + +# Note that ntp packets are always 48 bytes, so you should match on that too. + +ntp +^([\x13\x1b\x23\xd3\xdb\xe3]|[\x14\x1c$].......?.?.?.?.?.?.?.?.?[\xc6-\xff]) diff --git a/usr/local/share/protocols/openft.pat b/usr/local/share/protocols/openft.pat new file mode 100644 index 0000000..f81499a --- /dev/null +++ b/usr/local/share/protocols/openft.pat @@ -0,0 +1,12 @@ +# OpenFT - P2P filesharing (implemented in giFT library) +# Pattern attributes: good fast notsofast +# Protocol groups: p2p open_source +# Wiki: http://www.protocolinfo.org/wiki/OpenFT + +# Ben Efros <ben AT xgendev.com> says: +# "This pattern identifies openFT P2P transfers fine. openFT is part of giFT +# and is a pretty large p2p network. I would describe this pattern as pretty +# weak, but it works for the giFT-based clients I've used." + +openft +x-openftalias: [-)(0-9a-z ~.] diff --git a/usr/local/share/protocols/pcanywhere.pat b/usr/local/share/protocols/pcanywhere.pat new file mode 100644 index 0000000..86dae6b --- /dev/null +++ b/usr/local/share/protocols/pcanywhere.pat @@ -0,0 +1,11 @@ +# pcAnywhere - Symantec remote access program +# Pattern attributes: marginal veryfast fast +# Protocol groups: remote_access proprietary +# Wiki: http://www.protocolinfo.org/wiki/PcAnywhere + +# This is completely untested! +# See http://www.unixwiz.net/tools/pcascan.txt + +pcanywhere +# I think this only matches queries and not the bulk of the traffic! +^(nq|st)$ diff --git a/usr/local/share/protocols/poco.pat b/usr/local/share/protocols/poco.pat new file mode 100644 index 0000000..2bcf66d --- /dev/null +++ b/usr/local/share/protocols/poco.pat @@ -0,0 +1,11 @@ +# POCO and PP365 - Chinese P2P filesharing - http://pp365.com http://poco.cn +# Pattern attributes: ok veryfast fast +# Protocol groups: p2p +# Wiki: http://www.protocolinfo.org/wiki/Poco +# +# The author of this pattern says it works, but this is unconfirmed. +# Written by www.routerclub.com wsgtrsys. + +poco +^\x80\x94\x0a\x01....\x1f\x9e + diff --git a/usr/local/share/protocols/pop3.pat b/usr/local/share/protocols/pop3.pat new file mode 100644 index 0000000..b3d76e2 --- /dev/null +++ b/usr/local/share/protocols/pop3.pat @@ -0,0 +1,49 @@ +# POP3 - Post Office Protocol version 3 (popular e-mail protocol) - RFC 1939 +# Pattern attributes: great veryfast fast +# Protocol groups: mail ietf_internet_standard +# Wiki: http://www.protocolinfo.org/wiki/POP +# +# This pattern has been tested somewhat. + +# this is a difficult protocol to match because of the relative lack of +# distinguishing information. Read on. +pop3 + +# this the most conservative pattern. It should definitely work. +#^(\+ok|-err) + +# this pattern assumes that the server says _something_ after +ok or -err +# I think this is probably the way to go. +^(\+ok |-err ) + +# more that 90% of servers seem to say "pop" after "+ok", but not all. +#^(\+ok .*pop) + +# Here's another tack. I think this is my second favorite. +#^(\+ok [\x09-\x0d -~]*(ready|hello|pop|starting)|-err [\x09-\x0d -~]*(invalid|unknown|unimplemented|unrecognized|command)) + +# this matches the server saying "you have N messages that are M bytes", +# which the client probably asks for early in the session (not tested) +#\+ok [0-9]+ [0-9]+ + +# some sample servers: +# RFC example: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us> +# mail.dreamhost.com: +OK Hello there. +# pop.carleton.edu: +OK POP3D(*) Server PMDFV6.2.2 at Fri, 12 Sep 2003 19:28:10 -0500 (CDT) (APOP disabled) +# mail.earthlink.net: +OK NGPopper vEL_4_38 at earthlink.net ready <25509.1063412951@falcon> +# *.email.umn.edu: +OK Cubic Circle's v1.22 1998/04/11 POP3 ready <7d1e0000da67623f@aquamarine.tc.umn.edu> +# mail.yale.edu: +OK POP3 pantheon-po01 v2002.81 server ready +# mail.gustavus.edu: +OK POP3 solen v2001.78 server ready +# mail.reed.edu: +OK POP3 letra.reed.edu v2002.81 server ready +# mail.bowdoin.edu: +OK mail.bowdoin.edu POP3 service (iPlanet Messaging Server 5.2 HotFix 1.15 (built Apr 28 2003)) +# pop.colby.edu: +OK Qpopper (version 4.0.5) at basalt starting. +# mail.mac.com: +OK Netscape Messaging Multiplexor ready + +# various error strings: +#-ERR Invalid command. +#-ERR invalid command +#-ERR unimplemented +#-ERR Invalid command, try one of: USER name, PASS string, QUIT +#-ERR Unknown AUTHORIZATION state command +#-ERR Unrecognized command +#-ERR Unknown command: "sadf'". diff --git a/usr/local/share/protocols/qq.pat b/usr/local/share/protocols/qq.pat new file mode 100644 index 0000000..7689439 --- /dev/null +++ b/usr/local/share/protocols/qq.pat @@ -0,0 +1,25 @@ +# Tencent QQ Protocol - Chinese instant messenger protocol - http://www.qq.com +# Pattern attributes: good fast fast +# Protocol groups: chat +# Wiki: http://www.protocolinfo.org/wiki/QQ +# +# Over six million people use QQ in China, according to wsgtrsys. +# +# This pattern has been tested and is believed to work well. +# +# QQ uses three (two?) methods to connect to server(s?). +# one is udp, and another is tcp +# udp protocol: the first byte is 02 and last byte is 03 +# tcp protocol: the second byte is 02 and last byte is 03 +# tony on protocolinfo.org says that now the *third* byte is 02: +# "but when I tested on my PC, I found that when qq2007/qq2008 +# use tcp protocol, the third byte instead of the second is always 02. +# +# So the QQ protocol changed again, or I have made a mistake, I wonder +# that." +# So now the pattern allows any of the first three bytes to be 02. Delete +# one of the ".?" to restore to the old behaviour. +# pattern written by www.routerclub.com wsgtrsys + +qq +^.?.?\x02.+\x03$ diff --git a/usr/local/share/protocols/quake-halflife.pat b/usr/local/share/protocols/quake-halflife.pat new file mode 100644 index 0000000..7e2b537 --- /dev/null +++ b/usr/local/share/protocols/quake-halflife.pat @@ -0,0 +1,26 @@ +# Half Life 1 engine games (HL 1, Quake 2/3/World, Counterstrike 1.6, etc.) +# Pattern attributes: good veryfast fast +# Protocol groups: game proprietary +# Wiki: http://www.protocolinfo.org/wiki/Half-Life http://www.protocolinfo.org/wiki/Counter-Strike http://www.protocolinfo.org/wiki/Day_of_Defeat +# +# Contributed by Laurens Blankers <laurens AT blankersfamily.com>, who says: +# +# This pattern has been tested with QuakeWorld (2.30), Quake 2 (3.20), +# Quake 3 (1.32), and Half-life (1.1.1.0). But may also work on other +# games based on the Quake engine. +# +# Clayton Macleod <cherrytwist A gmail.com> says: +# [This should match] Counter-Strike v1.6, [...] the slightly updated +# Counter-Strike: Condition Zero, and the game Day Of Defeat, Team +# Fortress Classic, Deathmatch Classic, Ricochet, Half-Life [1] Deathmatch, +# and I imagine all the other 3rd party mods that also use this engine +# will match that pattern. + +quake-halflife +# All quake (like) protocols start with 4x 0xFF. Then the client either +# issues getinfo or getchallenge. +^\xff\xff\xff\xffget(info|challenge) + +# A previous quake pattern allowed the connection to start with only 2 bytes +# of 0xFF. This doesn't seem to ever happen, but we should keep an eye out +# for it. diff --git a/usr/local/share/protocols/quake1.pat b/usr/local/share/protocols/quake1.pat new file mode 100644 index 0000000..18e0ca0 --- /dev/null +++ b/usr/local/share/protocols/quake1.pat @@ -0,0 +1,18 @@ +# Quake 1 - A popular computer game. +# Pattern attributes: marginal veryfast fast +# Protocol groups: game proprietary +# Wiki: http://www.protocolinfo.org/wiki/Quake +# +# This pattern is untested and unconfirmed. + +# Info taken from http://www.gamers.org/dEngine/quake/QDP/qnp.html, +# which says that it "is incomplete, inaccurate and only applies to +# versions 0.91, 0.92, 1.00 and 1.01 of QUAKE" + +quake1 +# Connection request: 80 00 00 0c 01 51 55 41 4b 45 00 03 +# \x80 = control packet. +# \x0c = packet length +# \x01 = CCREQ_CONNECT +# \x03 = protocol version (3 == 0.91, 0.92, 1.00, 1.01) +^\x80\x0c\x01quake\x03 diff --git a/usr/local/share/protocols/radmin.pat b/usr/local/share/protocols/radmin.pat new file mode 100644 index 0000000..52ff6e0 --- /dev/null +++ b/usr/local/share/protocols/radmin.pat @@ -0,0 +1,16 @@ +# Famatech Remote Administrator - remote desktop for MS Windows +# Pattern attributes: ok veryfast fast +# Protocol groups: remote_access proprietary +# Wiki: http://www.protocolinfo.org/wiki/Radmin +# +# This pattern has been verified with Radmin v1.1 and v3.0beta on Win2000/XP +# It has only been tested between a single pair of computers. + +# The first packet of every TCP stream appears to be either one of: +# +# 01 00 00 00 01 00 00 00 08 08 +# 01 00 00 00 01 00 00 00 1b 1b + +radmin +^\x01\x01(\x08\x08|\x1b\x1b)$ + diff --git a/usr/local/share/protocols/rdp.pat b/usr/local/share/protocols/rdp.pat new file mode 100644 index 0000000..e10a81d --- /dev/null +++ b/usr/local/share/protocols/rdp.pat @@ -0,0 +1,19 @@ +# RDP - Remote Desktop Protocol (used in Windows Terminal Services) +# Pattern attributes: ok notsofast notsofast +# Protocol groups: remote_access proprietary +# Wiki: http://www.protocolinfo.org/wiki/RDP +# +# This pattern was submitted by Michael Leong. It has been tested under the +# following conditions: "WinXP Pro with all the patches, rdesktop server +# running on port 7000 instead of 3389 --> WinXP Pro Remote Desktop Client." +# Also tested is WinXP to Win 2000 Server. + +# At least one other person has reported it to work as well. + +rdp +rdpdr.*cliprdr.*rdpsnd + +# Old pattern, submitted by Daniel Weatherford. +# rdpdr.*cliprdp.*rdpsnd + + diff --git a/usr/local/share/protocols/replaytv-ivs.pat b/usr/local/share/protocols/replaytv-ivs.pat new file mode 100644 index 0000000..4d44b0f --- /dev/null +++ b/usr/local/share/protocols/replaytv-ivs.pat @@ -0,0 +1,10 @@ +# ReplayTV Internet Video Sharing - Digital Video Recorder - http://replaytv.com +# Pattern attributes: good veryfast fast +# Protocol groups: +# Wiki: http://www.protocolinfo.org/wiki/ReplayTV +# +# Pattern by jm 409 at hot mail dot com, who says that this one "worked best". + +replaytv-ivs +^(get /ivs-IVSGetFileChunk|http/(0\.9|1\.0|1\.1) [1-5][0-9][0-9] [\x09-\x0d -~]*\x23\x23\x23\x23\x23REPLAY_CHUNK_START\x23\x23\x23\x23\x23) + diff --git a/usr/local/share/protocols/rlogin.pat b/usr/local/share/protocols/rlogin.pat new file mode 100644 index 0000000..92f3735 --- /dev/null +++ b/usr/local/share/protocols/rlogin.pat @@ -0,0 +1,18 @@ +# rlogin - remote login - RFC 1282 +# Pattern attributes: ok veryfast fast +# Protocol groups: remote_access ietf_rfc_documented +# Wiki: http://www.protocolinfo.org/wiki/Rlogin +# +# usually runs on port 443 +# +# This pattern is untested. + +rlogin +# At least three characters (user name, user name, terminal type), +# the first of which could be the first character of a user name, a +# slash, then a terminal speed. (Assumes that usernames and terminal +# types are alphanumeric only. I'm sure there are usernames like +# "straitm-47" out there, but it's not common.) All terminal speeds +# I know of end in two zeros and are between 3 and 6 digits long. +# This pattern is uncomfortably general. +^[a-z][a-z0-9][a-z0-9]+/[1-9][0-9]?[0-9]?[0-9]?00 diff --git a/usr/local/share/protocols/rtp.pat b/usr/local/share/protocols/rtp.pat new file mode 100644 index 0000000..d808e1e --- /dev/null +++ b/usr/local/share/protocols/rtp.pat @@ -0,0 +1,40 @@ +# RTP - Real-time Transport Protocol - RFC 3550 +# Pattern attributes: marginal overmatch undermatch veryfast fast +# Protocol groups: streaming_video ietf_internet_standard +# Wiki: http://www.protocolinfo.org/wiki/RTP +# +# RTP headers are *very* short and compact. They have almost nothing in +# them that can be matched by l7-filter. If you want to match them +# along with their associated SIP packets, I think the best way might be +# to set up some iptables rules that watch for SIP packets and then also +# match any other UDP packets that are going between the same two IP +# addresses. +# +# However, I will attempt a pattern anyway. This is UNTESTED! +# +# I think we can count on the first bit being 1 and the second bit being +# 0 (meaning protocol version 2). The next two bits could go either way, +# but in the example I've seen, they are zero, so I'll assume they are +# usually zero. The next four bits are a count of "contributing source +# identifiers". I'm not sure how big that could be, but in the example +# I've seen, they're zero, so I'll assume they're usually zero. So that +# gives us ^\x80. The marker bit that comes next is probably zero for +# the first packet, although that's not a sure thing. Next is the +# payload type, 7 bits that might usually only take a few values, but +# maybe not. In the example I've seen, it's zero, which (with a zero +# marker bit) means it looks to l7-filter like it's not there at all. +# The rest of the header is random numbers (sequence number, timestamp, +# synchronization source identifier), so that's no help at all. +# +# I think the best we could do is to watch to see if several \x80 bytes +# come in with a small number of bytes between them. This makes all the +# above assumptions and also assumes that the first packet has no +# payload and not too much trailing gargage. So this will definitely not +# work all the time. It clearly also might match other stuff. + +rtp +^\x80......?.?.?.?.?.?.?.?.?.?.?.?.?\x80 + +# Might also try this. It's a bit slower (one packet and not too much extra +# regexec load) and a bit more accurate: +#^\x80......?.?.?.?.?.?.?.?.?.?.?.?.?\x80.*\x80 diff --git a/usr/local/share/protocols/rtsp.pat b/usr/local/share/protocols/rtsp.pat new file mode 100644 index 0000000..a5f309c --- /dev/null +++ b/usr/local/share/protocols/rtsp.pat @@ -0,0 +1,14 @@ +# RTSP - Real Time Streaming Protocol - http://www.rtsp.org - RFC 2326 +# Pattern attributes: good notsofast notsofast +# Protocol groups: streaming_video ietf_proposed_standard +# Wiki: http://www.protocolinfo.org/wiki/RTSP +# +# usually runs on port 554 +# +# To take full advantage of this pattern, please see the RTSP connection +# tracking patch to the Linux kernel referenced at the above site. +# +# This pattern has been tested and is believed to work well. + +rtsp +rtsp/1.0 200 ok diff --git a/usr/local/share/protocols/shoutcast.pat b/usr/local/share/protocols/shoutcast.pat new file mode 100644 index 0000000..6ae0824 --- /dev/null +++ b/usr/local/share/protocols/shoutcast.pat @@ -0,0 +1,26 @@ +# Shoutcast and Icecast - streaming audio +# Pattern attributes: good slow notsofast +# Protocol groups: streaming_audio +# Wiki: http://www.protocolinfo.org/wiki/Icecast +# +# usually runs on port 80 +# +# Original pattern contributed by Deepak Seshadri <dseshadri AT +# broadbandmaritime.com> who says "The difference between [Shoutcast and +# Icecast] is not clearly mentioned anywhere. According to this +# document, my pattern would filter JUST shoutcast packets." +# +# Should now match both Shoutcast and Icecast. Tested with Winamp (in +# 2005) and Totem using streams at dir.xiph.org (in Nov 2007). +# +# http://sander.vanzoest.com/talks/2002/audio_and_apache/ +# http://forums.radiotoolbox.com/viewtopic.php?t=74 +# http://www.icecast.org + +shoutcast +# The first branch looks for an HTTP request that looks like it is asking for +# a SHOUTcast stream. The second branch looks for the server's reply. However, +# some (newer?) servers answer with "http/1.0 200 OK", not "ICY 200 OK", so +# this will not work. +# This pattern was discovered using Ethereal. +^get /.*icy-metadata:1|icy [1-5][0-9][0-9] [\x09-\x0d -~]*(content-type:audio|icy-) diff --git a/usr/local/share/protocols/sip.pat b/usr/local/share/protocols/sip.pat new file mode 100644 index 0000000..3782e33 --- /dev/null +++ b/usr/local/share/protocols/sip.pat @@ -0,0 +1,18 @@ +# SIP - Session Initiation Protocol - Internet telephony - RFC 3261 +# Pattern attributes: ok fast fast +# Protocol groups: voip ietf_proposed_standard +# Wiki: http://www.protocolinfo.org/wiki/SIP +# +# This pattern has been tested with the Ubiquity SIP user agent. +# +# Thanks to Ankit Desai for this pattern. +# +# SIP typically uses port 5060. +# +# This pattern is based on SIP request format as per RFC 3261. I'm not +# sure about the version part. The RFC doesn't say anything about it, so +# I have allowed version ranging from 0.x to 2.x. + +#Request-Line = Method SP Request-URI SP SIP-Version CRLF +sip +^(invite|register|cancel) sip[\x09-\x0d -~]*sip/[0-2]\.[0-9] diff --git a/usr/local/share/protocols/skypeout.pat b/usr/local/share/protocols/skypeout.pat new file mode 100644 index 0000000..a6b6ba7 --- /dev/null +++ b/usr/local/share/protocols/skypeout.pat @@ -0,0 +1,49 @@ +# Skype to phone - UDP voice call (program to POTS phone) - http://skype.com +# Pattern attributes: ok slow notsofast overmatch +# Protocol groups: voip p2p proprietary +# Wiki: http://www.protocolinfo.org/wiki/Skype + +# Thanks to Myles Uyema, mylesuyema AT gmail.com + +# Taken using Ethereal traces of Windows Skype v1.2.037, same in v1.2.0.18_API +# +# Skype will attempt to use the same UDP port for all its connections as +# configured in its options. However, this is a random port by default. +# Skype has some preference for ports 80 and 443. +# +# Example sessions: +# +#SkypeOut <USA phone number> +#c6 5c bf 41 8e 8d d6 d2 08 <-- this is sometimes as short as 1 byte and +#c6 5c bf 41 8e 8d d6 d2 08 <-- sometimes as long as 9 (or more?) +#00 6b 2c f5 87 f1 06 +#00 6b 2c f5 87 f1 06 +#00 6b 2c f5 36 ea 85 +#00 6b 2c f5 36 ea 85 +#00 6b 2c f5 57 27 d4 +#00 6b 2c f5 57 27 d4 +#00 6b 2c f5 43 5b 00 +#00 6b 2c f5 43 5b 00 +# +#SkypeOut <USA phone number> +#7e 4f e5 b8 +#7e 4f e5 b8 +#00 6b 88 61 80 52 93 +#00 6b 88 61 80 52 93 +#00 6b 88 61 1a 09 e9 +#00 6b 88 61 1a 09 e9 +#00 6b 88 61 47 43 c4 +#00 6b 88 61 47 43 c4 + +skypeout + +# Scary. Our regular expressions suck. This is a prime candidate for +# some sort of a scheme to support two different regular expressions +# when there's a major difference between what the two libraries allow. +# For the Henry Spencer library, there's not much that can be done +# except requiring that we see the same byte twice. + +# This matches about %4 of random streams and 13% of printable random streams + +# This is slow, but not as bad as you might think. +^(\x01.?.?.?.?.?.?.?.?\x01|\x02.?.?.?.?.?.?.?.?\x02|\x03.?.?.?.?.?.?.?.?\x03|\x04.?.?.?.?.?.?.?.?\x04|\x05.?.?.?.?.?.?.?.?\x05|\x06.?.?.?.?.?.?.?.?\x06|\x07.?.?.?.?.?.?.?.?\x07|\x08.?.?.?.?.?.?.?.?\x08|\x09.?.?.?.?.?.?.?.?\x09|\x0a.?.?.?.?.?.?.?.?\x0a|\x0b.?.?.?.?.?.?.?.?\x0b|\x0c.?.?.?.?.?.?.?.?\x0c|\x0d.?.?.?.?.?.?.?.?\x0d|\x0e.?.?.?.?.?.?.?.?\x0e|\x0f.?.?.?.?.?.?.?.?\x0f|\x10.?.?.?.?.?.?.?.?\x10|\x11.?.?.?.?.?.?.?.?\x11|\x12.?.?.?.?.?.?.?.?\x12|\x13.?.?.?.?.?.?.?.?\x13|\x14.?.?.?.?.?.?.?.?\x14|\x15.?.?.?.?.?.?.?.?\x15|\x16.?.?.?.?.?.?.?.?\x16|\x17.?.?.?.?.?.?.?.?\x17|\x18.?.?.?.?.?.?.?.?\x18|\x19.?.?.?.?.?.?.?.?\x19|\x1a.?.?.?.?.?.?.?.?\x1a|\x1b.?.?.?.?.?.?.?.?\x1b|\x1c.?.?.?.?.?.?.?.?\x1c|\x1d.?.?.?.?.?.?.?.?\x1d|\x1e.?.?.?.?.?.?.?.?\x1e|\x1f.?.?.?.?.?.?.?.?\x1f|\x20.?.?.?.?.?.?.?.?\x20|\x21.?.?.?.?.?.?.?.?\x21|\x22.?.?.?.?.?.?.?.?\x22|\x23.?.?.?.?.?.?.?.?\x23|\$.?.?.?.?.?.?.?.?\$|\x25.?.?.?.?.?.?.?.?\x25|\x26.?.?.?.?.?.?.?.?\x26|\x27.?.?.?.?.?.?.?.?\x27|\(.?.?.?.?.?.?.?.?\(|\).?.?.?.?.?.?.?.?\)|\*.?.?.?.?.?.?.?.?\*|\+.?.?.?.?.?.?.?.?\+|\x2c.?.?.?.?.?.?.?.?\x2c|\x2d.?.?.?.?.?.?.?.?\x2d|\..?.?.?.?.?.?.?.?\.|\x2f.?.?.?.?.?.?.?.?\x2f|\x30.?.?.?.?.?.?.?.?\x30|\x31.?.?.?.?.?.?.?.?\x31|\x32.?.?.?.?.?.?.?.?\x32|\x33.?.?.?.?.?.?.?.?\x33|\x34.?.?.?.?.?.?.?.?\x34|\x35.?.?.?.?.?.?.?.?\x35|\x36.?.?.?.?.?.?.?.?\x36|\x37.?.?.?.?.?.?.?.?\x37|\x38.?.?.?.?.?.?.?.?\x38|\x39.?.?.?.?.?.?.?.?\x39|\x3a.?.?.?.?.?.?.?.?\x3a|\x3b.?.?.?.?.?.?.?.?\x3b|\x3c.?.?.?.?.?.?.?.?\x3c|\x3d.?.?.?.?.?.?.?.?\x3d|\x3e.?.?.?.?.?.?.?.?\x3e|\?.?.?.?.?.?.?.?.?\?|\x40.?.?.?.?.?.?.?.?\x40|\x41.?.?.?.?.?.?.?.?\x41|\x42.?.?.?.?.?.?.?.?\x42|\x43.?.?.?.?.?.?.?.?\x43|\x44.?.?.?.?.?.?.?.?\x44|\x45.?.?.?.?.?.?.?.?\x45|\x46.?.?.?.?.?.?.?.?\x46|\x47.?.?.?.?.?.?.?.?\x47|\x48.?.?.?.?.?.?.?.?\x48|\x49.?.?.?.?.?.?.?.?\x49|\x4a.?.?.?.?.?.?.?.?\x4a|\x4b.?.?.?.?.?.?.?.?\x4b|\x4c.?.?.?.?.?.?.?.?\x4c|\x4d.?.?.?.?.?.?.?.?\x4d|\x4e.?.?.?.?.?.?.?.?\x4e|\x4f.?.?.?.?.?.?.?.?\x4f|\x50.?.?.?.?.?.?.?.?\x50|\x51.?.?.?.?.?.?.?.?\x51|\x52.?.?.?.?.?.?.?.?\x52|\x53.?.?.?.?.?.?.?.?\x53|\x54.?.?.?.?.?.?.?.?\x54|\x55.?.?.?.?.?.?.?.?\x55|\x56.?.?.?.?.?.?.?.?\x56|\x57.?.?.?.?.?.?.?.?\x57|\x58.?.?.?.?.?.?.?.?\x58|\x59.?.?.?.?.?.?.?.?\x59|\x5a.?.?.?.?.?.?.?.?\x5a|\[.?.?.?.?.?.?.?.?\[|\\.?.?.?.?.?.?.?.?\\|\].?.?.?.?.?.?.?.?\]|\^.?.?.?.?.?.?.?.?\^|\x5f.?.?.?.?.?.?.?.?\x5f|\x60.?.?.?.?.?.?.?.?\x60|\x61.?.?.?.?.?.?.?.?\x61|\x62.?.?.?.?.?.?.?.?\x62|\x63.?.?.?.?.?.?.?.?\x63|\x64.?.?.?.?.?.?.?.?\x64|\x65.?.?.?.?.?.?.?.?\x65|\x66.?.?.?.?.?.?.?.?\x66|\x67.?.?.?.?.?.?.?.?\x67|\x68.?.?.?.?.?.?.?.?\x68|\x69.?.?.?.?.?.?.?.?\x69|\x6a.?.?.?.?.?.?.?.?\x6a|\x6b.?.?.?.?.?.?.?.?\x6b|\x6c.?.?.?.?.?.?.?.?\x6c|\x6d.?.?.?.?.?.?.?.?\x6d|\x6e.?.?.?.?.?.?.?.?\x6e|\x6f.?.?.?.?.?.?.?.?\x6f|\x70.?.?.?.?.?.?.?.?\x70|\x71.?.?.?.?.?.?.?.?\x71|\x72.?.?.?.?.?.?.?.?\x72|\x73.?.?.?.?.?.?.?.?\x73|\x74.?.?.?.?.?.?.?.?\x74|\x75.?.?.?.?.?.?.?.?\x75|\x76.?.?.?.?.?.?.?.?\x76|\x77.?.?.?.?.?.?.?.?\x77|\x78.?.?.?.?.?.?.?.?\x78|\x79.?.?.?.?.?.?.?.?\x79|\x7a.?.?.?.?.?.?.?.?\x7a|\{.?.?.?.?.?.?.?.?\{|\|.?.?.?.?.?.?.?.?\||\}.?.?.?.?.?.?.?.?\}|\x7e.?.?.?.?.?.?.?.?\x7e|\x7f.?.?.?.?.?.?.?.?\x7f|\x80.?.?.?.?.?.?.?.?\x80|\x81.?.?.?.?.?.?.?.?\x81|\x82.?.?.?.?.?.?.?.?\x82|\x83.?.?.?.?.?.?.?.?\x83|\x84.?.?.?.?.?.?.?.?\x84|\x85.?.?.?.?.?.?.?.?\x85|\x86.?.?.?.?.?.?.?.?\x86|\x87.?.?.?.?.?.?.?.?\x87|\x88.?.?.?.?.?.?.?.?\x88|\x89.?.?.?.?.?.?.?.?\x89|\x8a.?.?.?.?.?.?.?.?\x8a|\x8b.?.?.?.?.?.?.?.?\x8b|\x8c.?.?.?.?.?.?.?.?\x8c|\x8d.?.?.?.?.?.?.?.?\x8d|\x8e.?.?.?.?.?.?.?.?\x8e|\x8f.?.?.?.?.?.?.?.?\x8f|\x90.?.?.?.?.?.?.?.?\x90|\x91.?.?.?.?.?.?.?.?\x91|\x92.?.?.?.?.?.?.?.?\x92|\x93.?.?.?.?.?.?.?.?\x93|\x94.?.?.?.?.?.?.?.?\x94|\x95.?.?.?.?.?.?.?.?\x95|\x96.?.?.?.?.?.?.?.?\x96|\x97.?.?.?.?.?.?.?.?\x97|\x98.?.?.?.?.?.?.?.?\x98|\x99.?.?.?.?.?.?.?.?\x99|\x9a.?.?.?.?.?.?.?.?\x9a|\x9b.?.?.?.?.?.?.?.?\x9b|\x9c.?.?.?.?.?.?.?.?\x9c|\x9d.?.?.?.?.?.?.?.?\x9d|\x9e.?.?.?.?.?.?.?.?\x9e|\x9f.?.?.?.?.?.?.?.?\x9f|\xa0.?.?.?.?.?.?.?.?\xa0|\xa1.?.?.?.?.?.?.?.?\xa1|\xa2.?.?.?.?.?.?.?.?\xa2|\xa3.?.?.?.?.?.?.?.?\xa3|\xa4.?.?.?.?.?.?.?.?\xa4|\xa5.?.?.?.?.?.?.?.?\xa5|\xa6.?.?.?.?.?.?.?.?\xa6|\xa7.?.?.?.?.?.?.?.?\xa7|\xa8.?.?.?.?.?.?.?.?\xa8|\xa9.?.?.?.?.?.?.?.?\xa9|\xaa.?.?.?.?.?.?.?.?\xaa|\xab.?.?.?.?.?.?.?.?\xab|\xac.?.?.?.?.?.?.?.?\xac|\xad.?.?.?.?.?.?.?.?\xad|\xae.?.?.?.?.?.?.?.?\xae|\xaf.?.?.?.?.?.?.?.?\xaf|\xb0.?.?.?.?.?.?.?.?\xb0|\xb1.?.?.?.?.?.?.?.?\xb1|\xb2.?.?.?.?.?.?.?.?\xb2|\xb3.?.?.?.?.?.?.?.?\xb3|\xb4.?.?.?.?.?.?.?.?\xb4|\xb5.?.?.?.?.?.?.?.?\xb5|\xb6.?.?.?.?.?.?.?.?\xb6|\xb7.?.?.?.?.?.?.?.?\xb7|\xb8.?.?.?.?.?.?.?.?\xb8|\xb9.?.?.?.?.?.?.?.?\xb9|\xba.?.?.?.?.?.?.?.?\xba|\xbb.?.?.?.?.?.?.?.?\xbb|\xbc.?.?.?.?.?.?.?.?\xbc|\xbd.?.?.?.?.?.?.?.?\xbd|\xbe.?.?.?.?.?.?.?.?\xbe|\xbf.?.?.?.?.?.?.?.?\xbf|\xc0.?.?.?.?.?.?.?.?\xc0|\xc1.?.?.?.?.?.?.?.?\xc1|\xc2.?.?.?.?.?.?.?.?\xc2|\xc3.?.?.?.?.?.?.?.?\xc3|\xc4.?.?.?.?.?.?.?.?\xc4|\xc5.?.?.?.?.?.?.?.?\xc5|\xc6.?.?.?.?.?.?.?.?\xc6|\xc7.?.?.?.?.?.?.?.?\xc7|\xc8.?.?.?.?.?.?.?.?\xc8|\xc9.?.?.?.?.?.?.?.?\xc9|\xca.?.?.?.?.?.?.?.?\xca|\xcb.?.?.?.?.?.?.?.?\xcb|\xcc.?.?.?.?.?.?.?.?\xcc|\xcd.?.?.?.?.?.?.?.?\xcd|\xce.?.?.?.?.?.?.?.?\xce|\xcf.?.?.?.?.?.?.?.?\xcf|\xd0.?.?.?.?.?.?.?.?\xd0|\xd1.?.?.?.?.?.?.?.?\xd1|\xd2.?.?.?.?.?.?.?.?\xd2|\xd3.?.?.?.?.?.?.?.?\xd3|\xd4.?.?.?.?.?.?.?.?\xd4|\xd5.?.?.?.?.?.?.?.?\xd5|\xd6.?.?.?.?.?.?.?.?\xd6|\xd7.?.?.?.?.?.?.?.?\xd7|\xd8.?.?.?.?.?.?.?.?\xd8|\xd9.?.?.?.?.?.?.?.?\xd9|\xda.?.?.?.?.?.?.?.?\xda|\xdb.?.?.?.?.?.?.?.?\xdb|\xdc.?.?.?.?.?.?.?.?\xdc|\xdd.?.?.?.?.?.?.?.?\xdd|\xde.?.?.?.?.?.?.?.?\xde|\xdf.?.?.?.?.?.?.?.?\xdf|\xe0.?.?.?.?.?.?.?.?\xe0|\xe1.?.?.?.?.?.?.?.?\xe1|\xe2.?.?.?.?.?.?.?.?\xe2|\xe3.?.?.?.?.?.?.?.?\xe3|\xe4.?.?.?.?.?.?.?.?\xe4|\xe5.?.?.?.?.?.?.?.?\xe5|\xe6.?.?.?.?.?.?.?.?\xe6|\xe7.?.?.?.?.?.?.?.?\xe7|\xe8.?.?.?.?.?.?.?.?\xe8|\xe9.?.?.?.?.?.?.?.?\xe9|\xea.?.?.?.?.?.?.?.?\xea|\xeb.?.?.?.?.?.?.?.?\xeb|\xec.?.?.?.?.?.?.?.?\xec|\xed.?.?.?.?.?.?.?.?\xed|\xee.?.?.?.?.?.?.?.?\xee|\xef.?.?.?.?.?.?.?.?\xef|\xf0.?.?.?.?.?.?.?.?\xf0|\xf1.?.?.?.?.?.?.?.?\xf1|\xf2.?.?.?.?.?.?.?.?\xf2|\xf3.?.?.?.?.?.?.?.?\xf3|\xf4.?.?.?.?.?.?.?.?\xf4|\xf5.?.?.?.?.?.?.?.?\xf5|\xf6.?.?.?.?.?.?.?.?\xf6|\xf7.?.?.?.?.?.?.?.?\xf7|\xf8.?.?.?.?.?.?.?.?\xf8|\xf9.?.?.?.?.?.?.?.?\xf9|\xfa.?.?.?.?.?.?.?.?\xfa|\xfb.?.?.?.?.?.?.?.?\xfb|\xfc.?.?.?.?.?.?.?.?\xfc|\xfd.?.?.?.?.?.?.?.?\xfd|\xfe.?.?.?.?.?.?.?.?\xfe|\xff.?.?.?.?.?.?.?.?\xff) diff --git a/usr/local/share/protocols/skypetoskype.pat b/usr/local/share/protocols/skypetoskype.pat new file mode 100644 index 0000000..3649492 --- /dev/null +++ b/usr/local/share/protocols/skypetoskype.pat @@ -0,0 +1,13 @@ +# Skype to Skype - UDP voice call (program to program) - http://skype.com +# Pattern attributes: ok veryfast fast overmatch +# Protocol groups: voip p2p proprietary +# Wiki: http://www.protocolinfo.org/wiki/Skype + +# This matches at least some of the general chatter that occurs when the +# user isn't doing anything as well as actual calls. +# Thanks to Myles Uyema, mylesuyema AT gmail.com + +skypetoskype +# require at least 16 bytes (my limited tests always get at least 18) +^..\x02............. + diff --git a/usr/local/share/protocols/smb.pat b/usr/local/share/protocols/smb.pat new file mode 100644 index 0000000..cdf0fe1 --- /dev/null +++ b/usr/local/share/protocols/smb.pat @@ -0,0 +1,18 @@ +# Samba/SMB - Server Message Block - Microsoft Windows filesharing +# Pattern attributes: good fast notsofast +# Protocol groups: document_retrieval networking proprietary +# Wiki: http://www.protocolinfo.org/wiki/SMB +# +# "This protocol is sometimes also referred to as the Common Internet File +# System (CIFS), LanManager or NetBIOS protocol." -- "man samba" +# +# Actually, SMB is a higher level protocol than NetBIOS. However, the +# NetBIOS header is only 4 bytes: not much to match on. +# +# http://www.ubiqx.org/cifs/SMB.html +# +# This pattern is lightly tested. + +smb +# matches a NEGOTIATE PROTOCOL or TRANSACTION REQUEST command +\xffsmb[\x72\x25] diff --git a/usr/local/share/protocols/smtp.pat b/usr/local/share/protocols/smtp.pat new file mode 100644 index 0000000..eb98ae7 --- /dev/null +++ b/usr/local/share/protocols/smtp.pat @@ -0,0 +1,39 @@ +# SMTP - Simple Mail Transfer Protocol - RFC 2821 (See also RFC 1869) +# Pattern attributes: great notsofast fast +# Protocol groups: mail ietf_internet_standard +# Wiki: http://www.protocolinfo.org/wiki/SMTP +# +# usually runs on port 25 +# +# This pattern has been tested and is believed to work well. + +# As usual, no text is required after "220", but all known servers have some +# there. It (almost?) always has string "smtp" in it. The RFC examples +# does not, so we match those too, just in case anyone has copied them +# literally. +# +# Some examples: +# 220 mail.stalker.com ESMTP CommuniGate Pro 4.1.3 +# 220 mail.vieodata.com ESMTP Merak 6.1.0; Mon, 15 Sep 2003 13:48:11 -0400 +# 220 mail.ut.caldera.com ESMTP +# 220 persephone.pmail.gen.nz ESMTP server ready. +# 220 smtp1.superb.net ESMTP +# 220 mail.kerio.com Kerio MailServer 5.6.7 ESMTP ready +# 220-mail.deerfield.com ESMTP VisNetic.MailServer.v6.0.9.0; Mon, 15 Sep 2003 13:4 +# 220 altn.com ESMTP MDaemon 6.8.5; Mon, 15 Sep 2003 12:46:42 -0500 +# 220 X1 NT-ESMTP Server ipsmin0165atl2.interland.net (IMail 6.06 73062-3) +# 220 mail.icewarp.com ESMTP Merak 6.1.1; Mon, 15 Sep 2003 19:43:23 +0200 +# 220-mail.email-scan.com ESMTP +# 220 smaug.dreamhost.com ESMTP +# 220 kona.carleton.edu -- Server ESMTP (PMDF V6.2#30648) +# 220 letra.reed.edu ESMTP Sendmail 8.12.9/8.12.9; Mon, 15 Sep 2003 10:35:57 -0700 (PDT) +# 220-swan.mail.pas.earthlink.net ESMTP Exim 3.33 #1 Mon, 15 Sep 2003 10:32:15 -0700 +# +# RFC examples: +# 220 xyz.com Simple Mail Transfer Service Ready (RFC example) +# 220 dbc.mtview.ca.us SMTP service ready + +smtp +^220[\x09-\x0d -~]* (e?smtp|simple mail) +userspace pattern=^220[\x09-\x0d -~]* (E?SMTP|[Ss]imple [Mm]ail) +userspace flags=REG_NOSUB REG_EXTENDED diff --git a/usr/local/share/protocols/snmp.pat b/usr/local/share/protocols/snmp.pat new file mode 100644 index 0000000..5b88f03 --- /dev/null +++ b/usr/local/share/protocols/snmp.pat @@ -0,0 +1,18 @@ +# SNMP - Simple Network Management Protocol - RFC 1157 +# Pattern attributes: good veryfast fast superset +# Protocol groups: networking ietf_internet_standard +# Wiki: http://www.protocolinfo.org/wiki/SNMP +# +# Usually runs on UDP ports 161 (monitoring) and 162 (traps). +# +# These filters match SNMPv1 packets without fail, and are made as +# specific as possible not to match any ASN.1 encoded protocols. However +# these could still be matched by other protocols that use ASN.1 encoding + +# Contributed by Goli SriSairam <goli_sai AT yahoo.com> + +# This pattern has been tested and is believed to work well. + +# All SNMPv1 traffic. See snmp-mon.pat and snmp-trap.pat for details. +snmp +^\x02\x01\x04.+([\xa0-\xa3]\x02[\x01-\x04].?.?.?.?\x02\x01.?\x02\x01.?\x30|\xa4\x06.+\x40\x04.?.?.?.?\x02\x01.?\x02\x01.?\x43) diff --git a/usr/local/share/protocols/socks.pat b/usr/local/share/protocols/socks.pat new file mode 100644 index 0000000..a7501a8 --- /dev/null +++ b/usr/local/share/protocols/socks.pat @@ -0,0 +1,31 @@ +# SOCKS Version 5 - Firewall traversal protocol - RFC 1928 +# Pattern attributes: good notsofast notsofast +# Protocol groups: networking ietf_proposed_standard +# Wiki: http://www.protocolinfo.org/wiki/SOCKS +# +# Usually runs on port 1080 +# Also useful: http://www.iana.org/assignments/socks-methods +# +# We have had two reports that this pattern works. + +# method request, no private methods \x05[\x01-\x08]* +# method reply, assumes sucess \x05[\x01-\x08]? +# method dependent sub-negotiation .* +# request, ipv4 only \x05[\x01-\x03][\x01\x03].* +# reply \x05[\x01-\x08]?[\x01\x03].* + +# username/password method +# u/p request, assuming reasonable usernames and passwords +# \x05[\x02-\x10][a-z][a-z0-9\-]*[\x05-\x20][!-~]* +# server reply +# \x05 + +# GSSAPI method +# client initial token \x01\x01\x02.* +# server reply \x01\x01\x02.* + +# any other method .* (all methods boil down to this until we have information +# about all the commonly used ones) + +socks +\x05[\x01-\x08]*\x05[\x01-\x08]?.*\x05[\x01-\x03][\x01\x03].*\x05[\x01-\x08]?[\x01\x03] diff --git a/usr/local/share/protocols/soribada.pat b/usr/local/share/protocols/soribada.pat new file mode 100644 index 0000000..a5da9fd --- /dev/null +++ b/usr/local/share/protocols/soribada.pat @@ -0,0 +1,50 @@ +# Soribada - A Korean P2P filesharing program/protocol - http://www.soribada.com +# Pattern attributes: good slow notsofast +# Protocol groups: p2p +# Wiki: http://www.protocolinfo.org/wiki/Soribada + +# I am told that there are three versions of this protocol, the first no +# longer being used. That would probably explain why incoming searches +# have two different formats... + +# There are three parts to Soribada protocal: +# 1: Ping/Pong to establish a relationship on the net (UDP with 2 useful bytes) +# 2: Searching (in two formats) (UDP with two short easy to match starts) +# 3: Download requests/transfers (TCP with an obvious first packet) + +# 1 -- Pings/Pongs: +# Requester send 2 bytes and a 6 byte response is sent back. +# \x10 for the first byte and \x14-\x16 for the second. +# The response is the first byte (\x10) and the second byte incremented +# by 1 (\x15-\x17). +# No further communication happens between the hosts except for searches. +# A regex match: ^\x10[\x14-\x16]\x10[\x15-\x17].?.?.?.?$ +# First Packet ---^^^^^^^^^^^^^^^ +# Second Packet -----------------^^^^^^^^^^^^^^^^^^^^^^^ + +# 2 -- Search requests: +# All searches are totally stateless and are only responded to if the user +# actually has the file. +# Both format start with a \x01 byte, have 3 "random bytes" and then 3 bytes +# corasponding to one of two formats. +# Format 1 is \x51\x3a\+ and format 2 is \x51\x32\x3a +# A regex match: ^\x01.?.?.?(\x51\x3a\+|\x51\x32\x3a) + +# 3 -- Download requests: +# All downloads start with "GETMP3\x0d\x0aFilename" +# A regex match: ^GETMP3\x0d\x0aFilename + +soribada + +# This will match the second packet of two. +# ^\x10[\x14-\x16]\x10[\x15-\x17].?.?.?.?$ + +# Again, matching this is the end of the comunication. +# ^\x01.?.?.?(\x51\x3a\+|\x51\x32\x3a) + +# This is the start of the transfer and an easy match +#^GETMP3\x0d\x0aFilename + +# This will match everything including the udp packet portions +^GETMP3\x0d\x0aFilename|^\x01.?.?.?(\x51\x3a\+|\x51\x32\x3a)|^\x10[\x14-\x16]\x10[\x15-\x17].?.?.?.?$ + diff --git a/usr/local/share/protocols/soulseek.pat b/usr/local/share/protocols/soulseek.pat new file mode 100644 index 0000000..4385141 --- /dev/null +++ b/usr/local/share/protocols/soulseek.pat @@ -0,0 +1,16 @@ +# Soulseek - P2P filesharing - http://slsknet.org +# Pattern attributes: good fast fast +# Protocol groups: p2p +# Wiki: http://www.protocolinfo.org/wiki/Soulseek +# +# All my tests show that this pattern is fast, but one user has reported that +# it is slow. Your milage may vary. + +# This has been tested and works for "pierce firewall" commands and file +# transfers. It does *not* match all the various sorts of chatter that go on, +# such as searches, pings and whatnot. + +soulseek +# (Pierce firewall: in theory the token could be 4 bytes, but the last two +# seem to always be zero.|download: Peer Init) +^(\x05..?|.\x01.[ -~]+\x01F..?.?.?.?.?.?.?)$ diff --git a/usr/local/share/protocols/ssdp.pat b/usr/local/share/protocols/ssdp.pat new file mode 100644 index 0000000..db50362 --- /dev/null +++ b/usr/local/share/protocols/ssdp.pat @@ -0,0 +1,20 @@ +# SSDP - Simple Service Discovery Protocol - easy discovery of network devices +# Pattern attributes: good slow notsofast +# Protocol groups: networking ietf_draft_standard +# Wiki: http://www.protocolinfo.org/wiki/SSDP + +# This pattern was tested only by listening to a Linksys WRT54G. However, +# I expect it works in general given the simplicity of the protocol. + +# SSDP packets should _always_ be sent to the multicast address +# 239.255.255.250, making this pattern irrelevant. (Moreover, SSDP +# packets should be resitricted to local networks that have plenty of +# bandwidth.) However, Microsoft, as usual, has other ideas, so maybe +# it could be useful. Can't hurt, anyway. :-) +# +# http://www.upnp.org/download/draft_cai_ssdp_v1_03.txt +# http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/ssdp.asp + +ssdp +^notify[\x09-\x0d ]\*[\x09-\x0d ]http/1\.1[\x09-\x0d -~]*ssdp:(alive|byebye)|^m-search[\x09-\x0d ]\*[\x09-\x0d ]http/1\.1[\x09-\x0d -~]*ssdp:discover + diff --git a/usr/local/share/protocols/ssh.pat b/usr/local/share/protocols/ssh.pat new file mode 100644 index 0000000..adffe9e --- /dev/null +++ b/usr/local/share/protocols/ssh.pat @@ -0,0 +1,16 @@ +# SSH - Secure SHell +# Pattern attributes: great veryfast fast +# Protocol groups: remote_access secure ietf_draft_standard +# Wiki: http://www.protocolinfo.org/wiki/SSH +# +# usually runs on port 22 +# +# http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-22.txt +# +# This pattern has been tested and is believed to work well. + +ssh +^ssh-[12]\.[0-9] + +# old pattern: +# (diffie-hellman-group-exchange-sha1|diffie-hellman-group1-sha1.ssh-rsa|ssh-dssfaes128-cbc|3des-cbc|blowfish-cbc|cast128-cbc|arcfour|aes192-cbc|aes256-cbc|rijndael-cbc@lysator.liu.sefaes128-cbc|3des-cbc|blowfish-cbc|cast128-cbc|arcfour|aes192-cbc|aes256-cbc|rijndael-cbc@lysator.liu.seuhmac-md5|hmac-sha1|hmac-ripemd160)+ diff --git a/usr/local/share/protocols/ssl.pat b/usr/local/share/protocols/ssl.pat new file mode 100644 index 0000000..a10589a1 --- /dev/null +++ b/usr/local/share/protocols/ssl.pat @@ -0,0 +1,15 @@ +# SSL and TLS - Secure Socket Layer / Transport Layer Security - RFC 2246 +# Pattern attributes: good notsofast fast superset +# Protocol groups: secure ietf_proposed_standard +# Wiki: http://www.protocolinfo.org/wiki/SSL +# +# Usually runs on port 443 +# +# This is a superset of validcertssl. For it to match, it must be first. +# +# This pattern has been tested and is believed to work well. + +ssl +# Server Hello with certificate | Client Hello +# This allows SSL 3.X, which includes TLS 1.0, known internally as SSL 3.1 +^(.?.?\x16\x03.*\x16\x03|.?.?\x01\x03\x01?.*\x0b) diff --git a/usr/local/share/protocols/stun.pat b/usr/local/share/protocols/stun.pat new file mode 100644 index 0000000..5f0f58a --- /dev/null +++ b/usr/local/share/protocols/stun.pat @@ -0,0 +1,45 @@ +# STUN - Simple Traversal of UDP Through NAT - RFC 3489 +# Pattern attributes: ok veryfast fast +# Protocol groups: networking ietf_proposed_standard +# Wiki: http://www.protocolinfo.org/wiki/STUN +# +# This pattern is untested as far as I know. + +# Wikipedia says: "The STUN server is contacted on UDP port 3478, +# however the server will hint clients to perform tests on alternate IP +# and port number too (STUN servers have two IP addresses). The RFC +# states that this port and IP are arbitrary." + +stun +# \x01 is a Binding Request. \x02 is a Shared Secret Request. Binding +# Requests are, experimentally, exactly 20 Bytes with three NULL Bytes. +# The first NULL is part of the two byte message type field. The other +# two give the message length, zero. I'm guessing that Shared Secret +# Requests are similar, but I have not checked. Please read the RFC and +# do experiments to find out. All other message types are responses, +# and so don't matter. +# +# The .? allows one of the Message Transaction ID Bytes to be \x00. If +# two are \x00, it will fail. This will happen 0.37% of the time, since +# the Message Transaction ID is supposed to be random. If this is +# unacceptable to you, add another ? to reduce this to 0.020%, but be +# aware of the increased possibility of false positives. +^[\x01\x02]................?$ + +# From my post to the mailing list: +# http://sourceforge.net/mailarchive/message.php?msg_id=36787107 +# +# This is a rather permissive pattern, but you can make it a little better +# by combining it with another iptables rule that checks that the packet +# data is exactly 20 Bytes. Of course, the second packet is longer, so +# maybe that introduces more complications than benefits. +# +# If you're willing to wait until the second packet to make the +# identification, you could use this: +# +# ^\x01................?\x01\x01 +# +# or if the Message Length is always \x24 (I'm not sure it is from your +# single example): +# +# ^\x01................?\x01\x01\x24 diff --git a/usr/local/share/protocols/subspace.pat b/usr/local/share/protocols/subspace.pat new file mode 100644 index 0000000..57dabf1 --- /dev/null +++ b/usr/local/share/protocols/subspace.pat @@ -0,0 +1,20 @@ +# Subspace - 2D asteroids-style space game - http://sscentral.com +# Pattern attributes: marginal veryfast fast +# Protocol groups: game +# Wiki: http://www.protocolinfo.org/wiki/Subspace +# +# By Myles Uyema <mylesuyema AT gmail.com> +# +# This pattern matches the initial 2 packets of the client-server +# 'handshake' when joining a Zone. +# +# The first packet is an 8 byte UDP payload sent from client +# 0x00 0x01 0x?? 0x?? 0x?? 0x?? 0x11 +# The next packet is a 12 byte UDP response from server +# 0x00 0x10 0x?? 0x?? 0x?? 0x?? 0x?? 0x?? 0x?? 0x?? 0x01 0x00 +# +# l7-filter strips out the null bytes, leaving me with this pattern + +subspace +^\x01....\x11\x10........\x01$ + diff --git a/usr/local/share/protocols/subversion.pat b/usr/local/share/protocols/subversion.pat new file mode 100644 index 0000000..cc5ec3b --- /dev/null +++ b/usr/local/share/protocols/subversion.pat @@ -0,0 +1,12 @@ +# Subversion - a version control system +# Pattern attributes: ok veryfast fast +# Protocol groups: version_control open_source +# Wiki: http://www.protocolinfo.org/wiki/Subversion +# +# This pattern is UNTESTED. (But it seems straightforward enough...) +# +# Subversion uses TCP port 3690 by default. + +subversion +# This is not a valid basic GNU regular expression. +^\( success \( 1 2 \( diff --git a/usr/local/share/protocols/teamfortress2.pat b/usr/local/share/protocols/teamfortress2.pat new file mode 100644 index 0000000..83fb960 --- /dev/null +++ b/usr/local/share/protocols/teamfortress2.pat @@ -0,0 +1,10 @@ +# Team Fortress 2 - network game - http://www.valvesoftware.com +# Pattern attributes: good veryfast fast +# Protocol groups: game proprietary +# Wiki: http://www.protocolinfo.org/wiki/Team_Fortress +# +# Credits: Clayton Macleod <cherry twist at gmail dot com> +# Jan Engelhardt <jengelh at computergmbh dot de> + +teamfortress2 +^\xff\xff\xff\xff.....*tfTeam Fortress diff --git a/usr/local/share/protocols/teamspeak.pat b/usr/local/share/protocols/teamspeak.pat new file mode 100644 index 0000000..e83569f --- /dev/null +++ b/usr/local/share/protocols/teamspeak.pat @@ -0,0 +1,14 @@ +# TeamSpeak - VoIP application - http://goteamspeak.com +# Pattern attributes: good veryfast fast +# Protocol groups: voip proprietary +# Wiki: http://www.protocolinfo.org/wiki/TeamSpeak +# +# This pattern has been tested by Matthew Strait and verified by packet +# traces by at least two other people. The meaning of f4b303 is not +# known, but it seems to appear in all first packets. This pattern only +# matches the actual UDP voice traffic, not the TeamSpeak web interface +# or "TCP query". + +teamspeak +^\xf4\xbe\x03.*teamspeak + diff --git a/usr/local/share/protocols/telnet.pat b/usr/local/share/protocols/telnet.pat new file mode 100644 index 0000000..a93d17d --- /dev/null +++ b/usr/local/share/protocols/telnet.pat @@ -0,0 +1,15 @@ +# Telnet - Insecure remote login - RFC 854 +# Pattern attributes: good veryfast fast +# Protocol groups: remote_access obsolete ietf_internet_standard +# Wiki: http://www.protocolinfo.org/wiki/Telnet +# +# Usually runs on port 23 +# +# This pattern is lightly tested. + +telnet +# Matches at least three IAC (Do|Will|Don't|Won't) commands in a row. +# My telnet client sends 9 when I connect, so this should be fine. +# This pattern could fail on a unchatty connection or it could be +# matched by something non-telnet spewing a lot of stuff in the fb-ff range. +^\xff[\xfb-\xfe].\xff[\xfb-\xfe].\xff[\xfb-\xfe] diff --git a/usr/local/share/protocols/tesla.pat b/usr/local/share/protocols/tesla.pat new file mode 100644 index 0000000..f9fdece --- /dev/null +++ b/usr/local/share/protocols/tesla.pat @@ -0,0 +1,14 @@ +# Tesla Advanced Communication - P2P filesharing (?) +# Pattern attributes: marginal slow notsofast +# Protocol groups: p2p +# Wiki: http://www.protocolinfo.org/wiki/Tesla +# +# This pattern is untested! + +# This is lifted from http://oofle.com/filesharing.php?app=tesla +# There is no explaination of what these numbers mean. +# The above page says that the first string is found only in TCP packets +# and the second only in UDP. + +tesla +\x03\x9a\x89\x22\x31\x31\x31\.\x30\x30\x20\x42\x65\x74\x61\x20|\xe2\x3c\x69\x1e\x1c\xe9 diff --git a/usr/local/share/protocols/tftp.pat b/usr/local/share/protocols/tftp.pat new file mode 100644 index 0000000..e9f16f7 --- /dev/null +++ b/usr/local/share/protocols/tftp.pat @@ -0,0 +1,20 @@ +# TFTP - Trivial File Transfer Protocol - used for bootstrapping - RFC 1350 +# Pattern attributes: marginal veryfast fast +# Protocol groups: document_retrieval ietf_internet_standard +# Wiki: http://www.protocolinfo.org/wiki/TFTP +# +# usually runs on port 69 +# +# This pattern is unconfirmed. + +tftp +# The first packet from the initiating host should either be a Read Request +# or a Write Request. In the other direction, it should be data packet with +# block number one or an ACK with block number zero. We only attempt to match +# the initiating host's packets, because the only identifying features of +# the responses to them are two byte sequences (which isn't specific enough). +# (\x01|\x02) = Read Request or Write Request +# [ -~]* = the file name +# the rest = netascii|octet|mail (case insensitivity done by the kernel) + +^(\x01|\x02)[ -~]*(netascii|octet|mail) diff --git a/usr/local/share/protocols/thecircle.pat b/usr/local/share/protocols/thecircle.pat new file mode 100644 index 0000000..a161531 --- /dev/null +++ b/usr/local/share/protocols/thecircle.pat @@ -0,0 +1,11 @@ +# The Circle - P2P application - http://thecircle.org.au +# Pattern attributes: ok veryfast fast +# Protocol groups: p2p open_source +# Wiki: http://www.protocolinfo.org/wiki/The_Circle + +# This is tested with The Circle 0.41c on Linux. +# It likely misses some stuff. Notably, I wasn't able to test it on any +# large downloads, because no one is sharing anything! + +thecircle +^t\x03ni.?[\x01-\x06]?t[\x01-\x05]s[\x0a\x0b](glob|who are you$|query data) diff --git a/usr/local/share/protocols/tor.pat b/usr/local/share/protocols/tor.pat new file mode 100644 index 0000000..16f8884 --- /dev/null +++ b/usr/local/share/protocols/tor.pat @@ -0,0 +1,16 @@ +# Tor - The Onion Router - used for anonymization - http://tor.eff.org +# Pattern attributes: good notsofast notsofast +# Protocol groups: networking +# Wiki: http://protocolinfo.org/wiki/Tor +# +# This pattern has been tested and is believed to work well. +# +# It matches on the second packet. I have no idea how the protocol +# works, but this matches every stream I have made using Tor 0.1.0.16 as +# a client on Linux. +# +# It does NOT attempt to match the HTTP request that fetches the list of +# Tor servers. + +tor +TOR1.*<identity> diff --git a/usr/local/share/protocols/tsp.pat b/usr/local/share/protocols/tsp.pat new file mode 100644 index 0000000..e704ce0 --- /dev/null +++ b/usr/local/share/protocols/tsp.pat @@ -0,0 +1,13 @@ +# TSP - Berkely UNIX Time Synchronization Protocol +# Pattern attributes: good veryfast fast overmatch +# Protocol groups: time_synchronization open_source +# Wiki: http://www.protocolinfo.org/wiki/TSP +# +# http://ftp.svbug.com/ftp/pub/manuals/pdf/smm.22.timed.pdf +# http://docs.freebsd.org/44doc/smm/12.timed/paper.pdf +# +# This pattern is barely tested. + +tsp +# type, version (1), sequence number, 8 type specific bytes, machine name +^[\x01-\x13\x16-$]\x01.?.?.?.?.?.?.?.?.?.?[ -~]+ diff --git a/usr/local/share/protocols/unknown.pat b/usr/local/share/protocols/unknown.pat new file mode 100644 index 0000000..1c1c166 --- /dev/null +++ b/usr/local/share/protocols/unknown.pat @@ -0,0 +1,7 @@ +# Unknown - Dummy pattern for old unmatched connections. + +unknown +# This pattern is ignored by the kernel. It sees that the "protocol" is +# "unknown" and always returns unmatched for connections that are still +# being tested. +. diff --git a/usr/local/share/protocols/unset.pat b/usr/local/share/protocols/unset.pat new file mode 100644 index 0000000..80950c9 --- /dev/null +++ b/usr/local/share/protocols/unset.pat @@ -0,0 +1,8 @@ +# Unset - Dummy pattern for unmatched connections that are still being tested + +unset +# This pattern is ignored by the kernel. It sees that the "protocol" is +# "testing" and always returns matched for connections that are still +# being tested. +# NOT YET IMPLEMENTED. +. diff --git a/usr/local/share/protocols/uucp.pat b/usr/local/share/protocols/uucp.pat new file mode 100644 index 0000000..c7685cd --- /dev/null +++ b/usr/local/share/protocols/uucp.pat @@ -0,0 +1,11 @@ +# UUCP - Unix to Unix Copy +# Pattern attributes: ok veryfast fast +# Protocol groups: document_retrieval obsolete +# Wiki: http://www.protocolinfo.org/wiki/UUCP + +# This is completely untested! (I don't know how to use UUCP...) + +# See http://docs.freebsd.org/info/uucp/uucp.info.The_Initial_Handshake.html + +uucp +^\x10here= diff --git a/usr/local/share/protocols/validcertssl.pat b/usr/local/share/protocols/validcertssl.pat new file mode 100644 index 0000000..c004517 --- /dev/null +++ b/usr/local/share/protocols/validcertssl.pat @@ -0,0 +1,24 @@ +# Valid certificate SSL +# Pattern attributes: good notsofast notsofast subset +# Protocol groups: secure ietf_proposed_standard +# Wiki: http://www.protocolinfo.org/wiki/SSL + +# This matches anything claiming to use a valid certificate from a well +# known certificate authority. +# +# This is a subset of ssl, so it needs to come first to match. +# +# Note that opening a website that has a valid certificate will +# open one connection that matches this and many ssl connections that +# only match the ssl pattern. Thus, this pattern may not be very useful. +# +# This pattern is believed match only the above, but may not match all +# of it. +# +# the certificate authority info is sent in quasi plain text, if it matches +# a well known certificate authority then we will assume it is a +# web/imaps/etc server. Other ssl may be good too, but it should fall under +# a different rule + +validcertssl +^(.?.?\x16\x03.*\x16\x03|.?.?\x01\x03\x01?.*\x0b).*(thawte|equifax secure|rsa data security, inc|verisign, inc|gte cybertrust root|entrust\.net limited) diff --git a/usr/local/share/protocols/ventrilo.pat b/usr/local/share/protocols/ventrilo.pat new file mode 100644 index 0000000..7ee9c13 --- /dev/null +++ b/usr/local/share/protocols/ventrilo.pat @@ -0,0 +1,17 @@ +# Ventrilo - VoIP - http://ventrilo.com +# Pattern attributes: good fast fast +# Protocol groups: voip proprietary +# Wiki: http://www.protocolinfo.org/wiki/Ventrilo +# +# I have tested this with Ventrilo client 2.3.0 on Windows talking to +# Ventrilo server 2.3.1 (the public version) on Linux. I've done this +# both within a LAN and over the Internet. In one test, I tried +# monkeying around with the server settings to see if I could break the +# pattern, and I couldn't. However, you can't change the port number in +# the public server. +# +# It has also been tested by one other person in an unknown configuration. + +ventrilo +^..?v\$\xcf + diff --git a/usr/local/share/protocols/vnc.pat b/usr/local/share/protocols/vnc.pat new file mode 100644 index 0000000..9f77fdf --- /dev/null +++ b/usr/local/share/protocols/vnc.pat @@ -0,0 +1,22 @@ +# VNC - Virtual Network Computing. Also known as RFB - Remote Frame Buffer +# Pattern attributes: great veryfast fast +# Protocol groups: remote_access +# Wiki: http://www.protocolinfo.org/wiki/VNC +# +# http://www.realvnc.com/documentation.html +# +# This pattern has been verified with vnc v3.3.7 on WinXP and Linux +# +# Thanks to Trevor Paskett <tpaskett AT cymphonix.com> for this pattern. + +vnc +# Assumes single digit major and minor version numbers +# This message should be all alone in the first packet, so ^$ is appropriate +^rfb 00[1-9]\.00[0-9]\x0a$ + +# This is a more restrictive version which assumes the version numbers +# are ones actually in existance at the time of this writing, i.e. 3.3, +# 3.7 and 3.8 (with some clients wrongly reporting 3.5). It should be +# slightly faster, but probably not worth the extra maintenance. +# ^rfb 003\.00[3578]\x0a$ + diff --git a/usr/local/share/protocols/whois.pat b/usr/local/share/protocols/whois.pat new file mode 100644 index 0000000..0c8d0d0 --- /dev/null +++ b/usr/local/share/protocols/whois.pat @@ -0,0 +1,13 @@ +# Whois - query/response system, usually used for domain name info - RFC 3912 +# Pattern attributes: good notsofast notsofast overmatch +# Protocol groups: networking ietf_draft_standard +# Wiki: http://www.protocolinfo.org/wiki/Whois +# +# Usually runs on TCP port 43 +# +# This pattern has been tested and is believed to work well. + +whois +# Matches the query. Assumes only that it is printable ASCII without wierd +# whitespace. +^[ !-~]+\x0d\x0a$ diff --git a/usr/local/share/protocols/worldofwarcraft.pat b/usr/local/share/protocols/worldofwarcraft.pat new file mode 100644 index 0000000..dae2643 --- /dev/null +++ b/usr/local/share/protocols/worldofwarcraft.pat @@ -0,0 +1,65 @@ +# World of Warcraft - popular network game - http://blizzard.com/ +# Pattern attributes: ok veryfast fast +# Protocol groups: game proprietary +# Wiki: http://www.protocolinfo.org/wiki/World_of_Warcraft + +worldofwarcraft +^\x06\xec\x01 + +# Quoth the author of this pattern, Weisskopf Beat <weisb AT bfh.ch>: + +# I have written a pattern for wow (tested with versions 1.8.3 and +# 1.8.4, german edition). It does not match the login as i think this is +# uncritical, but i have added the necessary info later on. So only the +# actual in-game traffic is matched. +# +# I hope the pattern is specific enough, otherwise one may add some +# bytes from the response. +# +# some captured info: +# +# login: +# +# 0000: 00 02 28 00 57 6F 57 00 01 08 03 C7 12 36 38 78 ..(.WoW......68x +# 0010: 00 6E 69 57 00 45 44 65 64 3C 00 00 00 C0 A8 01 .niW.EDed<...... +# 0020: 22 0A 42 57 45 49 53 53 4B 4F 50 46 ".BWEISSKOPF +# +# 0000: 00 02 28 00 57 6F 57 00 01 08 03 C7 12 36 38 78 ..(.WoW......68x +# 0010: 00 6E 69 57 00 45 44 65 64 3C 00 00 00 C0 A8 01 .niW.EDed<...... +# 0020: 22 0A 42 57 45 49 53 53 4B 4F 50 46 ".BWEISSKOPF +# +# server asking: +# +# #1 +# 0000: 00 06 EC 01 04 49 C5 33 .....I.3 +# +# #2 +# 0000: 00 06 EC 01 C3 A8 6E 63 ......nc +# +# client response +# #1 +# 0000: 00 A4 ED 01 00 00 C7 12 00 00 00 00 00 00 42 57 ..............BW +# 0010: 45 49 53 53 4B 4F 50 46 00 EB 35 DC 89 5A CA 6D EISSKOPF..5..Z.m +# 0020: 17 95 DE 5B 74 6E 1E 5D 23 73 C6 8F 27 9F 11 12 ...[tn.]#s..'... +# 0030: BB 21 01 00 00 78 9C 75 CC 41 0A 83 50 0C 84 E1 .!...x.u.A..P... +# 0040: E7 3D 7A 19 75 25 D4 4D AB EB 12 5E A2 0C 8D 51 .=z.u%.M...^...Q +# 0050: D2 57 04 4F DF 2E 2D A4 B3 FD 86 3F A5 EF 1A C5 .W.O..-....?.... +# 0060: 71 90 F3 A3 7E E7 82 D5 C6 2E 55 CB 7E B9 FE 58 q...~.....U.~..X +# 0070: 43 A5 A8 4C 10 E5 1E 86 85 B6 E8 04 63 D8 1C 06 C..L........c... +# 0080: 5A A7 A9 84 D2 D9 6B 93 1C 5B 4F D9 D7 50 6E 04 Z.....k..[O..Pn. +# 0090: 0E 61 20 15 8B 6B 83 13 CB FD 09 D5 7F 0C 13 3F .a ..k.........? +# 00A0: DB 07 B4 EA 54 F8 ....T. +# +# #2 +# 0000: 00 A4 ED 01 00 00 C7 12 00 00 00 00 00 00 42 57 ..............BW +# 0010: 45 49 53 53 4B 4F 50 46 00 38 4C B5 95 C3 AD 25 EISSKOPF.8L....% +# 0020: CB 73 48 BD 82 FC 99 63 59 AC BF F3 D0 C6 8D AB .sH....cY....... +# 0030: 3D 21 01 00 00 78 9C 75 CC 41 0A 83 50 0C 84 E1 =!...x.u.A..P... +# 0040: E7 3D 7A 19 75 25 D4 4D AB EB 12 5E A2 0C 8D 51 .=z.u%.M...^...Q +# 0050: D2 57 04 4F DF 2E 2D A4 B3 FD 86 3F A5 EF 1A C5 .W.O..-....?.... +# 0060: 71 90 F3 A3 7E E7 82 D5 C6 2E 55 CB 7E B9 FE 58 q...~.....U.~..X +# 0070: 43 A5 A8 4C 10 E5 1E 86 85 B6 E8 04 63 D8 1C 06 C..L........c... +# 0080: 5A A7 A9 84 D2 D9 6B 93 1C 5B 4F D9 D7 50 6E 04 Z.....k..[O..Pn. +# 0090: 0E 61 20 15 8B 6B 83 13 CB FD 09 D5 7F 0C 13 3F .a ..k.........? +# 00A0: DB 07 B4 EA 54 F8 ....T. + diff --git a/usr/local/share/protocols/x11.pat b/usr/local/share/protocols/x11.pat new file mode 100644 index 0000000..f42b98f --- /dev/null +++ b/usr/local/share/protocols/x11.pat @@ -0,0 +1,22 @@ +# X Windows Version 11 - Networked GUI system used in most Unices +# Pattern attributes: good notsofast fast +# Protocol groups: remote_access x_consortium_standard +# Wiki: http://www.protocolinfo.org/wiki/X11 +# +# It is common for X to be tunneled through SSH. Then obviously this pattern +# will not catch it. +# +# Specification: http://www.msu.edu/~huntharo/xwin/docs/xwindows/PROTO.pdf +# Usually runs on port 6000 (6001 for the second server on a host, etc) +# +# This pattern has been tested. + +x11 +# 'l' = little-endian. 'B' = big endian +# ".?" is for the unused byte that comes next. If it's a null, it won't appear. +# \x0b = protocol-major-version 11. +# For some reason, protocol-minor-version is 0, not 6, so can't match it. +# This pattern is too general. +^[lb].?\x0b +userspace pattern=^[lB].?\x0b +userspace flags=REG_NOSUB diff --git a/usr/local/share/protocols/xboxlive.pat b/usr/local/share/protocols/xboxlive.pat new file mode 100644 index 0000000..8d402cf --- /dev/null +++ b/usr/local/share/protocols/xboxlive.pat @@ -0,0 +1,40 @@ +# XBox Live - Console gaming +# pattern attributes: marginal slow notsofast +# Protocol groups: game proprietary +# Wiki: http://www.protocolinfo.org/wiki/XBox_Live +# +# This may match all XBox traffic, or may only match Halo 2 traffic. +# We don't know yet. +# +# Thanks to Myles Uyema <mylesuyema AT gmail DOT com>, who says: +# +# Analyzing packet traces using Ethereal, the Xbox typically connects +# to remote users using UDP port 3074. The first frame is typically +# a 156 byte UDP payload. I've only scrutinized the first 20 or so bytes. +# +# Each line below represents the first frame between my Xbox and a remote +# player's IP address playing Halo2 on Xbox Live. +# +# 00 00 00 00 00 58 80 00 00 00 00 00 82 31 9e a8 05 0f c5 62 00 f3 96 08 +# 00 00 00 00 00 58 80 00 00 00 00 00 82 31 9e a8 0f 0f c5 62 00 f3 97 09 +# 00 00 00 00 00 58 80 00 00 00 00 00 82 31 9e a8 05 0f c5 62 00 f3 95 07 +# 00 00 00 00 00 58 80 00 00 00 00 00 81 87 ea 59 aa 11 ff 89 00 f3 bc 07 +# 00 00 00 00 00 58 80 00 00 00 00 00 81 87 ea 59 aa 11 ff 89 00 f3 be 09 +# 00 00 00 00 00 58 80 00 00 00 00 00 81 87 ea 59 aa 11 ff 89 00 f3 bf 0a +# 00 00 00 00 00 58 80 00 00 00 00 00 81 87 ea 59 aa 11 ff 89 00 f3 bd 08 +# 00 00 00 00 00 58 80 00 00 00 00 00 81 87 ea 59 aa 11 ff 89 00 f3 ba 05 +# 00 00 00 00 00 58 80 00 00 00 00 00 81 87 ea 59 aa 11 ff 89 00 f3 bb 06 +# 00 00 00 00 00 58 80 00 00 00 00 00 81 7f dd 14 f2 8e a3 a1 00 f3 ca 06 +# 00 00 00 00 00 58 80 00 00 00 00 00 81 7f dd 14 f2 8e a3 a1 00 f3 cc 08 +# 00 00 00 00 00 58 80 00 00 00 00 00 81 7f dd 14 f2 8e a3 a1 00 f3 c9 05 +# 00 00 00 00 00 58 80 00 00 00 00 00 8b ca 5b c0 d8 9c f8 c3 00 f3 d4 0a +# 00 00 00 00 00 58 80 00 00 00 00 00 8b ca 5b c0 d8 9c f3 c3 00 f3 d1 07 +# 00 00 00 00 00 58 80 00 00 00 00 00 8b ca 5b c0 d8 9c f8 c3 00 f3 d2 08 +# 00 00 00 00 00 58 80 00 00 00 00 00 8b ca 5b c0 d8 9c f8 c3 00 f3 cf 05 +# 00 00 00 00 06 58 4e 00 00 00 e6 d9 6e ab 65 0d 63 9f 02 00 00 02 80 dd +# 00 00 00 00 06 58 4e 00 00 00 46 e2 95 74 cd f9 bc 3d 00 00 00 00 8b ca +# 00 00 00 00 06 58 4e 00 00 00 cf ce 3b 5c f5 f2 49 9a 00 00 00 00 8b ca +# 00 00 00 00 06 58 4e 00 00 00 a9 c0 ac c5 16 e5 c9 92 00 00 00 00 8b ca + +xboxlive +^\x58\x80........\xf3|^\x06\x58\x4e diff --git a/usr/local/share/protocols/xunlei.pat b/usr/local/share/protocols/xunlei.pat new file mode 100644 index 0000000..c362e37 --- /dev/null +++ b/usr/local/share/protocols/xunlei.pat @@ -0,0 +1,14 @@ +# Xunlei - Chinese P2P filesharing - http://xunlei.com +# Pattern attributes: good veryfast fast +# Protocol groups: p2p +# Wiki: http://www.protocolinfo.org/wiki/Xunlei +# +# This has been tested by three people. It definitely catches some +# streams. +# +# Written by wsgtrsys of www.routerclub.com. Improved by VeNoMouS. +# Improved more by wsgtrsys and platinum of bbs.chinaunix.net. + +xunlei +^[()]...?.?.?(reg|get|query) + diff --git a/usr/local/share/protocols/yahoo.pat b/usr/local/share/protocols/yahoo.pat new file mode 100644 index 0000000..537349a --- /dev/null +++ b/usr/local/share/protocols/yahoo.pat @@ -0,0 +1,26 @@ +# Yahoo messenger - an instant messenger protocol - http://yahoo.com +# Pattern attributes: good fast fast +# Protocol groups: chat proprietary +# Wiki: http://www.protocolinfo.org/wiki/Yahoo_Messenger +# +# Usually runs on port 5050 +# +# This pattern has been tested and is believed to work well. + +yahoo +# http://www.venkydude.com/articles/yahoo.htm says: +# All Yahoo commands start with YMSG. +# (Well... http://ethereal.com/faq.html#q5.32 suggests that YPNS and YHOO +# are also possible, so let's allow those) +# The next 7 bytes contain command (packet?) length and version information +# which we won't currently try to match. +# L means "YAHOO_SERVICE_VERIFY" according to Ethereal +# W means "encryption challenge command" (YAHOO_SERVICE_AUTH) +# T means "login command" (YAHOO_SERVICE_AUTHRESP) +# (there are others, i.e. 0x01 "coming online", 0x02 "going offline", +# 0x04 "changing status to available", 0x06 "user message", but W and T +# should appear in the first few packets.) +# 0xC080 is the standard argument separator, it should appear not long +# after the "type of command" byte. + +^(ymsg|ypns|yhoo).?.?.?.?.?.?.?[lwt].*\xc0\x80 diff --git a/usr/local/share/protocols/zmaap.pat b/usr/local/share/protocols/zmaap.pat new file mode 100644 index 0000000..d21ad80 --- /dev/null +++ b/usr/local/share/protocols/zmaap.pat @@ -0,0 +1,17 @@ +# ZMAAP - Zeroconf Multicast Address Allocation Protocol +# Pattern attributes: ok veryfast fast +# Protocol groups: networking ietf_draft_standard +# Wiki: http://www.protocolinfo.org/wiki/ZMAAP +# +# http://files.zeroconf.org/draft-ietf-zeroconf-zmaap-02.txt +# (Note that this reference is an Internet-Draft, and therefore must +# be considered a work in progress.) +# +# This pattern is untested! + +zmaap +# - 4 byte magic number. +# - 1 byte version. Allow 1 & 2, even though only version 1 currently exists. +# - 1 byte message type,which is either 0 or 1 +# - 1 byte address family. L7-filter only works in IPv4, so this is 1. +^\x1b\xd7\x3b\x48[\x01\x02]\x01?\x01 |
