Saya coba cek dengan mengetikkan perintah clear.

clear

Muncullah pesan error

xterm-256color': unknown terminal type.

Ok, sudah diketahui masalahnya. Solusinya sederhana. Install paket ncurses-term, di server Debian/Ubuntu.

sudo apt-get install ncurses-term

Beberapa server Debian saya sudah terinstall (entah ini default atau terinstall saat saya menginstall paket lain), tetapi semua server Ubuntu Hardy (8.04) belum terinstall paket tsb. Mudah-mudahan ini membantu rekan-rekan yang mengalami hal yg serupa.

Singkatnya, misal di /etc/fstab saya tertulis spt ini.

# / was on /dev/sda8 during installation
UUID=e63ba07a-05e9-4745-bc93-26c589f976c7 /               ext4    errors=remount
-ro 0       1
# swap was on /dev/sda5 during installation
UUID=d55d01f4-9680-4562-a4f7-2f54b8ed3144 none            swap    sw            
  0       0

Lalu bagaimana kalau saya mau menambahkan partisi lain ke /etc/fstab dengan menggunakan format UUID seperti di atas. Caranya mudah, ketik di Terminal.

sudo blkid

Maka tampilan yang muncul adalah semua partisi dan UUID untuk partisi tersebut. Misal utk harddisk saya

/dev/sda1: LABEL="Recovery" UUID="6292C3C292C39945" TYPE="ntfs" 
/dev/sda2: LABEL="System Reserved" UUID="8466443666442B6E" TYPE="ntfs" 
/dev/sda3: UUID="01CC441D19810D10" TYPE="ntfs" 
/dev/sda5: UUID="d55d01f4-9680-4562-a4f7-2f54b8ed3144" TYPE="swap" 
/dev/sda6: UUID="bee69909-3c99-4240-aa09-9c5e8b3fe495" TYPE="ext4" 
/dev/sda7: LABEL="_Fedora-15-x86_6" UUID="2cfa5e94-d0de-46be-904d-7493ba1580a9" TYPE="ext4" 
/dev/sda8: UUID="e63ba07a-05e9-4745-bc93-26c589f976c7" TYPE="ext4" 
/dev/sda9: LABEL="openSUSE" UUID="32d7db68-5b45-cc01-10c5-da685b45cc01" TYPE="ext4" 

Links

http://www.unixtutorial.org/2008/05/ubuntu-uuid-how-to/

http://www.cyberciti.biz/faq/linux-finding-using-uuids-to-update-fstab/

Solusi sederhana untuk permasalahan Anda adalah dengan menggunakan file locking sederhana.

#!/bin/bash
 
LOCKFILE="/tmp/skrip.lock"
 
if [ -e "$LOCKFILE" ] ; then
    echo "Ada file lock. Mungkin skrip sedang dijalankan."
    exit 1
fi
 
touch $LOCKFILE
 
#
# disini Anda bisa tulis proses yang ingin dijalankan, misalnya:
# - rsync utk backup
# - rdiff-backup
# - scp 
# - dll
 
 
# setelah proses selesai dijalankan, hapus file lock.
rm -f $LOCKFILE

Untuk mengkonfigurasi HTTPS server, Anda harus mengaktifkan protokol SSL di blok server, dan menuliskan lokasi dari berkas server certificate dan private key:

server {
    listen               443;
    server_name          www.nginx.com;
    ssl                  on;
    ssl_certificate      www.nginx.com.crt;
    ssl_certificate_key  www.nginx.com.key;
    ssl_protocols        SSLv3 TLSv1;
    ssl_ciphers          HIGH:!ADH:!MD5;
    ...
}

Server certificate adalah entitas publik. Ini akan dikirim ke setiap klien yang terhubung ke server. Sedangkan private key adalah entitas keamanan dan harus disimpan dalam berkas dengan akses terbatas, tapi walau terbatas harus bisa dibaca oleh master proses nginx. Private key bisa juga disimpan dalam berkas sama sebagai certificate:

    ssl_certificate      www.nginx.com.cert;
    ssl_certificate_key  www.nginx.com.cert;

yang dalam kasus ini akses ke berkas juga harus dibatasi. Meskipun sertifikat dan kuncinya disimpan dalam satu berkas, hanya bagian certificate yang akan dikirim ke klien.

Direktif “ssl_protocols” dan “ssl_chipers” mungkin bisa digunakan untuk membatasi koneksi ke versi aman/kuat (strong) protokol SSL dan chipers. Sejak versi 0.8.20, nginx menggunakan “ssl_protocols SSLv3 TLSv1” dan “ssl_chipers HIGH:!ADH:!MD5” pada konfigurasi default, jadi semua itu hanya harus diset jika menggunakan versi nginx sebelumnya.

Optimasi HTTPS server

Operasi SSL mengkonsumsi sumberdaya CPU lebih banyak. Pada sistem multi prosesor Anda sebaiknya menjalankan beberapa worker processes: tidak lebih sedikit dari jumlah CPU core yang tersedia. Operasi yang paling banyak memakai sumberdaya CPU adalah pada saat SSL handshake.

Ada dua cara untuk meminimalkan jumlah operasi ini per klien: yang pertama adalah mengaktifkan keepalive connections untuk mengirimkan beberapa request melalui satu koneksi dan yang kedua adalah untuk menggunakan ulang sesi SSL untuk menghindari SSL handshake untuk koneksi parallel dan subsequent connections. Sesi-sesi ini disimpan dalam SSL session cache yang di share antara worker dan dikonfigurasi oleh direktif “ssl_session_cache“. Satu megabyte dari cache bisa menyimpan sekitar 4000 sesi. Nilai default untuk cache timeout adalah 5 menit. Dan bias dinaikkan menggunakan direktif “ssl_session_timeout“.

Berikut ini adalah contoh konfigurasi yang sudah dioptimasi untuk sistem quad core dengan 10M shared session cache:

worker_processes  4;
 
http {
    ssl_session_cache    shared:SSL:10m;
    ssl_session_timeout  10m;
 
    server {
        listen               443;
        server_name          www.nginx.com;
        keepalive_timeout    70;
 
        ssl                  on;
        ssl_certificate      www.nginx.com.crt;
        ssl_certificate_key  www.nginx.com.key;
        ssl_protocols        SSLv3 TLSv1;
        ssl_ciphers          HIGH:!ADH:!MD5;
        ...

SSL certifcate chains

Beberapa peramban mungkin komplen tentang sertifikat yang ditandatangani oleh well-kown certificate authority, sementara peramban lainnya mungkin menerima sertifikat tanpa masalah. Hal ini terjadi karena yang mengeluarkan otoritas telah menandatangi sertifikat server menggunakan sertifikat perantara (intermediate certificate) yang tidak tersedia di basis sertifikat dari well-known trusted certificate authorities, tapi dilain sisi sertifikat ini mungkin didistribusikan di sebagian peramban lainnya. Dalam kasus ini si otoritas biasanya menyediakan satu bundle chained certificates yang harus di gabungkan (concatenated) ke sertifikat yang telah ditandatangani. Sertifikat harus muncul sebelum chained certificates pada berkas yang sudah digabung:

$ cat www.nginx.com.crt bundle.crt > www.nginx.com.chained.crt

Berkas yang dihasilkan digunakan dalam direktif “ssl_certificate“:

server {
    listen               443;
    server_name          www.nginx.com;
    ssl                  on;
    ssl_certificate      www.nginx.com.chained.crt;
    ssl_certificate_key  www.nginx.com.key;
    ...
}

Jika sertifikate server dan bunel sudah digabungkan dalam urutan yang salah, nginx akan gagal dijalankan dan akan menampilkan pesan error:

SSL_CTX_use_PrivateKey_file(" ... /www.nginx.com.key") failed
   (SSL: error:0B080074:x509 certificate routines:
    X509_check_private_key:key values mismatch)

karena nginx mencoba menggunakan private key dengan certifikat pertama dari bundle dan bukan ke sertifikat server yang seharusnya.

Peramban biasanya menyimpan sertifikat perantara yang mereka terima dan yang ditandatangani oleh otoritas terpercaya, jadi peramban yang sudah digunakan secara aktif mungkin sudah memiliki sertifikat perantara yang dibutuhkan dan tidak akan komplen tentang sertifikat yang dikirim tanpa bundle. Untuk meyakinkan server mengirimkan certificate chain yang lengkap, Anda bisa menggunakan perintah “openssl“, misalnya:

$ openssl s_client -connect www.godaddy.com:443

...
Certificate chain
 0 s:/C=US/ST=Arizona/L=Scottsdale/1.3.6.1.4.1.311.60.2.1.3=US
     /1.3.6.1.4.1.311.60.2.1.2=AZ/O=GoDaddy.com, Inc
     /OU=MIS Department/CN=www.GoDaddy.com
     /serialNumber=0796928-7/2.5.4.15=V1.0, Clause 5.(b)
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc.
     /OU=http://certificates.godaddy.com/repository
     /CN=Go Daddy Secure Certification Authority
     /serialNumber=07969287
 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc.
     /OU=http://certificates.godaddy.com/repository
     /CN=Go Daddy Secure Certification Authority
     /serialNumber=07969287
   i:/C=US/O=The Go Daddy Group, Inc.
     /OU=Go Daddy Class 2 Certification Authority
 2 s:/C=US/O=The Go Daddy Group, Inc.
     /OU=Go Daddy Class 2 Certification Authority
   i:/L=ValiCert Validation Network/O=ValiCert, Inc.
     /OU=ValiCert Class 2 Policy Validation Authority
     /CN=http://www.valicert.com//emailAddress=info@valicert.com
...

Di contoh ini subject (“s”) dari sertifikat server www.GoDaddy.com #0 ditandatangani oleh issuer (“i”) yang merupakan subject dari sertifikat #1, yang juga ditandatangani oleh issuer yang merupakan subject dari certificate #2, yang ditandatangani oleh well-known issuer ValiCert, Inc. Semua sertifikat itu disimpan di built-in certificate base dari peramban.

Jika Anda tidak menambahkan certificate bundle, Anda hanya akan melihat sertifikate server #0.

A single HTTP/HTTPS server

Merupakan langkah yang baik untuk mengkonfigurasi server secara terpisah untuk protokol HTTP dan HTTPS dari sejak awal. Meskipun mungkin fungsionalitas mereka terlihat mirip, tapi ini bisa saja berubah secara signifikan di masa yang akan datang dan menggunakan server yang digabung mungkin akan menjadi masalah. Walau demikian, jika server HTTP dan HTTPS adalah sama, dan Anda tidak ingin berfikir tentang masa yang akan datang, Anda bisa mengkonfigurasi satu server tunggal yang menangani request HTTP dan HTTPS dengan menghapus direktif “ssl on” dan menambahkan parameter “ssl” untuk port *:443

server {
    listen               80;
    listen               443  ssl;
    server_name          www.nginx.com;
    ssl_certificate      www.nginx.com.crt;
    ssl_certificate_key  www.nginx.com.key;
    ...
}

Semenjak versi 0.8.21, nginx hanya membolehkan parameter “ssl” di set pada socket yang di listen dengan parameter “default”:

listen  443  default  ssl;

Name-based HTTPS servers

Biasanya muncul masalah umum ketika mengkonfigurasi dua atau lebih server HTTPS yang listening pada satu alamat IP:

server {
    listen           443;
    server_name      www.nginx.com;
    ssl              on;
    ssl_certificate  www.nginx.com.crt;
    ...
}
 
server {
    listen           443;
    server_name      www.nginx.org;
    ssl              on;
    ssl_certificate  www.nginx.org.crt;
    ...
}

Dengan konfigurasi ini, peramban menerima sertifikat dari default server, misalnya, www.nginx.com tanpa terpengaruh dengan server name yang direquest. Ini disebabkan karena sifat dari protokol SSL. Koneksi SSL terjadi sebelum browser mengirim request HTTP dan nginx tidak akan pernah tahu nama dari server yang direquest. Oleh karena itu, dia hanya akan menawarkan satu sertifikat dari default server.

Cara lama dan yang paling tokcer untuk mengatasi masalah ini adalah dengan membuat alamat IP terpisah untuk setiap HTTPS server:

server {
    listen           192.168.1.1:443;
    server_name      www.nginx.com;
    ssl              on;
    ssl_certificate  www.nginx.com.crt;
    ...
}
 
server {
    listen           192.168.1.2:443;
    server_name      www.nginx.org;
    ssl              on;
    ssl_certificate  www.nginx.org.crt;
    ...
}

Sertifikat SSL dengan beberapa nama

Ada cara lain untuk berbagi alamat IP antara beberapa HTTPS server, meskipun demikian, semuanya memiliki kelemahan. Salah satu cara adalah menggunakan sertifikat dengan beberapa nama pada bagian SubjectAltName di sertifikat. Sebagai contoh misalnya, www.nginx.com dan www.nginx.org. Tapi, bagian SubjectAltName memiliki panjang yang terbatas.

Cara lain adalah menggunakan sertifikat dengan wildcard name, misalnya, *.nginx.org. Sertifikat ini akan cocok dengan www.nginx.org, tapi tidak akan cocok dengan nginx.org dan www.sub.nginx.org. Dua metode tadi, bisa juga dikombinasikan. Sertifikat bisa saja berisikan exact dan wildcard name pada bagian SubjectAltName, misalnya, nginx.org dan *.nginx.org.

Akan lebih baik untuk menyimpan berkas sertifikat dengan beberapa nama dan berkas kunci privatenya pada level http dari berkas konfigurasi, agar di inherit ke semua server dari satu salinan memori.

ssl_certificate      common.crt;
ssl_certificate_key  common.key;
 
server {
    listen           443;
    server_name      www.nginx.com;
    ssl              on;
    ...
}
 
server {
    listen           443;
    server_name      www.nginx.org;
    ssl              on;
    ...
}

Server Name Indication

Solusi yang lebih mendasar untuk menjalankan beberapa server HTTPS pada satu alamat IP tunggal adalah menggunakan TLSv1.1 Server Name Indication extension (SNI, RFC3546), dimana dia membolehkan peramban melanjutkan request server name pada saat SSL handshake, dan selanjutnya, server akan tahu sertifikat yang mana yang harus digunakan untuk koneksi tersebut. Tapi SNI memiliki dukungan peramban yang terbatas. Saat ini dukungan fitur mulai ada di beberapa versi peramban berikut:

Opera 8.0;
MSIE 7.0 (hanya untuk Windows Vista atau versi lebih tinggi);
Firefox 2.0 dan peramban lain yang menggunakan platform Mozilla Platform rv:1.8.1;
Safari 3.2.1 (Versi Windows mendukung SNI pada Vista atau versi lebih baru);
dan Chrome (Versi Windows mendukung SNI pada Vista atau versi lebih baru).

Untuk menggunakan SNI di nginx, ini harus didukung oleh pustaka OpenSSL yang mana saat nginx dibangun juga oleh pustakan yang sedang ditautkan secara dinamik saat dijalankan. OpenSSL sudah mendukung SNI sejak versi 0.9.8f jika dia dibangun dengan opsi konfigurasi “--enable-tlsext“. Sejak OpenSSL 0.8.9j opsi ini diaktifkan secara default. Jika nginx sudah dibangun dengan dukungan SNI, maka nginx akan menampilkan ini ketika dijalankan dengan pilihan “-V”:

$ nginx -V
...
TLS SNI support enabled
...

Akan tetapi, jika nginx yang sudah diaktifkan SNI nya, tapi ditautkan secara dinamik ke pustaka OpenSSl yang tidak memiliki dukungan SNI, ngixn akan menampilkan peringatan:

nginx was built with SNI support, however, now it is linked
dynamically to an OpenSSL library which has no tlsext support,
therefore SNI is not available

Kompatibilitas

The SNI support status has been shown by the “-V” switch since 0.8.21 and 0.7.62.
The “ssl” parameter of the “listen” directive has been supported since 0.7.14.
SNI has been supported since 0.5.32.
The shared SSL session cache has been supported since 0.5.6.
Version 0.8.19 and later: the default SSL protocols are SSLv3 and TLSv1.
Version 0.8.18 and earlier: the default SSL protocols are SSLv2, SSLv3, and TLSv1.
Version 0.8.20 and later: the default SSL ciphers are “HIGH:!ADH:!MD5”.
Version 0.8.19: the default SSL ciphers are “ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM”.
Version 0.8.18 and earlier: the default SSL ciphers are
“ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP”.

Ditulis oleh Igor Sysoev
Diedit oleh Brian Mercer
Diterjemahkan oleh Cecep Mahbub

Squid mendukung 4 skema autentikasi, yaitu:

1. Basic
2. Digest
3. NTLM
4. Negotiate (mulai dari versi 2.6)

Masing-masing skema autentikasi punya kelebihan dan kekurangan masing-masing. Mari kita bahas satu per satu.

Basic Authentication

Ini adalah skema autentikasi yang didukung oleh semua peramban (browser) utama. Dan lebih dari itu, bisa berfungsi dengan baik di semua platform OS. Jadi kalau ingin menggunakan skema autentikasi yang yakin berfungsi dengan baik di semua browser, pakailah skema autentikasi basic.

Sayangnya skema autentikasi basic ini memiliki satu kelemahan utama, yaitu proses pengiriman data user dan password dikirim dalam format plain text. Jadi sangat rentan terhadap proses snip atau penyadapan saat proses autentikasi berlangsung.

Skema ini tidak disarankan ketika layanan yang diberikan akan diakses melalui jaringan internet. Tapi masih bisa ditolerir jika layanan itu dibuat untuk kalangan terbatas, misalnya LAN kantor. Dan karena squid pada umumnya digunakan di jaringan terbatas, skema autentikasi ini masih bisa digunakan.

Helper atau program bantu untuk autentikasi ke backend

Squid menyediakan beberapa program bantu untuk skema autentikasi basic. Anda bisa memilih mana yang cocok dengan keperluan Anda.

1. LDAP: Autentikasi ke LDAP.
2. NCSA: Menggunakan format penulisan username dan password format NCSA.
3. MSNT: Autentikasi ke domain Windows NT.
4. PAM: Menggunakan skema autentikasi PAM yang umum digunakan di sistem operasi Unix/Linux.
5. SMB: Menggunakan server SMB seperti Windows NT atau Samba.
6. getpwam: Menggunakan cara kuno, berkas password di Unix/Linux.
7. SASL: Mengggunakan pustaka SASL.
8. mswin_sspi: Windows native authenticator.
9. YP: Menggunakan database NIS.

Digest Authentication

Skema autentikasi digest diperkenalkan untuk mengatasi kelemahan yang ada di skema autentikasi basic. Skema ini lebih aman, karena pada saat autentikasi, data username dan password tidak dikirim dalam format plain text.

Secara umum, kelebihan skema autentikasi digest dibandingkan skema autentikasi basic, yaitu lebih aman. Tapi sayangnya tidak didukung oleh semua browser. Internet Explorer 5 & 6 adalah salah satu browser yang tidak mendukung skema autentikasi digest.

NTLM Authentication

Ini adalah skema autentikasi yang diperkenalkan oleh Microsoft. Dengan menggunakan skema autentikasi NTLM, semua user yang sudah login ke domain, ketika mengakses squid tidak akan diminta lagi username dan password. Ini yang kita kenal sebagai proses Single Sign On. Jika sudah sukses autentikasi di satu layanan, ketika ingin menggunakan layanan lain tidak perlu memasukkan login dan password lagi, proses autentikasi berlangsung secara transparan.

Sayangnya, seperti yang mungkin Anda sudah bisa tebak, ini hanya berfungsi dengan baik di sistem operasi Windows. Dan tidak semua browser mendukung skema autentikasi NTLM. Internet Explorer dan Firefox adalah salah satu browser yang mendukung skema autentikasi NTLM. Chrome, Safari dan Opera adalah contoh browser yang belum mendukung skema autentikasi NTLM.

Biasanya, untuk browser atau OS yang tidak mendukung skema autentikasi NTLM, ada pilihan fallback ke skema autentikasi basic.

Helper atau program bantu untuk autentikasi ke backend

Paket samba menyertakan winbind ntlm helper untuk membantu squid bisa memberikan layanan skema autentikasi NTLM.

Sedikit catatan di Debian atau Ubuntu, yang Anda gunakan adalah /usr/bin/ntlm_auth, dan BUKAN ke /usr/lib/squid/ntlm_auth.

Negotiate Authentication

Protokol negotiate diperkenalkan lagi-lagi oleh Microsoft, sering dikenal juga sebagai SPNEGO. Skema autentikasi ini memperbarui skema Single Sign On yang sebelumnya menggunakan autentikasi NTLM.

Jadi apakah Negotiate itu? Skema ini bisa dianggap sebagai wrapper (atau alat bantu) untuk menggunakan salah satu dari autentikasi ke Kerberos atau NTLM. Kelebihan skema ini, jauh lebih aman bila dibandingkan dengan skema autentikasi NTLM.

Kelemahannya, lagi-lagi hanya berfungsi dengan baik di lingkungan OS Windows. Selain itu untuk saat ini mengkonfigurasi skema autentikasi negotiate agak ribet, karena helper baru tersedia untuk sistem operasi windows.

Rangkuman

Di tulisan ini memang tidak memberikan contoh siap pakai, tapi diharapkan Anda memahami beberapa aspek dasar tentang skema autentikasi di Squid. Dan untuk memahami lebih lanjut, saya berika beberapa tautan yang mungkin bisa memberikan penjelasan yang lebih detail.

• http://wiki.squid-cache.org/Features/Authentication
• http://wiki.squid-cache.org/Features/NegotiateAuthentication
• http://en.wikipedia.org/wiki/BasicAuthenticationScheme
• http://en.wikipedia.org/wiki/NTLM
• http://en.wikipedia.org/wiki/DigestAccessAuthentication

Yang diperlukan

Pastikan Nginx dikompilasi dengan opsi:

--with-http_ssl_module

Jika Anda menggunakan paket debian atau rpm, Anda bisa memastikannya dengan pertintah:

nginx -V

Selain itu Anda harus sudah menginstal paket openssl.

Membuat Self Sign Certificate

Saya tuliskan lagi secara singkat. Lengkapnya silakan lihat di tulisan sebelumnya, Membuat Self Sign Certificate.

openssl genrsa -out server.key 2048
openssl req -new -key server.key -out server.csr
openssl x509 -req -days 731 -in server.csr -signkey server.key -out server.crt

Anda akan mempunyai 3 berkas baru.

server.crt
server.csr
server.key

Yang akan diguanakan hanya dua, server.crt dan server.key.

Konfigurasi Nginx

Sekarang silakan salin dua berkas tersebut, dan atur hak aksesnya. Asumsi Nginx dijalankan sebagai user www-data.

cp server.crt /etc/ssl/
cp server.key /etc/ssl/
chmod 644 /etc/ssl/server.crt
chmod 640 /etc/ssl/server.key
chown root:www-data /etc/ssl/server.key

Maka konfigurasi Nginx untuk https:

server {
    server_name perusahaan.com;
    listen 443;
    ssl on;
    ssl_certificate /etc/ssl/server.crt;
    ssl_certificate_key /etc/ssl/server.key;
}

4 Langkah Membuat Self-Signed Certificate

Buat Private Key

Buat private key dengan perintah di bawah ini. Anda akan diminta memasukkan password untuk mengenkripsi private key yang baru saja dibuat.

openssl genrsa -des3 -out server.key 2048

Anda kemungkinan besar, nantinya akan membuat versi yang tidak dienkripsi. Karena ketika sertifikat ssl digunakan dalam konfigurasi apache misalnya, setiap service apache di restart, server akan menunggu Anda memasukkan password untuk private key.

Cara lain, biar lebih hemat waktu, buat private key yang tidak dienkripsi. Gunakan perintah di bawah ini.

openssl genrsa -out server.key 2048

Buat Certificate Signing Request

Buat Certificate Signing Request, atau sertifikat yang akan disiapkan untuk di tanda tangani nanti.

openssl req -new -key server.key -out server.csr

Anda akan diminta memasukkan beberapa entri seperti di bawah ini:

Country Name (2 letter code) [AU]: ID
State or Province Name (full name) [Some-State]: DKI Jakarta
Locality Name (eg, city) []: Jakarta Selatan
Organization Name (eg, company) [Internet Widgits Pty Ltd]: PT. Ngadimin Sehat Selalu
Organizational Unit Name (eg, section) []: Dept. Teknologi Informasi    
Common Name (eg, YOUR name) []: www.ngadimin.com
Email Address []: cecep@ngadimin.com

Yang perlu Anda ingat, agar sertifikat Anda valid, dibagian Common Name isi dengan alamat dns yang akan diakses nanti oleh user. Jika user akan mengaksesnya dengan nama portal.perusahaan.com, maka isi dengan portal.perusahaan.com.

Sign Certificate Menggunakan Private Key

Tandatangani sertifikat menggunakan private key yang Anda buat sebelumnya (inilah makanya disebut self-sign certificate, karena dibuat dan ditandatangani menggunakan kunci yang sama).

Dalam contoh ini sertifikat akan valid selama 731 hari atau kira-kira 2 tahun. Silakan ganti dengan jumlah hari yang diinginkan. Saran jangan terlalu lama, dan jangan terlalu singkat.

openssl x509 -req -days 731 -in server.csr -signkey server.key -out server.crt

Buat versi Private Key yang tidak dienkripsi

Jika dilangkah sebelumnya Anda membuat private key yang dienkripsi (atau dilindungi dengan password), Anda bisa membuat versi yang tidak dilindungi dengan password menggunakan perintah di bawah ini.

openssl rsa -in server.key -out server.key.tidak-dienkripsi
mv server.key server.key.dienkripsi
mv server.key.tidak-dienkripsi server.key 

Selanjutnya Anda akan menggunakan versi private key yang tidak dienkripsi, untuk mempermudah menjalankan secara otomatis service yang menggunakan ssl.

Perintah yang Lebih Ringkas

Langkah-langkah di atas, bisa diringkas menjadi satu perintah seperti di bawah ini. Bedanya Anda tidak membuat certificate signing request dulu, tapi langsung bikin private key dan certificate nya.

openssl req -days 731 -newkey rsa:2048 -keyout server.key -out server.crt

Tapi sepertinya Anda tetap harus menjalankan perintah di bawah ini, untuk membuat versi private key yang tidak dienkripsi.

openssl rsa -in server.key -out server.key.tidak-dienkripsi
mv server.key server.key.dienkripsi
mv server.key.tidak-dienkripsi server.key 

Daftar Berkas Yang Dihasilkan

Baik menggunakan langkah-langkah yang lebih panjang, atau pakai perintah yang lebih ringkas, Anda kira-kira akan mendapatkan 4 berkas di bawah ini.

server.crt
server.csr --> kalau pakai cara ringkas, berkas ini tidak akan ada
server.key
server.key.dienkripsi

Dari berkas di atas, yang akan digunakan oleh service, seperti apache, nginx atau service lainnya, hanya dua berkas. Yaitu server.crt dan server.key.

Untuk konfigurasi ssl untuk apache atau nginx akan dijelaskan ditulisan terpisah.

Saya coba tampilkan tabel harga sertifikat SSL, dari salah satu situs reseller sertifikat ssl. Anda bisa dengan mudah menemukan tabel serupa dengan mencari tabel perbandingan harga sertifikat ssl di google.

Sertifikat SSL standar, rata-rata ada di harga lebih dari $100 dollar per tahun. Bahkan bisa mencapai ribuan dollar ketika menggunakan Sertifikat SSL Extended Validation (EV). Okelah misalnya Anda termasuk cukup menggunakan sertifikat ssl dengan level verifikasi terendah, seperti Geotrust RapidSSL atau Comodo PositiveSSL. Dibeberapa situs kedua sertifikat itu bisa Anda peroleh dengan harga $9 per tahun.

INGAT per tahun! Artinya tahun berikutnya Anda harus siap mengeluarkan budget yang sama.

Dengan self-signed certificate, Anda tidak perlu mengeluarkan biaya sepeserpun. Bikin sendiri, tanda tangani sendiri. Beres!

Mudah, tidak ada proses verifikasi

Verifikasi terendah dalam pembuatan Sertifikate SSL adalah dengan verifikasi domain. Jadi otoritas yang akan memverifikasi sertifikat Anda akan memastikan kalau Anda memang punya kontrol atas domain yang akan dibuatkan sertifikat sslnya.

Jika Anda membeli sertifikat SSL yang lebih tinggi lagi, dan tentunya lebih mahal pula, Anda harus siap dengan proses verifikasi yang lebih rumit lagi. Beberapa dokumen resmi akan diminta sebagai alat untuk memverifikasi identitas si pemilik domain.

Menggunakan self-signed certificate tidak perlu verifikasi. Tinggal bikin, gak ada verifikasi.

Amankah menggunakan Self-Signed Certificate?

Dari segi teknis, sama-sama aman. Jika sertifikat berbayar bisa digunakan untuk komunikasi ssl 256 bit, maka sertifikat yang dibuat dan ditandatangani sendiri juga bisa digunakan untuk keperluan itu. Yang membedakan hanya tingkat kepercayaan. Karena pada prinsipnya, sertifikat ssl hanyalah berperan sebagai kartu identitas.

Kapan harus menggunakan Sertifikat SSL komersial

Internet adalah sebuah ruang publik dimana tingkat anonimitasnya sangat tinggi. Banyak identitas tidak jelas bahkan identitas palsu di internet. Dan ini menjadi masalah ketika berhubungan dengan transaksi yang melibatkan uang di dunia online. Pengguna layanan transaksi online, tentunya ingin mendapatkan keyakinan kalau situs yang dia kunjungi memang memberikan identitas yang benar.

Dengan sertifikat SSL, pengguna bisa yakin kalau identitas yang ada di situs yang dia kunjungi memang benar atau valid. Pihak yang memberikan sertifikat (yang menandatangani sertifikat), menjamin data-data yang ada di sertifikat itu benar, berdasarkan proses verifikasi saat pembuatan sertifikat ssl tersebut.

Misal, ketika Anda mengakses situs https://ibank.klikbca.com, berdasarkan informasi yang Anda lihat di sertifikat ssl, Anda bisa yakin kalau yang menjalankan situs tersebut adalah PT. Bank Central Asia Tbk. Browser yang Anda gunakan juga tidak memunculkan peringatan, yang artinya sertifikat tersebut dikenali berdasarkan Root CA yang sebelumnya sudah disertakan di browser Anda.

Sebagai Catatan: Otoritas penyedia layanan sertifikat SSL, harus memenuhi sejumlah persyaratan agar sertifikat mereka bisa dimasukkan ke browser paling umum digunakan seperti Mozilla, Internet Explorer, Opera dll. Termasuk didalamnya membayar sejumlah biaya ke pengembang browser.

Bagaimana dengan self-signed certificate? Browser akan memperlakukan berbeda. Saat pertama kali Anda mengakses halaman https yang menggunakan self-signed certificate, browser akan menampilkan sejumlah peringatan. Peringatan karena yang menandatangani sertifikat tersebut, atau dalam kata lain yang menjamin data tersebut tidak dikenal.

Jadi kapan harus menggunakan Sertifikat SSL berbayar?

Ketika Anda berniat menjalankan situs yang melayani transaksi online untuk publik internet. Bentuk transaksi online ini bisa berupa toko online atau lainnya. Dengan memberikan Sertifikat SSL yang valid dikenali oleh browser, Anda bisa lebih meyakinkan calon pembeli untuk berbelanja di toko online Anda.

Kapan Self-Signed Certificate bisa ditolerir?

Kalau layanan yang diberikan hanya untuk kalangan terbatas saja. Misal untuk kalangan internal sebuah perusahaan saja, atau sebuah organisasi tertentu saja.

Terjemahan TAG: acl di squid.conf

Mari kita mulai dengan membaca tipe-tipe acl yang didefinisikan di squid.conf. Jika Anda kesulitan memahami karena kendala bahasa, saya coba terjemahkan blok acl tadi di bawah ini.

#  TAG: acl
#   Mendefinisikan Access List
#
#   acl namaacl tipeacl string1 ...
#   acl namaacl tipeacl "berkas" ...
#
#   ketika menggunakan "berkas", di dalam berkas tersebut harus berisikan satu item
#   per baris
#
#   tipeacl adalah salah satu dari tipe-tipe yang dijelaskan di bawah
#
#   Secara default, regular expression diset CASE-SENSITIVE
#   untuk membuatnya case-insensitive, gunakan opsi -i 
#
#   acl namaacl src      alamat-ip/netmask ...       (alamat IP klien)
#   acl namaacl src      alamat1-alamat2/netmask ... (rentang dari alamat-alamat)
#   acl namaacl dst      alamat-ip/netmask ...       (alamat IP dari targer URL)
#   acl namaacl myip     alamat-ip/netmask ...       (alamat IP untuk local socket)
#
#   acl namaacl arp      alamat-mac ... (format penulisannya xx:xx:xx:xx:xx:xx )
#     # ACL arp memerlukan opsi khusus saat mengkonfigurasi --enable-arp-acl.
#     # Lebih jauh lagi, ACL arp tidak berlaku untuk semua sistem operasi.
#     # Berfungsi di Linux, Solaris, FreeBSD dan beberapa varian *BSD.
#     #
#     # CATATAN: Squid hanya bisa mendeteksi alamat MAC dari klien yang ada di
#     # subnet yang sama. Jika klien berada di subnet yang berbeda, maka Squid tidak
#     # bisa mengetahui alamat MAC nya.
#
#   acl namaacl srcdomain   .fulan.com ...  # reverse lookup, IP klien
#   acl namaacl dstdomain   .fulan.com ...  # server tujuan dari URL
#   acl namaacl srcdom_regex [-i] xxx ...   # regex yang cocok dengan nama klien
#   acl namaacl dstdom_regex [-i] xxx ...   # regex yang cocok dengan server
#     # Untuk dstdomain dan dstdom_regex reverse lookup dicoba jika URL berbasiskan
#     # IP yang digunakan tidak ada yang cocok. Nama "none" digunakan jika reverse
#     # lookup gagal.
#
#   acl namaacl time     [day-abbrevs]  [h1:m1-h2:m2]
#       day-abbrevs:
#       S - Sunday (Minggu)
#       M - Monday (Senin)
#       T - Tuesday (Selasa)
#       W - Wednesday (Rabu)
#       H - Thursday (Kamis)
#       F - Friday (Jumat)
#       A - Saturday (Sabtu)
#       h1:m1 harus kurang dari h2:m2
#   acl namaacl url_regex [-i] ^http:// ...    # regex yang cocok di URL secara 
#                                                keseluruhan
#   acl namaacl urlpath_regex [-i] \.gif$ ...  # regex yang cocok pada bagian 
#                                                path URL
#   acl namaacl urllogin [-i] [^a-zA-Z0-9] ... # regex yang cocok pada bagian 
#                                                login URL
#   acl namaacl port     80 70 21 ...
#   acl namaacl port     0-1024 ...            # rentang diperbolehkan
#   acl namaacl myport   3128 ...              # (local socket TCP port)
#   acl namaacl proto    HTTP FTP ...
#   acl namaacl method   GET POST ...
#   acl namaacl browser  [-i] regexp ...
#     # pola yang cocok pada header User-Agent (lihat juga req_header di bawah)
#   acl namaacl referer_regex  [-i] regexp ...
#     # pola yang cocok pada header Referer
#     # Referer sangatlah tidak reliable, jadi gunakan dengan hati-hati
#   acl namaacl ident    namauser ...
#   acl namaacl ident_regex [-i] pattern ...
#     # string yang cocok pada keluaran ident.
#     # gunakan REQUIRED untuk menerima semua ident yang tidak kosong.
#   acl namaacl src_as   angka ...
#   acl namaacl dst_as   angka ...
#     # Kecuali untuk access control, AS number bisa digunakan untuk 
#     # mengarahkan request ke cache tertentu. Sebagai contoh untuk mengarahkan
#     # semua request untuk AS#1241 dan hanya itu saja ke cachesaya.domainsaya.net:
#     # acl ascontoh dst_as 1241
#     # cache_peer_access cachesaya.domainsaya.net allow ascontoh
#     # cache_peer_access cachesaya.domainsaya.net deny all
#
#   acl namaacl proxy_auth [-i] namauser ...
#   acl namaacl proxy_auth_regex [-i] pattern ...
#     # daftar dari namauser yang valid
#     # gunakan REQUIRED untuk menerima semua username yang valid. 
#     #
#     # CATATAN: ketika header Proxy-Authentication dikirim tetapi dia tidak
#     # diperlukan pada saat pengecekan ACL, maka username TIDAK akan dicatat
#     # di access.log.
#     #
#     # CATATAN: proxy_auth memerlukan program autentikasi EXTERNAL
#     # untuk memeriksa kombinasi username/password (lihat direktif auth_param).
#     #
#     # CATATAN: proxy_auth tidak bisa digunakan di transparent proxy karena
#     # peramban perlu dikonfigurasi menggunakan proxy agar bisa merespon pada
#     # proses autentikasi proxy.
#
#   acl namaacl snmp_community string ...
#     # String community untuk membatasai akses ke agen SNMP Anda.
#     # Contoh:
#     #
#     # acl snmppublic snmp_community public
#
#   acl namaacl maxconn angka
#     # Ini akan cocok ketika alamat IP dari klien memiliki
#     # jumlah koneksi HTTP yang tersambung melebihi dari <angka>
#
#   acl namaacl max_user_ip [-s] angka
#     # Ini akan cocok ketika user mencoba login melebihi dari <angka> 
#     # alamat ip yang berbeda. Parameter authenticate_ip_ttl mengontrol
#     # nilai timeout pada entri-entri ip.
#     # Jika dituliskan -s maka pembatasannya ketat, browsing akan ditolak
#     # dari alamat IP lainnya sampai nilai ttl expire. Tanpa -s Squid hanya
#     # akan membuat user kesel dengan "secara acak" menolak akses.
#     # (pencatatan akan di reset setiap kali batasan tercapai dan request
#     # akan ditolak)
#     # CATATAN: pada mode akselerasi atau ketika disana ada banyak anak proxy,
#     # klien mungkin akan terlihat datang dari beberapa alamat saat mereka memasuki
#     # peternakan proxy, jadi pembatasan hanya 1 akan menyebabkan problem ke user.
#
#   acl namaacl req_mime_type mime-type1 ...
#     # regex yang cocok dengan mime type dari request yang digenerate oleh klien
#     # Dapat digunakan untuk mendeteksi berkas upload atau beberapa tipe request
#     # HTTP tunneling.
#     # CATATAN: Ini TIDAK akan cocok dengan reply. Anda tidak bisa menggunakan
#     # ini untuk mencocokkan dengan tipe berkas yang dikembalikan.
#
#   acl namaacl req_header header-name [-i] any\.regex\.here
#     # regex yang cocok dengan request header apa saja yang sudah dikenali.
#     # Mungkin bisa dianggap sebagai superset dari ACL-ACL "browser", "referer" dan
#     # "mime-type".
#
#   acl namaacl rep_mime_type mime-type1 ...
#     # regex yang cocok dengan mime type dari reply yang diterima oleh squid. Dapat
#     # digunakan untuk mendeteksi berkas yang didownload atau beberapa tipe dari
#     # request HTTP tunneling.
#     # CATATAN: Ini tidak akan berpengaruh pada aturan http_access. Ini hanya akan
#     # berpengaruh pada aturan yang mempengaruhi reply data stream seperti misalnya
#     # http_reply_access.
#
#   acl namaacl rep_header nama-header [-i] regex\.apa\.saja\.disini
#     # regex yang cocok dengan reply header apa saja yang sudah dikenali.
#     # Mungkin bisa dianggap sebagai superset dari ACL-ACL "browser", "referer" dan
#     # "mime-type".
#     #
#     # Contoh:
#     #
#     # acl banyak_spasi rep_header Content-Disposition -i [[:space:]]{3,}
#
#   acl nama_acl external nama_class [arguments...]
#     # ACL external yang melakukan pencarian melalui class bantu yang didefinisikan
#     # oleh direktif external_acl_type.
#
#   acl urlgroup group1 ...
#     # cocok dengan urlgroup seperti yang diindikasikan oleh redirector.
#
#   acl namaacl user_cert atribut nilai...
#     # cocok dengan atribut-atribut dari user sertifikat SSL
#     # atributnya adalah salah satu dari DN/C/O/CN/L/ST
#
#   acl namaacl ca_cert attribut nilai...
#     # cocok dengan atribut-atribut dari user-user yang menerbitkan sertifikat 
#     # CA SSL
#     # atributnya adalah salah satu dari DN/C/O/CN/L/ST
#
#   acl namaacl ext_user namauser ...
#   acl namaacl ext_user_regex [-i] pola ...
#     # string yang cocok dengan namauser yang diberikan oleh pembantu acl external
#     # gunakan REQUIRED untuk menerima namauser apa saja yang tidak-kosong.

Bagaimana? cukup banyak kan aclnya. Pusing? ya wajar lah hehe

ACL yang paling umum digunakan

Dari sekian banyak tipe acl yang bisa digunakan, menurut pengalaman saya hanya beberapa saja yang umum digunakan. Tentunya memang semua itu tergantung kebutuhannya. Walau tidak umum digunakan, tapi kalau memerlkukannya, mungkin saja digunakan dan sebaliknya.

Biasanya yang paling umum diguanakan adalah, src, dst, dstdomain, port. ACL lainnya yang mungkin sering ditemui adalah url_regex, proxy_auth, maxconn, max_user_ip, time.

Untuk lebih memahami cara penggunaan acl ini, saya akan coba berikan beberapa contoh penggunaan acl.

Contoh 1: Membatasi akses internet dari IP tertentu

Misal, dalam satu jaringan kantor, semua diperbolehkan mengakses internet via proxy. Kecuali beberapa komputer di meja penerima tamu atau front office.

acl jaringan_kantor src 192.168.1.0/24
acl front_office src 192.168.1.21    # komputer1 di front office
acl front_office src 192.168.1.22    # komputer2 di front office
acl front_office src 192.168.1.23    # komputer3 di front office
 
http_access deny front_office
http_access allow jaringan_kantor

Sekalian untuk format penulisan acl di atas, Anda bisa juga menuliskannya seperti di bawah ini.

Format inline, jadi IP dituliskan ke samping, tanpa menekan enter atau penanda baris baru.

acl jaringan_kantor src 192.168.1.0/24
acl front_office src 192.168.1.21 192.168.1.22 192.168.1.23
 
http_access deny front_office
http_access allow jaringan_kantor

Format rentang, karena kebetulan IP si komputer front office berurutan.

acl jaringan_kantor src 192.168.1.0/24
acl front_office src 192.168.1.21-192.168.1.23/32
 
http_access deny front_office
http_access allow jaringan_kantor

Silakan dilihat lagi di blok ACL yang sudah saya terjemahkan di atas.

Contoh 2: Membatasi akses ke situs tertentu

Anda ingin memblock beberapa situs porno yang paling sering dikunjungi oleh user Anda. Tentu saja ini cara paling sederhana, dan mungkin tidak cocok untuk memblock situs porno secara keseluruhan. Tapi ini hanya sekedar contoh saja.

Pertama, pastikan rules untuk membatasi akses ke situs porno itu muncul lebih dahulu, dibandingkan rules lain yang membolehkan akses internet. Lihat contoh dibawah ini. Kita akan menggunakan tipeacl dstdomain, yang bisa digunakan untuk menandai domain tujuan yang akan diakses.

acl situs_porno dstdomain .playboy.com
acl situs_porno dstdomain .porno.com
http_access deny situs_porno
 
acl jaringan_kantor 192.168.1.0/24
http_access allow jaringan_kantor

Contoh penempatan yang salah ada di bawah ini

# Contoh penempatan yang salah
 
acl jaringan_kantor 192.168.1.0/24
http_access allow jaringan_kantor
 
# rules di bawah ini tidak akan pernah dijalankan, karena akses sudah diperbolehkan
# di baris sebelumnya
acl situs_porno dstdomain .playboy.com
acl situs_porno dstdomain .porno.com
http_access deny situs_porno

Jadi perlu Anda ingat, posisi menentukan prestasi. Atau posisi rules yang Anda buat di squid.conf sangat menentukan apakah rules tersebut akan digunakan atau tidak.

Contoh 3: Membatasi akses internet di jam kerja

Kali ini kita akan menggunakan tipe acl time. Langsung saja ke contoh.

acl jam_kerja time MTWH 08:00-12:00  # Senin s.d Kamis jam 08:00 s.d Jam 12:00
acl jam_kerja time F 08:00-11:30  # Jumat 08:00-11:30 WIB
acl jam_kerja time MTWHF 13:00-16:00 # Senin s.d Jumat jam 13:00 s.d 16:00
 
acl jaringan_kantor src 192.168.1.0/24
 
# Buka akses internet, diluar jam kerja
http_access allow jaringan_kantor !jam_kerja

Lihat tanda seru (!) di depan acl. Yang berarti tanda negasi, atau NOT (bukan). Jadi artinya kita hanya membuka akses internet untuk jaringan_kantor dan waktunya bukan di jam kerja.

Contoh 4: Membatasi akses internet di jam kerja, kecuali manager dan bos

Contoh lain, kantor hanya ingin membuka akses internet untuk komputer-komputer manajer dan si Boss besar. Karyawan lainnya, bisa mengakses internet tapi hanya di luar waktu kerja.

acl jam_kerja time MTWH 08:00-12:00  # Senin s.d Kamis jam 08:00 s.d Jam 12:00
acl jam_kerja time F 08:00-11:30     # Jumat 08:00-11:30 WIB
acl jam_kerja time MTWHF 13:00-16:00 # Senin s.d Jumat jam 13:00 s.d 16:00
 
# jaringan kantor
acl jaringan_kantor src 192.168.1.0/24
 
# manager dan boss
acl manager src 192.168.1.51  # manager keuangan
acl manager src 192.168.1.52  # manager marketing
acl manager src 192.168.1.53  # general manager
acl boss src 192.168.1.68     # si boss besar
 
# Buka akses internet untuk manager dan boss, tanpa batasan waktu
http_access allow manager
http_access allow boss
 
# Untuk karyawan lainnya, buka akses internet diluar jam kerja
http_access allow jaringan_kantor !jam_kerja

Rangkuman

Di tulisan hari kedua ini, Anda sudah berkenalan dengan beberapa tipe acl. src untuk menandai alamat ip dari klien, dstdomain untuk menandai domain yang akan diakses, time untuk menandai hari dan jam.

Selain itu Anda juga sudah belajar bagaimana menggunakan acl tersebut untuk keperluan tertentu. Contoh yang dituliskan disini misalnya, untuk membatasi akses ke proxy (menggunakan direktif http_access).

Satu lagi yang perlu diingat dari pelajar hari ini adalah, posisi menentukan prestasi (ini biar Anda ingat saja ya hehe). Artinya posisi rules yang Anda buat, menentukan apakah rules tersebut akan berfungsi sesuai apa yang Anda inginkan atau tidak.

Mari kita mulai saja, kita akan menginstal squid proxy server di Ubuntu 8.04.

Instalasi

Menginstal squid sangatlah mudah, semudah menginstal aplikasi lain dari repositori Ubuntu.

sudo apt-get install squid

Untuk menjalankan squid, bisa menggunakan perintah,

sudo /etc/init.d/squid start

Untuk mematikan squid, bisa menggunakan perintah,

sudo /etc/init.d/squid stop

Mengkonfigurasi

Setelah squid terinstal, lokasi konfigurasi ada di /etc/squid/squid.conf. Mari kita backup terlebih dahulu, karena kita akan melakukan beberapa perubahan di berkas konfigurasi tersebut.

sudo cp /etc/squid/squid.conf /etc/squid/squid.conf.asli

Sebelum kita lanjutkan, saya ingin menunjukkan sesuatu. Coba jalankan perintah di bawah ini,

sudo cat /etc/squid/squid.conf |wc -l

4529

Hasilnya kira-kira seperti tertulis di atas, yaitu 4529. Artinya berkas squid.conf yang akan kita sunting memiliki 4529 baris. Wow! Pantas kalau banyak admin pemula yang bingung ketika akan mengkonfigurasi squid.

Berbeda dengan apache atau postfix, pemaket sudah menyiapkan konfigurasi yang siap pakai, yang artinya begitu postfix atau apache diinstal sudah ada contoh yang bisa dilihat dan bisa dijalankan langsung. Tapi untuk paket squid di Ubuntu ini, squid.conf yang disertakan bukanlah contoh siap pakai. Berkas ini lebih mirip berkas dokumentasi hehe.

Oke, cukup ceritanya sampai disitu, mari kita mulai mengkonfigurasi. Dari sekian ribu baris, sebetulnya untuk menjalankan squid sebagai web proxy, kita hanya perlu mengkonfigurasi beberapa baris saja. Mari kita lihat apa saja yang harus dikonfigurasi.

acl dan http_access

Sebetulnya ini adalah topik yang besar, dan sudah saya rencanakan untuk membahasnya secara terpisah. Tapi karena untuk tahap awal, kita harus mengijinkan akses dari LAN agar bisa menggunakan proxy, kita bahas sekilas saja.

Yang perlu Anda ketahui, konfigurasi squid dibaca dari atas ke bawah. Artinya, yang pertama kali cocok, itulah yang menang. Selalu ingat konsep dasar ini, karena akan sangat penting untuk memahami mengapa konfigurasi squid Anda tidak bekerja dengan seharusnya.

Ok, sekarang kita harus membuat acl baru untuk mengijinkan semua IP di LAN Anda bisa menggunakan squid proxy yang baru diinstal.

Misal, Anda memiliki dua LAN, 192.168.1.0/24 dan 192.168.2.0/24. Maka konfigurasinya,

acl jaringan_saya src 192.168.1.0/24 192.168.2.0/24
http_access allow jaringan_saya

Jika Anda menginginkan hanya IP tertentu saja, bukan satu network, Anda bisa juga menuliskannya seperti di bawah ini.

acl jaringan_saya src 192.168.1.0/24 192.168.2.0/24
http_access allow jaringan_saya
 
acl kantor_cabang src 192.168.5.5
http_access allow kantor_cabang

Sekarang IP 192.168.5.5 yang ada di kantor cabang, bisa juga menggunakan proxy yang baru Anda buat.

cache_dir

Yang lain yang bisa dikonfigurasi saat ini adalah cache_dir. Defaultnya,

cache_dir ufs /var/spool/squid 100 16 256

Saya jelaskan singkatnya, artinya lokasi direktori cache (tempat menyimpan objek yang dicache) ada di direktori /var/spool/squid dan dialokasikan sebesar 100 mega bytes. Angka 16 dan 256 adalah jumlah direktori cache yang dibuat. 16 artinya akan ada 16 direktori di /vaar/spool/squid, dan didalamnya masing-masing ada 256 direktori lagi.

Jadi kalau Anda ingin mengubah besar alokasi untuk cache, ganti angka 100 itu dengan angka baru. Misal untuk mengalokasikan sebesar 2 GB, ganti dengan 2000.

Menerapkan Konfigurasi

Untuk saat ini cukup dua konfigurasi itu saja (biar Anda tidak pusing). Setelah selesai menyunting berkas konfigurasi untuk menerapkan perubahan yang baru dibuat, Anda bisa merestart squid.

sudo /etc/init.d/squid restart

Tapi proses restart biasanya akan agak lama. Untuk mempermudah, tanpa perlu melakukan restart squid, jalankan saja perintah berikut.

sudo squid -k reconfigure

Berkas squid.conf sederhana

Dari 4529 baris, saya hapus baris yang tidak (atau belum) kita perlukan. Hasilnya kurang lebih ada seratusan baris, jadi Anda lebih mudah membacanya.

Silakan unduh berkas squid.conf untuk disimpan di /etc/squid/squid.conf.

Untuk hari pertama, cukup sampai di sini, sampai jumpa di seri tulisan squid selanjutnya.