Bab 11. Layanan Jaringan: Postfix, Apache, NFS, Samba, Squid, LDAP, SIP, XMPP, TURN

Network services are the programs that users interact with directly in their daily work. They are the tip of the information system iceberg, and this chapter focuses on them; the hidden parts they rely on are the infrastructure we already described. They usually require the encryption technology described in Bagian 10.2, “X.509 certificates”.

11.1. Server Mail

Administrator Falcot Corp memilih Postfix untuk server surel elektroniknya, karena keandalan dan kemudahan konfigurasinya. Memang, desainnya memberlakukan bahwa setiap tugas diimplementasikan dalam sebuah proses dengan seperangkat izin minimum yang dibutuhkan, yang merupakan langkah mitigasi yang besar terhadap masalah keamanan.

ALTERNATIF Server Exim4

Debian menggunakan Exim4 sebagai peladen posel bawaan (instalasi awal menyertakan Exim4). Konfigurasi disediakan oleh paket yang terpisah, exim4-config, dan diatur secara otomatis berdasarkan jawaban dari pertanyaan Debconf yang mirip dengan pertanyaan yang diajukan oleh paket postfix.

Konfigurasi dapat berupa berkas tunggal (/etc/exim4/exim4.conf.template) atau terpecah dalam beberapa potongan konfigurasi tersimpan di bawah /etc/exim4/conf.d/. Keduanya, berkas tersebut digunakan olehperintah update-exim4.conf sebagai palet untuk menghasilkan /var/lib/exim4/config.autogenerated. Yang terakhir adalah berkas yang digunakan oleh Exim4. Berkat mekanisme ini, nilai yang dihasilkan melalui konfigurasi debconf Exim --yang tersimpan dalam /etc/exim4/update-exim4.conf.conf-- dapat disuntikkan ke dalam berkas konfigurasi Exim, bahkan ketika administrator atau paket lain telah mengubah konfigurasi bawaan Exim.

The Exim4 configuration file syntax has its peculiarities and its learning curve; however, once these peculiarities are understood, Exim4 is a very complete and powerful email server, as evidenced by the tens of pages of documentation.

→ https://www.exim.org/docs.html

11.1.1. Instalasi Postfix

The postfix package includes the main SMTP daemon. Other packages (such as postfix-ldap and postfix-pgsql) add extra functionality to Postfix, including access to mapping databases. You should only install them if you know that you need them.

Beberapa pertanyaan Debconf ditanyakan saat instalasi paket tersebut. Jawabannya memungkinkan menghasilkan versi pertama berkas konfigurasi /etc/postfix/main.cf.

Pertanyaan pertama berkaitan dengan jenis pengaturan. Hanya dua jawaban relevan yang diajukan jika ada server yang tersambung ke internet, "situs internet" dan "internet dengan smarthost". Yang pertama sesuai untuk server yang menerima email masuk dan mengirim email keluar langsung ke penerimanya, dan karenanya cocok untuk kasus Falcot Corp. Yang terakhir ini sesuai untuk server yang menerima email masuk secara normal, namun mengirimkan email keluar melalui server SMTP menengah — ”smarthost” — bukan langsung ke server penerima. Ini sangat berguna bagi individu dengan alamat IP dinamis, karena banyak server email menolak pesan yang datang langsung dari alamat IP semacam itu. Dalam kasus ini, smarthost biasanya adalah SMTP server milik ISP, yang selalu dikonfigurasi untuk menerima email dari pelanggan ISP dan meneruskannya dengan tepat. Pengaturan ini (dengan smarthost) selalu relevan untuk server yang tidak terhubung secara permanen ke internet, karena menghindari harus mengatur antrian pesan tidak terkirim yang perlu dicoba ulang di waktu yang lain.

Pertanyaan kedua berkaitan dengan nama lengkap mesin, digunakan untuk menghasilkan alamat email dari nama pengguna lokal; nama lengkap mesin sebagai bagian setelah simbol-at ("@"). Dalam kasus Falcot, jawabannya seharusnya mail.falcot.com. Pertanyaan ini yang diajukan secara default, namun konfigurasi yang diembannya tidak cukup lengkap untuk kebutuhan Falcot, karenanya administrator menjalankan perintah dpkg-reconfigure postfix agar dapat menyesuaikan lebih banyak parameter.

Salah satu pertanyaan tambahan yang diajukan untuk semua nama domain yang berhubungan dengan mesin. Daftar bawaan yang menyertakan nama lengkapnya sebagaimana sedikit padanan untuk localhost, namun domain utama falcot.com perlu ditambahkan sendiri. Lebih umumnya, pertanyaan ini seharusnya biasanya dijawab dengan seluruh nama domain yang mana mesin ini seharusnya melayani sebagai sebuah MX server; dengan kata lain, seluruh nama domain yang mana disebutkan DNS bahwa mesin ini akan menerima surel. Informasi ini berpangkal pada variabel mydestination pada berkas konfigurasi Postfix — /etc/postfix/main.cf.

Gambar 11.1. Aturan record DNS MX saat mengirimkan surel

Dalam beberapa kasus, instalasi juga dapat meminta jaringan apa yang harus diperbolehkan untuk mengirim surel melalui mesin. Dengan konfigurasi default, Postfix hanya menerima surel yang datang dari mesin itu sendiri; jaringan lokal biasanya akan ditambahkan. Administrator Falcot Corp menambahkan 192.168.0.0/16 ke jawaban default. Jika pertanyaan itu tidak muncul, variabel yang relevan dalam berkas konfigurasi adalah mynetworks, seperti yang terlihat dalam contoh di bawah ini.

Local email can also be delivered through procmail. This tool allows users to sort their incoming email according to rules stored in their ~/.procmailrc file. Both Postfix and Exim4 suggest procmail by default, but there are alternatives like maildrop or Sieve filters.

Setelah langkah pertama ini, para administrator mendapat berkas konfigurasi berikut; ini akan digunakan sebagai titik awal untuk menambahkan beberapa fungsi tambahan di bagian berikutnya.

Contoh 11.1. Berkas/etc/postfix/main.cf awal

# See /usr/share/postfix/main.cf.dist for a commented, more complete version


# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = no

# See http://www.postfix.org/COMPATIBILITY_README.html -- default to 2 on
# fresh installs.
compatibility_level = 2



# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.

smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
myhostname = mail.falcot.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = mail.falcot.com, falcot.com, localhost.localdomain, localhost
relayhost =
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 192.168.0.0/16
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = all

KEAMANAN Sertifikat SSL Snake oil

The snake oil certificates, like the snake oil “medicine” sold by unscrupulous quacks in old times, have absolutely no value: you cannot rely on them to authenticate the server since they are automatically generated self-signed certificates. However, they are useful to improve the privacy of the exchanges.

In general they should only be used for testing purposes, and normal service must use real certificates. The Let's encrypt initiative offers free and trusted SSL/TLS certificates, which can be generated using the certbot package as described in Bagian 11.2.2, “Adding support for SSL” and then used in postfix like this:

smtpd_tls_cert_file = /etc/letsencrypt/live/DOMAIN/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/DOMAIN/privkey.pem
smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtpd_tls_CApath = /etc/ssl/certs
smtp_tls_CApath = /etc/ssl/certs

A different way to generate own certificates is described in Bagian 10.2.2, “Infrastruktur Kunci Publik: easy-rsa”.

11.1.2. Mengkonfigurasi Domain Virtual

Server surat dapat menerima surel yang ditujukan kepada domain lain selain domain utama; ini kemudian dikenal sebagai domain virtual. Dalam kebanyakan kasus di mana hal ini terjadi, surel pada akhirnya tidak ditujukan ke pengguna lokal. Postfix menyediakan dua fitur menarik untuk menangani virtual domain.

11.1.2.1. Domain Alias Virtual

Suatu domain alias virtual hanya berisi alias, yaitu alamat-alamat yang hanya meneruskan surel ke alamat lain.

Domain seperti itu diaktifkan dengan menambahkan nama ke variabel virtual_alias_domains, dan mereferensi berkas pemetaan alamat dalam variabel virtual_alias_maps.

virtual_alias_domains = falcotsbrand.com
virtual_alias_maps = hash:/etc/postfix/virtual

Berkas /etc/postfix/virtual menjelaskan pemetaan dengan sintaks yang agak sederhana: setiap baris berisi dua field yang dipisahkan oleh spasi; field pertama adalah nama alias, field kedua adalah daftar alamat surel tujuan pengalihan. Sintaks khusus @domain.com mencakup semua sisa alias dalam suatu domain.

webmaster@falcotsbrand.com  jean@falcot.com
contact@falcotsbrand.com    laure@falcot.com, sophie@falcot.com
# The alias below is generic and covers all addresses within
# the falcotsbrand.com domain not otherwise covered by this file.
# These addresses forward email to the same user name in the
# falcot.com domain.
@falcotsbrand.com           @falcot.com

After changing /etc/postfix/virtual the postfix table /etc/postfix/virtual.db needs to be updated using sudo postmap /etc/postfix/virtual.

11.1.2.2. Domain Kotak Surat Virtual

Pesan-pesan yang ditujukan ke kotak surat domain virtual disimpan dalam kotak surat yang tidak ditugaskan ke pengguna sistem lokal.

Memfungsikan kotak surat domain virtual memerlukan menamai domain ini dalam variabel virtual_mailbox_domains, dan mereferensi ke berkas pemetaan kotak surat di virtual_mailbox_maps. Parameter virtual_mailbox_base berisi direktori di mana kotak pesan akan disimpan.

virtual_mailbox_domains = falcot.org
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_mailbox_base = /var/mail/vhosts

Parameter virtual_uid_maps (dan virtual_gid_maps) mengacu ke berkas yang berisi pemetaan antara alamat surel dan sistem pengguna (dan kelompok) yang "memiliki" kotak surat yang sesuai. Agar semua kotak surat dimiliki oleh pemilik/kelompok yang sama, sintaks static:5000 menetapkan UID/GID tertentu (yang bernilai 5000 di sini).

Sekali lagi, sintaks berkas /etc/postfix/vmailbox cukup sederhana: dua field dipisahkan dengan spasi. Field pertama adalah alamat surel dalam salah satu domain virtual, dan field kedua adalah lokasi kotak surat yang terkait (relatif terhadap direktori yang ditentukan dalam virtual_mailbox_base). Jika nama kotak surat berakhir dengan garis miring (/), surel akan disimpan dalam format maildir; jika tidak, format tradisional mbox akan digunakan. Format maildir menggunakan seluruh direktori untuk menyimpan kotak surat, masing-masing pesan disimpan dalam berkas terpisah. Dalam format mbox, seluruh kotak surat disimpan dalam satu berkas, dan setiap baris yang dimulai dengan "From " (From diikuti dengan spasi) menandai awal pesan baru.

# Surel Jean disimpan sebagai maildir, dengan
# satu berkas per surel dalam suatu direktori
# terdedikasi
jean@falcot.org falcot.org/jean/
# Surel Sophie's disimpan dalam suatu berkas "mbox"
# tradisional dengan semua surel disambung ke dalam
# satu berkas tunggal
sophie@falcot.org falcot.org/sophie

11.1.3. Pembatasan Penerimaan dan Pengiriman

Meningkatnya jumlah surel massal yang tidak diminta (spam) memerlukan menjadi semakin ketat ketika memutuskan surel mana yang mesti diterima oleh server. Bagian ini menyajikan beberapa strategi yang termasuk dalam Postfix.

If the reject-rules are too strict, it may happen that even legitimate email traffic gets locked out. It is therefor a good habit to test restrictions and prevent the permanent rejection of requests during this time using the soft_bounce = yes directive. By prepending a reject-type directive with warn_if_reject only a log message will be recorded instead of rejecting the request.

KULTUR Masalah spam

“Spam” is a generic term used to designate all the unsolicited commercial emails (also known as UCEs) that flood our electronic mailboxes; the unscrupulous individuals sending them are known as spammers. They care little about the nuisance they cause, since sending an email costs very little, and only a very small percentage of recipients need to be attracted by the offers for the spamming operation to make more money than it costs. The process is mostly automated, and any email address made public (for instance, on a web forum, or on the archives of a mailing list, or on a blog, and so on) will be likely discovered by the spammers' robots, and subjected to a never-ending stream of unsolicited messages. Also every contact found at a compromised system is targeted.

Semua administrator sistem mencoba untuk menghadapi gangguan dengan filter spam, tapi tentu saja spammer terus menyesuaikan diri dengan mencoba menghindari filter ini. Beberapa bahkan menyewa jaringan mesin yang terkompromi oleh worm dari berbagai sindikat kejahatan. Statistik baru-baru ini memperkirakan bahwa hingga 95% dari semua surel yang beredar di Internet adalah spam!

11.1.3.1. Pembatasan Akses Berbasis IP

Direktif smtpd_client_restrictions mengendalikan mesin mana yang diperbolehkan untuk berkomunikasi dengan server surel.

When a variable contains a list of rules, as in the example below, these rules are evaluated in order, from the first to the last. Each rule can accept the message, reject it, or leave the decision to a following rule. As a consequence, order matters, and simply switching two rules can lead to a widely different behavior.

Contoh 11.2. Pembatasan Berbasis Alamat Klien

smtpd_client_restrictions =
    permit_mynetworks,
    warn_if_reject reject_unknown_client_hostname,
    check_client_access hash:/etc/postfix/access_clientip,
    reject_rhsbl_reverse_client dbl.spamhaus.org,
    reject_rhsbl_reverse_client rhsbl.sorbs.net,
    reject_rbl_client zen.spamhaus.org,
    reject_rbl_client dnsbl.sorbs.net

The permit_mynetworks directive, used as the first rule, accepts all emails coming from a machine in the local network (as defined by the mynetworks configuration variable).

The second directive would normally reject emails coming from machines without a completely valid DNS configuration. Such a valid configuration means that the IP address can be resolved to a name, and that this name, in turn, resolves to the IP address. This restriction is often too strict, since many email servers do not have a reverse DNS for their IP address. This explains why the Falcot administrators prepended the warn_if_reject modifier to the reject_unknown_client directive: this modifier turns the rejection into a simple warning recorded in the logs. The administrators can then keep an eye on the number of messages that would be rejected if the rule were actually enforced, and make an informed decision later if they wish to enable such enforcement.

TIP tabel access

The restriction criteria include administrator-modifiable tables listing combinations of senders, IP addresses, and allowed or forbidden hostnames. These tables can be created using an uncompressed copy of the /usr/share/doc/postfix/examples/access.gz file shipped with the postfix-doc package. This model is self-documented in its comments, which means each table describes its own syntax.

The /etc/postfix/access_clientip table lists IP addresses and networks; /etc/postfix/access_helo lists domain names; /etc/postfix/access_sender contains sender email addresses. All these files need to be turned into hash-tables (a format optimized for fast access) after each change, with the sudo postmap /etc/postfix/file command.

Direktif ketiga memungkinkan administrator untuk mengatur blacklist dan whitelist server surel, disimpan dalam berkas /etc/postfix/access_clientip. Server di whitelist dianggap sebagai dipercaya, dan surel yang datang dari sana tidak diperiksa memakai aturan penyaringan berikut.

The last four rules reject any message coming from a server listed in one of the indicated blacklists. RBL is an acronym for Remote Black List, and RHSBL stands for Right-Hand Side Black List. The difference is, that the former lists IP addresses, whereas the latter lists domain names. There are several such services. They list domains and IP addresses with poor reputation, badly configured servers that spammers use to relay their emails, as well as unexpected mail relays such as machines infected with worms or viruses.

11.1.3.2. Memeriksa Validitas Perintah `EHLO` atau `HELO`

Each SMTP exchange starts with a HELO (or EHLO) command, followed by the name of the sending email server. Checking the validity of this name can be interesting. To fully enforce the restrictions listed in smtpd_helo_restrictions the smtpd_helo_required option needs to be enabled. Otherwise clients could skip the restrictions by not sending any HELO/EHLO command.

Contoh 11.3. Pembatasan pada nama yang diumumkan di EHLO

smtpd_helo_required = yes
smtpd_helo_restrictions =
    permit_mynetworks,
    reject_invalid_helo_hostname,
    reject_non_fqdn_helo_hostname,
    warn_if_reject reject_unknown_helo_hostname,
    check_helo_access hash:/etc/postfix/access_helo,
    reject_rhsbl_helo multi.surbl.org

Direktir permit_mynetworks pertama memungkinkan semua mesin di jaringan lokal untuk memperkenalkan diri dengan bebas. Hal ini penting, karena beberapa program email tidak menghormati bagian dari protokol SMTP ini secara cukup memadai, dan mereka dapat memperkenalkan diri dengan nama-nama yang tidak masuk akal.

The reject_invalid_helo_hostname rule rejects emails when the EHLO announce lists a syntactically incorrect hostname. The reject_non_fqdn_helo_hostname rule rejects messages when the announced hostname is not a fully-qualified domain name (including a domain name as well as a host name). The reject_unknown_helo_hostname rule rejects messages if the announced name does not exist in the DNS. Since this last rule unfortunately leads to too many rejections, the administrators turned its effect to a simple warning with the warn_if_reject modifier as a first step; they may decide to remove this modifier at a later stage, after auditing the results of this rule.

The reject_rhsbl_helo allows to specify a black list to check the hostname against an RHSBL.

Using permit_mynetworks as the first rule has an interesting side effect: the following rules only apply to hosts outside the local network. This allows blacklisting all hosts that announce themselves as part of the falcot.com network, for instance by adding a falcot.com REJECT You are not in our network! line to the /etc/postfix/access_helo file.

11.1.3.3. Menerima atau Menolak Berdasarkan Pengirim yang Diumumkan

Setiap pesan memiliki pengirim, diumumkan oleh perintah MAIL FROM dari protokol SMTP; sekali lagi, informasi ini dapat divalidasi dalam beberapa cara yang berbeda.

Contoh 11.4. Pemeriksaan pengirim

smtpd_sender_restrictions =
    check_sender_access hash:/etc/postfix/access_sender,
    reject_unknown_sender_domain,
    reject_unlisted_sender,
    reject_non_fqdn_sender,
    reject_rhsbl_sender rhsbl.sorbs.net

Tabel /etc/postfix/access_sender memetakan beberapa perlakuan khusus untuk beberapa pengirim. Ini biasanya berarti memasukkan beberapa pengirim ke daftar putih atau daftar hitam.

Aturan reject_unknown_sender_domain memerlukan domain pengirim yang valid, karena dibutuhkan untuk alamat yang valid. Aturan reject_unlisted_sender menolak pengirim lokal jika alamat tidak ada; hal ini mencegah surel dari yang dikirim dari alamat yang tidak valid dalam domain falcot.com, dan pesan yang berasal dari joe.bloggs@falcot.com hanya diterima jika alamat tersebut benar-benar ada.

Akhirnya, aturan reject_non_fqdn_sender menolak surel yang mengaku berasal dari alamat tanpa fully-qualified domain name. Dalam prakteknya, ini berarti menolak surel yang datang dari user@machine: alamat harus diumumkan sebagai user@machine.example.com atau user@example.com.

The reject_rhsbl_sender rule reject senders based on a (domain-based) RHSBL service.

11.1.3.4. Menerima atau Menolak Berdasarkan Penerima

Setiap surel yang memiliki minimal satu penerima, diumumkan dengan perintah RCPT TO dalam protokol SMTP. Alamat ini juga memerlukan validasi, bahkan jika itu mungkin kurang relevan daripada pemeriksaan atas alamat pengirim.

Contoh 11.5. Pemeriksaan penerima

smtpd_recipient_restrictions =
    permit_mynetworks,
    reject_unauth_destination,
    reject_unlisted_recipient,
    reject_non_fqdn_recipient,
    permit

reject_unauth_destination adalah aturan dasar yang mempersyaratkan pesan dari luar ditujukan kepada kami; pesan yang dikirim ke alamat yang tidak dilayani oleh server ini akan ditolak. Tanpa aturan ini, server menjadi relay terbuka yang memungkinkan spammer untuk mengirim surel yang tidak diinginkan; aturan ini wajib, dan itu paling baik disertakan di bagian awal dari daftar, sehingga tidak ada aturan lainnya mungkin mengotorisasi pesan sebelum tujuan telah diperiksa.

Aturan reject_unlisted_recipient menolak pesan yang dikirim ke pengguna lokal yang tidak ada. Ini masuk akal. Akhirnya, aturan reject_non_fqdn_recipient menolak alamat yang bukan fully-qualified; ini menjadikannya mustahil untuk mengirim surel ke jean atau jean@machine, dan memerlukan menggunakan alamat lengkap, seperti jean@machine.falcot.com atau jean@falcot.com.

The permit directive at the end is not necessary. But it can be useful at the end of a restriction list to make the default policy explicit.

11.1.3.5. Pembatasan Terkait dengan Perintah `DATA`

Perintah DATA SMTP dikirimkan sebelum isi pesan. Tidak memberikan informasi apapun per se, selain mengumumkan apa yang datang berikutnya. Masih bisa dipersyaratkan untuk pemeriksaan.

Contoh 11.6. Pemeriksaan DATA

smtpd_data_restrictions = reject_unauth_pipelining

Direktif reject_unauth_pipelining menyebabkan pesan ditolak jika pihak pengirim mengirim perintah sebelum balasan atas perintah sebelumnya dikirim. Ini penjaga terhadap optimasi yang umum digunakan oleh robot spammer, karena mereka biasanya tidak peduli isi balasan dan fokus hanya pada mengirim surel sebanyak mungkin dalam waktu sependek mungkin.

11.1.3.6. Menerapkan Pembatasan

Although the above commands validate information at various stages of the SMTP exchange, Postfix sends the actual rejection as a reply to the RCPT TO command by default.

Ini berarti bahwa bahkan jika pesan tersebut ditolak karena perintah EHLO yang tidak valid, Postfix tahu pengirim dan penerima ketika mengumumkan penolakan. Ini kemudian mencatat log pesan yang lebih eksplisit daripada yang bisa dilakukan jika transaksi telah terputus dari awal. Selain itu, sejumlah klien SMTP tidak mengharapkan kegagalan pada perintah SMTP awal, dan klien ini akan kurang terganggu oleh penolakan akhir ini.

Keuntungan akhir pilihan ini adalah bahwa aturan dapat mengumpulkan informasi selama berbagai tahap pertukaran SMTP; hal ini memungkinkan mendefinisikan izin lebih halus, seperti menolak koneksi non-lokal jika itu mengumumkan dirinya dengan pengirim lokal.

The default behavior is controlled by the smtpd_delay_reject rule.

11.1.3.7. Penyaringan Berdasarkan Isi Pesan

Sistem validasi dan pembatasan tidak akan lengkap tanpa cara untuk menerapkan pemeriksaan ke isi pesan. Postfix membedakan pemeriksaan yang berlaku ke header surel dari mereka yang berlaku ke tubuh surel.

Contoh 11.7. Memfungsikan penyaring berbasis konten

header_checks = regexp:/etc/postfix/header_checks
body_checks = regexp:/etc/postfix/body_checks

Kedua berkas berisi daftar ekspresi reguler (umumnya dikenal sebagai regexps atau regexes) dan tindakan menjadi dipicu ketika header surel (atau tubuh) cocok dengan ekspresi yang terkait.

Contoh 11.8. Berkas contoh /etc/postfix/header_checks

/^X-Mailer: GOTO Sarbacane/ REJECT I fight spam (GOTO Sarbacane)
/^Subject: *Your email contains VIRUSES/ DISCARD virus notification

KEMBALI KE DASAR Ekspresi reguler

The regular expression term (shortened to regexp or regex) references a generic notation for expressing a description of the contents and/or structure of a string of characters. Certain special characters allow defining alternatives (for instance, foo|bar matches either “foo” or “bar”), sets of allowed characters (for instance, [0-9] means "any digit", and . — a dot — means "any character"), quantification (s? matches either s or the empty string, in other words 0 or 1 occurrence of s; s+ matches one or more consecutive s characters; and so on). Parentheses allow grouping search results.

The precise syntax of these expressions varies across the tools using them, but the basic features are similar.

→ https://en.wikipedia.org/wiki/Regular_expression

Yang pertama memeriksa header yang menyebutkan perangkat lunak surel; jika GOTO Sarbacane (software surel massal) ditemukan, pesan tersebut akan ditolak. Ekspresi kedua mengendalikan subjek pesan; jika itu menyebutkan pemberitahuan virus, kita bisa memutuskan untuk tidak menolak pesan tetapi untuk membuangnya segera sebagai gantinya.

Menggunakan filter ini adalah pedang bermata dua, karena mudah untuk membuat aturan yang terlalu generik dan kehilangan surel yang sah sebagai akibatnya. Dalam kasus ini, tidak hanya pesan akan hilang, tapi pengirimnya akan mendapatkan pesan kesalahan yang tidak diinginkan (dan menjengkelkan).

11.1.4. Menyiapkan greylisting

"Greylisting" adalah teknik penyaringan yang pesan awalnya ditolak dengan kode kesalahan sementara, dan hanya diterima pada percobaan lebih lanjut setelah penundaan. Hal ini sangat efisien terhadap spam yang dikirim oleh banyak mesin yang terinfeksi oleh virus dan worm karena software ini jarang bertindak sebagai agen SMTP penuh (dengan memeriksa kode kesalahan dan mencoba kembali pesan gagal kemudian), terutama karena banyak dari alamat yang dipanen sebenarnya tidak sah dan mencoba kembali berarti kehilangan waktu.

Postfix tidak menyediakan greylist secara native, tapi ada fitur dimana keputusan untuk menerima atau menolak pesan tertentu dapat diserahkan ke program eksternal. Paket postgrey memuat program seperti itu, dirancang untuk berinteraksi dengan layanan delegasi kebijakan akses ini.

Setelah postgrey terinstal, itu berjalan sebagai daemon dan mendengarkan pada port 10023. Postfix kemudian dapat dikonfigurasi untuk menggunakannya, dengan menambahkan parameter check_policy_service sebagai pembatasan tambahan:

smtpd_recipient_restrictions =
    permit_mynetworks,
    [...]
    check_policy_service inet:127.0.0.1:10023

Setiap kali Postfix mencapai aturan ini dalam set aturan, itu akan menyambung ke daemon postgrey dan mengirim informasi mengenai pesan yang relevan. Pada sisinya, Postgrey mempertimbangkan triplet alamat IP/pengirim/penerima triplet dan memeriksa basis data apakah triplet yang sama telah terlihat baru-baru ini. Jika demikian, Postgrey menjawab bahwa pesan harus diterima; jika tidak, jawaban menunjukkan bahwa pesan harus ditolak untuk sementara, dan triplet dicatat dalam basis data.

Kelemahan utama dari greylist adalah bahwa pesan yang sah tertunda, yang tidak selalu bisa diterima. Hal ini juga meningkatkan beban pada server yang mengirim banyak surel yang sah.

DALAM PRAKTEK Kekurangan dari greylisting

Secara teori, greylist hanya harus menunda surat pertama dari pengirim yang diberikan kepada penerima tertentu, dan penundaan umumnya dalam orde menit. Kenyataannya, bagaimanapun, dapat sedikit berbeda. Beberapa ISP besar menggunakan cluster server SMTP, dan ketika pesan awalnya ditolak, server yang mencoba ulang transmisi mungkin tidak akan sama seperti yang pertama. Ketika itu terjadi, kedua server mendapat pesan kesalahan sementara karena greylist, dan seterusnya; mungkin butuh beberapa jam sampai transmisi ini dicoba oleh server yang sudah telah terlibat, karena server SMTP biasanya meningkatkan penundaan antara pengulangan di setiap kegagalan.

Sebagai akibatnya, alamat IP yang masuk dapat bervariasi dengan berjalannya waktu bahkan untuk pengirim tunggal. Tapi lebih jauh lagi: bahkan alamat pengirim dapat berubah. Sebagai contoh, banyak milis server menyandikan tambahan informasi dalam alamat pengirim untuk dapat menangani pesan kesalahan (dikenal sebagai bounces). Setiap pesan baru yang dikirim ke milis kemudian mungkin perlu pergi melalui greylist, yang berarti itu harus disimpan (secara sementara) pada server pengirim. Untuk milis yang sangat besar (dengan puluhan ribu pelanggan), ini dapat segera menjadi masalah.

Untuk memitigasi kelemahan ini, Postgrey mengelola daftar putih dari situs-situs seperti itu, dan pesan yang berasal dari mereka segera diterima tanpa melalui greulist. Daftar ini dengan mudah dapat disesuaikan dengan kebutuhan lokal, karena disimpan dalam berkas /etc/postgrey/whitelist_clients.

LEBIH LANJUT Greylisting selektif dengan milter-greylist

Kelemahan dari greylist dapat dimitigsai dengan hanya menggunakan greylist pada subset dari klien yang sudah dianggap sebagai kemungkinan sumber spam (karena mereka tercantum dalam daftar hitam DNS). Hal ini tidak mungkin dengan postgrey tapi milter-greylist dapat digunakan dengan cara itu.

Dalam skenario itu, karena blacklist DNS tidak pernah memicu penolakan definitif, menjadi masuk akal untuk menggunakan blacklist agresif, termasuk daftar semua alamat IP dinamis dari klien ISP (seperti pbl.spamhaus.org atau dul.dnsbl.Sorbs.net).

Since milter-greylist uses Sendmail's milter interface, the postfix side of its configuration is limited to “smtpd_milters = unix:/var/run/milter-greylist/milter-greylist.sock”. The greylist.conf(5) manual page documents /etc/milter-greylist/greylist.conf and the numerous ways to configure milter-greylist. You will also have to edit /etc/default/milter-greylist to actually enable the service.

11.1.5. Mengubah Filter Berdasarkan Penerima

Bagian 11.1.3, “Pembatasan Penerimaan dan Pengiriman” dan Bagian 11.1.4, “Menyiapkan greylisting” meninjau banyak kemungkinan pembatasan. Mereka semua memiliki kegunaan dalam membatasi jumlah spam yang diterima, tetapi mereka semua juga memiliki kelemahan. Maka semakin umum untuk menyesuaikan set filter tergantung pada penerima. Pada Falcot Corp, greylist menarik bagi sebagian pengguna, tapi mengganggu pekerjaan beberapa pengguna yang membutuhkan latensi rendah dalam surel mereka (seperti layanan dukungan teknis). Demikian pula, layanan komersial kadang-kadang memiliki masalah menerima surel dari beberapa penyedia Asia yang mungkin tercantum di daftar hitam; layanan ini meminta alamat tak tersaring untuk bisa berkorespondensi.

Postfix menyediakan kustomisasi filter dengan konsep "kelas pembatasan". Kelas dideklarasikan dalam parameter smtpd_restriction_classes, dan didefinisikan dengan cara yang sama sebagai smtpd_recipient_restrictions. Direktif check_recipient_access kemudian mendefinisikan tabel pemetaan penerima tertentu untuk seperangkat batasan.

Contoh 11.9. Mendefinisikan kelas pembatasan dalam main.cf

smtpd_restriction_classes = greylisting, aggressive, permissive

greylisting = check_policy_service inet:127.0.0.1:10023
aggressive =
        reject_rbl_client sbl-xbl.spamhaus.org,
        check_policy_service inet:127.0.0.1:10023
permissive = permit

smtpd_recipient_restrictions =
        permit_mynetworks,
        reject_unauth_destination,
        check_recipient_access hash:/etc/postfix/recipient_access

Contoh 11.10. Berkas /etc/postfix/recipient_access

# Unfiltered addresses
postmaster@falcot.com  permissive
support@falcot.com     permissive
sales-asia@falcot.com  permissive

# Aggressive filtering for some privileged users
joe@falcot.com         aggressive

# Special rule for the mailing-list manager
sympa@falcot.com       reject_unverified_sender

# Greylisting by default
falcot.com             greylisting

11.1.6. Mengintegrasikan Antivirus

Banyak virus yang beredar sebagai lampiran surel membuat penting untuk mengatur antivirus di titik entri jaringan perusahaan, karena meskipun sudah ada kampanye kesadaran, beberapa pengguna masih akan membuka lampiran dari pesan yang jelas-jelas mencurigakan.

SECURITY Controversial Discussion of Anti-Virus Software

The usage of virus scanners, or so called antivirus software, is controversial. There is usually a gap between the release of some piece of malware and the addition of detection rules to the antivirus database. During this gap, there is no software-based protection. Further, the usage often requires to run additional software, for example, to uncompress archives and scan all kinds of executables, which drastically increases the exploit potential of the antivirus software itself. Usage of such software solutions can therefor never replace awareness campaigns and simple behavioral rules (never open unsolicited sent attachments, etc.).

Para administrator Falcot memilih clamav untuk antivirus gratis mereka. Paket utama adalah clamav, tetapi mereka juga memasang beberapa paket tambahan seperti arj, unzoo, unrar, dan lha, karena mereka diperlukan oleh antivirus untuk menganalisis lampiran yang diarsipkan dalam salah satu format ini.

Tugas antarmuka antara antivirus dan server surel jatuh ke clamav-milter. milter (singkatan dari mail filter) adalah sebuah program penyaringan yang dirancang khusus untuk menyambung dengan server surel. Suatu milter menggunakan standar antarmuka pemrograman aplikasi (API) yang memberikan kinerja lebih baik daripada filter eksternal ke server surel. Milters awalnya diperkenalkan oleh Sendmail, tetapi Postfix segera mengikutinya.

Setelah paket clamav-milter diinstal, milter harus ditata ulang untuk berjalan pada sebuah port TCP bukan pada named socket yang default. Hal ini dapat dicapai dengan dpkg-reconfigure clamav-milter. Ketika diminta untuk "Antarmuka komunikasi dengan Sendmail", jawablah "inet:10002@127.0.0.1".

Konfigurasi ClamAV standar cocok untuk kebanyakan situasi, tetapi beberapa parameter penting masih dapat disesuaikan dengan dpkg-reconfigure clamav-base.

Langkah terakhir melibatkan meemberitahu Postfix untuk menggunakan filter yang baru-baru ini dikonfigurasi. Ini bisa dilakukan sekedar dengan menambahkan direktif berikut untuk /etc/postfix/main.cf:

# Virus check with clamav-milter
smtpd_milters = inet:[127.0.0.1]:10002

If the antivirus causes problems, this line can be commented out, and systemctl reload postfix should be run so that this change is taken into account.

Semua pesan yang ditangani oleh Postfix sekarang pergi melalui saringan antivirus.

11.1.7. Fighting Spam with SPF, DKIM and DMARC

The high number of unsolicited email sent every day led to the creation of several standards, which aim at validating, that the sending host of an email is authorized and that the email has not been tampered with. The following systems are all DNS-based and require the administrators to not only have control over the mail server, but over the DNS for the domain in question too.

CAUTION Controversial Discussion

Like any other tool, the following standards have limits and real effects if put to use. They can (and should) lead to emails being rejected or even just discarded. If that happens to some legitimate emails (sometimes sent from a misconfigured SMTP server), it usually causes anger and a lack of understanding by the user. Therefor these rules are often applied as a "soft fail" or a "soft reject", which usually means, that failing the checks only leads to adding a (header) mark to the affected email. There are people who think that this makes these standards "broken by design". Decide for yourself and be careful about how strict you choose to apply these standards.

11.1.7.1. Integrating the Sender Policy Framework (SPF)

The Sender Policy Framework (SPF) is used to validate if a certain mail server is allowed to send emails for a given domain. It is mostly configured through DNS. The syntax for the entry to make is explained in detail at:

→ http://www.open-spf.org/SPF_Record_Syntax

→ https://tools.ietf.org/html/rfc7208

→ https://en.wikipedia.org/wiki/Sender_Policy_Framework

The following is a sample DNS entry which states that all the domain's Mail Exchange Resource Records (MX-RRs) are allowed to email the current domain, and all others are prohibited. The DNS entry does not need to be given a name. But to use the include directive it must have one.

Name: example.org
Type: TXT
TTL:  3600
Data: v=spf1 a mx -all

Let's take a quick look at the falcot.org entry.

# host -t TXT falcot.org
falcot.org descriptive text "v=spf1 ip4:199.127.61.96 +a +mx +ip4:206.221.184.234 +ip4:209.222.96.251 ~all"

It states, that the IP of the sender must match the A record for the sending domain, or must be listed as one of the Mail Exchange Resource Records for the current domain, or must be one of the three mentioned IP4 addresses. All other hosts should be marked as not being allowed to send email for the sender domain. The latter is called a "soft fail" and is intended to mark the email accordingly, but still accept it.

The postfix mail server can check the SPF record for incoming emails using the postfix-policyd-spf-python package, a policy agent written in Python. The file /usr/share/doc/postfix-policyd-spf-python/README.Debian describes the necessary steps to integrate the agent into postfix, so we won't repeat it here.

The configuration is done in the file /etc/postfix-policyd-spf-python/policyd-spf.conf, which is fully documented in policyd-spf.conf(5) and /usr/share/doc/postfix-policyd-spf-python/policyd-spf.conf.commented.gz. The main configuration parameters are HELO_reject and Mail_From_reject, which configure if emails should be rejected (Fail) or accepted with a header being appended (False), if checks fail. The latter is often useful, when the message is further processed by a spam filter.

If the result is intended to be used by opendmarc (Bagian 11.1.7.3, “Integrating Domain-based Message Authentication, Reporting and Conformance (DMARC)”), then Header_Type must be set to AR.

Note, that spamassassin contains a plugin to check the SPF record.

11.1.7.2. Integrating DomainKeys (DKIM) Signing and Checking

The Domain Keys Identified Mail (DKIM) standard is a sender authentication system. The mail transport agent, here postfix, adds a digital signature associated with the domain name to the header of outgoing emails. The receiving party can validate the message body and header fields by checking the signature against a public key, which is retrieved from the senders DNS records.

→ http://dkim.org/

The necessary tools are shipped with the opendkim and opendkim-tools packages.

First the private key must be created using the command opendkim-genkey -s SELECTOR -d DOMAIN. SELECTOR must be a unique name for the key. It can be as simple as "mail" or the date of creation, if you plan to rotate keys.

Contoh 11.11. Create a private key for signing E-Mails from falcot.com

# opendkim-genkey -s mail -d falcot.com -D /etc/dkimkeys
# chown opendkim.opendkim /etc/dkimkeys/mail.*

This will create the files /etc/dkimkeys/mail.private and /etc/dkimkeys/mail.txt and set the appropriate ownership. The first file contains the private key and the latter the public key, that needs to be added to the DNS:

Name: mail._domainkey
Type: TXT
TTL:  3600
Data: "v=DKIM1; h=sha256; k=rsa; s=email; p=[...]"

The opendkim package in Debian defaults to a keysize of 2048 bit. Unfortunately some DNS servers can only handle text entries with a maximum length of 255 characters, which is exceeded by the chosen default keysize. In this case use the option -b 1024 to chose a smaller keysize. If opendkim-testkey succeeds, the entry has been successfully set up. The syntax of the entry is explained here:

→ https://tools.ietf.org/html/rfc6376

→ https://en.wikipedia.org/wiki/DKIM

To configure opendkim, SOCKET and RUNDIR must be chosen in /etc/default/opendkim. Please note that SOCKET must be accessible from postfix in its chrooted environment. The further configuration is done in /etc/opendkim.conf. The following is a configuration excerpt, which makes sure that the Domain "falcot.com" and all subdomains (SubDomain) are signed by the Selector "mail" and the single private key (KeyFile) /etc/dkimkeys/mail.private. The "relaxed" Canonicalization for both the header and the body tolerates mild modification (by a mailing list software, for example). The filter runs both in signing ("s") and verification ("v") Mode. If a signature fails to validate (On-BadSignature), the mail should be quarantined ("q").

[...]
Domain                  falcot.com
KeyFile                 /etc/dkimkeys/mail.private
Selector                mail

[...]
Canonicalization        relaxed/relaxed
Mode                    sv
On-BadSignature         q
SubDomains              yes

[...]
Socket                  inet:12345@localhost

[...]
UserID                  opendkim

It is also possible to use multiple selectors/keys (KeyTable), domains (SigningTable) and to specify internal or trusted hosts (InternalHosts, ExternalIgnoreList), which may send mail through the server as one of the signing domains without credentials.

The following directives in /etc/postfix/main.cf make postfix use the filter:

milter_default_action = accept
non_smtpd_milters = inet:localhost:12345
smtpd_milters = inet:localhost:12345

To differentiate signing and verification it is sometimes more useful to add the directives to the services in /etc/postfix/master.cf instead.

More information is available in the /usr/share/doc/opendkim/ directory and the manual pages opendkim(8) and opendkim.conf(5).

Note that spamassassin contains a plugin to check the DKIM record.

11.1.7.3. Integrating Domain-based Message Authentication, Reporting and Conformance (DMARC)

The Domain-based Message Authentication, Reporting and Conformance (DMARC) standard can be used to define a DNS TXT entry with the name _dmarc and the action, that should be taken, when emails, which contain your domain as sending host, fail to validate using DKIM and SPF.

→ https://dmarc.org/overview/

Let's have a look at the entries of two large providers:

# host -t TXT _dmarc.gmail.com
_dmarc.gmail.com descriptive text "v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com"
# host -t TXT _dmarc.yahoo.com
_dmarc.yahoo.com descriptive text "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc_y_rua@yahoo.com;"

Yahoo has a strict policy to reject all emails pretending to be sent from a Yahoo account but missing or failing DKIM and SPF checks. Google Mail (Gmail) propagates a very relaxed policy, in which such messages from the main domain should still be accepted (p=none). For subdomains they should be marked as spam (sp=quarantine). The addresses given in the rua key can be used to send aggregated DMARC reports to. The full syntax is explained here:

→ https://tools.ietf.org/html/rfc7489

→ https://en.wikipedia.org/wiki/DMARC

The postfix mail server can use this information too. The opendmarc package contains the necessary milter. Similar to opendkim SOCKET and RUNDIR must be chosen in /etc/default/opendmarc (for Unix sockets you must make sure, that they are inside the postfix chroot to be found). The configuration file /etc/opendmarc.conf contains detailed comments and is also explained in opendmarc.conf(5). By default, emails failing the DMARC validation are not rejected but flagged, by adding an appropriate header field. To change this, use RejectFailures true.

The milter is then added to smtpd_milters and non_smtpd_milters. If we configured the opendkim and opendmarc milters to run on ports 12345 and 54321, the entry in /etc/postfix/main.cf looks like this:

non_smtpd_milters = inet:localhost:12345,inet:localhost:54321
smtpd_milters = inet:localhost:12345,inet:localhost:54321

The milter can also be selectively applied to a service in /etc/postfix/master.cf instead.

11.1.8. SMTP Terotentikasi

Mampu mengirim surel memerlukan server SMTP yang dapat dijangkau; ini juga memerlukan server SMTP untuk mengirim surel melalui itu. Untuk pengguna roaming, ini mungkin memerlukan secara teratur mengubah konfigurasi klien SMTP, karena server SMTP Falcot's menolak pesan yang datang dari alamat IP yang tampaknya bukan milik perusahaan. Ada dua solusi: pengguna roaming menginstal server SMTP pada komputer mereka atau mereka masih menggunakan server perusahaan dengan beberapa cara untuk otentikasi sebagai karyawan. Solusi pertama tidak dianjurkan karena komputer tidak akan dihubungkan secara permanen, dan tidak akan dapat mengulangi pengiriman pesan jika terjadi masalah; kita akan fokus pada solusi yang terakhir.

Otentikasi SMTP di Postfix mengandalkan SASL (Simple Authentication and Security Layer). Hal ini membutuhkan instalasi paket libsasl2-modules dan sasl2-bin, kemudian mendaftarkan suatu kata sandi di basis data SASL untuk setiap pengguna yang memerlukan otentikasi pada server SMTP. Hal ini dilakukan dengan perintah saslpasswd2, yang memerlukan beberapa parameter. Opsi -U mendefinisikan domain otentikasi, yang harus cocok dengan parameter smtpd_sasl_local_domain dalam konfigurasi Postfix. Opsi -C memungkinkan membuat pengguna, dan -f menetapkan berkas yang akan dipakai jika basis data SASL perlu disimpan di lokasi yang berbeda dari default (/etc/sasldb2).

# saslpasswd2 -u `postconf -h myhostname` -f /var/spool/postfix/etc/sasldb2 -c jean
[... ketikkan kata sandi jean dua kali ...]

Perhatikan bahwa basis data SASL dibuat dalam direktori milik Postfix. Untuk memastikan konsistensi, kita juga mengubah /etc/sasldb2 menjadi link simbolik menunjuk pada basis data yang digunakan oleh Postfix, dengan perintah ln -sf /var/spool/postfix/etc/sasldb2 /etc/sasldb2.

Sekarang kita perlu mengkonfigurasi Postfix agar menggunakan SASL. Pertama pengguna postfix perlu ditambahkan ke grup sasl, sehingga dapat mengakses basis data akun SASL. Beberapa parameter baru juga diperlukan untuk mengaktifkan SASL, dan parameter smtpd_recipient_restrictions perlu dikonfigurasi untuk memungkinkan kilen terotentikasi-SASL untuk mengirim surel dengan bebas.

Contoh 11.12. Memfungsikan SASL di /etc/postfix/main.cf

# Enable SASL authentication
smtpd_sasl_auth_enable = yes
# Define the SASL authentication domain to use
smtpd_sasl_local_domain = $myhostname
[...]
# Adding permit_sasl_authenticated before reject_unauth_destination
# allows relaying mail sent by SASL-authenticated users
smtpd_recipient_restrictions =
    permit_sasl_authenticated,
    permit_mynetworks,
    reject_unauth_destination,
[...]

It is usually a good idea to not send passwords over an unencrypted connection. Postfix allows to use different configurations for each port (service) it runs on. All these can be configured with different rules and directives in the /etc/postfix/master.cf file. To turn off authentication at all for port 25 (smtpd service) add the following directive:

smtp      inet  n       -       y       -       -       smtpd
    [..]
    -o smtpd_sasl_auth_enable=no
    [..]

If for some reason clients use an outdated AUTH command (some very old mail clients do), interoperability with them can be enabled using the broken_sasl_auth_clients directive.

EKSTRA Klien SMTP terotentikasi

Kebanyakan klien surel dapat untuk melakukan otentikasi ke server SMTP sebelum mengirim pesan keluar, dan menggunakan fitur itu cukup dengan sekedar mengkonfigurasi parameter yang tepat. Jika klien yang digunakan tidak menyediakan fitur itu, solusinya adalah untuk menggunakan server Postfix lokal dan mengkonfigurasi dengan relay surel melalui server SMTP remote. Dalam kasus ini, Postfix lokal itu sendiri adalah klien yang mengotentikasi dengan SASL. Berikut adalah parameter yang diperlukan:

smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
relay_host = [mail.falcot.com]

Berkas /etc/postfix/sasl_passwd perlu berisi nama pengguna dan kata sandi yangdigunakan untuk otentikasi pada server mail.falcot.com. Berikut adalah contoh:

[mail.falcot.com]   joe:LyinIsji

Seperti semua pemetaan Postfix, berkas ini harus diubah menjadi /etc/postfix/sasl_passwd.db dengan perintah postmap.