Webconfigurator mobile access requires "Disable HTTP_REFERER enforcement check"
-
It seems that accessing the webconfigurator from my iPhone over the AT&T 3G network requires "Disable HTTP_REFERER enforcement check" on System: Advanced: Admin Access. Over WiFi it works just fine without that option.
A) is this expected/normal?
B) how severe are the security implications of checking that option such that remote admin through the cellular network is possible? -
Never heard of that happening, must be some kind of proxy that changes the REFERER, though that's an odd thing for a proxy to do. I'd only access over VPN remotely, to hit it on 3G you must have it wide open to the Internet.
Disabling that isn't a huge risk, it's an extra protection that almost nothing else provides but is a good practice. If you follow general best practices like never administering any web-managed device from the same browser you use for general Internet usage, then you don't have to worry about that at all.
-
@cmb:
Never heard of that happening, must be some kind of proxy that changes the REFERER, though that's an odd thing for a proxy to do. I'd only access over VPN remotely, to hit it on 3G you must have it wide open to the Internet.
Well, access is pretty simple:
Mobile Safari on the iPhone or iPad going through AT&T's wireless network directly to the web configurator via https; no proxy that I set or use. => warning
Mobile Safari on the iPhone or iPad going through the public WiFi at some cafe, or the private WiFi at home directly to the web configurator via https; no proxy that I set or use. => no warning
Of course, the mobile internet assigns some private IPs to the devices, but the same thing happens in most WiFi networks other than the one at home.
So I would have assumed that there is no proxy-ing with https? Or do AT&T and their friends at the NSA plant a man in the middle (remember the retroactive telco immunity…)
VPN access isn't possible, because L2TP doesn't work as expected, and regular IPSec won't work, because I already have to use an IPSec tunnel as my default route (remote network: 0.0.0.0/0), so any extra IPSec tunnel creates issues. I figured SSL would be sufficiently protected, maybe not...
-
Yeah if you're on HTTPS it should be impossible to change the REFERER. Unless you are being MITMed, which I seriously doubt, it's the phone's behavior that does that. Odd, haven't heard of that being the case, and haven't seen it personally, though I very rarely get onto any firewall via 3G on my iPhone and my iPad is wifi-only.
-
@cmb:
Yeah if you're on HTTPS it should be impossible to change the REFERER. Unless you are being MITMed, which I seriously doubt, it's the phone's behavior that does that. Odd, haven't heard of that being the case, and haven't seen it personally, though I very rarely get onto any firewall via 3G on my iPhone and my iPad is wifi-only.
Hm, why would the phone do that? It just (should) connect(s) over whatever link is available. That's exactly why I'm somewhat spooked (pun intended).
Does anyone have an iPhone on AT&Ts network, who can try to access their pfSense box over 3G/4G and see if they have the same problem?
-
I opened mine up temporarily to check, works fine via 3G on AT&T. Are you accessing it via a link from some other page? One thing that can make that come up is if you have a page with a link to send you to your firewall. You'll have to refresh the page so it's its own referer in that case. That wouldn't be any diff on wifi vs 3G.
-
No link that I'm aware of.
I type in the CNAME (e.g. gateway.my.net) of the host which is translated into the dyn-dns name (e.g. gateway.dyn.net) and resolved into an IP address, at least that's the theory.The only thing that I could see is that it get confused somehow with the two host names, but since I use the same host names when on WiFi and on 3G I don't think that should make a difference.
As I said: it's only when on the 3G net that this happens, WiFi access is just fine, same device, same browser, same everything that I can think of, which is what's so strange about it.
-
And you're sure that DNS entry is actually a CNAME and it's not some kind of HTTP redirect happening?
-
And you're sure that DNS entry is actually a CNAME and it's not some kind of HTTP redirect happening?
That'd be my guess too, though that shouldn't differ regardless of network. Probably would work if that CNAME is listed as an authorized hostname under System>Advanced.
-
And you're sure that DNS entry is actually a CNAME and it's not some kind of HTTP redirect happening?
Yep, I make that CNAME entry myself on my DNS server, and pfSense updates the host entry with DnyDNS that the CNAME points to.
-
@cmb:
Probably would work if that CNAME is listed as an authorized hostname under System>Advanced.
I'll try that later on. Good idea.
EDIT: That seems to have fixed it. At least it works now…
Thanks! This was driving me nuts. Still don't get it why this was only an issue on the 3G network ???
