ViciBox v.8.1 dynamic portal add-on

[Kumba]

I've made an add-on for the ViciBox Firewall in ViciBox v.8.1. This give you a portal that you can validate your IP against to get it added to the dynamic list.

You can install it by doing the following:

Code: Select all

wget http://download.vicidial.com/vicibox/install-dynportal.sh
bash install-dynportal.sh
pico /etc/apache2/vhosts.d/dynportal-ssl.conf    # Make changes here to match your SSL setup if you have valid certs
service apache2 restart
pico /srv/www/vhosts/dynportal/inc/defaults.inc.php   # Make any set-up changes you want here, like URL redirection, etc


After that, you can go to http://<server>:81/valid8.php for standard HTTP or https://<server>:446/valid8.php for HTTPS connection.

The portal is simple. An agent types in their user ID and password and if it matches an entry is made for the ViciBox Firewall's Dynamic IP List. Within a minute of them validating their IP they are able to login to access the ViciDial server/cluster normally. You will need to have already set-up the firewall to use the dynamic list before this will help with anything. But this gives a similar validation portal as Dynamic Good Guys and also works across a cluster of servers.

I might add a redirect option after login with a countdown timer to help make things easier, but this is good enough for a first draft. Another benefit is that this doesn't necessarily need to be running on a ViciDial server itself, but it will need to be able to get to the ViciDial database across a network to work right.

[thephaseusa]

Very nice thank you!

Is within 1 minute based on adding a once a minute —dynamic cron entry for VB firewall?

Also you have dynportal defaulted to validate users level 5 and above. I went in and changed mine to level 1, which I have agents set at. Should I be setting them at level 5?

John

[Kumba]

Very nice thank you!

Is within 1 minute based on adding a once a minute —dynamic cron entry for VB firewall?

Also you have dynportal defaulted to validate users level 5 and above. I went in and changed mine to level 1, which I have agents set at. Should I be setting them at level 5?

John

Yes, you need to run VBF every minute with the --dynamic flag set in cron. I'd recommend running --dynamic --flush flags. So something like this:

Code: Select all

* * * * * /usr/local/bin/VB-firewall.pl --dynamic --flush

It is worth noting that as long as the agent logs in through vicidial normally once every 14 days they don't need to go back through the dynamic access portal. The --dynamic flag looks for IP's that have logged in normally through ViciDIal as well as ViciBox dynamic portal logins.

User level 5 was just an arbitrary value picked that was the middle of the road. It's purpose is to provide an admin setting that further defines what agents are even allowed to use the dynamic portal. It can easily be changed like you have found out by editing inc/defaults.inc.php and changing the $PORTAL_userlevel value.

[thephaseusa]

Thanks again for the dynamic portal, it is working for me like a charm. Here is what I did with it:

I added onto your page valid8.php:

After you validate your login wait 60 seconds and click on the link at the bottom, then at the System Access Authorization page enter the same user name and password, and you will be sent to the VICIdial login page, where you can choose a campaign and click submit to log in. After you log in then click Call Agent Webphone, and you should hear "you are the only one in this conference" if you are properly logged in. You may want to bookmark the System Access Authorization page for future logins. LOGIN

So I give them a link to the dynamic portal and a username and password. They enter it on the page, click submit and get the message Login Validated for IP XXXXX. They wait a minute then click the link at the bottom which opens up the old System Access Authorization page from Dynamic Good Guys, which is the vicidial relogin page with user/pass/phone/phonepass all filled in already. They choose a campaign and click submit. Then they click on Call Agent Webphone and they hear the woman's voice if all is well.

I've logged in 3 new agents this way today!!!!

I have started a push again to hire virtual agents to work from home. The time required to get a new person logged in has been shortened considerably. My goodness how sweet it is to not have to talk about downloading, configuring, registering zoiper all day long! You guys are the best. Thank you VICIdial and thank you VICIphone!!!!!

[Kumba]

So I give them a link to the dynamic portal and a username and password. They enter it on the page, click submit and get the message Login Validated for IP XXXXX. They wait a minute then click the link at the bottom which opens up the old System Access Authorization page from Dynamic Good Guys, which is the vicidial relogin page with user/pass/phone/phonepass all filled in already. They choose a campaign and click submit. Then they click on Call Agent Webphone and they hear the woman's voice if all is well.

I'm not sure what you mean by the 'old System Access Authorization page from Dyanmic Good Guys'. After the dynamic portal validates the IP you should be able to just send them to the regular agent login at http://server.ip/agc/vicidial.php

As far as the auto-redirect and all that, I thought about adding it but didn't for two reasons. First was because I wanted to get the portal out quickly without slowing down the development with extra optional features. The second reason is that option really needs to be configurable since it could be considered a security concern. But my next update to the dynamic portal will likely include the ability to have a 60-second countdown and an automatic redirect to the agent login page.

[thephaseusa]

Thanks for your work. The portal is adding IP’s to the dynamic firewall list within 60 seconds just like you said.

I used that system access web page because i like the fact that you can log in there with just a user/pass and it takes you to the vicidial re-login page with everything filled in already. Otherwise agents have to remember a username, user password, phone login, phone password.

[williamconley]

For ease of use, the DGG login page will grab phone/phone pass from the user record on the way to drop the agent at the re-login page. Thus they have to hit login one extra time, but they don't need to remember credentials. Handy. I highly recommend this method. Probably similar to the options.php method that allows user-login-first, but I've never compared.

We've since modified it for a few clients that if there are no credentials it goes to the admin site instead of the agent relogin. For roaming managers.

[Kumba]

ViciBox Dynamic Portal v.1.1 has been released. What it add's is URL redirection with various features.

Features:
- Configurable agent URL
- Configurable admin URL
- Countdown timer with redirect message is displayed to the user upon successful login
- Configurable countdown timer, default is 60 seconds
- If the 'Phone Login' of the user's record in ViciDial is set to 'admin' it will redirect to the Admin URL
- Phone/User login and password can be passed through to the agent or admin interface
- By default only IP validation is enabled, the above can be set through the defaults.inc.php file


Make a backup if you have any custom changes first, but here's how you can upgrade to the new version :

Code: Select all

cd /srv/www/vhosts/
wget http://download.vicidial.com/vicibox/dynportal-current.tar.xz -O dynportal-current.tar.xz
tar -xf dynportal-current.tar.xz
cd dynportal
rm -rf apache2
pico inc/defaults.inc.php  # Make any setting changes here


The install-dynportal.sh script will also pull in this new version and install it on new installs.

The dynamic portal will be in ViciBox v.8.1.3 whenever I release that as well. All you'll have to do is just open TCP ports 81 and 446 for it.

[thephaseusa]

I just saw your post and just installed the new dynportal on another box. Nice))))))))
By default it grabs the phone login/phone pass and in 60 seconds it redirects to the RE-Login page with all the blanks filled in already. Thanks this saves me another step.

Excellent work on the new vicidial 8 firewall and the vicidial 8 dynportal!!!!!!!
Sweet))))

Not to be a spoil sport, but I think I found a small glitch.

You can enter a username that is not case sensitive, it will still validate the IP and redirect to relogin with the username spelled wrong. For example, i have a username of spc601 I tried SPC601 instead and it accepted the user/pass, and sent me to a relogin screen with SPC601 filled in as user login. Then of course if you try to log in, vicidial gives an error message of incorrect login, case sensitive user names.

John

[Kumba]

Not to be a spoil sport, but I think I found a small glitch.

You can enter a username that is not case sensitive, it will still validate the IP and redirect to relogin with the username spelled wrong. For example, i have a username of spc601 I tried SPC601 instead and it accepted the user/pass, and sent me to a relogin screen with SPC601 filled in as user login. Then of course if you try to log in, vicidial gives an error message of incorrect login, case sensitive user names.

John

OK, I'll take a look at it on Monday.

[williamconley]

I'd prefer Correction of the case-incorrect username rather than forcing case sensitivity. Case sensitivity should be reserved for the password.

Otherwise, Bill and bill are not compatible, and most users forget. It's a bit over the line to make MATT and matt and Matt three different users, or fail them for forgetting which one they are when they are really all the same user.

We usually convert all to upper case before comparison to avoid this problem (but only for the user name field). But apparently also Grabbing the correct version would be a good idea as well.

[dspaan]

Thanks for this add-on!

Questions:

-What parameters do i need to edit in /etc/apache2/vhosts.d/dynportal-ssl.conf ?

I replaced the paths for these ones:

SSLCertificateFile
SSLCACertificateFile
SSLCertificateKeyFile

With the paths i had in 1111-default-ssl.conf (i used certbot earlier to get a valid let's encrypt cert)

-When i visit https://myip:446/valid8.php i get to see a message: 'SSL is required but not available!'
The instruction says:

$PORTAL_secure=1; // 1 = Enable forced HTTPS, 0 = Disable forced HTTPS; If you aren't running on standard SSL ports this probably won't work!!!

Does this mean i need to use 443 instead of 446 for it to work?

-After i login i get a message 'Login Validated for IP <myip>' but i'm not getting redirected to the vicidial

-Does the .sh install script open up ports 443 and 81 in the yast firewall? I wanted to open them but noticed they were already open. Your instruction says port 446 is needed so this was a bit confusing.

-Could you make the portal so the phrases can be translated to the vicidial translation database?

[thephaseusa]

Yes in 1111-default-ssl.conf change the path to your certs for SSLCertifcateFile SSLCACertificateFile SSLCertifcateKeyFile
(/etc/certbot/live/FQDN/cert.pem fullchain.pem privkey.pem)

Also change path in dynportal-ssl.conf for SSLCertificateFile SSLCertificateKeyFile

In /etc/sysconfig/SuSEfirewall2 add 446 to FW_SERVICES_EXT_TCP and restart SuSEfirewall2

And in /srv/www/vhosts/dynportal/inc/defaults.inc.php I have $PORTAL_secure=0;
And also $PORTAL_userlevel=1;

And i use https://FQDN:446/valid8.php

Also, the original portal Kumba posted didn’t have a redirect. The second one does. If you already installed the first, he included an upgrade procedure.

John

[dspaan]

Hi John,

I have exactly the same settings as you
And i'm using the second version.

Just verifying.

Feature request for V8.1.3: When certbot runs, also update the pem file paths for Dynportal!

[Kumba]

Feature request for V8.1.3: When certbot runs, also update the pem file paths for Dynportal!

Update the paths? If you have set-up the apache conf file to match the paths that certbot uses then it will always have whatever SSL certificate certbot last got.

I'm not quite understanding what you mean.

[williamconley]

Note that certbot has a symlink that is repointed to the Live cert. Don't point directly to the cert, point to the symlink which certbot will update to point to the new cert each time.

[dspaan]

I'm talking about this step in the install instruction:

pico /etc/apache2/vhosts.d/dynportal-ssl.conf # Make changes here to match your SSL setup if you have valid certs

What do i need to update exactly in the .conf file?

Also, a suggestion about this parameter:

$PORTAL_redirectadmin='https://server.ip/vicidial/admin.php'; // Only matters if the above is not X and the phone login is set to 'admin' on the user record

Isn't it better to use one of the custom 1 to custom 5 fields (i think 5 is best) instead of the phone login? Because as admin i still login as agent to test stuff and don't want to use admin as phone login. Also what if there are more then one admin? They all have the same phone login which won't work.

[Kumba]

I'll be releasing the ViciBox Dynamic Portal v.1.2 along with ViciBox v.9.0 sometime in the new few weeks. Here's a list of changes/additions made to it:


- Release v.1.2
o Added an incurred delay to all submit requests regardless of
whether the login was correct or not; Default 1 second
o Added an Apache mod_cband configuration to deter DDoS and brute
force attempts; Requires the mod_cband apache module to be loaded
o mod_cband requires /srv/www/cband/dynportal.scoreboard to work
and it must be owned by the apache user (wwwrun:www on ViciBox)
o Updated and consolidated the Apache VHost configs
o Restricted access to ./inc directory through Apache directly
o Configurable HTML User ID and Password variable names to help
prevent bots and script kiddies from using canned attacks
o Added $PORTAL_casesensitivity to defaults.inc.php to control whether
the user or password field is matched aginst case sensitivity
o Added a check for failed login attempts stored within ViciDial so
that the portal can be tied to ViciDial's own security measures;
Default is 5
o Added the ability to increase the ViciDial failed login count
when invalid portal auth attempts are made; Disabled by default
o Added $PORTAL_adminfield in defaults.inc.php to allow the use of
any field in the vicidial_users table to be used for determining
if the regular or admin redirect URL is used
o Removed Changes section from code and put into the CHANGES file

[dspaan]

Very nice, looking forward to the next release! It would also be nice if you don't have to wait for the countdown timer until the cronjob has run but instead it will insert the rule immediately. And also an option that can open port 22 SSH for you. Sometimes i'm on the road and need access to a client server and can't get to it and VPN doesn't work over my mobile internet.

[Kumba]

The database insert is done as soon as you see the green authorized message. The problem is that the portal code doesn't control the actual system firewall. It just makes database inserts that VB-firewall.pl pulls from the database to do the actual firewall modifications. This is the only way for the portal to work across a cluster. The simplest way for me to run VB-firewall.pl is from the crontab entry, so once a minute it is. The other issue is if you had this scraping the ViciDial database once every second or even once every 5 seconds you would be generating load on the vicidial log tables which is never a good thing for ViciDial.

As far as controlling SSH you can modify the SuSEfirewall2-custom script to do that if you want. This is also outside the scope of the dynamic portal.

Very nice, looking forward to the next release! It would also be nice if you don't have to wait for the countdown timer until the cronjob has run but instead it will insert the rule immediately. And also an option that can open port 22 SSH for you. Sometimes i'm on the road and need access to a client server and can't get to it and VPN doesn't work over my mobile internet.

[williamconley]

DGG uses the xt_recent (or ipt_recent) module in iptables to create immediate effect. This could obviously be ignored after the minute mark, but it could be used to get the agent phone to register immediately and get the agent into the system. DGG, in fact, bounces directly to the re-login page from a successful login because it's active. The challenge is only with multi-server systems where the phone and web are on different IP address or on web load balanced systems where the initial login may not be the final login. however, we do have a "reach out and push to the recent module on ALL servers" method available as well. This either requires trust between servers and apache permission to launch an ssh request to the other server OR just a web page on each server that accomplishes the same task with a curl request from the original server.

Feel free to check the code on DGG. It would be nice to retire that in favor of this (otherwise more robust) system.

[Kumba]

I'm trying to keep the public facing web portion separate from any code that does real work, like performing system calls or modifying IPSets, for security reasons. In fact if I could further remove the portal web interface so that PHP/Apache didn't make any direct database calls that would be even better. Unfortunately that would either require some sort of a proxy/daemon/something running locally or a receiver/API part on a web server. That's just a level of complexity I'm not willing to freely invest any time in at the moment.

Right now I'm trying to convert VBF to firewalld cause that's completely broken.

[williamconley]

When we do it, we allow apache access to a specific device file (an entry to the GOOD device containing the IPs). Since the result will be the same (just faster than 60 seconds), it's almost like writing to a log file. Just that this file allows Immediate access to the system in a kernel-level device (which uses that "non-log" file instead of a Database entry). It still does this as the apache user, no elevation is required until you step over that line of "remote access" (which can be avoided with curl for security purposes by simply mirroring the identical request on all servers instead of just that one).

We did bump into a problem with a client who didn't want apache running on his dialers, and had to elevate to get that install to work properly.