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

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.

Kebanyakan layanan jaringan moderm memerlukan teknologi enkripsi agar beroperasi secara aman dan terpercaya, khususnya ketika digunakan pada internet publik. Sertifikat X.509 (yang mana dapat direferensikan sebagai Sertifikat SSL atau Sertifikat TLS) sering digunakan untuk tujuan ini. Sebuah sertifikat untuk domain tertentu seringkali dapat berbagi antara lebih dari satu layanan dibahas pada bagian ini.

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.

Sintaks berkas konfigurasi Exim4 memiliki kekhasan dan kurva belajarnya; namun, begitu keanehan ini dipahami, Exim4 merupakan peladen surel yang sangat lengkap dan hebat, yang dibuktikan dengan puluhan halaman dokumentasi.

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

11.1.1. Instalasi Postfix

Paket postfix menyertakan daemon SMTP utama. Paket lain (seperti postfix-ldap dan postfix-pgsql) menambahkan fungsionalitas tambahakan ke Postfix, termasuk mengakses basisdata terpetakan. 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.

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.

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

# 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_command = procmail -a "$EXTENSION"
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.

Pada umumnya mereka hanya boleh digunakan untuk tujuan pengujian, dan layanan normal harus menggunakan sertifikat nyata; ini dapat dihasilkan dengan prosedur yang dijelaskan dalam Bagian 10.2.1.1, “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.

Contoh 11.2. Direktif yang ditambahkan dalam berkas /etc/postfix/main.cf

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.

Contoh 11.3. Contoh berkas /etc/postfix/virtual

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

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.

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

Contoh 11.4. Direktif yang ditambahkan dalam berkas /etc/postfix/main.cf

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

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.

Contoh 11.5. Berkas /etc/postfix/vmailbox

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

KULTUR Masalah spam

"Spam" adalah istilah umum yang digunakan untuk menamai semua surel komersial yang tidak diinginkan (juga dikenal sebagai UCE) yang membanjiri kotak surat elektronik kita; individu-individu yang tidak bermoral yang mengirim mereka dikenal sebagai spammer. Mereka tidak peduli tentang gangguan yang mereka sebabkan, karena mengirimkan surel biayanya sangat rendah, dan hanya persentase yang sangat kecil dari penerima yang perlu tertarik dengan tawaran agar operasi spam menghasilkan lebih daripada biaya. Prosesnya kebanyakan otomatis, dan alamat surel yang dibuat publik (misalnya, di forum web, atau di arsip milis, atau di blog, dan sebagainya) akan ditemukan oleh robot spammer, dan menjadi sasaran pesan tak diharapkan yang tidak pernah berakhir.

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.

Contoh 11.6. Pembatasan Berbasis Alamat Klien

smtpd_client_restrictions = permit_mynetworks,
    warn_if_reject reject_unknown_client,
    check_client_access hash:/etc/postfix/access_clientip,
    reject_rbl_client sbl-xbl.spamhaus.org,
    reject_rbl_client list.dsbl.org

Ketika suatu variabel berisi daftar aturan, seperti pada contoh di atas, 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.

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.

TIP tabel access

Kriteria pembatasan termasuk tabel yang dapat dimodifikasi oleh administrator berisi daftar kombinasi pengirim, alamat IP, dan nama host yang diperbolehkan atau dilarang. Tabel ini dapat dibuat dari salinan berkas terkompresi /usr/share/doc/postfix-doc/examples/access.gz. Model ini didokumentasikan mandiri dalam komentar, yang berarti setiap tabel menjelaskan sintaksnya sendiri.

Tabel /etc/postfix/access_clientip menampung daftar alamat IP dan jaringan; /etc/postfix/access_helo berisi daftar nama domain; /etc/postfix/access_sender berisi alamat surel pengirim. Semua berkas ini harus diubah menjadi tabel hash (format yang dioptimalkan untuk akses cepat) setelah setiap perubahan, dengan perintah postmap /etc/postfix/berkas.

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.

Dua aturan terakhir menolak pesan yang berasal dari server yang tercantum dalam salah satu blacklist yang ditunjukkan. RBL adalah akronim untuk Remote Black List; ada beberapa daftar seperti itu, tetapi mereka semua memuat daftar 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 oleh nama server email pengirim; memeriksa validitas nama ini bisa menarik.

Contoh 11.7. Pembatasan pada nama yang diumumkan di EHLO

smtpd_helo_restrictions = permit_mynetworks,
    reject_invalid_hostname,
    check_helo_access hash:/etc/postfix/access_helo,
    reject_non_fqdn_hostname,
    warn_if_reject reject_unknown_hostname

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_hostname menolak surel ketika EHLO mengumumkan daftar nama host yang secara sintaksis salah. Aturan reject_non_fqdn_hostname menolak pesan ketika nama host yang diumumkan bukan fully-qualified domain name (yang memuat nama domain maupun nama host). Aturan reject_unknown_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.

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 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.8. Pemeriksaan pengirim

smtpd_sender_restrictions = 
    check_sender_access hash:/etc/postfix/access_sender,
    reject_unknown_sender_domain, reject_unlisted_sender,
    reject_non_fqdn_sender

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.

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.9. Pemeriksaan penerima

smtpd_recipient_restrictions = permit_mynetworks, 
    reject_unauth_destination, reject_unlisted_recipient, 
    reject_non_fqdn_recipient

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.

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.10. 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 hanya mengirimkan penolakan sebenarnya sebagai jawaban atas perintah RCPT TO.

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.

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

Istilah ekspresi reguler (disingkat menjadi regexp atau regex) mengacu ke notasi generik untuk mengekspresikan deskripsi dari isi dan/atau struktur serangkaian karakter. Karakter khusus tertentu memungkinkan mendefinisikan alternatif (misalnya, foo|bar cocok dengan "foo" atau "bar"), set karakter yang diizinkan (misalnya, [0-9] berarti setiap digit, dan . — dot — berarti sebarang karakter), kuantifikasi (s? cocok dengan s atau string kosong, dengan kata lain 0 atau 1 kali munculnya s; s+ cocok dengan satu atau lebih karakter s berturut-turut; dan seterusnya). Kurung memungkinkan pengelompokan hasil pencarian.

Sintaks yang tepat dari ungkapan-ungkapan ini bervariasi di seluruh alat yang menggunakan mereka, tapi fitur dasarnya sama.

→ http://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).

Karena milter-greylist menggunakan antarmuka milter Sendmail, konfigurasi sisi postfix-nya terbatas ke "smtpd_milters = unix:/var/run/milter-greylist/milter-greylist.sock". Halaman manual greylist.conf(5) mendokumentasikan /etc/milter-greylist/greylist.conf dan banyak cara untuk mengkonfigurasi milter-greylist. Anda juga harus menyunting /etc/default/milter-greylist untuk benar-benar mengaktifkan layanan.

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.13. 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.14. 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 yang menyebabkan masalah, baris ini dapat dijadikan komentar dan service postfix reload harus dijalankan sehingga perubahan ini diperhitungkan.

DALAM PRAKTEK Menguji antivirus

Setelah antivirus disiapkan, perilaku yang benar harus diuji. Cara termudah untuk melakukannya adalah dengan mengirim surel percobaan dengan lampiran yang berisi berkas eicar.com (atau eicar.com.zip), yang dapat diunduh secara daring:

→ http://www.eicar.org/86-0-Intended-use.html

Berkas ini bukan virus yang benar, tetapi berkas uji yang didiagnosa sebagai sebuah virus oleh semua perangkat lunak antivirus di pasar agar memungkinkan memeriksa instalasi.

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

11.1.7. 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.15. 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_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
[...]

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.