I want to limit simultaneous calls per extensions in Asterisk for security reasons. For example when a user is on the call no body else would be able to make a call by that extension.
How can I achieve this?
asterisklinuxSecurity
I want to limit simultaneous calls per extensions in Asterisk for security reasons. For example when a user is on the call no body else would be able to make a call by that extension.
How can I achieve this?
What a novel idea! I've not done that but I think I can get you going down the right path. If your system is similar to mine you'll find the following files that will serve as examples:
For digital faxing:
/etc/asterisk/extensions.conf
/var/lib/asterisk/bin/fax-process.pl
For emails with audio message attachments:
/etc/asterisk/extensions_additional.conf
/var/lib/asterisk/bin/audio-email.pl
We'll focus on the second action by taking a look at the part of the extensions_additional.conf file that deals with audio attachments:
[app-dictate-send]
include => app-dictate-send-custom
exten => *35,1,Answer
exten => *35,n,Macro(user-callerid,)
exten => *35,n,Noop(CallerID is ${AMPUSER})
exten => *35,n,Set(DICTENABLED=${DB(AMPUSER/${AMPUSER}/dictate/enabled)})
exten => *35,n,GotoIf($[$["x${DICTENABLED}"="x"]|$["x${DICTENABLED}"="xdisabled"]]?nodict:dictok)
exten => *35,n(nodict),Playback(feature-not-avail-line)
exten => *35,n,Hangup
exten => *35,n(dictok),Read(DICTFILE,enter-filename-short,,,,)
exten => *35,n,Set(DICTEMAIL=${DB(AMPUSER/${AMPUSER}/dictate/email)})
exten => *35,n,Set(DICTFMT=${DB(AMPUSER/${AMPUSER}/dictate/format)})
exten => *35,n,Set(NAME=${DB(AMPUSER/${AMPUSER}/cidname)})
exten => *35,n,Playback(dictation-being-processed)
exten => *35,n,System(/var/lib/asterisk/bin/audio-email.pl --file /var/lib/asterisk/sounds/dictate/${AMPUSER}/${DICTFILE}.raw --attachment dict-${DICTFILE} --format ${DICTFMT} --to ${DICTEMAIL} --subject "Dictation from ${NAME} Attached")
exten => *35,n,Playback(dictation-sent)
exten => *35,n,Macro(hangupcall,)
; end of [app-dictate-send]
You'll see that the /var/lib/asterisk/bin/audio-email.pl is referenced. The function runs line by line so if someone hangsup (ie line 8) then the .pl file is never fired off. But before this function can function it needs to be included like this:
include => app-dictate-send
I'm not going to print out the .pl file here. If you can write a pl file that will turn down the volume on your office jukebox when you manually run it, you can definitely set up Asterisk to fire off the pl when you get an incoming call.
Take a look at the /var/lib/asterisk/bin/fax-process.pl to see how asterisk fires off emails.
Now you'll probably want to adjust the first file I referenced above: /etc/asterisk/extensions.conf. This file tells Asterisk what to do when calls first come in. Take a look near the top of the file for this:
[from-did-direct]
include => ext-findmefollow
include => ext-local
You could create something like "turn_down_music.pl" and include it in a function like [app-lower-music]. You would then include it with:
[from-did-direct]
include => app-lower-music
include => ext-findmefollow
include => ext-local
Note that the [ext-local] file is defined in the extensions_additional.conf file but referenced in the the extensions.conf file. You can create your own custom extensions file and reference it in the extensions.conf file like this:
#include extensions_custom.conf
#include extensions_music.conf
Also note that # does not comment lines out. Instead ; comments lines out.
I have gained a lot from these two books:
Good luck!
It's hard to give specific advice from what you've posted here but I do have some generic advice based on a post I wrote ages ago back when I could still be bothered to blog.
First things first, there are no "quick fixes" other than restoring your system from a backup taken prior to the intrusion, and this has at least two problems.
This question keeps being asked repeatedly by the victims of hackers breaking into their web server. The answers very rarely change, but people keep asking the question. I'm not sure why. Perhaps people just don't like the answers they've seen when searching for help, or they can't find someone they trust to give them advice. Or perhaps people read an answer to this question and focus too much on the 5% of why their case is special and different from the answers they can find online and miss the 95% of the question and answer where their case is near enough the same as the one they read online.
That brings me to the first important nugget of information. I really do appreciate that you are a special unique snowflake. I appreciate that your website is too, as it's a reflection of you and your business or at the very least, your hard work on behalf of an employer. But to someone on the outside looking in, whether a computer security person looking at the problem to try and help you or even the attacker himself, it is very likely that your problem will be at least 95% identical to every other case they've ever looked at.
Don't take the attack personally, and don't take the recommendations that follow here or that you get from other people personally. If you are reading this after just becoming the victim of a website hack then I really am sorry, and I really hope you can find something helpful here, but this is not the time to let your ego get in the way of what you need to do.
You have just found out that your server(s) got hacked. Now what?
Do not panic. Absolutely do not act in haste, and absolutely do not try and pretend things never happened and not act at all.
First: understand that the disaster has already happened. This is not the time for denial; it is the time to accept what has happened, to be realistic about it, and to take steps to manage the consequences of the impact.
Some of these steps are going to hurt, and (unless your website holds a copy of my details) I really don't care if you ignore all or some of these steps, that's up to you. But following them properly will make things better in the end. The medicine might taste awful but sometimes you have to overlook that if you really want the cure to work.
Stop the problem from becoming worse than it already is:
However annoyed your customers might be to have you tell them about a problem, they'll be far more annoyed if you don't tell them, and they only find out for themselves after someone charges $8,000 worth of goods using the credit card details they stole from your site.
Remember what I said previously? The bad thing has already happened. The only question now is how well you deal with it.
Understand the problem fully:
Why not just "repair" the exploit or rootkit you've detected and put the system back online?
In situations like this the problem is that you don't have control of that system any more. It's not your computer any more.
The only way to be certain that you've got control of the system is to rebuild the system. While there's a lot of value in finding and fixing the exploit used to break into the system, you can't be sure about what else has been done to the system once the intruders gained control (indeed, its not unheard of for hackers that recruit systems into a botnet to patch the exploits they used themselves, to safeguard "their" new computer from other hackers, as well as installing their rootkit).
Make a plan for recovery and to bring your website back online and stick to it:
Nobody wants to be offline for longer than they have to be. That's a given. If this website is a revenue generating mechanism then the pressure to bring it back online quickly will be intense. Even if the only thing at stake is your / your company's reputation, this is still going generate a lot of pressure to put things back up quickly.
However, don't give in to the temptation to go back online too quickly. Instead move with as fast as possible to understand what caused the problem and to solve it before you go back online or else you will almost certainly fall victim to an intrusion once again, and remember, "to get hacked once can be classed as misfortune; to get hacked again straight afterward looks like carelessness" (with apologies to Oscar Wilde).
Reducing the risk in the future.
The first thing you need to understand is that security is a process that you have to apply throughout the entire life-cycle of designing, deploying and maintaining an Internet-facing system, not something you can slap a few layers over your code afterwards like cheap paint. To be properly secure, a service and an application need to be designed from the start with this in mind as one of the major goals of the project. I realise that's boring and you've heard it all before and that I "just don't realise the pressure man" of getting your beta web2.0 (beta) service into beta status on the web, but the fact is that this keeps getting repeated because it was true the first time it was said and it hasn't yet become a lie.
You can't eliminate risk. You shouldn't even try to do that. What you should do however is to understand which security risks are important to you, and understand how to manage and reduce both the impact of the risk and the probability that the risk will occur.
What steps can you take to reduce the probability of an attack being successful?
For example:
What steps can you take to reduce the consequences of a successful attack?
If you decide that the "risk" of the lower floor of your home flooding is high, but not high enough to warrant moving, you should at least move the irreplaceable family heirlooms upstairs. Right?
... And finally
I've probably left out no end of stuff that others consider important, but the steps above should at least help you start sorting things out if you are unlucky enough to fall victim to hackers.
Above all: Don't panic. Think before you act. Act firmly once you've made a decision, and leave a comment below if you have something to add to my list of steps.
Best Answer
There isn't an easy answer to this, but a number of people have suggested solutions. Basically you need to count the outbound channels yourself, as suggested here:
http://www.remiphilippe.fr/2010/05/29/simultaneous-call-limitation-on-asterisk/
The script looks like this, after groups have been enabled as a macro: