1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
|
# RTP - Real-time Transport Protocol - RFC 3550
# Pattern attributes: ok overmatch undermatch fast fast
# Protocol groups: streaming_video ietf_internet_standard
# Wiki: http://www.protocolinfo.org/wiki/RTP
# Copyright (C) 2008 Matthew Strait, Ethan Sommer; See ../LICENSE
#
# RTP headers are *very* short and compact. They have almost nothing in
# them that can be matched by l7-filter. As RTP connections take place
# between even numbered ports, you should probably check for that before
# applying this pattern. If you want to match them along with their
# associated SIP packets, you might try setting 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.
#
# 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 next bit is a tossup. Next is the payload type, 7
# bits. I've taken likely values from the WireShark code: 0-34, 96-127
# (decimal). The rest of the header is random numbers (sequence number,
# timestamp, synchronization source identifier), so that's no help at
# all.
rtp
^\x80[\x01-"`-\x7f\x80-\xa2\xe0-\xff]?..........*\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[\x01-"`-\x7f\x80-\xa2\xe0-\xff]?..........*\x80.*\x80
|
