Restricting a user's email destinations?

[thane]

Hello all,
I am setting up a server that will mostly be used by people logging on via ssh and performing tasks on the local machine. I would like to restrict certain users to only sending email to other users on the same host.

How would I most easily accomplish this? Would this be better performed by forcing some settings on the email client (mutt)?

Thank you for your time,
Thane

[W B Hacker]

thane wrote:

> Hello all,
> I am setting up a server that will mostly be used by people logging on via
> ssh and performing tasks on the local machine. I would like to restrict
> certain users to only sending email to other users on the same host.
>
> How would I most easily accomplish this?

Best is to not *have* shell accounts, other than, say 3 admin folks.

Anyone who can su to 'root' can undo whatever you have done.

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.

OTOH, if it is only 'accident's' you wish to reduce:

Remove, change perms, or repoint calls to the applicable MTA binaries.

Use 'wall' or a local-only message handling service instead of a full-blown MTA.

'Gross case' could be an instance of (for example) Exim that they *could* call,
but one whose user DB included only the accounts in question, was not bound to
an external port, had only the system/local router & transport (no remote smtp).

Simple case would be to use an editor to create a message, save it to common
storage, grant the addressee read privileges.

> Would this be better performed by
> forcing some settings on the email client (mutt)?
>

Beetle-tracking. Far less likely to be able to retain control of those than an
MTA/substitute, and neither approach is bullet-proof.

Anyone with the means to ssh-in to the server also has, by implication, the
hardware to support either webmail (borrowed gear) or his own
workstation-resident MUA-of-choice.

Ergo, we don't use system accounts for mail at all - even between and among
themselves. Instead, we put what we need into the virtual user DB like anyone
else, and/or use unrelated mail services entirely.

HTH,

Bill



--
## List details at http://www.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

[thane]

Bill,
Thank you for the thoughtful and instructive reply.

[Mike Cardwell-3]

* 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...

As for limiting which addresses can be emailed by certain users, you
should be able to do this in the acl's. There are 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.

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

--
## List details at http://www.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

[W B Hacker]

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.

;-)

Bill




--
## List details at http://www.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

[Stephen Gran-2]

On Fri, Jul 14, 2006 at 07:09:51AM +0800, W B Hacker said:
> Mike Cardwell wrote:
> >
> > 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.

I think you are misreading what that line does.  It redirects outbound
traffic destined to port 25 to localhost port 25.  It does not address
what port the query comes from.
--
 --------------------------------------------------------------------------
|  Stephen Gran                  | "Survey says..." -- Richard Dawson,     |
|  steve@...             | weenie, on "Family Feud"                |
|  http://www.lobefin.net/~steve |                                         |
 --------------------------------------------------------------------------

--
## List details at http://www.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

[W B Hacker]

Stephen Gran wrote:

> On Fri, Jul 14, 2006 at 07:09:51AM +0800, W B Hacker said:
>
>>Mike Cardwell wrote:
>>
>>>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.
>
>
> I think you are misreading what that line does.  It redirects outbound
> traffic destined to port 25 to localhost port 25.  It does not address
> what port the query comes from.

I understand what it *attempts* to accomplish.

Server security would be required to also prevent disabling the rule, either by
deletion, insertion of a pass or workaround earlier in the ruleset, or killing
the process that runs the firewall.

Better if it were on an external firewall.

It also does not block pointing to a far-end submission port, nor can we be
certain that a distant server will not accept local delivery without auth on
such a port.

Bill


--
## List details at http://www.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

On 14/07/2006 02:39, W B Hacker wrote:
> I understand what it *attempts* to accomplish.

...but by quibbling over it you're demonstrating that the obverse may be
true (from an understanding perspective). I've seen it in use, and it
*does* accomplish what it sets out to do, namely it prevents any user on
that system except the Exim user make outbound calls to port 25 on a
remote host. On a fairly generic web hosting platform it covers a
multitude of possible user sins by allowing very fine-grained control of
outbound mail; the system in question has been subject to an awful lot
of spam mastiness in the past because users insist on uploading scripts
(Perl, PHP) which don't sanitise input properly (or have many other
variant possibilities) and end up being abused by spammers.

> Server security would be required to also prevent disabling the rule, either by
> deletion, insertion of a pass or workaround earlier in the ruleset, or killing
> the process that runs the firewall.

All three options require root on the system (or privilege escalation).
In that case, all bets are off anyway - it would be relatively trivial
at that point to reconfigure almost any part of the system, Exim
included, to push email out. And killing "the process that runs the
firewall" would result in instant system death, being as iptables is
simply a userland interface to the kernel's netfilter functionality
(this being a Linux system). I suppose on other OSes things may be
different, but the same rule applies that if someone's "got root" you
might aswell either pack up and go home, or turn the machine off.

> Better if it were on an external firewall.

That I can agree with to a point, however where would you then run the
receiving MTA? Certainly not on the external firewall as it would then
become a bottleneck; also running another service on an external
firewall is loose, if not bad, design. In my opinion, obviously; other
opinions are available, and no doubt will be!

> It also does not block pointing to a far-end submission port, nor can we be
> certain that a distant server will not accept local delivery without auth on
> such a port.

I think Mike was simply pointing out the "default" case. Stating that it
doesn't do something it isn't designed to do is a rather fallacious
argument, IMO. It's easy to extend it to cover other ports (465,587).


Graeme

--
## List details at http://www.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

[Mike Cardwell-3]

* on the Fri, Jul 14, 2006 at 09:39:56AM +0800, W B Hacker wrote:

>>>> 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.
>> I think you are misreading what that line does.  It redirects outbound
>> traffic destined to port 25 to localhost port 25.  It does not address
>> what port the query comes from.
> I understand what it *attempts* to accomplish.

Attempts and succeeds...

> Server security would be required to also prevent disabling the rule, either by
> deletion, insertion of a pass or workaround earlier in the ruleset, or killing
> the process that runs the firewall.

Erm. The people he's trying to block from emailing remote accounts are
only normal system users as far as I understand... They don't have
root... "Server security would be required" - That's a given isn't it? A
normal user can't modify iptables rules...

> Better if it were on an external firewall.

Probably yes. But also, probably not necessary.

> It also does not block pointing to a far-end submission port,

So add a similar rule for port 587...

> nor can we be certain that a distant server will not accept local delivery without
> auth on such a port.

No idea what you're talking about here. How is this related to the
initial requirements stated at the beginning of this thread?

Mike

--
## List details at http://www.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

[W B Hacker]

Mike Cardwell wrote:

> * on the Fri, Jul 14, 2006 at 09:39:56AM +0800, W B Hacker wrote:
>
>
>>>>>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.
>>>
>>>I think you are misreading what that line does.  It redirects outbound
>>>traffic destined to port 25 to localhost port 25.  It does not address
>>>what port the query comes from.
>>
>>I understand what it *attempts* to accomplish.
>
>
> Attempts and succeeds...
>

..in preventing a user from reaching port 25 on a remote host, yes.

In preventing a user from sending mail, no, not by itself, it doesn't.

*snip*

> ... How is this related to the
> initial requirements stated at the beginning of this thread?
>
> Mike
>

The OP seeks to block users from sending to external destinations.

More things have to be done to accomplishing that than the rule shown.

Bill






--
## List details at http://www.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

[Mike Cardwell-3]

* on the Fri, Jul 14, 2006 at 07:09:51AM +0800, W B Hacker wrote:

>> 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.

What you've just described there doesn't bare any resemblance to what
the iptables rule I wrote does. "man iptables" should help.

>> As for limiting which addresses can be emailed by certain users, you
>> should be able to do this in the acl's.
> - and routers

Routers would probably be better actually yes. That way you don't have
to deal with multiple recipients in the non smtp acl.

>> There are  
> at least

At least? We've already determined that exim is the only user that can
now make outgoing port 25 connections. So surely the only way you can
invoke exim to send an email is by connecting to it via a tcp
connection, or running the exim binary... What's the third method of
sending an email using exim...

>> 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.

Yes it could I suppose. But I don't get how that's a response to my
text, or how it's related to the problem in question...

>> 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
> An identd is not required,

Er... I suppose you could force the use of asmtp. Installing an identd
daemon seems the easiest way though.

> and usually brings more headache than relief.

It does? It's one of the simplest services you can have installed. It
just works...

> - 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.

Sounds just like my suggestion. Except yours requires each email client
to use authenticated smtp.

> 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.

Nope. That's what my iptables rule prevents.

Mike

--
## List details at http://www.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

[Mike Cardwell-3]

* on the Fri, Jul 14, 2006 at 07:55:11PM +0800, W B Hacker wrote:

> The OP seeks to block users from sending to external destinations.
> More things have to be done to accomplishing that than the rule shown.

True I suppose. If someone decides to run their mail server on port
1234, then the user will be able to connect to it and send mail to it.
I'll leave it up to the original poster to decide whether that's even an
issue.

Mike

--
## List details at http://www.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

[W B Hacker]

Mike Cardwell wrote:

> * on the Fri, Jul 14, 2006 at 07:09:51AM +0800, W B Hacker wrote:
>
*snip*
>>>There are  

>>at least
>
>
> At least? We've already determined that exim is the only user that can
> now make outgoing port 25 connections. So surely the only way you can
> invoke exim to send an email is by connecting to it via a tcp
> connection, or running the exim binary... What's the third method of
> sending an email using exim...

If the object of the exercise is to prevent shell users from sending *only* via
Exim, that can be done entirely within Exim.

Your rule is far more useful, thank you.

But do not presume that by itself it is enough to *categorically* prevent a
shell account holder, or even a Zope/Plone/other feature-rich CMS user *without*
shell privileges, from transmitting a message from the server.

You have to close every port above 1024 and/or not already bound to by a
privileged daemon, and when you do *that* one wonders how happy your own MTA is
going to be when it tries to send to another MTA.

*snip* (identd)
>
>>and usually brings more headache than relief.
>
>
> It does? It's one of the simplest services you can have installed. It
> just works...
>

..and has a nasty history of server exploits. Enough so that attempts continue,
even if they have been fixed.

Log or tcpdump activity on your identd port sometime and see how much garbage
load your link (and stack, and CPU, and other resources) now have to deal with.

>
>>- 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.
>
>
> Sounds just like my suggestion. Except yours requires each email client
> to use authenticated smtp.
>

MUA's on 587 and such, yes. As RFC and good practice recommends.

Peer MTA's incoming on 25, not (necesarily).

>
>>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.
>
>
> Nope. That's what my iptables rule prevents.
>

OK. I can top that.

"I believe you."

And that IS a bigger lie...

;-)

Bill



--
## List details at http://www.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

[Mike Cardwell-3]

* on the Fri, Jul 14, 2006 at 08:42:45PM +0800, W B Hacker wrote:

>> At least? We've already determined that exim is the only user that can
>> now make outgoing port 25 connections. So surely the only way you can
>> invoke exim to send an email is by connecting to it via a tcp
>> connection, or running the exim binary... What's the third method of
>> sending an email using exim...
> If the object of the exercise is to prevent shell users from sending *only* via
> Exim, that can be done entirely within Exim.
>
> Your rule is far more useful, thank you.
>
> But do not presume that by itself it is enough to *categorically* prevent a
> shell account holder, or even a Zope/Plone/other feature-rich CMS user *without*
> shell privileges, from transmitting a message from the server.
>
> You have to close every port above 1024 and/or not already bound to by a
> privileged daemon, and when you do *that* one wonders how happy your own MTA is
> going to be when it tries to send to another MTA.

Can you give an example please, because I don't get exactly how you
think this could happen...

> *snip* (identd)
>>> and usually brings more headache than relief.
>> It does? It's one of the simplest services you can have installed. It
>> just works...
> ..and has a nasty history of server exploits. Enough so that attempts continue,
> even if they have been fixed.
> Log or tcpdump activity on your identd port sometime and see how much garbage
> load your link (and stack, and CPU, and other resources) now have to deal with.

I was talking about an identd server that would be queried locally. This
would of course be firewalled out of remote access. You could even
prevent any local user from talking to it other than exim, using a
similar iptables rule to the one I specified earlier... Now that's goint
to be secure for most.

>>> 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.
>> Nope. That's what my iptables rule prevents.
> OK. I can top that.
> "I believe you."
> And that IS a bigger lie...

Like I said earlier "man iptables"

Mike

--
## List details at http://www.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

[W B Hacker]

Mike Cardwell wrote:


>
> Can you give an example please, because I don't get exactly how you
> think this could happen...

'Could happen' ??

We've done it for *years* with a python module as a regular service for a CMS.

Acts like a remote-controlled MUA, not the normal webmail client, as it uses
non-local smtp, pop, imap resources.

Lynx / lynx-ssl text-mode browser is another way - one you can try for yourself
really easily.

lynx http(s)://<your remote webmail account URI>

There are others.

As said, restricting *Exim* as to destinations is not hard.

Preventing general misbehaviour originating on your own server that might get
your IP blacklisted is a little more difficult. IPFW / IPF / iptables can help.

Preventing users from sending mail entirely, or otherwise restricting them to a
sub-set of destinations is a *lot* harder if you need to support a variety of
services on the same box.

Bill


--
## List details at http://www.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

[Mike Cardwell-3]

* on the Fri, Jul 14, 2006 at 09:33:43PM +0800, W B Hacker wrote:

>> Can you give an example please, because I don't get exactly how you
>> think this could happen...
> 'Could happen' ??
>
> We've done it for *years* with a python module as a regular service for a CMS.
>
> Acts like a remote-controlled MUA, not the normal webmail client, as it uses
> non-local smtp, pop, imap resources.
>
> Lynx / lynx-ssl text-mode browser is another way - one you can try for yourself
> really easily.
>
> lynx http(s)://<your remote webmail account URI>

Then you're not sending mail from the local server, you're making http
requests from the local server instead. You're actually sending mail
from the remote server... I don't think what you've just described fits
with what thane is/was trying to restrict.

> As said, restricting *Exim* as to destinations is not hard.
>
> Preventing general misbehaviour originating on your own server that might get
> your IP blacklisted is a little more difficult. IPFW / IPF / iptables can help.
>
> Preventing users from sending mail entirely, or otherwise restricting them to a
> sub-set of destinations is a *lot* harder if you need to support a variety of
> services on the same box.

I don't think it is hard. I've managed it successfully on a large shared
hosting web farm. It just requires some thought and planning.

Mike

--
## List details at http://www.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/