Tuesday, 13 March 2012

SIP progress

Needless to say the SIP work has suffered due to ADR.

I am trying to calm down and make progress. However, I have got it properly recording inbound SIP registrations which check the username and password correctly.

I do however have to work out ways to handle this for external connections. You will typically have a carrier connecting in, and that may or may not be authenticated. There may also be external registered SIP devices. The problem is that if I respond to REGISTER requests asking for Authorization details then people will sip-vicious the FireBrick.

We actually put this code on a brick last night and by morning it was under attack.

Obviously we make sure attacks don't work by blacklisting source IPs and so on. But that does not stop someone trying.

So we have to come up with a more cunning approach to handle this. I suspect we have to check the from/to details are sensible before returning a 401, and if not sensible then not reply to external requests.

Some pondering needed :-)

Anyway, next bit of code is outgoing registrations (i.e. to a carrier).

Once that is done - we get on to actually making calls, which is where it gets to be fun...


  1. Don't forget to include compliance with RFC 4028 this time which you currently do not comply with on all my A&A lines. see here>

    SIP provides a mechanism by which both user agents and proxies can determine whether a given SIP session is still active. This mechanism is referred to as a Session Timer and is described in RFC 4028

  2. Not sure if this is a good idea or not but you could do some kind of filtering based on User Agent in the Register message. Of course it would be trivial for Sipvicious to emulate any other UA so that wouldn't work for long even if it worked at all.

    1. I have changed the logic slightly now - basically you get no reply to external probes unless you managed to use the username for a configured user that is configured to allow external registrations, and even then only if from the allowed IP group.

      Locally generated requests get all the proper error responses though as they are rather useful for debugging.