search

0perationPrivacy / VoIP

Web Base Telnyx/Twilio VoIP Interface enabling SMS, MMS and Voice calls using the providers API Keys and self-hosting the application.
https://VoIP.OperationPrivacy.com
GNU General Public License v3.0
246 stars 421 forks source link

Project Wiki - Web Application Firewall #57

Closed monkeysac closed 3 years ago

monkeysac commented 3 years ago

Apologies for opening an Issue here for something not directly related to code / functionality.

The Wiki currently suggests using Cloudflare WAF as a frontend for the VoIP web app hosted on Heroku. While its an excellent (and desired) end state I feel there should be more transparency about the means to achieve it.

The CF services suggested will essentially act to MITM any traffic you have flowing through the web app, therefore making interception & storage feasible for them and/or anyone with access to their servers. While this may come down to assessing what's worse between CF visibility (privacy anyone?) and access restrictions for certain countries (also ideal) I'd rather not have someone looking up the skirt of my VoIP solution of choice.

I'm not familiar enough with Heroku to suggest an alternative and all of their "firewall" options appear to be 3rd party add-ons. Heck, you can't even mandate HTTPS which is unfortunate. For starters, is it even possible to bundle with Nginx (to proxy for webapp) and Certbot (for SSL)?

0perationPrivacy commented 3 years ago

While this is a VoIP SMS app, I'm trying to keep it modular so you are not tied down to one technology, that includes WAF. I've implemented many WAFs in my career, honestly speaking, CloudFlare has been the easiest AND EXTREMELY effective.

For a cloud based app, this is the most feasible solution (free and quick with pretty decent privacy). For hosting on a VPS, it depends, if it's on NGINX, you can use ModSecurity (now maintained by F5), there's IPTables, full on appliances like F5 BIG-IP, etc.

On my task list I've put in a few native firewall features in Node.js like bruteforce protection (coming soon in a future update) and whole bunch of other easy ones.

Hosting on Heroku gives you their domain which already has the certificate on it, so you don't need to worry about letsencrypt. In self hosting, that's your headache.

I'll keep the app independent of the WAF but the above are my suggestions. Feel free to suggest better options for this use case (also looking at other apps on how they do it would help - hint, all enterprise apps use enterprise grade dedicated WAF appliances $$$)

monkeysac commented 3 years ago

While this is a VoIP SMS app, I'm trying to keep it modular so you are not tied down to one technology, that includes WAF. I've implemented many WAFs in my career, honestly speaking, CloudFlare has been the easiest AND EXTREMELY effective.

I agree. I use CF as well, though not often for circumstances such as this (possibly private comms). Standing it up against a Heroku+MongoDB deployment will have marginal benefit, if any, if your web app is always accessible at its herokuapps.com address (correct?). I reiterate my inexperience if not ignorance with heroku...

For a cloud based app, this is the most feasible solution (free and quick with pretty decent privacy). For hosting on a VPS, it depends, if it's on NGINX, you can use ModSecurity (now maintained by F5), there's IPTables, full on appliances like F5 BIG-IP, etc.

We'll have to agree to disagree about privacy on CF. :) If the recommendation remains perhaps its made apparent for users that their browser-based communication with web servers positioned behind their services are not end-to-end encrypted.

On my task list I've put in a few native firewall features in Node.js like bruteforce protection (coming soon in a future update) and whole bunch of other easy ones.

Very nice, thank you! Might it also be worth considering the addition of a Config Vars variable for a URI directory from which to serve the app (e.g. rather than ://web.app, serve blank page there + serve sms from ://web.app/randomdirectory/)? Yes I understand this is "security through obscurity" but in the absence of security options found with self-hosted/VPS it might be cool.

Hosting on Heroku gives you their domain which already has the certificate on it, so you don't need to worry about letsencrypt. In self hosting, that's your headache.

And via Heroku the app remains perpetually available via http/80 with no way to specify otherwise (that I could find). Its a shared server, yes, but the HTTP URL could be entered inadvertently entered and accessed by the user. Is there a way to refuse service in the absence of HTTPS using your technology stack...HTTP header detection perhaps?

Anyways, thanks for your discussion and debate. I wish I was able to lend a hand with development.

</rambling old man>

0perationPrivacy commented 3 years ago

@monkeysac great discussion, Thanks for that advice 👍🏻

Besides all this, the BIGGEST vulnerability is that the source code is open to the public. Nothing I can do about that 🤷🏽‍♂️

Remember this is still considered beta and insecure. Not as private as we all want, but better than the telco providing us the service. We now have some control over the infrastructure. It will mature with time, I guarantee you that.

monkeysac commented 3 years ago

Remember this is still considered beta and insecure. Not as private as we all want, but better than the telco providing us the service. We now have some control over the infrastructure. It will mature with time, I guarantee you that.

Agreed on all points. I'm very excited to see where this project goes!

Edit: Also if you end up charging for an app or turnkey access to the services please dont restrict payment to the dang play/app stores (looking at you, mysudo)! :)

0perationPrivacy commented 3 years ago

Remember this is still considered beta and insecure. Not as private as we all want, but better than the telco providing us the service. We now have some control over the infrastructure. It will mature with time, I guarantee you that.

Agreed on all points. I'm very excited to see where this project goes!

Edit: Also if you end up charging for an app or turnkey access to the services please dont restrict payment to the dang play/app stores (looking at you, mysudo)! :)

I will never charge for this app. It will eventually be on iOS and Android, always free. The donation option will always be open. If I wanted to make money from this, I would have had 10 other ideas. (You just have to bare with me juggling between 10 projects right now 😅) Enjoy 😇!

monkeysac commented 3 years ago

@0perationPrivacy for this one, did you happen to research feasibility of shifting app to a "subdirectory" of the heroku domain with a config variable (e.g. BASE_URL defined as https://xyz-cluster0.qxtle.mongodb.net/2Ci8hFvexFo5eW2/) ?

0perationPrivacy commented 3 years ago

@0perationPrivacy for this one, did you happen to research feasibility of shifting app to a "subdirectory" of the heroku domain with a config variable (e.g. BASE_URL defined as https://xyz-cluster0.qxtle.mongodb.net/2Ci8hFvexFo5eW2/) ?

Yes, in the process of implementing it, it's not as easy, it literally breaks everything as every API and function is tied to a directory. I'll have to change all directory paths for webhooks in Telnyx and Twilio as well. So if you suddenly introduce a new directory, all your sms's would stop working. You will need to go to each profile and press save again to replace the webhook links with the new URI. Will take a bit more time, but I'm working on it.

monkeysac commented 3 years ago

it literally breaks everything as every API and function is tied to a directory. I'll have to change all directory paths for webhooks in Telnyx and Twilio as well. So if you suddenly introduce a new directory, all your sms's would stop working.

Makes perfect sense, and I completely understand this one has to be chalked up as a "nice to have" given the goals & priorities of the project. One thing I did note in the time since is the fact our Github forks link to the heroku deployments by default with no option to disable it (yikes). Likewise, these forks are easy to discover via the git network.

This "discoverability" may put a new spin on a possible need for frontend obfuscation because, to your point, if an exploit in the code is discovered it can be capitalized on quite extensively...