Installed latest snap, now can't login to GUI
-
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!
-
I wasted a lot of precious time trying to figure out what the hell all of a sudden happened, and why I couldn't access the firewall.Ā If this is going to be left on by default, then the notice must give the administrator ways to get around it and how to manage it in the future.Ā I have absolutely no use for this feature at all, as I don't allow remote access to the UI.
-
It has nothing to do with you enabling remote access - DNS rebinding attacks are a way that someone remotely could get access to your router even when you have explicitly denied it. That's why it's a security risk.
The error message could probably be clearer, though. But it's still a beta so there's plenty of time to get a simple fix like that in.
-
Would there be anything wrong with having the message suggest to try accessing it by IP address instead and where to go to configure an exception for the host name?
-
Another way to protect the system from DNS rebinding attacks is to filter out all private address space addresses from the DNS replies that come from upstream forwarders. It's not going to work in every case though because not everyone uses the DNS forwarder that is included in pfSense.
Edit: 2.0 BETA already seems to do this with dnsmasq āstop-dns-rebind option, the other protection methods seem a bit excessive in that caseā¦
-
@kpa:
Edit: 2.0 BETA already seems to do this with dnsmasq āstop-dns-rebind option, the other protection methods seem a bit excessive in that caseā¦
Yes that's already done, no it's not excessive - that only helps if you're using the DNS forwarder, lots of people don't.
