Sorry for intruding, but this is puzzling me a lot.
I followed the guide to make Kamailio work with asterisk and realtime, Kamailio version 4 and asterisk 11.
(http://kb.asipto.com/asterisk:realtime:kamailio-4.0.x-asterisk-11.3.0-astdb )
up until now its working, and now want to get the phones (CISCO SPA504G, former linksys) to get the SIP notify command and reload to get their new config, from the asterisk cli
the cli command is "sip notify spa-reboot <username>"
The problem is that, using the setup in the guide, the phones registers with kamailio, kamalio then strip the password and register with no password to the asterisk, as supposed to be.
by that, when asterisk sends the SIP Notify with the reboot commands, it arrives to the kamailio, and is forwarded to phone, and the phone answers with a '401' and a digest.
In the flow, the kamailio (in the middle) receives the 401 and sends again the sip message to asterisk, and asterisk uses the digest to cipher the password and reply, but as asterisk is configured with no password, the reply contains as 'wrong' password (the empty/blank one)
is there any way to make kamailio intercepts again that '401' and reply with a crafted message, with the right digest, password, (the one in the ul table) and user, so the phone can accept the order and reboots?
The other (ugly) option, is to remove the auth from the phone, for the Sip Provisioning, but that would leave and open door to a reboot attack without auth needed from any IP. And I dont like that option.
As we talk, I managed to create a routing logic, but is that the right approach? :
===================
request_route {
if (is_method("NOTIFY")) { #xlog("NOTIFY received: $rs");
t_on_failure("MANAGE_FAILURE_401"); #try to intercep a 401
}
..... }
failure_route[MANAGE_FAILURE_401] {
if (t_check_status("401")) { #401 detectado dentro de un Notify, #probablemente ha sido por una orden de reboot. #hay que construir un paquete e intentar enviar, con el digest adecuado....
$uac_req(method)="NOTIFY"; $uac_req(ruri)="sip:"; $uac_req(furi)="sip:"; $uac_req(turi)="sip:"; $uac_req(hdrs)="Contact: <sip:"+ ">\r\n"; #Paquete construido, debe ser enviado uac_req_send(); xlog("401 detectado"); # exit; }
===================
Thanks in advance.....
On Thu, Mar 13, 2014 at 8:26 AM, Pedro Niño nino.pedro@gmail.com wrote:
The other (ugly) option, is to remove the auth from the phone, for the Sip Provisioning, but that would leave and open door to a reboot attack without auth needed from any IP. And I dont like that option.
This might not be as bad of an option as you think. If the SPA is behind a stateful firewall then that firewall should allow the NOTIFY from the registrar due to the REGISTER and NAT keep-alive packets opening the firewall, but disallow SIP from any other source. I would recommend verifying that before you deploy it though as I haven't tested it myself.
Corey
Indeed, of course that way works, but I am pretty sure that Kamailio can intercept and give the right response.
Right now what would be needed is to make a complete SIP Notify with the according digest, using the password picked from the database, and send it back. The answer would be a 200 'OK' .
Will keep trying, don't like to leave that back door open at the phones... On Thu, Mar 13, 2014 at 8:26 AM, Pedro Niño nino.pedro@gmail.com wrote:
The other (ugly) option, is to remove the auth from the phone, for the Sip Provisioning, but that would leave and open door to a reboot attack without auth needed from any IP. And I dont like that option.
This might not be as bad of an option as you think. If the SPA is behind a stateful firewall then that firewall should allow the NOTIFY from the registrar due to the REGISTER and NAT keep-alive packets opening the firewall, but disallow SIP from any other source. I would recommend verifying that before you deploy it though as I haven't tested it myself.
Corey
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users