I found my.firewalla.com... now, how do I stop it from going outside?
After the fiddling to get the bizzarre pairing to work by soldering a camera onto my toss-away phone I learned there IS a webUI... YEAH!
The webUI seems good if not simple... a WIP... thanks for the work. Now... when I use the webUI I get traffic egress traffic from the workstation to my.firewalla.com (various addresses). When I block it (after all the firewalla DNS should handle this and route to itself)... the webUI won't refresh or react to clicks.
Why does a local http server on the firewalla named my.firewalla.com have ANY traffic egress traffic and, why would it be from the workstation?
There are zero good and secure reasons for me to send information outside my network to manage it. How will this work when I move it into a network segment that cannot access the extranet?
After all NONE of this information should EVER leave my network for ANY reason other than the rare debug efforts... or this device increases attack vectors to include your system, all your employees, AWS employees, and the internet in general.
Well, our philosophy is to security usable. The product we are building is targeted at consumers and also small businesses. The box is not designed to be used in places where there is no internet access.
We certainly can customize the software for special environments that's outside the normal deployment, but there will be an additional cost.
As stated... this device does NOT add security... it increases risk.
You may have succeeded on usable (for some). But lost the security on the way.
The mere fact that information about my network goes outside of managed control and into the hands of ... who knows who... is the antipode of security... so, fail on the philosophy in actuality.
Nobody should have this on a real network with it spewing critical information across the net to some unknown stranger and stored in some unknown place with unknown security.
The closest to 'secure' I can see this design is called liability. Since we have no agreement on your secure and safe disposal of this data within seconds of arrival (or just blocking it); we don't even have that.
The best thing this does is educate people on what ruled they need to put into a firewall without the exploits designed in Firewalla.
What is the plan to correct this in-built, designed in Exploit?
@ Frank: there is a lot more out on servers as I (and you) expected.
I had been moving from blue to gold. Even before installing the gold, I had pondered to backup my ruleset (on the blue) to a PC, unplug the blue, start up the gold, and after getting it working, restore the backed-up ruleset of the blue into the gold. How naive! It's not bread & butter any more, it's all cloud. Even with the blue disconnected, I could comfortably import the ruleset, along with device names and alarm settings, from the (cloud-) repository into the gold, the blue was unpowered and disconnected, not involved at all.
So I conclude, there is a lot in the cloud, similar to having one's traffic logs in MS OneDrive. It's convenience and simplicity in focus, NOT privacy. As a privacy advocate, you need to switch into opensource like pfSense or OPNsense. Aware of that, I will still stick with cloud-based FireWallA - for convenience.
In the scenario I discussed, no phone was involved other than to gain access to my.firewalla.com. It was a laptop and the firewalla via ethernet.
Jul 21, 2020, 8:01 PM PDTIf you are you comfortable using the web page, please do not use it. The web page does not store anything, it is just a GUI presentation from your box.-------------------Me:Ahh... so an application on the local server/firewalla can do just the same to display the data which is likely sitting in the redis database on the firewalla. No need to go elsewhere but to the firewalla. Love it!All we need is a small tweak and we don't have easy bypassed and disabled authentication requiring a separate device! Or, use something like 'Authenticator' to manage TFA.Reduces the effort on the phone app since a TFA authentication to a web service that contains exactly 2 things ... the IP of the Firewalla and the port it listens on for TFA.Then the phone browser is launched to that IP/port and TFA occurs with the firewall... web page presents data... Bob's yer Uncle.Reduces your server overhead immensely not having to have those silly ssl sessions convey data to AWS.Then the Users risk is mitigate because nobody can pick up the phone and walk with the keys to her network.Your risk is mitigated since you employed TFA for your web service which retains only 2 bits of data (IP and port). And, not actionable private data, ... whatever is going over those 3 SSL sessions.
I forgot to mention above that a user selectable periodic update check is done.
Also, this can occur on a PC. Ridding the need to use a walking cellphone exploit we carry in and out of risk areas, loan for calls or views, and lose far more often than laptops and desktops.
Please sign in to leave a comment.