New SymLink Warning
In security advisor i am now getting this warning.
"cPanel no longer supports the hardened kernel. We recommend that you use KernelCare's free symlink protection. In order to enable KernelCare, you must replace the hardened kernel with a standard kernel."
The underlined portion is confusing. I though KernelCare was fee based, NOT free. Can we ustilize the symlink protection of KernerlCare w/o paying for the entire Kernel Care?
-
OK I uninstalled the hardened kernel and clicked the link to add the free KernelCare symlink. However now I am getting regular warnings form what looks to be a cron job for KernelCare. Delivered-To: xxxxx@xxxxxxx.xxx Envelope-to: root@xxxxxxxxxx.xxx From: root@xxxxxxxxxx.xxx (Cron Daemon) To: root@xxxxxxxxxx.xxx Subject: Cron /usr/bin/kcarectl --auto-update --gradual-rollout=auto Auto-Submitted: auto-generated Date: Sun, 13 May 2018 00:07:01 -0400 Unknown Kernel (CentOS 2.6.32-696.28.1.el6.x86_64 Is this something that needs to be addressed? I did not KNOWINGLY add in a full license to KernelCare ergo is it safe to just manually delete the job form the crontab? 0 -
No, this is to be expected. Kernelcare isn't exactly known for publishing kernel updates quickly, at least with my experience with stock CentOS kernels. Perhaps they pay more attention to their own CloudLinux kernels. The 2.6.32-696.28.1 kernel is the latest CentOS 6 kernel. It was released on May 9th. Kernelcare hasn't yet released any patches for 2.6.32-696.28.1 and it may be a while before they do. You will continue to receive these emails (every 4 hours? - /etc/cron.d/kcare-cron) until Kernelcare releases a patch for 2.6.32-696.28.1. It also means that you aren't technically protected with their symlink protection. 0 -
Well that is both good and bad news. So you are telling me that even by proceeding to remove the hardened kernel and install the supposed free symlink protection of KernelCare as directed by security advisor, I no longer have any symlink protection on my server? Why in the world would I be advised to do so if this is the case? 0 -
Well, you will when Kernelcare gets around to patching the latest CentOS 6 kernel, but don't hold your breathe on when that will happen. On the surface, the Kernelcare patch is much better than a cPanel hardened kernel. Because a hardened cPanel kernel creates yet another kernel that has to be maintained. But yea, I can butt heads with Kernelcare and their timeliness of their releases. I'm certainly not going to deride their product, but sometimes it seems like they have one person stuck in a dungeon somewhere that has to release Kernelcare patches for all of the kernels they "support". Makes me wonder if they have enough people hired or enough people there to do the work that they need to do. Or perhaps there's room on the market for a Kernelcare competitor? Since the demise of Ksplice, there's really no other rebootless kernel patching system. All the people that depend on Kernelcare for true rebootless kernels, they're still waiting for a 2.6.32-696.28.1 Kernelcare patch too. Depending on how you feel about security and keeping things up to date, this 4 day (so far) lag time between kernel release and Kernelcare patch may be an issue for you. 0 -
Security is EXTREMELY important to me and all of my servers. I am pretty upset that cpanel has used what I see as (at the very least) slightly underhanded tactics in shoving KernelCare at all of us. 1) cPanel historically recommended the hardened kernel for symlink protection. 1) A number of months ago cPanel tacked on a warning in Security Advisor that KernelCare is "highly recommended". 2) cPanel then depricates the hardened kernel and "highly recommends" that we use the free KernelCare symlink protection. cPanel failed to mention that free KernelCare symlink protection is not up to date and going through the process that they "highly recommended" leave my serves vulnerable. I would think that the cPanal team is a bit more professional than to "highly recommend" server owners take actions that put their servers at risk. If they have put us at risk in this area that we know about, how many things are going on that we do not know about? A comment from someone at cPanel would be appreciated here and "highly recommended". 0 -
Hello, I think there may be some confusion here. There are separate services/errors being references which are unrelated to each other: You noted the following error being received: cPanel no longer supports the hardened kernel. We recommend that you use KernelCare's free symlink protection. In order to enable KernelCare, you must replace the hardened kernel with a standard kernel."
This indicates you were using the cPanel hardened kernel which was deprecated as of cPanel v70. Documentation on this can be found here Symlink Race Condition Protection - EasyApache 4 - cPanel Documentation I do see that you rectified this per your next post:OK I uninstalled the hardened kernel and clicked the link to add the free KernelCare symlink. However now I am getting regular warnings form what looks to be a cron job for KernelCare.
In order to test this I created a test VM running CentOS 6 and my test environment is running the following Kernel Version:uname -r 2.6.32-696.28.1.el6.x86_64
I have the kernelcare symlink protection patch enabled - [QUOTE]Add KernelCare's Free Symlink Protection.This free patch set protects your system from symlink attacks. Add KernelCare's Free Patch Set. documentation to find a solution that is suited to your needs.
This is a replacement for the bluehost symlink protection and as stated NOT the KernelCare product and service - it is free of charge 52019 I am not getting those errors when the cron runs, though I may be a day late as it appears this was updated on 2018-05-13 [QUOTE]- kernel-2.6.32-696.28.1.el6(Last Updated: 2018-05-13 11:16:18)CentOS 6 (x86_64)
-
KernelCare Directory
There is a separate "yellow" warning that is for the actual kernelcare service which is the paid service but it is NOT the symlink protection which is separate: [QUOTE]Upgrade to KernelCare.KernelCare provides an easy and effortless way to ensure that your operating system uses the most up-to-date kernel without the need to reboot your server.
To address your concerns in your last response:Security is EXTREMELY important to me and all of my servers. I am pretty upset that cpanel has used what I see as (at the very least) slightly underhanded tactics in shoving KernelCare at all of us. 1) cPanel historically recommended the hardened kernel for symlink protection. 1) A number of months ago cPanel tacked on a warning in Security Advisor that KernelCare is "highly recommended". 2) cPanel then depricates the hardened kernel and "highly recommends" that we use the free KernelCare symlink protection.
We did deprecate the cPanel hardened kernel in its place we also do highly recommend the free KernelCare symlink protection patch in favor of the item we deprecated, to ensure that you have a working replacement for the item we chose to discontinue. Products like KernelCare are highly recommended for rebootless updates and while we do recommend them, you are in no way required to use the suggested products - they're suggestions.It also means that you aren't technically protected with their symlink protection.
cPanel failed to mention that free KernelCare symlink protection is not up to date and going through the process that they "highly recommended" leave my serves vulnerable.
In regards to this, I've confirmed with CloudLinux directly and their response was [QUOTE] KC patches (including symlink protection) are disabled while the running kernel is not supported by KC
With that in mind, if you're going to use the suggested SymLink protection provided by KCare you may want to wait until they patch to the latest kernel to update yours. I do agree that this should be documented though and I've opened an internal case to address this portion of it CPANEL-20443. I'll update here when I have more information on the status of the case. Thank you,
0 -
Lauren thank you for you extremly well thought out and informative response. At this point let me give you my situation and concerns to see if I need to address anything. I did perform the task of removing the hardened kernel as described earlier and I did click the link to use the free KC SymLink protection. I am no longer getting any email error referencing KC from cron, however when I look at the crontab I see nothing that looks like KC calls. Also I no longer see a KC and/or SymLink warning when I run Security Advisor. 0 6 * * * /usr/local/cpanel/scripts/exim_tidydb > /dev/null 2>&1 30 5 * * * /usr/local/cpanel/scripts/optimize_eximstats > /dev/null 2>&1 35 * * * * /usr/bin/test -x /usr/local/cpanel/bin/tail-check && /usr/local/cpanel/bin/tail-check 45 */4 * * * /usr/bin/test -x /usr/local/cpanel/scripts/update_mailman_cache && /usr/local/cpanel/scripts/update_mailman_cache 30 */4 * * * /usr/bin/test -x /usr/local/cpanel/scripts/update_db_cache && /usr/local/cpanel/scripts/update_db_cache 30 */2 * * * /usr/local/cpanel/bin/mysqluserstore >/dev/null 2>&1 15 */2 * * * /usr/local/cpanel/bin/dbindex >/dev/null 2>&1 15 */6 * * * /usr/local/cpanel/scripts/autorepair recoverymgmt >/dev/null 2>&1 */5 * * * * /usr/local/cpanel/scripts/dcpumon-wrapper >/dev/null 2>&1 48 5 * * * /usr/local/cpanel/whostmgr/docroot/cgi/cpaddons_report.pl --notify 10,25,40,55 * * * * /usr/local/cpanel/whostmgr/bin/dnsqueue > /dev/null 2>&1 57 22 * * * /usr/local/cpanel/3rdparty/bin/freshclam --quiet --no-warnings 8 0 * * * cd /var/netenberg/fantastico_f3/sources && /usr/local/cpanel/3rdparty/bin/php index.php crontab 0 4 * * * /etc/chkrootkit-0.50/chkrootkit 0 0 * * * /usr/local/cpanel/scripts/upcp --cron @reboot /usr/local/cpanel/bin/onboot_handler 0 2 * * * /usr/local/cpanel/bin/backup 0 1 * * * /usr/local/cpanel/scripts/cpbackup 5,20,35,50 * * * * /usr/local/cpanel/scripts/eximstats_spam_check 2>&1 0 */2 * * * /usr/local/cpanel/scripts/shrink_modsec_ip_database -x 2>&1 09,39 * * * * /usr/local/cpanel/scripts/clean_user_php_sessions > /dev/null 2>&1 1) How do I determine if the KC SymLink protection is in place and functioning as desired? 2) Going forward how will I know when KC SymLink is to the latest Kernel so that I can safely upgarde and/or is that even an issue? 0 -
Hi @PCZero however when I look at the crontab I see nothing that looks like KC calls
The cron should be at /etc/cron.d/kcare-croncat kcare-cron 24 */4 * * * root /usr/bin/kcarectl --auto-update --gradual-rollout=auto
Also I no longer see a KC and/or SymLink warning when I run Security Advisor.
That's because KCare patched to the latest kernel version just yesterday. [QUOTE]- kernel-2.6.32-696.28.1.el6(Last Updated: 2018-05-13 11:16:18)CentOS 6 (x86_64)
- KernelCare Directory when a new CentOS kernel drops. You'd probably need to disable automatic kernel updates though and do this manually each time once ready. I do sincerely hope that alleviates some of your concerns and I hope that the outcome of the case is favorable to everyone. I'll let you all know though as soon as I have any updates on that. Thanks!
0 -
Until the next major kernel exploit comes out and it takes Kernelcare a week or so to release a Kernelcare patch for the updated kernel. Then you are stuck with the "Do I reboot into an updated kernel that resolves this kernel exploit sans the symlink protection OR do I keep my kernel held back, vulnerable to the exploit, but safe from symlink attacks?" IMHO, the issue is more with Kernelcare taking their time to patch current kernels. Perhaps it's not a priority for them. Perhaps the market needs a Kernelcare competitor. For what it's worth, I'm really more of the thinking that this whole symlink protection mostly worthless. If you follow solid and appropriate file system permissions, you should not be affected by symlink attacks. But I do use the Kernelcare symlink protection (never a bad idea to be overly secure), but if it's not in place, the file system permission settings should protect against any damage. 0 -
Thanks again Lauren. I ran kcarectl --info and it returned the patch is applied message so all is well. So would the prescribed plan be... 1) Turn off automatic kernel updates. 2) Watch for kernel updates to be available (via Security Advisor or some other method) and when an update is available review the KC directory to verify that a KC patch os is available. 3) Once #2 has been verified then manually update the kernel and either wait for the next cron job to process or manually run /usr/bin/kcarectl --auto-update --gradual-rollout=auto Or am I making things too complicated for my own good? :) 0 -
Keep in mind, you have to reboot the server to boot into the new kernel. So you can install the new kernel, just don't reboot into the new kernel until a kernelcare patch is available for that new kernel. 0 -
If you follow solid and appropriate file system permissions, you should not be affected by symlink attacks. But I do use the Kernelcare symlink protection (never a bad idea to be overly secure), but if it's not in place, the file system permission settings should protect against any damage.
That's some sound advice right there.Perhaps the market needs a Kernelcare competitor.
There are some others like ksplice and kpatch off the top of my head but I don't know their turnaround time for new patches.So would the prescribed plan be... 1) Turn off automatic kernel updates. 2) Watch for kernel updates to be available (via Security Advisor or some other method) and when an update is available review the KC directory to verify that a KC patch os is available. 3) Once #2 has been verified then manually update the kernel and either wait for the next cron job to process or manually run /usr/bin/kcarectl --auto-update --gradual-rollout=auto
Yea that sounds about right, but @sparek-3 has a great point - you can install the new kernel just don't reboot into it until the kernel is supported by KCare:Keep in mind, you have to reboot the server to boot into the new kernel. So you can install the new kernel, just don't reboot into the new kernel until a kernelcare patch is available for that new kernel.
0 -
I got a new warnign /erro this am after the midnight update. The system cannot check the kernel status: Error querying for KernelCare license. Cpanel::Exception::HTTP::Network/(XID 8qz6tm) The system failed to send an HTTP "GET" request to "https://verify.cpanel.net/ipaddrs.cgi?ip=184.172.200.131" because of an error: SSL connection failed for verify.cpanel.net: SSL wants a read first at /usr/local/cpanel/Cpanel/Exception/CORE.pm line 336. Cpanel::Exception::create("HTTP::Network", HASH(0x2a47fd0)) called at /usr/local/cpanel/Cpanel/Exception.pm line 61 Cpanel::Exception::__ANON__(__CPANEL_HIDDEN__, HASH(0x2a47fd0)) called at /usr/local/cpanel/Cpanel/HTTP/Client.pm line 102 Cpanel::HTTP::Client::request(Cpanel::HTTP::Client=HASH(0x266cb88), "GET", "https://verify.cpanel.net/ipaddrs.cgi?ip=184.172.200.131", HASH(0x2a873d0)) called at (eval 21) line 6 HTTP::Tiny::get(Cpanel::HTTP::Client=HASH(0x266cb88), "https://verify.cpanel.net/ipaddrs.cgi?ip=184.172.200.131") called at /usr/local/cpanel/Cpanel/KernelCare/Availability.pm line 47 Cpanel::KernelCare::Availability::system_license_from_cpanel() called at /usr/local/cpanel/Cpanel/KernelCare.pm line 57 Cpanel::KernelCare::__ANON__() called at /usr/local/cpanel/3rdparty/perl/526/lib64/perl5/cpanel_lib/Try/Tiny.pm line 97 eval {...} called at /usr/local/cpanel/3rdparty/perl/526/lib64/perl5/cpanel_lib/Try/Tiny.pm line 90 Try::Tiny::try(CODE(0x1cd3b08), Try::Tiny::Catch=REF(0x2a877c0)) called at /usr/local/cpanel/Cpanel/KernelCare.pm line 57 Cpanel::KernelCare::get_kernelcare_state() called at /usr/local/cpanel/Cpanel/KernelCare.pm line 46 Cpanel::KernelCare::kernelcare_responsible_for_running_kernel_updates() called at /usr/local/cpanel/Cpanel/Kernel/Status.pm line 88 Cpanel::Kernel::Status::kernel_status("updates", 1) called at /usr/local/cpanel/Cpanel/Security/Advisor/Assessors/Kernel.pm line 219 eval {...} called at /usr/local/cpanel/Cpanel/Security/Advisor/Assessors/Kernel.pm line 219 Cpanel::Security::Advisor::Assessors::Kernel::_check_for_kernel_version(Cpanel::Security::Advisor::Assessors::Kernel=HASH(0x1d12448)) called at /usr/local/cpanel/Cpanel/Security/Advisor/Assessors/Kernel.pm line 72 Cpanel::Security::Advisor::Assessors::Kernel::generate_advice(Cpanel::Security::Advisor::Assessors::Kernel=HASH(0x1d12448)) called at /usr/local/cpanel/Cpanel/Security/Advisor.pm line 211 eval {...} called at /usr/local/cpanel/Cpanel/Security/Advisor.pm line 211 Cpanel::Security::Advisor::generate_advice(Cpanel::Security::Advisor=HASH(0xebc898)) called at /usr/local/cpanel/scripts/check_security_advice_changes line 58 scripts::check_security_advice_changes::__ANON__() called at /usr/local/cpanel/3rdparty/perl/526/lib64/perl5/cpanel_lib/Capture/Tiny.pm line 381 eval {...} called at /usr/local/cpanel/3rdparty/perl/526/lib64/perl5/cpanel_lib/Capture/Tiny.pm line 381 Capture::Tiny::_capture_tee(1, 1, 1, 0, CODE(0x22149c8)) called at /usr/local/cpanel/scripts/check_security_advice_changes line 60 scripts::check_security_advice_changes::script("scripts::check_security_advice_changes", ARRAY(0x9f0d40)) called at /usr/local/cpanel/scripts/check_security_advice_changes line 191
Whiskey Tango Foxtrot?0 -
FYI I logged ibnto WHM and ran Security Advisor as suggested and no errors were retruned. 0 -
Hi @PCZero I think that might be different. Based on this line: The system failed to send an HTTP "GET" request to "https://verify.cpanel.net/ipaddrs.cgi?ip="" because of an error: SSL connection failed for verify.cpanel.net: SSL wants a read first at /usr/local/cpanel/Cpanel/Exception/CORE.pm line 336. Cpanel::Exception::create("HTTP::Network", HASH(0x2a47fd0)) called at /usr/local/cpanel/Cpanel/Exception.pm line 61
To confirm, you're not still getting that error correct? It seems like there was an issue connecting over SSL to cPanel & WHM License Verification | cPanel Inc..0 -
Yes it was a one time error and when I went into WHM and ran Security Advisor it returned no errors. BTW Lauren I want to publicaly commend you on your level of support provided and your dedication to seeing any issue through to completion. Thank you for yoru help in this (even though it has at least slightly migrated into a secondary issue). I have emailed the cPanel team to let them know how godo of a job you have been doing providing assistance. 0 -
@PCZero I'm glad it's not still occurring! Thank you so much for that, it means a lot, they did let me know you did that and you don't know how much I appreciate it! I didn't think I did anything special, just trying to help but I'm so glad I've been able to help you. Thank you 0
Please sign in to leave a comment.
Comments
18 comments