Product SiteDocumentation Site

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

11.1. Server Mail
11.1.1. Instalasi Postfix
11.1.2. Mengkonfigurasi Domain Virtual
11.1.3. Pembatasan Penerimaan dan Pengiriman
11.1.4. Menyiapkan greylisting
11.1.5. Mengubah Filter Berdasarkan Penerima
11.1.6. Mengintegrasikan Antivirus
11.1.7. Melawan Spam dengan SPF, DKIM dan DMARC
11.1.8. SMTP Terotentikasi
11.2. Server Web (HTTP)
11.2.1. Memasang Apache
11.2.2. Menambahkan dukungan untuk SSL
11.2.3. Mengkonfigurasi Host Virtual
11.2.4. Direktif Umum
11.2.5. Penganalisis Log
11.3. Server Berkas FTP
11.4. Server Berkas NFS
11.4.1. Mengamankan NFS
11.4.2. Server NFS
11.4.3. Klien NFS
11.5. Menyiapkan Share Windows dengan Samba
11.5.1. Server Samba
11.5.2. Klien Samba
11.6. Proksi HTTP/FTP
11.6.1. Memasang
11.6.2. Mengkonfigurasi sebuah Singgahan
11.6.3. Mengkonfigurasi suatu Penyaring
11.7. Direktori LDAP
11.7.1. Memasang
11.7.2. Mengisi Direktori
11.7.3. Mengelola akun dengan LDAP
11.8. Layanan Komunikasi Real-Time
11.8.1. Pengaturan DNS untuk layanan RTC
11.8.2. Server TURN
11.8.3. Server Proksi SIP
11.8.4. Server XMPP
11.8.5. Menjalankan layanan pada port 443
11.8.6. Menambahkan WebRTC
Layanan jaringan adalah program-program yang berinteraksi secara langsung dengan para pengguna dalam pekerjaan mereka sehari-hari. Mereka adalah puncak gunung es sistem informasi, dan bab ini akan memfokuskan pada mereka; bagian tak terlihat tempat mereka bertumpu adalah infrastruktur yang sudah kita terangkan sebelumnya. Mereka biasanya memerlukan teknologi enkripsi yang diuraikan dalam Bagian 10.2, “setifikat X.509”.

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.

11.1.1. Instalasi Postfix

Paket postfix menyertakan daemon SMTP utama. Paket lain (seperti postfix-ldap dan postfix-pgsql) menambahkan fungsionalitas ekstra ke Postfix, termasuk mengakses basis data pemetaan. Anda hanya perlu menginstallnya jika Anda tahu Anda memerlukannya.
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.
Aturan record DNS MX saat mengirimkan surel

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.
Surel lokal juga dapat dikirimkan melalui procmail. Alat ini memungkinkan pengguna untuk memilah surel masuk mereka menurut aturan yang disimpan dalam berkas ~/.procmailrc mereka. Postfix dan Exim4 menyarankan procmail secara baku, tapi ada alternatif seperti maildrop atau filter Sieve.
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

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
Setelah mengubah /etc/postfix/virtual tabel postfix /etc/postfix/virtual.db perlu diperbarui menggunakan 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.
Jika aturan penolakan terlalu ketat, mungkin terjadi bahkan lalu lintas surel yang sah pun terkunci. Oleh karena itu, merupakan kebiasaan yang baik untuk menguji pembatasan dan mencegah penolakan permanen atas permintaan selama waktu ini menggunakan perintah soft_bounce = yes. Dengan menambahkan direktif tipe tolak dengan warn_if_reject hanya pesan log yang akan direkam daripada menolak permintaan tersebut.

11.1.3.1. Pembatasan Akses Berbasis IP

Direktif smtpd_client_restrictions mengendalikan mesin mana yang diperbolehkan untuk berkomunikasi dengan server surel.
Ketika suatu variabel berisi daftar aturan, seperti pada contoh di bawah, aturan-aturan ini dievaluasi berurutan, dari pertama sampai terakhir. Setiap aturan dapat menerima pesan, menolak, atau menyerahkan keputusan ke aturan berikutnya. Sebagai akibatnya, urutan penting, dan sekedar mempertukarkan dua aturan dapat menyebabkan perilaku yang sangat berbeda.

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
Direktif permit_mynetworks, yang digunakan sebagai aturan pertama, menerima semua surel yang datang dari mesin jaringan lokal (seperti yang didefinisikan oleh variabel konfigurasi mynetworks).
Direktif kedua biasanya akan menolak surel yang datang dari mesin tanpa konfigurasi DNS yang sepenuhnya valid. Sebuah konfigurasi yang valid berarti bahwa alamat IP dapat di-resolve ke suatu nama, dan bahwa nama ini, pada gilirannya, di-resolve ke alamat IP. Pembatasan ini sering terlalu ketat, karena banyak server surel yang tidak memiliki reverse DNS untuk alamat IP mereka. Ini menjelaskan mengapa para administrator Falcot mengawali pengubah warn_if_reject ke direktif reject_unknown_client: pengubah ini mengubah penolakan menjadi peringatan sederhana yang tercatat dalam log. Administrator dapat kemudian mengawasi jumlah pesan yang akan ditolak jika aturan yang benar-benar ditegakkan, dan membuat keputusan kemudian jika mereka ingin memberlakukan aturan itu.
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.
Empat aturan terakhir menolak pesan yang berasal dari server yang tercantum dalam salah satu blacklist yang ditunjukkan. RBL adalah akronim untuk Remote Black List, dan RHSBL singkatan dari Right-Hand Side Black List. Perbedaannya adalah bahwa yang pertama memuat daftar alamat IP, sedangkan yang kedua memuat daftar nama domain. Ada beberapa layanan seperti itu. Mereka membuat daftar domain dan alamat IP dengan reputasi buruk, server-server yang dikonfigurasi secara buruk yang dipakai oleh spammer untuk me-relay surel mereka, maupun pe-relay surel yang tak terduga seperti mesin-mesin yang terinfeksi worm atau virus.

11.1.3.2. Memeriksa Validitas Perintah EHLO atau HELO

Setiap pertukaran SMTP dimulai dengan perintah HELO (atau EHLO), diikuti dengan nama server surel pengirim. Memeriksa validitas nama ini bisa menarik. Untuk sepenuhnya menegakkan pembatasan yang tercantum dalam smtpd_helo_restrictions opsi smtpd_helo_required perlu diaktifkan. Jika tidak, klien dapat melewati pembatasan dengan tidak mengirimkan perintah HELO/EHLO.

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.
Aturan reject_invalid_helo_hostname menolak surel ketika EHLO mengumumkan daftar nama host yang secara sintaksis salah. Aturan reject_non_fqdn_helo_hostname menolak pesan ketika nama host yang diumumkan bukan fully-qualified domain name (yang memuat nama domain maupun nama host). Aturan reject_unknown_helo_hostname menolak pesan jika nama yang diumumkan tidak ada di DNS. Karena aturan terakhir ini sayangnya mengarah ke penolakan yang terlalu banyak, para administrator mengubah efeknya menjadi peringatan sederhana dengan pengubah warn_if_reject sebagai langkah pertama; mereka mungkin memutuskan untuk menghapus pengubah ini pada tahap berikutnya, setelah audit hasil peraturan ini.
reject_rhsbl_helo memungkinkan untuk menentukan daftar hitam untuk memeriksa nama host terhadap RHSBL.
Menggunakan permit_mynetworks sebagai aturan pertama memiliki efek samping yang menarik: aturan berikutnya hanya diterapkan ke host di luar jaringan lokal. Hal ini memungkinkan mencekal semua host yang mengumumkan diri mereka sebagai bagian dari jaringan falcot.com, misalnya dengan menambahkan baris falcot.com REJECT Anda tidak berada dalam jaringan kami! ke dalam berkas / postfix/dll/access_helo.

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.
Aturan reject_rhsbl_sender menolak pengirim berdasarkan layanan RHSBL (berbasis domain).

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.
Arahan permit di akhir tidak diperlukan. Tapi bisa berguna di akhir daftar batasan untuk membuat kebijakan default eksplisit.

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

Meskipun perintah di atas memvalidasi informasi di berbagai tahap pertukaran SMTP, Postfix mengirimkan penolakan sebenarnya sebagai jawaban atas perintah RCPT TO secara baku.
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.
Perilaku default dikendalikan oleh aturan smtpd_delay_reject.

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
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.

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.
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
Jika antivirus menyebabkan masalah, baris ini dapat dijadikan komentar dan systemctl reload postfix harus dijalankan sehingga perubahan ini diperhitungkan.
Semua pesan yang ditangani oleh Postfix sekarang pergi melalui saringan antivirus.

11.1.7. Melawan Spam dengan SPF, DKIM dan DMARC

Tingginya jumlah surel yang tidak diminta yang dikirim setiap hari mengarah pada pembuatan beberapa standar, yang bertujuan untuk memvalidasi bahwa host pengirim surel diotorisasi dan bahwa surel tersebut belum dirusak. Sistem berikut semuanya berbasis DNS dan mengharuskan administrator untuk tidak hanya memiliki kendali atas server surel, tetapi juga atas DNS untuk domain yang dipermasalahkan.

11.1.7.1. Mengintegrasikan Sender Policy Framework (SPF)

Sender Policy Framework (SPF) digunakan untuk memvalidasi jika server surel tertentu diizinkan untuk mengirim surel untuk domain yang diberikan. Hal ini sebagian besar dikonfigurasi melalui DNS. Sintaks untuk entri untuk membuat dijelaskan secara rinci di:
Berikut ini adalah contoh entri DNS yang menyatakan bahwa semua domain Mail Exchange Resource Records (MX-RRs) diperbolehkan untuk surel domain saat ini, dan semua yang lain dilarang. Entri DNS tidak perlu diberi nama. Tetapi untuk menggunakan direktif include itu harus memilikinya.
Name: example.org
Type: TXT
TTL:  3600
Data: v=spf1 a mx -all
Mari kita lihat entri falcot.org.
# 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"
Ini menyatakan bahwa IP pengirim harus cocok dengan record A untuk domain pengiriman, atau harus terdaftar sebagai salah satu Mail Exchange Resource Records untuk domain saat ini, atau harus menjadi salah satu dari tiga alamat IP4 yang disebutkan. Semua host lain harus ditandai sebagai tidak diizinkan untuk mengirim surel untuk domain pengirim. Yang terakhir disebut "soft fail" dan dimaksudkan untuk menandai surel yang sesuai, tetapi masih menerimanya.
Server surel postfix dapat memeriksa data SPF untuk surel masuk menggunakan paket postfix-policyd-spf-python, agen kebijakan yang ditulis dalam Python. Berkas /usr/share/doc/postfix-policyd-spf-python/README. Debian menjelaskan langkah-langkah yang diperlukan untuk mengintegrasikan agen ke dalam postfix, jadi kami tidak akan mengulanginya di sini.
Konfigurasi dilakukan dalam berkas /etc/postfix-policyd-spf-python/policyd-spf.conf, yang sepenuhnya didokumentasikan dalam policyd-spf.conf(5) dan /usr/share/doc/postfix-policyd-spf-python/policyd-spf.conf.commented.gz. Parameter konfigurasi utama adalah HELO_reject dan Mail_From_reject, yang mengkonfigurasi apakah surel harus ditolak (Fail) atau diterima dengan header yang ditambah (False), jika pemeriksaan gagal. Yang terakhir ini sering berguna, ketika pesan diproses lebih lanjut oleh filter spam.
Jika hasilnya dimaksudkan untuk digunakan oleh opendmarc (Bagian 11.1.7.3, “Mengintegrasikan Domain-based Message Authentication, Reporting and Conformance (DMARC)”), maka Header_Type harus diatur ke AR.
Perhatikan bahwa spamassassin memuat suatu plugin untuk memeriksa record SPF.

11.1.7.2. Mengintegrasikan DomainKeys (DKIM) Penandatanganan dan Pemeriksaan

Standar Domain Keys Identified Mail (DKIM) adalah sistem otentikasi pengirim. Agen transpor surat, di sini postfix, menambahkan tanda tangan digital yang terkait dengan nama domain ke header surel keluar. Pihak penerima dapat memvalidasi bidang badan pesan dan header dengan memeriksa tanda tangan terhadap kunci publik, yang diperoleh dari catatan DNS pengirim.
Alat-alat yang diperlukan dikemas dalam paket opendkim dan opendkim-tools.
Pertama, kunci privat harus dibuat menggunakan perintah opendkim-genkey -s SELECTOR -d DOMAIN. SELECTOR harus merupakan nama unik untuk kunci tersebut. Ini bisa sekadar "mail" atau tanggal pembuatan, jika Anda berencana untuk merotasi kunci.

Contoh 11.11. Membuat sebuah kunci privat untuk menandatangani Surel dari falcot.com

# opendkim-genkey -s mail -d falcot.com -D /etc/dkimkeys
# chown opendkim.opendkim /etc/dkimkeys/mail.*
Ini akan membuat berkas /etc/dkimkeys/mail.private dan /etc/dkimkeys/mail.txt dan mengatur kepemilikan yang sesuai. Berkas pertama berisi kunci pribadi, dan yang terakhir adalah kunci publik yang perlu ditambahkan ke DNS:
Name: mail._domainkey
Type: TXT
TTL:  3600
Data: "v=DKIM1; h=sha256; k=rsa; s=email; p=[...]"
Paket opendkim di Debian secara default memiliki ukuran kunci 2048 bit. Sayangnya beberapa server DNS hanya dapat menangani entri teks dengan panjang maksimum 255 karakter, yang dilampaui oleh ukuran kunci default yang dipilih. Dalam hal ini gunakan opsi -b 1024 untuk memilih ukuran kunci yang lebih kecil. Jika opendkim-testkey berhasil, entri telah berhasil disiapkan. Sintaks dari entri tersebut dijelaskan di sini:
Untuk mengkonfigurasi opendkim, SOCKET dan RUNDIR harus dipilih di /etc/default/opendkim. Harap dicatat bahwa SOCKET harus dapat diakses dari postfix di lingkungan chroot-nya. Konfigurasi lebih lanjut dilakukan di /etc/opendkim.conf. Berikut ini adalah kutipan konfigurasi, yang memastikan bahwa Domain "falcot.com" dan semua subdomain (SubDomain) ditandatangani oleh Selector "mail" dan kunci privat tunggal (KeyFile) /etc/dkimkeys/mail.private. Canonicalization "relaxed" baik untuk header dan body mentolerir modifikasi ringan (oleh perangkat lunak milis, misalnya). Filter berjalan baik dalam Mode penandatanganan ("s") dan verifikasi ("v"). Jika tanda tangan gagal untuk memvalidasi (On-BadSignature), surat harus dikarantina ("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
Dimungkinkan juga untuk menggunakan beberapa pemilih/kunci (KeyTable), domain (SigningTable), dan untuk menentukan host internal atau terpercaya (InternalHosts, ExternalIgnoreList), yang dapat mengirim surel melalui server sebagai salah satu domain penandatanganan tanpa kredensial.
Direktif berikut dalam /etc/postfix/main.cf membuat postfix memakai filter:
milter_default_action = accept
non_smtpd_milters = inet:localhost:12345
smtpd_milters = inet:localhost:12345
Untuk membedakan penandatanganan dan verifikasi, terkadang lebih berguna untuk menambahkan arahan ke layanan di /etc/postfix/master.cf sebagai gantinya.
Informasi lebih lanjut tersedia di direktori /usr/share/doc/opendkim/ dan halaman manual opendkim(8) dan opendkim.conf(5).
Perhatikan bahwa spamassassin memuat suatu plugin untuk memeriksa record DKIM.

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

Standar Domain-based Message Authentication, Reporting and Conformance (DMARC) dapat digunakan untuk menentukan entri DNS TXT dengan nama _dmarc dan tindakan yang harus diambil ketika surel yang berisi domain Anda sebagai host pengirim gagal divalidasi menggunakan DKIM dan SPF.
Mari kita lihat entri dari dua penyedia besar:
# 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 memiliki kebijakan yang ketat untuk reject semua surel yang berpura-pura dikirim dari akun Yahoo tetapi kekurangan atau gagal pemeriksaan DKIM dan SPF. Google Mail (Gmail) menyebarkan kebijakan yang sangat santai, di mana pesan tersebut dari domain utama masih harus diterima (p=none). Untuk subdomain, mereka harus ditandai sebagai spam (sp=quarantine). Alamat yang diberikan dalam kunci rua dapat digunakan untuk mengirim laporan DMARC gabungan. Sintaks lengkap dijelaskan di sini:
Server surat postfix dapat menggunakan informasi ini juga. Paket opendmarc berisi milter yang diperlukan. Mirip dengan opendkim SOCKET dan RUNDIR harus dipilih di /etc/default/opendmarc (untuk soket Unix Anda harus memastikan bahwa mereka berada di dalam chroot postfix untuk ditemukan). Berkas konfigurasi /etc/opendmarc.conf berisi komentar rinci dan juga dijelaskan di opendmarc.conf(5). Secara default, surel yang gagal dalam validasi DMARC tidak ditolak tetapi ditandai, dengan menambahkan kolom header yang sesuai. Untuk mengubahnya, gunakan RejectFailures true.
Milter kemudian ditambahkan ke smtpd_milters dan non_smtpd_milters. Jika kita mengkonfigurasi milter opendkim dan opendmarc untuk berjalan pada port 12345 dan 54321, entri di /etc/postfix/main.cf terlihat seperti ini:
non_smtpd_milters = inet:localhost:12345,inet:localhost:54321
smtpd_milters = inet:localhost:12345,inet:localhost:54321
Milter juga dapat diterapkan secara selektif ke suatu layanan dalam /etc/postfix/master.cf sebagai pengganti.

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

# Memfungsikan otentikasi SASL
smtpd_sasl_auth_enable = yes
# Define the SASL authentication domain to use
smtpd_sasl_local_domain = $myhostname
[...]
# Menambahkan permit_sasl_authenticated before reject_unauth_destination
# mengizinkan merelay surel yang dikirim oleh pengguna SASL-authenticated
smtpd_recipient_restrictions = 
    permit_sasl_authenticated,
    permit_mynetworks,
    reject_unauth_destination,
[...]
Biasanya merupakan ide yang baik untuk tidak mengirim kata sandi melalui koneksi yang tidak terenkripsi. Postfix memungkinkan untuk menggunakan konfigurasi yang berbeda untuk setiap port (layanan) yang dijalankannya. Semua ini dapat dikonfigurasi dengan aturan dan arahan yang berbeda di berkas /etc/postfix/master.cf. Untuk mematikan otentikasi sama sekali untuk port 25 (layanan smtpd) tambahkan direktif berikut:
smtp      inet  n       -       y       -       -       smtpd
    [..]
    -o smtpd_sasl_auth_enable=no
    [..]
Jika karena alasan tertentu klien menggunakan perintah AUTH yang sudah kedaluwarsa (beberapa klien surel yang sangat lama menggunakannya), interoperabilitas dengan mereka dapat diaktifkan menggunakan direktif broken_sasl_auth_clients.