Good morning, >>> Another approach may be to look at the packets themselves. I've no idea if >>> RTP packets have useful "headers" in them, but VoIP packets are likely to >>> share certain characteristics in terms of size and frequency. So if you see >>> a constant stream of regular size packets *both ways* between two specific >>> IPs then there is a good chance that they are an RTP stream, and if they >>> are small enough then they are likely to be voice. >> >> I was thinking about the same idea. Maybe using -m string , if there is >> useable content inside the packages.
I read through RCFs 1889 1890 3550 3551
RTP and RTP profiles
Not hundred % sure, but I have done a first guess and this is what I ended up
with:
I use shorewall to set up as much as I can. After that I add several „string
match“ rules. Final result looks like this:
Chain tcpost (1 references)
pkts bytes target prot opt in out source destination
1964K 1413M CONNMARK all -- * * 0.0.0.0/0 0.0.0.0/0
/* Copy connmark to packet mark */ CONNMARK restore mask 0xff
5982 2495K DSCP udp -- * * 0.0.0.0/0 0.0.0.0/0
udp dpts:5060:5076 mark match 0x1/0xff /* VoIP SIP */ DSCP set 0x18
677 98553 DSCP udp -- * * 0.0.0.0/0 0.0.0.0/0
udp spts:5060:5076 mark match 0x1/0xff /* VoIP SIP */ DSCP set 0x18
5982 2495K RETURN udp -- * * 0.0.0.0/0 0.0.0.0/0
udp dpts:5060:5076 mark match 0x1/0xff /* VoIP SIP */
158 17623 RETURN udp -- * * 0.0.0.0/0 0.0.0.0/0
udp spts:5060:5076 mark match 0x1/0xff /* VoIP SIP */
7 512 DSCP udp -- * * 0.0.0.0/0 0.0.0.0/0
mark match 0x1/0xff /* VoIP RTP */ DSCP set 0x28
7 512 RETURN udp -- * * 0.0.0.0/0 0.0.0.0/0
mark match 0x1/0xff /* VoIP RTP */
123 16632 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
mark match 0x4/0xff /* P2P */
13172 5741K RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
mark match 0xc/0xff /* Services deltaweb/RNS */
3 168 MARK udp -- * * 0.0.0.0/0
217.10.64.0/20 /* Sipgate */ MARK set 0x1
0 0 MARK udp -- * * 0.0.0.0/0
217.116.117.0/24 /* Sipgate */ MARK set 0x1
0 0 MARK udp -- * * 0.0.0.0/0
212.9.32.0/19 /* Sipgate */ MARK set 0x1
0 0 MARK udp -- * * 0.0.0.0/0
212.172.97.112/28 /* Easybell */ MARK set 0x1
3 168 CONNMARK udp -- * * 0.0.0.0/0 0.0.0.0/0
mark match 0x1/0xff CONNMARK save mask 0xff
3 168 RETURN udp -- * * 0.0.0.0/0 0.0.0.0/0
mark match 0x1/0xff
1006 437K MARK udp -- * * 0.0.0.0/0 0.0.0.0/0
udp dpts:5060:5076 /* SIP */ MARK set 0x1
30 2312 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0
udp spts:5060:5076 /* SIP */ MARK set 0x1
0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0
udp dpts:5004:5020 length 0:200 /* RTP */ MARK set 0x1
0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0
udp spts:5004:5020 length 0:200 /* RTP */ MARK set 0x1
336 33230 RTP udp -- * * 0.0.0.0/0 0.0.0.0/0
udp spts:5000:65535 dpts:5000:65535 length 0:200
1010 437K CONNMARK udp -- * * 0.0.0.0/0 0.0.0.0/0
mark match 0x1/0xff CONNMARK save mask 0xff
1010 437K RETURN udp -- * * 0.0.0.0/0 0.0.0.0/0
mark match 0x1/0xff
…
Chain RTP (1 references)
pkts bytes target prot opt in out source destination
0 0 MARK all -- * * 0.0.0.0/0 0.0.0.0/0
STRING match "|8000|" ALGO name kmp FROM 28 TO 29 /* PCMU */ MARK
xset 0x1/0xff
0 0 MARK all -- * * 0.0.0.0/0 0.0.0.0/0
STRING match "|8004|" ALGO name kmp FROM 28 TO 29 /* G723 */ MARK
xset 0x1/0xff
0 0 MARK all -- * * 0.0.0.0/0 0.0.0.0/0
STRING match "|8008|" ALGO name kmp FROM 28 TO 29 /* PCMA */ MARK
xset 0x1/0xff
0 0 MARK all -- * * 0.0.0.0/0 0.0.0.0/0
STRING match "|8009|" ALGO name kmp FROM 28 TO 29 /* G722 */ MARK
xset 0x1/0xff
0 0 MARK all -- * * 0.0.0.0/0 0.0.0.0/0
STRING match "|800f|" ALGO name kmp FROM 28 TO 29 /* G728 */ MARK
xset 0x1/0xff
0 0 MARK all -- * * 0.0.0.0/0 0.0.0.0/0
STRING match "|8012|" ALGO name kmp FROM 28 TO 29 /* G729 */ MARK
xset 0x1/0xff
There are two bytes in the RTP header which I had a closer look in the RFCs. I
„think“ these rules might work. There are several bits that may change, but
probably not for these codecs in SIP, if a connection has already been marked
with CONNMARK.
The RFCs say that RTP traffic must assign port from 5000: to 5000:. Also I
found out that most codecs are shorter than 160 bytes (G.711 and G722_64k)
If someone is interested in the iptables rules, feel free to contact me.
And: I am not an expert!!! This is a „best guess“ setup :)
Kind regards
-Christian Rößner
--
[*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
signature.asc
Description: Message signed with OpenPGP using GPGMail
------------------------------------------------------------------------------ Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
