Re: [exim] Quick Question - Prohibiting users from sending e…

Pàgina inicial
Delete this message
Reply to this message
Autor: W B Hacker
Data:  
A: exim users
Assumpte: Re: [exim] Quick Question - Prohibiting users from sending email
Troy Engel wrote:

> Marc Perkel wrote:
>
>>I'm trying to prevent hackers who might get in from being able to send
>>email if they manage to hack me. I want it so that unless they are
>>specific users that they have no rights to connect to port 25 or run exim.
>
>
> Does this machine receive email? If not, then the solution is simple:
>
> 1) decide on a smarthost (another machine) to accept mail from this
> IP/machine (ie relay). This machine could run Exim in normal mode.
>
> 2) configure Apache and Exim sending to use that smarthost, and only
> allow root or apache to use Exim. However, I would recommend using
> something like 'msmtp' instead of Exim to provide outgoing mail only.
> (http://msmtp.sourceforge.net/) and not listen on port 25, it's not needed.


No help. IF the box itself has been compromised, the perp has
shell access. With that, Exim is not needed - they can install
and run theior own smtp.

>
> 3) use iptables to block any outgoing SMTP (ports 25, 465, 587) to any
> machine other than the smarthost you decided on above. (see
> http://oceanpark.com/notes/firewall_example.html)
>


Not 100% useful. MTA's *listen* (for other mx) on port 25. They
ordinarily *send* on random ports well above 1024.


> Of course, if you need to receive mail on this machine then life is that
> much more complicated, but still using a smarthost and iptables together
> is your best chance at success. However, a hacker would most likely run
> the receiving SMTP server on an unusual port, so you might have to use a
> more hardcore iptables setup (ie disallow all outbound traffic instead
> of what's needed).


That last part is the hardest. Even IF one can configure the MTA
to use a specific outbound port and close all others, it will
relinquish that port between sending sessions.

At that point, some other process has a chance of grabbing it
and using it.

Further, it is generally a safe assumption that any entity
clever/patient enough to crack a shell account, can and will,
escalate privileges, eventually to 'root'..

To be 'certain', the box has to be constructed in such a way
that even 'root' cannot add/alter authorized users, nor alter
the config file, nor invoke other daemons ('coz there are no
HDD, utilities, nor coms channels - only PROM). That spells
state machine, and physically swapped PROMs, not in-place
reprogrammable ones.

And/or 'non-UNIX/Linux' - i.e. a single-user/process hardware
device of another sort.

As in an OS/2 cash-till/Automated Teller Machine - which doesn't
even have command shell or GP UI in the conventional sense -
just button-scan and canned graphics.

Bill



>
> hth,
> -te
>