Uwe Dippel wrote:
When dealing with web based submission, the best thing I have found is
to make sure the web based submission adds its own headers like what it
is and where the user came from and such so when diagnosing the problem
one can easily block based on that information. If there is an account
involved, you should include that info as well.
Dear Todd,
I'm sorry, but I lack the experience to understand what you mean. I
have 200+ users, several of them having set up (sorry, yes, written!),
who can install any CMS of their liking, using ftp; or any other
script that
sends mail. Some of them are official websites, so I can not shut down
the
whole mini_sendmail business in the chrooted Apache. I also cannot
read, study,
hundreds of thousands of lines of code to find out how and where a
web-page hosted by me allows an attacker to inject a message of her
own, to a recipient of her own choice.
Since mini_sendmail receives it through php from Apache, I wonder how
I could log e.g. the website from which it was sent, or at least
easily limit the number of calls of mini_sendmail.
Again, your idea being fine for an application developer, which I am not.
I wouldn't know how to add the account to which the application
belongs that can be abused.
The only two places where I, IMHO, can see a chance would be with an
extended
log or check of Apache or php; whenever a mail-call is logged, from
which directory, e.g.
If you're really cracking this nut properly, you'd include heuristics
to temporarily block if too many messages are sent in a given time
period,
and permanently block pending review if too many temporary blocks occur
within a given time period.
Yes. But that's a complete coder's work, isn't it? I wonder if there
is no
other solution, as mentioned above. sendmail_path =
"/bin/mini_sendmail -t -i"
is what I have in php.ini.
This could be helpful, possibly. First, you can maintain a functional
mini_sendmail by putting a nother script at /bin/mini_sendmail, this
script could do some sort of logging and then pass things on to the real
mini_sendmail, located somewhere else, different (hidden) name.
Since all this goes through php first, setting up this script is easy.
Question for someone more knowledgeable:
Can a simple script be set up to do any useful logging at this stage?
Obviously, major revisions in existing applications are to be skipped.
I wonder, if there are no logging features for
mini_sendmail or so. I read the man-page online, but didn't see any.
If it doesn't exist, it surely would be a good enhancement if the path of
the application from which it is send was carried through, so that a
filter
can be written, to allow or drop depending on the path of that
application.
Uwe
--
A human being should be able to change a diaper, plan an invasion,
butcher a hog, conn a ship, design a building, write a sonnet, balance
accounts, build a wall, set a bone, comfort the dying, take orders,
give orders, cooperate, act alone, solve equations, analyze a new
problem, pitch manure, program a computer, cook a tasty meal, fight
efficiently, die gallantly. Specialization is for insects.
-- Robert Heinlein
