General

New csf v2.85

Changes:

  • Fixed a problem with v2.84 which broke permanent IP blocking in lfd – it’s been a long week :-/

New csf v2.84

Changes:

  • Fixed problem with permanent LF blocks in lfd for individual application port blocks when set to permanent
  • Added new SYSLOG option to csf.conf to allow additional lfd logging to SYSLOG (requires perl module Sys::Syslog)
  • Added a minimum to LF_DSHIELD and LF_SPAMHAUS ip block lists refresh interval of 3600 to prevent getting yourself blocked!

N

New csf v2.82

Changes:

  • Fixed a documentation for LF_TRIGGER_PERM
  • Fixed issue where RT_[relay]_ALERT set to “0” was being ignored
  • Fixed condition from v2.80 which prevented SCRIPT_ALERT from working
  • If killproc.conf does not exist the Server Check now links to the Background Process Killer page instead of issuing a file missing error

New csf v2.81

Changes:

  • Added exe:/usr/local/cpanel/cpdavd to csf.pignore
  • Added option to disable refresh in WHM csf UI when viewing lfd.log
  • Removed debug code that prevented IP blocking — oops

New csf v2.80

Changes:

  • Added new lfd feature – Relay Tracking. This allows you to track email that is relayed through the server (cPanel only). It tracks general email sent into the server, email sent out after POP before SMTP and SMTP_AUTH authentication, local email sent from the server (e.g. web scripts). There are also options to send alerts and block IP addresses if the number of emails relayed per hour exceeds configured limits. The blocks can be either permanent or temporary. Currently blocking does not function for LOCALRELAY email.
  • Introduced a new blocking mechanism in lfd that allows a choice of permanent or temporary IP blocking. See csf.conf (LF_TRIGGER_PERM) for details on how to configure the various blocking options to use temporary instead of permanent blocks, e.g. for Login Failure blocking
  • Modified new installations to default to using seperate triggers for login failures, instead of the global LF_TRIGGER value

Are you still running without PHP protection?

An interesting report as been posted recently about the inherent dangers of allowing code to run under the same username as the apache process, i.e. nobody. This happens if you run PHP as a module, or CGI scripts without SUExec protection:http://seclists.org/bugtraq/2007/Jun/0250.htmlOf course, this is not anything new and the dangers have been known about for a long time. However the paper explains just how vulnerable you really are if you don’t protect your apache configuration from code being run within the context of its own user.Note that this affects both apache v1 and v2.Avoiding this issue is relatively simple:1. Enable SUExec (which is the default on cPanel installs)2. Enable PHPsuexec (or SuPHP), and understand the limitations that imposesLeaving your server without protection is inviting hackers to exploit your whole server including all your clients data, through a simple hole in one PHP script on one account on your server.An interesting take on this report is also discussed by the creator of mod_security:http://www.modsecurity.org/blog/archives/2007/06/apache_process.html

New csf v2.79

Changes:

  • Bug fixes
  • Added ACCEPT rule to 127.0.0.1:25 for the “cpanel” user if SMTP_BLOCK is enabled for the new cPanel Webmail configuration in v11
  • Added new configuration option DROP that allows you to choose the drop target for rejected packets (see csf.conf for more information)
  • Remove /etc/cron.d/csf_update on uninstall

New csf v2.77

Changes:

  • Closed vulnerability with temporary file checking
  • Tightened log file regex’s to prevent spoofed remote IP block attacks

Inept PHP developers strike again

Why on earth are the developers of PHP incapable of making their scripting language backwards compatible? It really, seriously, beggars belief. I’ll be sure to stick to perl scripts in the future as I’m sick and tired of their lack of professionalism when it comes to language development.BTW, a php upgrade today broke a couple of our website applications again, including the blog and forum, which seems to be an all too common occurrence.Inept idiots.IMHO 😉

New csf v2.76

Changes:

  • Improved file checking in Server Check script to prevent WHM failures