Cable Loss adalah total insertion loss pada sistem transmisi kabel. Cable loss mencakup penyisipan Loss pada kabel transmisi, kabel jumper, konektor dan pelindung petir. loss pada VSWR / power monitor, duplexer, combiner atau filter juga dapat menybabkan cable loss. Sebagai contoh, sistem transmisi kabel untuk antena 800 MHz terpasang di ketinggian 200 ft (61 m) pada sebuah menara dapat adalah sebagai berikut:
Kabel Transmisi: 7 / 8 “Andrew LDF5-50, 1,13 dB/100 ft (3,69 dB / 100 m) @ 824 MHz
Kabel Jumper: 1 / 2 Andrew “FSJ4-50B, 3,23 dB/100 ft (10,6 dB / 100 m) @ 824 MHz
230 ft (70 m) dari kabel transmisi= 2,60 dB
20 ft (6 m) jumper pada pemancar= 0,65 dB
10 ft (3 m) jumper pada antena= 0,32 dB
Koneksi pasang x 4 = 0,1 x 4=0,4 dB
Proteksi petir=0,1 dB Cable Loss (total loss sisipan)= 4,07 dB
Mengukur Cable Loss
Cable loss dapat diukur dengan peralatan yang sama yang digunakan untuk mengukur VSWR antena atau tingkat return loss. Sebuah Vector Network Analyzer (VNA) dengan sebuah mode cable loss tersembung pada pengukuran ini. Cukup menghubungkan salah satu ujung kabel Anda ke VNA, tempatkan VNA secara terbuka atau pendek pada ujung kabel, dan lakukan uji Cable Loss.
Sebuah VNA dengan distance-to-fault (DTF) atau mode lokasi kesalahan secara otomatis akan mengoreksi cable loss.
Cable loss per meter atau parameter kaki dimasukkan saat pengukuran DTF. Pengaturan pertama kali, hubungkan salah satu ujung kabel ke VNA dengan antena yang terhubung pada ujung kabel dan lakukan uji DTF. Hasilnya adalah sebuah VSWR antena atau pengukuran return loss mengoreksi cable loss.
Sebuah pengukur daya juga dapat digunakan untuk menghitung cable loss. Mengukur tingkat daya pada input dan output kabel anda, mengonversi ke satuan dBm, dan menghitung perbedaannya. Sebagai contoh, input daya 100 W (50 dBm) dan output 50 W (47 dBm) menghasilkan cable loss dari 3 dB (50 dBm – 47 dBm).
Jumlahkan parameter loss sisipan untuk setiap komponen transmisi kabel Anda pada frekuensi operasi Anda. Dengan catatan, loss sisipan meningkat seiring dengan meningkatnya frekuensi.
Server web standar pada Linux adalah Apache. Server web adalah teknologi yang menerima permintaan dari browser web dan menyajikan halaman web yang diminta untuk browser.
Versi desktop Ubuntu Linux tidak menginstal web server Apache secara default. Langkah pertama dalam membuat server web, oleh karena itu, adalah menginstal Apache. Hal ini dapat dilakukan baik dari baris-perintah atau dengan menggunakan Synaptic Package Manager. Untuk menggunakan Synaptic Package Manager, klik menu System, Administrasi pilih dan klik Synaptic Package Manager. Masukkan sandi Anda jika diminta untuk melakukannya. Klik pada tombol toolbar Search dan mencari apache2. Setelah pencarian selesai, Apache 2 Server harus tercantum di jendela Synaptic. Klik pada beralih berikutnya ke server Apache dan pilih Tandai untuk instalasi. Terakhir, klik Apply di toolbar untuk memulai instalasi.
Untuk menginstal Apache dari baris-perintah memulai sebuah jendela terminal (Applications-> Accessories-> Terminal) dan menjalankan perintah berikut pada prompt perintah:
Proses instalasi tidak akan hanya menginstal, tetapi juga menjalankan web server.
Pengujian Web Server
Setelah instalasi selesai langkah berikutnya adalah untuk memastikan server web dan berjalan. Untuk melakukan tes, kita dapat menguji melalui web browser. Caranya, buka web browser favorit kita, lalu ketik alamat 127.0.0.1. Itu adalah alamat localhost, atau kita juga bisa mengetik http://localhost/.
Konfigurasi Apache Web Server untuk Virtual Host
Langkah berikutnya dalam mengatur server web kita adalah dengan mengkonfigurasi nama domain. Ini dilakukan di / etc/apache2 direktori. Untuk mengkonfigurasi web server, buka terminal dan pindah ke direktori / etc/apache2. Dalam direktori ini, kita akan menemukan dua sub-direktori, yaitu sites-available dan sites-enable. Pindah ke direktori sites-enable. Dalam direktori ini kita akan menemukan file default yang dapat digunakan sebagai template untuk situs kita sendiri.
Salin default file ke sebuah file baru dengan nama yang sesuai dengan nama domain kita.Contoh:
sudo cp default webfirman.com
edit file webfirman.com menggunakan editor favoring kita. Berikut adalah isi dari file tersebut.
ServerAdmin webmaster@localhost
DocumentRoot /var/www/
Options FollowSymLinks
AllowOverride None
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
# This directive allows us to have apache2's default start page
# in /apache2-default/, but still have / go to the right place
#RedirectMatch ^/$ /apache2-default/
Jika kita menggunakan Ubuntu versi lama, isi file kita akan mengandung NameVirtualHost pada baris paling atas. Ubah menjadi komentar dengan menggunakan tanda #.
#NameVirtualHost *
Alasannya adalah bahwa parameter ini telah ditentukan di file sites-enabled/000-default file
NameVirtualHost 68.206.209.234
Jika parameter diatas tidak di beri komentar, maka ketika apache direstart akan muncul peringatan seperti ini:
[warn] NameVirtualHost *:0 has no VirtualHosts
Parameter ServerAdmin mendefinisikan alamat email web master jika ada yang ingin menghubungi admin web kita. Rubah sesuai dengan apa yang kita inginkan:
Selanjutnya parameter ServerName dan ServerAlias perlu ditentukan. Kita buat seperti contoh:
ServerName webfirman.com
ServerAlias www.webfirman.com
Langkah selanjutnya, kita perlu untuk mendefinisikan file konfigurasi web site kita yang pada parameter DocumentRoot. Biasanya /var/www/domainkita:
DocumentRoot /var/www/webfirman.com
Setelah selesai merubah konfigurasi pada file webfirman.com, kita perlu membuat symbolic link file tersebut dari /etc/apache2/sites-available/ ke /etc/apache2/sites-enable/. Ketik perintah:
Lalu, buat direktori /var/www/webfirman.com dan buat sebuah file html dengan judul index.html di dalamnya. Untuk isi file tersebut kita ambil contoh sebagai berikut:
Welcome to Webfirman.com
Langkah selanjutnya adalah restart apache:
sudo /etc/init.d/apache2 restart
Lalu kita coba buka pada web browser, masukkan alamat webfirman.com
HTTPS
Virtual Host merupakan cara untuk mengatur banyak website atau URL di dalam satu mesin atau satu IP. Misalkan kita mempunyai banyak domain tapi hanya mempunyai 1 IP public atau 1 server. Cara untuk mengatasi masalah itu adalah dengan cara membuat virtualhost yang ada di settingan apachenya. Virtual Host bisa anda gunakan setelah anda menginstall package-package apache dan sudah pasti web server anda sudah berjalan dengan baik. Sekarang kita langsung saja masuk ke dalah konfigurasi. Misalkan saya mempunya 2 buah domain [aminudin.net dan kelelawar.net] saya kebingungan karena saya hanya mempunyai 1 server, solusinya adalah anda harus mengarahkan domain tersebut ke IP server kita untuk contoh silahkan baca http://aminudin.net/?p=230 . kemudian seterusnya konfigurasi di sisi server nya kita lakukan konfigurasi virtualhost anda edit file yang berada di /etc/apache2/http.conf.
Konfigurasi
Install apache
# apt-get install apache2
Edit file “/ etc/apache2/apache2.conf”
# nano /etc/apache2/apache2.conf dengan menambahkan baris:
Sebelum Domain Name System (DNS), jaringan komputer menggunakan HOSTS files yang berisi informasi nama komputer dan alamat IPnya. File ini dikelola terpusat dan ditiap lokasi harus dibuat copy versi terbaru dari HOSTS files. Dengan penambahan 1 komputer di jaringan, maka kita harus copy versi terbaru ke setiap lokasi. Dengan peningkatan jaringan internet, hal ini makin merepotkan. Oleh karena itu DNS merupakan solusi untuk menggantikan fungsi HOSTS files.
DNS merupakan sistem database yang terdistribusi yang digunakan untuk pencarian nama komputer di jaringan yang menggunakan TCP/IP. DNS mempunyai kelebihan ukuran database yang tidak terbatas dan juga mempunyai performa yang baik. DNS merupakan aplikasi pelayanan di internet untuk menterjemahkan domain name ke alamat IP dan juga sebaliknya. DNS dapat dianalogikan sebagai pemakaian buku telefon dimana orang yang ingin kita hubungi, berdasarkan nama untuk menghubunginya dan menekan nomor telefon berdasarkan nomor dari buku telefon tersebut. Hal ini terjadi karena komputer bekerja berdasarkan angka, dan manusia lebih cenderung bekerja berdasarkan nama. Misalkan domain name yahoo.com mempunyai alamat IP 202.68.0.134, tentu mengingat nama komputer lebih mudah dibandingkan dengan mengingat alamat IP.
STRUKTUR DNS
Domain Name Space merupakan hirarki pengelompokan domain berdasarkan nama. Domain ditentukan berdasarkan kemampuan yang ada di struktur hirarki yang disebut level yang terdiri dari :
Root-Level Domains : merupakan level paling atas di hirarki yang diekspresikan berdasarkan periode dan dilambangkan oleh “.”.
Top-Level Domains : berisi second-level domains dan hosts yaitu :
com : organisasi komersial, seperti IBM (ibm.com).
edu : institusi pendidikan, seperti U.C. Berkeley (berkeley.edu).
org : organisasi non profit, Electronic Frontier Foundation (eff.org).
o net : organisasi networking, NSFNET (nsf.net).
gov : organisasi pemerintah non militer, NASA (nasa.gov).
mil : organisasi pemerintah militer, ARMY (army.mil).
xx : kode negara (id:Indonesia,au:Australia)
Second-Level Domains : berisi host dan domain lain yang disebut subdomain. Contoh dapat dilihat pada gambar 1. Domain Wijaya, wijaya.com mempunyai komputer server1.wijaya.com dan subdomain ws.wijaya.com. Subdomain ws.wijaya.com juga mempunyai host client1.ws.wijaya.com.
Host Name : domain name yang digunakan dengan host name akan menciptakan fully qualified domain name (FQDN) untuk setiap kompueter. Contohnya, jika terdapat fileserver1.wijaya.com, fileserver1 adalah host name dan wijaya.com adalah domain name.
SERVER NAMA dan ZONA
Program yang menyimpan informasi tentang domain name space disebut server nama (name server). Server nama biasanya mempunyai informasi yang lengkap mengenai bagian-bagian dari domain name space yang disebut zona (zone), yang biasanya diambil dari file atau dari Server nama lainnya. Server nama mempunyai otoritas (authority) untuk zona tersebut, dan Server nama juga dapat mempunyai otoritas untuk banyak zona.
Perbedaan antara sebuah zona dan sebuah domain adalah penting. Semua top-level domain, dan banyak second-level domain dibagi menjadi unit-unit yang lebih kecil.
Unit-unit tersebut disebut zona.
Gambar 2.2 Domain edu dibagi menjadi zona-zona (diambil dari
Pada gambar diatas domain edu dibagi menjadi zona-zona, termasuk zona berkeley.edu, zona purdue.edu, dan zona nwu.edu. Bagian atas dari domain edu, juga terdapat zona edu. Domain delegation seperti mendelegasikan tugas-tugas. Seorang manajer dapat membagi proyek besar menjadi tugas-tugas yang lebih kecil dan mendelegasikan tanggung jawab untuk tiap tugas kepada karyawan yang berbeda.
4. RESOLVERS
Resolvers merupakan client yang mengakses Server nama. Umumnya resolver melakukan :
• Query sebuah server nama.
• Menginterpretasikan respon (dapat berupa resource record atau sebuah error).
• Mengirimkan kembali informasi kepada program yang memintanya.
Dalam BIND (Berkeley Internet Name Domain), implementasi UNIX untuk sebuah server DNS, resolver hanya merupakan sebuah set library routines yang menghubungkan kedalam program seperti telnet dan ftp. Bahkan hal ini bukan merupakan proses yang terpisah dengan menggabungkan sebuah query, mengirim dan menunggu sebuah jawaban, dan untuk mengirimkan kembali query yang tidak mendapat jawaban.
5. RESOLUSI
Server nama diadaptasi dari mengambil data dari domain name space. Server nama tidak hanya memberikan data mengenai zona-zona yang diotoritasi oleh mereka, tapi juga mencari kedalam domain name space untuk mencari data yang tidak dalam otoritas mereka. Proses ini disebut resolusi nama (name resolution) atau resolusi.
6. Root Name Server
Root Name Server mengetahui tempat server-server nama untuk tiap domain toplevel. Dengan memberikan query mengenai sebuah nama domain, maka root name server dapat menyediakan nama-nama dan alamat-alamat server nama dari domain top level yang nama domainnya dicari. Dan server nama top-level dapat menyediakan list server-server nama yang berhubungan dengan domain second-level yang nama domainnya dicari. Tiap server nama yang diberikan query akan memberikan informasi cara untuk mendekati jawaban yang dicari, atau juga dapat menyediakan jawaban tersebut.
Root Name Server sangat penting dalam resolusi, maka DNS menyediakan mekanisme – seperti caching, yang akan dibahas dibawah – untuk membantu offload root name server. Tetapi dengan ketidakadaan dari informasi lain, resolusi harus dimulai dari root name server. Hal ini menyebabkan root name server sangat krusial bagi operasi DNS. Jika semua root name server internet tidak dapat dicapai dalam kisaran waktu tertentu, semua resolusi dalam internet akan gagal. Untuk menghindari hal ini, internet mempunyai tigabelas root name server yang tersebar pada jaringan. Server nama lokal akan memberikan query kepada root name server untuk alamat girigiri.gbrmpa.gov.au dan merujuk ke server nama au. Server nama lokal akan bertanya kepada server nama au pertanyaan yang sama, dan merujuk ke server nama gov.au. Server nama gov.au akan merujuk server nama lokal ke server nama gbrmpa.gov.au. Terakhir, server nama lokal akan bertanya ke server namagbrmpa.gov.au tentang alamatnya dan mendapatkan jawabannya.
7. Mapping Alamat ke Nama
Satu fungsi yang kuran dari proses resolusi adalah menjelaskan bagaimana alamat bisa di petakan kembali ke nama. Memetakan alamat ke nama dilakukan untuk menghasilkan keluaran yang dapat dibaca dan lebih cepat dimengerti. Dalam DNS, memetakan alamat ke nama tidak mudah. Data, termasuk alamat, dalam domain name
space diberi indeks. Dengan memberikan nama domain, menemukan alamat relative mudah. Tetapi untuk menemukan nama domain dari alamat memerlukan pencarian yang jeli kepada data pada diagram pohon tiap nama domain. Solusi terbaik adalah menciptakan bagian dari domain name space yang menggunakan alamat-alamat sebagai label. Dalam domain name space internet, porsi dari name space ini adalah domain in-addr.arpa.
Titik pada domain in-addr.arpa diberi label setelah representasi dotted-octet dari alamat IP. Domain in-addr.arpa dapat memiliki 256 subdomain yang berhubungan dengan tiap nilai yang munghin dalam oktet pertama dalam alamat IP. Setiap subdomain dapat mempunyai 256 subdomain lagi, berhubungan dengan nilai yang mungkin dari oktet kedua. Terakhir, pada level keempat, terdapat record sumber yang terhubung pada oktet terakhir yang akan memberikan nama domain lengkap dari host atau jaringan dari alamat IP tersebut. Perlu diperharikan bahwa saat membaca nama domain, alamat IP akan tampak mundur karena membaca dari ujung ke akarnya. Contohnya, jika alamat IP dari winnie.corp.hp.com adalah 15.16.192.152, maka subdomain dari in-addr.arpa nya adalah 152.192.16.15 yang akan memetakan kembali nama domainwinnie.corp.hp.com
8. CACHING
Proses resolusi keseluruhan terlihat sangat rumit, namun biasanya berlangsung cukup cepat. Kemampuan yang meningkatkan kecepatan ini disebut caching. Server-server nama akan meng-cache data-data untuk membantu meningkatkan kecepatan dari query. Jika sebuah resolver meng-query server nama untuk data domain nama yang diketahui oleh server nama tersebut, maka proses akan berjalan sedikit lebih cepat. Server nama dapat meng-chace jawaban yang akan meneruskan jawaban ke resolver.
Pada skala kecil, DNS adalah hal-hal yang diperlukan dalam pengoperasian internet . DNS bisa diperlukan dalam berbagai level perusahaan. Pada bahasan ini, akan dijelaskan beberapa macam security . Terbagi dalam 4 macam, yaitu :
1. Administrative security
Bagian ini menggunakan file permission, konfigurasi server, BIND konfigurasi, dan DMZ. Semua itu adalah teknik yang relative simple dan bias di aplikasikan pada DNS server yang berdiri sendiri
2. Zona transfer
Zona transfer bekerja menggunakan physical security, parameter pada BIND, atau eksternal firewall. Autentifikasi secara aman dari sumber dan tujuan dari zona transfer dapat atau tidak dapat di usahakan
3. Dynamic update
Dynamic update
4. Zona integritas
Hal – hal yang diperlukan zona data yang digunakan oleh salah satu DNS yang lain.
Karena itu, DNS sangat kritis dan penuh dengan perhitungan yang rumit dan termasuk mitos yang besar. Titik kritis dalam mendefinisikan kebijakan keamanan dan prosedur untuk memahami apa yang harus dijamin-atau tepatnya apa tingkat ancaman harus dijamin terhadap dan apa ancaman yang dapat diterima. Jawaban atas dua hal akan berbeda jika DNS adalah berjalan sebagai root-server versus berjalan sebagai-rumah sederhana di DNS yang melayani beberapa volume rendah web situs. Tidak ada aturan yang keras dan cepat; mendefinisikan kebijakan Anda adalah masalah paranoid pencampuran dengan penilaian.
DNS Normal Data Flow
Sumber ancaman yang potensial dapat diihat dalam gambar d bawah ini
Tahap pertama dari setiap review keamanan adalah ancaman audit yang berlaku dan bagaimana mereka dinilai serius dalam situasi organisasi tertentu. Sebagai contoh, jika dynamicupdates tidak didukung (modus default BIND's), tidak akan ada ancaman update dinamis.
Klasifikasi Keamanan
Klasifikasi keamanan merupakan sarana untuk memungkinkan pemilihan solusi yang tepat dan
strategi untuk menghindari risiko tersirat. Banyak metode-metode berikut ini dijelaskan. Penomoran berikut berhubungan dengan Gambar 10-1
ancaman Lokal (1): ancaman Lokal biasanya yang paling sederhana untuk mencegah, dan biasanya diimplementasikan hanya dengan menjaga kebijakan administrasi sistem suara. zona Semua file dan file konfigurasi lainnya DNS harus memiliki tepat membaca dan menulis akses, dan harus aman didukung atau diselenggarakan dalam repositori CVS. Stealth (atau Split) server DNS dapat digunakan untuk meminimalkan akses publik, dan BIND dapat dijalankan di kotak pasir atau penjara chroot (dijelaskan di bagian "BIND dalam Chroot Penjara" kemudian dalam bab ini).
Server-server (2): Jika sebuah organisasi budak menjalankan DNS server, perlu untuk melaksanakan zona transfer. Seperti disebutkan sebelumnya, adalah mungkin untuk menjalankan beberapa-master server DNS, bukan dari server master-budak, dan dengan demikian menghindari masalah yang terkait. Jika zona transfer diperlukan, BIND menawarkan beberapa parameter konfigurasi yang dapat digunakan untuk minimize risiko yang melekat dalam proses. TSIG dan Transaksi KEY (TKEY) juga menawarkan aman metode untuk otentikasi meminta sumber-sumber dan tujuan. Kedua metode dijelaskan secara rinci pada bagian "Mengamankan Zona Transfer" kemudian dalam bab ini. Transfer fisik dapat diamankan dengan menggunakan Secure Socket Layer (SSL) atau Transport Layer Security (TLS).
Server-server (3): default BIND adalah untuk menyangkal Dynamic DNS (DDNS) dari semua sumber. Jika sebuah organisasi memerlukan fitur ini, maka BIND menyediakan sejumlah konfigurasi parameter untuk meminimalkan risiko yang terkait; ini dijelaskan secara rinci nanti dalam bab. Jaringan desain arsitektur-yaitu, semua sistem yang terlibat dalam terpercaya perimeter-lebih lanjut dapat mengurangi eksposur tersebut. TSIG dan SIG (0) dapat digunakan untuk mengamankan transaksi dari sumber eksternal. Konfigurasi Stealth (Split) server digambarkan pada Bab 4 dan 7, dan TSIG dan SIG (0) keamanan yang dijelaskan dalam bagian "Mengamankan Dynamic Update "kemudian dalam bab ini.
Server-klien (4): Kemungkinan keracunan cache jauh karena spoofing IP, data antar-ception, dan hacks lainnya mungkin sangat rendah dengan situs web sederhana. Namun, jika situs tersebut profil tinggi, volume tinggi, terbuka untuk ancaman kompetitif, atau merupakan penghasil pendapatan yang tinggi, maka biaya dan kompleksitas penerapan solusi DNSSEC skala penuh mungkin bernilai-sementara. Upaya yang signifikan sedang diinvestasikan oleh pengembang perangkat lunak, Registry Operator, yang RIR, dan operator root-server, antara lain banyak, ke DNSSEC. Kita cenderung melihat signifikan trickle-down efek dalam waktu dekat dalam domain publik, serta dalam kelompok dikontrol seperti intranet dan extranet. Memang, Swedia akan menjadi yang pertama negara di dunia untuk menawarkan dukungan DNSSEC untuk se domain mulai tahun 2005 akhir
Klien-klien (5): standar DNSSEC.bis mendefinisikan konsep keamanan sadar penyelesai-suatu saat entitas-mitos yang dapat memilih untuk menangani semua validasi keamanan langsung, dengan nama lokal server bertindak sebagai gateway komunikasi pasif.
Konfigurasi defensif. Sebuah konfigurasi defensif adalah satu di mana semua, besar khususnya yang berkaitan dengan keamanan, fitur eksplisit diidentifikasi sebagai diaktifkan atau dinonaktifkan. Konfigurasi seperti mengabaikan semua pengaturan default dan nilai-nilai. Dibutuhkan sebagai titik awal situs kebutuhan, dan setiap mendefinisikan kebutuhan, positif atau negatif, dengan menggunakan laporan konfigurasi yang sesuai atau parameter lainnya. Default adalah orang malas besar bagi kami, tetapi mereka juga dapat berbahaya jika mereka berubah. Sebagai contoh, skrg sewa BIND versi Menonaktifkan DDNS secara default. Namun, banyak DNS administrator suka menambahkan pernyataan itu memungkinkan-update ("none";); secara eksplisit dalam klausul opsi global, baik sebagai jelas indikasi bahwa fitur tersebut tidak digunakan, dan sebagai perlindungan terhadap masa depan yang rilis dapat mengubah default. Sebuah file konfigurasi yang defensif mengidentifikasi semua persyaratan juga secara eksplisit mendefinisikan diri. Yaitu, dengan memeriksa file-tanpa perlu menemukan manual atau referensi dokumentasi-fungsi tersebut adalah jelas. Pada 03:00 saat pan-demonium terjadi, file diri terdefinisi tersebut dapat efek samping berguna. Deny All, Allow SelectivelyBahkan ketika operasi diperbolehkan, misalnya di NOTIFY atau zona transfer, itu mungkin bernilaiglobal menyangkal operasi dan selektif memungkinkan, seperti dalam fragmen berikut:
Remote Access. BIND rilis datang dengan alat administrasi yang disebut rndc (dijelaskan dalam Bab 9) yang mungkin digunakan secara lokal atau jarak jauh. Di satu sisi, rndc adalah tool yang berguna, sementara di sisi lain, jika Anda bisa masuk, sehingga dapat orang lain. BIND default adalah mengaktifkan rndc dari loopback tersebut alamat saja (127.0.0.1). Jika rndc tidak akan digunakan, harus secara eksplisit dinonaktifkan menggunakan null klausa kontrol, seperti yang ditunjukkan di sini:
// named.conf fragment
controls {};
....
Jika rndc digunakan, maka dianjurkan bahwa klausa kontrol eksplisit digunakan, bahkan jika
akses hanya diijinkan dari localhost, seperti yang ditunjukkan di sini:
// named.conf fragment
controls {
inet 127.0.0.1 allow {localhost;} keys {"rndc-key"};
};
ATTACKING DNS
PENGERTIAN DASAR TEKNIK-TEKNIK
SERANGAN TERHADAP DNS
Server-server DNS dapat diserang dengan menggunakan beberapa teknik, yaitu :
Serangan buffer overflow untuk mendapakan akses perintah ke server DNSatau merubah file-file dari zona.
Serangan penyingkapan/penyadapan informasi seperti transfer antar zona.
Serangan Cache poisoning sehingga cache dari DNS dikontaminasi oleh penyerang. Hal ini dilakukan dengan menggunakan prediksi ID transaksi atau query-query recursive.
Dalam teknik cache poisoning yang akan dijabarkan dibawah ini, diasumsikan server DNS targer adalah server BIND seperti mayoritas server DNS di internet.
CACHE POISONING MENGGUNAKAN PREDIKSI
ID TRANSAKSI
Misalkan saat sebuah klien dalam domain sa.com membuat permintaan untuk
membuka www.microsoft.com, maka akan terjadi urutan peristiwa sebagai berikut :
1. Klien akan menghubungi server DNS dan meminta membuka
www.microsoft.com. Query akan berisi informasi mengenai port UDP dari
klien, alamat IP dan sebuah ID transaksi DNS.
2. Karena server DNS klien bukan merupakan authoratative untuk domain
friendster.com akan melewati query-query recursive melalui server root DNS
di internet dan menghubungi server DNS friendster dan mendapatkan jawaban
untuk querynya.
3. Query yang berhasil ini kemudian diteruskan kembali kepada klien dan
informasi ini di cache oleh kedua server nama sa.com dan klien.
Hal-hal penting yang dapat dicatat adalah :
• Dalam langkah ketiga, klien hanya dapat menerima informasi jika server DNS
menggunakan port klien yang benar dan alamat sebagai tambahan kepada ID
transaksi DNS dalam langkah pertama. Ketiga informasi ini merupakan format
pembuktian (authentication).
• Informasi dari www.microsoft.com di cache oleh kedua klien dan server untuk
periode TTL (time to live) tertentu. Jika klien lain ingin bertanya kepada
ns1.sa.com untuk membuka www.microsoft.com selama proses TTL ini maka
server nama akan mengembalikan informasi dari cache dan tidak bertanya
kepada ns1.microsoft.com.
Perbedaan kebutuhan dibuat dalam ID transaksi yang dipakai antara klien dan server
nama dan ID transaksi antar server nama. Langkah-langkah diatas dapat disalah
gunakan oleh penyerang untuk meletakkan informasi yang salah dalam cache
nsi.jugi.com. Dalam ilustrasi dibawah ini, penyerang berusaha untuk memperkirakan
ID transaksi selama proses komunikasi antar server nama. Yang dilakukan penyerang
adalah :
• Mengirimkan permintaan resolusi dalam jumlah yang besar yang masingmasing
di spoof dengan informasi IP asal yang berbeda-beda untuk
www.microsoft.com kepada ns1.sa.com.
• ns1.sa.com akan mengirim tiap permintaan tersebut kepada server DNS dan
ns1.microsoft.com. Maka server ns1.sa.com menunggu balasan yang banyak
dari ns1.microsoft.com.
• Penyerang menggunakan proses menunggu ini untuk mengirimkan ns1.sa.com
banyak balasan dari ns1.microsoft.com. Tiap balasan yang palsu tersebut
mempunyai ID transaksi yang berbeda. Penyerang berharap untuk menebak ID
transaksi yang tepat yang digunakan oleh kedua server nama tersebut.
Jika penyerang berhasil maka informasi palsu tersebut akan disimpan dalam cache
ns1.sa.com. Hal ini merupakan serangan terhadap hubungan server nama dan server
nama yang akan mengakibatkan klien yang menggunakan server nama target akan
mendapatkan informasi yang palsu. ID transaksi BIND berada dalam kisaran 1-65535.
Tiga informasi yang dibutuhkan agar query dapat diterima yaitu ID transaksi, IP
sumber dan port sumber. Dengan mengetahui alamat IP sumber maka dapat diketahui
alamat server nama yang di query. Yang sulit dicari adalah port sumber. Seringkali
BIND akan menggunakan kembali port sumber yang sama untuk query dari klien
yang sama. Maka, jika penyerang bekerja dari sebuah server nama, maka dia dapat
meminta DNS untuK melihat hostname dari servernya dari server target dan saat
paket query recursif datang, maka port sumber didapatkan.
IMPLEMENTASI CACHE POISONING
Pada bab 4 ini, akan dibahas mengenai implementasi dari serangan cache poisoning
terhadap server DNS. Pada 4.1 merupakan implementasi serangan cache poisoning
yang saya dapatkan dari studi literatur makalah Attacking the DNS Protocol –
Security Paper v2, ESA Certification, Sainstitute.org. Pada 4.2 merupakan
implementasi serangan cache poisoning yang saya lakukan dengan cara sendiri.
Implementasi serangan-serangan ini dilakukan sebagai uji coba untuk pembelajaran.
CONTOH SERANGAN SERVER DNS
Cache Poisoning Pada Server DNS
Pada uji coba serangan ini, asumsikan server nama target adalah ns1.sa.com
(12.12.12.12) dan kita menginginkan untuk “meracuni” cachenya untuk mempercayai
bahwa www.microsoft.com memiliki alamat IP 10.10.10.10 dan dengan harapan
bahwa semua query yang akan datang dalam cache-nya akan terarah ke alamat
10.10.10.10. Dengan alamat server DNS dari microsoft.com adalah
ns1.microsoft.com (13.13.13.13).
Skrip pertama dari serangan ini disebut dns1.pl1 yang secara lengkap dapat dilihat dari
http://www.sainstitute.org/articles/tools/Dns1.pl . Serangan ini harus dijalankan dari
server nama autorisasi yang dikendalikan oleh penyerang untuk meng query server
nama target untuk sebuah hostname yang di autorisasi oleh mesin penyerang. Dalam
contoh ini, skrip dijalankan dari ns1.happydays.com dan penyerang meng query
server nama target untuk www.happydays.com :
dns1.pl 12.12.12.12 www.happydays.com
source port: 54532
Dengan demikian maka kita mendapatkan port sumber. Skrip kedua yang ditulis oleh
Ramon Izaguirre disebut hds0.pl2 ( http://www.sainstitute.org/articles/tools/Hds0.pl )
Permintaan pertama untuk resolusi dari ms2.sa.com dan jawaban yang palsu
dikembalikan oleh penyerang yaitu 10.10.10.10. Dibawah ini merupakan informasi
yang diterima dari sisi klien:
[root@fanta init.d]# nslookup
Default Server: [128.1.1.100]
Address: 128.1.1.100
> ms2.sa.com
Server: [128.1.1.100]
Address: 128.1.1.100
Name: ms2.sa.com
Address: 10.10.10.10
Informasi yang tidak benar dikembalikan ke klien dan diterima. DNS hijacker
mempunyai pilihan a-d dengan semua permintaan DNS diintersep/dicuri dan dibalas
dengan informasi yang tidak benar.
SERANGAN SERVER DNS
Pada bagian ini, akan ditunjukkan implementasi serangn server DNS dengan cara
pribadi yaitu serangan ke DNS lokal yang hanya mempengaruhi alamat IP sendiri saja
dan juga serangan ke server DNS yang mempengaruhi semua klien yang
menggunakan server tersebut.
Melalui DNS Lokal
Cache poisoning dapat dilakukan dengan melakukan perubahan pada DNS komputer
lokal. Dengan perubahan tersebut maka serangan hanya terjadi pada alamat IP lokal
klien tersebut (alamat IP yang digunakan adalah 167.205.66.11 dengan nama LSKK-
11) dan tidak mengenai klien-klien lain. Pada implementasi ini, yang akan dilakukan
adalah merubah pemetaan alamat IP dari www.friendster.com ke alamat IP
167.205.65.5. Alamat IP www.friendster.com yang sebenarnya adalah
209.11.168.242. Langkah-langkahnya adalah :
1. Mengedit file pada C:\WINDOWS\system32\drivers\etc\hosts dengan
menambahkan 167.205.65.5 www.friendster.com.
2. Pada konfigurasi LAN setting di internet explorer, ditambahkan
*.friendster.com.
Dengan melakukan kedua langkah tersebut maka www.friendster.com tidak akan
dilewatkan ke proxy. Maka hasil yang didapatkan adalah :
Gambar 4.2 Tampilan dari 167.205.65.5
Melalui Server DNS
Pada implementasi serangan ini, serangan akan ditujukan pada server DNS. Dampak
dari serangan ini adalah klien-klien yang berada dalam domain server tersebut akan
terserang. Dalam implementasi ini akan dicoba mengalihkan www.friendster.com ke
alamat IP 167.205.65.10. Langkah-langkahnya adalah dengan membuat zona baru:
1. konfigurasi named.conf
zone "friendster.com" {
type master;
file "db.friendster";
};
2. konfigurasi db.friendster
$TTL 30d
@ IN SOA ns.friendster.com. me.frenster.com. (
2004030304 ; serial
1d ; refresh
1h ; retry
30d ; expire
1d ) ; minimum
IN NS ns.friendster.com.
$ORIGIN friendster.com.
www IN A 167.205.65.10
Hasil apabila di query adalah :
^_^ nslookup
Default Server: ns.friendster.com
Address: 167.205.66.11
> ls -d friendster.com
[ns.friendster.com]
$ORIGIN friendster.com.
@ 4w2d IN SOA ns.friendster.com. me.frenster.com. (
2004030304 ; serial
1D ; refresh
1H ; retry
4w2d ; expiry
1D ) ; minimum
4w2d IN NS ns.friendster.com.
www 4w2d IN A 167.205.65.10
@ 4w2d IN SOA ns.friendster.com. me.frenster.com. (
2004030304 ; serial
1D ; refresh
1H ; retry
4w2d ; expiry
1D ) ; minimum
Terlihat bahwa www.friendster.com teralihkan tampilannya ke alamat IP
167.205.65.10, berarti serangan berhasil.
KEAMANAN DNS DARI SERANGAN CACHE
POISONING
Pada umumnya cache poisoning dapat dengan mudah dihadapi. Semua program DNS
mempunyai pilihan untuk mematikan atau menonaktifkan proses caching. Jika proses
caching tidak diaktifkan, menipu balasan kepada sebuah server adalah sia-sia.
Program yang paling terbaru telah mempunyai patch untuk melawan poisoning. Saat
ini, paket-paket yang diterima dengan cacatan authoritative / berkuasa diverifikasi
dahulu sebelum memasukannya ke dalam cache.
Mekanisme dan Implementasi Cache Poisoning Pada DNS Server Sandi Wijaya
EC5010 Keamanan Sistem Informasi ITB
Security
Jika anda memasang DNS server pada komputer yang berfungsi sebagai gateway antara jaringan internal anda dengan jaringan Internet serta DNS Server anda tidak melayani request dari luar (caching only DNS atau DNS untuk jaringan lokal saja) maka anda bisa membuat named untuk melayani hanya jaringan lokal saja dengan menambah baris berikut di dalam blok options:
listen-on { 127.0.0.1; 192.168.1.100; };
Sehingga named hanya membuka port pada interface loopback (127.0.0.1) dan eth0 (192.168.1.100)
