Page 1 of 1

[GUIDE] Securing Vicibox

PostPosted: Tue Jan 15, 2013 9:27 am
by DarknessBBB
Hope it helps!
It seems to work. Actually I don't know how to ban people trying to access to the admin page and phpMyAdmin page. Any suggestion is appreciated!

https://docs.google.com/document/d/1I2x ... 4vMj4/edit

Re: [GUIDE] Securing Vicibox

PostPosted: Tue Jan 15, 2013 9:13 pm
by williamconley
phpMyAdmin should be locked via apache (locking the folder to remove any possible access). this requires a sep user/pass for that folder (which is not a bad thing, after all regular users shouldn't be in there anyway!). We lock ALL servers we build in this manner. It is a mere matter of creating a password file with httpd2 and configuring the apache conf file for the site.

Ordinarily, we simply whitelist the servers. We have also begun adding our Dynamic Good Guys to all client servers automatically. We only have to sell it two more times before we release it as an installable (svn down, install ... done).

Re: [GUIDE] Securing Vicibox

PostPosted: Mon Jan 28, 2013 8:54 am
by sadikhov
Thanks for the post...

Re: [GUIDE] Securing Vicibox

PostPosted: Tue Jan 29, 2013 5:41 am
by geoff3dmg
I use an IP whitelist .htaccess for my vicidial webpages and also phpmyadmin. The format of the .htaccess is as follows.

Deny from all
Allow from localhost
Allow from <IP>

Re: [GUIDE] Securing Vicibox

PostPosted: Tue Jan 29, 2013 11:39 am
by williamconley
For heavy usage: Each web page that is pulled must access the.htaccess page in every directory to check permissions before allowing access. And your server is still subject to ssh and SIP brute force attacks.

That is because it is only your web service using a whitelist stored in a flat file. Consider locking the folders via a password file, this reduces the I/O on the machine (important during heavy usage). Better yet, use IPtables to lock the entire system by IP address and then nobody who is "unapproved" can even see that your server exists. No chance to get a packet in on any port (excludes the possibility of an ssh or sip attack or any other form of intrusion). :)

Re: [GUIDE] Securing Vicibox

PostPosted: Tue Jan 29, 2013 12:24 pm
by geoff3dmg
Oh yes, I use fail2ban with jails that trigger iptables-allports as well as .htaccess files.

Re: [GUIDE] Securing Vicibox

PostPosted: Tue Jan 29, 2013 2:00 pm
by williamconley
And as long as they don't rotate IP addresses ... you're safe. I still like pure whitelist. :)

for one thing: What if they don't log in? phpMyAdmin for example has known flaws ... (not to mention known user/pass pairs in Vicidial ...). That's an example covered by your .htaccess, but I would suspect there are others in other packages not web based ... a good guess on port 3306 would wreak havoc.

Re: [GUIDE] Securing Vicibox

PostPosted: Wed Jan 30, 2013 10:57 am
by geoff3dmg
oh yeah, I agree with that. You can't even use fail2ban with MySQL as it doesn't log failed access attempts. Best way is to firewall everything then only allow the minimum access people need. The issue is with some of my smaller sites there's no server infrastructure to have a VPN server so I have to expose SSH etc to everyone and anyone so I can get access from <random wifi hotspot> when I'm on the road.

Re: [GUIDE] Securing Vicibox

PostPosted: Wed Jan 30, 2013 1:57 pm
by williamconley
we have a product called Dynamic Good Guys which opens a web port (other than 80) but only exposes a single file on that port. Without a link to that file, you'll never gain access to anything (and there is no access to any other port). After you access that page through your link ... a successful login will authorize your IP (until a reboot) and your iPad now has access at Panera Bread. :)

So far, no unauthorized access has occurred after this has been installed. We've even set it up in a couple clusters for access to the entire system.

Re: [GUIDE] Securing Vicibox

PostPosted: Thu Jan 31, 2013 5:20 am
by geoff3dmg
Yes, in a similar vein, I keep meaning to test SSH Port Knocking. Thanks for reminding me. The other thing you can do with SSH is use keys rather than passwords.