Autor: W B Hacker Data: A: exim users Assumpte: Re: [exim] Restricting a user's email destinations?
Mike Cardwell wrote:
> * on the Thu, Jul 13, 2006 at 10:28:45AM +0800, W B Hacker wrote:
>
>
>>Even 'ordinary' shell-account holders can usually drop their own smtp code into
>>place. Essentially all of the interpreted languages have several available.
>>
>>and - at the end of the day, anyone who needs to do so can telnet to a distant
>>server and manually send a message. It isn't hard to do.
>
>
> You can get around such problems by building a tight firewall. I get around this
> particular problem on one of my systems by redirecting all outgoing connections
> on port 25 to localhost unless they're initiated by the exim user. I do this
> using iptables:
>
> iptables -t nat -A OUTPUT -p tcp --dport 25 -d ! 127.0.0.1 -m owner ! --uid-owner exim -j DNAT --to-destination 127.0.0.1
>
> Someone might find that useful...
The intent is good, but that specific rule is not necessary on Unix, nor will it
block outbound traffic.
- ports below 1024 are reserved to 'root' anyway.
- an(y) MTA running as a daemon will have been given that port (by initial
invocation as root).
- once a daemon has bound to port 25, the next entity (even root) that attempts
to bind to it will be denied. Demo this by manually attempting to onvoke Exm a
second time, and tailing /var/log/messages /var/log/maillog,
/var/log/exim/paniclog (wherever you are logging).
But perhaps most of all - an MTA ordinarily *listens* on port 25, and initiates
outbound smtp on ports above 1024.
And w/r user-installed mailing code - any port that they can get the use of
will do.
I'll presume you have a rule eleswhere that blocks that.
>
> As for limiting which addresses can be emailed by certain users, you
> should be able to do this in the acl's.
- and routers
> There are
at least
> two ways they could
> send the email, either by calling the exim binary directly, or by making
> a local connection to port 25. There are different ways to identify the
> sending user in both circumstances.
>
Careful crafting of the exim setup can prevent 'smtp incoming' from other ports
on your own IP, and control non-smtp as well - long before acl's come into play.
Careful crafting of routers, with or without acl aid, can add to that control.
> If the sending is being done by calling the exim binary directly, you
> can access the users uid inside $caller_uid.
>
> If the sending is being done by the user connecting to port 25 locally,
> you should install an identd server and use $sender_ident
>
> Mike
>
An identd is not required, and usually brings more headache than relief.
- properly configured, authentication should be required for any traffic not
destined for on-host users. Non-authenticated smtp traffic addressed to off-host
destinations should be treated as unauthorized relay attempts.
At the end of the day, Exim rulesets can restrict 'proper' users to specific
destinations and/or prohibit specific destinations.
But the 'challenge' remains that a shell account holder who has either the
ability to install and use executables or even to simply acess telnet, can
connect to a destination server without ever touching Exim.
Put another way:
- Seeing to it that your Exim daemon is not misused is one 'world'.
- Protecting the server overall from misuse is a different 'world'.
And preventing 'wetware' from communicating *at all* gets into the zone of
firearms and barbed wire. Even that has proven porous.