Category Archives

128 Articles
WordPress Modus Pemeliharaan

WordPress Modus Pemeliharaan

WordPress mematikan semua aktivitas saat diperbaharui. Dia akan muncul halaman Dalam Pemeliharaan (Maintenance Mode). Sayangnya, tampilan yang ada saat ini kurang menarik.

Saatnya mengubah tampilan menjadi lebih baik.

Buat Halaman PHP maintenance.php

Tanpa perlu plugin, cukup buat sebuah berkas PHP di wp-content/maintenance.php yang berisi:

<?php
$protocol = $_SERVER["SERVER_PROTOCOL"];
if ( 'HTTP/1.1' != $protocol && 'HTTP/1.0' != $protocol )
    $protocol = 'HTTP/1.0';
    header( "$protocol 503 Service Unavailable", true, 503 );
    header( 'Content-Type: text/html; charset=utf-8' );
?>
<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8">
    <title>Maintenance mode</title>
    <meta name="msapplication-TileColor" content="#5bc0de" />
    <meta name="msapplication-TileImage" content="assets/img/metis-tile.png" />

    <!-- Bootstrap -->
    <link rel="stylesheet" href="//cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/3.3.1/css/bootstrap.min.css">

    <!-- Font Awesome -->
    <link rel="stylesheet" href="//cdnjs.cloudflare.com/ajax/libs/font-awesome/4.2.0/css/font-awesome.min.css">
  </head>
  <body class="error">
    <div class="container">
      <div class="col-lg-8 col-lg-offset-2 text-center">
        <div class="logo">
          <h1>Teehee.... </h1>
        <img src='/wp-content/uploads/Maintenance.png'>
        </div>
        <p class="lead text-muted">Oops, you caught us upgrading. Please refresh this page a minute later.</p>
      </div>
    </div>
  </body>
</html>
<?php die(); ?>

Berkas ini sebenarnya hanya modifikasi dari modus pemeliharaan yang dimiliki WordPress. Saya menambahkan tiga berkas: dua berkas CSS yang ada di CDN dan satu berkas gambar (wp-content/uploads/Maintenance.php) yang saya buat sendiri menggunakan MyPaint. Klik gambar untuk mendapatkan kode sumber.

maintenis

A custom maintenance mode.

Bacaan Lebih Lanjut

Galat WP Cron Pada WordPress 4.3

Galat WP Cron Pada WordPress 4.3

Ada kesalahan pemrograman pada WordPress 4.3 sehingga mengakibatkan WP Cron menginjeksi tugas dengan rangkaian yang panjang. Galat ini ada di Galat #33423. Tambalan tersedia pada Tambalan #33646.

Masalah ini membuat beberapa situs yang saya kelola berbasis WordPress jatuh. Hal ini karena WordPress secara otomatis memperbaharui dirinya ke WordPress 4.3.

Saya memodifikasi Tambalan #33646 untuk menambal WordPress 4.3 menjadi berkas WP4.3-WPCronError.patch untuk lebih gampangnya. Berikut cara membetulkan WordPress 4.3:

  1. Unduh berkas WP4.3-WPCronError.patch. Supaya mudah, saya asumsikan berkas ada di /tmp.
  2. Masuk ke direktori WordPress (misalnya /var/www)
    cd /var/www
  3. Setelah itu, tambal WordPress 4.3 Anda. Sekali lagi, saya asumsikan berkas tambalan ada di /tmp. Kalau Anda beda, sesuaikanlah.
    patch -Np1 -i /tmp/WP4.3-WPCronError.patch_.txt
  4. Selesai.

Semoga bermanfaat.

HHVM dengan SupervisorD
supervisord spawned two hhvm with one as a backup

HHVM dengan SupervisorD

Sebelum ini saya telah membahas bagaimana menggunakan HHVM dengan Monit. Saat ini saya berusaha mengaplikasikan HHVM dengan Supervisord. Supervisord adalah sebuah aplikasi yang bertugas untuk mengatur proses-proses. Dia mirip dengan uWSGI, unicorn, gunicorn, systemd, dan lain sebagainya.

Eh, systemd? Bukankah systemd sebuah aplikasi init?

Iya, betul! Mereka semua memiliki fungsi yang kurang lebih sama. Namun, supervisord memiliki konfigurasi agnostik dibandingkan systemd. Maklum saja, systemd digunakan untuk sistem juga. Sekarang orang masih merasa ngeri kalau berhubungan dengan sistem. Ya, begitu, deh….

Skenario

Skenario yang digunakan sebagai contoh adalah sebagai berikut:

  • Supervisord akan dipakai untuk meluncurkan 2 proses HHVM.
  • HHVM yang pertama akan dipakai sebagai koneksi utama dengan NGINX.
  • HHVM yang kedua digunakan sebagai cadangan.

Untuk skenario pemasangan virtual host yang dipakai secara beramai-ramai, Anda dapat menyesuaikan dengan kebutuhan.

Pasang HHVM dan Supervisord

Cara memasang repositori Debian 7 dan Debian 8. Untuk Ubuntu dan distro-distro sejenis lainnya silakan cari sendiri. Saya pernah membahas di artikel terdahulu.

Mari pasang secara Debian:

sudo apt-get install hhvm supervisor

Selanjutnya konfigurasi.

Konfigurasi

Untuk konfigurasi HHVM yang sama/generik, saya akan menuliskannya dalam sebuah berkas konfigurasi HHVM. Untuk dua proses HHVM, konfigurasi supervisord akan berisi parameter yang berbeda dalam menjalankan HHVM.

HHVM

Buat sebuah berkas /etc/hhvm/hhvm_generik.ini — saya kurang kreatif memberi nama, silakan ganti dengan nama lain.

; php options

; php options


; hhvm specific
hhvm.server.type = fastcgi
hhvm.server.default_document = index.php
hhvm.log.level = Warning
hhvm.log.always_log_unhandled_exceptions = true
hhvm.log.runtime_error_reporting_level = 8191
hhvm.log.use_log_file = true
hhvm.log.file = /var/log/hhvm/error.log
hhvm.mysql.typed_results = false

hhvm.jit = 1
hhvm.eval.jit_warmup_requests = 1

hhvm.keep_perf_pid_map = 0
hhvm.perf_pid_map = 0
hhvm.perf_data_map = 0

hhvm.server.apc.enable_apc = true

Selanjutnya, konfigurasi berbeda untuk tiap proses HHVM.

supervisord

Konfigurasi untuk proses HHVM utama, /etc/supervisor/conf.d/hhvm.conf

[program:hhvm]
command=/usr/bin/hhvm -c /etc/hhvm/php.ini -c /etc/hhvm/server_wp.ini -m server
     -vPidFile=/var/run/hhvm/pid
     -vServer.FileSocket=/var/run/hhvm/hhvm.sock
     -vRepo.Central.Path=/var/run/hhvm/hhvm.hhbc
directory=/var/www/html
numprocs=1
autostart=true            ; start at supervisord start (default: true)
autorestart=unexpected    ; auto restart if HHVM dies
startretries=3
user=www-data  ; setuid to this UNIX account to run the program

Selanjutnya, saya akan buat konfigurasi untuk proses HHVM cadangan. Saya akan menandai beberapa baris yang berbeda.

[program:hhvm2]
command=/usr/bin/hhvm -c /etc/hhvm/php.ini -c /etc/hhvm/server_wp.ini -m server
     -vPidFile=/var/run/hhvm/pid2
     -vServer.FileSocket=/var/run/hhvm/hhvm2.sock
     -vRepo.Central.Path=/var/run/hhvm/hhvm.hhbc
directory=/var/www/html
numprocs=1
autostart=true            ; start at supervisord start (default: true)
autorestart=unexpected    ; auto restart if HHVM dies
startretries=3
user=www-data  ; setuid to this UNIX account to run the program

Supaya jelas, perubahan yang saya buat untuk proses HHVM kedua:

  • Baris pertama, ubah nama grup proses menjadi hhvm2. Istilah grup proses karena bisa jadi dalam hhvm2 ada beberapa proses.
  • Baris ketiga, ubah nama proses menjadi /var/run/hhvm/pid2
  • Baris keempat, ubah nama socket menjadi /var/run/hhvm/hhvm2.sock]

Saya masih menggunakan konvensi direktori yang lama, /var/run. Untuk konvensi saat ini, sebaiknya ditulis ke direktori /run. Anda sebaiknya membiasakan diri saja dengan direktori itu.

Untuk skenario yang lain, repositori kode HHVM pada baris ke-5 dapat ditaruh pada berkas yang berbeda. Kebetulan saya menggunakan pengguna yang sama, jadi saya menggunakan satu repositori saja.

Pak, itu aman, ‘kah?

Repositori HHVM itu sendiri adalah sebuah berkas SQLite3. Menurut FAQ SQLite, SQLite3 menggunakan penguncian sistemberkas saat menulis. Sehingga, hanya satu saja proses yang bisa menulis. Sayangnya, untuk sistemberkas NFS dan FAT mekanisme itu tidak terjamin. Ingatlah untuk tidak menaruh berkas repositori di NFS.

Repositori HHVM berukuran sangat besar. Hal ini dapat membebankan untuk skenario inang dengan banyak situs. Untuk menghemat, Anda dapat saja membuat repositori HHVM dengan perizinan grup dapat menulis (0660). Lalu, setiap pengguna yang menjalankan HHVM dimasukkan ke grup itu. Ah, tapi ini di luar skenario dan saya takkan membahas untuk saat ini.

nginx

Ubah upstream NGINX untuk menambahkan satu HHVM sebagai cadangan. Sebagai contoh, saya menaruh upstream dalam sebuah berkas /etc/nginx/conf.d/upstream.conf

# Upstream to abstract backend connection(s) for PHP.
upstream php {
  server unix:/var/run/hhvm/hhvm.sock;
  server unix:/var/run/hhvm/hhvm2.sock backup;
}

Kira-kira begitulah untuk setiap konfigurasi. Selanjutnya, mari menjalankan setiap proses.

Jalankan Semua

Selanjutnya, jalankan proses.

supervisord

Pertama-tama, tambahkan aturan-aturan HHVM yang baru dibuat.

sudo supervisorctl reread
sudo supervisorctl add hhvm
sudo supervisorctl add hhvm2

Baris pertama meminta supervisord untuk membaca ulang konfigurasi. Dua baris selanjutnya menjalankan HHVM.

Oh, iya, kalau misalnya ada perubahan di berkas konfigurasi, jalankan:

sudo supervisorctl update hhvm

Ganti hhvm dengan nama grup proses yang lain.

nginx

Jalankan NGINX seperti biasa.

sudo invoke-rc.d nginx restart

Selesai.

Bacaan Lebih Lanjut

WordPress, NGINX, HHVM, dan Monit

WordPress, NGINX, HHVM, dan Monit

Bagi yang sudah pernah berurusan dengan situs yang berat, Anda pasti juga jengah dengan kelakuan PHP-FPM. Ada beberapa solusi yang saat ini tersedia:

Beberapa waktu yang lalu saya sudah membahas tentang uWSGI. Sekarang, saya mau mencoba teknologi HHVM. Doakan saja supaya saya tidak malas dan juga mau mencoba HippyVM dan PHP7-FPM sehingga saya bisa menuliskan untuk Anda.

Pasang HHVM

Cara pasang HHVM di berbagai sistem operasi ada di sini. Saya asumsikan hendak dipasang di sistem operasi Debian Jessie.

sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0x5a16e7281be7a449
echo deb http://dl.hhvm.com/debian jessie main | sudo tee /etc/apt/sources.list.d/hhvm.list
sudo apt-get update
sudo apt-get install hhvm

Perintah-perintah ini pada intinya memasang kunci paket repo HHVM dan menambahkan repo tersebut ke daftar repositori sistem. Kemudian, perbaharui daftar paket yang tersedia dan pasang HHVM.

Selanjutnya, ubah konfigurasi HHVM di /etc/hhvm/server.ini menjadi

; php options

pid = /var/run/hhvm/pid

; hhvm specific 
hhvm.server.file_socket=/var/run/hhvm/hhvm.sock
hhvm.server.type = fastcgi
hhvm.server.default_document = index.php
hhvm.log.level = Warning
hhvm.log.always_log_unhandled_exceptions = true
hhvm.log.runtime_error_reporting_level = 8191
hhvm.log.use_log_file = true
hhvm.log.file = /var/log/hhvm/error.log
hhvm.repo.central.path = /var/run/hhvm/hhvm.hhbc
hhvm.mysql.typed_results = false

; Generate JIT codes sooner!
hhvm.eval.jit_warmup_requests = 1

; Disable Perf debugging
hhvm.keep_perf_pid_map = 0
hhvm.perf_pid_map = 0
hhvm.perf_data_map = 0

Ada beberapa perbedaan dengan konfigurasi biasa. Berikut yang penting:

  • Saya memilih untuk menggunakan socket dari pada port TCP karena lebih aman dalam menentukan hak akses.
  • Saya menyuruh HHVM untuk segera mengaktifkan optimasi dari sejak awal. Hal ini mengakibatkan peladen agak lama di awal.
  • Saya mematikan fungsi profiling. Fungsi ini berguna kalau Anda mau men-debug kode PHP Anda yang dieksekusi oleh HHVM. Kemungkinan besar, Anda terlalu malas seperti saya. Fungsi ini hanya akan memenuhi /tmp dengan berkas peta performa.

Pasang NGINX

Pertama-tama, pasang NGINX:

sudo apt-get install nginx

Set upstream NGINX ke HHVM di berkas /etc/nginx/conf.d/upstream.conf

# Upstream to abstract backend connection(s) for PHP.
upstream php-hhvm {
  server unix:/var/run/hhvm/hhvm.sock;
}

Lalu, buat sebuah blok konfigurasi /etc/nginx/php-hhvm

location ~ \.(hh|php)$ {
    try_files $uri =404;

    fastcgi_keep_conn on;
    fastcgi_pass   php-hhvm;
    fastcgi_index  index.php;
    fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include        fastcgi_params;
}

Ini saya ambil dan modifikasi sedikit dari hhvm.conf yang biasanya terpasang saat kita memasang HHVM.

Nah, setiap Virtual Host yang mau menggunakan, tinggal mengikutkan berkas php-hhvm di dalam berkas konfigurasinya. Misalnya, kita buat sebuah berkas /etc/nginx/sites-available/default

server {
    # Anything not directed at specific host will hit "Welcome to nginx"
    listen 80 default_server;
    server_name _;
    
    root /var/www/html;
    index index.php index.html index.htm;

    location / {
            try_files $uri $uri/ /index.php?$args ;
    }

        include php-hhvm;

}

Jangan lupa, ini cuma contoh! Untuk mesin produksi, tolong ubah berkas direktori dan tambahkan beberapa aturan untuk menghindari injeksi.

Selanjutnya, pasang seperti biasa ala Debian:

sudo ln -s /etc/nginx/sites-available/default /etc/nginx/sites-enabled/default
sudo invoke-rc.d nginx reload

Beres.

Eits! Nanti dulu, Kisanak! Supaya situs tetap berjalan, mari pasang Monit untuk memonitor keberadaan HHVM. Menurut pengalaman saya, awal-awal HHVM rentan terhadap aplikasi yang harus dinyalakan ulang.

Pasang Monit

Pasang Monit.

sudo apt-get install monit

Buat konfigurasi Monit untuk HHVM di /etc/monit/conf.d/hhvm yang isinya:

check process hhvm with pidfile /var/run/hhvm/pid
  group hhvm
  start program = "/usr/sbin/service hhvm start" with timeout 60 seconds
  stop program = "/usr/sbin/service hhvm stop"
  if failed unixsocket /var/run/hhvm/hhvm.sock then restart
  if mem > 400.0 MB for 1 cycles then restart
  if 5 restarts with 5 cycles then timeout

Untuk dapat memonitor Monit, langkah opsional yang dapat diambil adalah dengan mengubah 3 baris berikut pada /etc/monit/monitrc

set httpd port 2812 and
   use address localhost  # only accept connection from localhost
   allow localhost        # allow localhost to connect to the server and

Kalau pada konfigurasi Jessie, baris-baris itu mulai dari baris ke-130.

Setelah selesai, muat ulang Monit:

invoke-rc.d restart monit

Kalau mau lihat Monit, silakan ketik:

sudo monit status

Tentunya, langkah opsional dikerjakan. Bila tidak, maka Monit tak dapat dilihat.

Selesai!

Paket ca-certificates-java Pada Ubuntu Rusak

Paket ca-certificates-java Pada Ubuntu Rusak

Saat saya hendak membangun Gradle, saya selalu mendapat pesan kesalahan seperti ini:

Exception in thread "main" javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty

Hal ini terjadi saat saya hendak mengunduh sebuah berkas dari HTTPS. Semua versi Java yang terpasang, baik OpenJDK maupun Oracle 7, 8 tidak dapat menggunakan. Usut punya usut, ternyata ada masalah pada pemasangan paket ca-certificates-java pada Ubuntu Vivid yang saya gunakan. Saya lihat besar berkasnya:

$ ls -al /etc/ssl/certs/java/cacerts 
-rw-r--r-- 1 root root 32 Apr 29 07:21 /etc/ssl/certs/java/cacerts

Cuma 32 byte!

Solusi adalah dengan membuat ulang berkas tersebut.

sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure

Selesai.

Sumber:

NGINX, uWSGI, PHP pada Debian Jessie

NGINX, uWSGI, PHP pada Debian Jessie

Solusi PHP-FPM sudah tak mencukupi lagi untuk saya. Sering kali saya mendapati sistem-sistem dengan pengunjung banyak tidak bereaksi. Padahal, semua layanan menyala.

Dari kasak-kusuk di Internet yang saya dapati bahwa ternyata PHP-FPM harus sering-sering dijalankan ulang. Bahkan, ada yang memasang CRON untuk menjalankan ulang PHP-FPM setiap 15 menit sekali. Saya pun terenyuh.

Untungnya, ada sebuah solusi, yakni uWSGI. Awalnya, ia hanya untuk menjalankan layanan web berbasis Python. Namun, sekarang ia berkembang untuk menjalankan hampir apa saja. Enaknya dia, setiap proses dijalankan sebagai pengguna biasa (non-root).

Cara Pasang

Cara pasang seperti biasa:

sudo apt-get install nginx uwsgi uwsgi-plugin-php

Seperti biasa.

Konfigurasi

NGINX

Cara konfigurasi sama seperti PHP-FPM, tetapi sedikit berbeda. Berikut sekilas contoh konfigurasi salah satu virtual host (/etc/nginx/sites-available/xxx)

server {
  ...

  location / {
    index   index.php;
    try_files $uri $uri/ /index.php?$args;
  }

  ...

  location ~ .php$ {
     include uwsgi_params;
     uwsgi_modifier1 14; 
     uwsgi_pass unix:/tmp/uwsgi_webphp.sock;
  }
}

Perhatikan bahwa tidak ada yang berubah dari baris lain. Hanya blok pengolah PHP yang diubah dari FastCGI untuk PHP-FPM menjadi UWSGI. Aplikasi nginx memiliki antarmuka alami dengan uWSGI.

Seperti biasa, aktifkan virtual host dengan:

sudo ln -s /etc/nginx/sites-{available,enabled}/xxx
sudo service nginx restart

Selanjutnya uWSGI.

uWSGI

Pada Debian Jessie, virtual host uWSGI terletak pada /etc/uwsgi/apps-available/xxx.ini

Perhatikan kalau uWSGI mengharapkan ekstensi .ini pada setiap berkas konfigurasi virtual host yang valid.

Mari buat berkas /etc/uwsgi/apps-available/webphp.ini (Iya, saya kurang kreatif, silakan ganti nama berkas dengan apa saja)

[uwsgi]
socket=/tmp/uwsgi_webphp.sock
pidfile2=/tmp/uwsgi_webphp.pid
daemonize=/var/log/uwsgi/webphp.log
plugins=php

chdir=/var/www
cheaper=4
close-on-exec=1
harakiri=360
max-requests=128
processes=8
master=1
uid=www-data
gid=www-data
chmod=666
log-5xx=1
vacuum=1
post-buffering=8192

Perhatikanlah yang berbeda ada pada baris 3! Gunakan pidfile2, jangan pidfile saja! Opsi pidfile2 yang membuat adalah pengguna tersebut, bukan root. Bila menggunakan pidfile, layanan uwsgi akan gagal dikendalikan oleh Debian.

Aktifkan konfigurasi ala Debian:

sudo ln -s /etc/uwsgi/apps-{available,enabled}/webphp.ini
sudo service uwsgi restart

Selesai.

ACL Slightly Differ from Apache HTTPd 2.2 to 2.4

Upgrading server from Apache HTTPd (Apache2) 2.2 to 2.4 has its bumps here and there. One of them is ACL. If you encounter denied access and on error log encounter this:

AH01630: client denied by server configuration

It probably means you had this in your config:

Order allow,deny
Allow from all

Those two lines must be changed into

Require all granted

Done.

Reference

ffmpeg/libav conflict management: USE=libav

2015-02-01-use-libav
  Title                     ffmpeg/libav conflict management: USE=libav
  Author                    Michał Górny 
  Posted                    2015-02-01
  Revision                  1

The support for automatic choice between ffmpeg and libav is going to be
deprecated in favor of explicit choice via USE flags. This change aims
to solve multiple repeating issues, including Portage undesirably
wanting to replace one package with the other, lack of proper reverse
dependency on ffmpeg/libav upgrades and some of the hard-to-understand
upgrade failures involving blockers. It also may be used to make ffmpeg
and libav co-installable in the future.

The current USE=ffmpeg will maintain its role of enabling optional
support for ffmpeg or a compatible implementation (libav) in a package.
However, whenever appropriate additional USE=libav will be introduced to
control the preference of one implementation over the other.

Users who currently use libav (the Gentoo default) do not have to
perform any action since USE=libav is enabled by default. It should be
noted that the users still need to enable USE=ffmpeg on packages with
optional libav support as well. Users who want to use ffmpeg instead
need to specify USE=-libav in make.conf explicitly.

Please also note that some packages support only one of the two
implementations. An attempt to install one of those packages may result
in blockers requiring the user changes the global USE=libav state.
The most notable example of such package is media-video/mplayer.
media-video/mpv may be used as a replacement for users who prefer libav.

Please do not alter the state of 'libav' flag on a per-package basis
(e.g. via package.use). The flag needs to be set globally to have
consistent value throughout all packages. Otherwise, blockers will
prevent upgrades.

— taken from GENTOO ESELECT NEWS.

CPU_FLAGS_X86 introduction

CPU_FLAGS_X86 introduction

The USE flags corresponding to the instruction sets and other features specific to the x86 (amd64) architecture are being moved into a separate USE flag group called CPU_FLAGS_X86. In order not to lose CPU-specific optimizations, users will be required to update their make.conf (and package.use) file. For example, if the following USE flags were present: USE=”mmx mmxext sse sse2 sse3″ Those flags need to be copied into: CPU_FLAGS_X86=”mmx mmxext sse sse2 sse3″ Please note that the same CPU_FLAGS_X86 variable is used both on x86 and amd64 systems. When in doubt, you can consult the flag descriptions using one of the commonly available tools, e.g. `equery uses` from gentoolkit: $ equery uses media-video/ffmpeg Most of the flag names match /proc/cpuinfo names, with the notable exception of SSE3 which is called ‘pni’ in /proc/cpuinfo (please also do not confuse it with distinct SSSE3). To help users enable the correct USE flags, we are providing a Python script that generates the correct value using /proc/cpuinfo. It can be found in the app-portage/cpuinfo2cpuflags package: $ emerge -1v app-portage/cpuinfo2cpuflags $ cpuinfo2cpuflags-x86 In order to ensure safe migration and maintain compatibility with external repositories, it is recommended to preserve the old USE settings for a period of one year or until no package of interest is still using them.

PS: This is a verbatim copy of a reminder in ESELECT NEWS. I take it to this blog as a reminder for myself in the future.

Memperketat Keamanan Situs

Memperketat Keamanan Situs

Pendahuluan

Halo, jumpa lagi di hari Jumat!

Karena isu keamanan akhir-akhir ini semakin ketat, saya merasakan perlunya pembelajaran kepada masyarakat Indonesia mengenai penggunaan enkripsi yang tepat. Entahlah, mungkin ini juga karena saya meneliti Owncloud terlalu jauh. Atau mungkin ini sekedar tulisan menambah kuota tulisan saya di blog. Ilmu memang untuk dibagi.

Orang pasti sudah tahu tentang BEAST, CRIME, dan HEARTBLEED. BEAST adalah proof-of-concept serangan terhadap enkripsi TLSv1.0 yang menyebabkan sebuah domain dapat dibajak dari implementasi TLS v1.0 yang buruk di sistem operasi. Lalu, ada CRIME yang menyerang implementasi kompresi HTTP pada TLS dan SPDY. Yang menghebohkan berikutnya adalah HEARTBLEED yang menyerang implementasi cacat OpenSSL pada implementasi ekstensi TLS heartbeat.

Yang terakhir dan teranyar adalah POODLE, eksploit terhadap SSLv3 yang menyebabkan sekarang ini orang dipaksa untuk mematikan SSLv3. Ya, kecuali Anda menggunakan IE6/7 pada Windows XP yang belum diperbaharui, sebenarnya SSLv3 sudah lama tidak diperlukan. Bahkan, sebaiknya Anda memaksa peramban Anda langsung menggunakan TLS v1.2.

Ekstensi AES-NI

Tapi… tapi… bukankah menggunakan enkripsi membuat peladen kurang responsif?

Itu dulu! Sekarang, ‘kan, sudah ada ekstensi AES-NI pada prosesor x86. Jadi, enkripsi dilakukan secara langsung oleh CPU. Saya melakukan eksperimen kecil untuk memperlihatkan perbedaan operasi biasa dan menggunakan AES-NI.

Operasi biasa menggunakan instruksi CPU normal.

$ OPENSSL_ia32cap="~0x200000200000000" openssl speed -elapsed -evp aes-128-cbc
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128-cbc for 3s on 16 size blocks: 34349970 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 64 size blocks: 8984170 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 256 size blocks: 2337382 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 1024 size blocks: 589989 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 8192 size blocks: 74022 aes-128-cbc's in 3.00s
OpenSSL 1.0.1i 6 Aug 2014
built on: Fri Aug  8 06:23:32 WIB 2014
options:bn(64,64) rc4(8x,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx) 
compiler: x86_64-pc-linux-gnu-gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -O2 -pipe -march=native -mtune=native -fomit-frame-pointer -flto=8 -floop-interchange -ftree-loop-distribution -floop-strip-mine -floop-block -ftree-vectorize -fno-strict-aliasing -Wa,--noexecstack
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128-cbc     183199.84k   191662.29k   199456.60k   201382.91k   202129.41k

Sedangkan berikut operasi menggunakan instruksi AES-NI.

$ openssl speed -elapsed -evp aes-128-cbc
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128-cbc for 3s on 16 size blocks: 99416661 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 64 size blocks: 27157194 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 256 size blocks: 7746016 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 1024 size blocks: 2005119 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 8192 size blocks: 253147 aes-128-cbc's in 3.00s
OpenSSL 1.0.1i 6 Aug 2014
built on: Fri Aug  8 06:23:32 WIB 2014
options:bn(64,64) rc4(8x,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx) 
compiler: x86_64-pc-linux-gnu-gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -O2 -pipe -march=native -mtune=native -fomit-frame-pointer -flto=8 -floop-interchange -ftree-loop-distribution -floop-strip-mine -floop-block -ftree-vectorize -fno-strict-aliasing -Wa,--noexecstack
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128-cbc     530222.19k   579353.47k   660993.37k   684413.95k   691260.07k

Berikut tabel hasilnya:

Instruksi CPU Tipe 16-bit 64-bit 256-bit 1024-bit 8192-bit
AES-NI aes-128-cbc 530222,19 579353,47 660993,37 684413,95 691260,07
Normal 183199,84 191662,29 199456,6 201382,91 202129,41
Performa 2,8942284557 3,0227827811 3,313970909 3,3985701667 3,4198886248
Total Performa AES-NI 3,2098881874

Tampak bahwa dalam kasus ini, penggunakan AES-NI pada OpenSSL meningkatkan performa 3 kali lipat.

Dukungan AES-NI

Untuk mengetahui apakah prosesor peladen Anda mendukung AES-NI, silakan lihat dengan:

$ cat /proc/cpuinfo  | grep aes
flags           : ... aes ...

Kalau didukung, akan ada tulisan ‘aes’. Biasanya, sih, untuk prosesor AMD dan Intel yang baru [baca: keluaran tahun-tahun ini] sudah mendukung instruksi AES-NI. Kalau pun belum, bisa langsung saja mengompilasi OpenSSL dengan menggunakan instruksi SSE4 atau AVX. Ya, tapi itu di luar cakupan tulisan ini agar tidak terlalu rumit.

Untuk Debian Wheezy, OpenSSL 1.0.1e yang digunakan akan secara otomatis mendeteksi AES-NI. Tidak perlu mengompilasi sendiri untuk versi Debian tersebut. Untuk sistem operasi yang lain, silakan konsultasi kepada Mbah Gugel.

Bila Anda menggunakan KVM atau Proxmox, pastikan Anda menggunakan tipe CPU Host. Cara lain adalah pastikan instruksi AES-NI diperbolehkan untuk KVM.

Konfigurasi NGINX

Karena OpenSSL transparan, maka tidak ada yang perlu dipusingkan oleh NGINX untuk menggunakan AES-NI. NGINX hanya perlu memberitahukan protokol enkripsi yang dipakai untuk HTTPS.  Untuk itu, perhatikan contoh konfigurasi NGINX:

server {
        listen   80;
        listen  [::]:80 ipv6only=on;
        server_name  www.contoh.aja;
        server_name_in_redirect on;
        port_in_redirect on;

        access_log  /var/log/nginx/normal.access.log;
        error_log  /var/log/nginx/normal.error.log;

        ## redirect http to https ##
        rewrite        ^ https://$server_name$request_uri? permanent;
}

server {
        listen   443 ssl spdy;
        listen [::]:443 ipv6only=on ssl spdy;

        server_name  www.contoh.aja;
        server_name_in_redirect on;
        port_in_redirect on;

        ssl  on;
        ssl_certificate /etc/nginx/ssl.cert;
        ssl_certificate_key /etc/nginx/ssl.key;
        
        ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers         "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS";
        ssl_prefer_server_ciphers on;
        ssl_session_cache   shared:SSL:10m;
        ssl_session_timeout 10m;

        access_log  /var/log/nginx/ssl.access.log;
        error_log  /var/log/nginx/ssl.error.log;

        ## HERE PHP ENGINE AND OTHER REWRITE RULES ##
}

Saya akan mencoba menjelaskan beberapa bagian yang penting. Saya mengasumsikan Anda sudah tahu mengonfigurasi NGINX secara dasar sehingga saya tak perlu menjelaskan semuanya. Atau, setidaknya Anda bisa mencari langsung di Internet.

Saya sengaja tidak menyertakan aturan FastCGI PHP dan aturan-aturan rewrite untuk mengurangi kompleksitas kode. Ada banyak tutorial dasar untuk menyertakan aturan FastCGI. Lagipula, untuk aturan-aturan rewrite tergantung kepada aplikasi yang kita gunakan (Drupal, WordPress, dsb.).

Yak, langsung saja.

Mendengar di IPv4 dan IPv6

Berikut sintaksis agar NGINX mendengar semua antarmuka jaringan (IPv4 dan IPv6).

listen   80;
listen  [::]:80 ipv6only=on;

Ada alasan mengapa mengaktifkan dual stack. Universitas Indonesia (UI) sudah sejak lama memiliki satu blok (/16) IPv4 kelas B. Karena termasuk historical member dari IANA, UI juga beruntung mendapatkan satu blok /48 IPv6. Itu sebabnya, hampir semua peladen UI sudah memiliki IPv6 sendiri berikut IPv4 publik.

Mengarahkan Semua ke HTTPS

Berikut sintaksis untuk mengarahkan koneksi HTTP ke HTTPS.

rewrite        ^ https://$server_name$request_uri? permanent;

Ada tutorial lama yang menyampur koneksi HTTPS dan HTTP. Hal ini tidak sesuai dengan prinsip keamanan. Bila memang situs ingin aman sepenuhnya, maka harus semuanya harus menggunakan HTTPS. Konten campuran (berisi HTTP dan HTTPS) tidak disarankan dan beberapa peramban akan cerewet tentang itu.

Mengaktifkan SPDY

Berikut sintaksis agar NGINX menggunakan SSL (HTTPS) dengan SPDY.

listen   443 ssl spdy;
listen [::]:443 ipv6only=on ssl spdy;

Untuk akselerasi HTTPS, Google mengembangkan teknik SPDY. Hampir semua peramban modern mendukung protokol SPDY. Saya pernah membahas ini.

Mengaktifkan SSL

Baris-baris inilah yang mengaktifkan enkripsi HTTPS (SSL).

ssl  on;
ssl_certificate /etc/nginx/ssl.cert;
ssl_certificate_key /etc/nginx/ssl.key;

Baris ssl_certificate mengarahkan ke berkas sertifikat peladen. Ada tiga jenis skenario untuk berkas sertifikat peladen:

  1. Untuk menambah legitimasi, biasanya sertifikat ditandatangani oleh Certificate Authority (CA) yang sudah diakui. StartSSL menyediakan layanan ini dengan gratis. Kalau mau yang murah ada RapidSSL atau Komodo. Kalau mau lebih bonafide, gunakan VeriSign. Mereka ini biasanya sertifikat utamanya (root certificate) sudah dipasang di sistem operasi/peramban. Root certificate adalah sertifikat CA yang dipakai untuk melegitimasi sertifikat sebuah server.
  2. Ada juga organisasi yang membuat root certificate sendiri. Biasanya, mereka memasang sendiri root certificate ke sistem operasi/peramban pengguna. Ada banyak tutorial tentang itu, terutama Windows Server dan UNIX.
  3. Yang paling jamak digunakan di tutorial-tutorial biasanya menggunakan sertifikat yang ditandatangani sendiri (self-signed).

Silakan pilih skenario yang terbaik. Untuk situs bisnis biasanya menggunakan CA pihak ketiga (poin 1). Namun, untuk Intranet biasanya menggunakan poin 2.

Baris berikutnya ssl_certificate_key mengarahkan berkas kunci privat peladen. Pastikan berkas ini hanya bisa diakses baca-saja oleh root (0400).

Parameter Tambahan

Berikut parameter tambahan yang opsional. Parameter-parameter ini yang memperkuat enkripsi situs.

Hanya Gunakan TLS

Protokol SSLv3 sudah tamat semenjak POODLE beberapa hari yang lalu. Banyak yang menyarankan untuk mematikan protokol ini. Ya, berhubung protokol ini sudah sangat lama, wajar saja. Lagipula, hanya IE6/7 yang menggunakan Windows XP SP3 yang belum ditambal saja yang terpengaruh. Sisanya, dunia sudah mengenal TLS sejak lama.

Ya sudah, cukup aktifkan semua versi protokol TLS saja.

ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;

Protokol TLS pun sebenarnya tidak begitu aman. Kalau mau paranoid, hanya aktifkan TLSv1.2 saja. Tentu saja, ini mengurangi jumlah pengunjung dan peramban yang bisa mengakses situs kita.

Gunakan SHA256 AES-GCM dengan Forward Secrecy dan RC4 Sebagai Cadangan

Semenjak tahun 2011, SHA1 dianggap sudah tidak aman lagi. Lebih parah lagi, Google akan mempenalti situs-situs yang masih menggunakan SHA1 pada 1 Januari 2017. Artinya, semua situs yang masih memakai sertifikat dengan tanda tangan SHA1 akan dianggap tidak aman oleh produk-produk Google.

Bila Anda masih baru mau memasang sertifikat, gunakan sertifikat dengan tanda tangan SHA256. Atau kalau lebih bagus lagi, gunakan SHA387. Tetapi, untuk SHA387 masih jarang dan lagi mahal.

Ada banyak protokol pertukaran kunci dan saya tidak mau terlalu detail. Saat ini protokol yang aman dari gangguan adalah AES-GCM dan RC4. Protokol RC4 sudah lama dan relatif aman. Sedangkan GCM masih relatif baru, sehingga beberapa peramban lama tidak mendukung.

[Lama itu hitungannya 10 s.d. 20 tahun yang lalu, ya, kawan-kawan.]

Saat ini RC4 disarankan untuk ditinggalkan. Bukan berarti dia tidak aman. Sudah ada metodenya, tetapi untuk bisa membobol RC4 saat ini memerlukan sumber daya yang sangat besar. Jadi, RC4 relatif cukup aman.

Penggunaan AES-GCM disarankan oleh karena adanya instruksi AES-NI yang mempercepat percepat perhitungan.  Teknik ini peningkatan implementasi dari AES-CBC dengan menggunakan instruksi perangkat keras. Itu sebabnya, AES-CBC disarankan ditinggalkan.

Berikut instruksinya.

ssl_ciphers         "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS";

Oh, iya, satu lagi. Dalam konfigurasi ini diaktifkan mode Forward Secrecy yang ada di TLSv1.2.

Mengaktifkan Urutan Enkripsi Di Sisi Server

Instruksinya:

ssl_prefer_server_ciphers on;

Instruksi ini mengakibat peladen akan menyuruh klien untuk menggunakan metode enkripsi yang diinginkan sesuai dengan urutan. Ini mengurangi kemungkinan klien yang sudah mendukung TLSv1.2 malah menggunakan versi terdahulu karena konfigurasi perambannya. Hal ini bisa memitigasi terhadap serangan BEAST.

Menyimpan Sesi SSL

Instruksinya:

ssl_session_cache   shared:SSL:10m;
ssl_session_timeout 10m;

Untuk keperluan optimasi, NGINX dapat menyimpan sesi SSL pada tembolok. Ada dua jenis yang didukung. Yang pertama, tembolok tersebut disimpan oleh NGINX sehingga bisa diakses oleh sesama proses-proses pekerja NGINX. Yang kedua, per pekerja menggunakan tembolok yang disediakan oleh OpenSSL. Disarankan untuk menggunakan tembolok NGINX saja.

Menurut NGINX, 1 MB mampu menampung 4000 sesi. Konfigurasi ini menggunakan 10MB sehingga kira-kira ada 40000 sesi yang didukung. Setiap sesi ini disimpan selama 10 menit saja. Silakan dikonfigurasikan sesuai kemampuan peladen Anda.

Terakhir

Setelah semua selesai, silakan menyalakan ulang NGINX. Mari saya rekap untuk Anda:

  1. Gunakan SPDY untuk mempercepat koneksi HTTPS.
  2. Gunakan kunci dengan algoritma SHA256 atau lebih yang sudah divalidasi oleh CA.
  3. Gunakan protokol TLS teranyar dengan AES-GCM dengan RC4 sebagai cadangan.
  4. Gunakan tembolok untuk mengoptimasi penggunaan TLS.

Anda pun sudah memiliki peladen yang cukup handal. Anda bisa mempelajari teknik-teknik tambahan lain mengenai SSL, misalnya menggunakan OCSP.

Terakhir, Anda perlu mengedukasi pengguna Anda agar tidak memberikan sandi kepada siapa pun dan mengganti sandi secara periodik, misalnya 6 bulan sekali. Percuma punya infrastruktur yang handal tanpa pengguna yang paham.

Nota Bene

Gunakan pihak ketiga untuk menguji SSL. Saya menggunakan perkakas dari Qualys SSL Lab. Contoh hasil pengujian konfigurasi SSL pada Blog Staff UI.

SSL Labs test on Blog Staff UI. Yeah, we need to upgrade into SHA256. The certificate is issued not long ago.

SSL Labs test on Blog Staff UI. Yeah, we need to upgrade into SHA256. The certificate is issued not long ago.

Bacaan Lebih Lanjut

Owncloud: Solusi Perangkat Lunak Bebas

Owncloud: Solusi Perangkat Lunak Bebas

Untuk memenuhi kuota menulis, saya akan menulis mengenai pemasangan Owncloud. Ini bukan karena Snowden yang memberitahukan untuk menghindari menggunakan Facebook, Google, dan Twitter. Tetapi, karena saya memang sedang iseng tentang perangkat lunak ini. Coba ada yang meminta untuk mencoba sesuatu yang lain, saya pasti menulis tentang itu.

Berbeda dengan konfigurasi biasa, saya menggunakan NGINX sebagai peladen HTTP dan PHP-FPM sebagai penyedia PHP. Hal ini karena ada WAF yang bisa dikonfigurasi nantinya apa bila Anda mau membuat ini serius. Ada banyak tambahan yang bisa dibuat dari Owncloud.

Yak, tanpa banyak basa-basi, mari kita memasang. Saya asumsikan Anda telah memasang NGINX dan MySQL pada peladen Anda. Saya juga mengasumsikan Anda menggunakan Debian atau turunannya (BlankOn atau Ubuntu).

Menyiapkan Basisdata

Pertama-tama, siapkan basisdata terlebih dahulu, masuk ke dalam terminal MySQL sebagai Administrator:

sudo mysql --defaults-file=/etc/mysql/debian.cnf

Buat basisdata dan berikan hak akses ke klien Owncloud:

CREATE DATABASE awansendiribd;
GRANT ALL PRIVILEGES ON awansendiribd.* TO 'megawan'@'localhost' IDENTIFIED BY 'week^u2heoQuuv]ah9sah]B~ahShie?t';
FLUSH PRIVILEGES;
QUIT;

Saya menggunakan pwgen untuk membuat sandi yang aman:

pwgen -y 32

Anda bisa buat sendiri sandi Anda, ganti nama basisdata, dan nama klien basisdata yang akan digunakan. Hal ini agar Owncloud Anda bisa aman. Belajarlah untuk aman.

Menyiapkan Rumah

Pada konfigurasi kali ini, saya menggunakan pengguna tersendiri untuk Owncloud. Bukan pengguna baku www-data, tetapi yang berbeda — Anda pun bisa berbeda dari tutorial ini. Caranya:

sudo adduser --home /srv/awani --disabled-password awani

Saya membedakan instalasi Owncloud dengan datanya. Mari buat kedua direktori tersebut.

sudo -u awani mkdir /srv/awani/{app,data}

Selanjutnya, unduh dan pasang Owncloud. Pada penulisan ini, yang terbaru adalah Owncloud 7.0.2. Silakan cek versi terbaru yang mungkin sudah ada saat Anda mencoba ini lagi di masa mendatang.

wget https://download.owncloud.org/community/owncloud-7.0.2.tar.bz2 -O- | \
sudo -u awani tar xvfj - -C /srv/awani/app --strip 1

Sesuaikan dengan direktori Anda sendiri.

Menyiapkan konfigurasi Peladen

Ada dua yang perlu disiapkan:

  1. Peladen PHP-FPM untuk konfigurasi PHP5.
  2. Peladen NGINX untuk HTTPS.

Sekarang konfigurasi PHP-FPM.

Konfigurasi PHP-FPM

Buat berkas konfigurasi /etc/php5/fpm/pool.d/owncloud yang berisi:

[owncloud]
;; I'm using Socket-based connection because it's safer.
;; Set only Owncloud user
user = awani
group = awani
listen = /tmp/php5-awan-awan.sock
listen.owner = awani
listen.group = awani
listen.mode = 0660

;; Set default server pools
pm = dynamic
pm.max_children = 20 
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 5 

;; Set PHP5 logging
chdir = /
php_admin_value[error_log] = /var/log/fpm-php.awan-awan.log
php_admin_flag[log_errors] = on

;; Longer execution time and bigger upload size.
php_admin_value[max_execution_time] = 300 
php_admin_value[upload_tmp_dir] = /tmp
php_admin_value[upload_max_filesize] = 16G
php_admin_value[post_max_size] = 16G

Jumlah peladen itu tidak saya rubah. Silakan Anda sesuaikan dengan kebutuhan dan kemampuan mesin Anda. Berkas yang bisa diunggah pun sampai 16GB. Secara teori, sih, berkat Menkominfo yang mau turun, tidak mungkin ada berkas sebesar itu yang diunggah.

Setelah selesai, aktifkan Owncloud dan muat ulang PHP-FPM Anda.

sudo invoke-rc.d php5-fpm restart

Sekarang saatnya mengonfigurasi NGINX.

Konfigurasi NGINX

Asal Anda tahu, CA yang beredar di pasaran masih menggunakan enkripsi 1024-bit dan 2048-bit. Kalau pun ada yang 4096-bit, mereka menjual sertifikat dengan harga mahal. Itu sebabnya, saya menggunakan sertifikat yang ditandatangani sendiri.

Sedikit tambahan, Debian dan distro GNU/Linux terbaru lainnya menolak menyertakan CA yang masih 1024-bit. Makanya tempo hari kita gagal memasang Origin. Hal ini karena Origin masih menggunakan CA yang 1024-bit. Ya, itulah nasib keamanan sebatas ilusi.

Membuat Sertifikat Ditandatangani Sendiri (Self-signed Certificate)

Mari membuat sertifikat yang bisa ditandatangani sendiri:

sudo openssl req -newkey rsa:4096 -sha512 -x509 -days 3650 -nodes -out /etc/nginx/awan-awan.pem -keyout /etc/nginx/awan-awan.key

Selanjutnya membuat konfigurasi NGINX.

Membuat Konfigurasi NGINX

Buat berkas konfigurasi /etc/nginx/sites-available/owncloud dengan isi sebagai berikut:

## REDIRECT ALL HTTP TO HTTPS
server {
        listen 80;
        server_name awan.contoh.aja; # CHANGE THE HOSTNAME!
        return 301 https://$server_name$request_uri;  # enforce https
}

## HTTPS
server {
        listen 443 ssl;
        server_name awan.contoh.aja; # CHANGE THE HOSTNAME!

        keepalive_timeout   70;

        ## DISABLE SSLv3 only TLS!
        ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers         AES128-SHA:AES256-SHA:RC4-SHA:DES-CBC3-SHA:RC4-MD5;
        ssl_certificate     awan-awan.pem;
        ssl_certificate_key awan-awan.key;
        ssl_session_cache   shared:SSL:10m;
        ssl_session_timeout 10m;

        # Path to the root of your installation
        root /srv/awani/app;

        client_max_body_size 16G; # set max upload size
        fastcgi_buffers 64 4K;

        rewrite ^/caldav(.*)$ /remote.php/caldav$1 redirect;
        rewrite ^/carddav(.*)$ /remote.php/carddav$1 redirect;
        rewrite ^/webdav(.*)$ /remote.php/webdav$1 redirect;

        ## REWRITE FOR BETTER CLEAN URL
        rewrite ^/f/(.*)$       /public.php?service=files&t=$1;

        index index.php;
        error_page 403 /core/templates/403.php;
        error_page 404 /core/templates/404.php;

        location = /robots.txt {
            allow all;
            log_not_found off;
            access_log off;
        }

        location ~ ^/(data|config|\.ht|db_structure\.xml|README) {
                deny all;
        }

        location / {
                # The following 2 rules are only needed with webfinger
                rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
                rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json last;

                rewrite ^/.well-known/carddav /remote.php/carddav/ redirect;
                rewrite ^/.well-known/caldav /remote.php/caldav/ redirect;

                rewrite ^(/core/doc/[^\/]+/)$ $1/index.html;

                try_files $uri $uri/ index.php;
        }

        #Path to default data directory
        location ~ ^/srv/awani/data/ {
            internal;
            root /;
        }

        location ~ ^(.+?\.php)(/.*)?$ {
                try_files $1 = 404;

                include fastcgi_params;
                fastcgi_param SCRIPT_FILENAME $document_root$1;
                fastcgi_param PATH_INFO $2;
                fastcgi_param HTTPS on;
                fastcgi_pass unix:/tmp/php5-awan-awan.sock;
        }

        # Optional: set long EXPIRES header on static assets
        location ~* ^.+\.(jpg|jpeg|gif|bmp|ico|png|css|js|swf)$ {
                expires 30d;
                # Optional: Don't log access to assets
                access_log off;
        }
}

Perhatikan kalau saya menghapus SSLv3 dari muka bumi. Setahu saya, hanya IE6 yang masih menggunakan SSLv3. Peramban modern sudah mendukung TLS. Bahkan, kalau mau lebih aman, silakan hapus selain TLSv1.2 agar aman dari gangguan SHARK.

Jalankan ulang NGINX.

 sudo ngxensite owncloud 
sudo invoke-rc.d nginx restart

Sekarang saatnya memulai pemasangan.

Menyiapkan Konfigurasi Owncloud

Setelah semua berjalan sebagai mana mestinya, saatnya membuka peramban dan mengarahkan ke alamat yang telah dibuat. Nanti ada wisaya yang berisi satu halaman konfigurasi pengguna awal (Administrator), letak data, dan konfigurasi basisdata. Saya malas membuat cuplikannya, lebih baik saya arahkan saja.

Bagian pertama adalah membuat Administrator Owncloud.

Create an admin account

  • superman
  • r4NdomP4$sW()Rd

Bagian berikutnya adalah direktori menaruh data.

Data folder

  • /srv/awani/data

Lalu konfigurasi MySQL.

Configure the database

  • megawan
  • week^u2heoQuuv]ah9sah]B~ahShie?t
  • awansendiribd
  • localhost

Setelah itu semua selesai, lalu tekan tombol Finish Setup.

Tunggu sebentar dan hasilnya Anda siap untuk masuk.

Owncloud Login page

Owncloud Login page

Selamat mencoba dan bereksplorasi! Mohon bagi-bagi ilmu kalau ada yang baru.

Bacaan Lebih Lanjut

sed Membuang Sebuah Pola Hingga Baris Tertentu
RegEx

sed Membuang Sebuah Pola Hingga Baris Tertentu

RegEx

RegEx

Ada virus Windoze yang menginjeksi berkas-berkas HTML dengan VBScript dan binari berbahaya. Sepertinya target operasi mereka adalah pengembang Web yang menggunakan Windoze. Nantinya, HTML tersebut akan dipublikasikan di sebuah peladen dan diakses oleh banyak orang.

Kebetulan, dari hasil inspeksi bersih-bersih, kami menemukan adanya berkas-berkas HTML yang terinfeksi virus demikian. Kalau hanya satu atau dua, mungkin cukup dihapus. Tapi, kali ini harus memanggil Kapten Regex!

IFS=$(echo -en "\n\b") ; for a in `grep -rlH 'DropFileName = "svchost.exe"' .` ; do sed -i '/<SCRIPT Language=VBScript.*/,+14d' $a; done

Penjelasan:

  • IFS=$(echo -en "\n\b") ;
    Ini memberitahukan kepada BASH bahwa penanda akhir baris adalah Line Break (“\n” atau “\b”). Ini untuk mengatasi nama berkas dengan spasi.
  • grep -rlH 'DropFileName = "svchost.exe"' .
    Mencari berkas-berkas yang berisi ‘DropFileName = “svchost”‘ pada direktori ini “.” dan anak-anaknya.
  • sed -i '/<SCRIPT Language=VBScript.*/,+14d' $a
    Mencari pola “<SCRIPT Language=VBScript” dan menghapus pola tersebut dan 14 baris setelahnya.

Kebetulan saya membaca dulu berkas yang terinfeksi. Ia menginfeksi di akhir baris tapi bukan di baris baru. Wah, ini tantangan dalam menemukan pola yang benar. Apalagi memang beberapa HTML yang mendukung Windoze juga menggunakan VBScript.

Kebetulan saya bukan guru sed.  Saya tidak tahu bagaimana melanjutkan menghapus sampai akhir baris. Saya terpaksa menghitung ada berapa baris. Jumlah baris infeksi ada 14 baris.

Mungkin rekan-rekan ada peningkatan yang lebih bagus?

Perbaikan LDAP

Perbaikan LDAP

Menyalin Seluruh Entri LDAP

Ada kalanya perlu menyalin seluruh entri LDAP untuk keperluan pencadangan.

sudo slapcat -l bekap.ldif

Menyalin dapat dilakukan saat peladen LDAP (SLAPD) masih menyala.

Membetulkan LDAP yang Rusak Karena Basisdata

Biasanya LDAP itu rusak karena basisdata BerkeleyDB-nya mengalami kerusakan. Hal ini terjadi misalnya karena ada yang utak-atik, peladen yang mati langsung secara fisik, atau sebab-sebab lainnya.

Kali ini anggap saja kita termasuk orang yang bagus karena melakukan pencadangan terhadap seluruh entri LDAP.

  1. Matikan SLAPD
    sudo invoke-rc.d slapd stop
  2. Salin dahulu direktori basis data SLAPD. Direktori ini biasanya mengandung $LDAP_ROOT_DB/log sebagai log basisdata dan $LDAP_ROOT_DB/data yang berisi berkas-berkas basisdata BerkeleyDB milik LDAP.Hapus semua berkas kecuali $LDAP_ROOT_DB/data/DB_CONFIG
    sudo rm $LDAP_ROOT_DB/data/*.bdb
    sudo rm $LDAP_ROOT_DB/data/__db.00*
    sudo rm $LDAP_ROOT_DB/data/alock
    sudo rm $LDAP_ROOT_DB/logs/*
  3. Sekarang saatnya menyalin kembali berkas cadangan yang sudah dibuat sebelumnya. Jangan lupa, waktu yang diperlukan sangat lama, bahkan bisa sampai berjam-jam bila LDAP sudah memiliki banyak entri.
    sudo -u openldap slapadd -q -l bekap.ldif
  4. Setelah sekian lama dan selesai tak ada lagi kesalahan, segera nyalakan kembali SLAPD.
    sudo invoke-rc.d slapd start
  5. Selesai!

Mudah-mudahan sudah beres dan dapat berjalan lagi. Ingat, rajin-rajinlah membuat pencadangan.

Komparasi Pustaka-pustaka SSL yang Terkena SSL

Komparasi Pustaka-pustaka SSL yang Terkena SSL

Dari sebuah blog, diketemukan bahwa baik NSS, GnuTLS, OpenSSL memiliki potensi masalah dengan alokasi memori. Blog tersebut menganalisis potensi tersebut dari bagaimana konvensi kode mereka tertulis. Anehnya, dari semua pengimplementasi SSL/TLS, JSSE malah justru implementasi yang aman dan terpercaya. Aneh karena mengingat akhir-akhir ini Java sering kali dituduh biang lubang keamanan. Such a plot twist! 😛

Tim Starling’s blog

Galat Heartbleed pada OpenSSL

Galat Heartbleed pada OpenSSL

Selagi Pemilu, ternyata muncul sebuah kehebohan tentang galat pada OpenSSL. Saya belum sempat menulis karena kehebohan Pemilu lebih terasa. Saya sudah memilih, loh.

Kehebohan tentang OpenSSL dikarenakan adanya sebuah modul di OpenSSL yang bernama Hearbeats. Modul ini menyebabkan OpenSSL membuka sampai 64KB memori untuk dibaca. Itu sebabnya, galat ini berbahaya karena bisa jadi 64KB memori itu berisi login, sandi, atau sertifikat X.509.

Cara mengatasinya?

Galat ini hanya ada pada OpenSSL versi 1.0.1 s.d. 1.0.1f dan 1.0.2-beta. Silakan tingkatkan ke versi 1.0.1g atau 1.0.2-beta1.

Atau cara kedua adalah dengan mematikan Hearbeats. Caranya dengan mengompilasi ulang OpenSSL Anda dengan menambah “-DOPENSSL_NO_HEARTBEATS” pada kompilasi untuk mematikan Heartbeats pada kompilasi.

Cara Paling Gampang

Anda sudah mengaktifkan repo keamanan distro Anda? Ya, tinggal:

$ sudo apt-get update && sudo apt-get dist-upgrade

Selesai.

Cara Agak Susah

Cara agak susah adalah dengan mengompilasi sendiri. Bisa ikuti cara BLFS.

Unduh OpenSSL-1.0.1g dan semuanya.

$ wget http://www.openssl.org/source/openssl-1.0.1g.tar.gz
$ wget http://www.linuxfromscratch.org/patches/blfs/svn/openssl-1.0.1g-fix_parallel_build-1.patch
$ wget http://www.linuxfromscratch.org/patches/blfs/svn/openssl-1.0.1g-fix_pod_syntax-1.patch

Buka dan tambal paket.

$ tar xvfz openssl-1.0.1g.tar.gz
$ cd openssl-1.0.1g
$ patch -Np1 -i ../openssl-1.0.1g-fix_parallel_build-1.patch
$ patch -Np1 -i ../openssl-1.0.1g-fix_pod_syntax-1.patch

Kompilasi.

$ ./config --prefix=/usr --openssldir=/etc/ssl --libdir=lib shared zlib-dynamic
$ make

Saya pikir Debian tidak akan menggunakan pustaka statik. Maka, matikan saja dari pada mengotori sistem.

$ sed -i 's# libcrypto.a##;s# libssl.a##' Makefile

Selanjutnya pasang.

$ sudo make MANDIR=/usr/share/man MANSUFFIX=ssl install
$ sudo install -dv -m755 /usr/share/doc/openssl-1.0.1g
$ sudo cp -vfr doc/* /usr/share/doc/openssl-1.0.1g

Beres.

Cara saya

Hmm… cara saya terlalu rumit untuk ditulis di sini. Nanti saja.

Bacaan Lebih Lanjut

WinSCP Transfer Berkas dengan Perizinan yang Benar
WinSCP

WinSCP Transfer Berkas dengan Perizinan yang Benar

Beberapa dari Anda masih banyak yang lemah iman sehingga masih menggunakan Windoze dalam mengerjakan persitusan. Lalu, ketika Anda selesai membuat situs, Anda pun mengunggah ke peladen dengan menggunakan FTP. Tak berapa lama kemudian, situs Anda terjebol maling.

Ada banyak hal yang menyebabkan hal tersebut. Salah satunya adalah buku-buku sesat yang terbit di Indonesia yang banyak menyarankan perizinan 777. Dengan perizinan tersebut, maling dapat dengan mudah mengubah berkas dan mengeksekusinya. Kemudian, peladen Anda dikuasai olehnya.

Untuk membatasi itu, biasakan untuk membuat perizinan yang baik. Untuk:

  • Berkas: 644 atau 640
  • Direktori/folder: 755 atau 750

Nah, permasalahannya adalah VFAT (FAT32) tidak memiliki bit-bit perizinan dalam sistem berkasnya. Itu sebabnya, setiap aplikasi transfer selalu berasumsi bahwa berkas-berkas yang ditransfer dapat dieksekusi. Bahkan, untuk berkas-berkas sistem berkas NTFS pun banyak aplikasi yang tetap menyalakan bit eksekusi.

Untuk itu, mari gunakan transfer yang aman (SFTP/SCP) dan membuat bit perizinan yang baik.

Caranya

  1. Buka WinSCP, pilih Tools ❱ Preferences
    newpage

    New connection window.

  2. Pada jendela preferensi, pilih Transfer. Lalu, pada pilihan sebelah kanan pilih Default. Dengan Default terpilih, klik tombol Edit untuk membuka jendela Transfer settings.
    Preferences window

    Preferences window

  3. Pada Transfer settings, klik tombol eliptik (…) pada Set permissions dan lakukan:
    • Hilangkan semua centang dari X untuk menghilangkan bit eksekusi.
    • Lalu centang Add X to directories.
    Dengan set ini, maka semua berkas yang diunggah tidak akan ada bit eksekusinya.
    Transfer settings window for Default behavior.

    Transfer settings window for Default behavior.

  4. Setelah selesai, klik OK dan lakukan operasi seperti biasa.
  5. Selesai.

Terakhir

Skrip PHP dan berkas-berkas lainnya tidak dijalankan oleh terminal. Tidak perlu membuat bit eksekusi untuk mereka. Kalau pun ada yang butuh paling skrip terminal. Nah, untuk skrip-skrip terminal, Anda bisa menyalakan bit eksekusi secara manual dengan chmod.

Perilaku ini jauh lebih aman dari pada membiarkan semua berkas di peladen dengan bit eksekusi aktif.

Salt (IV/Initial Value) untuk WordPress

Salt (IV/Initial Value) untuk WordPress

Kalau Anda malas menggunakan pwgen dan tetap ingin punya situs WordPress yang cukup handal, gunakan IV yang benar untuk nonce dan kunci-kunci WordPress. Situs untuk memproduksi nilai-nilai itu ada di:

https://api.wordpress.org/secret-key/1.1/salt/

Contoh isinya: (berubah-ubah tiap kunjungan)

define('AUTH_KEY',         'mWdR-e!-_)`AryNg{s>-N<pHy^K|63s -v2wBF^1a^f@#9dwr.IY</Sri@Z;H|w!');
define('SECURE_AUTH_KEY',  'n);FO?q@0w5E}Wm;^A]l<O.;9|y+i u}VhEXO6TX -%+Z^8z|K>Yi14HMH*99G-o');
define('LOGGED_IN_KEY',    'iZ-8]wfgj&UA*zvb|ir  Gw][n Qe>i*8.ehK-UiX9=30G;oAZnqBHw*DwW4:n<i');
define('NONCE_KEY',        'f*6h8vSj/zfA+!JxTo-]G|mC;mY$|87? xi,)DNX4oEliOzcq|O=_%L5>@H2g*5|');
define('AUTH_SALT',        'wGV0|F/+#7pME/eSF+eW+ecc=Or wx!2obB|`W}:_{:Oc,o]NWNwr8EScF+X?,Ih');
define('SECURE_AUTH_SALT', 'KC)u]z}qurPmy0cB:UeZPi9R^&LM&:qO@Ihua,YOY.Sx0-wB*.! Feyo}ljZj.A)');
define('LOGGED_IN_SALT',   'pa:31Tt!8/a3+tzrF&1r{%C#u,d)tL_Z+1YXH8NY=kWCEY_nrR3}BSXA@8<8VKp`');
define('NONCE_SALT',       '4E/#-?fw+s{`C-s@{`9uvSqd_zZNRl<r]1u-@<;8i6C~03u(CNBW(qgbc:NpR0XL');

 

Pencurian Identitas Digital Akun UI
Mancing Mania!

Pencurian Identitas Digital Akun UI

A disguised Webmail UI site.

A disguised Webmail UI site.

Nampaknya pengguna akun Universitas Indonesia sedang diincar oleh para penipu digital. Mereka menyalin situs Webmail UI dan kemudian menaruhnya di sebuah peladen lain dengan kode yang sedikit diubah.

Real Webmail UI site

Real Webmail UI site

Sekilas, jika dibandingkan dengan situs Webmail UI yang asli, nampak serupa. Blok peringatan yang kedua baru saja saya tambahkan untuk memperingati pengguna Webmail UI. Kecuali blok merah tersebut, semua nampak sama.

Ya, modus penipuan ini sebenarnya gampang. Dia cukup mengunduh seluruh halaman Webmail UI. Misalnya, kalau di Firefox tinggal Save As –> Webpage Complete. Kemudian, mereka mengubah bagian pengisian Username dan Password untuk mengirimkannya ke alamat lain.

Pada kasus Webmail UI, halaman yang asli akan mengirim kepada sebuah mesin webmail:

<form action="https://webmail.ui.ac.id/squirrel/src/redirect.php" method="post" name="login_form">

sedangkan yang palsu akan mengirim ke peladen lokal:

<form action="ui.php" method="post" name="login_form">

Hmm… pantas saja akhir-akhir ini ada banyak “aktivitas” di peladen UI. Nampaknya mereka sedang mengincar UI. Duh, berani-beraninya menjelang Natal dan Tahun Baru. Ya, Tuhan, ajar saya untuk tak membalas dendam ala 4Ch.

Untuk para pengguna UI, mohon berhati-hatilah dan pastikan bahwa URL yang sedang Anda akses adalah benar dari UI.

SciTE REGEX Mengubah Di Antara
SciTE Search Dialog for padding first and last of each line.

SciTE REGEX Mengubah Di Antara

Semisal ada berkas tabular  yang hendak dijadikan kueri SQL yang isinya beratus-ratus baris. Contoh cuplikan data:

rambutan
durian
nangka

Diubah menjadi

'rambutan',
'durian',
'nangka',

Maka perintah yang dilakukan di SciTE (atau Scintilla):

  1. Tekan CRTL+H untuk membuka pencarian.
  2. Beri centang pada “Regular Expression”
  3. Masukkan pada “Find What”
    ^.*$
    Artinya, semua karakter yang ada dari awal (^) sampai akhir baris ($).
  4. Masukkan pada “Replace With”
    '\0',
    Artinya, ganti menjadi “‘” karakter-karakter yang terpilih (“\0”) “‘,”. Misalnya: “‘rambutan’,”. Ini dilakukan per baris. Berikan centang pada “Wrap Around” agar semua baris diproses walau di mana pun posisi kursor.

Hal ini seperti Gambar.

SciTE Search Dialog

SciTE Search Dialog for padding first and last of each line.

Semoga bermanfaat.

Bacaan Lebih Lanjut