Patching/Upgrading OpenSSL

[jasonlitka]

@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?

[fragged]

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.

[dgcom]

@fragged:

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.

[jimp]

@dgcom:

@fragged:

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.

[jimp]

@jsheed_sa:

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.

[dgcom]

@jimp:

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.

[doktornotor]

@dgcom:

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

[jimp]

@dgcom:

@jimp:

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.

@dgcom:

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.

[SysIT]

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!

[dgcom]

@jimp:

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.

@jimp:

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).

[port9]

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?

[jimp]

@port9:

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.

[A Former User]

2 quick questions.

I'm still on 2.0.3, can I go directly to 2.1.2 once it's out ?
Was 2.0.3 even vulnerable ?

[jimp]

@Satras:

I'm still on 2.0.3, can I go directly to 2.1.2 once it's out ?

Yes.

@Satras:

Was 2.0.3 even vulnerable ?

No. Only if you used the Unbound package.

[ingmthompson]

@dgcom:

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 tend to agree with this. I'm using it in a home environment, not a corporate production network. Sometimes things break when I'm not there, and given that I'm the only person who knows anything about IT in the house it falls to me to fix it (often quickly due to some perceived life-or-death situation that really isn't as important as it's made out to be, ah the joys of family).

Risk assessment = minimal, as far as I'm concerned. There are plenty more interesting networks out there to play around in than mine.

[stephenw10]

It's not really a question of your network being uninteresting. It's far more likely to be some bot that grabs your login details and turns your router into a spam relay. The bot doesn't care how interesting your network is.
Like any risk assessment you have to consider both the chances of something happening and the consequences. If the potential consequence is that your firewall is compromised leading to your internal machines being compromised requiring complete re-install of everything - is that a risk worth taking?

Steve

[dgcom]

@stephenw10:

It's not really a question of your network being uninteresting. It's far more likely to be some bot that grabs your login details and turns your router into a spam relay.

And you would be amazed how often this happens via SSH with weak root password!

[keychain]

Weak Passwords and root? Authorized_keys only, AllowUsers, Port only open to specific IP or Range..  Those who use root-access with weak passwords won't start updating now, so this will always be a lost cause.

[dgcom]

@keychain:

Weak Passwords and root? Authorized_keys only, AllowUsers, Port only open to specific IP or Range..  Those who use root-access with weak passwords won't start updating now, so this will always be a lost cause.

And that is my point - it is not the protocol, which is "bad", it is how it is being used.

[joako]

@fragged:

Use VPN

OpenVPN is vulnerable too.