1
|
# STUN - Simple Traversal of UDP Through NAT - RFC 3489
|
2
|
# Pattern attributes: ok veryfast fast
|
3
|
# Protocol groups: networking ietf_proposed_standard
|
4
|
# Wiki: http://www.protocolinfo.org/wiki/STUN
|
5
|
# Copyright (C) 2008 Matthew Strait, Ethan Sommer; See ../LICENSE
|
6
|
#
|
7
|
# This pattern is untested as far as I know.
|
8
|
|
9
|
# Wikipedia says: "The STUN server is contacted on UDP port 3478,
|
10
|
# however the server will hint clients to perform tests on alternate IP
|
11
|
# and port number too (STUN servers have two IP addresses). The RFC
|
12
|
# states that this port and IP are arbitrary."
|
13
|
|
14
|
stun
|
15
|
# \x01 is a Binding Request. \x02 is a Shared Secret Request. Binding
|
16
|
# Requests are, experimentally, exactly 20 Bytes with three NULL Bytes.
|
17
|
# The first NULL is part of the two byte message type field. The other
|
18
|
# two give the message length, zero. I'm guessing that Shared Secret
|
19
|
# Requests are similar, but I have not checked. Please read the RFC and
|
20
|
# do experiments to find out. All other message types are responses,
|
21
|
# and so don't matter.
|
22
|
#
|
23
|
# The .? allows one of the Message Transaction ID Bytes to be \x00. If
|
24
|
# two are \x00, it will fail. This will happen 0.37% of the time, since
|
25
|
# the Message Transaction ID is supposed to be random. If this is
|
26
|
# unacceptable to you, add another ? to reduce this to 0.020%, but be
|
27
|
# aware of the increased possibility of false positives.
|
28
|
^[\x01\x02]................?$
|
29
|
|
30
|
# From my post to the mailing list:
|
31
|
# http://sourceforge.net/mailarchive/message.php?msg_id=36787107
|
32
|
#
|
33
|
# This is a rather permissive pattern, but you can make it a little better
|
34
|
# by combining it with another iptables rule that checks that the packet
|
35
|
# data is exactly 20 Bytes. Of course, the second packet is longer, so
|
36
|
# maybe that introduces more complications than benefits.
|
37
|
#
|
38
|
# If you're willing to wait until the second packet to make the
|
39
|
# identification, you could use this:
|
40
|
#
|
41
|
# ^\x01................?\x01\x01
|
42
|
#
|
43
|
# or if the Message Length is always \x24 (I'm not sure it is from your
|
44
|
# single example):
|
45
|
#
|
46
|
# ^\x01................?\x01\x01\x24
|