cPanel

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

Bug in cPanel CURRENT/EDGE chkservd

If you are finding chkservd restarting lfd, antirelayd, mailscanner or other monitored process then there’s a bug in the latest chkservd. cPanel have been informed via the EDGE users mailing list (just now). Whilst waiting for a fix, you have two options:1. Untick the monitored services that chkservd keeps restarting falsely in WHM > Service Monitor > under the Monitor list. The dowside of this is that those processes won’t be monitored if they fail. You will also need to tick them again once cPanel have fixed chkservd2. Apply the following modification yourself. The upside is that monitoring continues, the downside is that it’s unofficial and will be overwritten after a upcp upgrade:Edit /usr/local/cpanel/libexec/chkservd and go to line 369 and change it from:

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

cPanel v11 email: [mailconfigupdate] Unable to automaticlly update the mailer config on "hostname"

If you receive the following email on cPanel v11 and you’re running our MailScanner package or are not using the cPanel inbuilt SpamAssassin setup:

cPanel was unable to automatically merge your Exim configuration with the new settings that shipped with the build you have installed (cpanel_version) because you have a custom ACL configuration which cannot be automatically configured.

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 MailScanner Script v2.57

Changes:

  • Removed the use of wget
  • Modified to use pgrep instead of pidof which is broken on some systems
  • New version of MailScanner v4.60.8

Recipient/Sender verification issue from older cPanel v11 CURRENT

If you are finding :fail: messages ending up in the exim queue, then the cause is most likely a bug that was in an older cPanel v11 CURRENT release that introduced a miss-configuration in exim.conf. This has been fixed in the latest builds, but if you were an early v11 adopter your exim.conf may be incorrect.You can check this by going into the WHM > Exim Configuration Editor > Advanced Mode and scrolling down to the ACL section. Then check for the following lines:require verify = recipientand:require verify = senderBoth lines will probably have related message and comments around them. You need to ensure that the recipient verification comes before the sender verification. If it doesn’t, switch the blocks around and save the configuration.This problem is also responsible for root email delivery failures for the root crontab jobs and with the global abuse and postmaster /etc/myaliases file setup that we perform.