295860Re: Temporarily block domain.tld from sending?
- Oct 8, 2013On 10/8/2013 7:15 PM, lists@... wrote:
> On Wed, October 9, 2013 10:41 am, Stan Hoeppner wrote:Look at every file in this user's publicly accessible directory tree.
>> 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
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,There are all manner of ways credentials can fall into the wrong hands.
> can there be any other reason that leaked password...?
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.
- << Previous post in topic Next post in topic >>