Lars Nielsen wrote:
Lars Nielsen wrote:
Hi List,
I am developing a php-based webservice with which i want to control and
manage exim from a web-gui.
What is the best and most secure way to control Exim from a php-script?
Some issue can be configured via a database but i still need to call the
exim executable some times!?
Lars,
Perhaps it is just time-zones and weekend priorities, but the lack of a
response so far just might indicate a reluctance to help you implement
what has to be akin to an attempt to walk on water .. and failing, have
coded the electronic equivalent of a suicide-kit, 'abuseability' wise.
php is a grand tool for coding nice web pages rapidly.
Securing it and preventing a web app being suborned is NOT so fast and
easy, adn more than a few MTA have suffered becasue of that.
'More better' if you must go that route to use the oldest and best
tested and debugged off-the shelf F/LOSS php critter you can find.
Its devel team and user community will at least already have the scars
and wisdom gained from TRYING to secure it. And more than a few times.
Easier to then customize look and feel than reinvent that entire
wheel... a decidedly 'non-trivial' exercise.
And one not really within Exim's purview...
Anything that can invoke the binary ... can invoke the binary.
Best Exim can do thereafter is try to filter and ratelimit.
You'll need an acl_not_smtp critter to do some of that...
Bill
--
韓家標
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Hi Bill,
Thanks for your advise and comment. I am sure this is not a trivial
task. Thats why I asked for ideas here! :-)
Is it possible to invoke the exim binary in another way than to call it
directly from a script/commandline? It would mostly be to reload
configuration-settings.
If dynamic adjustment to configuration is the goal, it is far better to
NOT re invoke it any more often than one must. Elevated privs are (or
should be) required to EITHER modify or swap configs OR (re)invoke the
binary.
Far more flexible to configure Exim to get those 'dynamic' inputs from
tables or DB, or a mix of such, as you can independently set privilege
levels on those, and they need not even all be 'local'. Exim is quite
happy to read per-system, per-recipient, per-destination, or
per-'situation' data from external sources, rapidly so, and in as
intricate a combination as you may choose to create.
With an external DB-engine on a remote server, one can even provide at
least an modest level of protection against whomever has 'root' of the
MTA box surreptitiously accessing/modifying key data - such as UID:PWD.
At the very least, one has a better chance of preserving an audit trail
on the distant box, EVEN IF the miscreant has implemented a local
replacement, as the queries will show time-related anomalies.
Side note, but I'd use an OS or external FW that blocked 'from any ___
to any port 25' in such a way as to grant the Exim daemon - and no other
- ability to get off-box with a destination SMTP submission port as target.
Whilst php, perl, ruby, python, tcl, yadda, yadda - and near-as-dammit
ALL compiled languages - have available smtp-sender code-snippets, 'Job
ONE' isn't so much that of picking the least-risky of 'em nor scripts to
the same effect ... but rather insuring that a closely-watched MTA is
the ONLY route off-box.
All your eggs in one basket. Then watch that basket, as it were, 'coz
Exim is one vicious tattle tale when told to be.
As to a 'web app'. I'd want to at least run it sealed into a virtualizer
guest container if not on separate iron entirely from the MTA.
Another side note.. 'LAMPS' As in Linux, Apache, MySQL php .. etc?
.. perhaps more accurate to call that "LCD" as in Lowest Common
Denominator. Widely understood and used, yes. Equally widely attacked.
though seldom as successfully as it once was, but.. still uber-annoying
as to b/w and machine-cycle waste in the defence.
Why defend against horseflies when one need not attract them in the
first place? 'php' or 'aspx' visible in a URL attract vermin. ID of
Linux as an OS is only marginally less attractive to attackers than an
MS OS. Quite 'secure-able' by those who care to do, but too many sloppy
installations about.
Consider OpenBSD, Hiawatha, PostgreSQL, compiled apps instead of
interpreted, perl or python if one must ...and most of the vermin will
go seek easier targets and leave your costly b/w and power budget clear
for user's benefit ... instead of perpetually distracting street-brawls
on the link.
JM2CW. I don't use 'em as an 'elitist'. I use 'em 'coz I am too damned
*lazy* to waste time minding 'high speed idiots', and too bleedin' cheap
to waste for-fee resources.
Bill
--
韓家標
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
