docs/diploma: thesis/tex/4-MasqmailsFuture.tex comparison

comparison thesis/tex/4-MasqmailsFuture.tex @ 165:a7fd6d974d3c

added lots of notes about spam, malware, auth, ...

author	meillo@marmaro.de
date	Thu, 18 Dec 2008 16:41:42 +0100
parents	5681a18270b5
children	4ac06b7b9bdf

comparison

equal deleted inserted replaced

-:0e208e23aac3
+:a7fd6d974d3c
 \end{quote}
 He identifies the security of \qmail\ to come from it's \name{compartmentalization}, which goes hand in hand with modularity:
 \begin{quote}
 A perfect example is the contrast between the feature envy early \sendmail\ architecture implemented as one process and the simple, modular architecture of \qmail. The security of \qmail\ comes from its compartmentalized simple processes that perform one task only and are therefor testable for security. \cite[page 64]{hafiz05}
 \end{quote}
+As well does \person{Dent}: ``The modular architecture of Postfix forms the basis for much of its security.''\cite[page 7]{dent04}
 Modularity is needed for supporting modern \MTA\ requirements, providing a clear interface to add further functionality without increasing the overall complexity much. Modularity is also an enabler for security. Security comes from good design, as \person{Graff} and \person{van Wyk} explain:
 \begin{quote}
 Good design is the sword and shield of the security-conscious developer. Sound design defends your application from subversion or misuse, protecting your network and the information on it from internal and external attacks alike. It also provides a safe foundation for future extensions and maintainance of the software.
 %
 \subsection{Modules needed}
 This section tries to identify the needed modules for a modern \MTA. They are later the pieces of which the new architecture is built of.
-\subsubsection*{The simplest MTA}
+\subsubsection*{The simple view}
-This view of the problem is taken from \person{Hafiz} \cite[pages 3-5]{hafiz05}.
+The basic job of a \mta\ is to tranport mail from a sender to a recipient. This is the definition of such a program and this is how \person{Dent}\cite[page 19]{dent04} and \person{Hafiz} \cite[pages 3-5]{hafiz05} start on the design.
-The basic job of a \mta\ is to tranport mail from a sender to a recipient. The simplest \MTA\ therefor needs at least a mail receiving facility and a mail sending facility. This basic \MTA---following the definition of an \MTA---is much to abstract. Hence a next step to add some important features is needed, the result is an operational \MTA.
+An \MTA\ therefor needs at least a mail receiving facility and a mail sending facility. But both, and probably all \MTA\ developers (excluded the only forwarders), see the need for a mail queue. A mail queue removed the need to deliver at once. They also provide fail-safe storage of mails until they are delivered.
-\subsubsection*{Mail queue}
-\person{Hafif} adds a mail queue to make it possible to not deliver at once.
-Mail queues are probably used in all \mta{}s, excluding the simple forwarders. A mail queue is a essential requirement for \masqmail, as it is to be used for non-permanent online connections.
 \subsubsection*{Incoming channels}
 The second addition \person{Hafiz} made is the split of incoming and outgoing channels into local and remote. The question is, if this is nessesary. It is the way, it was done for a long time, but is this extra complexity needed?
 As mail delivery to local users, is \emph{not} included in the basic job of \MTA{}s, why should they care about it? In order to keep the system simple and to have programs do one job well, the local delivery job should be handed over to \NAME{MDA}s. \name{Mail delivery agents} are the tools that are specialized for local delivery. They know about the various mailbox formats and are aware of the problems of concurrent write access and thelike. Hence handling the message and the responsiblity for it over to a mail delivery agent, like \name{procmail} or \name{maildrop}, seems to be the right way to go.
 This means outgoing connections, piping mails into local commands needs to be implemented.
-\subsubsection*{Mail queue (again)}
+\subsubsection*{Sanitize mail}
+generate valid headers: add, rewrite
+... better before inserting into the queue
+(determine the method to send at that position?)
+\subsubsection*{Aliasing}
+where to expand aliases?
+\subsubsection*{Mail queue}
+Mail queues are probably used in all \mta{}s, excluding the simple forwarders. A mail queue is a essential requirement for \masqmail, as it is to be used for non-permanent online connections.
 \subsubsection*{Authentication}
-easiest: restricting by static IP addresses (Access control via hosts.allow/hosts.deny)
+either by
-if dynamic remote hosts need access: some auth is needed
+- network/ip address
-- SASL
+	easiest: restricting by static IP addresses (Access control via hosts.allow/hosts.deny)
-- POP/IMAP: pop-before-smtp, DRAC, WHOSON
+or
-- TLS (certificates)
+- some kind of auth (for dynamic remote hosts)
+	adds complexity
-``None of these add-ons is an ideal solution. They require additional code compiled into your existing daemons that may then require special write accesss to system files. They also require additional work for busy system administrators. If you cannot use any of the nonauthenticating alternatives mentioned earlier, or your business requirements demand that all of thyour users' mail pass through your system no matter where they are on the Internet, SASL is probably the solution that offers the most reliable and scalable method to authenticate users.'' (Dent: Postfix, page 44, ch04)
+	- SASL
+	- POP/IMAP: pop-before-smtp, DRAC, WHOSON
+	- TLS (certificates)
+\begin{quote}
+None of these add-ons is an ideal solution. They require additional code compiled into your existing daemons that may then require special write accesss to system files. They also require additional work for busy system administrators. If you cannot use any of the nonauthenticating alternatives mentioned earlier, or your business requirements demand that all of thyour users' mail pass through your system no matter where they are on the Internet, SASL is probably the solution that offers the most reliable and scalable method to authenticate users.
+\cite[page 44]{dent04}
+\end{quote}
 \subsubsection*{Encryption}
+TLS/SSL prevents attackers to listen on the cable
+but it does not prevent man-in-the-middle attacks
+signed certificates help here
+ch /usr/share/ssl/misc
+create new CA:
+\begin{verbatim}
+	CA.pl -newca
+		country: DE
+		state: schwaben
+		city: Ulm
+		company:
+		section:
+		name:
+		emailaddress:
+\end{verbatim}
+generate ssl key:
+\begin{verbatim}
+	CA.pl -newreq
+		... the same questions
+\end{verbatim}
+sign request with CA:
+\begin{verbatim}
+	CA.pl -sign
+\end{verbatim}
+remove passphrase from private key:
+\begin{verbatim}
+	openssl rsa <newreq.pem >key.pem
+	(to be used by programs automaticly)
+\end{verbatim}
+secure:
+\begin{verbatim}
+	chmod 400 *.pem
+	cp newcert.pem /etc/postfix/cert.pem
+	cp key.pem /etc/postfix/key.pem
+	cp demoCA/cacert.pem /etc/postfix/CAcert.pem
+	chmode 400 /etc/postfix/*.pem
+	mkdir /etc/stunnel
+	cat newcert.pem key.pem >/etc/stunnel/stunnel.pem
+	chmod 400 /etc/stunnel/stunnel.pem
+	(check /etc/stunnel with `stunnel -V')
+\end{verbatim}
+set up stunnels for POP, etc:
+\begin{verbatim}
+	nmap localhost
+	stunnel -d pop3s -r localhost:pop3 -p /etc/stunnel/stunnel.pem
+	stunnel -d imaps -r localhost:imap -p /etc/stunnel/stunnel.pem
+	nmap localhost
+		pop3s 995
+		imaps 993
+\end{verbatim}
+do not use stunnel wit SMTP:
+because all incoming mail would be from 127.0.0.1 !!
+use STARTTLS instead
+postfix: main.cf
+\begin{verbatim}
+	smtpd_use_tls = yes
+	smtpd_tls_received_header = no (does not log in received headers)
+	smtpd_tls_key_file = /etc/postfix/key.pem
+	smtpd_tls_cert_file = /etc/postfix/cert.pem
+	smtpd_tls_CA_file = /etc/postfix/CAcert.pem
+	smtp_use_tls = yes  (use TLS for sending)
+	smtp_tls_key_file = /etc/postfix/key.pem
+	smtp_tls_cert_file = /etc/postfix/cert.pem
+	smtp_tls_CA_file = /etc/postfix/CAcert.pem
+\end{verbatim}
 \subsubsection*{Spam prevention}
 where to filter what
+postfix:
+content-filter: arbitrary programs that talk smtp, can filter, rewrite or delete mail
+- before-queue-c-f: need to be fast, can prevent system load
+- after-queue-c-f: need more resources in global, more load
+exim:
+acls: to filter, what to accept (hook into smtp dialog) (complex)
+routers: take recipient address and choose a matching transport
+transports: ways to deliver mail (smtp, local)
 postfix: after-queue-content-filter (smtp communication)
-exim: content-scan-feature
+exim: content-scan-feature (analyses the content: MIME stuff, blacklisted words, virus scanning) (all within smtp dialog)
 sendmail: milter (tcp or unix sockets)
 checks while smtp dialog (pre-queue): in MTA implemented (need to be fast)
 checks when mail is accepted and queued: external (amavis, spamassassin)
+what do do with recognized mail?
+- reject (only possible if recognized during SMTP dialog)
+- forward with added header line or changed subject
+(eisentraut05: page 18--20)
+check incoming and outgoing mail
+(eisentraut05: page 21)
+milter:
+communication with external daemons via a special protocol
+at various times in the smtp dialog possible
+can reject, delete or alter messages
+http://milter.org
+(eisentraut05: page 69)
+use SA with exim:
+- with transport: piped into sa
+- content-scanning-feature: with ACL during smtp dialog
+- plugin: sa-exim
+- within amavis
+use SA with sendmail:
+- with milter
+- within mimedefang or amavis
+use SA with postfix:
+- within amavis or mailfilter
+(eisentraut05: page 25) ``Ganz ohne Analyse während der SMTP-Phase kommt sowieso kein MTA aus, und es ist eine Frage der Einschätzung, wie weit man diese Phase belasten möchte.''
+DNSBL can contain:
+- open relays
+- dynamic IP addresses
+- verified spam sources
+- open multistage relays
+- vulnerable CGI scripts
+- open proxy servers
+example: NJABL (http://njabl.org)
+DNSBL in smpt dialog is aggressive and can lead to problems (eisentraut05: page 126)
+greylisting:
+if first contact from that address: temp failure and add to list
+sender will retry, then accept
+``Das Greylisting zählt derzeit zu den effektivsten Methoden, um gegen unerwünschte E-Mails vorzugehen. Allein durch Greylisting können derzeit rund 70\% des potenziellen Spam-Aufkommens auf einem Mailserver vollständig geblockt werden. Allerdings ist es auch nur eine Frage der Zeit, bis sich die Gemeinde der Spammer und Virenautoren auf diese Methode der Spam-Bekämpfung eingerichtet und entsprechende Queues in ihre Software eingebaut hat.''(eisentraut05: page 138)
+Probleme: load balancing using multiple servers with different IPs.
+postfix: with policy server
+exim: direct in config
+sendmail: with greylist milter
+hashcash
+\subsubsection*{Virus checking}
+The same for malicious content (\name{malware}) like viruses, worms, trojan horses. They are related to spam, but affect the \MTA less, as they are in the mail body.
+message body <-> envelope, header
+anti-virus: clamav
+postfix: via amavis
+exim: via content-scanning-feature called from acl
+sendmail: with milter
+procmail
+virus scanner work on file level
+amavis receives mail via smtp or pipe, splits it in its parts (MIME) and extracks archives, the come the virus scanners
+if the mail is okay, it goes via smtp to a second mta
 AMaViS (amavisd-new): email filter framework to integrate spam and virus scanner
+\begin{verbatim}
 internet -->25 MTA -->10024 amavis -->10025 MTA --> reciptient
 |                            |
 +----------------------------+
-mail scanner:
+\end{verbatim}
-incoming queue --> mail scanner --> outgoing queue
+postfix and exim can habe both mta servises in the same instance, sendmail needs two instances running.
+what amavis recognizes:
+- invalid headers
+- banned files
+- viruses
+- spam (using spam assassin)
 mimedefang: uses milter interface with sendmail
-\subsubsection*{Virus checking}
+MailScanner:
+incoming queue --> MailScanner --> outgoing queue
-The same for malicious content (\name{malware}) like viruses, worms, trojan horses. They are related to spam, but affect the \MTA less, as they are in the mail body.
+postfix: with one instance possible, exim and sendmail need two instances running
-message body <-> envelope, header
-anti-virus: clamav
 \subsubsection*{Archiving}
+\texttt{always\_bcc} feature of postfix
 \section{A new architecture}

Mercurial > docs > diploma

comparison thesis/tex/4-MasqmailsFuture.tex @ 165:a7fd6d974d3c