Web Uygulama Sızma Testleri İçin Kontrol Listeleri: I

Checklist for Web Application Pentesting 

Bugünden itibaren bir web uygulama sızma testinde temel olarak hangi testlerin yapılması gerektiğini konu edinen bir yazı dizisi oluşturmayı planlıyorum. Plana sadık kalabilirsem bu yazı dizisi, şu yazılardan oluşacak:

1. Application Information
2. Information Gathering & Configuration Management
3. Authentication
4. Session Management
5. Authorization
6. Data Validation
7. Denial of Service

1.  Application Information

• Uygulamanın IP adresi belirlenir.
• Uygulamanın üzerinde çalıştığı uygulama sunucu belirlenir.
• Uygulamada var olan roller ve kayıtlı kullanıcı bilgileri toplanır (Blackbox bir test değilse bu bilgi uygulama sahibinden alınır).
• Uygulama sunucuyu barındıran işletim sistemi tespit edilir.
• Uygulama yazılım dili belirlenir
• Ayrıntılı site haritası çıkarılır (crawling).
• Uygulama girdi (input) alanları belirlenir.
• Uygulamanın çalıştığı ana çatılar belirlenir (Joomla, LifeRay vb.).
• Web servisleri kullanılıp kullanılmadığı tespit edilir.

2. Information Gathering & Configuration Management

2.1. Minimum Bilgi Prensibi Testleri

• Uygulama özellikle uyarı mesajlarında minimum bilgi vermelidir. Örneğin:  “Şifreniz yanlış” ya da “Şifreniz 6 karakter olmalıdır” yerine  “Şifreniz ya da Kullanıcı İsminiz yanlış”  kullanılmalıdır.
• Uyarı mesajlarının kodları da değerlendirilmelidir. Aynı mesaj farklı kodlarla veriliyor olabilir. Örneğin:
• http://www.foo.com/err.jsp?User=baduser&Error=0
• http://www.foo.com/err.jsp?User=gooduser&Error=2
• Sayfa içindeki gizli alanlar dikkatle incelenmelidir; hassas bilgi içeriyor olabilir.
• Talebe dönen yanıtlarda (response) uygulamanın yazıldığı teknoloji hakkında bilgi olup olmadığı kontrol edilmelidir. Örneğin:
• X-Powered-By: ASP.NET
• X-AspNet-Version: 2.0.50727

2.2. Yardım Sayfaları

• Uygulamanın detayları ile ilgili bilgi verebileceğinden yardım sayfaları sadece kayıtlı kullanıcılara gösterilmelidir.

2.3. SSL Kullanımı

• Verinin internet tarayıcısı ile sunucu arasında şifrelenmesini sağlamak için mutlaka SSL kullanılmalıdır. Diğer taraftan SSL hizmeti veriliyor ise kesinlikle aynı uygulama (uygulama bölümü ) için SSLsiz hizmet sunulmamalıdır. Bu özellikle SSLStrip gibi HTTPS bağlantıları HTTP olarak yansıtan araya girme saldırını mümkün kılan ürünlerin kullanılabilmesi nedeniyle önemlidir.
• Sunucu sertifikasının onaylanmış bir sertifika makamı tarafından verilmiş olması ve tarayıcının da bu sertifikayı tanıması zaruridir, kontrol edilmelidir.
• SSL3.1 ve TLS1.1 altı protokoller, belirlenmiş açıklıkları olduğundan kullanılmıyor olmalıdır.

2.4. HTML Açıklama Satırları

• HTML kodunun içine gömülmüş ve daha sonra unutulmuş yorumlar,  kullanıcı bilgisi ya da sistem sürümü ile ilgili bilgiler içerebilirler. Bu nedenle varlıkları kontrol edilmelidir.

2.5. Sunucu Bilgisinin Kısıtlanması

• Özellikle hata sayfalarında sunucu bilgisi (özellikle 400 ve 500'lü HTTP response kodları) kullanıcıya gösterilmektedir. Minimum bilgi prensibi gereğince, bu bilginin saklanması gerekmektedir.
• Ayrıca yanıtta (response) "Server" başlığı bulunup bulunmadığı kontrol edilir.

2.6. Hata Sayfalarının Gösterimi

• Hata sayfaları 400’lü kodlar yerine 200’lü kodlarla tarayıcıya döndürülmeli ve mümkünse standart bir uygulama sayfasının (ana sayfa)  içinde görülebilir bir formatlama ile gösterilmelidir.

2.7. Dosya Uzantılarının Test Edilmesi

• Sitenin hangi tür bir yazılım altyapısına sahip olduğu konusunda bilgi verebilir. Özellikle sayfa kaynağı görüntülenip,  ilgili uzantılara erişilmeye çalışılabilir.  Diğer taraftan, JSP uzantılı bir uygulama PHP sayfalarını da yorumlayabiliyor olabilir.  Dolayısıyla, benzeri bir test bu kapsamda da gerçekleştirilebilir.

2.8. Yedeklenmiş yada Unutulmuş Dosyalar

• Uygulama geliştiricileri betik ya da sayfaları güncellerken, ilgili modüllerin yedeklerini almış olabilir. Örneğin Cp_config.jsp  config.jsp.backup gibi. Bu tür sayfalar henüz geliştirme aşamasında ya da test amaçlı oluşturulduğu için ciddi açıklıklar barındırabilir. Tespit edilmeleri önemlidir.

2.9. Yönetici Arayüzü Erişim Testi

• Test edilen site üzerindeki
• http://sirket.com.tr/admin
• http://sirket.com.tr/yonetici
• http://sirket.com.tr/manager gibi sadece yetkili kullanıcılara açık olması gereken bağlantılar tespit edilmeye çalışılır. Tespit edilmesi durumunda ise gerekli taramalar yapılır.
• Yönetici arayüzleri uygulama sunucuya göre değişebilir ya da web sunucudan farklı bir portta çalışabilir. Örneğin JBOSS JMX-CONSOLE ya da Glassfish Admin arayüzü gibi.

2.10. Desteklenen HTTP metotları ve XST Açıklığı

• HTTP servisi sunucular farklı HTTP metotlarını desteklemekte ve varsayılan kurulumda bu metotların bir kısmı aktiftir.  OPTIONS sorgusu ile hangi metotların desteklendiği bilgisine erişilebilir. OPTIONS sorgusunun kısıtlanması durumunda tarama araçları kullanılarak gerekli bilgiye ulaşmak mümkündür.

2.11. Bilinen Açıklıklar

• Uygulamanın üzerinde çalıştığı uygulama sunucu (hangi versiyon ise), yazıldığı programlama dili, mimarisinde kullanılan framework'ler ve teknolojiler için açıklanmış açıklıklar internetten taranmalı ve bu açıklıklar için gerekli önlemlerin alınıp alınmadığı mutlaka kontrol edilmelidir.

2.12. E-posta Adresleri Tespiti

• Web sayfalarında kaba bir şekilde tutulmuş e-posta adreslerinin varlığı, bu posta adreslerin otomatik tarama araçlarıyla yakalanmasına ve bu adreslerin "spam" e-postaların hedefi haline gelmesine sebebiyet verebilir. Bu tür e-posta adresleri sistemde otomatik araçlar tarafından yakalanamayacak şekilde tutulmalıdırlar. Örneğin:
• abc at hotmail nokta com

Bir sonraki yazı, kimlik denetimi (authentication) konulu test maddeleri üzerine olacak.

HTTP Security Header'ları Neden ve Nasıl Kullanılmalıdır?

Uygulama geliştirirken güvenlik adına genelde input validation ve session management konularına yoğunlaşılır; bu konu biraz ikinci planda kalır.

Mehmet İnce, header'larda güvenlik ayarı ile ilgili çok güzel bir yazı paylaşmış, şiddetle tavsiye edilir:
https://www.mehmetince.net/http-security-headerlari-neden-ve-nasil-kullanilmalidir/

Web Uygulama Sızma Testi Araçları

Bu yazı, web uygulama sızma testleri sırasında kullanılan araç çeşitlerini konu almıştır. Bu araçların hangi amaçla kullanıldığı anlatılarak kullanılabilecek bazı araçlar listelenmiştir. Amaç reklam yapmak değil, o konuda tecrübe sahibi olunan araçların paylaşılmasıdır; araç sahipleriyle hiçbir bağlantım yoktur.

Otomatik Açıklık Tarama Araçları

Web uygulama sızma testlerinde kullanılan en önemli araçlardır. Temel işlevleri, kendisine girdi olarak verilen bir web uygulamasının açıklıklarını tespit edip raporlamaktır. Bu amaçla aşağıdaki işlevleri gerçekleştirirler:

• Uygulama hakkında bilgi toplama. Uygulama sunucu, uygulamanın yazıldığı programlama dili gibi bilgilerin tespitine çalışılır; tam otomatize bir adımdır.
• Uygulama haritasını çıkarmak (crawling, spidering). Genelde tam otomatize bir adımdır; kimi zaman uygulama kullanıcısının müdahalesine ihtiyaç duyulabilir.
• Uygulama login ve logout mekanizmalarının belirlenmesi. Login için genellikle kullanıcı adı / parola gibi özel bilgiler gerekir; hangi yolların (linklerin) de logout olmaya neden olduğunun uygulamaya öğretilmesi gerekir. Bu nedenlerle bu adım genelde uygulama kullanıcısının müdahalesine ihtiyaç duyar.
• Bilinen zafiyetlere göre uygulama zafiyetlerinin tespiti. Otomatize bir adımdır. Bununla birlikte uygulamanın hangi zafiyet türlerine göre taranacağı, saniyede kaç talep (request) gönderileceği, taramanın hangi hassasiyette gerçekleştirileceği gibi ayarlar uygulama kullanıcısı tarafından yapılabilir.

Ticari ya da ücretsiz birçok otomatik tarama aracı mevcuttur. Bunlardan en yaygın kullanılanlarının konu edildiği Temmuz 2014 tarihli bir değerlendirme raporuna (https://www.qualys.com/docs/gartner-magic-quadrant-application-security-testing.pdf) adresinden erişilebilir.Değerlendirmeye göre magic quadrant şu şekilde oluşmuştur:

Değerlendirmeye konu edilen ticari araçlar yanında, açık kaynak kodlu ürünler de mevcuttur. W3AF bunlardan biridir. Ruby ile yazılmış ücretsiz bir araçtır. Ticari ürünlerin olmadığı durumlarda idare edebilecek kadar tarama yapar; ticari ürünler kadar iyi ve etkili değildir. Kendi modüllerinizi yazmanıza izin verir. Yakın zamanda Rapid7 ürünü kendi ürün ailesine katsa da halen açık kaynak bir üründür.

Personal Proxy (Kişisel Vekil Sunucu)

Web uygulama sızma testlerinde kullanılan en önemli araçlardan biri de kişisel vekil sunuculardır. Bu araçlar, istemci ile sunucu arasındaki trafikte araya girerek 7. katman seviyesindeki paketlerin incelenmesine ve yakalanıp değiştirilmesine olanak verir. Gerek manuel açıklık taramaları için, gerekse otomatik tarama araçları tarafından raporlanan zafiyetlerin gerçekten var olup olmadığını incelemek için kullanılır.

PortSwigger tarafından geliştirilmiş Burp Suite aracı, bu amaçla kullanılabilecek ürünlerden biridir. Ücretli olan Pro versiyonu da mevcuttur. Temelde HTTP ve HTTPS trafiğinde araya girme amacıyla kullanılmaktadır. Bunun yanında online kaba kuvvet (brute force) ve sözlük (dictionary) saldırıları, HTTP fuzzing gibi yetenekleri de mevcuttur. Bununla birlikte bir önceki maddede sözü edilen otomatik tarama araçları kadar yetenekli olmasa da zafiyet tarama yeteneği de vardır.

Bir diğer kişisel vekil sunucu da OWASP tarafından geliştirilen ve açık kaynaklı olan ZAP Proxy aracıdır. Bu aracın da zafiyet tarama yeteneği mevcuttur.

Sunucu Tarafı Açıklıkların Taranması

Web uygulama testlerinde birden fazla etkileşim arayüzü bulunmaktadır. Bunlardan biri uygulamanın kendisi ise, bir diğeri de uygulamanın üzerinde barındığı uygulama ve web sunucudur. Bu sunucu sistemlerin güvenliği de en az uygulamanın güvenliği kadar önemlidir.

Sunucu tarafı açıklıkların tespiti için Nessus ve benzeri bir zafiyet tarama aracı kullanılabilir. Ücretli olan Pro versiyonu da mevcuttur. Nessus Pro, sunucu tarafı açıklıkların yanı sıra ön tanımlı (default) değerlerde kalmış kullanıcı adı / parola çiftleri, internete açık şekilde bulunan içerik yönetim sistemi (CMS) arayüzleri, kullanılan SSL versiyonunun denetimi gibi temel düzeydeki web uygulama zafiyetlerini de tespit edebilecek modüllere sahiptir.

Tespit Edilen Zafiyetlerin Sömürülmesi (Exploitation)

Otomatik tarama araçları ya da manüel yollarla tespit edilen açıklıkların yanlış alarm (false positive) olup olmadığının belirlenmesi ve bu açıklıkları kullanarak nereye kadar gidilebileceğinin tespiti de oldukça önemlidir. Sızma testlerini (pentest) zafiyet taramalarından (vulnerability assessment) ayıran en önemli yön de budur.

Genel olarak, diğer tüm sızma testi türlerinde olduğu gibi web uygulama sızma testlerinde de tespit edilen zafiyetlerin sömürülmesi ve sömürü sonrası yapılabileceklerin belirlenmesi için Metasploit aracı kullanılabilir. Ürün ailesi içindeki msfconsole, msfcli, msfvenom ücretsizdir ve komut satırı çalışan ürünlerdir. Ücretli olan Pro versiyonu da mevcuttur ve web arayüzüne sahiptir.

SQL enjeksiyonu, web uygulamaları için en tehlikeli açıklıklardan biridir. Bu nedenle bu açıklıkla neler yapılabileceğinin belirlenmesi ayrıca önemlidir. Bu amaçla SQLMap aracı kullanılabilir. Ücretsizdir, KALI içinde de yer almaktadır. Komut satırı (command line) çalışan bir üründür. Her bir açıklık özel bir durum oluşturduğundan bir sürü parametre içerir; bu nedenle kullanımı oldukça zordur ancak bir o kadar da etkilidir.

Örnek verilebilecek bir diğer SQL enjeksiyonu istismar aracı da Havij’dir. Grafik arayüzü olan bir araçtır, bu nedenle SQLMap’e gönre kullanılışı oldukça basittir. Ticari bir üründür; ücretsiz versiyonu sadece 1-2 VTYS (Veritabanı Yönetim Sistemi) destekler.

Diğer Araçlar

Bunlara ilave olarak özel durumlarda farklı araçlar edinip testlerde kullanılmaya çalışılmaktadır: Web servis testleri olduğu takdirde SOAP UI, “thick client” bir uygulama söz konusu ise HTTP Debugger Pro aracı bu durumlarda kullanılabilecek araçlara örnektir.

CEH v7 Sınavına Çalışırken

• Ön tanımlı portlar (http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers):
• NTP ==> UDP 123
• Telnet ==> TCP 23
• SMTP ==> TCP 25
• DNS ==> TCP 53 & UDP 53
• SMTP ==> TCP 25
• Printer ==> TCP 515
• TFTP (Trivial FTP) ==> UDP 69
• Syslog ==> UDP 514
• SNMP ==> UDP 161
• SMB ==> TCP 445
• LDAP ==> TCP & UDP 389
• POP3 ==> TCP 110
• Kerberos ==> TCP & UDP 88
• PCI-DSS (Payment Card Industry Data Security Standard), senede en az 1 kez ve her kayda değer değişiklik ve güncelleme sonrası iç ve dış sızma testleri ihtiyacı olduğunu söyler.
• Saldırgan makinesinden zombi bilgisayara gönderilen IPID'ye, zombi bilgisayar talep kapalı porta geldiyse IPID+1, açık porta geldiyse IPID+2 olarak yanıt döner.
• Akıllı kartlar, sertifikalarını güvenli bir şekilde transfer etmek için EAP (Extensible Authentication Protocol) protokolünü kullanır.
• İnternetten kurum içine yapılacak bir testte, sınır uyarı sistemlerini alarma geçirmeden test yapabilmek için en etkili yol, taramayı SSH üzerinden tünellemektir.
• Smurf attack: Büyük miktarda ICMP paketini, hedeflenen kurban makinenin spoofed IP adresi ile oluşturup, IP broadcast adresi kullanarak bir networkte broadcast ederek yapılan DoS saldırısıdır. Bu, networkteki tüm hostların kurban mekineye yanıt dönmesine ve kurban makine üzerinde hatırı sayılır bir trafiğe neden olur. Bunu önlemenin yolu, router'ın broadcast ping mesajlarını kabul etmesinin engellenmesidir (disable).
• Fingerprinting VPN firewalls ==> Ike-scan
• Bir router'a TTL değeri 1 olan bir ICMP paketi geldiğinde router
• Paketi discard eder
• Paketi gönderen (kaynak) makineye "time exceeded" mesajı gönderir.
• Windows sistemlerde çalışan servisler, "sc query" komutu ile listelenebilir (Çok sayıda servis olduğundan terminalin buffer'ı hepsini göstermeye yetmeyebilir; komutu "| more" ile kullanmakta fayda var).
• Windows sistemlerde Microsoft tarafından imzalanmış kritik dosyaların bütünlüğü, "sigverif.exe" sistem aracı ile kontrol edilebilir.
• PKI, 1024-bit RSA algoritması kullanır.
• OSI modeli ve bazı süreçlerin yer aldığı katmanlar:
• 7. Application Layer
• 6. Presentation Layer
• 5. Session Layer
• 4. Transport Layer ==> TCP/IP Session hijacking, Circuit-level gateway
• 3. Network Layer
• 2. Data Link Layer ==> PPTP encryption
• 1. Physical Layer
• CISCO VPN config dosyalarının uzantısı "pcf"dir. Bu dosyalar bağlanma parolalarını içeriyor olabilir ve bu parolalar Cain and Abel ile decode edilebilir.
• Ethereal/Wireshark, TCPDump ve Snort, aynı paket yakalama özelliğine sahiptirler.
• Bir Windows makinede built-in firewall'ın ayarlarını command prompttan şu komutla öğrenebilirsiniz: "netsh.exe firewall show config"
• WPA2, 128 bit ve CCMP seviyesinde AES kullanır.
• Rubber Hose kriptografi saldırısı, genellikle bir bilgisayara ihtiyaç duyulmadan yapılır.
• Syskey, 128 bit encryption kullanır.

IPv6 - Saat 3

IPv4 - IPv6 İletişim - Çeviri
IPv4 bir cihaz ile IPv6 bir cihaz doğrudan haberleşemez.
Çeviri

• Çevirici, üzerinde çeviriyi yapan bir betik çalıştıran alelade bir bilgisayar.
• Uçtan uca bağlantıyı kesen - bozan bir yapı
• Video konferans, uzaktan erişim vb. durumlarda sıkıntı var.
• IPSec çalışmaz bu yöntemle. Göndericide hesaplanan bütünlük değeri ile alıcıda hesaplanan farklı olacak, arada çevirdik çünkü.
• Bu başlık altındaki yöntemler:
• NAT64 - DNS64
• Belirlenen önek arkasına IPv4 adresi eklenerek çeviri yapılıyor.
• IPv4 adresi, hexa olarak da decimal olarak da eklenebiliyor, ikisi de kabul ediliyor.
• Belirlenen ön ek: 64:FF9B::/96
• TRT
• IVI

IPv6 - Saat 2

IPv6 Adres Tipleri

• Unicast. Tek bir interface tanımlar
• Multicast. Bir gruba gönderilir
• Anycast. Paket sadece aynı adresi kullanan, bize en yakın üyeye gönderilir.

• IPv6'de
• Broadcast yok (Multicast var)
• NAT yok
• Küresel yönlendirilebilir IPv& adresleri, 2 ile başlıyor!
• 0::/8 bloğu
• Belirsiz adres: 0:0:0:0:0:0:0:0
• 0:0:0:0:0:0:0:1
• 001::/3 => Global unicast (Mantıken "küresel NAT" gibi düşünülebilir)
• Bir interface'e istediğimiz kadar adres verebiliriz
• Kernel seviyesinde "bu interface'e şu kadar adres verilebilir" diye ayarlamakta fayda var!
• Küresel yönlendirme öneki
• ISP'ler içim 32
• Diğer için 48
• FE80::/10 => Link local unicast - link local adres.
• Sadece lokalde bu tür adresler olması lazım, dışarıda görmememiz lazım aslında. Ama görülüyormuş...
• FF00::/8 => Multicast
• Streaming
• Lokal ağda kullanılacak gibi görünüyor.
• "Tüm multicast adresler" oluşturulduğunda v4'teki broadcast'e karşılık oluyor.
• IPv6 adreslerini
• Üniversitelere Ulakbim verecek
• Kamu kurumları ISP'lerden temin edebilecek
• Türk Telekom, IPv6 hizmeti sunmaya başladı

Başlık Yapısı

• Ek başlıklar kullanılmadıysa "paketin ilk şu kadarı başlıktır" diyebiliyoruz.
• Başlık paketleri
• Version
• Traffic class
• Flow label
• Payload length <==
• Next header <==
• Hoop limit <==
• Source address
• Destination address  
• Fragmentation işi, ek başlıklarla hallediliyor.
• IPv6, fragmentation'ı aradaki hiçbir cihaz yapmasın, source ile destination bilsin sadece. Böylece statement vs.'ye ihtiyaç kalmıyor
• UZANTI BAŞLIKLARI

ICMPv6

• Aradaki FW vb. cihazların, ICMP tiplerine göre filtreleme yapıabiliyor olması gerekecek.
• Tip alanı (ilk 8 bit)
• İlk bit 0 ise (0-127) => hata mesajı
• İlk bit 1 ise (128-255) => bilgi mesajı

• "goforit" projesi: Dünya çapında IPv6 destekleyen cihazlar
• Komşu keşfi (Neighbor discovery) protokolü
• ICMPv6 mesajlarını kullanır
• ARP + ICMPv4 router discovery + ICMPv4 redirect
• 2 tip adres yapılandırması
• Statik. Sunuculara yaparız, sonra o sunucuya otomatik ip yapılandırmasına girme deriz.
• Otomatik
• Stateless (durum denetimsiz). Kime ne IP verildiğini tutan bir şey yok. İlan edilen prefix'i (ilan eden muhtemelen router) alan cihaz, IP  üretir ve kullanır. Üretim MAC adresi kullanılarak yapılır.
• Yeni uygulamada, IP'den MAC adresi anlaşılmasın diye MAC kullanımından vazgeçiliyor.
• Stateful (durum denetimli). Dağıtılan IP'lerin tutulduğu durum.
• DHCPv6 kullanılabilir.
• Bir sıkıntı: Router advertisement ile gateway dağıtamıyoruz.
• Çok düşünülerek tasarlanmamış, durum denetimsiz kullanılması öngörülerek tasarım yapılmış.

IPv6 - Saat 1

 IPv6 Temelleri

• RFC 2460 - 2461
• Her ne kadar "Yeni Nesil IP yapılandırması" diyorsak da yaklaşık 10 yıllık bir teknoloji.
• En temel ihtiyaç sebebi: IPv4 32 bitlik adres yapısı (adresleme için yetersiz)
• 3 Şubat 2011: IANA, elinde kalan son /8 IPv4 aralıklarını bölgesel IP adresi dağıtım yetkililerine (RIR) paylaştırmış.
• NAT'ın temel sıkıntısı, uçtan uca bağlantı yapısını bozuyor olması.
• IPSec ya da uygulama seviyesinde IPv4'ün açıklarını kapatmaya çalıştık.
• "Otomatik IP yapılandırması"
• Durum denetimcisiz IP yapılandırması
• Örnek: Kablosuz sensör ağları
• ABD'nin Afganistan'da kullandığı iddiaları var.
• Servis kalitesi (QoS)
• Yeni teknolojilere adaptasyon kolaylığı sağlaması için esnek başlık parçası düşünülmüş. Yeni bir teknoloji için başlığın değişmesi düşünüldüğünde bu ek başlık, başlığa iliştiriliyor... diye anladım.
• IPv6, 128 bitlik adres yapısına sahip.

Yeni Güvenlik Özellikleri

• IPSec, bütünleşik olarak gelmekte.
• Güvenlik için ek başlıklar mevcut.

 Getirdikleri

• Sadeleştirilmiş başlık yapısı. Kullanmadığımız parametreleri kaldırıp ihtiyaç duyduğumuz yeni başlıkları ekleme.
• Otomatik adres yapılandırması 
• Neighbor Nodes ile etkileşim için yeni protokol
• ICMPv6
• Multicast
• Dolaşılabilirlik. Farklı ağlar içinde aynı IP adresinin kullanılması.

• IPv6 kısaltma kuralları (RFC-5952)
• Solda kalan 0'lar atılır
• 4 hexa basamağı da 0 olan blokları komple atalım ve yerine ":" koyalım. DİKKAT: Bu kısaltma 1 kez yapılmalı, yoksa o ":" ile kısaltılan aralıklarda kaçar 0 atıldığını bilemeyiz.
• Örnek
• 2001:0db8:0000:0000:0000:0000:0000:0c50
• 2001:db8::c50
• CIDR gösterimi kullanılmaktadır.
• Ağ adresini belirleyen bit sayısı / işareti kullanılarak adres sonuna yazılır
• 2001:db8::2aa:ff:fe28:9ce5 /32
• Ağ adresi: 2001:db8::
• Subnetleme
• 4'ün katı olsun maskelerimiz. Yoksa işleri karıştırabiliriz
• En uzun 64 bit maske
• Kalan 64 bit, arayüz tanıtıcı olacak. Cihaz, 48 bitlik MAC adresine 16 bit daha ekleyerek tanıtıcı yapacak kendisine.
• ISP, 56 bitlik aralık verdiyse, 64 - 56 = 8 bitlik subnet adresleme aralığın olacak; 2 üzeri 8 subnet tanımlayabilme demek bu da.
• Daha çok subnet istiyorsak, ISP'den 52 bitlik ya da daha düşük bitlik aralık alacağız paraya kıyıp.