Loading ...
Sorry, an error occurred while loading the content.

295860Re: Temporarily block domain.tld from sending?

Expand Messages
  • Stan Hoeppner
    Oct 8, 2013
      On 10/8/2013 7:15 PM, lists@... wrote:
      > On Wed, October 9, 2013 10:41 am, Stan Hoeppner wrote:
      >> On 10/8/2013 3:08 PM, lists@... wrote:
      > Stan, Michael and other who responded, thanks
      >> Others responded with some good ideas here, mostly locking down PHP
      >> itself so it can't use the sendmail binary. But it sounds like this is a
      >> generic web hosting server for your customers. Which means they may be
      >> using all manner of languages other than PHP, such as Perl, Java, etc.
      > modified php.ini as per Micheal's suggestion;
      > yes, it is as you suggest, 'all manner..';
      >> In this case, the most thorough way to lock this down, other than
      >> disabling the pickup service in master.cf, is to restrict execute
      >> permissions on the sendmail binary to root. This prevents all web
      >> applications from using the pickup service. Then instruct all of your
      >> users to use the submission service on TCP 587 for sending mail.
      >> Disabling pickup is the easiest and quickest way to stop this spamming
      >> permanently. But it will likely break management functions that need to
      >> send mail via pickup, such as logwatch, pflogsumm, etc. Thus restricting
      >> which users can execute the sendmail binary is a better solution.
      > I'll work towards that later today
      > I'm still perplexed with access: the user claims no one else had ftp

      Look at every file in this user's publicly accessible directory tree.
      You may find that s/he saved the username/password in a text file
      (regardless of file extension, or name), which is quite common for many
      users, especially those who don't update the site but once every few
      weeks, months, etc. They bookmark the URL and "remember" the
      credentials this way when they need to work on the site. Crackers will
      often find such files, even if not exposed anywhere in the HTML content
      of the site.

      > password, ftp password was a random 8-char alpha/numeric string,
      > can there be any other reason that leaked password...?

      There are all manner of ways credentials can fall into the wrong hands.
      Above is only one. The simplest is the Post-it note, both literally
      and metaphorically. You can't control this. What you can is the
      password itself, and the frequency of change. Random passwords are
      meaningless if someone can simply copy or steal the Post-it. Changing
      passwords regularly helps mitigate this problem, but not if users simply
      put the new password in an accessible file, as in the scenario above.

    • Show all 18 messages in this topic