Fixing PfBlocker-NG weak cipher and DH Strength Vulnerabilities
-
---WARNING---
Restricting ciphers available can have unintended consequences. If you have older web browsers in your environment, this will cause them to be unable to load the block page. DNSBL will still work, but users may be left unaware that a page is being blocked. I have verified these changes as compatible with Firefox versions 60 and above.
---WARNING---Vulnerability scanning the firewall yielded the following results:
A quick review of the results:
Weak Ciphers: This would indicate that a client could potentially negotiate to use weak ciphers when connecting. The risk here is relative, as it depends on what kind of information is transmitted to pfsense's DNSBL. Seeing as whats being transmitted is blocked traffic, I feel this should be considered a 'low' risk. We'll fix it anyway.Certificate signed using a weak signature algorithm: Again, since this is a cert used for DNSBL, this probably shouldnt be considered a medium. Personally, I'd rate this lower than 'low', at 'annoying'. The biggest impact to me would be browsers being redirected to the DNSBL block page would show a warning. I won't be fixing this in this post.
DH group strength vulnerability: Again, this isn't a production web server, so this isnt a medium risk in reality. I'd rate this as a 'low' for my environment.
TCP timestampts: This one can be a bit controversial. Essentially, you can calculate a system's uptime, which can be used for instance to see if the system has been up for X amount of time. This is used as recon to determine the likelihood of an admin patching their system (think if a major vulnerability was exposed, this would be used to check the likelihood of a fix being applied.) We will never fix this, as fixing this impacts network connections negatively. It's rated at low, and I'd agree with this rating.
On to fixing the ciphers and DH strength..
First, I don't know what software is hosting the webserver, so a quick search in the processes:
ps ax | grep http 74281 - S 0:00.09 /usr/local/sbin/lighttpd_pfb -f /var/unbound/pfb_dnsbl_lighty.confWe've found the DNSBL webserver, and conveniently, its config file.
So now we edit the config and make the following changes:
Change this:$HTTP["remoteip"] =~ ".*" { $SERVER["socket"] == "0.0.0.0:8443" { ssl.engine = "enable" ssl.pemfile = "/var/unbound/dnsbl_cert.pem" ssl.dh-file = "/etc/dh-parameters.4096" ssl.cipher-list = "EECDH+AESGCM:EDH+AESGCM:AES128+EECDH:AES128+EDH" ssl.ec-curve = "secp384r1" } $SERVER["socket"] == "10.254.254.254:443" { ssl.engine = "enable" ssl.pemfile = "/var/unbound/dnsbl_cert.pem" ssl.dh-file = "/etc/dh-parameters.4096" ssl.cipher-list = "EECDH+AESGCM:EDH+AESGCM:AES128+EECDH:AES128+EDH" ssl.ec-curve = "secp384r1"to this:
$HTTP["remoteip"] =~ ".*" { $SERVER["socket"] == "0.0.0.0:8443" { ssl.engine = "enable" ssl.pemfile = "/var/unbound/dnsbl_cert.pem" ssl.dh-file = "/etc/dh-parameters.4096" ssl.honor-cipher-order = "enable" ssl.use-sslv2 = "disable" ssl.use-sslv3 = "disable" ssl.openssl.ssl-conf-cmd = ("Protocol" => "-TLSv1.1, -TLSv1, -SSLv3") ssl.cipher-list = "EECDH+AESGCM:EDH+AESGCM:AES128+EECDH:AES128+EDH" ssl.ec-curve = "secp384r1" } $SERVER["socket"] == "10.254.254.254:443" { ssl.engine = "enable" ssl.pemfile = "/var/unbound/dnsbl_cert.pem" ssl.dh-file = "/etc/dh-parameters.4096" ssl.honor-cipher-order = "enable" ssl.use-sslv2 = "disable" ssl.use-sslv3 = "disable" ssl.openssl.ssl-conf-cmd = ("Protocol" => "-TLSv1.1, -TLSv1, -SSLv3") ssl.cipher-list = "EECDH+AESGCM:EDH+AESGCM:AES128+EECDH:AES128+EDH" ssl.ec-curve = "secp384r1"Now we rescan and get the following results:
Enjoy
-
ssl.use-sslv2 = "disable" - (No longer needed. As of 1.4.21 this is disabled by default.)
Try with the following as it restricts it to TLS 1.1 and 1.2 only.
ssl.use-sslv3 = "disable" ssl.honor-cipher-order = "enable" ssl.openssl.ssl-conf-cmd = ("Protocol" => "-ALL, TLSv1.1, TLSv1.2")Update:
Also probably don't need to add "ssl.use-sslv3" .... but haven't tested that...Can test with:
openssl s_client -connect :8443 -ssl3
-
@BBcan177 said in Fixing PfBlocker-NG weak cipher and DH Strength Vulnerabilities:
ssl.use-sslv2 = "disable" - (No longer needed. As of 1.4.21 this is disabled by default.)
Try with the following as it restricts it to TLS 1.1 and 1.2 only.
ssl.use-sslv3 = "disable" ssl.honor-cipher-order = "enable" ssl.openssl.ssl-conf-cmd = ("Protocol" => "-ALL, TLSv1.1, TLSv1.2")Update:
Also probably don't need to add "ssl.use-sslv3" .... but haven't tested that...Can test with:
openssl s_client -connect :8443 -ssl3I put the ssl.use statements in for a couple of reasons:
1-It was part of the recommended configuration, according to: https://cipherli.st
2-ssl.cipher-list was defined, yet it was not being used. Which lead me to believe that it is only used when ssl.honor-cipher-order is enabled.I'm not familiar with lighttpd configuration, as I've never directly configured it, so I'd be unable to confirm the sslv2 statement. I'll leave it in 'just in case', but I'd be inclined to believe you as ssl.openssl.ssl-conf-cmd recommendation from cipherli.st doesnt state -SSLv2.
I've also left tls1.1 disabled in favor of only allowing tls 1.2 to be used. I haven't run into any browser/mobile phone/other device as of yet that was unable to use tls 1.2. YMMV on that.
Still, good info to know and thanks for taking the time to update the tread!
-
@isolatedvirus said in Fixing PfBlocker-NG weak cipher and DH Strength Vulnerabilities:
I have been testing TLSv1.2 only for a couple hours and it does seem to be fine with just that...
The "-ALL" will drop all, and then the "TLSv1.2" adds it.... So I think that's all that is needed...
If you can test without these two lines, and repeat your scan would be appreciated!
ssl.use-sslv2 = "disable" ssl.use-sslv3 = "disable"And only adding these two lines as-is:
ssl.honor-cipher-order = "enable" ssl.openssl.ssl-conf-cmd = ("Protocol" => "-ALL, TLSv1.2")And you can confirm with these commands from a pfSense shell:
openssl s_client -connect 127.0.0.1:8443 -ssl3 openssl s_client -connect 127.0.0.1:8443 -tls1 openssl s_client -connect 127.0.0.1:8443 -tls1_1This should only connect:
openssl s_client -connect 127.0.0.1:8443 -tls1_2
-
@BBcan177 said in Fixing PfBlocker-NG weak cipher and DH Strength Vulnerabilities:
@isolatedvirus said in Fixing PfBlocker-NG weak cipher and DH Strength Vulnerabilities:
If you can test without these two lines, and repeat your scan would be appreciated!ssl.use-sslv2 = "disable" ssl.use-sslv3 = "disable"And only adding these two lines as-is:
ssl.honor-cipher-order = "enable" ssl.openssl.ssl-conf-cmd = ("Protocol" => "-ALL, TLSv1.2")ok, give me a few moments to change the config and restart the pfblockerng service. typically takes a few minutes to complete the scan as well. I'll update with findings.
-
Ran into some issues restarting the DNSBL service. Got it fixed now (unrelated to the changes).
Scan is running now, I'll edit this post with results.
Edit 1:
While waiting on the results I've done a cipher scan to get preliminary results:user@personal:~/git/cipherscan$ ./cipherscan -a 10.254.254.254:8443 ......... prio ciphersuite protocols pfs_keysize 1 ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 ECDH,P-384,384bits 2 ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 ECDH,P-384,384bits 3 DHE-RSA-AES256-GCM-SHA384 TLSv1.2 DH,4096bits 4 DHE-RSA-AES128-GCM-SHA256 TLSv1.2 DH,4096bits 5 ECDHE-RSA-AES128-SHA256 TLSv1.2 ECDH,P-384,384bits 6 ECDHE-RSA-AES128-SHA TLSv1.2 ECDH,P-384,384bits 7 DHE-RSA-AES128-SHA256 TLSv1.2 DH,4096bits 8 DHE-RSA-AES128-SHA TLSv1.2 DH,4096bits Certificate: Not a match, UNTRUSTED, 2048 bit, sha1WithRSAEncryption signature TLS ticket lifetime hint: 300 OCSP stapling: not supported WARNING - None of the CNs match the hostname given Here is the list of common names found in the certificate CN_DNSBLI'd prefer to just link the cert used by DNSBL to the firewall's ACTUAL cert (why identify it otherwise?). I'm using a wildcard from LE, so if youre familiar with how to do this please let me know.
Edit 2: @BBcan177
Scan results:
I pretty much expected these results based on the cipher scan. We're seeing two results because of 443/8443 ports in use by pfblockerng.
-
In response to a chat message, changing the cipher list to:
ssl.cipher-list = "EECDH+AESGCM:EDH+AESGCM"yields the following cipher results:
user@personal:~/git/cipherscan$ ./cipherscan 10.254.254.254:8443 ..... prio ciphersuite protocols pfs_keysize 1 ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 ECDH,P-384,384bits 2 ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 ECDH,P-384,384bits 3 DHE-RSA-AES256-GCM-SHA384 TLSv1.2 DH,4096bits 4 DHE-RSA-AES128-GCM-SHA256 TLSv1.2 DH,4096bitsThis is fine for modern browsers. Confirmed on firefox 60 esr.
-
I am all for locking down and using current ciphers... You do understand such changes could break users using old browsers right ;)
We get users here using still using pfsense 2.1, etc.. If they don't update their firewall software - what are the odds they don't update their browser as well
Just saying ;)
-
@johnpoz said in Fixing PfBlocker-NG weak cipher and DH Strength Vulnerabilities:
I am all for locking down and using current ciphers... You do understand such changes could break users using old browsers right ;)
We get users here using still using pfsense 2.1, etc.. If they don't update their firewall software - what are the odds they don't update their browser as well
Just saying ;)
if theyre not updating i'd suppose theyre also not securing their environment either, or reading this post ;)
that being said though.. this config will cause older browsers that try to navigate to the DNSBL page to fail.
-Will it still block the traffic: Yes
-Will they get the pretty blockpage for HTTP/S blocks? No for https (incompatible cipher, a cert mismatch error is to be expected anyway), yes for http.I have no old OSes in my environment, and no older browsers either. The oldest browser i have access to (as in currently installed) is Firefox ESR: version 60. This config works for this browser, so any firefox version above will be fine as well (i think current is version 65? i could be wrong on that though). I dont use chrome, but I'd ASSUME it doesnt have an issue either.
-
Oh don't get me wrong... All for it!! Lock it down to TLS 1.3 even ;) Just might want a note stating old browsers might fail.. There are many a user that has old devices..
Can see the threads already.. Pfblocker works with X, but not Y... They won't say its just not getting the block page, etc. And for sure will not mention they followed thread X for changing the ciphers either, etc. etc..
It was just like the flood of threads back when they turned off old ciphers in ssh on pfsense... Lots of threads about that - ssh no longer works... Which was not the case, worked just fine its just your ssh client was out of date ;)
There is one thing when users don't keep up to date and their shit breaks, there is another when you don't note the obvious.. So you can rub their noses in like a dog... See if you would of just read the release notes ;)
-
@johnpoz said in Fixing PfBlocker-NG weak cipher and DH Strength Vulnerabilities:
Oh don't get me wrong... All for it!! Lock it down to TLS 1.3 even ;) Just might want a note stating old browsers might fail.. There are many a user that has old devices..
Can see the threads already.. Pfblocker works with X, but not Y... They won't say its just not getting the block page, etc.
Ah i gotcha. I'll update the first post (didnt think about people doing this without knowing the implications). This is why they pay you the big bucks! :)
-
@isolatedvirus said in Fixing PfBlocker-NG weak cipher and DH Strength Vulnerabilities:
people doing this without knowing the implications
Dude - heheheehheh you have no freaking IDEA!!! heheheeheh that is a freaking given!!
