F5 looping SIP ACK packet over and over
F5 sending ACK over and over to SIP proxy server in response of 200 OK and later after max out request SIP Proxy dropping packets, it's very strange behavior, following is pcap of SIP request. You can see in last 3 ACK (there are many but i capture only 3 for this question) 70.xx.xx.202 - SNAT IP 70.xx.xx.180 - VIP Address 70.xx.xx.29 - SIP Server U 70.xx.xx.29:5060 -> 70.xx.xx.202:4371 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP 10.0.30.101:5060;branch=z9hG4bK-38590-1-0;rport=4371;received=70.xx.xx.202. From: "anon" ;tag=38590SIPpTag001. To: service . Call-ID: 1-38590@10.0.30.101. CSeq: 1 INVITE. Content-Length: 0. . U 70.xx.xx.29:5060 -> 70.xx.xx.202:4371 SIP/2.0 200 OK. Record-Route: . Via: SIP/2.0/UDP 10.0.30.101:5060;rport=4371;received=70.xx.xx.202;branch=z9hG4bK-38590-1-0. From: "anon" ;tag=38590SIPpTag001. To: service ;tag=a6a1c5f60faecf035a1ae5b6e96e979a-3c64. Call-ID: 1-38590@10.0.30.101. CSeq: 1 INVITE. Record-Route: . Content-Type: application/sdp. Contact: . Content-Length: 321. P-hint: DIRECT-RTP. . v=0. o=- 3705165012 3705165012 IN IP4 74.xx.xx.28. s=session. c=IN IP4 74.xx.xx.28. t=0 0. m=audio 18424 RTP/AVP 0. a=rtpmap:0 PCMU/8000. a=sp_media_cookie:4ac9631c1f904ac9631c1f9a014ac9631c47f8. a=candidate 900568881 1 pas900568881 UDP 1.0 74.xx.xx.28 18424. a=sp_chan_type:echo. a=sp_max_gain:1.700000. a=sp_rtcp:0. U 70.xx.xx.202:4371 -> 70.xx.xx.29:5060 ACK sip:service@70.xx.xx.180:5060 SIP/2.0. Via: SIP/2.0/UDP 10.0.30.101:5060;branch=z9hG4bK-38590-1-5. From: "anon" ;tag=38590SIPpTag001. To: service ;tag=a6a1c5f60faecf035a1ae5b6e96e979a-3c64. Call-ID: 1-38590@10.0.30.101. CSeq: 1 ACK. Contact: sip:.anon.@10.0.30.101:5060. Max-Forwards: 70. Subject: Performance Test. Content-Length: 0. P-hint: PROXY-RTP.. Record-Route: . . U 70.xx.xx.202:8553 -> 70.xx.xx.29:5060 ACK sip:service@70.xx.xx.180:5060 SIP/2.0. Record-Route: . Record-Route: . Via: SIP/2.0/UDP 70.xx.xx.29:5060;branch=0. Via: SIP/2.0/UDP 10.0.30.101:5060;rport=4371;received=70.xx.xx.202;branch=z9hG4bK-38590-1-5. From: "anon" ;tag=38590SIPpTag001. To: service ;tag=a6a1c5f60faecf035a1ae5b6e96e979a-3c64. Call-ID: 1-38590@10.0.30.101. CSeq: 1 ACK. Contact: sip:.anon.@70.xx.xx.202:4371. Max-Forwards: 16. Subject: Performance Test. Content-Length: 0. P-hint: PROXY-RTP.. Record-Route: . P-hint: PROXY-RTP. P-hint: NON-LOCAL. . U 70.xx.xx.202:8553 -> 70.xx.xx.29:5060 ACK sip:service@70.xx.xx.180:5060 SIP/2.0. Record-Route: . Record-Route: . Record-Route: . Record-Route: . Via: SIP/2.0/UDP 70.xx.xx.29:5060;branch=0. Via: SIP/2.0/UDP 70.xx.xx.29:5060;rport=8553;received=70.xx.xx.202;branch=0. Via: SIP/2.0/UDP 10.0.30.101:5060;rport=4371;received=70.xx.xx.202;branch=z9hG4bK-38590-1-5. From: "anon" ;tag=38590SIPpTag001. To: service ;tag=a6a1c5f60faecf035a1ae5b6e96e979a-3c64. Call-ID: 1-38590@10.0.30.101. CSeq: 1 ACK. Contact: sip:.anon.@70.xx.xx.202:8553. Max-Forwards: 15. Subject: Performance Test. Content-Length: 0. P-hint: PROXY-RTP.. Record-Route: . P-hint: PROXY-RTP. P-hint: NON-LOCAL. P-hint: PROXY-RTP. P-hint: NON-LOCAL.
Shellshock – The SIP Proxy Edition
The recent Shellshock and Heartbleed vulnerabilities have something in common – they both affect very infrastructural services. That is the reason their magnitude is much bigger than any other ol’ vulnerability out there. “Everyone” uses bash, “everyone” uses OpenSSL. Shock the shell However, one of the differences is that bash isn’t a public facing service like OpenSSL. Bash is simply the shell service of the underlying operating system. To be able to get to bash and exploit the vulnerability – one has to find a way to remotely “talk” with and feed it their evil commands via environment variables. Arguably, the most common path to reach bash is through a web server that makes use of the CGI technology. By default, CGI creates user-controlled environment variables, which are then parsed by bash, for every HTTP request the server accepts. This means that exploiting bash on such a system is as easy as sending an HTTP request to a CGI controlled page. However, CGI isn’t the only service that uses bash “behind the scenes”. DHCP services are affected, SSH and Telnet are affected, FTP services are affected. Some SIP proxies are also affected, we will learn why and how to mitigate them. SIP Express Router and friends Popular open source SIP proxies, such as Kamailio, have been found vulnerable to Shellshock. The author of a POC tool called sipshock has written a very clear explanation on the matter: The exec module in Kamailio, Opensips and probably every other SER fork passes the received SIP headers as environment variables to the invoking shell. This makes these SIP proxies vulnerable to CVE-2014-6271 (Bash Shellshock). If a proxy is using any of the exec functions and has the 'setvars' parameter set to the default value '1' then by sending SIP messages containing a specially crafted header we can run arbitrary code on the proxy machine. This means that if you have a public facing SIP proxy running a SIP Express Router implementation, you should patch your bash immediately. If you have an F5 LTM doing load balancing for that SIP server – a simple iRule will save you the headache of patching the operating system, and give you breathing room to do so properly. Mitigate Shellshock SIP with BIG-IP iRules The following iRule will detect SIP requests which contain the Shellshock pattern in one of the headers: when CLIENT_DATA { set sCVEPattern "*: () \{*" set bCVEFound 0 if { [string match $sCVEPattern [UDP::payload]] } { set bCVEFound 1 } } when SIP_REQUEST { if { $bCVEFound } { log local0. "Detected CVE-2014-6271 Shellshock attack! IP: '[IP::client_addr]' From: [SIP::from] To: [SIP::to]" reject } } Create a new iRule and attach it to your SIP proxy virtual server. Make sure the Virtual Server has “UDP” set as protocol, and is assigned with a SIP profile.