Patching/Upgrading OpenSSL
-
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!
-
Have you tested it? Not working for me. Its like snort ignoring custom rules… :(
I compared the rules and they are the same on the blog as in the posted VRT ruleset.
In Snort:WAN Rules:custom.rules
Did you upgrade to the latest snort version? I am still on the previous release. (Not sure if that matters)
As a test, I copied two of the rules and changes the rule sid (so I wouldn't have duplicates) and they saved no problem.
EDIT: Maybe now is a good idea to pay the $29.00 for a Snort VRT membership?
-
Tested the posted rules, and ran http://filippo.io/Heartbleed/ to test. Alert (and ip block) appeared referencing the rule…
-
(Yes, running latest snort package).
For me, custom rules did not work, but they are already included for free in emerging-current_events.rules and those are catching it.
-
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!
PSK is not vulnerable. This was specific to SSL/TLS.
-
Also some snort rules http://blog.fox-it.com/2014/04/08/openssl-heartbleed-bug-live-blog/, slightly different from the the snort team.
-
Did some more testing, but could not make rules from here to work in custom rules.
However, updated emerging-current_events.rules works pretty well.Anyone, who has snort installed should get free ETOpen rules updated and check emerging-current_events.rules on WAN interface.
-
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.
That's my plan- wait. It appears that at least the FBSD p1 patch to 10.0 stuffed things up a bit. They updated the shared libs, but not the headers. Now anyone compiling ports has issues…...
Since freebsd-update can potentially break things, I for one would argue you need to take it out of the distro. You don't want a cowboy (like myself) going crazy updating and breaking things.
I'd love to see it in the distro, but I realize that such a mechanism creates a major can of worms in trying to maintain configuration management.
-
That's my plan- wait. It appears that at least the FBSD p1 patch to 10.0 stuffed things up a bit. They updated the shared libs, but not the headers. Now anyone compiling ports has issues…...
Hm, I have yesterday installed p1 on FreeBSD 10.0-RELEASE. And today I have upgraded e.g. port www/apache22. I did not have any problems when building and installing. And Apache is still working. Do you have any reference for your "Now anyone compiling ports has issues…..". Or have I just been favoured by fortune :)
Regards,
Peter
