IOS router'larda PKI konfigürasyonu

Merhaba

Bu zamana kadarki yazılarımda ISAKMP’de kimlik denetimini hep önceden paylaştırılmış gizli anahtar ile (Pre-shared Secret Key ve Pre-Shared Key, kısaca PSK) yaptık. ISAKMP kimlik denetimi için PSK sıklıkla kullanılır çünkü çok basit bir yöntemdir. PSK’nın yeterince ölçeklenebilir olmadığı durumlarda ise kimlik denetimi sertifikalarla yapılabilir. Asimetrik şifreleme ve hash algoritmalarıyla çalışan bu mekanizmaya PKI (Public Key Infrastructure) adı verilir.

Aşağıdaki durumları düşünelim:

  • Router’larda VPN’in sonlanabileceği sabit IP’li bir interface olmaması ve/veya
  • VPN sonlandıran çok fazla sayıda router olması

Bu gibi durumlarda kimlik denetiminde PSK kullanacak olursak muhtemelen ya yönetilebilirlikten ya da güvenlikten ödün vermek zorunda kalırız. Bunun da sebebi şu: Bildiğimiz gibi ISAKMP PSK’lar bir IP adresi veya IP bloğu için tanımlanır. Yukarıdaki durumlardan biri söz konusu olduğunda PSK’yı tanımlayabileceğimiz IP adres veya bloklarını tek tek her router’a girmemiz ölçeklenebilir olmaz. Eğer tüm IP’ler veya en iyi ihtimalle büyük bir IP bloğu için PSK tanımlarsak da güvenlikten ödün vermiş oluruz (bu konudaki bilgi paylaşımı için Gökhan’a teşekkürler :)). Sonuç olarak böyle bir durumda en iyi çözüm kimlik denetimi için sertifika kullanmak olacaktır.

Bu yazımda IOS router’larda bu yapı için basit bir konfigürasyon örneği vereceğim. Sertifika kullanarak kimlik denetiminin nasıl gerçekleştiğini anlamak için Seda’nın yazısına bakabilirsiniz. Ayrıca o yazıyı okumadan önce de hash ve simetrik/asimetrik şifreleme konusunda bilgi sahibi olmanızı öneririm.

IOS router’lar CA (Certificate Authority) olarak konfigüre edilebilir. VPN’e dahil olacak router’lar da sertifikalarını bu CA’ya onaylatıp birbirlerini kimlik denetiminden geçirebilir. İlgili konfigürasyonlara geçmeden önce sağlamamız gereken şartlara bir bakalım:

  • Bir PKI’nin düzgün çalışabilmesi için bu altyapıdaki cihazların saat ve tarih senkronizasyonu çok önemlidir. Bu amaçla NTP kullanılabilir. (Router’lar NTP Server olarak da konfigüre edilebilir). Kullanılmazsa da router’larda clock set girilmiş olmalıdır.
  • Tüm router’larda RSA anahtarları oluşturacağımızdan hostname ve ip domain name girilmiş olmalıdır.
  • Sertifika onaylatma ve CRL kontrolü işlemlerinde kullanılan SCEP (Simple Certificate Enrollment Protocol)’in çalışabilmesi için CA’da ip http server girilmiş olmalıdır.

CA KONFİGÜRASYONU

CA(config)# crypto key generate rsa general-keys label OGUL-CA modulus 1024 exportable
CA(config)# crypto key export rsa OGUL-CA pem url nvram: 3des cisco123

cisco123 şifresi anahtarlar yeni bir IOS CA’ya import edilirken lazım olacaktır. Şimdi nvram’e baktığımızda public – private anahtar çiftini görebiliriz:

 

CA(config)# crypto pki server OGUL-CA
CA(cs-server)# database level {minimal | names | complete}
CA(cs-server)# database url nvram
CA(cs-server)# issuer-name CN=OGUL-CA, O=Agciyiz, ST=IST, C=TR
!! sadece CN=<Common Name> gerekli, diğer attribute’lar isteğe bağlıdır.
CA(cs-server)# lifetime crl 24 !! 24 saat önerilen değerdir
CA(cs-server)# lifetime certificate 750 !! 750 gün önerilen değerdir
CA(cs-server)# lifetime ca-certificate 1825 !! 1825 gün, 3-5 yıl önerilen değerdir
CA(cs-server)# no shutdown
CA(cs-server)# do write memory !! sertifikayı kaydeder.

Şimdi nvram’e baktığımızda CA sertifikasını görebiliriz:

CA’YA SERTİFİKAYI ONAYLATMA (SCEP KULLANARAK)

R1(config)# crypto key generate rsa general-keys modulus 1024
R1(config)# crypto ca trustpoint OGUL-CA
R1(ca-trustpoint)# enrollment url http://10.0.1.3:80
R1(ca-trustpoint)# revocation-check crl
R1(ca-trustpoint)# auto-enroll 70
!! Sertifika süresinin %70’i dolduğunda tekrar sertifika onaylatma isteği yapılır.
R1(ca-trustpoint)# source interface FastEthernet0/0
!! Gerekliyse SCEP istekleri için source interface belirtilebilir.

Sertifika onaylatma için öncelikle CA sertifikasını almalıyız:
R1(config)# crypto ca authenticate OGUL-CA

Sonrasında sertifika onaylatma isteği gönderiyoruz:
R1(config)# crypto ca enroll OGUL-CA

CA’da gelen sertifika isteklerini görmek için:
CA# crypto pki server OGUL-CA info requests

 

Bekleyen sertifika isteklerini onaylamak için:
CA# crypto pki server OGUL-CA grant <istek num.>

R1’de sertifikaları kaydetmek için:
R1(config)# do write memory

Şimdi nvram’e baktığımızda CA sertifikasının yanı sıra R1’in imzalanmış sertifikasını da görebiliriz:

SERTİFİKA İPTALİ VE CRL

CA önceden onayladığı bir sertifikayı iptal (revoke) edebilir. Ayrıca iptal ettiği sertifikaların bir listesini tutar. Bu listeye CRL (Certificate Revocation List) denir. PKI server etkinleştirildiği andan itibaren bu listeyi flash’ta görebiliriz:

VPN router’ları şu üç durumda CRL listesini alırlar:

  • R1(config)# crypto ca crl request OGUL-CA komutuyla
  • CA tarafından belirlenen CRL lifetime dolduğunda
  • Reboot edildiğinde

revocation-check crl komutu olduğu sürece VPN router’ları ISAKMP negotiation sırasında karşı tarafın sertifikasının CA’dan aldıkları CRL’de olup olmadığını kontrol eder. Sertifika CRL’de ise kimlik denetimi başarısız olur.

Sertifika iptali için öncelikle sertifikasını iptal edeceğimiz VPN router’ına bağlanıp sertifika seri numarasını öğrenmeliyiz. Bunu aşağıdaki komutla yapabiliriz:

 

 

 

 

 

 

Sertifika seri numarasını öğrendikten sonra CA’da bunu more flash:2.cnm komutuyla kontrol edebiliriz:

CA# more flash:2.cnm
subjectname_str = hostname=R1.ogul.com
expiration = 10:19:45 UTC Apr 22 2015

Bu sertifikayı iptal etmek için ise aşağıdaki komutu giriyoruz:
CA# crypto pki server OGUL-CA revoke 0x02

Dikkat edilmesi gereken nokta bu komutta sertifika seri numarası 16’lı tabanda girilmelidir.

Son olarak, almış olduğumuz sertifikaları ISAKMP kimlik denetiminde kullanmak için isakmp policy altında authentication rsa-sig komutunu girmeliyiz.

Kaynak ve ayrıntılı bilgi: Digital Certificates/PKI for IPSec VPNs (Cisco)

Bir Cevap Yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir