Queue Call

[mcjoel.ramirez]

Please anyone who have idea on this - is it possible that icoming calls came in to our vicidial and no available agents on the first ingroup and forwarded into another ingroups but suddenly no agents available can the call back to the first ingroup.

[mflorell]

Yes, but you should be careful when using circular logic like that.

[williamconley]

Ingroups all have "drop actions" ... and can be sent to another ingroup as a result of exceeding specified drop time.

but if you set group 1 to drop to group 2 and group 2 to drop to group 1 ... you could set up a closed loop and have callers on hold forever.

[mcjoel.ramirez]

thanks for the advise, but here is the full scenario we have two in-groups.

group 1 & group 2 with separate DID's. if you call our DID in group 1 and no agents
are available it will drop action to group 2, if group 2 is full, after 3mins drop
action will goto our main office. what we need is, if one of agents in group 1 got available before 3mins, how can we return the call to group 1 is there any way to do
this?

[KDell]

You could allow agents in group one to take calls from group two, set group two Next agent call to "inbound_group_rank" and set agents in group one to a lower priority than those in group two.


That way group one drops to group two, if an agent in group one becomes available while all agents in group two are busy they will receive that call, and that will avoid te circular logic that may trap a call on hold.

[williamconley]

Nice solution.

[mcjoel.ramirez]

it is not possible for group 1 to take calls from group 2 because our group 2 is a set of expert agents that handle all types of calls. but in group 1 handle a lower priority call. what we need is a call from DID of group 1 that has been transfered to group two because no available agents in group 1, but suddenly no agents are also available in group 2. so basicly, the call that was originally for group 1 is not hanging in queue in group 2. if one agent becomes free in group 1 he should be able to take the call.

[williamconley]

make a 3rd ingroup for the "combo" units. 2nd tier would be "prioritized" to prefer the agents you WANT to get the calls before the other ones.

then you have two completely different pathways and can differentiate between them easily while prioritizing them as well.

[mcjoel.ramirez]

Good Day,

Thanks for the big help our problem has been solved.

Now i just would like to ask another help for the problem that we are encountering if i go to ssh on our asterisk and you type IFTOP you will see ip address that is not belongs to our network and trying to hack our asterisk.

we done some iptables blocking for the specific IP & Port but it is still there,
please help me out, what is the best solutions for this......




Thanks & Best Regards,
Mc Joel T. Ramirez

[williamconley]

We have a NEW system that allows a LOCKDOWN single page web to be the ONLY public facing access on port 81 with a "link required" filename (ie: if you don't know the name of the logon page, you'll never see anything ... if you use a port other than 81 you'll get a black hole, no response). After the agents log on via this web page, THEN they will have full access to the system.

We've just developed this system. Went yesterday morning, Beta testing this week.

It allows for a full reset of all dynamic IP addresses nightly.

The only change for the agents is that they log in on a different page.

(Also: they log on with their USER/PASS first instead of their PHONE/PASS and the PHONE/PASS is then prepopulated because it was easy ).

We will also shortly be adding "phone ips" from the Admin->Phones table to be populated into the whitelist automatically, but this would really only be necessary if the phone were on a different IP from the user (we have a client who has this situation using WiMax in Miami).

[mcjoel.ramirez]

Any who has a best solutions for blocking IP Address in asterisk vicidial with port.


weve done some IPTABLES commands to block it but its not working.

[williamconley]

Code: Select all

iptables -I INPUT 1 -s 202.126.32.5/32 -p all -j DROP

will drop ALL traffic from that single ip address. regardless of port. (immediate affect)

other methods can be difficult (opensuse allows traffic based on previous contact with the system in question, so closing the port in the existing opensuse system may not be effective ... since the packets may be auto-authorized through another portion of the firewall coding ... this method simply bypasses the entire firewall system and drops matching packets immediately).

This will NOT get your bandwidth back immediately, as the "bot" in question will not care that you are no longer responding until it is done with its cycle. At that point, they will likely change to a NEW IP address and hit you again. So they will keep hammering your firewall (slowing your bandwidth), then change to a new IP, get in for another few thousand attempts, then get locked out ... but still hammer at your firewall blowing your bandwidth as long as they get ANY access when they change IPs.

Our new system kills that. The ONLY public port is 81 and using it requires knowing the actual name of the page that the logon is on (unless you are already authorized). After logging on, you are now authorized and may continue normally. So far, it's working quite well. (Day 2 of Beta)

[mcjoel.ramirez]

Thank you very much, but i already try to use that but still didn't work for us, is there more best way to block this cause it just display the host name like this nidm-new4-sh2.custome:5167 and if you check their IP it will give you 195.122.208.53...please help anyone who has a best solutions for this problem.........thanks in advance

[williamconley]

iptables -I INPUT 1 -s 195.122.208.0/24 -p all -j DROP

or

iptables -I INPUT 1 -s 195.122.0.0/16 -p all -j DROP

or

iptables -I INPUT 1 -s 195.0.0.0/8 -p all -j DROP

BUT: Be sure YOU are not on the "195.x.x.x" ip range! Or you'll lock yourself out.

also: define "didn't work"? are you saying they are still getting into your serve or that you are still being "attacked"? The attack will NOT stop until the bot stops sending, often this takes an hour (you are dropping that packets, but your 'puter is busy with them!)

[mcjoel.ramirez]

Thanks a lot but still not working for this case is any one who has a best solutions to block this on IPTABLES, hope that anyone can help us out with this or any one who already have experience with this kind of case.....

[williamconley]

define "didn't work"? are you saying they are still getting into your serve or that you are still being "attacked"? The attack will NOT stop until the bot stops sending, often this takes an hour (you are dropping that packets, but your 'puter is busy with them!)

if they are not getting in, but still attacking, you have only the option of changing your ip address to stop them or wait out the bot.

(although: i have managed to use bandwidth limiting to "reduce" the attack, but that often requires ALLOWING them access to allow the bandwidth limit packet reponses to return to their server ... then you can limit them to 10k and go back to work ...)

[mcjoel.ramirez]

it is still on the view of IFTOP that affecting our outgoing Bandwidth, how to limit them into 10k? or any other way to block this?
nidm-new4-sh2.custome:5167.....hope you still can help us with this....

[williamconley]

ok: it's "still in iftop" ... are you RECEIVING packets from them or SENDING packets TO them? (iftop shows both and can toggle between with "t")

Bandwidth limiting is ... tricky

Here's a decent reference/how to site: http://www.topwebhosts.org/tools/traffic-control.php

[mcjoel.ramirez]

We are receiving packets from them that affects our calls...what other things or blocking commands that we can do to stop this?

[mcjoel.ramirez]

=> nidm-new4-sh2.customer.vol.cz:5167 0b 0b 0b
<= 260Kb 260Kb 274Kb



this is the flow that has shown in our iftop, what can we do to stop this?

[williamconley]

you would need to change your IP or limit the bandwidth to their ip while allowing access until the end of the shift.

we've had this situation, when shutting down was NOT an option ... but the invasion was SSH based, so limiting all ssh speed to a tiny amount resolved the issue nicely ...

what port are they hitting?

[mcjoel.ramirez]

they are hitting in the port of 5167.....

[williamconley]

in the above listing, it shows THEIR port is 5167, but it does not show YOUR port#.

[mcjoel.ramirez]

his hitting our sip port.

[williamconley]

port 5060? (i try not to assume)

so limiting it based on the PORT is not quite likely. LOL

the link i posted earlier has a sample setup to limit bandwidth. obviously you'd need to adjust it for your needs. i'm pretty sure you can limit based on anything you like (ip of remote server for instance). our script happens to do it based on local port number.

[mcjoel.ramirez]

So the only solutions that we have here is changing the ip address?

no any other solutions to prevent this case?

[williamconley]

the link i posted earlier has a sample setup to limit bandwidth. obviously you'd need to adjust it for your needs. i'm pretty sure you can limit based on anything you like (ip of remote server for instance). our script happens to do it based on local port number.

[mcjoel.ramirez]

ok thanks a lot, so we cant do other solutions to block this.....? or how can we prevent this in future...even we did not change our IP?

[williamconley]

they are attacking because they got through once. their bot registered the POSSIBILITY of getting into a SIP account. so their bot is going to brute force password attack until its "timer" expires and then move on to the next victim.

it will likely come back at least one or two more times, but IF from now on the IPTables are set up for WHITELIST ONLY, they will likely give up after only a minute or two (although I've had them try for an hour a day for two or three days even with IPtables on after a successful "attempt" run ... because THEY know you're still there, hiding, so they hope your system will overload and let them in).

if you use IPTables to become invisible, you have a good chance of only being disrupted for a few minutes on one or two more occasions. but you gotta lock it down

[mcjoel.ramirez]

ok got it.

Thanks....could you please give me the full details of steps that i have to do to be successful like what you've done in your systems? i hope you still can give and support us with this matter.

[williamconley]

iptables lockdown + bandwidth limiting.

i posted the link above from which we constructed our port-based bandwidth limit, but ours won't help you since you don't want to base yours on port, so start where we did (on that post i listed).

also i've posted the iptables lockdown recently (although if you have vicibox that's as easy as removing ALL the allowed services, including the "advanced" ones).

now: if you're talking about having an easy method to "whitelist" ip addresses (on a web page, without ssh access) or the self-sign version we have in beta ... those we charge for.

[williamconley]

oh!

be sure you are LOCAL to the machine in question, as you may lock yourself out. (console login! until you learn iptables, this WILL completely lock you out! except for traffic initiated by the server itself). Experiment

Code: Select all

yast firewall

Allowed Services

Highlight any listed "Allowed Service" and select "Alt l" to delete all of them.

Then "Alt d" for the Advanced items, and delete all entries.

Then you must issue IPtables "allow" commands for anyone you just "cut off" who needs access.

one at a time (or change the /32 to allow ranges if you know what you are doing):

Code: Select all

iptables -I INPUT 1 -s xx.xx.xx.xx/32 -p all -j ACCEPT

This "ACCEPT" command can also be done from a script, or from the yast firewall configuration or custom yast firewall .conf files ... but the simplest method (especially for testing) is direct from the command line for each IP. (the effect when executed from the command line is immediate but will not survive a reboot)