Looking for opinions on ViciBox v.8.1 firewall integration

[Kumba]

So I am down to what I think is my final design for an integrated ViciBox v.8.1 dynamic white list.

Here's a rough breakdown:

-- Three IP Lists: ViciWhite, ViciDynamic, ViciBlack (white/grey/black lists effectively)
-- The three IP lists are NOT to be used by anything in ViciDial, it's just a convenient way to have them be manageable from the ViciDial interface
-- ViciBlack is a global blocklist, any IP on here gets all traffic blocked (EVERYTHING) and takes priority over the other lists
-- ViciWhite is a manually entered list of IPs allowed to connect via SIP/IAX (carriers, PBXs, etc)
-- ViciDynamic is dynamically compiled list of Agent/Admin login IPs based on vicidial_user table information (ignores RFC1918 IPs)
-- RFC1918 IP's are on the whitelist by default (192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12, 127.0.0.1)
-- Web Interface is universally accessible unless on the blacklist cause the blacklist blocks EVERYTHING (this is important to note)
-- Only SIP/IAX traffic is affected by the White or Dynamic lists, RTP and Web traffic are open unless the IP is on the blacklist
-- The ViciDynamic list ages, so only ACTIVE users that have successfully logged into the web interface in the past 14 days will be put on it
-- IP list format is in CIDR format, I.E. A.B.C.D/NM. If no Bit/Net Mask is given /32 will be assumed, which is a single IP Address
-- Requires a ViciDial SVN version greater then 2726 or Build greater then 170409-0950
-- The default ViciBox v.8.1 install will only have the blacklist activated although it will be empty by default, an empty blacklist hurts nothing
-- The whitelist and dynamiclist can be implemented separately, so you can have just the whitelist and blacklist if you want, or just dynamic and blacklist, or all three.
-- A CLI tool to allow you to add or remove IPs from the Black and White list, integrates with ViciDial through the /etc/astguiclient.conf files like other ViciDial utilities
-- Script run from cron every minute, so there is approximately a 2-minute delay between active changes
-- Requires SuSEfirewall2 to be running and only applies to the 'external' zones, internal zones are not affected
-- All blocks/matches are done using IPSet and IPTables which is significantly more dynamic and scalable then any other approach I've found

The one downside is the grace time between when an agent initially logs in to the web interface and when they will be able to connect their soft phone. This should only be an issue for initial login or if the agent doesn't login for more then 14 days and their IP isn't on the whitelist. The second issue would be if someone deletes the IP Lists in the web interface or tries to use it for user groups or something.

Let me know what you think of this sort of firewall integration.

[williamconley]

Honestly, I'm not on board with open port 80 to the world. I would be ok with that as an "option" that's easily deactivated either when not needed or in times of turmoil ("are we being attacked?"). Default either way is good, as long as pure whitelist is an option out of the box.

I'd love to hear input on that topic.

The one downside is the grace time between when an agent initially logs in to the web interface and when they will be able to connect their soft phone.

This has the potential to be an ongoing support call generator.

What is the cause of the delay?

We (Um ... Dynamic Good Guys) use a "GOOD" file from the "recent" iptables module to make the ports available immediately. We also use an alternate port and random page name for addition to the good file. This exposes NOTHING from the web server until after successful login. No attack vector outside the apache "page not found" response.

We are in the midst of upgrading this interface to "bounce invisibly" to a normal login page after user/pass is entered successfully. And it's a pretty login, too.

[Kumba]

Honestly, I'm not on board with open port 80 to the world. I would be ok with that as an "option" that's easily deactivated either when not needed or in times of turmoil ("are we being attacked?"). Default either way is good, as long as pure whitelist is an option out of the box.

I'd love to hear input on that topic.

The idea is to be integrated and transparent to end users. From what we have found the web interface is not how most ViciDial systems are compromised. It's weak passwords on SIP brute force attacks. This is easily 9 out of 10 if not 99 out of 100 'hacks' we find. Our approach is to provide a level of protection that is universally applicable without being draconian or obtrusive. This is what I think is a good mix of that. But the more brains engaged the better which is why I made this post.

The ViciDial login pages already have a brute force mitigation scheme in place. If you attempt to login as the same user more then 10 times it will block that user's ability to log in from any IP address for 15 minutes. This makes it pretty unattractive for brute force. You can further secure the web interface by removing the HTML redirect page requiring your average port scanner to guess the correct URL to get to the ViciDial login page. Any sort of HeartBleed or other such protocol attacks will still be vulnerable at an obscure port that apache is serving as well. If you've ever ran a PCI WEB-DSS scan you know the automated port scanners will find all the random ports that serve HTTP or HTTPS content.

However it would be fairly trivial to modify the implementation so that it blocks web traffic as well unless you're on the right list. Then you could have your special login page just insert authenticated IPs into the ip list table in vicidial and it'll get pulled in automatically.

The one downside is the grace time between when an agent initially logs in to the web interface and when they will be able to connect their soft phone.

This has the potential to be an ongoing support call generator.

What is the cause of the delay?

It's the propagation delay across a cluster with all the moving parts. The IP list scripts are all ran from the crontab which has a 1 minute minimum cycle time. So the whole process goes as follows:

1) Someone logs into the Agent or Admin interface of vicidial -OR- someone add's an IP to the whitelist/blacklist
2) An IP scraper runs on the database, extracts a list of recently logged in IP addresses and inserts them into the dynamic ip list table in the database
3) An IP processing script runs on all the telephony (or wherever) servers in the cluster and downloads these IP lists from the database and loads them, allowing people in

Each step has the potential to take up to 60 seconds depending upon timing. So the longest theoretical wait time would be 2 minutes. 1 minute from step 1 to 2, and another minute from step 2 to 3. I will probably add a configurable artificial delay to step 3 so that it waits 10 seconds before connecting to the database. This would make the shortest time around 1 minute 10 seconds. Any database should be able to turn out that list of IPs in step 2 in 10 seconds or less. It's not like it's a write heavy or complex table. It should be noted that if someone manually inserts the IP into the whitelist that you would have only 1 minute delay since the rest of the cluster does not have to wait on the IP scraper to put it into the dynamic list.

[williamconley]

One thing at a time:

From what we have found the web interface is not how most ViciDial systems are compromised.

From what we have found, the "open to the world" web interface is what invites the attacks. Once on the list, you have to whitelist or deal with permanent attacks. In many cases they don't stop attacking for a couple days after the gates are closed (bouncing off the firewall even though nothing gets through, because it's a script).

I will admit that keeping the UDP ports locked may dissipate this somewhat, but my fear is that those who would attack would (once again) update their attack methods.

If the word 'vicidial' is visible to public, it's now a target since the script kitties know "vicidial=asterisk=sip traffic=money". Then they may begin attacking the Vicidial web interface to get into the system. I've been trying to avoid that inevitablity.

[williamconley]

If you attempt to login as the same user more then 10 times it will block that user's ability to log in from any IP address for 15 minutes. This makes it pretty unattractive for brute force.

We've had plenty of rotating IP and rotating user brute force attacks. They aren't "normal", but they happen enough to keep everything in our colo whitelisted. We've also taken on some problem clients who were already being attacked and resolved their issues completely. In many of these cases, they were likely being targeted (so they are special), but I like the fact that Dynamic Good Guys protects at all levels.

Any sort of HeartBleed or other such protocol attacks will still be vulnerable at an obscure port that apache is serving as well.

While heartbleed itself has been patched, you are right to suggest that there will likely be another similar vector some day. However: If someone finds a way to hack into our servers through the 404 page, we'll be the smallest group to be attacked at the back end of the spectrum while we turn off even the 404 page on all our servers until that, too is patched.

In our case, the port isn't "obscure" it's merely a means to remove the entire web from view and leave ONLY a 404 page and a randomly named UUID page as the only means of entry. No way to guess it, nothing but 404 without it.

Which means I'm agreeing with the "remove the bounce", but taking it farther. You must have the link or you'll not be getting into the system at all. And while you're trying to hack, there's only ONE page available on that entire web because "ports" can define a web.

My goal has been to avoid (as much as I can) slowly training the script kitties how to break into the system. Instead of removing one block at a time and allowing them to progress with us. Take it all away unless the hacker in question can hack directly into an apache server's 404 page ... and if they can do that, they are above my paygrade and unlikely to care about our little world. lol

[Kumba]

Any sort of HeartBleed or other such protocol attacks will still be vulnerable at an obscure port that apache is serving as well.

While heartbleed itself has been patched, you are right to suggest that there will likely be another similar vector some day. However: If someone finds a way to hack into our servers through the 404 page, we'll be the smallest group to be attacked at the back end of the spectrum while we turn off even the 404 page on all our servers until that, too is patched

Heartbleed had nothing to do with the HTML page being served. If you weren't patched and someone made an SSL connection to your apache server, you were vulnerable to heartbleed. The entire HTTP body was never even really looked at or part of the Heartbleed exploit at all.

I'll get the framework in place and think about how some sort of pre-login screen can be easily added.

[williamconley]

Heartbleed had nothing to do with the HTML page being served.

True. I was offering an example of a bad exploit, showing how the "randomness" can mean that pretty much no matter what we are exposed ... but it still requires a connection and a reason to bother trying.

Just seeing if raising the alarm now will cause me to make **less** money from security work next year. I like the money, but I prefer Code rather than cleanup. lol

[vkad]

I agree with Kumba and what you can do is enforce stronger passwords through the backend for SIP Registration. Also, enforce non-numeric phone extensions.
Also timeblock any ip that logs-in with incorrect login after certain attempts. Keep increasing the time if they keep retrying. It will be forever before they can break in through the web interface, unless they know about the potential username or password.
If a user logs in successfully add them to the greylist or whitelist. (What about remote users of viciphone?)
Do we need a greylist?

[williamconley]

I agree with Kumba and what you can do is enforce stronger passwords through the backend for SIP Registration.

Strong passwords is often an invitation to longer attacks. This results very often in a Denial of Service condition resulting from Brute Force attacks on the passwords (especially the strong ones).

Also, enforce non-numeric phone extensions.

Artificial constraints piss off clients. I agree that they should be alphanumeric, but a lot of clients don't agree and require (not want: require) numeric extensions to match the user id. These are paying clients (often with good-sized bankrolls). One does not tell them no "because I know better than you". Especially when whitelisting resolves the issue.

Also timeblock any ip that logs-in with incorrect login after certain attempts.

When agents in a call center share an IP, that becomes problematic. So grey lists. But still doesn't solve the problem when a rotating IP attack occurs. Then ONLY a whitelist solution will solve the problem. This is often a sticking point with many rooms. Until their first rotating IP brute force attack. Then they stop discussing it and just go with whitelist. And we're done with that client.

Keep increasing the time if they keep retrying. It will be forever before they can break in through the web interface, unless they know about the potential username or password.

Like ... 6666? or admin? Let's not forget some of those risky visible text files that still creep up every now and then (and let's not overlook custom code written by someone not expecting an attack during coding ...).

Note that if you leave your web open, you'll get daily hits from random IPs looking for web pages that don't exist. Right now, that's not a big deal since most don't check for any Vicidial risks. But when that moment comes (in general or just because of an ex-employee or someone you pissed off in the phillipines), you'll really wish you were whitelisted.

I may be a little over the top. But we published Dynamic Good Guys a decade ago for free for a reason. I've battled DOS attacks to keep servers online (during the attacks) so 200 agents don't have to get sent home without pay that day (DOS attacks can only be resolved by changing your IP, and then only if they attack does not follow you due to your domain name, which all your agent also use). Whitelist was my answer to avoid that. It works.

[vkad]

I agree with Kumba and what you can do is enforce stronger passwords through the backend for SIP Registration.

Strong passwords is often an invitation to longer attacks. This results very often in a Denial of Service condition resulting from Brute Force attacks on the passwords (especially the strong ones).
The denial of service attacks can only be stopped through blacklisting. I don't believe it can be helped if you have a really avid attacker from china or russia. If they want to to take you down, they will do their best, but their is no point in dos if their isn't a chance of attack.
If it is known publicly that passwords are stronger in vicidial, then it doesn't make sense to brute force that server. A lot wouldn't try to brute force something they know is going to be very hard to break. If their aim is to just bring your servers down, they will dos attack you regardless.

Also, enforce non-numeric phone extensions.

Artificial constraints piss off clients. I agree that they should be alphanumeric, but a lot of clients don't agree and require (not want: require) numeric extensions to match the user id. These are paying clients (often with good-sized bankrolls). One does not tell them no "because I know better than you". Especially when whitelisting resolves the issue.

Good point. Well, I only use it for a few friends call centers and I do it for free, so couldn't see that point of view, but it makes perfect sense.

Also timeblock any ip that logs-in with incorrect login after certain attempts.

When agents in a call center share an IP, that becomes problematic. So grey lists. But still doesn't solve the problem when a rotating IP attack occurs. Then ONLY a whitelist solution will solve the problem. This is often a sticking point with many rooms. Until their first rotating IP brute force attack. Then they stop discussing it and just go with whitelist. And we're done with that client.
Rotating IP attacks can be blacklisted with global blacklists which if shared amongst vicidial users can be fairly easy to build. Like truecaller, but for building blacklists.
Whitelist is great for situations when you know that your agents connect through specific static IPs. But for dynamic IPs there needs to be a block.

Keep increasing the time if they keep retrying. It will be forever before they can break in through the web interface, unless they know about the potential username or password.

Like ... 6666? or admin? Let's not forget some of those risky visible text files that still creep up every now and then (and let's not overlook custom code written by someone not expecting an attack during coding ...).

Note that if you leave your web open, you'll get daily hits from random IPs looking for web pages that don't exist. Right now, that's not a big deal since most don't check for any Vicidial risks. But when that moment comes (in general or just because of an ex-employee or someone you pissed off in the phillipines), you'll really wish you were whitelisted.

Only blacklist the IP that the attack or the scan came from. Dynamic IPs have to be dealt with what I said. Static IPs could and potentially should be whitelisted.

The only way to stop a dos attack is to survive a dos attack. You keep blocking and blacklisting the IPs. You can't really win against large botnets without having a shared regularly updating (maybe list with a feedback loop) blacklist.

I may be a little over the top. But we published Dynamic Good Guys a decade ago for free for a reason. I've battled DOS attacks to keep servers online (during the attacks) so 200 agents don't have to get sent home without pay that day (DOS attacks can only be resolved by changing your IP, and then only if they attack does not follow you due to your domain name, which all your agent also use). Whitelist was my answer to avoid that. It works.

[williamconley]

The denial of service attacks can only be stopped through blacklisting.

DOS attacks can NOT be stopped through any means without a specialty routing service. Blacklisting will stop traffic from getting to your server, but it will not get your server back on the internet until the DOS attack stops. Those packets will continue to hit your firewall, and your internet is Down until they stop. Anything that invites a brute force attack risks a DOS situation that can not be stopped. Usually DOS attacks will subside within a few hours and all but disappear within 24 hours. But make no mistake: They can not be stopped without changing your IP (or using a paid service that simulates changing your IP, which is expensive and cool).

Rotating IP attacks can be blacklisted with global blacklists which if shared amongst vicidial users can be fairly easy to build.

This is wishful thinking. Like saying CallerID blocking will work if you get the right app on your phone. It's a fallacy and it does not work. There is no univeral IP blocking share list that is reliable enough to be used without severely overutilizing the iptables resources of your server. Building one would create a monolith that will eat resources better used for dialing and ultimately not be comprehensive no matter how hard you try as the attackers botnets grow and change.

Only blacklist the IP that the attack or the scan came from.

During which you train the attacker how you shut them off. Eventually they rotate the IPs and brute force DOS is the result. Been there. Not a fun week for any client who has had the unfortunate luck to be targeted. Don't wait until this is you. It's expensive. Especially if they break in when you're not looking and spend all your VOIP money. Seriously.

The only way to stop a dos attack is to survive a dos attack. You keep blocking and blacklisting the IPs.

Wrong. You slow down their traffic. They continue to attack on new IPs, so you must continually slow new IPs. Then you change your IP (if possible) and whitelist the server. During the attack, you can still run your server, but may not have full internet speed available. After the attack you whitelist and hope their system isn't automated so it doesn't attack automatically tomorrow. Because if they do, on new IPs, you have to UNwhitelist and then send the "slow down" packets to those IPs to survive another day.

To be clear: The reason banks and major corporations hate and fear DOS is because you **can't** turn it off. But you CAN slow it down if they don't notice you're doing it, thus giving you "some" of your internet. This is often enough to run for the rest of the day. Then you whitelist and pray. But leaving yourself open on the public internet is literally an invitation to a DOS attack. Slowly shutting down their IPs one at a time is often taken as a challenge to a botnet attacker.

Our dialers have been whitelisted (all of them) since we experienced this effect years ago. We still get clients quite regularly who come to us for this very reason today. Keeping any standard ports on your dialer open to the world is a bad idea. Keeping port 80 invites every botnet in the world. Port 5060 invites SIP attacks trying to get to your VOIP money.

[vkad]

vkad wrote:
The denial of service attacks can only be stopped through blacklisting.

I also meant through the routers. It won't be possible to do this through your server. They could even simulate a SYN ATTACK BY SPOOFING IP IF THEY WANTED AND TAKE YOU DOWN. But let's hope your system won't be tricked into that anymore or your network.
Open to the web or not, if someone is persistent to take you down and that is their intent they will do so. IPtables won't help you with that. They could do a portscan and find out that you are Dynamic Good Guys. THERE IS NOTHING STOPPING A PERSISTENT AND DETERMINED ATTACKER.

HOWEVER, a dos doesn't mean that they eventually break into your system, the reason for this is that a strong password will have a lot of combinations. This attack is on a remote system and responses to brute force are going to be slow. I think you are underestimating the power of a strong password.

A 8 letter and digit combination will take forever to bruteforce over a web service. If they go too fast they will dos you or if they slow down they will most likely never get the password.

Another thing could be a delay or sleep of 2-5 random seconds on every attempt of valid or invalid login. This ensures every authentication request is at least 2 seconds. This should discourage them into attacking as they know this will just take forever.
You could have a geolist where you can identify which country or locality the agent can login from, which can further reduce the attack vector. If an agent should login from Phillipines and they try to login from China, you should approve or automatically deny that request.
THEY WILL NOT BE ABLE TO BRUTE FORCE INTO YOUR SYSTEM ALMOST 99.999999% of the time if you had a relatively complex password. But they can dos you if they wanted.

What you are hypothesis suggests is to put services like gmail, used my goverments, banks and large corporates behind DYNAMIC GOOD GUYS because you make them safer.
While I agree that you make them safer to simple attacks, but you don't to attackers who just wanna take you down. Attackers won't be able to login, but they take down your service. But whats the point in that, attackers don't make money in taking you down. Unless someone is paying them to take you down, it doesn't make business sense for them to dos you.

If SIP is so inherently unsafe we shouldn't be using it at all, but it is not. It is our practices of adhering to paying clients who want to use numeric usernames and numeric only passwords that are maybe 4 digits long.

Using stronger passwords + blacklists + authentical delay + geoip = more than enough. The next thing may be two-factor auth. YOU CANNOT BRUTE FORCE THIS SERVER ALMOST 99.999999999% of the times through authentication vector. The only way would be vulnerabilities in the application or the operating system.

THERE ARE MORE CHANCES OF the attacker to hold the owner hostage to a dos attack if money is not paid, but they will not be able to brute force a password almost forever.

Do you know what is wishful thinking? That the attacker will not attack you tomorrow. You can only survive an attack if the attacker knows you can survive the attack. Be it through "special routing", changing ips (do you really think they won't find you?) or other means.

Most of the vicidial users are not big corporates and most of them will not be worth the time + money to be brute forces or dos worthy.

[thephaseusa]

Very interesting thread. Here is my experience. I installed vicibox and started dialing in March 2017. Almost right away I saw constant attempts to log in to my sip phones. I had good passwords on them, and nobody managed to log in, but I saw it was a serious vulnerability. Searching this forum I found the DGG whitelist firewall and installed it on all servers. Ever since, problem solved. I rarely monitor probes anymore, I know nobody can get in unless they are whitelisted. That was about ports 5060-5061 and 4569. As to ports 80 and 81, I think it was beautiful idea to close 80 and move web logins to 81. At the time I installed DGG I didn't appreciate the concept fully. And I admit it seemed a little clumsy to type :81 instead of just typing the log in site. The random page name is also brilliant. I also admit though I got lazy and changed the random page name to a page name I could remember. But I have never seen attempts to log in to my :81 log in page. The User Group Login Report is a nice utility for seeing who has logged in and from where. Do we have in Vicidial a page that shows failed logins, or warnings sent to admin for failed logins? It seems to me DGG does the job. What would be the reasoning to open port 80? Just for user convenience? I shudder to think of someone finding the vicidial admin login web site, typing in user 6666 password 1234 and getting admin access. I agree with William.

"However it would be fairly trivial to modify the implementation so that it blocks web traffic as well unless you're on the right list. Then you could have your special login page just insert authenticated IPs into the ip list table in vicidial and it'll get pulled in automatically."

Kumba I think what you wrote there is the correct solution.

John M

[williamconley]

... Here is my experience. ...
Kumba I think what you wrote there is the correct solution.

John M

I like the fact that you appear to have been able to essentially stop caring about the firewall. That's the entire concept. No more firewall discussions or time wasted on that topic at all.

That's the goal. Dial! lol

[Kumba]

Everything is a balance of convenience versus hardening. The best security implementation would be to only run off of a manually inputted whitelist. This is also the most involved for administration and will generate the most noise from users.

So I will be aiming for ease of use and transparency for new admins. This is going to be how I will implement the integrated firewall:

Blacklist - Always on by default; The VoIP Black List from www.voipbl.org will be loaded plus an optional IP List called 'ViciBlack'
Dynamic List - SIP and IAX ports will be blocked unless a user has successfully logged into the web interface in the past 14 days, then they will open up after a minute or so
White List - Statically assigned list to always allow in, this is where your carriers and such will go

The default implementation of the Dynamic and White lists is to only control access to SIP and IAX. Lets refer to this as Mode 1 ACL. This will be easiest for new admin's and provide a reasonable compromise between convenience and security for 9 out of 10 installs out there.

Mode 2 ACL will block ALL (web, SIP, IAX, etc) cluster access unless you are specifically on the Dynamic or White list. This will have to be set-up manually by the server admin but is a pretty trivial process. By default all RFC1918 IP address' will be included in the whitelist but it can optionally be removed by the admin. This mode has the potential for you to easily block all network connections to the system requiring you to log in from the console to correct. It is because of the easy potential to brick the network connectivity to your cluster that I have decided to not have this be an install option. Switching to this mode would require about half a dozen commands/edits though so the more advanced Admins will be able to easily set this up.

The firewall integration is persistent and works across an entire cluster even after reboots. All IPs are stored in the main database as an IP List and can be easily added to through the ViciDial admin web interface.

[williamconley]

Will there be a (simple?) switch to make the whitelist apply to all ports? (That would make me Very Happy.)

Mode 2 will do that. It will block all traffic regardless of ports.

[Kumba]

Mode 2 will block all traffic regardless of what it is. This will be pretty trivial so you can easily copy/paste commands to switch it. I might even write a bash script to do it for you.

[williamconley]

I'll probably write a patch to make it a "preference" if you don't. lol

[vkad]

Can you add a simple live console on the interface that shows the past login attempts?

Thanks for the mode 1. I strongly believe that you DON'T need to hide the web as that reduces usability significantly, especially when you will want to see more and more agents using viciphone. Imagine if the banks would have had been giving out users unique URLs for login access so that it becomes safer. It would simple increase the hurdle and will only increase "relative security" if the other authentication parameters are strong.

If vicidial has such a strong vulnerability with web (as per williamconley) you might as well use digital certificates to login to verify the agents, but I think strong passwords and alphanumeric usernames are more than enough.

[williamconley]

vicidial has such a strong vulnerability

Please don't make up words and attribute them to me.

My point is that an invitation to attack on a server that is the lifeblood of a company, and for which being "down" results in a loss of income for everyone in the building: An invitation to attack is unwarranted and in this case entirely unnecessary. Any server that does not require public access shouldn't have it. But any server with paychecks on the line definitely shouldn't have it. The loss from a single "oh, crap, they actually are attacking us!" moment completely counteracts any possible gains by making the server public.

IMHO.

Now if you want to discuss how "hardened" Vicidial is, that's a completely different conversation. One I prefer to avoid. By keeping everything whitelisted I've avoided that conversation for quite a while, thanks.

[vkad]

vicidial has such a strong vulnerability

Please don't make up words and attribute them to me.

My point is that an invitation to attack on a server that is the lifeblood of a company, and for which being "down" results in a loss of income for everyone in the building: An invitation to attack is unwarranted and in this case entirely unnecessary. Any server that does not require public access shouldn't have it. But any server with paychecks on the line definitely shouldn't have it. The loss from a single "oh, crap, they actually are attacking us!" moment completely counteracts any possible gains by making the server public.

IMHO.

Now if you want to discuss how "hardened" Vicidial is, that's a completely different conversation. One I prefer to avoid. By keeping everything whitelisted I've avoided that conversation for quite a while, thanks.

No intentional, that is just how I felt and it is an opinion. I do apologize for the quotation marks, they weren't to be taken literally as you should see from other overlooked mistakes in my grammar.

I wholly agree with your second point but a big corporate's requirements are vastly different to most of the vicidial users.

And the system should be made to be inherently secure, however by hiding it from public sight to make it secure may, in fact, lead to vulnerabilities not being discovered or systems not being tested for the real world security (and many other problems). With webrtc and remote agents now a possibility more than ever before, it will only help the vicidial community to make the system more secure and generally meant to be used on public servers.

Most of my friends have at least some remote agents now and I think that is only possible because of webrtc. If a whitelist or other url redirection or port is implemented it is just a headache since most agents have dynamic IPs at homes and just adds to the training and admin. It is just easier to have a uniform login process throughout.

We get a lot of SIP attacks and the once instance where we were compromised was when we had left a test account with 112 phone open. That is why we prefer webrtc and have alphanumeric extensions and complex registration passwords. The agents only need to remember their campaign login and not phone and pass.

[williamconley]

big corporate's requirements are vastly different to most of the vicidial users.

This is about the small users who would have serious loss of paycheck. Major users can survive that plus they can afford DOS prevention systems (look up cloudflare among other services). You must understand that script kitties search at all times and don't care if you're large or small: when they identify a system to attack, they attack it. The goal is to stay off their radar, and this goal is for small companies who don't want to employ security staff or pay for DDOS protection hardware and routing services.

the system should be made to be inherently secure, however by hiding it from public sight to make it secure may, in fact, lead to vulnerabilities not being discovered or systems not being tested for the real world security

I think you got that backwards. Vicidial is worldwide. Vulnerabilities are handled as individual users share them to the best of The Vicidial Group's capabilities. "Discovering vulnerabilities" sounds so clinical: When a vulnerability is discovered it costs money and time and possibly jobs. Avoiding discovering vulnerabilities for each individual office is really what this is about. No individual user really wants to "find a vulnerability": They want to make calls and money. Having a secret vulnerability isn't even a thought process, much less a concern. Upgrading every few years for feature upgrades will fix old vulnerabilities they never knew or cared about.

If a whitelist or other url redirection or port is implemented it is just a headache since most agents have dynamic IPs at homes and just adds to the training and admin

Which is why we published DGG a decade ago. A lot of people use the DGG login as the "standard" agent login so there is no longer a need to put any ip in any whitelist ever: It's fully automated using what looks and feels like the same login method to the agent. Admin is not involved in the process except to send the link(s) to the agents. Plus it's possible to have one link per remote agent if there's a trust issue with those agents (ie: fire one and delete just his link).

We have an upgraded "Pretty" version of the Agent DGG page we hope to publish later this year that's *completely* seamless, smooth, and very nice looking but still maintains security by having virtually zero exposure for attack.

With DGG properly configured: Agents phone/phone pass can be auto-filled after they put in their User/Pass, even without WebRTC.

These tools all exist for a reason ...

[thephaseusa]

Vkad, I like the idea of a page or report showing failed login attempts too. In the admin utility User Group Login Report you see all the successful logins. I've been wondering where you find failed logins. I think that would be a nice addition.

But as for usability I don't understand your point. Your agents are going to need a login web page. If you give them mydomain.com and let them log in through port 80 of you vicidial web server, there are 2 steps after that to get logged in. You are redirected to the phone login page, so 1 you enter the softphone user name and password. 2 on the next screen you enter the user name, password and campaign. So that's 3 steps, 2 pages to pass through. I've been using the DGG firewall for over a year. With it you give them mydomain.com:81/mysecretloginpage.php. They enter their user name and password 1 time, if accepted they are passed to the vicidial relogin page, where the values for phone user, phone password, user name, user password and already filled in, you choose your campaign click submit and you are ready to dial. With DGG you enter 1 user/pass just one time. I've used both methods, and for me, the DGG method is faster and easier.

But you specify viciphone, maybe this all changes using viciphone? Will vicidial with viciphone built in now have a 1 page 1 step login? If so, I understand your point. Still I don't think logging in would be faster or easier than with DGG. It would be equally fast and easy. Either way you still have to provide a log in web site address, a user name and a password.

However, why expose your vicidial server port 80 to the world? And say hey, here I am, I dare you to try to hack me)) Vicidial is running all over the planet, 24/7, with millions, maybe billions of dollars a year pouring through it's servers. Hundreds of thousands, maybe millions of call center workers depend on vicidial for their livelihood. Why would we reveal our agent login page and admin login page to the bad guys unless we have to? And the bigger vicidial becomes it seems clear the more attacks will directed against it.

I like the Kumba plan, the Mode1 and Mode2. Mode1 will be for new admins using vicidial for the first time, so after their initial install they can get into their own system))) I think they should be advised though that Mode2 is more secure, and after learning the system they should be encouraged to switch to Mode2.

Being persistent across clusters including after reboots is outstanding too.

One other thought. Historically they attack us to steal our sip money and resell it. "It's weak passwords on SIP brute force attacks. This is easily 9 out of 10 if not 99 out of 100 'hacks' we find." But we have other valuables on our servers. Millions of leads. Personal data on our clients. Maybe recordings. Maybe financial info. One successful hack could put a vicidial operator out of business and maybe into legal jeopardy as well. You experience a data breach. Next thing you know a DOJ team is at your office imaging your servers. I think we take all prudent measures to prevent something like this. If you are accused in a lawsuit or in a criminal action of failing to adequately safeguard consumers' personal information, I'm not sure that saying "easier usability" or "user convenience" is going to be an adequate defense. I think they will counter with, was it really that difficult to add another layer of security to prevent a breach?

This is extremely important. Thank you Kumba and VICIdial for giving us a chance to discuss this issue while you are finalizing your next release.

John M

[vkad]

Vkad, I like the idea of a page or report showing failed login attempts too. In the admin utility User Group Login Report you see all the successful logins. I've been wondering where you find failed logins. I think that would be a nice addition.

But as for usability I don't understand your point. Your agents are going to need a login web page. If you give them mydomain.com and let them log in through port 80 of you vicidial web server, there are 2 steps after that to get logged in. You are redirected to the phone login page, so 1 you enter the softphone user name and password. 2 on the next screen you enter the user name, password and campaign. So that's 3 steps, 2 pages to pass through. I've been using the DGG firewall for over a year. With it you give them mydomain.com:81/mysecretloginpage.php. They enter their user name and password 1 time, if accepted they are passed to the vicidial relogin page, where the values for phone user, phone password, user name, user password and already filled in, you choose your campaign click submit and you are ready to dial. With DGG you enter 1 user/pass just one time. I've used both methods, and for me, the DGG method is faster and easier.

---We only have single login for campaign. The user doesn't login twice or need to know their phone details at all. They only need their campaign login details. Vicidial automatically handles that. For the agents (especially remote) its simpler to have them just go the a port 80 dialer page and they just login.

But you specify viciphone, maybe this all changes using viciphone? Will vicidial with viciphone built in now have a 1 page 1 step login? If so, I understand your point. Still I don't think logging in would be faster or easier than with DGG. It would be equally fast and easy. Either way you still have to provide a log in web site address, a user name and a password.

//Would you like your facebook.com or google.com to be on port 81 or other port? Try typing in facebook.com:81/loginpage.php

However, why expose your vicidial server port 80 to the world? And say hey, here I am, I dare you to try to hack me)) Vicidial is running all over the planet, 24/7, with millions, maybe billions of dollars a year pouring through it's servers. Hundreds of thousands, maybe millions of call center workers depend on vicidial for their livelihood. Why would we reveal our agent login page and admin login page to the bad guys unless we have to? And the bigger vicidial becomes it seems clear the more attacks will directed against it.
//That is exactly my point. Hiding behind a different port won't really help you. It is almost the same as using port 80 except that its not a standard for web applications. If you start using a unique page for login, then great but now you have added further hassle but you do gain security. But its pointless, because if you have strong passwords, they wouldn't be able to break into your system anyways, atleast in your business model's lifetime or your life time or their business model's life time or their lifetime. Infact they wouldn't be able to break into your system in all the call center's agents and hackers lifetimes added together.
You can never be too cautious, but this is being overprotective.

If I tell you my email, could you break into my facebook or email account for that matter? Or have me blacklisted or make it impossible for me to login. You can't. You could have way way back, but you can't anymore. But you can SPAM me, but is it worth the effort for most people?
It should be the same for vicidial....

I like the Kumba plan, the Mode1 and Mode2. Mode1 will be for new admins using vicidial for the first time, so after their initial install they can get into their own system))) I think they should be advised though that Mode2 is more secure, and after learning the system they should be encouraged to switch to Mode2.

//I don't think they should be pointed to mode 2.
Google adwords processes more in dollars that vicidial users for sure. Mode 2 is great, but why not just take everything offline and force agents to work from the office and have everything on private IP.

The point is the servers should be secure publicly and it is not too much to ask for in today's time. It should be a standard, not an option (and an insecure option for that matter) for the servers to be able to run with only public IPs. They should be able to form a secure cluster over public IPs.

Being persistent across clusters including after reboots is outstanding too.
One other thought. Historically they attack us to steal our sip money and resell it. "It's weak passwords on SIP brute force attacks. This is easily 9 out of 10 if not 99 out of 100 'hacks' we find." But we have other valuables on our servers. Millions of leads. Personal data on our clients. Maybe recordings. Maybe financial info. One successful hack could put a vicidial operator out of business and maybe into legal jeopardy as well. You experience a data breach. Next thing you know a DOJ team is at your office imaging your servers. I think we take all prudent measures to prevent something like this. If you are accused in a lawsuit or in a criminal action of failing to adequately safeguard consumers' personal information, I'm not sure that saying "easier usability" or "user convenience" is going to be an adequate defense. I think they will counter with, was it really that difficult to add another layer of security to prevent a breach?

What happens if say you use weak passwords and internal attack happens? What if a disgruntled manager steals all your leads? Do you have a SOP for that?

It is more of a reason to use a strong password. You can't skimp on using a strong password. The first step is to make it atleast 8 characters long (that alone increases the attack time to almost forever). Unique usernames (added complexity).
If you store financial info like credit card information, you should be PCI DSS compliant.

If you don't want DOJ imaging your servers (which they most likely won't) unless you are a big company. The court wouldn't spend more money on the case than you can pay out in most cases because it wouldn't make business sense. Even courts know the business sense in this. Secondly, when you sign an agreement with the client, you explain to them the policy for breaches (you should have one in a contract) and then have a Standard Operating Procedure.

Do your employees sign NDAs to not leak and information?

Keep it simple and use a stronger password and a alpha numeric username. Since the usernames of a vicidial system aren't public, it just increases the time complexity for the attack.

This is extremely important. Thank you Kumba and VICIdial for giving us a chance to discuss this issue while you are finalizing your next release.

THERE is a reason most attacks that come to you try logging in with numeric usernames.....

I will setup a simple vicibox system. If you successfully break in I will give you $2000 (not on dos but breaking in).
And if you want I can setup a server just using basic cloudflare plan and if you can dos that system, then I will give you another $2000.

[williamconley]

Sorry, no time for the rest of the book right now: but i can respond to this:

If you give them mydomain.com and let them log in through port 80 of you vicidial web server, there are 2 steps after that to get logged in.

DGG is a single web page with a random name on a port other than 80 because 80 is an attack vector.

You send this page to the agent and they use it as their desktop shortcut to log in. Nothing to remember. Without the link, they have no way into the server (along with everyone from China and all those guys you fired last month: No way to guess a password anywhere, nothing to attack unless they have the link).

They DO need their user/pass, but those can technically be put into the desktop shortcut as well, so *really* nothing to remember if you do that.

Next up: They have their user/pass provided by the link OR they type them (not too much to ask: user/pass). That information either proves correct, or the page refreshes with a "nope" message. Pretty standard and simple so far: one link ...user/pass.

IF they successfully guessed the proper user/password, the DGG magic happens: They are added to the firewall (in the background, invisible) and they are bounced to the full/normal "re-login" page with their user/pass/phone/phonepass pre-filled. They would then choose a campaign from the dropdown and hit login.

So:
1) Click on desktop shortcut
2) User/pass
3) submit
4) Choose campaign from dropdown.
5) Submit

2 is optional if you put the user/pass in the shortcut
4 will also require phone/phone pass if the user's entry (in Vicidial's "User" modify) does not have a phone/phone pass filled in.

The upgraded version will also pre-select the campaign into the dropdown if there's only one. Thus 3) would no longer be necessary.

So if you make sure the user has a phone/phone pass in their user record, and the user has a single authorized campaign based on their user group ... when the new system is published, it'll be 1(submit)(submit). Not gonna get much easier than that (unless we add a bit of javascript to remove the second "submit", lol).

[vkad]

Sorry, no time for the rest of the book right now: but i can respond to this:

If you give them mydomain.com and let them log in through port 80 of you vicidial web server, there are 2 steps after that to get logged in.

DGG is a single web page with a random name on a port other than 80 because 80 is an attack vector.

You send this page to the agent and they use it as their desktop shortcut to log in. Nothing to remember. Without the link, they have no way into the server (along with everyone from China and all those guys you fired last month: No way to guess a password anywhere, nothing to attack unless they have the link).

They DO need their user/pass, but those can technically be put into the desktop shortcut as well, so *really* nothing to remember if you do that.

Next up: They have their user/pass provided by the link OR they type them (not too much to ask: user/pass). That information either proves correct, or the page refreshes with a "nope" message. Pretty standard and simple so far: one link ...user/pass.

IF they successfully guessed the proper user/password, the DGG magic happens: They are added to the firewall (in the background, invisible) and they are bounced to the full/normal "re-login" page with their user/pass/phone/phonepass pre-filled. They would then choose a campaign from the dropdown and hit login.

So:
1) Click on desktop shortcut
2) User/pass
3) submit
4) Choose campaign from dropdown.
5) Submit

2 is optional if you put the user/pass in the shortcut
4 will also require phone/phone pass if the user's entry (in Vicidial's "User" modify) does not have a phone/phone pass filled in.

The upgraded version will also pre-select the campaign into the dropdown if there's only one. Thus 3) would no longer be necessary.

So if you make sure the user has a phone/phone pass in their user record, and the user has a single authorized campaign based on their user group ... when the new system is published, it'll be 1(submit)(submit). Not gonna get much easier than that (unless we add a bit of javascript to remove the second "submit", lol).

Vicidial only has a single login for us. You can easily enable that with options.php, but I think it should be the default.
Agents don't need to know their phone details.

DGG can also be brute forces with rotating IPs. It can also be DOS attacked.

All the steps that you are using in DGG simply point to one thing. Stronger passwords....
-> You use random link because you don't want to be found ----- same effect as having a stronger password, but links have to be put in a shortcut and so on.....Increasing admin hassle....What if the shortcut is deleted by mistake.
If a malware takes your shortcut from the desktop with pre-auth then your system is toast. Its equivalent to giving out the api keys and api secret.
It is akin to storing your password on a file. Now, since when has that been considered safe???
-> Managing different urls for different agents....Now thats a good idea...But again is it worth the hassle for the admin when a stronger password would have the same effect.

If you are responding to web requests, then your url can be bruteforced by cycling through possible urls....Once they have found your url they can start bruteforcing for login....Now your systems toast since you are not enforcing stronger passwords.
--But you would say that you could change the URL and its all good again. Well you could but then you need to send this to the agent again. Why wouldn't you use something simpler such as a stronger password?

A strong password for logins mitigates all the risks of an attack that DGG mitigates. You are trying to do what a strong password would do but through a preauthorised link... It serves the same function as a strong password but with extra steps and hassle.

Likelyness of someone successfully bruteforcing a domain name such as = 8 characters
(4 lowercase letters,
2 special characters,
2 numbers)
688= 457,163,239,653,376 combinations

Imagine we added an authentication delay of 2 seconds. That means that it would take 9.1432648e+14 seconds to guess all possible combinations. or lets say it takes approximately half that to brute force. That will take 126989788793 hours = 5291241199.69 days = 14496551.232 years

Now lets say that your server is capable of churning out 100,000 (hundred thousant) auth requests per second = just for arguments sake. Lets assume the person is using 10000 computer botnet churning 10 auth requests per second.

It will still take them 144.96551232 years to get you if they dont actually crash your servers.

If they wanted to get you in a reasonable period, lets say in 3 months = 90 days = 2160 hours = 7776000 seconds.
They would need to have 58791568 auth requests per second. That is 5879156 attacking you with 10 requests per second.
They would consume 250 gigabits of bandwidth per second.

In conclusion, your password over the internet will not be broken as long as it is a relatively complex 8 character password....

-----------So what is the point of a hidden login link I ask you when strong passwords do the same with less hassle?-----------------------------

Even a simple password such as W1ll1amc0nley is going to take forever. Then you add in alpha number usernames, and forget that you are going to be brute forced into successfully.

[thephaseusa]

A couple more thoughts:

1. Just yesterday there was a report of a user having his phone extension hacked and money drained out of his voip account.

On the admin pages there are already warnings about weak passwords, which is good. You could take that a step farther, like many do on the internet, and not allow weak passwords. Why allow a user to create a sip phone extension named 100 with a password of 100, or an admin to use 6666 and 1234? Maybe provide an option there for the system to generate a strong password for them too.

2. Write a Security Section in the managers manual, where you explain the security concerns with VICIdial, the options offered to provide the best security, and a maybe a brief history of exploits against asterisk, voip, and VICIdial. Warn users about potential risks. For example, hackers stealing voip money, hackers stealing consumer information, etc. Explain the security risks from outside and from inside their networks, how to protect against them, and how to identify them if they occur.

3. If you make the default security level whitelist and block traffic except for RFC1918 and require any other IP's needing access to be entered into the whitelist, sure some users may complain. And maybe this forum gets a lot of questions about how to use it. But I think they might complain louder if they end up as a defendant in a civil litigation or criminal complaint relating to the data breach they suffered. However, in a court of law I think making traffic lockdown the default setting could show intent on the part of Vicidial to protect consumer data. And if users change the setting to allow traffic that is their choice for ease of use, or whatever their reason. But if a user claims he was new to the software, selected the default setting assuming it was best and most secure, a court might agree. I worry that our biggest concern today is potential data breaches. And I don't want to see vicidial on a list like this:

The 17 biggest data breaches of the 21st century
https://www.csoonline.com/article/21308 ... ntury.html


In searching exploits at https://www.exploit-db.com you can see the bad guys are well aware of vicidial and the potential payoffs in hacking it. These are web exploits. All of them aren't ancient history either, one of them is dated 2017.

And, I also came across this thread from this very forum in February 2011:

We were hacked: Security vulnerability in lead loader
viewtopic.php?f=4&t=25534&hilit=security+vulnerability

An interesting comment at the end of the thread too:

"While I hesitate to put this directly on the vicidial wiki, I'll put it here for now:

http://www.viciwiki.com/index.php/Whitelist

And if I get permission to move it to the Vicidial wiki, I'll move it later. Maybe Kumba will make this an option during installation on Vicibox 4.1".

[Acidshock]

Ok my .02 hehe. I think a dynamic whitelist on authentication is the best solution. It could easily be done. Personally I think it should be done for all traffic across the board...Including web traffic. Basically like a portal. You could technically offload all VICIDIAL web traffic on to an obscure port, say 43255 which is firewalled. Then there could be a page that exists on port 80/443 that authenticates against the database. If the username is correct, the IP is logged in the database and the user forwarded to port 43255. If the user revisits port 80/443 it redirects them to 43255 as long as their IP is still valid. The reason I like this style is that it also prevents attacks known and unknown to the web platform. It also makes the web platforms footprint much smaller. You can also then have a utility in the admin utilities to add an IP permanently to the allowed IP table for known ips. A script can then run on all servers which checks for updates and updates all the boxes whitelists every minute.

Kumba,

On a side note we could easily modify snortsam to allow you to push out firewall updates to all the boxes in realtime. The code is very simplistic and it could run via a simple screen session. I currently use this right now on my IDS to push out block lists on suspicious traffic. Even though my boxes are already whitelist only on 5060, etc.

[kimberly1]

How do we enable just a single login with the campaign login, and remove the phone login?
Thanks in advance for the help!

[williamconley]

How do we enable just a single login with the campaign login, and remove the phone login?
Thanks in advance for the help!

The Vicidial Manager's Manual is available free at EFLO.net. Look up the usage of $user_login_first in "options.php" and the example file available at /srv/www/htdocs/agc/options-example.php

[thephaseusa]

If you set options.php in /agc to $user_login_first=1 will you then not have to enter a phone login and phone password?
Or does it just reverse the order of login, instead of phone first its user first?

[williamconley]

You still have to enter them. Otherwise, how will the vicidial system know where to call the agent? But I believe they can be prepopulated (haven't tested that). Note that Kumba's new dynamic portal will prepopulate them. That's in another thread.

[thephaseusa]

Yes the new portal prepopulates both logins and passwords.
So the user_login_first doesnt really accomplish what the new portal does or what your dgg login page does, which is fill in all the blanks so you just have to choose a campaign and click submit to log in atthe RE-Login page. Therefore with those you need remember only 1 user/pass. The username log in and password. You dont have to remember the phone login and phone pass.

[williamconley]

Not like there's a lot of code involved in grabbing those values. All it would take is someone creating a "preference" in the system settings (or in the settings containers) that would allow this feature and then grab those values "if present" to prepopulate the next page.

Then submit a diff and voila!

[kimberly1]

Thank you williamconley and others. I searched the manual before posting the question but had difficulty finding it with my keywords search. With your help, I was only able to find:
Phone Login - Here is where you can set a default phone login value for when the user logs into the
agent interface. This value will populate the phone_login automatically when the user logs in with their
user-pass-campaign in the agent login screen. If you have agents that are always at the same phone you
can use this option, otherwise leave it blank.
NOTE: The "user_login_first" option must be enabled on the back-end of the server first, for this
feature to work.

--
I see the Phone Login field in the User record .. it currently has the user/password I set up for them. However, I'm still not able to EXCLUDE the need for them to log in an extra time/step.

[thephaseusa]

It populates the phone login but not the phone password.
As I understand it, $user_login_first=1 only changes the login screen to ask for the username /password first, as opposed to the default of the phone login/phone password being first.

If you bookmark the RE-Login page with everything filled out, then you wont have to enter any usernames logins or passwords again.

JM

[williamconley]

It populates the phone login but not the phone password.

That's just annoying. I'm happy our clients are using the DGG link. I'd think someone would have paid for an Admin Preference allowing both to be grabbed.

If you bookmark the RE-Login page with everything filled out, then you wont have to enter any usernames logins or passwords again.

Definitely good advice. We usually stop at this point during training and show this to clients so they can bookmark and place this link on the desktop of each workstation after deleting the User's password (so that's the only thing they need to remember: Their password). This allows hot-desking because the link on the desktop contains the phone login.

[kimberly1]

Thank you all for the feedback!
Agreed; it does populate the user, but not the password.

[thephaseusa]

But again, in case you didn’t notice the other thread, with vicibox 8.1.2 the dynportal allows for entering only a username and a user password, and being forwarded to the vicidial Re-Login page with both user/pass and phone/pass all filled in correctly for you, where one only need choose a campaign and click submit to log in. And after the first time, you can just bookmark the Re-Login page and skip the portal in the future. The dynportal of course also adds the user’s IP address into the dynamic list so it’s allowed past the firewall. A very nice addition to the vicibox, especially for virtual or work at home users.