Patching/Upgrading OpenSSL
-
@cmb:
Any plans to get such patches easier in the future? As much as I like to hope, but I do not think this is the last one :(
It depends on the issue. This one's difficult because it requires recompiling a slew of PBIs, which is very time consuming, and building an entire release. If it were as simple as "here's a file, copy this and you're fixed", we would have provided that file 24 hours ago. It's also not something that's exploitable in the common uses of the system and where people are using reasonable security practices. Spend a lot more time looking at your web servers, mail servers, etc. right now, and follow my recommendations in the post above.
Forgive my ignorance, but why could a user not simply grab the new OpenSSL version, from FreeBSD and compile?
Yes he could and did… but he apparently did something really bad according to this thread (still, his firewalls seem to be working fine with this approach, perhaps
because he doesn't use pbi packages on them). -
Packages on pfSense are in pbi-packages since 2.1 which means that each package that uses OpenSSL or other dependencies will have their own copy of the binaries. So if you have stunnel, squid or other packages that also use OpenSSL, the package pbi-package will have to be recompiled.
-
@developers: Thanks for working that fast on this problem.
-
Are there going to be updated 2.2 snapshots released to address this issue?
-
Of course. Obviously it's a lower priority for the dev team.
It's less of an issue because no-body is using 2.2 for anything other than internal experimentation are they? ;)Steve
-
It's less of an issue because no-body is using 2.2 for anything other than internal experimentation are they? ;)
And I thought it's exactly that what gets you the "Hero"-Membership…
-
It's less of an issue because no-body is using 2.2 for anything other than internal experimentation are they? ;)
I use it in production because I like to take life to the extreme.
I'm actually just a simple home user, but this bug is still somewhat concerning to me. I've disabled WAN WebConfigurator access for the time being, just to be safe.
-
Hardcore! :P
Steve
-
@ingenieurmt:
I'm actually just a simple home user, but this bug is still somewhat concerning to me. I've disabled WAN WebConfigurator access for the time being, just to be safe.
Why would you have that enabled in the first place?
-
You should never ever ever ever ever expose the configuration to internet. Use VPN or SSH to access a machine inside your network and access the configuration from within your network.
-
You should never ever ever ever ever expose the configuration to internet. Use VPN or SSH to access a machine inside your network and access the configuration from within your network.
Properly protected web UI (good password, custom port + SSL) is no worse than VPN or SSH.
-
You should never ever ever ever ever expose the configuration to internet. Use VPN or SSH to access a machine inside your network and access the configuration from within your network.
Properly protected web UI (good password, custom port + SSL) is no worse than VPN or SSH.
Except in this case where your SSL could have been spewing confidential data all over… :-)
VPN or SSH is best. Letting anyone even touch your GUI port remotely from an arbitrary IP is a bad thing. As this proves, it's not about a password, it's about exploiting the service itself. Custom ports won't hide you for long.
-
Forgive my ignorance, but why could a user not simply grab the new OpenSSL version, from FreeBSD and compile?
I ran some tests doing just that (build openssl package, then pkg_add the package) and the results were OK but I did not perform extensive testing. It did at least stop the GUI from exposing data via Heartbleed. It may have been OK in general even. I'd say it's sufficient as a stopgap but it's not better than a full firmware update where other programs have also been updated.
Don't forget there is also the ECDSA flaw in OpenSSL that was patched in the base system OpenSSL too.
-
VPN or SSH is best. Letting anyone even touch your GUI port remotely from an arbitrary IP is a bad thing. As this proves, it's not about a password, it's about exploiting the service itself. Custom ports won't hide you for long.
Are you saying VPN or SSH never had any security issues? Don't think so. VPN is also not convenient - does not work from many locations. SSH is better, but theoretically can be exploited as well - with the bug you do not know about (yet).
What is really missing for Web UI is the IP lockout if someone tries to brute force password.
-
What is really missing for Web UI is the IP lockout if someone tries to brute force password.
That actually is NOT missing at all… you are welcome to try and lock yourself out. :P
-
VPN or SSH is best. Letting anyone even touch your GUI port remotely from an arbitrary IP is a bad thing. As this proves, it's not about a password, it's about exploiting the service itself. Custom ports won't hide you for long.
Are you saying VPN or SSH never had any security issues? Don't think so. VPN is also not convenient - does not work from many locations. SSH is better, but theoretically can be exploited as well - with the bug you do not know about (yet).
Not had any? No, but generally a better track record. If you protect access to the GUI properly behind a VPN, then even if the encryption of the VPN has failed (see PPTP) it is still useful for access control as an additional layer of protection/authentication.
OpenVPN works from anywhere that you can make an HTTPS connection from if you run it the right way(s). And the fact that it isn't convenient is a plus, not a minus.
What is really missing for Web UI is the IP lockout if someone tries to brute force password.
That's already present. But you don't want the world to be able to hit your GUI port directly anyhow, so it's more useful against local attackers/infected local hosts, but it is there.
-
For those complaining about lack of updates, you clearly are not working in the I.T Field.
I hate when something goes down, you get 100 people contacting you "crap is down..when will it be backup" and then people who linger over your shoulder like that is going to help.
It will be fixed when they get it fixed so don't get angry if all you get is 1 daily update, think of the time they are not wasting answering the forums and instead working on the problem.
as said, if you have your GUI open to the internet, lock it down, IP restrictions, port changes, what ever!
-
Not had any? No, but generally a better track record. If you protect access to the GUI properly behind a VPN, then even if the encryption of the VPN has failed (see PPTP) it is still useful for access control as an additional layer of protection/authentication.
OpenVPN works from anywhere that you can make an HTTPS connection from if you run it the right way(s). And the fact that it isn't convenient is a plus, not a minus.
Well, openssl had excellent track record up to about 2 days ago as well.
That's already present. But you don't want the world to be able to hit your GUI port directly anyhow, so it's more useful against local attackers/infected local hosts, but it is there.
Did not see any setting to limit number of bad login attempts, did not see it clearly documented…
If it is there - good.As far as WebUI - I suggest everyone makes their own risk analysis. Information is out there to make a proper judgement and having WebUI open is not that bad as you try to describe (when TLS is not broken, of course and IP restrictions are in place).
-
I have always disabled the WebGUI to the outside world. I have on occasion specified one or 2 IP's that can access it if I knew I was going to be working on it from that location for a while. I.E. When working the firewall located at my house while at work I would allow just that one IP. Otherwise I use OpenVPN to access it.
Isn't this firewall security 101?
-
I have always disabled the WebGUI to the outside world. I have on occasion specified one or 2 IP's that can access it if I knew I was going to be working on it from that location for a while. I.E. When working the firewall located at my house while at work I would allow just that one IP. Otherwise I use OpenVPN to access it.
Isn't this firewall security 101?
Yep. Looks like you get an A.
