Συντάκτης: Tim Jackson Ημερομηνία: Προς: exim-users Αντικείμενο: Re: [exim] infrastructure design and security
Hi exim-users@???, on Sat, 11 Sep 2004 15:35:10 +0200 you
wrote:
> I recommended using exim with sa and clamav to do protocol-time spam-
> and virusscanning and avoid collateral spam. This would be accomplished
> by putting them on a box in the outer DMZ and turning off the firewall's
> smtp proxy. > My friend had two objections to this, both stemming from security
> concerns: 1. Currently, nobody has direct access to any box in the outer
> DMZ. So an attacker would need to break into the smtp proxy of the
> firewall first, for which the manufacturer assumes liability.
Firstly: are you sure this is correct? Most commercial software comes with
strongly-worded licenses disclaiming liability for pretty much everything,
particularly consequential losses. Your colleague may have someone "to
blame" but whether this is going to add up to anything substantial in
terms of getting redress for consequential loss if everything goes
horribly wrong and the compromise of the proxy leads to some deeper
company compromise is a different matter entirely. Check the license.
> On the other hand, open source software running on an open source OS
> does not assume liability in case of break-ins.
He can always buy support from Red Hat/SuSE or whatever. Whether that's
going to result in any increased "liability" on the part of the supplier I
don't know, but it will certainly give him someone "to blame" (and to go
for for support) and quite possibly give just as much (or little) real
assurance/insurance as buying a commercial proxy/firewall.
> 2. Since machines in the outer DMZ can be potentially hacked, putting
> the virus scanner there instead of the inner DMZ, seems risky to my
> friend. Because if the virus scanner on the exim machine gets hacked, it
> can be manipulated to never detect any virus, and then he would have no
> protection against email-borne viri.
Putting it in the DMZ doesn't *necessarily* make any difference. Depending
on exactly what protocol-level checks the proxy is doing, it's entirely
possible that an "internal" machine could suffer a compromise in the same
way as if it's outside the DMZ, if that compromise came through something
related to the SMTP protocol or the contents thereof. Which could
potentially be worse than having it in the DMZ (because if it was
compromised in the DMZ, at least its access to internal machines is
limited/non-existent, whereas behind the firewall an intruder might well
be able to step across to other systems).
> Still, judging from reading the list, it seems that the concept of
> running exim plus sa and clamav on one box accessible from the big bad
> internet seems a common approach. How do you guys address my friend's
> concerns?
I think like anything it's a matter of risk. By which I mean: is the proxy
*really* adding a significant amount of security? That's a question you
can only really answer by knowing what it does, but ultimately the data is
still going to be parsed in some way or another by an internal machine.
Sure, having the machine behind a firewall might stop non-SMTP based
attacks, but on the other hand if it's compromised by an SMTP-based attack
which isn't caught by the proxy then you end up with a compromised machine
*inside* the network rather than in the DMZ, which is worse. And if you
don't actually *run* anything except SMTP on the machine doing the virus
scanning, then is it really *that* much more susceptible to attack if it's
in the DMZ? I'm thinking here a heavily-locked down, minimal machine with
every security patch you like (or don't) on it, all network servers
disabled except Exim (even SSH if you want - just admin it from a
console).
> Is anybody aware of an exploit of exim?
No software is perfect, but if you look back in the archives of security
mailing lists and similar, you'll find that Exim has a good general record
for security. There have been a small number of security issues over the
years, but they are very low in number and often relatively low in risk.
I'm not aware of any known outstanding issues, and ones that have cropped
up have generally been fixed in a timely manner.