Patching/Upgrading OpenSSL
-
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
-
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!
-
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.
-
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.
-
-
-
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.
I grant you, this is possible. That said, there have to be hundreds of thousands of other home networks just on my ISP alone, notwithstanding the dozen or so other ISPs in this country. Any one of them would make a perfectly tempting target for such a bot (even more so given the fact that most home routers are virtually never updated). I'd also like to take this opportunity to point out that there's only so much that one can do with 2Mbps upstream.
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?
For that, someone would have to not only get through the firewall but through the internal machines too, which are not exactly unprotected themselves.
All said, you've made your case, and while I stand by my original point that my network is simply not interesting enough to warrant targeting, I'm going to take a look at the feasibility of setting up a basic VPN solution in pfSense to handle remote support requirements.
-
@ingenieurmt:
my network is simply not interesting enough to warrant targeting,
No Offend, but this Attitude makes you a prime Target. People believeing they are save cause they are not interresting enough.
-
Everyone is interesting to an indiscriminate bot scanning for hosts to exploit.
-
Use VPN
OpenVPN is vulnerable too.
Only if used in SSL/TLS mode without a TLS authentication key. The way the wizard sets it up for a simple RA VPN for management use it would not be vulnerable.
Yeah, that's good news. When I have once manually set up my OpenVPN server without the wizard I did not exactly understand what this setting would achieve but considered it safe. I have just found your statement confirmed in the OpenVPN community:
https://community.openvpn.net/openvpn/wiki/heartbleed
Peter
-
So there are two versions of openssl in pfsense:
/usr/bin/openssl - OpenSSL 0.9.8y 5 Feb 2013 which is the base system openssl
and
/usr/local/bin/openssl - OpenSSL 1.0.1e 11 Feb 2013 which presumably was installed via the ports system to get a more recent version because of dependencies
A simple freebsd-update fetch; freebsd-update install will take care of the first version of openssl.
The second version (/usr/local/bin/openssl) will need to be compiled on a 8.3-p11 system via ports to get 1.0.1g. openvpn 2.3.2 needs to be rebuilt from ports along with lighttpd 1.4.32. Move all of this over then while in single user mode.
Not terribly difficult, but time consuming - but doable if you need a fix ASAP.
NOTE: There may be other dependencies on openssl that I've missed. lighttpd and openvpn are the obvious ones.
-
freebsd-update won't work on pfSense, and would break things if it did. At least for now. Might change in the future.
OpenVPN and lighttpd don't need rebuilt, they are not statically linked to OpenSSL.
Just wait for a firmware update, it'll be coming soon.
-
@Satras:
@ingenieurmt:
my network is simply not interesting enough to warrant targeting,
No Offend, but this Attitude makes you a prime Target. People believeing they are save cause they are not interresting enough.
I'd prefer to keep my own counsel on what my attitude may or may not constitute, if you don't mind.
-
hm.. should I stay up for an hour more or two?
-
-
Snort has released some rules to help detect this vulnerability. If they work?
Just an FYI
http://vrt-blog.snort.org/2014/04/heartbleed-memory-disclosure-upgrade.html
-
Requires a Snort subscription of course to get the rule now, not after 30 days when it hits the free rules set.
Reading the article, it seems like the actual rules are released in the post also :)
-
The rules are listed on their website.
Copy and paste them into the local rules… ;)
I'm sure that's why they posted them like that. I have a paid subscription so its already in my ruleset.
-
Have you tested it? Not working for me. Its like snort ignoring custom rules… :(
-
Is the server side (listener side) of site-to-site OpenVPN configured with a pre-shared key vulnerable to the heartbleed exploit? I don't know if the PSK is functionally similar to a TLS authentication key.
The good news is that most (not all) of our server listener ports have a WAN rule restricting connections to those ports to static IPv4 addresses. The bad news is the 'not all' part.
Questions:
1. Are IP-agnostic site-to-site OpenVPN listeners (configured with PSK) vulnerable to heartbleed?
2. If the answer to #1 is "yes, vulnerable", and if the aforementioned unrestricted listeners are configured to be limited to ONE connection, and if the connection has been nailed up the entire time, would that prevent a drive-by from exploiting the vulnerability?
3. If the answer to #1 is "yes, vulnerable" and the answer to #2 is 'No, vulnerable', is the post-update remedy to simply re-key the vulnerable server and client? In other words would the SINGLE vulnerable server listener expose ALL of the PSK's bound to ALL of the server instances, or just the one? (simplifying re-keying)Thanks in advance for the rapid response to the vulnerability!
