Compromised server?

While debugging an issue with calls being dropped, I’ve noticed that on the final ACK from server to the client that is being dialed, the Contact field contains an IP that is not only wrong, but maps to an IP in APNIC (Asia). We have no endpoints there. Calls are being dropped approx 20 seconds after connection with the message below. I know this message normally points to a NAT problem, but it has simultaneously occured in a system of multiple networks that was previously working:

[Nov 1 13:29:23] WARNING[3348]: chan_sip.c:2962 retrans_pkt: Maximum retries exceeded on transmission YjExOGJhOTA3MTRlMmI2MDNjMDUyYjMzMDU3M2EyNWM. for seqno 2 (Critical Response) -- See doc/sip-retransmit.txt. [Nov 1 13:29:23] WARNING[3348]: chan_sip.c:2989 retrans_pkt: Hanging up call YjExOGJhOTA3MTRlMmI2MDNjMDUyYjMzMDU3M2EyNWM. - no reply to our critical packet (see doc/sip-retransmit.txt). -- Executing [h@from-asterisk-queue:1] Hangup("SIP/413-00000004", "") in new stack

In the debug log:

[code]—
Retransmitting #3 (NAT) to 173.XXX.XXX.XXX: 54722:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.XXX.XXX.XXX:5060;branch=z9hG4bK-d8754z-162f835a187ac952-1—d8754z-;received=173.XXX.XXX.XXX;rport=54722
From: sip:413@XXX.XXX.com;tag=557cfd29
To: sip:997@XXX.XXXXXX.com:5060;tag=as7b7dce3a
Call-ID: OWMzMzJmMGI5YmQzYzg4NjBmMjBhMjRlM2Y1ODIxZDg.
CSeq: 2 INVITE
User-Agent: Asterisk PBX 1.6.0.20
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Contact: sip:9XX@204.XXX.XXX.XXX
Content-Type: application/sdp
Content-Length: 280

v=0
o=root 443962970 443962970 IN IP4 204.XXX.XXX.XXX
s=Asterisk PBX 1.6.0.20
c=IN IP4 204.XXX.XXX.XXX
b=CT:384
t=0 0
m=audio 14430 RTP/AVP 8
a=rtpmap:8 PCMA/8000
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
m=video 16230 RTP/AVP 34
a=rtpmap:34 H263/90000
a=sendrecv


inv5031*CLI>[/code]

If you dont know the IP add it to your iptables ,

also look at teh logs and see if you have lots of register attempts and alos do a sip show peers and make sure the ips the peers have are correct.

Ian

Done, but I guess my question is how would this IP come up if it is not an IP that is involved in the connection? The packet sniff was done with two known machines and this IP came up as the “contact”. Is it possible something more than a SIP account was compromised and a configuration changed?