I’m getting anonymous SIP calls from outside even through SIP guests are disabled.
The firewall is also up.
I also found in the logs the register for the aforementioned call, I can’t paste the whole log due to the forum’s link filter.
[2020-02-24 06:40:59] ERROR[8624] pjproject: sip_transport.c Error processing 365 bytes packet from UDP 37.49.226.118:20328 : PJSIP syntax error exception when parsing ‘Contact’ header on line 8
I appreciate some help on this matter.
Do you have a reason to have your SIP Ports exposed to the internet? If not, lock it down.
Then break the link. We know how to fix them.
Or be smarter than the filter. replace one the periods with %2E.
pastebin%2Ecom
@PitzKey Yes, I need people outside to register and VPN isn’t an option.
@sorvani Ah, yes, sorry. I was kind of in a hurry and didn’t notice the preview could show me that.
Anyway:
[2020-02-24 04:18:44] ERROR[8624] pjproject: sip_transport.c Error processing 704 bytes packet from UDP 78.159.97.143:57294 : PJSIP syntax error exception when parsing ‘Request Line’ header on line 1 col 12:
INVITE sip: 46812111518 @179.35.1.75 SIP/2.0
Via: SIP/2.0/UDP 78.159.97.143:57294;branch=z9hG4bK893505454
Max-Forwards: 70
From: <sip:1001 @179.35.1.75>;tag=267335684
To: <sip: 46812111518 @179.35.1.75>
Call-ID: 1016399891-1598317367-1375465937
CSeq: 1 INVITE
Contact: <sip:1001 @78.159.97.143:57294>
Content-Type: application/sdp
Content-Length: 208
Allow: ACK, BYE, CANCEL, INFO, INVITE, MESSAGE, NOTIFY, OPTIONS, PRACK, REFER, REGISTER, SUBSCRIBE, UPDATE, PUBLISH
User-Agent: pplsipv=0
o=1001 16264 18299 IN IP4 192.168.1.83
s=call
c=IN IP4 192.168.1.83
t=0 0
m=audio 25282 RTP/AVP 0 101
a=rtpmap:0 pcmu/8000
a=rtpmap:8 pcma/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11– end of packet.
[2020-02-24 04:49:46] NOTICE[15568] res_pjsip/pjsip_distributor.c: Request ‘REGISTER’ from ‘“2001” <sip:2001 @179.35.1.75>’ failed for ‘185.35.64.142:6949’ (callid: vfrooihajxogvjyvitqfumynnhylpeynnywcjehkfpeiqvdvfy) - Failed to authenticate
[2020-02-24 04:49:46] NOTICE[19603] res_pjsip/pjsip_distributor.c: Request ‘REGISTER’ from ‘“2001” <sip:2001 @179.35.1.75>’ failed for ‘185.35.64.142:6949’ (callid: vfrooihajxogvjyvitqfumynnhylpeynnywcjehkfpeiqvdvfy) - Failed to authenticate
[2020-02-24 05:07:51] NOTICE[15568] res_pjsip/pjsip_distributor.c: Request ‘REGISTER’ from ‘“505” <sip:505 @179.35.1.75>’ failed for ‘185.35.64.142:8386’ (callid: pyuajlqbqlvftkdqxblofwxhrcvwleqiqxcoinkyqcbwsanhqf) - Failed to authenticate
[2020-02-24 05:07:51] NOTICE[7538] res_pjsip/pjsip_distributor.c: Request ‘REGISTER’ from ‘“505” <sip:505 @179.35.1.75>’ failed for ‘185.35.64.142:8386’ (callid: pyuajlqbqlvftkdqxblofwxhrcvwleqiqxcoinkyqcbwsanhqf) - Failed to authenticate
I guess that’s all that matters, the rest of it is just failed registration attempts.
Who are the ‘outside’ people? If they are branch offices, teleworkers, etc., set up your firewall to allow only those IP addresses. If you need to allow arbitrary addresses e.g. app connecting via mobile data, can you use SIP over TLS or at least TCP?
If the above is unworkable, do the authorized requests have your domain name (rather than just your IP address), or can you arrange that? If so, set up iptables rules to drop SIP packets that don’t contain the name.
Can you put your SIP on a random port, instead of port 5060 (you will have to set all your clients to use the new port)?
Thanks for your reply. Can you expand a bit on why TLS or TCP would help on my situation?
The third option seems good, but if the scanner did switch to the domain instead of IP, wouldn’t this be rendered moot? What are the chances?
Finally, I was worried this could be an exploit on the FreePBX system itself, since it shouldn’t be accepting such a strange call. Can I rest those worries then?
Of all such calls
99.9% plus are UDP
99.9% plus are to port 5060
99.9% plus are to your IP not your domain
Do the math with those three rules, but realise that you will never be able to filter ALL SIP calls if you listen to the whole internet with just those rules in place.
I got that, I understand you can’t be 100% bulletproof with just the firewall efforts or more. The part that actually worries me is:
Why did FreePBX ever accept this call, am I dealing with a bug here? Did I get the configuration wrong somewhere? For what I know about security practices, changing the port and such won’t really solve the issue.
Asterisk (less correctly, FreePBX) didn’t accept the registration, the negotiation failed :-
Request ‘REGISTER’ from ‘“2001” <sip:2001 @179.35.1.75>’ failed for ‘185.35.64.142:6949’ (callid: vfrooihajxogvjyvitqfumynnhylpeynnywcjehkfpeiqvdvfy) - Failed to authenticate
If you don’t accept calls to [email protected] but just to [email protected] the call wouldn’t get as far as it did.
Ugh, I just noticed that I stupidly pasted some completely unrelated lines. My bad.
[2020-02-26 06:44:31] ERROR[8624] pjproject: sip_transport.c Error processing 367 bytes packet from UDP 45.143.220.213:34243 : PJSIP syntax error exception when parsing ‘Contact’ header on line 8 col 10:
REGISTER sip:179.35.1.75 SIP/2.0
Via: SIP/2.0/UDP 45.143.220.213:34243;branch=z9hG4bK-4136754188;rport
Content-Length: 0
From: “AmooT”<sip:100 @1.1.1.1>;tag=62333233303134623133633401363233393435363938
Accept: application/sdp
User-Agent: Cisco
To: “AmooT”<sip:100 @1.1.1.1>
Contact: None
CSeq: 1 REGISTER
Call-ID: 626909302026934278862794
Max-Forwards: 70– end of packet.
[2020-02-26 07:05:03] ERROR[8624] pjproject: sip_transport.c Error processing 364 bytes packet from UDP 37.49.226.118:27348 : PJSIP syntax error exception when parsing ‘Contact’ header on line 8 col 10:
REGISTER sip:179.35.1.75 SIP/2.0
Via: SIP/2.0/UDP 37.49.226.118:27348;branch=z9hG4bK-1189874830;rport
Content-Length: 0
From: “AmooT”<sip:100 @1.1.1.1>;tag=623332333031346231336334013731343435323331
Accept: application/sdp
User-Agent: Cisco
To: “AmooT”<sip:100 @1.1.1.1>
Contact: None
CSeq: 1 REGISTER
Call-ID: 170251267928674183625210
Max-Forwards: 70– end of packet.
“[email protected]” is what shows on the phone display when the internal extensions receive the call.
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.