Postscreen - Schutz vor Überbelastung und SPAM-Abwehr
Die Grundidee hinter Wietse Venema's postscreen Daemon, ist der Schutz des Mailservers vor Überlastung. Ein postscreen Prozess lässt dabei nur noch diejenigen Verbindungen zum SMTP-Daemon durch, die die Eingangstest nicht überlebt haben. Typischer Weise sind gekaperte Rechner (Zombies) und andere SPAM-Bots für etwa 90% aller Spam-Mails verantwortlich. Durch das Elimimieren dieser unerwünschten Verbindungsanfragen, stehen die SMTP-Serverprozesse mehr den legitimen MTAs1) zur Verfügung und entlastet so den kompletten Server.
Damit der erwünschte MTA zu MTA Verkehr bestmöglichst nicht eingeschränkt wird, pflegt der postscreen Daemon eine eigene temporäre Whitelist, in die er alle Clients einträgt, die die postscreen Prüfungen bereits bestanden haben.
Die Hauptaufgabe, bzw. wie Wietse es sagt „..die größte Herausforderung“ von postscreen ist es mit nur einer Bewertung herauszufinden, ob es sich um einen SPAMer handelt oder nicht. Dies ist vor allem dadurch notwendig, da viele Zombie-Systeme versuchen, möglichst unerkannt SPAM zu versenden und dadurch vermeiden große Mengen an einem Host einzuliefern. Bewertet postscreen den Zustellversuch als HAM, also als erwünschten Verkehr, so merkt er sich diesen Host in seiner temporären Whitelist und vermeidet so weitere Verzögerungen bei legitimen Verkehr. Eine weitere Herausforderung von SPAM versendenden Systemen ist die begrenzte Zeit, bevor die betroffenen IP-Adressen auf Blacklisten erscheinen, die zur Verfügung steht um SPAM zu verschicken. Daher sind viele SPAM-Clients darauf getrimmt, möglichst schnell ihre Post loszuwerden. Sie ignorieren daher sehr oft richtige SMTP-Implementierungen, legen mit der Übertragung sofort nach dem Connect los oder ignorieren Rückmeldungen des Empfangssystems. All dies macht sich postscreen zu nutze!
Zur Erkennung von Zombies nutzt der Postscreen Daemon verschiedene Techniken. So prüft der Daemon erst mal, ob der Client auf einer Blacklist gelistet ist. Dabei kann er verschiedene Listen befragen und entsprechend deren Gewichtung eine Entscheidung treffen. Des weiteren prüft postscreen, ob der Client RFC-konform arbeitet, oder ob der Client ungefragt loslegt bevor der SMTP-Daemon sich richtig gemeldet hat. Bereits diese beiden Prüfungen reichen aus, um eine erste Entscheidung auf HAM oder SPAM zu treffen.
manpage
Viele wertvolle Konfigurationshinweise findet man in der Manpage von postscreen.
# man 8 postscreen
POSTSCREEN(8) POSTSCREEN(8)
NAME
postscreen - Postfix zombie blocker
SYNOPSIS
postscreen [generic Postfix daemon options]
DESCRIPTION
The Postfix postscreen(8) server provides additional protection against
mail server overload. One postscreen(8) process handles multiple
inbound SMTP connections, and decides which clients may talk to a Post-
fix SMTP server process. By keeping spambots away, postscreen(8)
leaves more SMTP server processes available for legitimate clients, and
delays the onset of server overload conditions.
This program should not be used on SMTP ports that receive mail from
end-user clients (MUAs). In a typical deployment, postscreen(8) handles
the MX service on TCP port 25, while MUA clients submit mail via the
submission service on TCP port 587 which requires client authentica-
tion. Alternatively, a site could set up a dedicated, non-postscreen,
"port 25" server that provides submission service and client authenti-
cation, but no MX service.
postscreen(8) maintains a temporary whitelist for clients that have
passed a number of tests. When an SMTP client IP address is
whitelisted, postscreen(8) hands off the connection immediately to a
Postfix SMTP server process. This minimizes the overhead for legitimate
mail.
By default, postscreen(8) logs statistics and hands off every connec-
tion to a Postfix SMTP server process, while excluding clients in
mynetworks from all tests (primarily, to avoid problems with non-stan-
dard SMTP implementations in network appliances). This mode is useful
for non-destructive testing.
In a typical production setting, postscreen(8) is configured to reject
mail from clients that fail one or more tests. postscreen(8) logs
rejected mail with the client address, helo, sender and recipient
information.
postscreen(8) is not an SMTP proxy; this is intentional. The purpose
is to keep spambots away from Postfix SMTP server processes, while min-
imizing overhead for legitimate traffic.
SECURITY
The postscreen(8) server is moderately security-sensitive. It talks to
untrusted clients on the network. The process can be run chrooted at
fixed low privilege.
STANDARDS
RFC 821 (SMTP protocol)
RFC 1123 (Host requirements)
RFC 1652 (8bit-MIME transport)
RFC 1869 (SMTP service extensions)
RFC 1870 (Message Size Declaration)
RFC 1985 (ETRN command)
RFC 2034 (SMTP Enhanced Status Codes)
RFC 2821 (SMTP protocol)
Not: RFC 2920 (SMTP Pipelining)
RFC 3207 (STARTTLS command)
RFC 3461 (SMTP DSN Extension)
RFC 3463 (Enhanced Status Codes)
RFC 5321 (SMTP protocol, including multi-line 220 banners)
DIAGNOSTICS
Problems and transactions are logged to syslogd(8).
BUGS
The postscreen(8) built-in SMTP protocol engine currently does not
announce support for AUTH, XCLIENT or XFORWARD. If you need to make
these services available on port 25, then do not enable the optional
"after 220 server greeting" tests, and do not use DNSBLs that reject
traffic from dial-up and residential networks.
The optional "after 220 server greeting" tests involve postscreen(8)'s
built-in SMTP protocol engine. When these tests succeed, postscreen(8)
adds the client to the temporary whitelist, but it cannot not hand off
the "live" connection to a Postfix SMTP server process in the middle of
a session. Instead, postscreen(8) defers attempts to deliver mail with
a 4XX status, and waits for the client to disconnect. When the client
connects again, postscreen(8) will allow the client to talk to a Post-
fix SMTP server process (provided that the whitelist status has not
expired). postscreen(8) mitigates the impact of this limitation by
giving the "after 220 server greeting" tests a long expiration time.
CONFIGURATION PARAMETERS
Changes to main.cf are not picked up automatically, as postscreen(8)
processes may run for several hours. Use the command "postfix reload"
after a configuration change.
The text below provides only a parameter summary. See postconf(5) for
more details including examples.
NOTE: Some postscreen(8) parameters implement stress-dependent behav-
ior. This is supported only when the default parameter value is
stress-dependent (that is, it looks like ${stress?{X}:{Y}}, or it is
the $name of an smtpd parameter with a stress-dependent default).
Other parameters always evaluate as if the stress parameter value is
the empty string.
COMPATIBILITY CONTROLS
postscreen_command_filter ($smtpd_command_filter)
A mechanism to transform commands from remote SMTP clients.
postscreen_discard_ehlo_keyword_address_maps ($smtpd_discard_ehlo_key-
word_address_maps)
Lookup tables, indexed by the remote SMTP client address, with
case insensitive lists of EHLO keywords (pipelining, starttls,
auth, etc.) that the postscreen(8) server will not send in the
EHLO response to a remote SMTP client.
postscreen_discard_ehlo_keywords ($smtpd_discard_ehlo_keywords)
A case insensitive list of EHLO keywords (pipelining, starttls,
auth, etc.) that the postscreen(8) server will not send in the
EHLO response to a remote SMTP client.
TROUBLE SHOOTING CONTROLS
postscreen_expansion_filter (see 'postconf -d' output)
List of characters that are permitted in
postscreen_reject_footer attribute expansions.
postscreen_reject_footer ($smtpd_reject_footer)
Optional information that is appended after a 4XX or 5XX
postscreen(8) server response.
soft_bounce (no)
Safety net to keep mail queued that would otherwise be returned
to the sender.
BEFORE-POSTSCREEN PROXY AGENT
Available in Postfix version 2.10 and later:
postscreen_upstream_proxy_protocol (empty)
The name of the proxy protocol used by an optional before-
postscreen proxy agent.
postscreen_upstream_proxy_timeout (5s)
The time limit for the proxy protocol specified with the
postscreen_upstream_proxy_protocol parameter.
PERMANENT WHITE/BLACKLIST TEST
This test is executed immediately after a remote SMTP client connects.
If a client is permanently whitelisted, the client will be handed off
immediately to a Postfix SMTP server process.
postscreen_access_list (permit_mynetworks)
Permanent white/blacklist for remote SMTP client IP addresses.
postscreen_blacklist_action (ignore)
The action that postscreen(8) takes when a remote SMTP client is
permanently blacklisted with the postscreen_access_list parame-
ter.
MAIL EXCHANGER POLICY TESTS
When postscreen(8) is configured to monitor all primary and backup MX
addresses, it can refuse to whitelist clients that connect to a backup
MX address only. For small sites, this requires configuring primary and
backup MX addresses on the same MTA. Larger sites would have to share
the postscreen(8) cache between primary and backup MTAs, which would
introduce a common point of failure.
postscreen_whitelist_interfaces (static:all)
A list of local postscreen(8) server IP addresses where a non-
whitelisted remote SMTP client can obtain postscreen(8)'s tempo-
rary whitelist status.
BEFORE 220 GREETING TESTS
These tests are executed before the remote SMTP client receives the
"220 servername" greeting. If no tests remain after the successful com-
pletion of this phase, the client will be handed off immediately to a
Postfix SMTP server process.
dnsblog_service_name (dnsblog)
The name of the dnsblog(8) service entry in master.cf.
postscreen_dnsbl_action (ignore)
The action that postscreen(8) takes when a remote SMTP client's
combined DNSBL score is equal to or greater than a threshold (as
defined with the postscreen_dnsbl_sites and
postscreen_dnsbl_threshold parameters).
postscreen_dnsbl_reply_map (empty)
A mapping from actual DNSBL domain name which includes a secret
password, to the DNSBL domain name that postscreen will reply
with when it rejects mail.
postscreen_dnsbl_sites (empty)
Optional list of DNS white/blacklist domains, filters and weight
factors.
postscreen_dnsbl_threshold (1)
The inclusive lower bound for blocking a remote SMTP client,
based on its combined DNSBL score as defined with the
postscreen_dnsbl_sites parameter.
postscreen_greet_action (ignore)
The action that postscreen(8) takes when a remote SMTP client
speaks before its turn within the time specified with the
postscreen_greet_wait parameter.
postscreen_greet_banner ($smtpd_banner)
The text in the optional "220-text..." server response that
postscreen(8) sends ahead of the real Postfix SMTP server's "220
text..." response, in an attempt to confuse bad SMTP clients so
that they speak before their turn (pre-greet).
postscreen_greet_wait (normal: 6s, overload: 2s)
The amount of time that postscreen(8) will wait for an SMTP
client to send a command before its turn, and for DNS blocklist
lookup results to arrive (default: up to 2 seconds under stress,
up to 6 seconds otherwise).
smtpd_service_name (smtpd)
The internal service that postscreen(8) hands off allowed con-
nections to.
Available in Postfix version 2.11 and later:
postscreen_dnsbl_whitelist_threshold (0)
Allow a remote SMTP client to skip "before" and "after 220
greeting" protocol tests, based on its combined DNSBL score as
defined with the postscreen_dnsbl_sites parameter.
Available in Postfix version 2.11 and later:
postscreen_dnsbl_timeout (10s)
The time limit for DNSBL or DNSWL lookups.
AFTER 220 GREETING TESTS
These tests are executed after the remote SMTP client receives the "220
servername" greeting. If a client passes all tests during this phase,
it will receive a 4XX response to all RCPT TO commands. After the
client reconnects, it will be allowed to talk directly to a Postfix
SMTP server process.
postscreen_bare_newline_action (ignore)
The action that postscreen(8) takes when a remote SMTP client
sends a bare newline character, that is, a newline not preceded
by carriage return.
postscreen_bare_newline_enable (no)
Enable "bare newline" SMTP protocol tests in the postscreen(8)
server.
postscreen_disable_vrfy_command ($disable_vrfy_command)
Disable the SMTP VRFY command in the postscreen(8) daemon.
postscreen_forbidden_commands ($smtpd_forbidden_commands)
List of commands that the postscreen(8) server considers in vio-
lation of the SMTP protocol.
postscreen_helo_required ($smtpd_helo_required)
Require that a remote SMTP client sends HELO or EHLO before com-
mencing a MAIL transaction.
postscreen_non_smtp_command_action (drop)
The action that postscreen(8) takes when a remote SMTP client
sends non-SMTP commands as specified with the postscreen_forbid-
den_commands parameter.
postscreen_non_smtp_command_enable (no)
Enable "non-SMTP command" tests in the postscreen(8) server.
postscreen_pipelining_action (enforce)
The action that postscreen(8) takes when a remote SMTP client
sends multiple commands instead of sending one command and wait-
ing for the server to respond.
postscreen_pipelining_enable (no)
Enable "pipelining" SMTP protocol tests in the postscreen(8)
server.
CACHE CONTROLS
postscreen_cache_cleanup_interval (12h)
The amount of time between postscreen(8) cache cleanup runs.
postscreen_cache_map (btree:$data_directory/postscreen_cache)
Persistent storage for the postscreen(8) server decisions.
postscreen_cache_retention_time (7d)
The amount of time that postscreen(8) will cache an expired tem-
porary whitelist entry before it is removed.
postscreen_bare_newline_ttl (30d)
The amount of time that postscreen(8) will use the result from a
successful "bare newline" SMTP protocol test.
postscreen_dnsbl_ttl (1h)
The amount of time that postscreen(8) will use the result from a
successful DNS blocklist test.
postscreen_greet_ttl (1d)
The amount of time that postscreen(8) will use the result from a
successful PREGREET test.
postscreen_non_smtp_command_ttl (30d)
The amount of time that postscreen(8) will use the result from a
successful "non_smtp_command" SMTP protocol test.
postscreen_pipelining_ttl (30d)
The amount of time that postscreen(8) will use the result from a
successful "pipelining" SMTP protocol test.
RESOURCE CONTROLS
line_length_limit (2048)
Upon input, long lines are chopped up into pieces of at most
this length; upon delivery, long lines are reconstructed.
postscreen_client_connection_count_limit ($smtpd_client_connec-
tion_count_limit)
How many simultaneous connections any remote SMTP client is
allowed to have with the postscreen(8) daemon.
postscreen_command_count_limit (20)
The limit on the total number of commands per SMTP session for
postscreen(8)'s built-in SMTP protocol engine.
postscreen_command_time_limit (normal: 300s, overload: 10s)
The time limit to read an entire command line with
postscreen(8)'s built-in SMTP protocol engine.
postscreen_post_queue_limit ($default_process_limit)
The number of clients that can be waiting for service from a
real Postfix SMTP server process.
postscreen_pre_queue_limit ($default_process_limit)
The number of non-whitelisted clients that can be waiting for a
decision whether they will receive service from a real Postfix
SMTP server process.
postscreen_watchdog_timeout (10s)
How much time a postscreen(8) process may take to respond to a
remote SMTP client command or to perform a cache operation
before it is terminated by a built-in watchdog timer.
STARTTLS CONTROLS
postscreen_tls_security_level ($smtpd_tls_security_level)
The SMTP TLS security level for the postscreen(8) server; when a
non-empty value is specified, this overrides the obsolete param-
eters postscreen_use_tls and postscreen_enforce_tls.
tlsproxy_service_name (tlsproxy)
The name of the tlsproxy(8) service entry in master.cf.
OBSOLETE STARTTLS SUPPORT CONTROLS
These parameters are supported for compatibility with smtpd(8) legacy
parameters.
postscreen_use_tls ($smtpd_use_tls)
Opportunistic TLS: announce STARTTLS support to remote SMTP
clients, but do not require that clients use TLS encryption.
postscreen_enforce_tls ($smtpd_enforce_tls)
Mandatory TLS: announce STARTTLS support to remote SMTP clients,
and require that clients use TLS encryption.
MISCELLANEOUS CONTROLS
config_directory (see 'postconf -d' output)
The default location of the Postfix main.cf and master.cf con-
figuration files.
delay_logging_resolution_limit (2)
The maximal number of digits after the decimal point when log-
ging sub-second delay values.
command_directory (see 'postconf -d' output)
The location of all postfix administrative commands.
max_idle (100s)
The maximum amount of time that an idle Postfix daemon process
waits for an incoming connection before terminating voluntarily.
process_id (read-only)
The process ID of a Postfix command or daemon process.
process_name (read-only)
The process name of a Postfix command or daemon process.
syslog_facility (mail)
The syslog facility of Postfix logging.
syslog_name (see 'postconf -d' output)
The mail system name that is prepended to the process name in
syslog records, so that "smtpd" becomes, for example, "post-
fix/smtpd".
SEE ALSO
smtpd(8), Postfix SMTP server
tlsproxy(8), Postfix TLS proxy server
dnsblog(8), DNS black/whitelist logger
syslogd(8), system logging
README FILES
POSTSCREEN_README, Postfix Postscreen Howto
LICENSE
The Secure Mailer license must be distributed with this software.
HISTORY
This service was introduced with Postfix version 2.8.
Many ideas in postscreen(8) were explored in earlier work by Michael
Tokarev, in OpenBSD spamd, and in MailChannels Traffic Control.
AUTHOR(S)
Wietse Venema
IBM T.J. Watson Research
P.O. Box 704
Yorktown Heights, NY 10598, USA
POSTSCREEN(8)
Testscenarien mit Konfigurationsbeispielen
Im Folgendem wollen wir uns die einzelnen Test einmal genauer betrachten und anschließend unsere individuelle Konfiguration für unseren Postfix SMTP-Mailserver erstellen. Hierzu legen wir uns z.B. am Ende unserer /etc/postfix/main.cf eine neue Section POSTSCREEN - ERSTE STUFE DER SPAM/UCE/VIREN-ABWEHRMECHANISMEN an.
# vim /etc/postfix/main.cf
... ################################################################################ ## POSTSCREEN - ERSTE STUFE DER SPAM/UCE/VIREN-ABWEHRMECHANISMEN #
erste Schnelltests
black- & whitelist
Einen der ersten Tests, die postscreen anstellt ist die Prüfung der Clien-IP-Adresse auf Eintrag eines Eintrags in der Black-/White-Liste. Der Konfigurationsparameter hierzu lautet postscreen_access_list.
Wir tragen also einen Eintrag in unserer neuen Section POSTSCREEN - ERSTE STUFE DER SPAM/UCE/VIREN-ABWEHRMECHANISMEN hierzu ein.
# vim /etc/postfix/main.cf
# Django : 2014-10-29 - PERMANENT WHITE/BLACKLIST TEST
# default: postscreen_access_list = permit_mynetworks
postscreen_access_list = permit_mynetworks
cidr:/etc/postfix/postscreen_white-blacklist
Wir haben hier also alle Hosts aus mynetworks und eine zusätzliche cidr-Tabelle /etc/postfix/postscreen_whitelist definiert.
Diese Datei legen wir gleich mal als nächstes an.
# vim /etc/postfix/postscreen_whitelist
- /etc/postfix/postscreen_white-blacklist
# Django : 2014-10-29 # access-Tabelle: Wer wird von postscreen ausgenommen und wer nicht? # Tabelle zum black- und whitelisten einzelner Hosts auf Basis ihrer # IP-Adressen. In der rechten Tabellenspalte können die Aktionen # "permit", "reject" und "dunno" gesetzt werden. # Nach dem Ändern und/oder Erweitern der Tabelle, muss ein # laufender Postfix über die Änderungen mit einem reload informiert # werden: # $ systemctl reload postfix.service # # Es muss hier keine Datenbank mit postmap erzeugt werden, da # Postfix die ASCII-Konfigurationsdatei direkt auswertet! # 88.217.171.167/32 permit 192.168.2.0/24 dunno 213.183.2.247/32 reject 213.183.9.35/32 reject
In der rechten Tabellenspalte können folgende drei Aktionen gesetzt werden:
permitEs werden keine weiteren postscreen-Test durchgeführt. Die Verbindung wird sofort an einen SMTP-Daemon weitergereicht.dunnoNichts weiter unternehmen und Client zum nächsten Test weiterreichen.rejectClient blacklisten und weitere Suche in der Tabelle beenden. Abhängig vom Parameter postscreen_blacklist_action mit der weiteren Bearbeitung der Clientverbindung verfahren.
Den Parameter postscreen_blacklist_action definieren wir nun als nächsten.
# vim /etc/postfix/main.cf
# default: postscreen_blacklist_action = ignore postscreen_blacklist_action = drop
Hier stehen uns drei Aktionen zur Verfügung:
ignoreNichts unternehmen und mit weiteren Tests fortfahren. Bei der nächsten Clientverbindung mit der gleichen IP ebenso verfahren.enforceWeitermachen mit den anderen Tests, jedoch am Ende die Verbindung mit einem SMTP-Fehlercode 550 abschließen. Die Informationen HELO, SENDER und EMPFÄNGER werden gelogged. Bei der nächsten Clientverbindung mit der gleichen IP ebenso verfahren.dropDie Verbindung sofort mit einem SMTP-Fehlercode 521 beenden. Bei der nächsten Clientverbindung mit der gleichen IP ebenso verfahren.
Natürlich kann die Pflege von einzelnen Systemen zu einer sehr zeitaufwändigen Arbeit ausarten, vor allem dann wenn Versendende Systeme großer Mailprovider oder besonderer geclusteter Mailserver zum Einsatz kommen. Werden Mails von Servern unterschiedlicher abwechselnd von unterschiedlichen Mailrelays mit unterschiedlichen IP-Adresssen verschickt, wird die Nutzung von Postscreen so ad absurdum geführt, insbesondere dann wenn man die Post 220 SMTP Server Greeting Tests nutzen möchte.
Eine manuelle Pflege der postscreen_access_list ist hier nicht mehr praxisgerecht. Statt nun auf die Nutzung der Funktion postscreen_access_list zu verzichten, ist die Nutzung einer automatisch gepflegten Access-Liste mit Hilfe von postwhite vorzuziehen!
temporäre whitelist
Als nächstes prüft postscreen, ob der Client einen temporären Whitelisting Eintrag hat; d.h. hat der Client früher schon einmal einen postscreen-Test positiv abgeschlossen.
Will man selbst einen Blick in die temporäre whitelist-Datenbank werfen, so muss man erst mal den Postfix-Daemon stoppen.
# systemctl stop postfix.service
Anschließend kann man mit Hilfe des Befehls postmap einen Blick in die Datenbank werfen.
# postmap -s btree:/var/lib/postfix/postscreen_cache
103.25.223.73 1415110281;1415031447;1417615882;1417615882;1417615882 104.43.131.15 1415281935;1415199135;1417787536;1417787536;1417787536 107.170.40.75 1415400834;1415318034;1417906434;1417906434;1417906434 108.163.243.186 1415369879;1415287079;1417875480;1417875480;1417875480 ...
Neben den IP-Adressen findet man dort jede Menge Timestamps, die jedoch nur Postfixintern zu Anwendung kommen und auch sonst nicht weiter von Belang sind.
MX Policy Test
Es ist kein großes Geheimnis, dass SPAMer die im DNS hinterlegten Prioritäten gerne ignorieren und bevorzugt den Backup MX ansprechen. Dies machen sie in der Hoffnung, der Backup MX ist eventuell schlechter gepflegt als der primäre MX.
Der dritte Test, den postscreen anstellt überprüft nun genau, dieses absondere Verhalten dieser Zombie-Clients zu prüfen.
Hat man nur einen MX mit nur einer IP, dann kann man die Standardkonfigurationsoption, die postscreen mitbringt, getrost beibehalten und diesen Test somit überspringen!
Mit der Option postscreen_whitelist_interfaces kann man definieren, auf welchen Interfaces/IP-Adressen das automatische Setzen der Whitelist aktiviert und eben deaktiviert werden soll. Die eben angesprochene Standardoption zeigt auf static:all, also auf alle zur verfügung stehenden IP-Adressen.
Wenn wir nun eine weitere IP-Adresse auf unserem Mailserver binden und im DNS als Backup-MX definieren, können wir quasi einen Pseudo-Backup-MX mimen. Schlägt dann ein Client immer nur bzw. zuerst auf der IP-Adresse des definierten Backup-MX auf, dann ist dies höchstwahrscheinlich ein SPAM-Bot. Solch einen Client wollen wir definitiv nicht vertrauen, sondern diesen immer durch alle Postscreen-Test schicken. Dies erreichen wir mit folgender Konfigurationsoptiom, die wir nun in der Sektion POSTSCREEN - ERSTE STUFE DER SPAM/UCE/VIREN-ABWEHRMECHANISMEN anfügen.
# vim /etc/postfix/main.cf
... # Django : 2014-10-29 - MAIL EXCHANGER POLICY TESTS # default: postscreen_whitelist_interfaces = static:all postscreen_whitelist_interfaces = !88.217.171.167 static:all
Der Eintrag definiert nun, dass das Eintragen in die automatische temporäre Whitelist auf allen IP-Adressen/Interfaces erfolgen soll, aber nicht auf der IP-Adresse 88.217.171.167!
WICHTIG:
Das klapp natürlich nur, wenn der alle postscreen-Prozesse von einem master-Daemon gesteuert werden! Möchte man zwischen mehreren Mailservern die temporäre Whitelist sharen, sind zusätzliche Konfigurationsmaßnahmen notwendig!
Konfigurationsbeispiel
- memcached installieren, konfigurieren und starten.
# yum install memcached -y
# vim /etc/sysconfig/memcached
# systemctl start memcached
- Auf jeden MX-Host in der /etc/postfix/main.cf eintragen unter der Section POSTSCREEN - ERSTE STUFE DER SPAM/UCE/VIREN-ABWEHRMECHANISMEN :
postscreen_cache_map = memcache:/etc/postfix/postscreen_cache proxy_write_maps = proxy:btree:/var/lib/postfix/postscreen_cache
Ferner legen wir die zusätzliche Konfigurationsdatei /etc/postfix/postscreen_cache an.
# Django : 2014-11-07 postscreen-cache Konfigurationsdatei # memcache = inet:217.91.103.190:11211 backup = proxy:btree:/var/lib/postfix/postscreen_cache key_format = postscreen:%sAnschließend führen wir einen Reload des Postfix-Masterdaemon durch.
# systemctl reload postfix
Nach diesen ersten Schnelltests für der Postscreen-Daemon noch weitere Tests aus, die man in zwei Gruppen einteilen kann, die wir uns nun noch ansehen und konfigurieren werden.
"Pre 220 SMTP Server Greeting" Tests
Die zweite Gruppe an Tests führt Postscreen aus, noch bevor der SMTP-Daemon die initiale Begrüßung „220 … ESMTP Postfix“ an den Client sendet. Die kurze Verzögerung, meist im Bereich von Sekunden, wird über den Parameter postscreen_greet_wait gesteuert. Besteht der Client diese Vor „220 SMTP Server Greeting“ Tests, erhält der Client einen Eintrag in der temp. whitelisting Tabelle und die aktuelle Verbindung wird vom postscreen-Daemon sofort an einen SMTP-Daemon weitergereicht, der mit der weiteren Annahme und Bewertung der Sendung fortfahren kann.
Dies erfolgt aber nur wenn keine weiteren Nach „220 SMTP Server Greeting“ Tests definiert und aktiviert wurden!
Pregreet Test
Beim ersten Test in dieser Kategorie macht sich postscreen eine weitere Eigenschaft von SPAM-Bots/-Zombies zu nutze. Diese missachten nämlich die RFC-Konformität und versuchen sofort nach der ersten Meldung des Servers, ihren Müll abzuliefern. Der postscreen Daemon sendet erst einmal eine nicht RFC-konformen greeter. Bsp.:
220-mx01.nausch.org ESMTP Postfix
Dann wartet der Server die mit Paramater postscreen_greet_wait definierte Zeit ab und sendet dann erst den richtigen greeter.
220 mx01.nausch.org ESMTP Postfix
Erst hier beginnt ein ordnungsgemäßer konfigurierter Mailserver/Client mit dem Dialog. SPAM-Bots/-Zombies hingegen legen meist sofort los und senden nach der ersten Zeile bereits ihren HELO/EHLO, schließlich wollen diese ja in der kurzen Zeit bist die IP-Adresse auf einer Blocklist landet, möglichst viel SPAM versenden. Der postscreen Daemon erkennt dies und führt abhängig vom Parameter postscreen_greet_action die gewählte Aktion aus:
ignoreNichts unternehmen und mit weiteren Tests fortfahren. Bei der nächsten Clientverbindung mit der gleichen IP ebenso verfahren.enforceWeitermachen mit den anderen Tests, jedoch am Ende die Verbindung mit einem SMTP-Fehlercode 550 abschließen. Die Informationen HELO, SENDER und EMPFÄNGER werden gelogged. Bei der nächsten Clientverbindung mit der gleichen IP ebenso verfahren.dropDie Verbindung sofort mit einem SMTP-Fehlercode 521 beenden. Bei der nächsten Clientverbindung mit der gleichen IP ebenso verfahren.
DNSBL-Abfragen und DNSWL-Abfragen
Parallel zu diesem Test, kann der postscreen Daemon bereits mit der Client-IP-Adresse eine oder mehrere Blocklisting-Server oder auch Whitelist-Server befragen. Ähnlich wie mit dem Daemon policyd-weight kann man hier einzelnen Listen eine unterschiedliche Gewichtung zuweisen und so gezielter ein Ergebnis über „hopp“ oder „top“ erlangen. Die Definition der gewählten Listen erfolgt über den Parameter postscreen_dnsbl_sites. Wir ergänzen also die Section POSTSCREEN - ERSTE STUFE DER SPAM/UCE/VIREN-ABWEHRMECHANISMEN mit den von uns gewählten Listen ein.
# vim /etc/postfix/main.cf
... # Django : 2014-10-29 - BEFORE 220 GREETING TESTS # default: postscreen_dnsbl_threshold = 1 postscreen_dnsbl_threshold = 2 # # default: postscreen_dnsbl_sites = postscreen_dnsbl_sites = zen.spamhaus.org*2 bl.spamcop.net*1 b.barracudacentral.org*1
Nutzt man auf Grund der Verwendung bzw. des Mailaufkommens sich eine SPAMHAUS DNSBL Lizenz, trägt man diesen Lizenzstring entsprechend mit an. Bsp:
postscreen_dnsbl_sites = <individueller-spamhaus-lizenzkey>.zen.spamhaus.org*2 bl.spamcop.net*1 b.barracudacentral.org*1
Damit nun der postscreen-Daemon beim Blocken mit einem 550er Returncode nicht den Lizenzkey <individueller-spamhaus-lizenzkey>.zen.spamhaus.org mitmeldet, müssen wir die Rückmeldung entsprechend „kastrieren“. Wir tragen hierzu in unserer Postscreen-Konfiguration noch folgende Zeile nach.
# vim /etc/postfix/main.cf
... postscreen_dnsbl_sites = <individueller-spamhaus-lizenzkey>.zen.spamhaus.org*2 bl.spamcop.net*1 b.barracudacentral.org*1 # Django : 2014-11-08 Blocklist-Rückmeldung maskieren # default: postscreen_dnsbl_reply_map = postscreen_dnsbl_reply_map = texthash:/etc/postfix/dnsbl_reply
Anschließend legen wir uns noch diese Mapping-Tabelle an.
# vim /etc/postfix/dnsbl_reply
# Django : 2014-11-08 550er DNSBL Rückmeldung verstecken <individueller-spamhaus-lizenzkey>.zen.spamhaus.org zen.spamhaus.org
Der Parameter postscreen_dnsbl_threshold legt fest, ab welcher Punktezahl, in unserem Konfigurationsbeispiel also beim Erreichen des Wertes 2, der postscreen-Daemon tätig werden soll. Dabei stehen uns folgende Aktionen zur Verfügung:
ignoreNichts unternehmen und mit weiteren Tests fortfahren. Bei der nächsten Clientverbindung mit der gleichen IP ebenso verfahren.enforceWeitermachen mit den anderen Tests, jedoch am Ende die Verbindung mit einem SMTP-Fehlercode 550 abschliessen. Die Informationen HELO, SENDER und EMPFÄNGER werden gelogged. Bei der nächsten Clientverbindung mit der gleichen IP ebenso verfahren.dropDie Verbindung sofort mit einem SMTP-Fehlercode 521 beenden. Bei der nächsten Clientverbindung mit der gleichen IP ebenso verfahren.
"Post 220 SMTP Server Greeting" Tests
In der dritten und letzten Phase kann postscreen mit seiner internen SMTP-Engine sog. deep protocol Tests anstellen. Diese Tests sind weitaus tiefer gehender im SMTP-Protokoll und unterscheiden sich damit wesentlich von den „Pre 220 SMTP Server Greeting-“ und den DNSBL-Tests. Eine wesentliche Einschränkung gibt es bei den „Post 220 SMTP Server Greeting“ Tests, der nicht verschwiegen werden sollte. Ein bisher unbekannter Client muss nach dem erfolgreichen Bestehen der Tests erneut mit dem MX verbinden, da der postscreen-Daemon den bestehenden und bereits begonnenen SMTP-Dialog nicht an einen „richtige“ SMTP-Daemon weiterreichen kann. Postscreen ist kein SMTP-Proxy! Daher muss sich der Client, erneut und hoffentlich mit der gleichen IP-Adresse erneut melden, was natürlich zu einer gewissen Verzögerung bei der Mailannahme führen kann und wird.
Damit es nicht zu unnötigen Verzögerungen kommt, sind folgende Maßnahmen sehr hilfreich:
- Whitelisting: Bekannte und vertrauenswürdige Absender, die mit verschiedenen IP-Adressen beim Versenden operieren, am besten mit Hilfe des postscreen_dnsbl_whitelist_threshold's die „Pre 220 SMTP Server Greeting-“ und „Post 220 SMTP Server Greeting“ Tests überspringen lassen.
- Multihome-MX: Hat man nur einen Mailserver, so kann man sich mit folgendem Trick behelfen. Der Mailserver bekommt eine zweite IP-Adresse, die über das DNS als Backup-MX, also mit einer höheren Priorität versehen, veröffentlicht wird. So erhöht man die Rückkehrerquote, ähnlich wie bereits beim Konfigurationsparameter postscreen_whitelist_interfaces.
- cache-sharing: Bei größeren Installationen mit Hilfe von memcached unbedingt die caching-Daten mit einer groß bemessenen memcache_table teilen! Deteils hierzu sind bereits beim Punkt MX Policy Test beschrieben.
- 25: die SMTP-Engine von Postscreen unterstützt weder AUTH, XCLIENT noch XFORWARD Funktionen! Werden diese Funktionen auf Port 25 benötigt, dann scheidet der Einsatz der „Post 220 SMTP Server Greeting“-Tests leider aus.
- Submission: MUAs wird ausschließlich der Submisssion-port 587 zum Einliefern der Nachrichten angeboten. So können diese gezielt die postscreen Tests umgehen.
Stellt man auf produktiv im Einsatz befindlichen Mailservern den zusätzlichen Gewinn bei der SPAM-Abwehr durch Nutzung der "Post 220 SMTP Server Greeting" Tests ins Verhältnis zu auftretenden Mailverzögerungen, muss man sich natürlich die Frage stellen, ob hier noch der Aufwand lohnt.
In den seltensten Fällen wird man daher wirklich diese Funktion nutzen wollen!
Wir tragen also einen Eintrag in unserer neuen Section POSTSCREEN - ERSTE STUFE DER SPAM/UCE/VIREN-ABWEHRMECHANISMEN hierzu ein.
# vim /etc/postfix/main.cf
# Django : 2014-10-29 # default: postscreen_dnsbl_whitelist_threshold = 0 postscreen_dnsbl_whitelist_threshold = -1
"Command Pipelining" Tests
Standardmäßig ist ein SMTP-Halbduplex-Protokoll, d.h. der Sender wie auch der Empfänger sendet immer einen Befehl ein Befehl bzw. eine Antwort und wartet dann auf eine Bestätigung/Antwort von der Gegenseite. Die Postscreen interne SMTP-Engine unterdrückt das ESMTP-Kommando Pipelining; d.h. Pipelining wird nicht angeboten. Setzt man nun die Option postscreen_pipelining_enable = yes, so erkennt postscreen Mail-Zombies, die Protokollwidrig trotzdem versuchen mehrere befehle auf einmal zu senden.
Wir tragen also einen Eintrag in unserer neuen Section POSTSCREEN - ERSTE STUFE DER SPAM/UCE/VIREN-ABWEHRMECHANISMEN hierzu ein.
# vim /etc/postfix/main.cf
# Django : 2014-10-29 # default: postscreen_pipelining_enable = no postscreen_pipelining_enable = yes
Folgende Aktionen stehen uns bei positiven Testergebnis zur Verfügung:
ignoreNichts unternehmen und mit weiteren Tests fortfahren. Bei der nächsten Clientverbindung mit der gleichen IP ebenso verfahren.enforceWeitermachen mit den anderen Tests, jedoch am Ende die Verbindung mit einem SMTP-Fehlercode 550 abschließen. Die Informationen HELO, SENDER und EMPFÄNGER werden gelogged. Bei der nächsten Clientverbindung mit der gleichen IP ebenso verfahren.dropDie Verbindung sofort mit einem SMTP-Fehlercode 521 beenden. Bei der nächsten Clientverbindung mit der gleichen IP ebenso verfahren.
"Non-SMTP Command" Tests
Ein weitere Protokollanomalie von SPAM-Bots ist die Verwendung von SMTP-Befehlen oder besser gesagt von nicht SMTP-Befehlen, wie z.B. connect oder exit. Der Postscreen-Daemon greift dabei standardmäßig auf die gleichen verbotenen SMTP-Befehle zurück, wie die der SMTP-Daemons.
Setzt man die Konfigurationsoption postscreen_non_smtp_command_enable = yes erkennt postscreen diese Protokollverstöße und kann entsprechend tätig werden.
Wir tragen also einen Eintrag in unserer neuen Section POSTSCREEN - ERSTE STUFE DER SPAM/UCE/VIREN-ABWEHRMECHANISMEN hierzu ein.
# vim /etc/postfix/main.cf
# Django : 2014-10-29 #postscreen_non_smtp_command_enable = no postscreen_non_smtp_command_enable = yes
Folgende Aktionen stehen uns bei positiven Testergebnis zur Verfügung:
ignoreNichts unternehmen und mit weiteren Tests fortfahren. Bei der nächsten Clientverbindung mit der gleichen IP ebenso verfahren.enforceWeitermachen mit den anderen Tests, jedoch am Ende die Verbindung mit einem SMTP-Fehlercode 550 abschließen. Die Informationen HELO, SENDER und EMPFÄNGER werden gelogged. Bei der nächsten Clientverbindung mit der gleichen IP ebenso verfahren.dropDie Verbindung sofort mit einem SMTP-Fehlercode 521 beenden. Bei der nächsten Clientverbindung mit der gleichen IP ebenso verfahren.
"Bare Newline" Tests
SMTP ist eine zeilenorientierte Protokoll, d.h. jede gesendete Zeile hat eine begrenzte Länge und wird mit <CR> <LF> abgeschlossen. Zeile, die nur mit einem <LF>, also einem fehlenden <CR>, abgeschlossen sind, sind laut dem SMTP-Protokoll nicht erlaubt. Viele SPAM-Bots machen aber gerade diese Protokollverstöße. Somit kann Postscreen diese Protokollanomalie erkennen und ja nach Konfiguration eine Entscheidung treffen.
Wir tragen also einen Eintrag in unserer neuen Section POSTSCREEN - ERSTE STUFE DER SPAM/UCE/VIREN-ABWEHRMECHANISMEN hierzu ein.
# vim /etc/postfix/main.cf
# Django : 2014-10-29 # default: postscreen_bare_newline_enable = no postscreen_bare_newline_enable = yes # default: postscreen_bare_newline_action = ignore postscreen_bare_newline_action = drop
Folgende Aktionen stehen uns bei positiven Testergebnis zur Verfügung:
ignoreNichts unternehmen und mit weiteren Tests fortfahren. Bei der nächsten Clientverbindung mit der gleichen IP ebenso verfahren.enforceWeitermachen mit den anderen Tests, jedoch am Ende die Verbindung mit einem SMTP-Fehlercode 550 abschliessen. Die Informationen HELO, SENDER und EMPFÄNGER werden gelogged. Bei der nächsten Clientverbindung mit der gleichen IP ebenso verfahren.dropDie Verbindung sofort mit einem SMTP-Fehlercode 521 beenden. Bei der nächsten Clientverbindung mit der gleichen IP ebenso verfahren.
gesamte Konfiguration
main.cf
Im Gesamten ergibt sich nun folgende Section POSTSCREEN - ERSTE STUFE DER SPAM/UCE/VIREN-ABWEHRMECHANISMEN in unserer Konfigurationsdatei /etc/postfix/main.cf
... ################################################################################ ## POSTSCREEN - ERSTE STUFE DER SPAM/UCE/VIREN-ABWEHRMECHANISMEN # # Django : 2014-10-29 - PERMANENT WHITE/BLACKLIST TEST # default: postscreen_access_list = permit_mynetworks postscreen_access_list = permit_mynetworks cidr:/etc/postfix/postscreen_whitelist # # default: postscreen_blacklist_action = ignore postscreen_blacklist_action = drop # Django : 2014-10-29 - MAIL EXCHANGER POLICY TESTS # default: postscreen_whitelist_interfaces = static:all postscreen_whitelist_interfaces = !88.217.171.167 static:all # Django : 2014-10-29 - PRE 220 GREETING TESTS # # default: postscreen_greet_banner = $smtpd_banner # # default: postscreen_greet_action = ignore postscreen_greet_action = enforce # default: postscreen_dnsbl_threshold = 1 postscreen_dnsbl_threshold = 2 # # default: postscreen_dnsbl_sites = postscreen_dnsbl_sites = zen.spamhaus.org*2 bl.spamcop.net*1 b.barracudacentral.org*1 #swl.spamhaus.org*2 # # default: postscreen_dnsbl_action = ignore postscreen_dnsbl_action = enforce # Django : 2014-10-29 - POST 220 GREETING TESTS # # default: postscreen_dnsbl_whitelist_threshold = 0 postscreen_dnsbl_whitelist_threshold = -1 # # default: postscreen_pipelining_enable = no # # default: postscreen_pipelining_action = enforce # # default: postscreen_non_smtp_command_enable = no # # default: postscreen_non_smtp_command_action = drop # # default: postscreen_bare_newline_enable = no # # default: postscreen_bare_newline_action = ignore #
master.cf
Zum Aktivieren unseres Postscreen-Daemon aktivieren wir nun den bereits vorgesehenen Eintrag zu Postscreen bzw. tragen diese nach:
# vim /etc/postfix/master.cf
# # Postfix master process configuration file. For details on the format # of the file, see the master(5) manual page (command: "man 5 master"). # # Do not forget to execute "postfix reload" after editing this file. # # ========================================================================== # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (yes) (never) (100) # ========================================================================== # # Django : 2014-10-29 postscreen # smtp inet n - n - 1 postscreen smtpd pass - - n - - smtpd -o smtpd_sasl_auth_enable=no dnsblog unix - - n - 0 dnsblog tlsproxy unix - - n - 0 tlsproxy ...
Aktivierung
Zur Aktivierung unserer Konfigurationsänderungen führen wir nun noch einen Restart des Postfix-Master DAemon durch.
# systemctl restart postfix
Den Serverstatus können wir uns nun mit Hilfe des folgenden Aufrufes anzeigen lassen.
# systemctl status postfix
● postfix.service - Postfix Mail Transport Agent
Loaded: loaded (/usr/lib/systemd/system/postfix.service; enabled; vendor preset: disabled)
Active: active (running) since Mon 2014-11-10 20:57:24 CET; 18s ago
Process: 15133 ExecStop=/usr/sbin/postfix stop (code=exited, status=0/SUCCESS)
Process: 15148 ExecStart=/usr/sbin/postfix start (code=exited, status=0/SUCCESS)
Process: 15146 ExecStartPre=/usr/libexec/postfix/chroot-update (code=exited, status=0/SUCCESS)
Process: 15143 ExecStartPre=/usr/libexec/postfix/aliasesdb (code=exited, status=0/SUCCESS)
Main PID: 15221 (master)
CGroup: /system.slice/postfix.service
├─15221 /usr/libexec/postfix/master -w
├─15222 pickup -l -t unix -u
└─15223 qmgr -l -t unix -u
Nov 10 20:57:23 vml000087.dmz.nausch.org systemd[1]: Starting Postfix Mail Transport Agent...
Nov 10 20:57:24 vml000087.dmz.nausch.org postfix/master[15221]: daemon started -- version 2.11.3, configuration /etc/postfix
Nov 10 20:57:24 vml000087.dmz.nausch.org systemd[1]: Started Postfix Mail Transport Agent.
Bewertungsbeispiele
Pass New
Folgender Auszug aus einem Maillog zeigt einen neuen Client der alle Tests bestanden hat.
Nov 8 06:39:36 vml000080 postfix/postscreen[12580]: CONNECT from [66.220.144.178]:27747 to [10.0.0.80]:25 Nov 8 06:39:42 vml000080 postfix/postscreen[12580]: [66.220.144.178]27747: discarding EHLO keywords: DSN Nov 8 06:39:43 vml000080 postfix/postscreen[12580]: [66.220.144.178]27747: discarding EHLO keywords: DSN Nov 8 06:39:44 vml000080 postfix/postscreen[12580]: NOQUEUE: reject: RCPT from [66.220.144.178]:27747: 450 4.3.2 Service currently unavailable; from=<postmaster@facebookmail.com>, to=<dmarc-reports@nausch.org>, proto=ESMTP, helo=<mx-out.facebook.com> Nov 8 06:39:49 vml000080 postfix/postscreen[12580]: PASS NEW [66.220.144.178]:27747 Nov 8 06:39:49 vml000080 postfix/postscreen[12580]: DISCONNECT [66.220.144.178]:27747
Reconnect
Folgender Auszug aus einem Maillog zeigt einen Reconnect eines bereits bekannten Client.
Nov 8 16:24:29 vml000080 postfix/postscreen[23895]: CONNECT from [88.198.212.215]:49376 to [10.0.0.80]:25 Nov 8 16:24:29 vml000080 postfix/postscreen[23895]: PASS OLD [88.198.212.215]:49376
Pregreet und DNSBL
Im folgendem Beispiel sehen wir gleich zwei Ergebnisse. Zum Einen hat der Client nicht abgewartet bis zum vollständigen Begrüßungscode und zum anderen wurde der Schwellwert für die gewichtete DNSBL von 2 erreicht.
Nov 8 16:21:50 vml000080 postfix/postscreen[23895]: CONNECT from [36.224.135.17]:1900 to [10.0.0.80]:25 Nov 8 16:21:50 vml000080 postfix/postscreen[23895]: PREGREET 21 after 0.35 from [36.224.135.17]:1900: HELO 217.91.103.190\r\n Nov 8 16:21:50 vml000080 postfix/postscreen[23895]: DNSBL rank 2 for [36.224.135.17]:1900 Nov 8 16:21:51 vml000080 postfix/postscreen[23895]: NOQUEUE: reject: RCPT from [36.224.135.17]:1900: 550 5.7.1 Service unavailable; client [36.224.135.17] blocked using zen.spamhaus.org; from=<z2007tw@yahoo.com.tw>, to=<vkihwpdh@yahoo.com.tw>, proto=SMTP, helo=<217.91.103.190> Nov 8 16:21:51 vml000080 postfix/postscreen[23895]: HANGUP after 1 from [36.224.135.17]:1900 in tests after SMTP handshake Nov 8 16:21:51 vml000080 postfix/postscreen[23895]: DISCONNECT [36.224.135.17]:1900
Pregreet und COMMAND COUNT LIMIT
Bei folgendem Beispiel sehen wir wiederum einen Preegreet-Verstoß. Weiterhin sehen wir eine Überschreitung beim eingestellten postscreen_command_count_limit von 20.
Nov 3 17:20:10 vml000080 postfix/postscreen[7924]: CONNECT from [50.31.146.101]:46294 to [10.0.0.80]:25 Nov 3 17:20:10 vml000080 postfix/postscreen[7924]: PREGREET 21 after 0.14 from [50.31.146.101]:46294: HELO vps.w21099.com\r\n Nov 3 17:20:11 vml000080 postfix/postscreen[7924]: NOQUEUE: reject: RCPT from [50.31.146.101]:46294: 550 5.5.1 Protocol error; from=<stamina07@tiscali.it>, to=<hotmabox@yahoo.com>, proto=SMTP, helo=<vps.w21099.com> Nov 3 17:20:11 vml000080 postfix/postscreen[7924]: NOQUEUE: reject: RCPT from [50.31.146.101]:46294: 550 5.5.1 Protocol error; from=<stamina07@tiscali.it>, to=<hotmabox@yahoo.com>, proto=SMTP, helo=<vps.w21099.com> Nov 3 17:20:12 vml000080 postfix/postscreen[7924]: NOQUEUE: reject: RCPT from [50.31.146.101]:46294: 550 5.5.1 Protocol error; from=<stamina07@tiscali.it>, to=<hotmabox@hotmail.com>, proto=SMTP, helo=<vps.w21099.com> Nov 3 17:20:12 vml000080 postfix/postscreen[7924]: NOQUEUE: reject: RCPT from [50.31.146.101]:46294: 550 5.5.1 Protocol error; from=<stamina07@tiscali.it>, to=<hotmabox@hotmail.com>, proto=SMTP, helo=<vps.w21099.com> Nov 3 17:20:13 vml000080 postfix/postscreen[7924]: NOQUEUE: reject: RCPT from [50.31.146.101]:46294: 550 5.5.1 Protocol error; from=<stamina07@tiscali.it>, to=<goomabox@gmail.com>, proto=SMTP, helo=<vps.w21099.com> Nov 3 17:20:13 vml000080 postfix/postscreen[7924]: NOQUEUE: reject: RCPT from [50.31.146.101]:46294: 550 5.5.1 Protocol error; from=<stamina07@tiscali.it>, to=<goomabox@gmail.com>, proto=SMTP, helo=<vps.w21099.com> Nov 3 17:20:13 vml000080 postfix/postscreen[7924]: COMMAND COUNT LIMIT from [50.31.146.101]:46294 after MAIL Nov 3 17:20:13 vml000080 postfix/postscreen[7924]: DISCONNECT [50.31.146.101]:46294
BARE NEWLINE
Beim letzten Logging-Beispiel sehen wir, dass der Postscreen-Daemon bei einer bestehenden TLS-Session einen Bare Newline Verstoß entdeckt hatte.
Nov 9 17:59:25 vml000080 postfix/tlsproxy[1654]: CONNECT from [85.199.49.140]:40225 Nov 9 17:59:26 vml000080 postfix/tlsproxy[1654]: Anonymous TLS connection established from [85.199.49.140]:40225: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Nov 9 17:59:58 vml000080 postfix/postscreen[1144]: BARE NEWLINE from [85.199.49.140]:40225 after quit Nov 9 17:59:58 vml000080 postfix/postscreen[1144]: DISCONNECT [85.199.49.140]:40225 Nov 9 17:59:58 vml000080 postfix/tlsproxy[1654]: DISCONNECT [85.199.49.140]:40225
weitere Beispiele
Weitere Beispiele zu Postscreen und dessen Loggingfunktionalitäten findet man auf der Seite von Wietse Venema.
graphische Statistiken Postscreen
Will man sich einen generellen Überblick über die Postscreen-Auswirkungen beim Mailverkehr informieren, greift man am besten auf Mailgraph-NG zurück.
postwhite
Natürlich kann die Pflege von einzelnen Systemen zu einer sehr zeitaufwändigen Arbeit ausarten, vor allem dann wenn versendende Systeme großer Mailprovider oder besonderer geclusteter Mailserver zum Einsatz kommen. Werden Mails von Servern unterschiedlicher abwechselnd von unterschiedlichen Mailrelays mit unterschiedlichen IP-Adresssen verschickt, wird die Nutzung der black- & whitelist Tests von Postscreen so ad absurdum geführt, insbesondere dann wenn man die Post 220 SMTP Server Greeting Tests nutzen möchte.
Eine manuelle Pflege der postscreen_access_list ist hier nicht mehr praxisgerecht. Statt nun auf die Nutzung der Funktion postscreen_access_list gänzlich zu verzichten, ist die Nutzung einer automatisch gepflegten Access-Liste mit Hilfe von postwhite2) vorzuziehen!
Stellt man auf produktiv im Einsatz befindlichen Mailservern den zusätzlichen Gewinn bei der SPAM-Abwehr durch Nutzung der "Post 220 SMTP Server Greeting" Tests ins Verhältnis zu auftretenden Mailverzögerungen, muss man sich natürlich die Frage stellen, ob hier noch der Aufwand lohnt.
In den seltensten Fällen wird man daher wirklich diese Funktion nutzen wollen!
Installation
Mit Hilfe des Projekts Postwhite - Automatic Postcreen Whitelist & Blacklist Generator von Steve Jenkins ist es möglich automatisiert eine Whitelist-Tabelle erstellen und aktualisieren zu lassen.
Postwhite selbst greift wiederum auf SPF-tools zurück. Wir werden also zunächst SPF-tools auf unseren Server holen. Wir wechseln dazu erst einmal in unser locales SRC-Verzeichnis.
# cd /usr/local/src
Nun clonen wir das Projekt direkt von GITHUB-Server.
# git clone https://github.com/spf-tools/spf-tools.git
Anschließend clonen wir das Projekt Postwhite.
# git clone https://github.com/stevejenkins/postwhite.git
Damit wir später postwhite einfach starten können verlinken wir das zugehörige binary nach /usr/local/bin/.
# ln -s /usr/local/src/postwhite/postwhite /usr/local/bin/postwhite # ln -s /usr/local/src/postwhite/scrape_yahoo /usr/local/bin/scrape_yahoo
Konfiguration
Postwhite
Für die Konfiguration von postwhite finden wir in dem geclonten Projektordner eine vorgefertigte Konfigurationsdatei, die wir in das Verzeichnis /etc kopieren.
# cp /usr/local/src/postwhite/postwhite.conf /etc/
Diese Konfigurationsdatei passen wir nun unseren Gegebenheiten an. Wir passen also dort die beiden Pfade spftoolspath und yahoo_static_hosts.
# vim /etc/postwhite.conf>
- /etc/postwhite.conf
# CONFIGURATION OPTIONS FOR POSTWHITE # https://github.com/stevejenkins/postwhite # POSTWHITE WILL LOOK FOR THIS FILE IN /etc/postwhite.conf # FILE PATHS # Django : 2019-01-28 # default: spftoolspath=/usr/local/bin/spf-tools spftoolspath=/usr/local/src/spf-tools postfixpath=/etc/postfix postfixbinarypath=/usr/sbin whitelist=postscreen_spf_whitelist.cidr blacklist=postscreen_spf_blacklist.cidr # Django : 2019-01-28 # default: yahoo_static_hosts=/usr/local/bin/postwhite/yahoo_static_hosts.txt yahoo_static_hosts=/usr/local/src/postwhite/yahoo_static_hosts.txt # CUSTOM HOSTS # Enter custom hosts separated by a space, ex: "example.com example2.com example3.com" custom_hosts="" # Include list of Yahoo Outbound IPs from https://help.yahoo.com/kb/SLN23997.html? include_yahoo="yes" # Do you also want to build a blacklist? enable_blacklist=no blacklist_hosts="" # Do what to invalid IPv4 addresses and CIDRs? # Valid settings are 'remove' 'fix' or 'keep' invalid_ip4=remove # Simplify (remove) IP addresses from the whitelist that are already covered by CIDRs? # WARNING: Enabling this option can dramatically increase the time Postwhite takes to # run if you have many mailers selected. Try it once, then come back and turn it off. :) simplify=no # Reload Postfix Automatically when done? reload_postfix=yes
Postscreen/Postfix
Postwhite wird uns eine Whitelist generieren und bei Bedarf auch eine Blacklist. Wir müssen nun unsere Postscreen-Konfiguration entsprechend anpassen, so dass die generierte(n) CIDR-Liste(n) entsprechend eingebunden werden.
# vim /etc/postfix/main.cf
... ################################################################################ ## POSTSCREEN - ERSTE STUFE DER SPAM/UCE/VIREN-ABWEHRMECHANISMEN # # Django : 2019-01-27 - PERMANENT WHITE/BLACKLIST TEST # default: postscreen_access_list = permit_mynetworks postscreen_access_list = permit_mynetworks cidr:/etc/postfix/postscreen_spf_whitelist.cidr #cidr:/etc/postfix/postscreen_spf_blacklist.cidr ...
Programmstart
manueller Start
Nun können wir postwhite das erste mal starten.
# postwhite
Starting Postwhite v3.4 (14 April 2018)
Reading options from /etc/postwhite.conf...
Creating temporary files...
Recursively querying SPF records of selected whitelist mailers...
Querying webmail hosts...
Getting spf.constantcontact.com
Getting aspmx.sailthru.com
Getting mail.zendesk.com
Getting _ipspf.yahoo.com
Getting _spf1.yahoo.com
Getting _spf2.yahoo.com
Getting _spf3.yahoo.com
Getting spf.messagingengine.com
Getting _spf.google.com
Getting _netblocks.google.com
Getting _netblocks2.google.com
Getting _netblocks3.google.com
Getting spf.protection.outlook.com
Getting spfa.protection.outlook.com
Getting spfb.protection.outlook.com
Getting spf-a.outlook.com
Getting spf-b.outlook.com
Getting spf-a.hotmail.com
Getting _spf-ssg-b.microsoft.com
Getting _spf-ssg-c.microsoft.com
Getting emsd1.com
Getting acemdns.com
Getting _spf-a.microsoft.com
Getting spf.protection.outlook.com
Getting spfa.protection.outlook.com
Getting spfb.protection.outlook.com
Getting _spf-b.microsoft.com
Getting _spf-mdm.microsoft.com
Getting _spf-c.microsoft.com
Getting _spf-ssg-a.microsoft.com
Getting _spf-ssg-a.msft.net
Getting spf-a.hotmail.com
Getting spf-a.outlook.com
Getting spf-b.outlook.com
Getting spf.protection.outlook.com
Getting spfa.protection.outlook.com
Getting spfb.protection.outlook.com
Getting spf-a.hotmail.com
Getting _spf-ssg-b.microsoft.com
Getting _spf-ssg-c.microsoft.com
Getting spf.zoho.com
Querying social network hosts...
Getting _spf.facebook.com
Getting spf.mtasv.net
Getting facebookmail.com
Getting amazonses.com
Getting spf-00082601.pphosted.com
Getting _spf.pinterest.com
Getting _spf.google.com
Getting _netblocks.google.com
Getting _netblocks2.google.com
Getting _netblocks3.google.com
Getting _spf.greenhouse.io
Getting mailgun.org
Getting spf1.mailgun.org
Getting spf2.mailgun.org
Getting _spf.google.com
Getting _netblocks.google.com
Getting _netblocks2.google.com
Getting _netblocks3.google.com
Getting mailgun.org
Getting spf1.mailgun.org
Getting spf2.mailgun.org
Getting _spf.google.com
Getting _netblocks.google.com
Getting _netblocks2.google.com
Getting _netblocks3.google.com
Getting sendgrid.net
Getting mail.zendesk.com
Getting _spf.google.com
Getting _netblocks.google.com
Getting _netblocks2.google.com
Getting _netblocks3.google.com
Getting _thirdparty.twitter.com
Getting spf.mandrillapp.com
Querying ecommerce hosts...
Getting spf1.amazon.com
Getting spf2.amazon.com
Getting amazonses.com
Getting c._spf.ebay.com
Getting ces._spf.ebay.com
Getting p._spf.ebay.com
Getting emarsys.net
Getting _spf.salesforce.com
Getting p2._spf.ebay.com
Getting pp._spf.paypal.com
Getting ppcorp._spf.paypal.com
Getting 3ph1._spf.paypal.com
Getting 3ph2._spf.paypal.com
Getting 3ph3._spf.paypal.com
Getting 3ph4._spf.paypal.com
Getting 3ph5._spf.paypal.com
Querying bulk mail hosts...
Getting spf-a.authsmtp.com
Getting spf-b.authsmtp.com
Getting support.zendesk.com
Getting mail.zendesk.com
Getting _spf.salesforce.com
Getting _spf.google.com
Getting _netblocks.google.com
Getting _netblocks2.google.com
Getting _netblocks3.google.com
Getting spf0.exacttarget.com
Getting spf1.exacttarget.com
Getting spf2.exacttarget.com
Getting spf3.exacttarget.com
Getting spf4.exacttarget.com
Getting notifications.fishbowl.com
Getting _spf-dash.rmsbot.com
Getting spf.mtasv.net
Getting aspmx.pardot.com
Getting et._spf.pardot.com
Getting mktomail.com
Getting zuora.com
Getting zuora.com._nspf.vali.email
Skipping (has macros) %{i}._ip.%{h}._ehlo.%{d}._spf.vali.email
Getting stspg-customer.com
Getting sparkpostmail.com
Getting _spf.sparkpostmail.com
Getting _netblocks.sparkpostmail.com
Getting sendgrid.net
Getting _spf.icontact.com
Getting spf.protection.outlook.com
Getting spfa.protection.outlook.com
Getting spfb.protection.outlook.com
Getting 4638697.spf08.hubspotemail.net
Getting sg08.hubspotemail.net
Getting spe08.hubspotemail.net
Getting servers.mcsv.net
Getting mail.zendesk.com
Getting _spf.google.com
Getting _netblocks.google.com
Getting _netblocks2.google.com
Getting _netblocks3.google.com
Getting mailsenders.netsuite.com
Getting mailgun.org
Getting spf1.mailgun.org
Getting spf2.mailgun.org
Getting _spf.google.com
Getting _netblocks.google.com
Getting _netblocks2.google.com
Getting _netblocks3.google.com
Getting 2910904.spf10.hubspotemail.net
Getting sg10.hubspotemail.net
Getting spe10.hubspotemail.net
Getting support.zendesk.com
Getting mail.zendesk.com
Getting spf.mailjet.com
Getting _spf.google.com
Getting _netblocks.google.com
Getting _netblocks2.google.com
Getting _netblocks3.google.com
Getting spf.messagelabs.com
Getting nets1.spf.messagelabs.com
Getting nets2.spf.messagelabs.com
Getting _spf.google.com
Getting _netblocks.google.com
Getting _netblocks2.google.com
Getting _netblocks3.google.com
Getting partners.sendgrid.com
Getting _spf.salesforce.com
Getting stspg-customer.com
Getting _labs.sendgrid.com
Getting messagesystems.com
Getting _spf.salesforce.com
Getting _spf.google.com
Getting _netblocks.google.com
Getting _netblocks2.google.com
Getting _netblocks3.google.com
Getting _spf.sparkpostmail.com
Getting _netblocks.sparkpostmail.com
Querying miscellaneous hosts...
Getting _spf.google.com
Getting _netblocks.google.com
Getting _netblocks2.google.com
Getting _netblocks3.google.com
Getting esp.github.com
Getting _spf.createsend.com
Getting servers.mcsv.net
Getting _spf1.zendesk.com
Getting _spf2.zendesk.com
Getting _spf3.zendesk.com
Getting _spf4.zendesk.com
Getting _spf5.zendesk.com
Getting _spf6.zendesk.com
Querying custom hosts...
Including scraped Yahoo! outbound hosts...
Removing invalid IPv4 CIDRs from whitelist.......................................................................
Sorting whitelist rules...
Writing 1896 whitelist rules to /etc/postfix/postscreen_spf_whitelist.cidr...
Reloading Postfix configuration to refresh rules...
postfix/postfix-script: refreshing the Postfix mail system
Done!
Damit der laufende Postfix-Daemon die neu erstellte bzw. eine geänderte Whitelist neu einlesen kann, bedarf es eines Relaods des Daemon. Gemäß unserer Konfiguration wir dieser Relaod nach dem Erstellen der CIDR-Liste automatisch ausgeführt, was im MAillog auch entsprechend protokolliert wird.
Jan 27 22:10:28 vml000080 postfix/postfix-script[13598]: refreshing the Postfix mail system Jan 27 22:10:28 vml000080 postfix/master[4129]: reload -- version 3.3.2, configuration /etc/postfix
automatischer zeitgesteuerter Programmstart
In regelmäßigen Abständen soll nun die CIDR-Tabelle mit den Whitelistingeinträgen generiert werden. Hierzu verschieben wir einfach den symbolischen link aus dem Verzeichnis /usr/local/bin in das Verzeichnis /etc/cron.daily
# mv /usr/local/bin/postwhite /etc/cron.daily/
Somit wird einmal am Tag die bestehende whitelist-Tabelle aktualisiert.
Für die Aktualisierung der speziellen Yahoo-Tabelle verschieben wir den zugehörigen symbolischen link aus dem Verzeichnis /usr/local/bin in das Verzeichnis /etc/cron.weekly. Hier hat sich ein wöchentlicher Update der Liste als ausreichend gezeigt.
# mv /usr/local/bin/scrape_yahoo /etc/cron.weekly/
FAZIT
Alles in allem kann man festhalten. Mit Hilfe von Postscreen erhöht man nicht nur die Erreichbar- und Verfügbarkeit seines Mailservers, sondern man erreicht auch ähnliche wenn nicht gar bessere SPAM/UCE/Virenmail-Schutz, wie zu früheren Zeiten mit greylisting und policyd-weight. Vor allem die vielen Verzögerungen bei der Mailzustellung, die bei Greylisting bis dato von den Endusern mehr oder minder beklagt wurden, gehören mit Postscreen der Vergangenheit an!
Somit kann man guten Gewissens den Einsatz und dem Vorzug von Postscreen vor Greylisting und policyd-weight vornehmen!
127.0.0.1