CSF Syslog Security Warning, are there analogous features in cPanel itself?

[ThinIce]

CSF has been updated with a security warning around the security of the information in system logs. While I digest this (the http://configserver.com/free/csf/readme.txt contains useful further information) are there any cPanel scripts and features that can be similarly mislead?

6.41 - SECURITY WARNING:

Unfortunately, syslog and rsyslog allow end-users to log messages to
some system logs via the same unix socket that other local services
use. This means that any log line shown in these system logs that
syslog or rsyslog maintain can be spoofed (they are exactly the same
as real log lines).

Since some of the features of lfd rely on such log lines, spoofed
messages can cause false-positive matches which can lead to confusion
at best, or blocking of any innocent IP address or making the server
inaccessible at worst.

Any option that relies on the log entries in the files listed in
/etc/syslog.conf and /etc/rsyslog.conf should therefore be considered
vulnerable to exploitation by end-users and scripts run by end-users.

There is a new RESTRICT_SYSLOG option that disables all those features
that rely on affected logs. This option is NOT enabled by default.

See /etc/csf/csf.conf and /etc/csf/readme.txt for more information
about this issue and mitigation advice

NOTE: This issue affects all scripts that process information from
syslog/rsyslog logs, not just lfd. So you should use other such
scripts with care

Our thanks go to Rack911.com for bringing this issue to our attention

 

[cPanelMichael]

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.

 

[ThinIce]

An interesting discussion with involved participants can be found at

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 Web Hosting Talk - View Single Post - FEATURED Log Spoofing Vulnerabilities - CSF, BFD, Fail2Ban and Many Others... [SEEKING INPUT]

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.

 

[jols]

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?

 

[SoftDux]

/subscribing

 

[jols]

Anyone familiar enough with cPHulk to be able to answer this question? TIA.

 

[ThinIce]

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:

Web Hosting Talk - View Single Post - FEATURED Log Spoofing Vulnerabilities - CSF, BFD, Fail2Ban and Many Others... [SEEKING INPUT]

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

Web Hosting Talk - View Single Post - FEATURED Log Spoofing Vulnerabilities - CSF, BFD, Fail2Ban and Many Others... [SEEKING INPUT]

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 information

 

[ThinIce]

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...

 

[chirpy]

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.

 

[ThinIce]

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

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 )

 

[PPNSteve]

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,

 

[Infopro]

From the ConfigServer Blog:

RESTRICT_SYSLOG_GROUP taken out of BETA as it appears stable and effective. Setting RESTRICT_SYSLOG to “3″ is the recommended option

 

[Skin]

From the ConfigServer Blog:

\subscribing