-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unexpected skipped audits after hardening apache #12
Comments
hi @ChefRycar which version of inspec do you use? maybe you have an old version, which does not include the fix of arlimus/sslshake#7 (underlying library for the inspec ssl resource) |
Aha, that is a possibility. Do we know what version of inspec that fix was implemented in? |
@ChefRycar Yes The updated sslshake library, which caused the problem was updated in inspec version >= 1.21.0 So with inspec 1.21.0 and 1.22.0 , this problem should go away background: Due to a bug in the underlying sslshake library arlimus/sslshake#6, arlimus/sslshake#7 - the ssl resource did not connect to servers configured with robust security (like enforced in this ssl-baseline) - resulting in skipping tests. |
Thanks, @supergicko! That got me further along. Interestingly enough, I'm finding the opposite to be true -- when I'm using an earlier version of inspec, it detects the ports as expected, but with 1.22, it's skipping the ports. Here's a couple of tests I did in kitchen with differing inspec versions: Inspec 1.11
Inspec 1.22
|
@ChefRycar SSLCipherSuite EECDH+AESGCM:EDH+AESGCM right? |
Yup! |
Revisiting this, as I think this may be an issue upstream in inspec. Previously had pinned my environment to 1.19.x, which solved things in the short-term, but in updating my automate server to use the compliance beta, I needed to upgrade inspec to 1.27.x to get my results showing properly, and this issue re-surfaced. As far as I can tell, the ssl resource isn't able to properly inspect SSL ports. To try and simply things, I pared down my usecase to a protocols-only set of resources, and scanned port 443 directly rather than dynamically portfinding. I found that inspec didn't seem to be able to correctly grab any of the protocol/cipher settings after updating my config. Anything I'm expecting to not be enabled passes, and anything I expect to be enabled fails. Example: As in the earlier case, I created a simplified ssl config in apache (e.g. I skipped the cipher settings, and focused on protocols alone), that looked like this:
Then, tried running a compliance profile that contained the following control:
The control failed when I ran. If, however, I changed resources to invoke openssl directly on the node, it provided the expected passing result:
Suspect this is related to when ssl-handshake was updated around 1.20, but am unfamiliar with how things are controled under the hood, and haven't investigated further just yet. |
@arlimus @supergicko any ideas? |
@chris-rock, @ChefRycar i cannot reproduce this with chefdk 1.4.3 but this is a fresh install and i did not switch back and fort inspec. @chris-rock is it possible to install a inspec version (for example the newest one) on top of chefdk? And if yes, does it use the sslshake IN inspec definition, or the sslshake of the chefdk (which could be an older one)? because to me it seems like an old version of sslshake is used to determine the handshakes, which leads to confusing results.. This issue needs some tests for different http(s) servers, maybe with docker |
Background:
I have been using the ssl-baseline profile to demonstrate a simple failure/remediation story using this cookbook to configure apache for ssl: https://github.com/chef-cft/bjc/tree/master/cookbooks/bjc-ecommerce
Recent updates look to produce an edge case where the profile produces an unexpected edge case, where the profile passes, but because it doesn't think any ports are listening on SSL, and skips all of the functional tests (e.g. there's one passed test for inspec version. The rest are skipped). Older versions of the profile do not appear to be affected.
Details & Reproduction Steps:
Initial revisions configured apache with the following settings to remediate detected errors:
Recent updates included a check for CBC ciphers (b5fd0ff), which the above settings do not alleviate. To address, we updated our CipherSuite to look like so:
Initial testing (done 4/17/17 - 4/18/17) seemed to validate that this fixed our remaining audits, and got a clean bill of health across the board. However, on Friday 4/21, we started seeing the above described behavior. Before enforcing the cipher suite, our tests fail as expected. After making the above change, tests now no longer detect that SSL is running, and all tests are skipped. Reverting back to an earlier version (on our case, from a 1.1.1 snapshot on our compliance server) produced the expected passing tests.
The text was updated successfully, but these errors were encountered: