[LinuxFocus-icon]
Ev  |  Erişimdüzeni  |  İçindekiler  |  Arama

Duyumlar | Belgelikler | Bağlantılar | LF Nedir
Bu makalenin farklı dillerde bulunduğu adresler: English  Castellano  Deutsch  Francais  Nederlands  Turkce  

convert to palmConvert to GutenPalm
or to PalmDoc

Bernard Perrot
tarafından Bernard Perrot
<bernard.perrot%28at%29univ-rennes1.fr>

Yazar hakkında:
Bernard, 1972'den beri CNRS ( Fransız Ulusal Araştrma Merkezi )'nde Sistem ve Ağ Mühendisi olarak çalışmaktadır."Institut National de Physique Nucléaire et de Physique des Particules" (In2p3)'de bilgisayar sistemleri güvenliği ile görevlidir.Şu an, Fizik ve Matematik Bölümü'nün Matematik Araştırma Enstitüsü'nde çalışıyor.

Türkçe'ye çeviri:
Özcan Güngör <ozcangungor%28at%29netscape.net>

İçerik:

 

Secure your connections with SSH

ssh

Özet:

Bu makale ilk defa Linux Magazine France'ın güvenlik üzerine olan bölümünde yayınlanmıştır.Editör, yazarlar ve tercümanlar, bu konu hakkındaki her makalenin LinuxFocus'ta yayınlanmasına izin vermişlerdir.LinuxFocus, bunları İngilizce'ye çevirir çevirmez size sunar.Bu işle ilgili bütün kişilere teşekkür ederim.Bu tanıtım, bu kökene ait bütün makalelerde yer alacaktır.
Bu makalede size SSH'i ve onun nasıl kullanıldığını anlatacağız.Bu bir kullanma klavuzu ya da yükleme prosedürü değildir.Daha çok özel sözcüklerin anlamını ve SSH'in özelliklerini anlatır.Verilen linkler ve dökümanlar, SSH'in kullanımı hakkındaki bütün bilgileri içerir.

_________________ _________________ _________________

 

SSH Ne İçin Kullanılır ?

Öncelikle ( ve kronolojik olarak), SSH (ssh komutu), rsh ( ve rlogin ) komutlarının güvenli biçimidir.rsh'ın "Remote SHell ( uzak kabuk )" anlamına geldiği gibi ssh de "Secure SHell ( güvenli kabuk )" anlamına gelir.rsh size kullanıcı yetkilendirmesi istemeden uzak kabuğa izin verir.ssh de aynı servisi sağlar ancak yüksek ve çoklu seviyeli güvenlik içerir.
Eğer bu konu hakkında fazla bilginiz yoksa, yapcağınız tek şey telnet,rsh ve rlogin gibi komutların yerine ssh kullanmaktır.Herşey aynı şekilda çalışacaktır ancak daha güvenli bir şekilde.
Yani,

% rlogin serveur.org (or telnet serveur.org)

yerine

% ssh serveur.org

kullanacaksınız.
SSH'in basit kullanımından kaynaklanan güvenlik kazaları daha çok kurbanların ihmallerinin sonucudur.

 

Gerekenler Nelerdir ?

Aşağıda bağlantıların bazı çok önemli durumları hakkında öneriler vardır: Bunlara karşlık yeterli olmayan bazı çözümler: Ve işte SSH, güzel bir çözüm:  

SSH Sürüm 1 ve SSH Sürüm 2

Bu dünyada hiçbir şeyin mükemmler olmadığı gibi iki uyumsuz SSH protokolü sürümü vardır: 1.x sürümü (1.3 ve 1.5) ve 2.0 sürümü.Kullanıcı için bir versiyonda diğerin geçmek zor değildir.Hem sunucuda hem istemcide aynı versiyonun olması yeterli.
SSH sürüm 1 birleşiktir ancak SSH sürüm 2 üç katmandan oluşur:
  1. SSH Ulaşım Katmanı Protokolü (SSH-TRANS)
  2. SSH Yetki Protokolü (SSH-AUTH)
  3. SSH (Bağlantı Protokolü (SSH_CONN)
Her protokol katmanı, IETF ile normalleştirilmiş dökümanlarda tanımlanmıştır.Yapıyı açıklayan dört döküman vardır.Bunları http://www.ietf.org/html.charters/secsh-charter.html
Detaylara girmeden SSHv2'de neler var bir bakalım: SSH sürüm 1 ve 2 arasındakü teknik farklar şunlardır:
 

SSH sürüm 1 SSH sürüm 2
Monolitik ( bütünleşik ) dizayn Yetkilendirmeyi, ulaşımı ve bağlantıyı katmanlara ayırma
CRC32 aracılığı ile bütünleşme (güvenli değil) HMAC (hash şifrelemesi) ile şifreleme
Her oturum için yalnız bir oturum Her oturum için sınırsız oturum sayısı
Sadece simetrik gizli sistem ile anlaşma, her iki tarafta yalnız bir anahtar ile tanımlama Daha ayrıntılı anlaşma ( simerik gizli sistem, açık nahtar, sıkıştırma, ...) ve ayrı oturum anahtarları, her iki tarafta sıkıştırma ve bütünleşme
Açık anahtar için sadece RSA algoritması Açık anahtar için RSA ve DSA algoritmaları
İstemci tarafından gönderilen oturum anahtarı Oturum anahtarı için Diffle-Hellman protokolü aracılığıyla anlaşma
Oturum anahtarı bütün oturum boyunca geçerli Yenilenebilir oturum anahtarı
 

Bir Sürü Anahtar ile Uğraşma

SSH anahtar türlerini hızlıca açıklayalım: Kullanıcı, yukarıdaki anahtarların gizli anahtar kısmını koruyan bir geçişdeyimi(passphrase) atar.Bu koruma gizli anahtarı içeren dosyanı simetrik algoritmayla şifrelenmesiyle garantilenir.Bu dosyayı şifreleyen gizli anahtar, geçişdeyiminden türetilir.
   

Yetkilendirme Yöntemleri

Birçok kullanıcı yetkilendirme yöntemi vardır.Seçim, güvenlik politikalarında tanımlanan gereksinilere göre yapılır.Burada temel kategoriler bulunmaktadır: Yetkilendirmeyi ilgilendiren bir kaç elemana göz atalım:  

Şifreleme Algoritmaları

Şimdi, iletişim kanalını şifreleme (saklı anahtar kullanarak) ve kullanıcı yetkilendirme (açık anahtar ile şifreleme) arasındaki farkı anlatalım.
Yetkilendirme için, sürüm 2 için RSA'yı veya DSA'yı seçebiliriz ve sürüm 1 için sadece RSA'yı seçebiliriz.Tarihsel olarak,bazı ülkelerde RSA patentli olduğundan DSA kullanılacaktı.2000 yılının yazı sonunda RSA'nın kullanımı serbestleştive kısıt ortadan kalkmış oldu.Hangisinin iyi hangisinin kötü olduğun hakkında bir fikrim yok (yalnızca DSA, "saf" NSA ürünüdür).
Simetrik şifreleme için, birçok seçenek vardır.Protokol, tek bir ortak algoritma kullanmaya zorlar:Üç anahtarlı üçlü-DES.Eğer sunucu ve iştemci ağlantı kuramazlarsa bu yöntemi kullanırlar.3DES, en az peformanslı algoritma olduğundan, önce daha iyi bir algoritma kullanmayı denerler.Bazı gereksiz ve eski (arc4,DES,RC4...) algoritmaları bir kenar koyup şunlarla kendmizi sınırlayacağız: Protokolün "özel bir algoritma" kullanmaya izinvermise karşılık neden bu kadar çok algoritma olduğunu anlamamışımdır.Sence, zamanlan, AES standart olacaktır.
   

Port Yönlendirme, Tüneller

SSH, SSH oturumunda her TCP veri akışının yönlendirmesini "tünel" aracılığıyla yapabilir.Veri akışını, istemci ve sunucu portlarını yönetmek yerine, bağlantı sırasında oluşturuluan tünel ile yapar (takip eden diyagrama bakınız).
X11 protokolü için fazladan güç harcamadan yapılır.
Diğre akışlar için, her ikli tarafta komut satırı seçenekleri vardır: SSH'in bu özelliği bazen "zavallılar için tünel" diye adlandırılır.Buradaki zavallılığın anlamı, istemci tarafında yönetim yapamaktır.Sacede belirli durumlarda yerel portlar (port > 1024) çok az haklarla yönlendirilebilir.Diğer yönden, bazı haklar verilmiş prot yönlendirme yapmak için root hesabına ya da root haklarına sahip bir kullanıcı olmak gerekir.
IP ile olduğu gibi, herşeyi herşeyin içine koymak mümkündür.Sadece TCP akışını değil, PPP bağlantısını da yönlendirebilirsiniz.Bu IP içinde "gerçek" IP tüneli yapmamıza izin verir (şifrelenmiş olduğundan güvenlidir).Konu, bu makalenin sınırların aşar, ayrıntılı bilgi için Linux VPN-HOWTO yazısını okyabilirsiniz.
İlk akılda tutulacak şey telnet akışını yönlendirmek:Bu gereksiz görünebilir, SSH zaten telneh yerine bir bağlantı sunuyor.Bu yöntemle istenilen istemciye ulaşlabilir çünkü SSH, Windowstm ve MacOS tm gibi ortamlarda çalışmıyor olabilir.Örneğin,"Mindterm"'ün "terminal emülasyonu" (Java'nın SSH istemcisi, bütün modern sistemlerde çalışır) Java'nın performans dşüklüğünden yakınır:Bu istemciyi sadece SSH tüneli oluşturmak için kullanabilirsiniz.
Aynı şekilde, "xterm" gibi ( örneğin SSH'in otomatik X11 yönlendirmesi kullanarak) uzak bir istemci başlatarak, SSH'i X terminallerde kullanabilirsiniz.
Tünel, veri akışı -veriyi tüneli başlatan kişi göndermiyor olsa bile- olduğu sürece açık kalır.Bu yüzden "sleep" komutu yeni TCP bağlantısını yönlendiren SSH tüneli açarken yararlı olur.
 

% ssh -n -f -L 2323:serveur.org:23 serveur.org sleep 60

% telnet localhost 2323

... welcome to serveur.org ...
İlk komut bir tünel açar, sunucuda sleep 60 komutunu çalıştırır ve yerel 2323. portu uzaktaki 23. porta (telnet) yönlendirir.İkinci komut, yerel 2323. portta telne istemcisi çalıştırır ve sunucuya bağlanırken
şifrelenmiş tüneli kullanır.Sleep komutu birdakika sonra duracaktır.Telnet komutunu çalıştırabilmek için sadece bir dakikanız var.Ama tünel son istemci işini bitirene kadar açık kalacaktır.
 

 

Ana Dağıtımlar: ücretsiz olanlar

Farklı platformda farklı sunucu ve/veya istemci kullanacaksınız ve SSHv1 ile SSHv2 uyumsuzdur.Makalenin sonundaki referansalar diğer uygulamaları bulmanızda yardımcı olacaktır.Buradaki tabloda sadece ücretsiz ve yeterince stabil olanlar vardır.
 

ürün platform protokol link notlar
OpenSSH Unix sürüm 1 ve 2 www.openssh.com ayrıntılar aşağıdadır
TTSSH Windowstm sürüm 1 www.zip.com.au/~roca/ttssh.html
Putty Windowstm sürüm 1 ve 2 www.chiark.greenend.org.uk/~sgtatham/putty sadece beta sürümü
Tealnet Windowstm sürüm 1 ve 2 telneat.lipetsk.ru
SSH secure shell Windowstm sürüm 1 ve 2 www.ssh.com ticari amaçlar dışında ücretsiz
NiftytelnetSSH MacOStm sürüm 1 www.lysator.liu.se/~jonasw/freeware/niftyssh/
MacSSH MacOStm sürüm 2 www.macssh.com
MindTerm Java sürüm 1 www.mindbright.se sürüm 2 ticaridir
MindTerm'ün Java'nın platformdan bağımsız uygulamasıdır (sadece Jav runtime'a gereksinim vardır) ve iyi tasarlanmış WEB tarayıcında çalıştırlıbilen bir servlet'dir.Maalesef, bu mükemmel ürünün son sürümü ticaridir.
   

OpenSSH

Büyük ihtimalle unix/linux ortamlarında kullanılan tek dağıtımdır ( sürekli destek, kısa cevap süresi, açık-kod ve ücretsiz).

OpenSSH'in gelişimi, OpenBSD projesinde Tatu Ylonen'nin orjinal sürüm ile başladı (SSH 1.2.12).Şu an OpenSSH üserşnde iki grup çalışmakta.Biri sadace OpenBSD projesi için, diğeri ise diğer dağıtımları çıkarmak için çalışıyor.

Açık ve okunabilir kodları olmasına rağmen, beni rahatsız eden iki nokta var:

Bence ( ki yalnız değilim), çokluplotrofm şifreleme ürünleri, platform ne olursa olsun kararlı ve sabit olmalıdır.Hatta paltformun belirli karakteristiklerini de göz önüne almalıdır.
Diğer rakiplerin ürünlerinin çok ve çekici olamamalarını normal karşılamalıyız.Eğer diğer ürünleri ele almazsak, OpenSSH en kötü ürün.Kodun tekrar tasarlanıf yazılması toplum için daha faydalı olacaktır.
   

Kötü Haber ...

SSH mucize yaratmaz.O ne için yapıldı ise onu en iyi şekilde yapar.Daha fazlası beklenmemelidir.Yetkilendirilmiş bağlantıları korumaz.Eğer hesap paylaşılmışsa, bir saldırgan aynı hesaptan bilgisayarınıza bağlanabilir.SSH, diğre pratik ve kolay güvenlik politikalarıyla birlikte mükemmeldir.Eğer biri SSH'i heryerde kullanmıyorsa, potansiyel bir risk oluşturur.Bir saldırgan bu şifreyi kullanup SSH ile bağlantı kurarsa hiçbir şekilde iz bırakmayacatır.
Saldırganlara kapılar açacak olan SSH deamonlarının sebep olacağı tehlikelerin kişileri endişelenmemesi gerekir:IP'de herşeyi herşeyin içine koymak mümkün.Firewall aracılığıyla önemli protokollerin uygunsuzluğunu da içerir: HTML tünelleri, ICMP tünelleri, DNS tünelleri...Eğer %100 güvenlik istiyorsanız, bilgisayarınızı açmayın.SSH, kullanımından kaynaklanan bazı "delik"leri vardır (mükemmle program olmadığından bazıları geçmişte düzeltilmiştir).Bazıları da protokolden kaynaklanmaktadır.Bu "delik"ler -bazılarının çok önemli oldukları bildirilmişse de- düzeltilmesi teknik olarak karmaşık olan zayıflıklardır.SSH kullanılarak kaçınılan güvenlik kazaları günlüktür ve SSH'in zayıflılığından kaynaklananlar bazen teoriktir.Şu yazıyı okumak inginç olacaktır: http://www.hsc.fr/ressources/presentations/mitm/index.html . Bununla birlikte yüksek güvenlik isteyen uygulamalar (bankacılık, askeriye..) bazı potansiyel açıkları göz önüne almalıdırlar.  

Sonuç

Girişte yazdığımı tekrarlyacağım:SSH, ne mucizeler yaratır ne de tek başına bütün güvenliği sağlar.Ama temel bağlanma yolarından (telnet, rsh...) daah iyidir.
   

Önemli Linkler

İlk iki kita SSHv1 ve v2'yi kapsar. Eğer harcayacak paranız varsa, iyi bir başlangıç...  

Korunan Kanalı Kötüye Kullanmak (SSHv1'deki rastgle padding kullanılarak yapılmış)

Burada, SSHv1'de (ve v2'de) rastgele padding kullanılarak yapılmış bir korunan kanalı nasıl kaldıracağımızı açıklayağız.Pranoyakları etkileyecek kalp krizlerinde sorumlu değilim.
SSHv1'in paketleri şu yapıdadır:
 
 
offset

(byte)

isim uzunluk
(bytes)
tanımlama
0 boyut 4 paket boyutu,padding'siz alan boyutu,yani
boyut=uzunluk(tip)+uzunluk(veri)+uzunluk(CRC)
4 padding p =1 to 8 rastgele padding: boyut sekizin katı olacak şekilde ayarlanır
4+p tip 1 paket tipi
5+p veri n (değişken >= 0)
5+p+n doğrulama 4 CRC32

Sadece bir alan şifrelenmez: boyut.Şifrelen kısmın uzunluğu, paddingler kullanılarak daima sekizin katı yapılır.Paddingler daima kullanılır.Eğer son üç alanın boyutu sekizin katı ise 8 byte uzunluğunda padding kullanılır ( 5+p+n, modül 8'e göre kalan 0'dır).Şifreleme fonksiyonu C, simetrik ve CBC modunda olsun ve deşifreleme fonksiyonu C-1 olsun.Kolay olsun diye sadece 8 byte paddingli paketleri alacağız.Bir paket geldiğinde, onu rastegele sayı ile padding yapmak yerine, C-1(M) değerini yerleştireceğiz.M mesajını C fonksiyonuyla deşifre etmek ile kanalı şifrelemek aynı anlamdadır (aslında Mnin şifrelenmeden deşifre edilmesi matematiksel açıdan bi anlan içermez, ama pratik kullanımda bu konun detaylarına inmeyeceğim).Sonra paketin diğre işlemlerine devam ederiz, yani 8 bytelık şifreleme.

Sonuç şu olacaktır:


offset içerik
notlar
0 boyut
4 byte şifrelenmedi
4 8 byte padding (şifrelenmiş) yani C(C-1 (M))
12... son tip,veri,CRC

 
Burada ilginç olan ne?İlk şifrelenmiş blok C(C-1(M))'i içerir. C simetrik şifreleme fonksiyonu olduğundan C(C-1(M)) =M
dir.İlk blok, şifrelenmiş veride deşifrelenmiş olarak gönderilir.Bunun anlamı, ağ üzerinde iletişimi dinleyebilen biri bilgileri nasıl kullanacağını bilir.
Üçlü-DES(168 bit) oturumunda, bu tip paketlerin sayısı üçtür.Bu bilgilerle bir ağ dinleyicisi bütün iletişimi deşifre edebilir.Anahtar gönderildiğinde, paddingleri pakete sokmadan önce "ön-şifreleme"ye artık gerek kalmz.Eğer biri daha çok bilgi eklemek isterse, herhangi boyutta padding kullanması mümkündür.
Bu korunmuş kanalın kullanımının bulunması asla mümkün değildir! Daha önce de belirtiğim gibi iletinin her elemanı şifrelerken dikkatlı olunmalıdır.Bulunamaz çünkü paddingler rastgeledir, doğruluk testini kullanamazsınız. Şifreleme ürünlerinde asla rastgele paddingler kullanmayınız.
Bu kanalı diğerlerinde daha tehlikeli yapan şey, SSH_MSG_IGNORE gibi şifrelenmiş anahtar bilgisin sahip olmadan kullanabileceğiniz iletilerdir.
Rastgele paddinglerin kötü etkilerinden korunmak için, kararlı paddingler kullanılmalıdır: genellikle " kendini tanımlayan paddingler" denir ve n. offset byte'ı n'i içerir.Rasgele paddingler, SSHv2'de vardır.Bir şeçimdir.
Sonuç olarak,burada sadece korunmuş kanalı eleştirdim.Çünkü SSH gibi çok güvenli olduğunu iddia eden bir ürünün gerçekten en üst düzeyde güvenlik sunması gerekir. Artık ticari ürünlerin bir çok açık içerdiklerini biliyorsunuz:Sadece açık-kod ürünleri birincil gereksinime izin verir.O da kodun incelenmesi ve bu incelem gerçekten gereklidir.

 

Bu yazı için görüş bildiriminde bulunabilirsiniz

Her yazı kendi görüş bildirim sayfasına sahiptir. Bu sayfaya yorumlarınızı yazabilir ve diğer okuyucuların yorumlarına bakabilirsiniz.
 talkback page 

Görselyöre sayfalarının bakımı, LinuxFocus Editörleri tarafından yapılmaktadır
© Bernard Perrot, FDL
LinuxFocus.org
Çeviri bilgisi:
fr --> -- : Bernard Perrot <bernard.perrot%28at%29univ-rennes1.fr>
en --> tr: Özcan Güngör <ozcangungor%28at%29netscape.net>

2003-02-04, generated by lfparser version 2.35