Bu sayfa son olarak 2020-06 tarihinde güncellendi.

Bu süreç değişebilir. Geçerli süreç için lütfen bu sayfaya bakın.

Bu sayfa Haziran 2020 tarihinde güncellenmiştir.

Araştırmacılar: Araştırma ya da hack çalışmalarınızda şunlardan kaçınmanızı rica ediyoruz: - I2P ağında Etkin açıkları kullanmak veya Hizmet Reddi saldırıları gerçekleştirmek - I2P geliştirme ekibinin üyeleri üzerinde sosyal mühendislik yapmak - I2P mülklerine ve/veya veri merkezlerine karşı herhangi bir fiziksel veya elektronik girişimde bulunmak

I2P bir açık kaynak topluluğu olduğundan, birçok gönüllü ve geliştirme ekibi üyeleri kendilerine ait herkese açık ("özel olmayan İnternet") etki alanlarının yanında I2P Siteleri de işletmektedir. Bu siteler ya da sunucular, güvenlik açığı değerlendirme ve yanıtlama süreci kapsamında DEĞİLDİR, yalnız temel I2P kodu bu kapsamdadır.

I. Güvenlik Konuları için İletişim Noktası

security (at) geti2p.net - GPG Key fingerprint = EA27 06D6 14F5 28DB 764B F47E CFCD C461 75E6 694A

II. Güvenlik Müdahale Ekibi

Echelon, güvenilir bir güvenlik iletişim noktasıdır. E-postaları uygun şekilde ekip üyelerine yönlendirir.

III. Olay Müdahalesi

  1. Araştırmacı bildirimini şuradan gönderir: security (at) geti2p.net
  2. Müdahale Ekibi, uygunluğa ve/veya bilgi kümesine göre bildirimden sorumlu bir Müdahale Sorumlusu belirler.
  3. Müdahale Ekibi en fazla 3 iş günü içinde, araştırmacıya yalnız şifrelenmiş yöntemler üzerinden yanıt verir.
  4. Müdahale Sorumlusu, gerekli bilgileri sağlamak ve bildirimin gerçekten bir güvenlik açığı olup olmadığını doğrulamak için sorgulamalar yapar.
    1. Bildirimin bir güvenlik açığı olduğu ortaya çıkarsa, ilerlenir.
    2. Bir güvenlik açığı değilse:
      1. Müdahale Sorumlusu, bildirimin neden bir güvenlik açığı olmadığını açıklayan bir yanıt verir.
      2. Müdahale Sorumlusu, gerekirse konuyu herkese açık Trac üzerindeki yeni ya da var olan bir destek kaydına taşır.
  5. Güvenlik açığının önem derecesini belirleyin:
    HIGH
    Ağı bir bütün olarak etkiler, tüm ağı kırma potansiyeline sahiptir yada büyük bir felaket ölçeğindedir.
    MEDIUM
    Bazı yönelticileri etkiler veya dikkatlice yararlanılmalıdır.
    LOW
    Kolayca yararlanılmaz.
  6. Güvenlik açığının önem derecesine göre yanıtlayın:
    1. YÜKSEK önem dereceleri sınıflandırıldıktan en fazla 3 iş günü sonra web sitesinde ve haber akışında bildirilmelidir.
      1. Bildirimde, varsa kullanıcıların uygulaması gereken adımlar listelenmelidir.
      2. Bildirimde güvenlik açığından yararlanılmasını sağlayabilecek bir ayrıntı bulunmamalıdır.
      3. İkinci konu, birinciye göre önceliklidir.
    2. ORTA ve YÜKSEK önem dereceleri için Anlık Sürüm yayınlanır.
    3. DÜŞÜK önem dereceleri bir sonraki Normal Sürümde ele alınır.
  7. Müdahale Ekibi gerekli yamaları uygular.
    1. Müdahale Sorumlusu, YEREL OLARAK bir yama üzerinde çalışır. Yamalar, müdahale ekibi tarafından, herkese açık olarak duyurulması güvenli olana kadar PGP ile şifrelenmiş e-posta yoluyla paylaşılır.
    2. Yamalar araştırmacı ile birlikte gözden geçirilir.
    3. Gözden geçirme sırasında HERKESE AÇIK yazılım güncellemelerindeki iletilerde, KİŞİSEL dal ya da yazılım güncellemelerindeki güvenlik kapsamına atıfta bulunulmamalıdır.
    4. Güvenlik açığı duyurusunun taslağı hazırlanır.
      1. Güvenlik açığının önem derecesini belirtin.
      2. Etkilenen sistemleri ve uygulamaları ekleyin.
      3. Yama uygulanamıyorsa (varsa) çözümleri ekleyin.
    5. Yayınlanma tarihi tartışılır.
  8. Yayınlanma tarihinde, Müdahale Ekibi güncellenmeyi tamamlamak üzere geliştiriciler ile iş birliği yapar:
    1. Müdahale Sorumlusu, yazılımın "düzeltme dalını" ana koda ekler.
    2. Müdahale Sorumlusu, güvenlik açığı duyuru taslağını sürüm notlarına ekler.
    3. Anlık ya da Normal Sürüm yayını ile ilerlenir. Şu anda, yalnız bir işletim sistemi veya mimari için bir ağ içi güncelleme yayınlanamaz Etkilenen tüm ürünlerin olabildiğince hızlı yayınlanabilmesi için, bu yazılımdan sorumlu kişinin gerekli işlemleri en kısa zamanda yapması gerekir. Daha da önemlisi, Debian, Ubuntu ve F-Droid üzerindeki paket yöneticileri de düşünülmelidir.

IV. Yayın Sonrası Açığa Çıkarma Süreci

  1. Müdahale Ekibi, III. bölümdeki tüm işlemleri 90 gün içinde yapmalıdır.
  2. III. bölümdeki Olay Müdahalesi süreci başarıyla tamamlanırsa:
    1. Müdahale Sorumlusu araştırmacı ile görüşerek, araştırmacının katkıda bulunduğunun duyurulmasını isteyip istemediğini sorar.
    2. Güvenlik açığı duyuru taslağı tamamlanır ve aşağıdakiler eklenir:
      1. Proje adı ve adresi.
      2. Etkilendiği bilinen sürümler.
      3. Etkilenmediği bilinen sürümler (Örnek: Güvenlik açığından etkilenen kod yeni bir sürümde eklendiğinden bundan önceki sürümler etkilenmemiş olabilir).
      4. Denetlenmeyen sürümler.
      5. Güvenlik açığının türü ve etkisi.
      6. Zaten alınmışsa veya varsa, bir CVE kodu.
      7. Planlanmış ve organize edilmiş yayın tarihi.
      8. Azaltıcı etkenler (Örnek: Güvenlik açığı yalnız yaygın kullanılmayan durumlarda, varsayılan yapılandırmadan farklı ayarlarda ortaya çıkıyorsa).
      9. Geçici çözümler (kullanıcıların bu güvenlik açığından etkilenmesini azaltmak için yapabilecekleri yapılandırma değişiklikleri).
      10. İstiyorsa, bildirimi yapan araştırmacının emeklerini anma.
    3. Tamamlanmış güvenlik açığı duyurusu web sitesinde ve haber akışında yayınlanır.
      1. If the vulnerability may be exploited while the network is being upgraded, delay the announcement until the vulnerable routers are upgraded.
      2. After the update is successful, write the announcement for the news feed, send it for translation, and release it.
      3. When translations come in, news operators should pull in the translations and update their feeds.
    4. YÜKSEK önem dereceleri için, iyi bilinen e-posta listelerinde tamamlanmış güvenlik açığı duyurusu yayınlanır:
      1. oss-security@lists.openwall.com
      2. bugtraq@securityfocus.com
    5. Uygulanabiliyorsa, geliştiriciler bir CVE kodu başvurusunda bulunur.
      1. Düzeltmenin yapıldığı kayıt, gelecekteki işlemler için referans yapılır ve bir CVE kodu eklenir.
  3. III. bölümdeki Olay Müdahale süreci başarıyla *tamamlanmadıysa*:
    1. Müdahale Ekibi ve geliştiriciler, III. bölümdeki konuların hangilerinin neden çözümlenemediğini ve bunların gelecekte nasıl çözümleneceğini tartışmak için bir IRC toplantısı düzenler.
    2. Olayı izleyen bir geliştirici toplantısında V. bölümde ele alınan noktalar görüşülmelidir.
    3. Bir güvenlik açığı hakkında bilgi verilip verilmeyeceği veya ne zaman duyurulacağı konusunda anlaşmazlık ortaya çıkarsa, Müdahale Ekibi IRC aracılığıyla konuyu herkese açık olarak tartışır ve bir fikir birliğine varmaya çalışır.
    4. Duyuru zamanlaması ile ilgili fikir birliği sağlanamazsa (en geç 90gün içinde), araştırmacı (90gün sonra) güvenlik açığını herkese açık olarak duyurma hakkına sahiptir.

V. Olay İncelemesi

  1. Kod temelini yalıtma
    1. Müdahale Ekibi ve geliştiriciler şu konular üzerinde çalışmak için organize olmalıdır:
      1. Sınıfların/kitaplıkların/işlevlerin vb. soruna göre uyarlanması
      2. Uygulamalara/dağıtım paketlerine vb. odaklanılması.
      3. Kullanıcı/yapılandırma hatası vb.
  2. Denetim
    1. Müdahale Ekibi ve geliştiriciler şu konular üzerinde çalışmak için organize olmalıdır:
      1. 1. maddede anıldığı gibi sorunlu alan(lar)ın denetlenmesi.
      2. İç raporların oluşturulması ve ileride başvurulmak üzere arşivlenmesi.
      3. Sonuçlar kritik değilse, IRC ya da herkese açık Trac üzerinde herkese açık olarak paylaşılması.
  3. Müdahale Ekibi, III. bölümü tamamladıktan sonra 45 gün içinde V. bölümü tamamlamalıdır.

VI. Sonuçlar

Herkese açık duyuru yapıldıktan sonra, olay(lar) ile ilgili ilgili herhangi bir başka soru veya çözüm, araştırmacı ile müdahale + geliştirme ekibi arasında şu başlıklarla ele alınabilir:

  1. Trac
  2. IRC
  3. Email
  4. Twitter

VII. Sürekli iyileştirme

  1. Müdahale Ekibi ve geliştiriciler, önceki yılın olaylarını gözden geçirmek için yıllık toplantılar düzenlemelidir.
  2. Müdahale Ekibi veya belirlenen kişi(ler) şu konularda kısa bir sunum yapmalıdır:
    1. Olaylardan etkilenen I2P alanları.
    2. Olaylardan kaynaklanan herhangi bir ağ kesintisi ya da (varsa) parasal maliyet.
    3. Olaylardan kaçınma yolları (varsa).
    4. Bu sürecin olaylarla başa çıkmada ne kadar etkili olduğu.
  3. Sunumdan sonra, Müdahale Ekibi ve geliştiriciler şu konuları tartışmalıdır:
    1. Gelecekteki olayları azaltmak için geliştirme süreçlerinde yapılabilecek değişiklikler.
    2. Gelecekteki müdahaleleri iyileştirmek için bu süreçte yapılabilecek değişiklikler.