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