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...
Subscribe to:
Post Comments (Atom)
Fencing
Bit of fun... We usually put up some Christmas lights on the house - some fairy lights on the metal fencing at the front, but a pain as mean...
-
Broadband services are a wonderful innovation of our time, using multiple frequency bands (hence the name) to carry signals over wires (us... -
For many years I used a small stand-alone air-conditioning unit in my study (the box room in the house) and I even had a hole in the wall fo... -
It seems there is something of a standard test string for anti virus ( wikipedia has more on this). The idea is that systems that look fo...
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>
ReplyDeleteSIP 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
Sounds like a good idea
DeleteNot 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.
ReplyDeleteI 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.
DeleteLocally generated requests get all the proper error responses though as they are rather useful for debugging.