Abstrak
analisis lalu lintas jaringan itu secara tradisional terbatas
untuk paket header, karena protokol transport dan aplikasi Port yang biasanya cukup untuk mengidentifikasi protokol aplikasi. Dengan munculnya port-independen, peer-to-peer, dan dienkripsi protokol, tugas mengidentifikasi aplikasi protokol menjadi semakin menantang, sehingga menciptakan motivasi untuk membuat alat dan perpustakaan untuk klasifikasi protokol jaringan. Karya ini meliputi desain dan implementasi nDPI, sumber terbuka Perpustakaan untuk protokol klasifikasi menggunakan kedua paket header dan muatan. nDPI disahkan secara ekstensif diberbagai monitoring proyek-proyek mulai dari Linux kernel protokol klasifikasi, untuk Analisis lalu lintas 10 Gbit, pelaporan kedua protokol tinggi deteksi akurasi dan efisiensi.
I. PENDAHULUAN
Dalam hari-hari awal Internet, Jaringan lalu lintas protokol dikenali oleh protokol dan pelabuhan. Contoh SMTP menggunakan TCP port 25 sementara telnet digunakan TCP port 23. Wellknow ini protokol/pelabuhan Asosiasi ditentukan dalam/etc/protocols file, yang merupakan bagian dari setiap sistem operasi berbasis Unix. Seiring waktu, dengan munculnya panggilan prosedur jauh (RPC),Port statis menjadi masalah. Oleh karena itu, aplikasi-aplikasi spesifik seperti rpcbind dan portmap dikembangkan untuk menangani dinamis pemetaan. Secarahistoris, aplikasi
Port sampai 1024 diidentifikasi Layanan sistem penting, seperti email atau sistem remote login dan karenanya memerlukan pengguna super hak istimewa; binding port untuk protokol mereka akan disimpan hingga
hari ini. Port di atas 1024 digunakan untuk ditetapkan pengguna layanan dan sangat umumnya dinamis. Identifikasi protokol ini sering tidak dapat diandalkan bahkan ketika statis port yang digunakan. Kasus di titik adalah TCP/80 digunakan untuk HTTP.
Awalnya, HTTP diciptakan untuk membawa web yang terkait dengan sumber daya seperti halaman HTML dan dekoratif konten. Namun, yang Ekstensibilitas di bagian kecil karena fleksibilitas header dan
MIME jenis spesifikasi) bersama dengan integrasi asli di
browser web HTTP sekarang sering digunakan untuk membawa bebas webrelated
sumber daya. Sebagai contoh, itu adalah sekarang protokol de-facto
untuk men-download/upload file, sehingga menggantikan mentransfer File
Protocol (FTP), yang dirancang khusus untuk itu
tujuan. Menyebar menggunakan HTTP dan dukungan asli
firewall (yaitu, firewall mengakui dan memvalidasi protokol
header), membuat HTTP (dan mitranya aman HTTPS)
pilihan ideal pengembang ketika membuat sebuah protokol baru yang telah
untuk melewati firewall tanpa pembatasan. Banyak peer-to-peer
Protokol dan aplikasi populer (misalnya, Skype) menggunakan HTTP sebagai
pilihan terakhir ketika mereka harus melewati firewall dikasus semua Port diblokir. Kami membuat laporan lalu lintas dari
berbagai jaringan, mulai dari situs akademik untuk komersial
ISP, dan menyadari bahwa HTTP adalah yang paling banyak digunakan
protokol. Ini tidak berarti bahwa pengguna sebagian besar menggunakannya untuk
berselancar di web. Protokol ini secara luas digunakan oleh sosial
Jaringan, geografis peta dan video streaming layanan.
Dengan kata lain persamaan TCP/80 = web ini tidak berlaku lagi.
Karakterisasi protokol jaringan diperlukan tidak
hanya untuk menciptakan akurat jaringan laporan lalu lintas, tetapi semakin,
untuk keseluruhan kebutuhan keamanan jaringan. Modern firewall
menggabungkan keamanan IP/protokol/port berbasis dengan protokol yang dipilih
inspeksi untuk memvalidasi protokol, khususnya orang-orang
Berdasarkan UDP, misalnya, protokol manajemen jaringan sederhana
(SNMP) dan Domain Name System (DNS). Protokol VoIP,
seperti SIP dan H.323, diperiksa untuk informasi spesifik,
Misalnya, IP dan port yang mana suara dan video akan mengalir. Cisco
Berbasis jaringan perangkat aplikasi pengakuan (NBAR) [1],
dan merintis Palo Alto jaringan berbasis aplikasi firewall [2]
aplikasi-protokol berbasis manajemen lalu lintas. Hari ini,
Fasilitas pemeriksaan lalu lintas ini tersedia pada setiap modern
Jaringan keamanan perangkat, karena pengikatan port/protokol
Metode ini sering bergantung pada sifat-sifat Statistik protokol
seperti paket ukuran dan intra-paket kedatangan waktu distribusi.
yang:
• Protokol tersebut mampu mengklasifikasikan hanya beberapa traf-
FIC kategori (urutan besarnya kurang DPI
Perpustakaan) dan dengan demikian kurang cocok untuk protokol halus granularity
Deteksi aplikasi.
• Beberapa tes menunjukkan tingkat signifikan ketidaktepatan mengusulkan
metode tersebut tidak mungkin berguna dalam pasif
Analisis lalu lintas, tetapi tidak mungkin untuk digunakan untuk misi
aplikasi kritis, seperti memblokir lalu lintas.
Kebutuhan ini merupakan motivasi untuk mengembangkan
efisien open source perpustakaan DPI mana efisiensi didefinisikan
oleh kebutuhan untuk memantau 10 Gbps lalu lintas menggunakan semata-mata
komoditi perangkat keras (yakni, tidak khusus hardware diperlukan).
Penggunaan open source penting karena:
• Komersial DPI Perpustakaan sangat mahal kedua dalam
syarat-syarat lisensi satu kali biaya dan pemeliharaan tahunan
biaya. Kadang-kadang mereka harga yang ditetapkan berdasarkan pada tahunan
pendapatan pelanggan, bukan pada tetap per-lisensi
biaya, sehingga lebih rumit skema harga.
• Sumber tertutup DPI toolkit sering tidak extensible oleh
pengguna akhir. Ini berarti bahwa pengembang bersedia untuk menambahkan
dukungan protokol baru/custom harus meminta ini
perubahan produsen Toolkit. Pada intinya, pengguna
oleh karena itu adalah pada belas kasihan DPI Perpustakaan vendor di
persyaratan biaya dan jadwal.
• Sumber-terbuka alat tidak memasukkan komersial DPI
Perpustakaan seperti mereka berada dalam Non-Disclosure
Perjanjian (NDA) yang membuat mereka cocok untuk menjadi
dicampur dengan perangkat lunak open source dan dimasukkan ke dalam
kernel sistem operasi.
Meskipun DPI adalah topik panas untuk waktu yang lama, selain
beberapa pengecualian langka, kebanyakan karya penelitian tidak mengarah ke
penciptaan sebuah toolkit DPI publik tersedia namun terbatas mereka
Ruang lingkup untuk prototipe atau alat prof-of-konsep.
nDPI desain dan implementasi, sedangkan bagian IV menjelaskan
proses validasi. Bagian V menyimpulkan kertas. The
saat ini bekerja pada nDPI dan rencana masa depan dijelaskan dalam
Bagian VI.
II. LATAR BELAKANG DAN MOTIVASI
DPI didefinisikan sebagai analisis paket data muatan
secara real time (yaitu, pengolahan DPI harus lebih cepat daripada
tingkat lalu lintas akan dimonitor dinyatakan akan menghasilkan
dalam paket tetes) pada lokasi fisik tertentu. Inspeksi
termotivasi oleh berbagai alasan, termasuk aplikasi protokol
identifikasi, analisis pola lalu lintas dan metadata (misalnya, pengguna
ekstraksi nama). Beberapa berpemilik DPI Perpustakaan vendor tersebut
sebagai iPoque, QOSMOS, dan kebun anggur mencakup semua aspek,
Protokol deteksi mungkin juga dapat dilaksanakan menggunakan pola
pencocokan atau dengan menggunakan protokol khusus decoder. The
mantan pendekatan tidak efisien karena penggunaan regularexpressions
[25] dan rawan kesalahan karena itu tidak merekonstruksi
Paket 6-tupel aliran (VLAN, protokol, IP /-
Port sumber/tujuan), dengan demikian sesuai salib-paket hilang.
Mencari pola dalam muatan un decoded dapat juga
mengarah keluar dari konteks Cari data (misalnya, email termasuk
kutipan dari koneksi HTTP mungkin bingung dengan
lalu lintas web) atau mismatches ketika paket tertentu (misalnya, bidang
Nama host NetBIOS) dikodekan.
Aplikasi drive pemilihan sesuai DPI
Perpustakaan. Kami memilih untuk fokus pada lalu lintas jaringan pemantauan yang
dapat berkisar dari analisis pasif paket untuk paket aktif inline
penegakan kebijakan. Perpustakaan DPI harus mencakup berikut
Fitur:
• High-reliability protokol deteksi inline, per aplikasi,
penegakan kebijakan protokol.
• Perpustakaan diperpanjang diperlukan untuk protokol baru dan
Runtime dalam protokol sub definisi. Fitur ini
diperlukan karena protokol baru muncul dari waktu
waktu atau berkembang (misalnya, protokol Skype berubah
secara signifikan sejak setelah Microsoft akuisisi).
Pemeliharaan Perpustakaan permanen adalah, oleh karena itu, diperlukan.
• Kemampuan untuk mengintegrasikan lisensi open source untuk
digunakan oleh aplikasi open source yang ada dan embedding
ke kernel sistem operasi. Sebagaimana telah
dibahas, penuh sumber kode ketersediaan sangat penting untuk
menjaga privasi.
• Ekstraksi metrik dasar jaringan (misalnya, Jaringan
dan aplikasi latensi) dan metadata (misalnya, DNS
permintaan/respon) yang dapat digunakan dalam pemantauan
aplikasi sehingga menghindari duplikat decoding paket,
sekali dalam perpustakaan DPI dan juga dalam pemantauan
aplikasi.
Fokus kami, oleh karena itu, dapat diandalkan protokol deteksi menggunakan
protokol decoder dikombinasikan dengan kemampuan untuk ekstrak dipilih
metadata parameter untuk penggunaan aplikasi yang
Perpustakaan ini. Hal ini memungkinkan ekstraksi metadata yang dipilih
parameter yang kemudian dapat digunakan oleh aplikasi yang menggunakan
Perpustakaan DPI. Perpustakaan deteksi protokol open source lainnya,
seperti libprotoident, terbatas dalam lingkup karena mereka tidak
ekstrak metadata dan hanya menganalisis 4 pertama B muatan di
setiap arah untuk deteksi protokol. Karena komersial DPI
Perpustakaan tidak boleh digunakan secara awal, kami memilih OpenDPI,
pendahulu open source komersial iPoque protokol
dan aplikasi klasifikasi mesin (PACE), yang tidak
lagi dikelola oleh para pengembangnya. OpenDPI dirancang
aplikasi protokol Deteksi dan metadata
Perpustakaan ekstraksi. Karena itu alihlah untuk beberapa waktu,
Perpustakaan tidak termasuk berbagai protokol modern (misalnya, Skype);
Kode adalah sebagian besar prototipe kualitas dan kemungkinan digunakan sebagai
suatu bukti dari konsep untuk produk komersial. Titik di
mendukung OpenDPI adalah fakta bahwa film ini akan didistribusikan di bawah
lisensi GPLv3 yang memungkinkan pengembang untuk memasukkannya dalam
aplikasi perangkat lunak tanpa terikat NDA atau lainnya
pembatasan khas produk DPI komersial. Selain itu,
lisensi open source yang memungkinkan kode untuk diperiksa, kunci
persyaratan ketika payload paket diperiksa dan berpotensi
informasi pribadi mungkin bocor. Pilihan kami OpenDPI
sebagai titik awal didorong oleh alasan ini.
A. dari OpenDPI untuk nDPI
Perpustakaan OpenDPI ditulis dalam C dan hal ini dibagi dalam dua
komponen utama: perpustakaan inti (bertanggung jawab untuk penanganan
Paket baku, decoding IP lapisan 3 dan 4, dan ekstraksi dasar
informasi seperti alamat IP dan port) dan plugin dissectors
(bertanggung jawab untuk mendeteksi protokol ~ 100 didukung oleh
OpenDPI). nDPI warisan arsitektur dua lapisan-lapisan ini tetapi
dialamatkan beberapa masalah hadir dalam desain OpenDPI:
• Perpustakaan OpenDPI dirancang untuk menjadi extensible,
Namun dalam prakteknya struktur data yang digunakan secara internal
• Kemampuan untuk mengintegrasikan lisensi open source untuk
digunakan oleh aplikasi open source yang ada dan embedding
ke kernel sistem operasi. Sebagaimana telah
dibahas, penuh sumber kode ketersediaan sangat penting untuk
menjaga privasi.
• Ekstraksi metrik dasar jaringan (misalnya, Jaringan
dan aplikasi latensi) dan metadata (misalnya, DNS
permintaan/respon) yang dapat digunakan dalam pemantauan
aplikasi sehingga menghindari duplikat decoding paket,
sekali dalam perpustakaan DPI dan juga dalam pemantauan
aplikasi.
Fokus kami, oleh karena itu, dapat diandalkan protokol deteksi menggunakan
protokol decoder dikombinasikan dengan kemampuan untuk ekstrak dipilih
metadata parameter untuk penggunaan aplikasi yang
Perpustakaan ini. Hal ini memungkinkan ekstraksi metadata yang dipilih
parameter yang kemudian dapat digunakan oleh aplikasi yang menggunakan
Perpustakaan DPI. Perpustakaan deteksi protokol open source lainnya,
seperti libprotoident, terbatas dalam lingkup karena mereka tidak
ekstrak metadata dan hanya menganalisis 4 pertama B muatan di
setiap arah untuk deteksi protokol. Karena komersial DPI
Perpustakaan tidak boleh digunakan secara awal, kami memilih OpenDPI,
pendahulu open source komersial iPoque protokol
dan aplikasi klasifikasi mesin (PACE), yang tidak
lagi dikelola oleh para pengembangnya. OpenDPI dirancang
aplikasi protokol Deteksi dan metadata
Perpustakaan ekstraksi. Karena itu alihlah untuk beberapa waktu,
Perpustakaan tidak termasuk berbagai protokol modern (misalnya, Skype);
Kode adalah sebagian besar prototipe kualitas dan kemungkinan digunakan sebagai
suatu bukti dari konsep untuk produk komersial. Titik di
mendukung OpenDPI adalah fakta bahwa film ini akan didistribusikan di bawah
lisensi GPLv3 yang memungkinkan pengembang untuk memasukkannya dalam
aplikasi perangkat lunak tanpa terikat NDA atau lainnya
pembatasan khas produk DPI komersial. Selain itu,
lisensi open source yang memungkinkan kode untuk diperiksa, kunci
persyaratan ketika payload paket diperiksa dan berpotensi
informasi pribadi mungkin bocor. Pilihan kami OpenDPI
sebagai titik awal didorong oleh alasan ini.
A. dari OpenDPI untuk nDPI
Perpustakaan OpenDPI ditulis dalam C dan hal ini dibagi dalam dua
komponen utama: perpustakaan inti (bertanggung jawab untuk penanganan
Paket baku, decoding IP lapisan 3 dan 4, dan ekstraksi dasar
informasi seperti alamat IP dan port) dan plugin dissectors
nDPI warisan arsitektur dua lapisan-lapisan ini tetapi
dialamatkan beberapa masalah hadir dalam desain OpenDPI:
• Perpustakaan OpenDPI dirancang untuk menjadi extensible,
Namun dalam prakteknya struktur data yang digunakan secara internal
statis. Sebagai contoh, banyak jenis data dan bitmap,
digunakan untuk menjaga keadaan untuk semua protokol yang didukung,
terikat untuk ukuran tertentu (misalnya, 128 bit) dan dengan demikian
membatasi jumlah protokol diidentifikasi.
• Setiap kali sebuah protokol terdeteksi, Perpustakaan berusaha
Temukan lebih lanjut protokol sesuai bukan hanya mengembalikan
pertandingan pertama. Hasilnya adalah kinerja penalti
tanpa kebutuhan nyata memerlukan e
Table I. EVALUATION OF THE LATEST VERSION OF NDPI.
automata berdasarkan Multifast2
Perpustakaan yang mengimplementasikan
string yang cocok sesuai dengan algoritma Aho-Corasick. Ini
Perpustakaan ini cukup efisien: pada saat startup penciptaan automata mengambil
sedikit waktu (yaitu, hampir seketika dengan sepersepuluh dari string,
atau beberapa detik dengan seratus ribu senar), maka ini
Perpustakaan dikonfigurasi melakukan lebih dari 10 Gbps selama pencarian ketika
dikonfigurasi dengan seratus ribu string.
IV. NDPI VALIDASI
Terdapat karya-karya hari yang membandingkan keakuratan nDPI di
persyaratan protokol deteksi terhadap toolkit DPI lain. Mereka
Kesimpulannya adalah bahwa "nDPI dan libprotoident yang sukses
benar mengklasifikasikan sebagian (walaupun diakui tidak semua) dari
aplikasi yang kita meneliti dan hanya salah satu dievaluasi
Versi (svn revisi 7249 atau yang lebih baru), kami memutuskan untuk menghapus
penggunaan heuristik ini, sehingga kita pada dasarnya menghilangkan
positif palsu pada biaya sedikit meningkatkan jumlah
arus terdeteksi dengan menggunakan protokol-protokol ini dua. Kami juga
kembali dilaksanakan dukungan untuk beberapa protokol lainnya, seperti FTP,
SOCKSv4, SOCKSv5, eDonkey, PPLive, Uap, RTMP, dan
Versi terbaru dari nDPI diuji menggunakan sama
metodologi dan dataset sama seperti [27], sehingga kami bisa
membandingkan hasil dan menunjukkan dampak perubahan terbaru.
Pada dasarnya, tanah-kebenaran didirikan oleh berbasis host
lalu lintas sistem, yang menandakan arus oleh proses pemantauan
nama-nama yang Diperoleh dari alas sistem. Hasil
istilah persen dari arus diklasifikasikan dengan benar, salah, dan
kiri unclassified untuk protokol paling populer, aplikasi,
dan layanan web yang ditampilkan di meja saya. Kadang-kadang, hasil
Diperoleh pada tingkat lain daripada tes diduga. Untuk
contoh, ketika kita diuji untuk kemampuan untuk mendeteksi HTTP
lalu lintas, kami juga memperoleh hasil sebagai Google, Facebook, atau
DropBox. Dalam evaluasi ini, kami mengakui hasil tersebut sebagai benar, meskipun protokol tidak secara eksplisit diberi.
Yang dapat menyebabkan ketidaktepatan kecil dalam kasus jika terdeteksi
Lalu-lintas Facebook sebenarnya adalah bukan HTTP (tapi, misalnya, SSL).
Ini adalah satu-satunya perbedaan dari tes dilakukan di [27]
mana hanya hasil pada tingkat diajukan dianggap sebagai
benar (misalnya, HTTP), sementara yang lain (misalnya, Facebook)
dianggap sebagai unclassified).
Karena ada banyak tes yang luas di nDPI protokol deteksi
akurasi, makalah ini berfokus pada kinerja nDPI. Untuk
tujuan tersebut, kami mengembangkan sebuah aplikasi bernama pcapReader3
yang baik dapat menangkap dari perangkat jaringan fisik dan membaca
paket dari pcap file. Untuk menguji nDPI pada jaringan fisik di
contoh untuk inti yang berbeda. Singkatnya, 10 Gbps lalu lintas dapat diperiksa ketika di seluruh dua Core (di atas tes menunjukkan DPI di 8 Gbps menggunakan satucore), menggunakan perangkat keras sederhana dengan harga komoditas kami digunakan dalam pengujian kami. Dalam hal penggunaan memori, nDPI kebutuhan beberapa memori untuk memuat konfigurasi dan automatas digunakan untuk string berbasis pencocokan. Ini memori yang digunakan oleh nDPI adalah ~ 210 KB tanpa konfigurasi kustom dimuat bahwa kenaikan ~ 25 KB ketika konfigurasi kustom yang dimuat. Selain itu, nDPI tetap per-aliran informasi yang independen dari aplikasi protokol dan yang membawa ~ 1 KB per aliran. V. KESIMPULAN
makalah ini menyajikan nDPI, toolkit open source yang dirilis di bawah lisensi GPLv3 tersedia di https://svn.ntop.org/svn/ntop/ batang/nDPI /. Ini saat ini mampu mendeteksi lebih dari 170 protokol termasuk Skype, BitTorrent, dan protokol pesan lainnya. Tes validasi dilakukan oleh pihak ketiga menunjukkan nDPI yang melebihi toolkit beberapa komersial dan open source dalam hal akurasi pengenalan protokol. Dalam hal kinerja, menggunakan dua core CPU dan hardware komoditas, nDPI dapat menangani10 Gbit link penuh sarat dengan lalu lintas Internet. Hal ini membuatnya cocok untuk skenario dimana keakuratan Deteksi dan kinerja tinggi adalah persyaratan. VI. FINAL PIDATO pengembangan nDPI masih berlangsung. Ada beberapa fitur pentingyang hilang dalam versi nDPI, namun, mereka yang direncanakan untuk dimasukkan dalam batang SVN resmi dalam waktu dekat. Satu kelemahan yang paling penting dari implementasi saat ini (serta dari mayoritas alat bantu klasifikasi lalu lintas yang saat ini ada) adalah kualitas hasil disediakan. Biasanya, kelompok menyediakanhanya hasil setiap aliran, yang seharusnya menjadi ciri aliran dalam cara yang paling rinci. Oleh karena itu, output adalah campuran dari hasil pada berbagai tingkat:IP protokol (yaitu, TCP atau UDP), protokol aplikasi (misalnya, DNS, HTTP, SSL, BitTorrent atau SMTPS), jenis konten (misalnya, MPEG, atau Flash), dan akhirnya, penyedia layanan (misalnya, Facebook atau YouTube). Kegunaan hasil tersebut sangat terbatas. Pada awalnya, satu aliran dapat menggunakan beberapa aplikasi protokol(seperti HTTP dan Dropbox). Kedua, suatu aplikasi protokol (sebagai DNS) dapatmenggunakan beberapa IP protokol (TCP dan UDP). Di ketiga, mustahil untuk menilai apakah tingkat yang paling rinci isi (sebagai Flash) atau layanan (seperti YouTube). Akhirnya, skema ini tidak memungkinkan untuk memberikan tepat akuntansi lalu lintas (misalnya, hal ini tidak mungkin untuk akun HTTP lalu lintas, jika hasil yang diberikan pada tingkat ganda, sehingga dalam sebagian besar kasus HTTP bahkan tidak disebutkan). Oleh karena itu, kita mengubah format hasil, sehingga semua klasifikasi mungkin akan diberikan secara konsisten.
