Installed latest snap, now can't login to GUI
-
When I try to log into the web gui after installing today's snapshot, I get this error message:
Potential DNS Rebind attack detected, see http://en.wikipedia.org/wiki/DNS_rebinding
I tried yesterday's snap as well, and got the same thing. The firewall appears functional, I just can't connect to it. Any idea how far back I should go to get this working again?
-
When I try to log into the web gui after installing today's snapshot, I get this error message:
Potential DNS Rebind attack detected, see http://en.wikipedia.org/wiki/DNS_rebinding
I tried yesterday's snap as well, and got the same thing. The firewall appears functional, I just can't connect to it. Any idea how far back I should go to get this working again?
See http://forum.pfsense.org/index.php/topic,26815.0.html
Guessing it's the same issue.
-
It was, thanks! Must have been a new feature added in the past month or so. That setting should probably remain disabled for upgrade installs.
-
That setting should probably remain disabled for upgrade installs.
No, it's a security feature that should be on by default for everyone, and easy to work around should you be in a scenario where it doesn't automatically work (which is the vast majority now that we've fixed the initial fallout), such as accessing it by IP instead of hostname if the hostname is something other than the configured hostname or any locally configured dyndns name. What were you trying to use to access it?
-
@cmb:
No, it's a security feature that should be on by default for everyone, and easy to work around should you be in a scenario where it doesn't automatically work (which is the vast majority now that we've fixed the initial fallout), such as accessing it by IP instead of hostname if the hostname is something other than the configured hostname or any locally configured dyndns name. What were you trying to use to access it?
I have two DNS names resolving to the private and public IP's on this particular firewall. There can be only one hostname, so that is based on the public name, not the private one. It's really just a DNS shortcut for me to use internally. I don't see why using a DNS name that doesn't match one of the listed hostnames would be a security vulnerability???
-
I don't see why using a DNS name that doesn't match one of the listed hostnames would be a security vulnerability???
http://en.wikipedia.org/wiki/DNS_rebinding
-
I read that, but still don't see how it has any relevance to pfSense. I mean, we're talking about guys who are operating their own firewalls and accessing them from their own workstations using DNS records on their own domains, which they control. An external attacker doesn't have access to any of that, and if they do, security is already compromised.
-
I read that, but still don't see how it has any relevance to pfSense. I mean, we're talking about guys who are operating their own firewalls and accessing them from their own workstations using DNS records on their own domains, which they control.
The system has no way of knowing it's your own domain and an authorized hostname if it's not configured as such on the firewall. I guess if it's any hostname within the configured domain it could be bypassed, but not sure how much that would help.
-
Just add all the alternate hostnames you like under System > Advanced, under the Admin Access options.
As cmb said, unless you tell pfSense what your other (valid) hostnames are, it has no way to know what is valid and what is not.
-
Sure, I've done that now, but my point is that I shouldn't have to. I think all this "feature" is going to do is generate lots more questions from end-users. I simply don't see how it increases security in the slightest.
-
Because an attacker can make up whatever DNS entry he wants on a domain he controls, and point it to your router to exploit this hole.
Unless the router knows what hostnames are valid, it can't protect against that.
-
I understand that, but how is that realistically an actual hole in security? No one but an admin knows the login for the firewall, so redirecting random users to it shouldn't pose a problem. If an admin gets redirected to it, then they can log in.
I'm still missing where the "hole" is. Setting up wildcard records just to resolve to a firewall's IP has been a possibility since DNS was invented. Is this only in the DoS category?
-
For the details, you'll have to read up on DNS rebinding, as linked elsewhere in the thread.
If you don't like the checks, you can disable them under the Admin options as well.
-
Its purpose is almost entirely protecting from gross negligence - a system with default or easily guessed password. Or, if some vulnerability is found in our web interface in the future, it protects against that being exploited in such a manner.
-
@cmb:
Its purpose is almost entirely protecting from gross negligence - a system with default or easily guessed password. Or, if some vulnerability is found in our web interface in the future, it protects against that being exploited in such a manner.
Only if accessed via a hostname that isn't on the list. If accessed by IP, which I have a tendency to think is more likely for a brute-force attack, this check does nothing.
Please don't turn into Microsoft in the security department…trying to protect from gross negligence by making everything harder to use. Why not just force the user to change the admin password on first login? Wouldn't that be 100% more effective than protecting from DNS rebinding "attacks"??? You can't, and shouldn't, be trying to force best practice procedures on people assuming that your way is the best in every scenario.
I don't have any problem with this being an option, but enabling it by default only prompts more questions here and elsewhere.
-
But accessing by IP has no relevance to a DNS rebinding attack.
-
Of course…I never indicated that.
My point was that, since the type of attack that you're trying to protect against is not generally going to come at a firewall by name, then this check is probably pointless. It only serves to keep the people who own/administer the device out of it in some situations.
I'm done trying to debate this…
-
My point was that, since the type of attack that you're trying to protect against is not generally going to come at a firewall by name, then this check is probably pointless. It only serves to keep the people who own/administer the device out of it in some situations.
The only attack we're trying to protect against with this is a DNS rebinding attack, and can only come by name. I'm not sure where the confusion is coming from.
Mismatched IPs are also checked, but are only warned against, not blocked entirely.
The "average" user is not going to be accessing their router by a custom hostname anyhow, so they'll not trigger this protection. However, the error message could probably be more verbose with a better description of how to bypass the error if it's a legit hostname.
-
I think the confusion here lies in that the DNS rebind attack does not use your own DNS domain/records but a completely unrelated domain name.
-
I am 100% for enabling this by default, and in fact it has resulted in positive press for pfSense for being responsive to the security issues raised at BlackHat this week. If you look at this tweet: http://twitter.com/sullrich/status/19855137030 and follow the link to the article referenced, the last paragraph says, "'The only router software that I know of that does this now is pfsense,' Heffner said. 'They contacted me when my Black Hat talk abstract went up.'" You can't buy that kind of praise…from the guy who did the BlackHat talk and is doing all the interviews no less!
If adding a little configuration to access the firewall by more than one hostname gets pfSense this kind of security kudos (and, being a firewall, isn't the whole dang point to be as secure as possible?!), I'm all for it. Especially since it's likely 99% of users use the IP of pfSense (especially home users, where this attack is most likely and default passwords are less likely to have been changed) and will never see the warning.
I do agree that perhaps a link could be provided to a more detailed explanation of the problem. However, 2.0 is still a beta, and there's still time to get this in place before the release, even if it were next week (which would be awesome, but I'm not speculating, just wishing :-) I would certainly not find this to be an out of place default switch, especially on a beta-level product, even without documentation. As long as it's well documented when finally released, I agree that leaving it on by default is extremely wise, even when upgrading from 1.2.3. Layered security (defense-in-depth) is good, even if you always change your admin passwords.
Kudos!
