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
�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:
- A� �zerinden �ifre g�ndermekten ka��n�n.
- Ba�l� sistemlerde g��li yetkilendirme
kullan�n.
- Uzak komutlar� tam g�venlik i�inde �al�t�r�n.
- Dosya transferini koruyun.
- G�venli�i zay�f olan X11 oturunlar�n�n
g�venli�ini art�r�n.
Bunlara kar�l�k yeterli olmayan baz� ��z�mler:
- "R-komutlar�" : BU komutlar �ifreyi a��k
�ekilde g�ndermez ancak "rhosts" mekanizmas� g�venlik sorunlar�na sebep olur.
- "Tek kullan�ml�k �ifreler": Sadece yetkilendirmeyi
komtrol eder, veri ak���n� de�il.Bu y�ntemin �ekici bir �n� olmas�na ra�men
kullan�c�lara kabul ettirmek zordur.
- ��frelenmi�(encrypted) telnet: BU sadece
telnet ile i�e yarar.Bunun d���ndakileri (X11 gibi) kapsamaz.
Ve i�te SSH, g�zel bir ��z�m:
- R-komutlar�n� de�i�tirir: rsh ve rlogin
yerine ssh, rcp yerine scp, ftp yerine sftp.
- S�k� yetkilendirme kullan�r.A��k anahtarlar
kullanarak �ifreleme algoritmalar�na dayan�r (ister sistemler i�in, ister
kullan�c�lar i�in).
- X11 ve "t�nel" otumunda TCP veri ak���n�
y�nlendirme.Bu otomatik olarak yap�labilir.
- T�neli �ifreleme.�stenildi�inde s�k��t�rma
da yapar.
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:
- SSH Ula��m Katman� Protokol� (SSH-TRANS)
- SSH Yetki Protokol� (SSH-AUTH)
- 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:
- Ula��m katman�, b�t�nl���, �ifrelemeyi,
s�k��t�rmay� ve sistemin yetkilendirmesini sa�lar.
- Yetkilendirme katman� yetkilendirmeyi
sa�lar ( �ifreler,a��k anahtarlar )
- Ba�lant� katman�, t�neli (kabuk, SHH-agent,port
y�nlendirme, ak�� kontrol�) y�netir.
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� anahtar�: A��k anahatar�n ve
gizli anahtar�n (her ikisi de asimetriktir) derlemesinden olu�ur. Kullan�c�
tan�mlam��t�r ve kal�c�d�r (diskte tutulur).E�er a��k anahtar y�ntemi(ileride
a��klanacakt�r) kullan�lm��sa bu anahtar kullan�c� yetkilenidirmesi i�in
kullan�l�r.
- Makina anahtar�: A��k anahatar�n ve gizli
anahtar�n (her ikisi de asimetriktir) derlemesinden olu�ur. Sunucu y�netici
taraf�ndan kurulum veya ayarlanma an�nda olu�uturulur ve kal�c�d�r (diskte
saklan�r). Bu anahtar sistemler aras� yetkilendirmede kullan�l�r.
- Sunucu anahtar�: A��k anahatar�n ve gizli
anahtar�n (her ikisi de asimetriktir) derlemesinden olu�ur.Bir deamon taraf�ndan
olu�turulur ve her �al��t�r�lmada ve d�zenli olarak de�i�ir.Bu anahtar SSHv1'de
oturum anahtarlar� de�i�imini g�venli yapmak i�in haf�zada saklan�r ( SSHv2'de,
sunucu anahatar� yoktur.De�i�imim g�venligi Diffle-Hellman protokol� taraf�ndan
sa�lan�r.)
- Oturum anahtar�: Bu anahtar, ileti�im
kanal�n�n g�venli�ini sa�lamak i�in simetrik �ifreleme algoritmas� kullan�larak
olu�turulur.Modern �ifreleme �r�nlerinde oldu�u gibi, bu anahtar rastlant�sal
ve k�sa �m�rl�d�r.SSHv1'de, her oturum i�in bir anahtar vard�r ve her iki
tarafta da bulunur.SSHv2'de, her iki tarafta farkl� olan iki anahtar bulunur.
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:
- "telnet benzeri":
Bu, geleneksel �ifre y�ntemidir:Ba�lant� yap�ld�ktan
ve kullan�c� kendisini tan�mlad�ktan sonra �ifre girmesi istenir.Bu �lifre,
sunucu �zerinde daha �nce bu kullan�c�ya atanm�� �ifre ile kar��la�t�r�l�r.Buradaki
problem (internet �zerinde astronomik say�lara ula�an �al�nt�lara sebep olan)
�ifrenin neredeyse a��k �ekilde g�nderilmesi.Elinde basit bir "sniffer" program�
olna herkes bu �ifreyi g�rebilir.Burada SSH de ayn� �ekilde �al���r (yeni
ba�layanlar i�in SSH'e ge�menin basit bir yolu,��renilmesi gereken daha fazla
�ey yoktur) ancak SSH'de �ifre �ifrelenerek g�nderilir.
Bu y�ntemden daha g�venli olan� ise "Tek kullan�ml�k
�ifre"dir:BU a��k�a daha iyi ve daha g�venlidir.Fakat kullan�m k�s�tlar�
y�z�nden heryerde kullan�lamaz.�u �ekilde �al���r:Kullan�c� ismini girdikten
sonra sunucu sabit bir �ifre sormak yerine bir "soru" sorar.Bu soru her seferinde
farkl�d�r ve cevap da de�i�ir.Cevab�n ��renilmesi �nemli de�ildir ��nk� bir
daha kullan�lmayacakt�r.
� - "rhosts benzeri"
Bu durumda, tan�mlama R-komutlar�nda oldu�u
gibi /etc/rhosts ya da ~/.rhosts gibi istemciyi do�rulayan dosyalard�r.SSH,
daha iyi tan�mlama ve daha �zel bir dosya (shosts) kullan�r.Bu yeterince g�veni
de�ildir ve e�er tek ��z�m de�ilse kullan�lmas�n� tevsiye etmem.
� - A��k anahtar kullan�lmas� :
Burada, yetkilendirme asimetrik �ifrelemeye
dayan�r (ar�nt�lar i�in �ifreleme makalesine
bak�n; basit�e, SSHv1 RSA kullan�r ve SSHv2 DSA kullan�r).Kullan�c�n�n a��k
anahtar� sunucuda, gizli anahtar� ise istemcide saklan�r.Bu y�ntemle, hi�bir
gizli bilgi a�da g�r�nmez ve asla sunuya g�nderilmez.
Hala m�kemmel g�venli�e ul�amd�k ��nk� bu
y�ntemde g�venlik kullan�c�n�n ciddyetine ba�l�d�r ( bu sadece SSH'e �zg�
de�ildir, a��k anahtar� olan b�t�n sistemlerde vard�r); A��k anahtar�n istemcide
s�k��t�rl�mas�ndan ka��nmak i�in, anahtar bir �ifre (genellikle ge�i�deyimi
denir) ile korunur.E�er kullan�c� kendi gizli anahtar�n� korumazsa, buna
sahip olan ki�i her yere ula�abilir.Bu y�zden g�venlik kullan�c�n ciddiyetine
ba�l�d�r ve sunucu y�neticisinin gizli anahtar�n d�zg�n korunup korunmad���ndan
haberdar olmas� m�mk�n de�ildir.Bug�n SSH ciddiyeti kontrol etmez.�rne�in;E�er
bir gizli �ifre ev bilgisayar�nda ge�i�deyimi kullan�lmadan saklan�rsa (evde
k�t� niyetli ki�iler olmayaca��ndan neden ge�i�deyimiyle u�ra�al�m ki !!)
ve bir g�n bu bilgisayar tamire giderse ( g�lmeyim, elektronik imzalar yayg�nla�t�k�a
bunlar olacakt�r), tamirci (o�lu veya arkada��) gizli �ifreyi alabilecektir.
SSH'i ayarlamak SSHv1, SSHV2 ya da OpenSSH
kullan�m�na ve hatta MacOS tm ya da Windowstm kullan�m�na
g�re de�i�ir.Temel prensipleri ve ad�mlar� hat�rlatal�m:
- Asimetrik anahtar �iftinin nas�l �ertilece�i
(bunlar a��k/gizli RSA veya DSA anahtar �iftidir), genellikle istemci �zerinde
tan�mlan�r (e�er birden fazla istemci varsa birinde anahtar �iftini �retip
di�relerine kopyalabilirsiniz).Baz� MacOS tm ya da Windows
tm istemcileri bu anahtarlar� �retecek programlara sahip de�ildir.Bunu
i�in �nce bir Unix istemcide bunlar� �retip sonra di�re istemcilere kopyalanmal�d�r.
- Yetkilendirme yapacak sunucuya a��k anahtar�n
kopyalanmas�.Bunun i�in kullan�c�n�n ~/.ssh dosyas�ndaki gerekli sat�rlar�,
sunucuda ayn� yere kopyalamak yeterlidir (dosya ismi SSH versiyonuna g�re
de�i�ir,autorized_keys yada autorization gibi).
- Hepsi bu...E�er ayarlar sunucu seviyesinde
daha fazla yetkilendirmeye gereksinim duyarsa, kullan�c� ba�lan�rken ge�i�deyimini
girmek zorunda kalacakt�r.
Yetkilendirmeyi ilgilendiren bir ka� elemana
g�z atal�m:
- ssh-agent
Bir ki�inin gizli anahtar�n� korumamas�n�
bir nedeni de her ba�lant� kuruldu�unda anahtar�n tekrar girilmesidir.Ba�lant�
arkaplanda �al��an scriptlerle kuruldu�unda, anahtar kullan�lamaz.�aresi SSH
ajan�(ssh-agent)'d�r.Bu servis, sizin taraf�n�zdan �al��t�r�l�r ve sizin
kimlik bilgilerinizi (kullan�c� ismi/makina ismi/ge�i�deyimi) saklar, ba�lat�
gerekti�inde bu bilgileri sizin i�in g�nderir.�stemci taraf�nda, �ifre sadece
bir defa sorulur.
Kimsenin sizi gizli anahtar�n�z� korumak
i�in zorlayamaca��n� biliyorsunuz ama bu ihmali yapt���n�zda olacaklardan
siz sorumlu olursunuz. - "ayr�nt�"
modu
Bazen ba�lant� kullan�c�n�n bilmedi�i bir
sebepten dolay� kopar.Bu durumlarda -v (verbose/ayr�nt� modu) se�ene�ini ssh
komutuna ekleyin.Bu durumda bir�ok ayr�nt�l� ileti alacaks�n�z.Bir�ok durumda
giri� yapamaman�z ve ba�lant� kopmas�n�n sebebini bulabilirsiniz.
�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:
- IDEA: 3DES'den daha performasl�d�r.Lisans
i�in baz� �artlar� vard�r (Unix versiyonlar�nda neredeyse default alogritmad�r.)
- Blowfish: �ok h�zl� ve g�venlidir.
- AES: yeni standart (DES yerine gelmi�tir).Ever
her iki taraftada varsa bunu kullan�n.Bu i� i�in yap�lm��t�r.
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:
- Yerel port y�nlendirme(istemciden sunucuya)
�
�
�
�
�
�
�
�
�rnek:user@alice% ssh -L 1234:bob.org:143
bob.org
Bu sistem, alice�oeg'dan IMAP sunucusu olan
bob.org'a ula��m� sa�lar.D��ar�dan yap�lacak ba�lant�lar engellenecektir.Ba�lant�lar
sadece alice.org �zerinde �al��t�l�an IMAP istemcisinden yerel makinalar�n
1234. portuna yap�labilir.
- (1) alice.org �zerindeki kullan�c�, SSH
t�nelini (ba�lant�s�n�) a�ar.
- (2) alice.org �zerindeki kullan�c�, istemcinin
yerel IMAP'ini yerel makinan�n 1234. portuna eri�ecek �ekilde ayarlar.
�
- Uzaktaki portu yerel porta y�nlendirme
�
�
�
�
�
�
�
�
�rnek: root@alice% ssh -R 1234:bob.org:143
bob.org
Bu �rnek de yukar�dakiyle ayn�d�r ancak
uzak makinadaki port y�nlendirilmi�tir.Sadece root kullan�c� bu komutu kullanabilir
ancak b�t�n kullan�c�lar olu�turulan t�neli kullanabilir.
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.
�
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:
- OpenSSH kendi �ifreleme k�t�phanesini,
OpenSSL'i kullan�r ve genelde bu k�t�phane dinamik olarak ba�lanm��t�r.Bizim
durumumuzda, bu �ifreleme paketi iyi g�venlik seviyesine ve g�venilir �zelliklere
sahiptir ve bu paket, bana g�re, bir �nceki yakla��m� tamamen yanl�� k�lar.Tabii
ki bu k�t�phaneye yap�lacak bir sald�r� pakete yap�lm�� olur.
- OpenSSH, kendisine ait baz� hassah servileri
kullan�r ( �rne�in, ratgele say� �reteci).OpenSSL de oldu�u gibi buradaki
d�� ba��ml�lar hakk�nda uyar�da bulunaca��m.
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.
- "Man in the middle (ortadaki adam)" sald�r�s�:
�
�
�
�
�
�
�
�
Sald�rgan, her iki taraf�n da paketlerini
durdurur ve kendi paketlerini g�nderir.( senaryolar� art�rmak m�mk�nd�r: aradaki
ba�lant�y� kesip kendisinin ger�ek istemci oldu�una inand�rmak)
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.
- SSH: the Secure Shell
�
�
�
�
�
�
�
�
Daniel J. Barret & Richard E. Silverman
O'Reilly - ISBN 0-596-00011-1
- Unix Secure Shell
�
�
�
�
�
�
�
�
Anne Carasik
McGraw-Hill - ISBN 0-07-134933-2
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.
2003-02-04, generated by lfparser version 2.35