Asterisk IP authentication…

Thinking about making your own termination service ?? need to make IP-based authentication for asterisk ??

This took me quite some time to figure out how to do it properly…

In Trixbox, or any similar distribution that uses FreePBX interface, trying to add an extension won’t help in this at all…

Thanks to the guys here, I got a clue on how to do it…

Go to the Trunks page, and create a new SIP trunk, give your trunk some meaningful name (VMWare for example), clear all the text in Outgoing Settings PEER details…

In Incoming Settings, give it anyother different name (VMWare-in for this example)…

In USER Details

context=from-internal
host=xx.yy.zz.97
type=peer
disallow=all
allow=ulaw&alaw&gsm&g729
insecure=port,invite
nat=yes

Now /etc/asterisk/sip_additional.conf would show something similar to this

[VMWare]
[VMWare-in]
disallow=all
context=from-internal
host=xx.yy.zz.97
type=peer
allow=ulaw
allow=alaw
allow=gsm
allow=g729
insecure=port,invite
nat=yes

If not using FreePBX, just add lines similar to these in /etc/asterisk/sip.conf

Applying the context from-internal will cause asterisk to process the calls from that peer using the usual dial-plan, just as if the call came from an internal extension…

Apply the changes, and you’re done…

About these ads

14 Responses

  1. thanks for the tip , i haven’t tried it as of yet ,
    but my friend wants me to have ip authentication for sip , like your situtaiton , the only problem which remains is that , how can i test it ?
    can i test it with a softphone or something similar ?
    thank you in advance.

    • You can try a softphone, set the outbound proxy to your asterisk, try to make a call from a trusted IP, and from another untrusted IP, or if you have the luxury want to go fancy, you can have two asterisk installations say on VMWare/VBox/Xen, have both asterisk boxes try to send traffic to the trunk, after you make sure there’s one trusted IP and one is not…

  2. thank you , as a matter of fact , i didn’t even needed to test it , it worked like a charm :)
    it saved me alot of trouble , thank you.

  3. Well, that we’ve made the authentication via IP address, I’m wondering how much is this solution secure ?

    In my case, I’m force to configure my trunks from A2Billing, which can be made on IP authentication only. But I’m looking for a solution to make that secure, since every packet sent to my VoIP provider and having my IP address as the source IP can use my balance, which not secure at all.

    Thanks for your constructive ideas,

    • In theory, sure it can be used to spoof your IP and use your balance…
      But let’s think about it for a sec…

      To have a two-way voice conversation, and to finish the SIP handshake, the provider will need to talk back to you, route back packets to your IP, which will reach you indeed…

      Let’s assume that the handshake thinggy is done (which I don’t think it can ever finish, because it needs to know to which port it will send the RTP traffic, and the SIP provider needs to notify you whether the call has been picked up or not to start sending voice), the only use will be to spam phone users with an advertisement call that wouldn’t wait for any kind of response from the user…

      Please correct me if i’m missing something here…

      • The real problem occurs when the hacker do change the routing path configuration by tracing the router which forwards packets to the VoIP provider, and then send to this router Routing Updates Packets telling them that I (the hacker using my IP address) am your best route for that IP Address (my IP address). This can be easily done since no authentication or authorization are required at routing protocols level…

        Can you imagine the problem ?

        So, and since I’m using OpenSER in my architecture, I thought about registering my VoIP account on the OpenSER (via username and password), and then configure my trunks on A2Billing as if the OpenSER is my provider. But in this case, I’m not sure how the sip signaling and RTP channels are going to take place having (for outboud calls scénario):

        User Agent –> OpenSER –> AsteriskA2billing -> OpenSER -> VoIP Provider

        Is this feasible ?

        Thanks for your reply,

      • That has to be some super hacker with huge extensive resources to announce to the provider’s router that he’s the next best cost neighbor :D, in fact for that kind of a hack, the hacker must have already hacked an ISP (a neighbor ISP), I’m not saying it won’t happen, but seriously if a hacker is that powerful he won’t just hack into your account with a VoIP provider, certainly he’ll have a much bigger fish to fry :D

        Anyway, in the setup you have mentioned, you have to pay extra care about the handeling of OpenSER with SIP traffic and the SIP handshake, make sure it won’t put itself as an RTP proxy or you’d have a bottle neck in your setup …

        Better yet, is to pass that SIP trunk though a VPN tunnel, only for the SIP auth/handshake thinggy, and route the RTP traffic off the VPN tunnel to avoid the overhead, I’ve actually implemented this setup twice before, and it worked (and still is working in production mode for 10,000s min/month) like magic …

  4. Hello again and thanks for your constructive explanation.

    I’m actually facing a solution design issue and need it to be more clear. Here’s what I’m planning to do:

    Solution: VoIP provider (IVR, prepaid cards, DID, callback, local access number, VoIP wholesale termination)

    Solution Components: OpenSER + N x Asterisk + A2Billing + Database

    Architecture: As Asterisk is the heart of my solution and the building block for all services, I wish to have a scalable solution (many Asterisk), a per-call load balancer (I thought about OpenSER), a billing solution called by every Asterisk server and a centralized database (realtime mode).
    I’ve already configured a runnning Asterisk-A2Billing in realtime mode.
    Now I’m working on adding the OpenSER in front of my Asterisk server.

    Before going on to configure my servers, I need to understand the following:

    1) Where do my sip users register, on OpenSER or Asterisk ? Knowing the fact that if user registration takes place on Asterisk, there will not be a per-call load balancing (for a given Asterisk server, the number of users registered isn’t equal to the number of concurent calls)

    2) If users do register in OpenSER, will Asterisk need to register users again ? If not, how will OpenSER “forward” the call (sip request) to the chosen Asterisk, and how would Asterisk communicate (RTP, SIP) with the user ?

    3) What are the different scenarios for passing the RTP channels ? via OpenSER or directly between Asterisk and users/VoIP trunk ? And what are the advantages of each scenario ?

    Thanks a lot for your reply and recommendations,

    • Since you’re talking about a commercial solution, not some hobby stuff, you should think from a different perspective …
      Instead of having some components in hand and trying to build up a system with them, you’ll end up either with a disaster (failed business/lost revenue) or you’ll end up spending too much time stitching and fixing bugs (more revenue loss), or building entirely new modules/software to add to the functionality to these generic components (Which I don’t believe you have the luxury to do so, as a starting business) …

      You should think what business requirements you have and look for the components that would fulfill these requirements, not the other way around…

      To be honest, that kind of consultancy and architecture design and implementation I do for lots of money, however, my recommendation to you is; You really gotta think out of the box, and start assessing commercial solutions for VOIP billing and authentication, however you can still have asterix at the heart of the setup to do all the fancy stuff you want to do, in other words, keep asterix doing the things it does the best (IVR, call back, voice mails), and let the billing be done by something specifically created for billing …

      One more thing, you must know exactly how SIP signaling and RTP traffic goes between the communicating nodes, your best bet is to never to create a bottle neck on the RTP path to make sure you offer a good quality service …

      If you don’t want to start investing in a commercial product, that’s fine and I can understand, you can start off with a simple setup, but you must keep an eye on the bigger target and be ready to invest in a solution that would scale upto your expectations …

      • After all that’s my own personal humble opinion on this matter … I hope I could have been of more assistance to you …

  5. In fact, it all started with the goal in mind to build a commercial solution. But it takes eventhought much time to think about related issues such as security.

    The solution I’ve talked about in my last message in intended to fulfill my future-business requirements: Scalability, load balancing, fault-tolerance, quality of service and potentially a good pool of commercial services.

    You think A2Billing couldn’t be a nice billing solution ?

    I’ve expected a technical answer while you answer is a little bit general, like an out-of-the-box reply, and I understand that such consultancy are paid, but what I need isn’t a configuration files nor an architecture diagram. I just need to understand how OpenSER and Asterisk should communicate (SIP) with respect to the discussed architecture.

    Thank you a lot.

    Best regards,

    • A2billing caused lots of problems with me, in terms of lost revenue, lost minutes, and more, so we moved on to a commercial solution for billing…

      Anyway, I’m sorry to disappoint you by giving you an “out-of-the-box” reply, but I assure you I’m not an automated reply bot, nor claiming to know something I don’t …

      If you want to read about generic SIP signaling and SIP protocol, and how the call flow actually goes, I suggest you read some manuals and RFCs about how it works, and I also suggest you run tcpdump/wireshark on the participating nodes in a setup to figure out how the signaling works, and how the traffic goes across all nodes …
      You gotta try several modes of operations, B2BUa, RTP proxies, NAT’ed IPs, SIP Proxies etc, to really learn by example how these things work …

      Once again sorry to disappoint you …

  6. Hello,

    Not at all, you haven’t disappointed me. Never mind. I understand the complexity of interoperating many systems which weren’t basically designed to work with each other. Furthermore, it’s not always possible to start with commercial solutions which require a lot of money to spend while the income still not guaranteed as long as the solution is under development.

    Thanks a lot,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: