No access to webinterface "Potential DNS Rebind attack detected" since July/3
-
Hi,
http://redmine.pfsense.org/issues/708 ?
I can't access the webinterface anymore..
Thank you!
Edit: Is it safe to downgrade to the last snapshot before? The one from 30th June? Or was there anything changed inside config.xml?
-
Same here.
Edit: I reinstalled June 30 snapshot and reloaded a saved configuration and all all is back to normal. Before resorting to this solution I reset the system to factory default 3 times and set everything as a first time setting to no avail. After setting it back to https the "Potential DNS Rebind…" appeared.
-
using HTTPS.)Note: Access vi internal IP works (still using HTTPS). This access is via the OpenVPN Server running on this same system.
System info:
Host: VMWare ESXi 4.x
Guest: Initial Install: pfSense-2.0-BETA3-20100630-1444
Update: pfSense-Full-Update-2.0-BETA3-20100703-0057 via AutoUpdate w/signing check disabled"Hardware":
2 CPU
2 NICs (Only 1 in use, running as OpenVPN Server Only)
256MB RAM
1GB HD -
This happens to me also when accessing it from lan
Edit: same problem with today's snaphot
-
I've been accessing my VMs from their LAN side and WAN side both, haven't had any issues. Have you tried with a snapshot from the 5th or preferably the 6th?
-
I'm getting this message when accessing pfsense via its DynDNS FQDN on WAN (https). No problem using the WAN IP address, nor using https://pfsense or 192.168.1.1 from LAN. Chrome and Firefox affected.
July 4 and 5 snapshots affected. Will try the latest tonight.
-
ok, that's a new bit of information. I've only been accessing it by IP address.
-
This commit just went in which should help with dyndns hostnames, as long as the dyndns hostname is configured in pfSense (which it should be in most cases).
Can you try to gitsync and try again?
-
And I committed a fix after that which fixed another issue with that.
It works for me from dyndns hostnames now.
-
Sorry, I tried everything on the git page you linked and got nothing but errors. I also made my filesystem writable first but no dice.
-
ah, on nanobsd that doesn't work so well.
You'll have to wait for the next new image. I stopped a build in progress since it didn't have these changes, and started it again. It will probably be late this evening when it uploads the nanobsd images.
Or you can download an updated copy of /etc/inc/auth.inc:
# /etc/rc.conf_mount_rw # fetch -o /etc/inc/auth.inc http://redmine.pfsense.org/projects/pfsense/repository/revisions/master/raw/etc/inc/auth.inc # /etc/rc.conf_mount_ro
-
I'll try the next snapshot then. Is there some cleanup I need to do in my filesystem after attempting to install git? I don't see anything glaringly out of place in /root or /tmp.
-
I'll try the next snapshot then. Is there some cleanup I need to do in my filesystem after attempting to install git? I don't see anything glaringly out of place in /root or /tmp.
Not really, it might leave some files in /root/pfSense/ you can safely remove.
-
Hi again,
tried the 6th June Snapshot, still the same issue.
Cannot access the webinterface from wan by its ipaddress nor hostname. DNS Rebind…
I'll try next snapshot when it comes available. -
Jim made the change around 3.5 hours ago; not long enough to be in the latest build. The next snapshot will be the true test.
-
Yes, I'm excited already ;)
BTW: was just referring to "Have you tried with a snapshot from the 5th or preferably the 6th?"
-
Especially since I had to stop the builder and restart it again, we found several more bugs and cases to test for in that code.
If you need the fixes, pull in the code with the fetch command I mentioned above and it should be OK.
-
Hey, thnx very much.
I for myself will stick to 30th June Snapshot in the meanwhile.Thnx for all the hard work!
-
This may be a Potential DNS Rebind attack not an issue with pfsense. Do an nslookup or dig of google.com or twitter.com Use multiple DNS servers other than your own as well as the router.
-
This may be a Potential DNS Rebind attack not an issue with pfsense. Do an nslookup or dig of google.com or twitter.com Use multiple DNS servers other than your own as well as the router.
No, we actually added a bunch of code to protect against DNS rebind attacks that would affect the web interface, but the checks needed some work. They should be OK in the next snapshot that comes out.
-
If you have an account at OpenDNS.com (and not just using their forwarders) you can have RFC1918 responses filtered out automatically, effectively disabling all DNS rebind attacks.
-
@kpa:
If you have an account at OpenDNS.com (and not just using their forwarders) you can have RFC1918 responses filtered out automatically, effectively disabling all DNS rebind attacks.
There is a checkbox in the current repo code to disable these checks entirely if you want :-)
-
Hi again,
just to let you know: the current snapshot 20100706-2143 still doesn't allow me to access the webinterface via its ip address nor hostname :(
-
@mxx:
Hi again,
just to let you know: the current snapshot 20100706-2143 still doesn't allow me to access the webinterface via its ip address nor hostname :(
What type of snapshot or update file is that? I'm not seeing any files with that timestamp.
Are you running the GUI on a standard port? Any kind of port forwarding involved?
Does it work after you do the fetch command I mentioned earlier in this thread?
-
I used http://snapshots.pfsense.org/FreeBSD_RELENG_8_1/i386/pfSense_HEAD/updates/pfSense-Full-Update-2.0-BETA3-20100706-2143.tgz
That's the latest one I've found.
I'm running the webif on a non standard port (5556). No port forwarding at all.
Sorry didn't try to download the inc file manually as I thought it would already have been built-in in this Snapshot.
I'll give that a try now!
Thank you!
-
It's possible that the snapshot didn't get all of the changes we checked in, I don't remember when it was started.
-
That snapshot does have the code for letting you in with the GUI on an alternate port, and I can put my WebGUI on that port and it works fine.
Is there something else different about how you access the GUI? A proxy involved somehow?
-
Okay after that it does work when I use the wan ip to connect.
When I use the hostname I setup for that ip in our dns server hosted externally, it does not.
It's quite bothersome to differentiate all the ip addresses used by different boxes and 2 pfsense firewalls that's why I set them up..Will this also get fixed or would I have to disable the feature completely?
You mentioned a switch to turn it off, could you please tell me where I can find it?Thanks!
Edit: no proxy, really standard config.. really strange.. accessing it by its ip address before I pulled the file didn't work at all, though I cannot say for sure whether it was a browser cache issue, sorry. However access by using the ip address works, but not with its hostname.. though this hostname is fully resolveable…
Edit: ok, I'm sorry, the error might be that pfsense's locally configured fqdn doesn't match the forwarding in the external dns server, what do you think?
Edit 3: But the problem is that this fqdn isn't possible to be resolved it's just a local domain...
I'd really like to be able to access each of its wan if ips by hostname forwardings..
May changing its hostname afterwards have any possible negative impacts on anything? Haven't installed tinydns.. ? -
We already thought of just that scenario. :-)
Go to System > Advanced, on the admin tab. Put your custom hostname in the "Alternate Hostnames" box.
-
Hahaha great!
Thank you :)
All the best,
Max
Edit: works like a charm
-
Request: could you disable the feature by default or disable it until the first successful web login?
The way it is now it was a bit complicated to install pfsense on a VM only accessible by dnat through another router.Thanks!
-
I doubt that's going to be possible because it would defeat the purpose.
If you have a VM, usually you can stick another VM on its LAN. The only "official" way to get into the web interface to start with is from the LAN.
If it doesn't work when accessing it via IP address, then that could probably be addressed, but we'd need a lot more info.
-
Yes I can stick its lan interface into another vswitch to set it up, but this is just one possible scenario where it's quite easy.
I had a linux box in the lan accessible by its lan ip with one interface in a vswitch. Pfsense's lan if was connected to the same vswitch.
Pfsense LAN IP: 192.168.20.1 -> vswitch
Linux LAN IP: 192.168.0.30 -> LAN, 192.168.20.20 -> vswitch
I set it up to dnat incoming requests on port 443 from the lan side, to 192.168.20.1 and to SNAT to 192.168.20.20When trying to connect via the linux box' lan ip from the lan side, I was greeted by dns rebind warning.. I edited config.xml and rebooted..
-
I'm going to commit a patch here in a while that will work if accessing by any IP, since the DNS rebinding issue only matters for hostnames.
Though I'm considering adding a warning to the login screen if the IP isn't a local IP.
-
Thanks!
-
It should be patched now, though I made it display an error if you are accessing it by an IP that is not configured locally on the system, since that could still be a potential man-in-the-middle attack even if it is a valid configuration.
-
I get no error using the July 8 build accessing via DynDNS hostname on WAN, which is the one scenario that was causing the error for me previously.
-
I get no error using the July 8 build accessing via DynDNS hostname on WAN, which is the one scenario that was causing the error for me previously.
That was one of the first exceptions that was added, so it's good to know it's working :-)
-
No errors here with July 10 snapshot.
It is Fixed. -
I experienced and solved a very similar problem on 2.0-BETA4 (amd64) built on Thu Oct 7 18:57:45 UTC 2010 FreeBSD 8.1-RELEASE-p1.
I had two unused interfaces, DMZ and OPT2. I had DMZ set to something like 192.168.252.254/24. Then I disabled that. Then I enabled OPT2 and set it to the same IP address. After that, every time I used the web interface to access OPT2 I would get a completely different page, with the simple error message of "Potential DNS Rebind attack detected." I tried several different things, but nothing would allow me to change the IP address.
Finally, I logged in via SSH. I selected the menu option to change the interface IP address. I did so, to something unused like 192.168.251.6 or whatever. After that, I could get back into the web configuration menu for OPT2.
In the course of troubleshooting it, I came across this thread, and thought I would leave a solution in case others have the problem.