CSF Syslog Security Warning, are there analogous features in cPanel itself?
-
Hello :) You can review the associated configuration files for the service to get a better idea of what exactly it's utilized with: /etc/syslog.conf /etc/rsyslog.conf Thank you. 0 -
An interesting discussion with involved participants can be found at [url=http://www.webhostingtalk.com/showthread.php?t=1344458]Log Spoofing Vulnerabilities - CSF, BFD, Fail2Ban and Many Others... [SEEKING INPUT] - Hosting Security and Technology - Web Hosting Talk The full thread is worth a read, but there is a protection available if you use CloudLinux, albeit with the side effect of preventing cron job logging. Igor's post [url=http://www.webhostingtalk.com/showpost.php?p=8999229&postcount=13]Web Hosting Talk - View Single Post - FEATURED Log Spoofing Vulnerabilities - CSF, BFD, Fail2Ban and Many Others... [SEEKING INPUT] [Quote]For CloudLinux clients utilizing CageFS this can be prevented by limiting access to /dev/log inside CageFS. For that remove file: /etc/rsyslog.d/schroot.conf Or remove this line from that file: $AddUnixListenSocket /usr/share/cagefs-skeleton/dev/log That will prevent end user's access to /dev/log, preventing them from spoofing things like that. 0 -
Big question then ---> If we need to disable brute force detection within CSF, then can cPHulk then "pick up the slack"? In other words, does cPHulk suffer from the same log spoofing vulnerability as apparently CSF does now? 0 -
/subscribing 0 -
Anyone familiar enough with cPHulk to be able to answer this question? TIA. 0 -
[quote="jols, post: 1561951">Big question then ---> If we need to disable brute force detection within CSF, then can cPHulk then "pick up the slack"?
While I wouldn't presume to speak for him, that doesn't necessarily appear to be Chripy's suggestion: [url=http://www.webhostingtalk.com/showpost.php?p=9000085&postcount=25]Web Hosting Talk - View Single Post - FEATURED Log Spoofing Vulnerabilities - CSF, BFD, Fail2Ban and Many Others... [SEEKING INPUT] [Quote]For reasons I mentioned in my post above I'd suggest leaving it on "0" as a reminder to the risks. If you are aware and don't want to be bothered by the warning, set it to "2". If you have a particularly self-destructive and untrustworthy client base set it to "1", but be aware that this could provide a net reduction in protection.
I'd take the "particularly self-destructive and untrustworthy client base" bit to mean that if you know full well you've got a lot of exploitable Joomla 1.x installs outstanding or something of the ilk or you know full well you've got people signing up just to screw with you. That said I guess most hosts are going to have an estimated % of accounts compromised at any one time regardless of their policies, I suppose you have to weigh how you feel about the state of your systems and the protection these feature provide against having to be a bit more careful. Note there is also now a beta option to restrict access to syslog [url=http://www.webhostingtalk.com/showpost.php?p=9001914&postcount=27]Web Hosting Talk - View Single Post - FEATURED Log Spoofing Vulnerabilities - CSF, BFD, Fail2Ban and Many Others... [SEEKING INPUT] [Quote]New BETA option RESTRICT_SYSLOG_GROUP. This has been added for a new RESTRICT_SYSLOG option "3? which restricts write access to the syslog/rsyslog unix socket(s). See csf.conf and the new file /etc/csf/csf.syslogusers for more information0 -
[quote="jols, post: 1561951">Big question then ---> If we need to disable brute force detection within CSF, then can cPHulk then "pick up the slack"? In other words, does cPHulk suffer from the same log spoofing vulnerability as apparently CSF does now?
That's the kind of thing I was hoping the cPanel guys might comment on, I'd imagine giving the pros and cons on this one they're formulating a measured response before posting, it wouldn't overly surprise me to learn the major people involved are chin wagging together in private as well as the public discussions on WHT. The reason you can check for example reported root logins against /var/log/wtmp using last (to be sure they aren't spoofed) is that it is not a syslog log (I believe /var/log/secure is off the top of my head). As far as cphulk goes I'm guessing that it'll suffer at least some of the same problems as CSF...0 -
[quote="ThinIce, post: 1562341">While I wouldn't presume to speak for him, that doesn't necessarily appear to be Chripy's suggestion
You're speaking very well for me :) We're hoping that the new BETA option will suffice, short of Redhat/CentOS releasing a more secure logging daemon for v5/v6 (which isn't likely to happen at all), to help mitigate this issue. Even without the new option, you do indeed have to weigh the likelihood of an attacker wanted to disrupt the server they are on (they don't usually want to do this) compared to exploiting its resources for their own ends (they usually want to do this). So, disabling the affected options completely is likely to be self-defeating. cPHulk works in a very different way to lfd's log line scanning. For most services it is assessing the patterns of login attempts to services via PAM and then prevents further logins from the source as configured. In that sense, it isn't going to be vulnerable to this issue, however it does have its own weaknesses when it comes to blocking the attacks and so a variety of protection mechanisms can't usually hurt.0 -
[quote="chirpy, post: 1562632">You're speaking very well for me :) ... cPHulk works in a very different way to lfd's log line scanning. For most services it is assessing the patterns of login attempts to services via PAM and then prevents further logins from the source as configured. In that sense, it isn't going to be vulnerable to this issue, however it does have its own weaknesses when it comes to blocking the attacks and so a variety of protection mechanisms can't usually hurt.
Heh, I'm blushing :o Thanks for the extra info on cPHulk, I imagine that'll be a useful clarification for many (unless I'm just being a klutz and missed an obvious indicator ;) )0 -
What I really want to know, at this time, is what to set RESTRICT_SYSLOG option in CSF config to on a cPanel based shared hosting server, 0 -
From the ConfigServer Blog: [QUOTE]RESTRICT_SYSLOG_GROUP taken out of BETA as it appears stable and effective. Setting RESTRICT_SYSLOG to "3? is the recommended option 0 -
[quote="Infopro, post: 1566512">From the ConfigServer Blog:
\subscribing0
Please sign in to leave a comment.
Comments
12 comments