main groups: preventive strategies and corrective
strategies.
In the side of the preventive strategies we can
find several efforts for minimizing the threats and, as
consequence, the risks associated to be attacked.
One of them is to establish a corporative policy for
the use of email, another to protect the email
address, by not publishing it in non secure webs, or
by using obfuscators.
Some of the corrective strategies try to avoid
that, once the attack initiated, the spam or infected
mail, arrive its target, but allowing the valid
messages. We can find also two broad classes, one is
a technique based on the message content and the
other not based in the content.
The techniques based in the message content
analyze this and the subject header in search of a set
of words that reflect the kind of message, using
basic filters, , heuristic filters, or bayesian filters (Li
et al, 2006), that learn to distinguish the valid (ham)
mails and the spam.
The other techniques are based in other different
characteristics in the message content, as the name
of the source server or its IP address:
- Black lists, IP addresses lists that must be
blocked because they are known as spam
sources.
- White lists, lists with trusted sender IP
addresses.
- Distributed filters (DCC, Distributed
Checksum Clearinghouse). In this case the
user marks any message he considers to be
spam, then DCC program generates a
signature identifying the message and sends
it to the DCC servers, that are updated
daily, as the pay service referenced in
www.cloudmark.com.
- Grey Lists or challenge/response.
- Sender Policy Framework, an emerging
standard in which the domain owners
designate their email servers in DNS in a
predefined way (using SPF registers) that
let the email messages receivers to check if
it is a legitimate message sent by the email
server associated to the domain specified in
the sender.
But what it is not possible to find, at least in the
open source arena, is a complete and easy to manage
and effective system, and we thought a good idea
was to develop an exhaustive control of the problem
in a continuous, adaptive way, really a securely
managed service.
To face the problem we began studying a new
possible protection architecture.
3 PROTECTION
ARCHITECTURE FOR THE
EMAIL SERVICE
If it is assumed that it seems impossible to stop the
attacks and malware infections with a 100% of
success, and that the attackers are more dynamic
than the developers and builders of protection
products, it is crucial to understand that it must be
the infrastructure itself the responsible of the
constant and continuous protection against the
possible (very probable) unwanted effects.
It must be provided a multilevel architecture that
channels and minimizes the impact of a protection
level with respect to the next one, and such that the
possible vulnerabilities of a level doesn’t affect the
following one. In this way we can consider each
level an independent sub-service, which must be
protected.
One of the main pillars in this architecture is that
the mailboxes are not in the same server that
receives the messages from Internet. This allows an
easier protection of the stored user content, not being
affected in the case of having being attacked
successfully one of the front levels.
Other important consideration is to oblige any
message sent from within our organization to go
through the same levels that a received message. The
objective is to minimize the risk window associated
with the corporative electronic mails.
Taking all that into consideration we can define
the different protection levels, illustrated in Figure 1.
3.1 Multilevel Architecture
We can differentiate 5 different levels in the
architecture:
1- Front-end shell: The first line of defence,
exposed directly to Internet. We place here
the email server published in the DNS
server for our organization domain, the
server target of any world wide email server
for sending email messages to our
organization.
2- Corporate firewall: We can include a strict
filter in our firewall defining our front-end
email server as the only machine that can
introduce email messages in our internal
network. On the other hand, nobody from
the internal corporate network can send
email outside without using the front-end
email server (the firewall is instructed to).
SECRYPT 2008 - International Conference on Security and Cryptography
470