Eposta üniversiteler için ne anlama geliyor?

Bir önceki yazımda üniversitelerin %52'sinin eposta servisini kendi kontrolü olmayan şirketler aracılığı ile verdiğini yazmıştım. Üniversitelerin %17'sinin de eposta sunucularını MS işletim sistemleri üzerinden sağladığı düşünülünce konuya özgür yazılım açısından bakan biri için durum oldukça kötü görünüyor. Bu yazıda da üniversiteler neden bu tercihi yapıyorlar ve sonuçları neler oluyor konularını tartışmak istiyorum.

Biz yapamayız, ara eleman olalım fikrinin bir uzantısı

Üniversitelerin üreten ve paylaşan kurumlar olması durumunda neler yapabildiğinin dünyada pek çok örneği var BSD (Berkeley Software Distribution), wu-ftpd (Washington University ftp daemon) ve (MIT tarafından geliştirilen) Kerberos diğer pek çokları arasından bir çırpıda aklıma gelenler. Elbette eposta sunucularını kendimiz tutsak fezaya bayrak dikecektik, dışarı verdiğimiz için dikemiyoruz demiyorum ama eposta sunucusunu dahi kendi ayakta tutamayan bir üniversite nasıl olacak da dünyada yapılmamış bir işi kendi bilgi işleminden bekleyecek bilemiyorum. Eposta sunucularının diğer bütün sunucu servisleri gibi sorunlar çıkarttığı tahmin etmesi zor olmayan bir gerçek ama bunları çözmeye çalışmak, bu çözümleri başkalarıyla paylaşmak harcanan emeğe değecek bir iş bence. Sunucu servislerini dışarı taşımak bilgi işlemleri sorunları çözebilen birimler olmaktan sorun raporlayan birimlere dönüştürmek demek oluyor.

Bu servisler gerçekten "bedava" değil

Ne Google ne de Microsoft üniversitelere eposta hizmeti verirken belirli kullanıcı sayılarına kadar ücret talep etmiyor. Bu hizmeti sonsuza dek ücretsiz vereceklerinin, hatta vereceklerinin garantisi de yok. Yakın gelecekte bu servisi ücretli hale getireceklerini de düşünmüyorum doğrusu. Bir üniversitenin binlerle ifade edilen personelinin, onbinlerce öğrencisinin epostalarına üste para vermeden sahip olabilen bir kurum bundan neden vazgeçsin ki zaten? Peki bedava olmayan ne o zaman? İnternet bağlantısı tabi ki. Bilmeyenler için yazayım; ülkemizde üniversiteler internet bağlantısı için kendi bütçelerinden bir harcama yapmıyorlar. TÜBİTAK'a bağlı ULAKBİM bütün devlet üniversitelerinin bağlantıları için faturayı kendisi ödüyor. Durum böyle olunca üniversitelerde internet bağlantısı sanki ücretsizmiş gibi bir algı oluşuyor ama durumun öyle değil.

Telekom altyapısına çok az yatırım yapıldığından ULAKBİM üniversitelere çok kısıtlı bant genişlikleri verebiliyor. 50.000 öğrencisi ve 2000 personeli olan bir üniversitenin hızının yaklaşık 1Gbit/s olduğunu söyleyebilirim (çoğu anadolu üniversitesi için rakamlar bunun çok altında aslında). Aşağıda dün avrupada yaşayan bir arkadaşımla yaptığım yazışmada da görebileceğiniz gibi bir ev kullanıcısı 500 Mbit/s hızı tek başına kullanabiliyor. Hal böyleyken kurum içi eposta haberleşmesinin tamamını Amerika'ya gönderip alması veya yurtiçine gönderilen her epostanın Avrupayı gezip öyle yerine ulaşması bence kötü bir karar. Harcanan bu bant genişliğinin parasını üniversiteler kendi ödemiyor ama sonuçta ödeniyor.


Kararlar teknik değil idari 

Üniversite bilgi işlem daire başkanlıklarının çoğunlukla çok kısıtlı kaynaklarla çalıştığı bilenen bir gerçek ama çok yeni kurulmuş bir kaç üniversite dışında mail hizmetini google veya MS'e devretmiş üniversiteler zaten servisi veriyordu. Önemli bir çoğunluğunda bu işi çok kaliteli yapan arkadaşlarımız vardı, hala da o kurumlarda çalışıyorlar. Eposta sunucusunu biz işletmeyelim kararı bu servisi veren teknik bilgisi olan personelin kararı değil, üst yönetimlerin aldıkları kararlar. Bunu çok fazla sistem yöneticisinden bizzat dinledim.

Eposta sunucusu işletmek zor bir iş mi diye sorarsanız cevabım 'yeterince bilmiyorsanız her sunucuyu işletmek zor' olacaktır. Birer eğitim ve araştırma kurumu olan üniversiteler işletmesi zor diyerek kullanıcıların mahremiyetlerini hiçe sayarak bu görevden vazgeçmemeliler. Böyle bakınca DNS de zor bir servis diyerek yarın onu da mı kontrolümüz dışında bir yere vereceğiz?

Eposta yazışmalarının mahremiyeti hiç düşünülmüyor

Eposta yazışmalarımızı MS veya Google'a teslim etmek bütün yazışmalarımızı iki bütün amerikan şirketinin diskinde tutmak demek olurken bundan rahatsız olmamak nasıl mümkün oluyor anlamakta zorluk çekiyorum gerçekten. Bütün kullanıcıların gönderip aldıkları mailler üzerinden yapılabilecek en hafif şeyin reklam gösterimi olabileceğini düşünüyorum. Konuya bilgi güvenliği açısından bakınca durumun vahametini görmemek mümkün değil. Son dönemde hakkında çokça konuşulan kişisel verilerin korunması açısından bakınca da kurumların kullanıcılarının epostalarını hiçbir kontrolleri olmayan kurumlara devretmesi üzerinde konuşulması gereken bir konu olmalı.

İnternet erişim engellemeleri hiç hesaba katılmıyor

Neredeyse üç yıl youtube engelinin yaşandığı bir ülkede yaşıyoruz. Bu engellemelerin önce dns çözümlemesiyle yapıldığını daha sonra ise google'a ait IP adreslerinin engellendiğini hatırlatmak isterim. Google bu adresler üzerinden sadece youtube yayınını değil başka servislerini de yaptığından diğer servislere erişimde sorunlar yaşandığını düşününce yarın benzer bir yasaklama olduğunda (olmayacağını düşünen varsa tanışmak isterim kendisiyle) eposta servisinde bir aksama olduğunda üniversiteler kiminle konuşup servislerini ayağa kaldırabilirler? Benzer şekilde dosya paylaşım sitelerine getirilecek bir yasakla eposta servisleriyle birlikte kullanıcılara sunulan depolama alanları da bir anda erişilmez duruma gelecektir. Üniversiteler bütün kullanıcılarını vpn veya tor kullanmaya yönlendirmeyecekse bu durum için bir planlarının olması gerekir ama olmadığını hepimiz biliyoruz.

Servisi başkasına yaptırmak elimizdeki araçları alıyor

Kurum dışından biri size eposta gönderdiğini söylesin ve siz bunu alamamış olun. Ortada bir sorun olduğu açık ama bunu nasıl çözeceksiniz. Eğer eposta sunucusu kurumunuzdan biri tarafından yönetiliyorsa sunucu loglarına bakmasını sorunu teşhis etmesini isteyebilirsiniz ama bunu google'dan nasıl isteyeceksiniz?

Kullanıcılarınıza google ve/veya sunmadığı bir teknolojiyi kullandırmak istemeniz durumunda yine eliniz kolunuz bağlı durumdasınız. Örneğin epostalarınızı Google'a vermişseniz eposta sunucunuza IPv6 üzerinden de erişilebilirken MS henüz bu hizmeti vermiyor (en azından Outlook kullanan hiçbir üniversite MX kaydına böyle bir girdi yapmamış). Eposta sunucusunu kendisi barındıran 17 anadolu üniversitesinin eposta sunucusuna IPv6 üzerinden de ulaşılabiliyor. Elbette Microsoft da yarın IPv6 hizmeti vermeye başlayabilir ama yeni bir teknolojiyi denemek, kullanmak için bu şirketlerin zamanlamasını beklemek üniversitelerin yapması gereken bir şey mi sizce de?

Yerli de değil, milli de

Son zamanlarda hemen herkesin dilinde olan yerli yazılım, milli yazılım söylemi ile epostaları Amerika'da, Avrupa'da saklamak yan yana getirmesi zor şeyler gibi görünmüyor mu size de? Bu konuda daha önce uzunca yazdığım için tekrarlamak istemiyorum ama özgür yazılımlar sanki bu topraklarda yazılmış gibi kullanabileceğimiz ve ihtiyaçlarımıza göre özelleştirebileceğimiz yazılımlarken onları kullanmalıyız.

Dünyada durum nasıl?

Dünyaca ünlü, hemen herkesin adını bildiği MIT, Harvard, Yale, Caltech, Purdue, Oxford ve Princeton eposta servisini MS veya Google'a vermiş değil. Bunda da gören gözler için bazı ibretler olmalı.

Konuyla ilgili hala ikna edici olmayan bir yer varsa yorum olarak yazarsanız cevaplamaya çalışayım.

5 Nisan 2017

Posted In: eposta, Gezegen, google, microsoft, Özgür yazılım

Üniversiteler eposta bayrağını nasıl kaybetti?

Üniversitelerin bilgi işlem daire başkanlıkları çoğunlukla kısıtlı personelle ama çok büyük özveriyle çalışan birimleridir. İşler yolunda giderken, yani internet bağlantısında bir problem olmadığında, ne yaptıkları pek anlaşılmaz ama en küçük kesintide hatırlanırlar. Üniversitelerin verdiği servisler çoğunlukla bu özverili personelin öğrenme isteğinden ve merakından kaynaklanır. Amirlerinin çoğunlukla adını bile duymadıkları servisleri kendi kurumlarında etkinleştirmek için hiç karşılığını almadıkları fazla mesailer harcarlar. ULAKBİM'in bilgi işlem personellerini bir araya getirdiği etkinliklerde heyecanla servisleri nasıl ayağa kaldırdığını anlatan çok sunum dinlemiş biri olarak yazıyorum bunları.

On yıl kadar önce neredeyse bütün üniversiteler diğer bütün servisleri gibi kendi eposta servislerini de kendi sunucularında tutarlardı. Zaten çok kısıtlı kaynaklarla çalışan bilgi işlem daire başkanlıkları çoğunlukla GNU/Linux kullanarak verirdi bu hizmeti. Kendi yetişmiş personeli olmasa bile civardaki üniversitelerdeki meslektaşlarından destek alarak bir kere kurulunca kuruma yetecek bir düzen kurulmuş olurdu.

Yukarıdaki cümleler hep geçmiş zamanlı çünkü bugün tablo çok büyük ölçüde değişmiş durumda. Aşağıda ayrıntılarını okuyacağınız gibi üniversiteler bu servisi büyük oranda artık kendileri vermiyorlar. Bir servisi vermek demek onun ayakta durması ve geliştirilmesi sırasında öğrenilecek şeylerle personelin kendisini geliştirmesi de demek olduğundan bilgi işlem daire başkanlıkları bu görevi başkalarına teslim ederken kendilerini de çok şeyden mahrum bırakıyorlar. Durum gerçekten bahsettiğim kadar vahim mi birlikte bakalım.


Bugün itibariyle Yüksek Öğretim Kurulu Başkanlığının bilgilerine göre 183 üniversitemiz var.
  • Bunların 7 tanesinin ya alan adı bile belli değil ya da henüz eposta servisi vermiyor. 
  • 51 üniversite personelinin elektronik postalarını Google'a devretmiş durumda. DNS sunucularına girilen bir kayıtla bütün eposta yönetimi işini Google'a teslim ederek bir odadan diğerine gönderilen epostanın kendi kampüslerindeki sunucuya değil California'ya gidip geri dönmesine neden olmuş durumdalar. Mesafeyi gözünüzde daha iyi canlandırabilmeniz için Mardin'den gönderilen bir epostanın gidip geldiği yolun bir ekran görüntüsü koyuyorum. Bu bağlantı için ödenen bedeli hepimizin vergileriyle yaptığımızı hatırlatmama eminim gerek yoktur.

  • 38 üniversite Microsoft'un çevrimiçi Outlook servisini kullanıyor. Bunu yapan üniversiteler de yine epostaları üzerindeki bütün kontrolü kaybetmiş durumdalar. Aşağıdaki ekran görüntüsü de Şırnak'tan gönderilen epostaların iletim merkezini gösteriyor.

  • 1 üniversite epostalarını Yandex'e, 1'i de Superonline'a teslim etmiş durumda.
  • Epostalarını bulut servislerine vermemiş üniversitelerden 29 tanesi Microsoft işletim sistemleri kullanarak bu servisi kendisi işletiyor.
  • 1 üniversite IBM AIX kullanırken, 2 üniversite de Oracle ile eposta servisini ayakta tutuyor.
  • 4 üniversite eposta servisini FreeBSD/OpenBSD kullanarak kendi sunucularında barındırıyor.
  • Sadece 49 üniversite bu servisi bir GNU/Linux dağıtımı kullanarak sürdürüyor. Bunların 18'inin sayfasından zimbra kullandıkları açıkça görülebiliyor.
Üniversitelerin özgür yazılımlar kullanarak kolayca yönetebilecekleri bu servisi yurtdışındaki bulut servislerine (başkasının bilgisayarına) teslim etmelerinin nedenlerini ve bunun yol açtığı şeyleri de bir sonraki yazıya bırakmadan önce bu bilgilere nasıl ulaştığımı yazayım kısaca: YÖK'ün sayfasından üniversitelerin alan adlarını öğrendikten sonra bir çok alternatifin arasından mxtoolbox'tan eposta sunucusu kaydını sorgulamak için 'MX Lookup' seçeneği kullanılabilir. Bununla google ve MS outlook kullananlar hemen görülebilirken kalanlar için üniversite sayfalarına girip 'eposta' bağlantılarını takip etmek yeterli olacaktır.

4 Nisan 2017

Posted In: eposta, Gezegen, google, güvenlik, microsoft, Özgür yazılım, Üniversite, yandex, zimbra

Son kullanıcı için özgür yazılım neden önemli? -3-

Meraklısı için bu serinin önceki yazıları: [0], [1], [2].

Özgür yazılımlar doğaları gereği sahipli yazılımlardan daha düşük ücretlerle sahip olunabilir yazılımlardır. Çok büyük oranda ücretsiz olarak kullandığımız özgür yazılımları para verip alsak bile dağıtılmaları ile ilgili bir kısıtlama olmadığından bir kere elde ettiğiniz özgür yazılımı isterseniz satabilir, isterseniz ücretsiz dağıtabilirsiniz. Peki bir sahipli yazılıma para verdiğinizde aslında neye sahip olursunuz? Yazılımı kurarken kabul edip devam ettiğiniz son kullanıcı sözleşmelerinde bu durum açıkça belirli ama çoğumuz onları okumadığımız için bir kaç noktaya dikkat çekmek önemli olacak.

Örnek olarak sahipli bir yazılım olan Microsoft Windows 10 işletim sisteminin kullanıcı sözleşmesinde neler olduğuna bakalım:

  • Kullanıcıların önemli bir çoğunluğu yazılım için ödedikleri paranın karşılığı olarak yazılımı satın aldığını düşünür ama bu çoğu durumda doğru değildir. Windows işletim sistemi için ödediğiniz paranın karşılığında "Yazılımın satışı yapılmamakta, lisansı verilmektedir". Eğer satın almış olsaydınız onun nasıl çalıştığını anlamak için istediğiniz amaçla çalıştırabilir, değiştirebilir, dağıtabilir, değiştirdiğiniz halini dağıtabilirdiniz. Örneğin bir otomobil için ödediğiniz bedelin karşılığında aldığınız arabayı kime isterseniz satabilirsiniz, motorunu açıp nasıl çalıştığına bakabilirsiniz, eğer elinizden geliyorsa bütün aksamını ihtiyaçlarınıza uygun değiştirebilir ve bu haliyle satabilirsiniz. Bahsettiğim bu işlemleri yapabileceğiniz yazılımlar özgür yazılımlardır.
  • Parasını ödediğiniz MS Windows işletim sisteminin "yazılımın teknik kısıtlamalarını aşacak çözümler üretmek", "yazılımda tersine mühendislik işlemi yapmak, yazılımı kaynak koda dönüştürmek veya assembler diline çevirmek veya bunları yapma girişiminde bulunmak" ve "yazılımı, ticari barındırma için sunucu yazılımı olarak kullanmak" son kullanıcı sözleşmesiyle yasaklanmış durumda. Bunları elbette çoğu kullanıcı zaten yapmayacaktır ama yapmasının yasak olması farklı bir şey.
  • Yazılımı "yayımlamak, kopyalamak, devretmek veya ödünç vermek" de yasaklananlar arasında. Mesela bir yakın arkadaşınız isterse yazlığınızın veya arabanızın anahtarını kimseden izin almadan verebilirken isteyeceği şey MS Windows olursa ona 'kusura bakma' demeniz bekleniyor. Hatta başka bir bilgisayarınız varsa ona da kurulum yapamazsınız. "Yazılımı yeni bir cihaza her devrettiğinizde, önceki cihazdan kaldırmalısınız". Bu da yetmediyse kurulum yaptığınız işletim sistemi üzerine sanal makineye bile ikinci bir kurulum yapmanıza yine aynı kullanıcı sözleşmesi izin vermiyor.
  • Madem bu kadar kıymetli bir şey diyerek lisansına bu kadar para verdiğiniz yazılımın kopyasını alıp saklamak isterseniz (sadece saklamak için) "yedekleme amaçlarıyla yazılımın tek bir kopyasını oluşturabilirsiniz".
  • Peki bu işletim sistemini kullanırken gizliliğim, güvenliğim ne durumda diye merak ediyorsanız sözleşmede buna da açıklık getirilmiş: "Bu anlaşmayı kabul etmekle ve yazılımı kullanmakla, Microsoft'un Microsoft Gizlilik Bildiriminde (aka.ms/privacy) ve yazılım özellikleriyle ilişkili kullanıcı arabiriminde açıklandığı şekilde bilgileri toplayabileceği, kullanabileceği ve açıklayabileceğini kabul etmiş olursunuz". Bu sözleşmeyi kabul eden birinin 'bilgisayarımdan bazı bilgiler toplanmış ve birilerine verilmiş' diye sızlanmaya hakkı yok çünkü baştan bunu kabul ediyor.
  • Buraya kadarki şartları bir şekilde kabul etmişseniz bile yazılımın sizin ücretini ödeyip lisansını aldığınız şekilde bilgisayarınızda kalacağından da emin olamazsınız. Yine sözleşmede geçen ifadeyle "Bu anlaşmayı kabul ederek, ek bildirim olmaksızın bu tür otomatik güncelleştirmeleri almayı kabul edersiniz". Yani bilgisayarınıza kurduğunuz yazılım yarın bazı işlevleri yerine getirmeyebilir veya bilmediğiniz (aslında kaynak kodu kapalı olduğu için hiçbir zaman bilemeyeceğiniz) yeni işlevler edinmesini sağlayacak bir hale size bir bildirim mesajı bile göstermeden dönüşebilir.
  • Yazılımı kendiniz kullanmaktan vazgeçip başkasına devretmek isterseniz, devredeceğiniz kişinin Amerikanın ticaret ambargosu uygulamadığı bir ülkede yaşamasının gerekmesi de kendi başına kabul edilemez bir durum olmalı normal insanlar için.
Normalde benzer şartları sunan hiçbir ürüne değil para vermek, bedava olsa kullanmayız. Özgür yazılımlar yukarıda bahsi geçen kısıtlamalarla karşılaşmayacağınız, size özgürlükler sunan yazılımlardır.

17 Mart 2017

Posted In: Gezegen, Lisans, microsoft, Özgür yazılım

GNU/kWindows

Son zamanlarda benzersiz bir karışım hakkında çok konuşuluyor: GNUtamamıyla özgür işletim düzeni— ve Microsoft Windows —özgürlüğü reddeden, kullanıcıyı denetleyen, gözetim düzeni. Ayrıca ortalıkta çok fazla yanlış bilgi var. Düşüncelerimi sizlerle paylaşacağım.

Bu konuyu tartışmadan önce bazı terimleri açıklığa kavuşturmamız gerekiyor: Kullanıcılar “Linux” işletim düzeni hakkında konuştuklarında aslında Linux çekirdeği eklenmiş GNU işletim düzenine atıfta bulunurlar; biz buna GNU/Linux (ya da GNU+Linux) işletim düzeni diyoruz. Çeşitli biçimlerde GNU işletim düzenini kullanıyorsanız komut satırından tanıdık gelecek bir çok yazılım GNU yazılımıdır: bash, (g)awk, grep, ls, cat, bc, tr, gcc, emacs ve diğerleri. Linux bir çekirdektir ve işletim düzeninin yapmaya çalıştıklarını destekler: işlemleri, hafızayı, dosya düzenlerini ve daha fazlasını yönetir, çekirdeğin çeşitli eylemleri gerçekleştirmesini yöneten düzen çağrılarını sağlar, bu eylemler yeni işlemleri çatallamak ya da hafızayı tahsis etmek gibidir. Bu önemli bir ayrımdır —tüm bu yazılımı “Linux” olarak adlandırmak hatalı olduğu gibi tamamıyla özgür Unix ikamesi olan GNU tasarısını göz ardı etmektedir.

İsimlendirme sorunu oldukça yaygındır, GNU/Linux işletim düzeni kullanıyor olsa bile çoğu kullanıcı GNU'nun ne olduğunu bilmemektedir. Son olarak GNU Bash'tan “Linux Bash” olarak bahseden makale okudum; bu adeta GNU tasarısına, 26 yıldır Unix-benzeri düzenlerde (Apple'ın sahipli Mac OS X'i dahil) en geniş kullanıma sahip kabuğu yazan tüm yazarlara atılan bir tokattır.

GNU çoğunlukla Linux çekirdeğiyle kullanılmaktadır ama durum her zaman böyle değildir. Örneğin GNU kendi çekirdeği Hurd ile çalışabilir (GNU/Hurd). BSD çekirdeği olan bir düzende çalışabilir (örn. GNU/kFreeBSD). Ama bugün bir ay önce bile duymayı beklemeyeceğiniz birşeyden bahsetmek istiyorum: GNU ve Windows çekirdeği. Bu karışım GNU/kWindows (GNU ile Windows çekirdeği) olarak atfedildi.[1]

Anlaşılana göre Microsoft ve Canonical Linux düzen çağrılarını Windows'un anlayabileceği türe çeviren bir uyumluluk katmanı, altdüzen yazmak için birlikte çalışıyor. Yani, Linux çekirdekli bir düzen için derlenmiş yazılım çağrı çevirme ile Windows üzerinde çalışacak. Bir çok makale bu düzeni “Windows üzerinde Ubuntu” ya da “Windows üzerinde Linux” olarak adlandırıyor. Yanılgı şu ki bu düzen Linux çekirdeğini kapsamıyor, GNU işletim düzeninin Linux yerine Windows'un çekirdeğiyle çalıştığına tanıklık ediyoruz.

Bu Microsoft için yadsınamaz bir teknik yarardır: Windows kullacıları GNU/Linux'tan ya da Apple'ın özgürlüğü reddeden Mac OS X'i gibi diğer Unix benzeri düzenlerden tanımış olabileceği ortamlarda geliştirme yapmak istiyor. Fakat bunun hakkında düşününce önemli bir kavramı göz ardı ettiğini anlıyoruz:

Kullanıcılar bir işletim düzeni adı olarak “Linux"tan bahsettiklerinde GNU hakkında konuşmaktan kaçınıyor. Ve GNU'dan bahsedilmesinden kaçınarak ayrıca GNU'nun üzerinde kurulduğu temel ilkeleri tartışmaktan kaçınmış oluyorlar, bu ilkeler tüm kullanıcıların yazılımdan dört ana özgürlüğü temin etmesi fikridir: yazılımı her amaç için kullanabilmek, yazılımı anlayabilmek ve ihtiyaca göre düzenleyebilmek (ya da sizin için bunu başkasının yapabilmesi), yazılımı diğerleriyle paylaşabilmek, değişikliklerinizi başkalarıyla paylaşabilmek. Bu dört özgürlüğe saygılı yazılımlara özgür yazılım diyoruz.

Özgür yazılım gerçekten önemlidir, saldırıya açık olan kullanıcıların geliştirme esnasında (yazılım geliştiricilerin ya da şirketlerin değil) kendisinin denetimini temin eder. Kullanıcının bu dört özgürlüğünü ihmal eden herhangi bir yazılım özgür olmayan (ya da sahipli), özgürlüğü reddeden yazılımdır.  Bunun anlamı herhangi bir özgür olmayan yazılımın yeteneği ve verimi önemsizdir, benzer görevi yerine getiren özgür yazılımdan daima aşağıda olacaktır.

Herkes özgürlükten ya da özgür yazılım felsefesinden konuşmak istemez. Bu anlaşmazlık "açık kaynak” geliştirme yöntembiliminde sonuçlanmıştır, özgür yazılımın faydalarını gerekli fikirsel hususları tartışmadan şirketlere satmaktadır. “Açık kaynak” felsefesinde eğer özgür olmayan bir yazılım daha iyi özelliklere ve verime sahipse o kesinlikle daha iyidir, çünkü “açık kaynak” geliştirme yöntembiliminden üstün gelmiştir, özgür olmayan yazılım her zaman kötü bir şey olarak sayılmaz.

Tüm bunları bir araya getirelim: GNU adında özgür bir işletim düzenine sahibiz. Genellikle Linux çekirdeğiyle birlikte kullanılıyor ve ikisi birlikte GNU/Linux işletim düzeni olarak adlandırılıyor. Ama şimdi GNU/Linux'u alıp Linux'u kaldırıp ve onun yerine Windows çekirdeğini eklediğimiz bir duruma sahibiz, kar sağlayan GNU/kWindows. GNU kullanıcı özgürlüklerine değer verir. Windows ise tam tersini yapar.

Kullanıcılar neden bunu istiyor? Yani, belki de Mac OSX'te GNU araçlarını istemeleriyle aynı sebeptir, kullanmak istedikleri yazılımları kullanmak istiyorlar ayrıca GNU'da beğendikleri teknik faydaları istiyorlar. “Açık kaynak” felsefesini ele aldığımızda —çünkü eğer bir kullanıcı özgürlüğüne değer veriyorsa GNU/Linux gibi tamamıyla özgür bir işletim düzeni kullanmalıdır. Eğer bir kullanıcı zaten Windows kullanıyorsa GNU yükleyerek bir takım özgürlükler kazanır, artık düzeninde özgürlüklerine değer veren daha fazla yazılıma sahiptir ve bu yüzden böylesi onun için daha iyidir.

Peki ya bugün GNU/Linux kullanıyorsanız? Bu durumda GNU/kWindows düzenine geçmek büyük bir gerileme demektir, bunu yaparken özgürlüklerinizi Microsoft'a teslim etmiş olursunuz. Microsoft'un özgürlüğü reddeden gözetleyici düzeninde ne kadar parlak özellikler tanıttığının bir önemi yok, özgürlüğünüze saygı duyan bir işletim düzeni her zaman birincil tercih olmalıdır. Kullanıcıların GNU'nun sağladığı teknik yararlar için GNU/kWindows düzenine geçmemesi adına elimizden gelenin en iyisini yapacağız.

Birazı gerçek birazı felsefik olmak üzere elimizde bir takım sorunlar var:

İlkin, lütfen GNU/kWindows'u “Windows üzerinde Linux” (bununla ilgili başka bir biçimde) olarak atfetmeyin, yanlış bilgiyi yaymak durumu karıştırmanın ötesinde GNU işletim düzeni üzerinde çalışan binlerce yazarı göz ardı etmektir. “Windows üzerinde Ubuntu” olarak anmazsanız en iyisini yapmış olursunuz, bu tam yanlış bir ifade sayılmaz -Ubuntu'nun dağıttı GNU'yu kullanıyorsunuz- ama hala GNU Tasarısından bahsetmiyor. GNU'dan bahsedersek, kullanıcılar tasarıyla ilgili sorular sorabilir ve belki de kendi kendilerine sonuç ararlar. Özgür yazılım felsefesini okuyacaklar ve umarım sorunları, evvela daha önce farkında olmadıkları sorunları anlamaya başlayacaklar.

İkinci olarak, GNU/kWindows düzeni kullanan birisi gördüğünüzde kibarca nedenini sorun. Onlara sadece bu teknik yetenekleri sağlayan değil ayrıca özgürlüğü sağlayan daha iyi işletim düzeninin olduğunu söyleyin! Özgür yazılımın ne olduğunu söyleyin ve onlarla özgür yazılımı bağdaştırın ve neden önemli olduğunu anlamalarını sağlayın.

GNU'dan yarar sağlayan daha fazla insan görmek iyi ama ne için burada bulunduğumuzu ya da adımızı çok fazla anmadan, kullanıcıları diğer taraftan sahipli gözetim düzenine çekerek, böyle satıldığında mutlu olamayız.

[1] Bu isim Richard Stallman’dan gelmektedir. GNU Tasarısının kurucusudur.

Lisans: Bu metin CC BY-SA 4.0 lisansı altında dağıtılan “GNU/kWindows” metninden tercüme edilmiştir. Özgün metin Mike Gerwitz tarafından yazılmıştır. Tercüme metni CC BY-SA 4.0 altında lisanslanmıştır.

9 Nisan 2016

Posted In: canonical, gnu, GNU/kWindows, gnu/linux, hurd, linux, linuxgezegeni, microsoft, Özgür yazılım, tercüme, ubuntu, windows

GNU/kWindows

Son zamanlarda benzersiz bir karışım hakkında çok konuşuluyor: GNU —tamamıyla özgür işletim düzeni— ve Microsoft Windows —özgürlüğü reddeden, kullanıcıyı denetleyen, gözetim düzeni. Ayrıca ortalıkta çok fazla yanlış bilgi var. Düşüncelerimi sizlerle paylaşacağım. Bu konuyu tartışmadan önce bazı terimleri açıklığa kavuşturmamız gerekiyor: Kullanıcılar “Linux” işletim düzeni hakkında konuştuklarında aslında Linux çekirdeği eklenmiş GNU işletim düzenine atıfta … Okumaya devam et "GNU/kWindows"

9 Nisan 2016

Posted In: canonical, gnu, GNU/kWindows, gnu/linux, hurd, linux, linuxgezegeni, microsoft, Özgür yazılım, tercüme, ubuntu, windows

ReactOS: Özgür lisanslı Windows inşa etmek

Çoklu önyüklemeden WINE'a, özgür yazılım Windows uygulamalarını çalıştırmak için hep bir çözüm üretmeye çalıştı. Yine de bu çabaların sadece birkaçı Windows'un özgür lisanslı uyarlaması olan ReactOS kadar hırslı olabildi. Tasarı 2006'dan beri faal ve on yıllık zorlu ve ihtiyatlı geliştirmenin ardından Şubat 2016'da ilk alpha sürümü piyasaya çıktı.

Geliştirici Ziliang Guo'ya göre özgür lisanslı Windows 95 uyarlamasını hedefleyen FreeWin95 tasarısının başarısızlığından ReactOS meydana geldi.

“FreeWin95 hiçbir yere gelemedi çünkü insanlar işletim sistemini nasıl uyarlayacakları hakkında teknik tartışmalar yaptı ve çıkmaza sürüklendi. Kimse kodlamayı istemedi.”

Mesafe kaydedememenin bir sonucu olarak Jason Filby ve David Welch Windows NT'nin özgür sürümünü oluşturmak için yeni bir tasarı oluşturdular. Bir başka tasarı üyesi olan Jeff Know tasarıya ReactOS (React: tepki) adını önerdi çünkü bu çaba Microsoft'un masaüstündeki tekeline bir tepkiydi.

image

Geçmişten bir esinti: ReactOS üzerinde WinZip çalışıyor

Tersine Mühendislik ve Belgelendirme

Başlangıçta ReactOS zorluklarla karşı karşıya geldi. Tasarı başladığında bir çok Windows derleyicisi sahipliydi ve özgür olan bir kaçı ise acı verici şekilde yetersizdi. Gerekli araçları geliştirmekte büyük bir adım niteliğindeki MinGW‘den sorumlu ana geliştirici Casper Hornstrup'ı hatırlıyor Guo. Bu koşullar altında ReactOS'u çalıştırabilmek/önyükleyebilmek bile bir mihenk taşıydı. Guo'nun belirttiği gibi,

“Gerçekten bir işletim sistemini çalıştırabilmek insanların düşündüğünden daha karmaşık bir iş”

Bir diğer sorun ise Windows NT'nin iç mimarisi için yetersiz belgelendirme olmasıydı. Örneğin, çekirdek seviyesi API'leri üzerinde bilgi yetersizliği NT sürücü uyumluluğunu zorlaştırıyordu. Benzer olarak dahili birbirine bağımlılıkların geliştirilmesi gerekiyordu, sorun teknik zorluklara sebep olduğu gibi bu zorlukları artırıyordu.

“Takım eksik bir özelliği tamamlamak üzere olduğunda bazen varolan bileşenlerin içine geri dönüp hackleri silmesi gerekebiliyor, (bu süreç) diğer hacklerle bağlantılı hacklerin oluşturduğu bir tavşan deliğinde sonlanıyor ve tüm bu şey başarısız yollarda adeta çöküyor.” diyerek açıklıyor Guo.

Bugün durum bir miktar düzeldi. MSDN sitesi, Windows Internals, Inside Microsoft Windows ve Windows Graphics Programming gibi bir çok kitaba ek “Microsoft Windows hakkında bolca belgelendirme mevcut” diyor tasarı yürütücüsü Aleksey Bragin. Bu bilgiler özgürce kullanılabiliyor ama bilgiler hatalar içerebiliyor ve belgelenmemiş bölümleri olabiliyor.

Bir diğer avantaj ise WINE'ın Win 32API için uyumluluk katmanı. ReactOS bunu yeniden kullabilir fakat “Tabi ki takım bu API'lere güç sağlayacak Win32 altsistemini doğru bir şekilde tamamlamak zorunda.” diyor Guo.

Bu nedenle, bu avantaja karşın, ilerlemek için ReactOS üçüncü şahıslar tarafından yapılan tersine mühendisliğe bağımlı. Diğer zamanlarda, tasarı üyeleri karakutuculuğa (blackboxing) başvuruyor, farklı türde girdilere Windows'un verdiği cevapları sistematik olarak test ediyor ve içerde neler olduğunu anlamaya çalışıyorlar.

Malesef, tersine mühendislik çoğu kez hukuksal mayın tarlasına dönüşüyor.

“Tasarıda her zaman şu farkındalık oldu: Microsoft'un bizi stratejik tehdit olarak görebilir ve kapatmayı isteyebilir.” diyor Guo. Herhangi bir olası sorunu önlemek adına, ReactOS her zaman dikkatli davranıyor, öncelikle katkıların kısıtlı Microsoft kodundan elde edilmediğinden emin olunuyor. Örneğin, tersine mühendislikle oluşturulmuş ve ardından Assembly'den C'ye çevrilmiş kod kabul edilmiyor ama karakutuculuk kabul ediliyor.

Doğrusu, Bragin'e göre, ReactOS mümkün olduğu kadar tersine mühendislikten kaçınmayı tercih ediyor. Tersine mühendislik kaçınılmaz olduğunda katkıcılardan GNU Kodlama Standartları'nın 2.1 maddesini uygulamaları, sahipli yazılımlara -özellikle Windows'a- atfı önlemeleri bekleniyor. Buna göre tüm kod mümkün mertebe özgün olandan farklı olmalıdır.

Yine de, tersine mühendislik bir gri alan gerektiriyor. Guo bunu hatırlatıyor, bir noktada, tasarı geliştiricileri lekesiz kodu neyin oluşturduğu hakkında farklı yorumlarla konu üzerinde tartıştı. Bu tartışma bazı geliştiricilerin çıkmasına sebep oldu ve tasarı kodlarının iç denetimiyle sonuçlandı. Neyse ki lekeli kod bulunmadı ve tasarı nihayet yoluna devam edebildi.

Önündeki Zorluklar

Alpha sürümü 0.4'ün piyasaya sürülmesi yıllar süren kitke kaynaklı çalışmayla, sınırlı başarının ardından geldi. Yeni sürüm Canlı CD olarak mevcut, Windows NT olarak tanıtılıp VirtualBox'a kolayca kurulabiliyor. Çağdaş donanım üzerinde yirmi yıllık sistemleri öykündüğü için işletim sistemi saniyeler içinde önyükleniyor. Winzip, özgür yazılım olan LibreOffice, bir kaç eski ve basit oyun gibi çeşitli yazılımları çalıştırabiliyor.

image

ReactOS kendi Solitaire sürümünü çalıştırıyor.

Yine de zorluklar sürüyor. Her zaman olduğu gibi nitelikli geliştiriciler ender:

“Halihazırda Microsoft için çalışmayan NT çekirdek uzmanlarının sayısı çok az.” diye not ediyor Guo. Mevcut donanımı desteklemek oldukça zor olabiliyor, Guo değişken donanım standartlarının bir problem olduğunu söylüyor ve “Microsoft bile bunlarla sıfır sorun yaşamıyor.” diyerek ekliyor.

Bir diğer sorun ise, son sürümlerdeki kullanılırlık üzerinde yapılan geniş çalışmaların ardından, Guo'nun sözleriyle:

“Geçmişte çok çok daha az olan kullanıcının görebileceği, büyük değişikliklerle yere yakın olan birçok meyve toplanmış oldu.”

Bu bazı temel sorunları hatırlatıyor. Örnek olarak öncelikler hakkında soru üzerine Bragin şöyle dedi:

“En önemli açık hafıza yönetimi ve önbelleklemeye bağlı sistem kararlılığında. Diğer sorunlar da var elbette ama gerçekten kararlı çekirdeğe sahip olmak tasarı için büyük başarı olur.”

Diğer baskı yapan sorun ise oyunlar için DirectX desteği. ReactOS WINE'ın DirectX uyarlamasına sırtını yaslamayı umuyor. Bragin oyun desteğinin önemli olduğunu çünkü hafızayı, dosya sistemini ve ağı kullanmaları “işletim sisteminin kendisi için güzel bir test” olduğunu vurguluyor.

İlk alpha sürümü dikkate değer bir mihenk taşı. ReactOS halihazırda yeterince gelişmiş, Bragin onu işletim sistemlerini öğretmek için kullanıyor.

“Ama gerçekten ReactOS'un bir kullanım senaryosunda Windows'un yerine kullanılabilecek güçte olduğu anı görmek istiyorum. Bu an kesinlikle önümüzdeki beş yıl içinde yaşanacak.” diyerek bir öngörüde bulunuyor.

Genel Dağıtıma Doğru

Sahipli geliştirmeyle etkileşime giren diğer özgür yazılımlarda olduğu gibi ReactOS da Microsoft'un kendi API'lerindeki daimi değişimin daima gerisinde kalacağa benziyor. Ancak bu durum ilk çıktığındaki kadar kasvetli olmayabilir.

ReactOS her Windows sürümünün tüm özelliklerini yeniden çoğaltmakla ilgilenmiyor.

“Biz güzel özellikler üretmeye çalışıyoruz, örneğin çeşitli temalar arasında geçiş yapmamızı sağlayan kullanıcı arayüzü tasarlayıcımız gibi. Yine de, Microsoft'un her eklediği güzel değil. Örneğin, Metro Arayüzü ya da diğer yeni API'ler yeterince popüler olmadıkça bunlara fazlaca vakit ayırmaya gerek yok. Eğer birisi gerçekten isterse bir Windows 8 Metro Teması yapabilir. Yine de böylesi bir arayüzü seven çok kişi olduğundan emin değilim. Windows 10 ya da Windows 8'e eklenmiş çok fazla değer görmüyorum.” diyor Bragin.

Her neyse, alpha sürümüyle birlikte ReactOS ivme kazanmışa benziyor. Hedefi hala zoruluklarla karşı karşıya.

Not: Tercümeyi tek seferde bitirme inadım sonucunda bir ya da iki cümleyi anlamakta epey zorlandığımdan anlam bütünlüğünü bozmayacak şekilde yazıdan çıkardım, yine bir kaç cümlede birebir çeviriden sakındım.
Lisans: Bu metin CC by-SA 4.0 ya da sonrası altında dağıtılan “ReactOS: Building a Free-Licensed Windows” metninden tercüme edilmiştir. Özgün metin Bruce Byfield tarafından yazılmıştır. Tercüme CC by-SA 4.0 ya da sonrası altında tekrar lisanslanmıştır.

31 Mart 2016

Posted In: Açık kaynak, free software, linuxgezegeni, microsoft, open source, Özgür yazılım, reactos, röportaj, tercüme, windows

ReactOS: Özgür lisanslı Windows inşa etmek

Çoklu önyüklemeden WINE’a, özgür yazılım, Windows uygulamalarını çalıştırmak için hep bir çözüm üretmeye çalıştı. Yine de bu çabaların sadece birkaçı Windows’un özgür lisanslı uyarlaması olan ReactOS kadar hırslı olabildi. Tasarı 2006’dan beri faal ve on yıllık zorlu ve ihtiyatlı geliştirmenin ardından Şubat 2016’da ilk alpha sürümü piyasaya çıktı. Geliştirici Ziliang Guo’ya göre özgür lisanslı Windows … Okumaya devam et "ReactOS: Özgür lisanslı Windows inşa etmek"

30 Mart 2016

Posted In: Açık kaynak, free software, linuxgezegeni, microsoft, open source, Özgür yazılım, reactos, röportaj, tercüme, windows

Özgür müyüz, Değil miyiz?

PC Labs, sürekli yeni haber ve makaleler yayınlayan, belki de bu sebeple hemen her gün mutlaka ziyaret ettiğim güzel bir internet sitesi. Okuduğum kimi yazılar bana hayli sıradan gelirken bazı konular ise müthiş ilgimi çekiyor ve beni düşünmeye sevk ediyor. Bu bağlantıda okuduğum bir makale de beynimin hücrelerini kaşındıran bir türde…Yazıda 390.000 kişi gibi devasa bir […]

26 Nisan 2011

Posted In: Apple, Kapitalizm, linux, Mac, microsoft, özgürlük, pardus, PC, Seçim, Serbest Piyasa, Standart, Tercih, Toplum, ubuntu, windows, yazılım

Pencereler ile Elma’nın Kavgası

Elinin tuttuğu, gözünün gördüğü her şeyin patentini almaya çalışan Apple’ın, son olarak da App Store’u markalaştırmak istemesine tepki gösteren firmalar arasına Microsoft da katıldı. Microsoft Ocak ayında bu durum için mahkemeye başvurmuş ve “App Store”un çok geniş bir isim olduğunu ve markalaştırılmaması gerektiğini belirtmişti. Apple ise App Store ifadesinin, Microsoft’un yorumladığı gibi “süper market” anlamında […]

5 Mart 2011

Posted In: App Store, Apple, linux, Lisans, Marka, microsoft, Özgür, pardus, Patent

Güvenli Kod Yazımı

Evet arkadaşlar uzun zamandır yazamıyordum. Bunun nedeni uzun zamandır projelerle uğraşıyor olmam. Bugün sizlerle projelerimi yaparken rapor olarak yazdığım nasıl güvenli kod yazılır adlı raporumu paylaşacağım. Verilen örnekler biraz .NET platformu üzerinden ama herkes için yararlı olacağını düşünüyorum.


Güvenlik çok yönlü bir olaydır ve güvenlik riskleri her yerde olabilir. Belki kötü bir hata denetim kodu, belki çok geniş bir yetkilendirme, belki de server üzerinde hangi servislerin çalıştığının unutulması  Bu liste böyle uzar gider ve yazımızın amacı da buradan çıkar Burada bizim amacımız en çok yapılan yazılım hatalarını incelemek ve bu hatalara karşı ne gibi önlemler alabileceğimizi öğrenmektir. Unutmayalım ki bunlar sadece güvenli kod yazabilmek için ilk adımlarımızdır. Bunların dışında yüzlerce farklı saldırı tekniği ve korunma metodu vardır. Bunların hepsini uygulasak dahi aklımızdan çıkarmamız gereken bir husus daha vardır. Asla güvenli kod yoktur. Çünkü saldırganlar her geçen gün saldırı tekniklerini değiştirmekte ve farklı saldırılarla sistemlerimize ve kodlarımıza saldırmaktadırlar.

Olası Güvenlik Riskleri

1)SQL Injection

SQL Injection hala daha görülebilecek en büyük açıklıklardan biridir. Kullanıcı verisine dayanan bir atak türüdür. Bu atak türü genellikle kod yazanların SQL Injectionı tam anlamıyla anlamadıkları için başlarına gelir. Peki nedir bu SQL injection. Bunu anlayabilmemiz için once SQL in ne olduğunu bilmemiz gerekir. SQL veritabanıyla anlaşmamızı ve verileri veritabanından çekip üzerlerinde işlem yapmamızı sağlayan bir dildir. Bir nevi biz insanların veritabanıyla konuşup anlaşma şeklidir. SQL Injectionı ise kullanıcının söylediği sözlerin veritabanına biraz değiştirilmiş şekliyle yansıtılması olarak tanımlarsak yanlış tanımlamış olmayız. Buna gore de veri tabanının bize vereceği değer değişecektir ki kötü niyetli son kullanıcılar bu yapıdan faydalanarak istenmeyen olaylara maruz bırakabilir bizi. SQL Injectionı biraz kavradıktan sonra bir tane gerçek örnek üzerinde durumu konuşalım.
Aşağıdaki gibi bir SQL sorgumuz olsun

Select * from kullanıcılar where username=$uname AND password=$pass

$uname ve $pass kısımlarını kullanıcıdan alıyoruz. Burada eğer kullanıcı bize gerçek değerleri verip giriş yaparsa bunda hiçbir sorun yok. Ama eğer kullanıcı adı ve şifre yerine özel bir takım karakterler yazarak girişi sağlayabilirsek işte o anda yetkisiz olarak verilere ulaşabiliriz. Username ve pass için bir SQL injection denemesi yaparak neler olabileceğini inceleyelim. Eğer usename ya da pass yerine “OR” yazarsak yetkisiz olarak giriş yapabiliriz ve system içerisinde kullanıcı yetkilere gore gönlümüzce dolaşabilriz.

Select * from kullanıcılar where uname =”OR”=” AND pass=”OR”=”

2)Cross Side Scripting

Cross Side Scripting kısaca, HTML ve Javascript yardımıyla bir sitede, siteye giren kullanıcıya tehlike arz edecek şekilde kod çalıştırmaya denir. Temel olarak kullanıcıların bilgilerini çalmayı amaçlar. Cross Side Scripting de SQL Injection gibi kullanıcı verilerine dayanan bir saldırı türüdür.

3)Broken Authentication and Session Management
   
Tam olarak güvenliği sağlanmamış ( örneğin md5 veya benzeri bir algoritma ile korunmamış) oturum nesnenleri ve çerezlerinin ele geçirilip kötü amaçlar için kullanılmasıdır. Organizasyonlar için önerilen şeyse developerlarına güçlü authentication ve session management control sağlamasıdır.

4)Insecure Direct Object References
   
Herhangi bir kontrol mekanızması olmadan kod içerisinden bir dosyanın include edilmesi, direk veritabanı erişim bilgilerinin saklanması ve çağrılması ve benzeri public fonksiyon erişimleri gibi hatalardır. Korunmak içinse indirect objeler kullanılmalı ve objelere erişim control altında tutulmalıdır.

5)Cross Site Request Forgery (CSRF)
   
CSRF ataklarından bir sisteme login olmuş kullanıcı tekrardan login request göndermesi için zorlanır fakat bu sefer login requestindeki bilgileri istemciye değil saldırgana aittir.
Konuyu daha iyi anlayabilmek için yine bir banka örneği vererek açıklayalım. Saldırganın amacı banka hesabımızı boşaltmaktır. Bu amaç için bir web sitesi hazırlar ve bir resim içerisine bir kod aşağıdaki gibi bir kod gömer.

http://example.com/transferFunds? amount=1500&destinationAccount=attackersAcct#“ width="0" height="0" />

Eğer kullanıcı önce bankasında bir işlem yapıp daha sonar banka sayfasını kapatmadan bu siteye girip yukarıdaki imajın bulunduğu linke tıklarsa saldırgan kurbanın bilgisayarındaki cookie bilgilerinden yararlanarak amacına ulaşabilir.

6)Security Misconfiguration
   
Güvenlik ile ilgili tanımların zayıf, yanlış veya varsayılan olarak bırakılmasından kaynaklanan saldırılardır. Örneğin evinizdkei ADSL modemleri şifrelerinin değiştirilmemesi gibi. Her cihazın default şifrelerine ( bunlara cisco, juniper vb güçlü cihazlar dahil) internetten 15 saniyede ulaşabilirsiniz.

7)Insecure Cryptographic Storage
   
Kriptolonamamış verilerin zayıf sunucularda korunması(maması). Günümüzde pek çok e-ticaret sitesi müşterilerinin bilgilerini şifrelemeden saklamaktadır. Kötü niyetli Host sahibi veya saldırgan bu bilgilere ulaşabilir. Korunmak için verytabanına kaydettiğimiz özellikle şifre gibi veriler kriptolanmış bir şekilde kaydedilmelidir.

8)Failure to Restrict URL Access
   
Erişimi kısıtlanmış sayfalara erişimlerin kontrol edilmemesidir, bu sayafalara erişen diğer sayfa ve modüllerin iyi bir şekilde izlenmemesi veya kodlama hataları vb.
Örneğin bir admin paneline bir kısıtlama koymadan link yardımıyla ulaşılabilyorsa bu çok büyük bir güvenlik riskidir.

9)Insufficient Transport Layer Protection

Uygulamalar genelde hassas mesajlar gönderilirken network trafiğini kriptolamayı başramayabilirler. Başarsalar bile zayıf algoritmalar vb şeylerle yaparlar. Burada eğer network trafiğini dinlemeyi başaran birileri varsa bizim network üzerinden ulaştırmaya çalıştığımız bütün bilgileri çalabilir.   
Bu ataklardan korunmak için böyle hassas verilerimizi güçlü bir kriptolama işleminden sonra yollamalıyız.

10)Unvalidated Redirects and Forwards
   
Bir çok web uygulamasında ilk ve son veri kontrolü yapılmaksızın yönlendirmeler yapılmaktadır. Buna en güzel örnek yıllar önce alışveriş sitelerinde ödeme sayfasına geçmeden bir önceki sayfalarda fiyatlar ve miktalar değiştirilerek ödeme sayfasına yönlendirme işlemleri idi. Kısaca uygun bir kontrol yapılmadan saldırganın bizi pishing ya da malware sitesine yönlendirmesidir.
Korunmak içinse yönlendirmelerden kaçınmalıyız. Eğer yapmak zorundaysak kullanıcılardan aldığımız veriler doğrultusunda yapmayınız.

Kodlarımızı Daha Güvenli Yapabilmek İçin 7 Öneri

1)Asla Kullanıcı Girdisine Güvenme

Bu yazıyı okuyorsanız aklınızda kalması gereken en önemli şey budur. Asla kullanıcı girdisine güvenmeyin. Çünkü saldırıların büyük bir çoğunluğu bu taraftan gelir. Eğer dış dünyadan aldığımız her verinin doğru ve kötü niyetsiz olduğuna inanırsak ilk sorunumuz orada başlar. Çünkü saldırganlar tarafından kullanılan bir çok güvenlik açığı sunucuya kendi işlerine yarayacak kötü bir mesaj göndermle kırılır.
Inputlara güvenmek ve bilgilerin doğru formda olduğuna koşulsuca inanmak buffer taşmasına, cross side scriptinge, SQL Injectiona ve bunun gibi bir çok soruna neden olabilir.

2)Buffer Taşmalarından Korunun

Buffer taşması saldırganın programa programın beklediği değerden daha büyük bir değer vermesi  sonucunda değişkenin ayrılmış olan memory alanina sığmamasıdır. Ya da programlama yaparken ufak bir gözden kaçma sonrasında da oluşabilir. Programcı ne kadar tecrübeli olursa olsun bu hatalara dikkat etmelidir. Bir buffer taşması sonucu uzaya gönderilmiş olan bir uzay gemisi parçalanmıştır. Görüldüğü gibi küçük bir olaymış gibi gözüksede sonuçları çok büyük olabiliyor. Bu kadar büyük sorunlara yol açabilmesine ragmen genellikle buffer taşmasının çözümü oldukça basittir. Genelde biraz dikkatli olarak ve alınan değerlerin aralıklarını belirleyerek üstesinden gelinebilir.
Bu olaylara mahal vermemek için yapılması gereken en önecelkli şey unsafe kodlara izin vermemektir.


3)Cross-site Scriptlerden Korunun

Croos side scriptleri webe özel güvenlik açıklarından biridir. Aşağıdaki kod parçasına bakmak istersek;


Böyle masum gibi görünen bir kodun aslında saldırıya açık bir kod bloğudur. Normlde, kullanıcı bu tür bir koda aşağıdaki gibi bir URL ile birlikte ulaşırlar:


C# yukarıdaki script kodundan aldığı verileri iyi formda ve sadece name değerinden başka bir şey almayacakmış gibi düşünür. Fakat saldırganlar bu kodu istismar ederler ve name değeri yerine tıpkı bir name değeriymiş gibi bir script girerler;


Eğer yukarıdaki adresi adres çubuğuna girersek önümüze içeriğinde hi! Yazan bir dialog box ın çıktığını görürüz. Bu ne demek peki. Bu saldırganın bizim web sitemize istediği gibi müdahale edebilmesi anlamına geliyor. Belki böylesine zararsız bir kod için çok bir önemi olmayabilir fakat bir de olaya şu açıdan bakın. Bu web sitesinin bir bankanın web sitesi olduğunu ve yazılan scriptin internet şubesine giriş butonunu etkilediğini düşünelim.




Kullanıcı giriş butonuna tıkladığı zaman aynı bankanın internet şubesi arayüzüne bağlanır gibi fakat saldırganın önceden hazırladığı bir web sitesine yönlendirir.




Web sitesi tıpkı bankanın sitesine benzediğinden kullanıcılar çoğunlukla gerçek web sitesiyle arasındaki farkı anlayamazlar ve güvendikleri için bilgilerini girmeye başlarlar. Bunun sonucunda da girilen bilgiler saldırgan tarafından ele geçirilmiş olur. Elbette bankalarımızın güvenliği bunların çok daha üstünde güvenlik tedbirleri alınarak yapılıyor fakat bu örneks durumun vahammiyetini daha iyi kavrayabilmemiz içindi.
Peki cross side scripting den kodumuzu nasıl koruyacağız. Bu olayın başımıza gelmesini engelleyebilmemiz için iki yöntem öneriliyor. İlki ve yazımızda da ilk olarak değindiğimiz konu olan asla kullanıcı girdisine güvenme ve girdinin ne içermesi gerektiğini katı bir şekilde belirle. Örneğin; bu işi gerçekleştirmek için regular expressionları kullanabiliriz. Regular expressionlarla kullanıcının girdisini kısıtlayarak bu işlemi yaparız. Aşağıdaki c# kodu bu işi nasıl yapabileceğimizi gösteriyor.

Regex r=new Regex(@”^[\w]{1,40}$”);
If(r.Match(strName).Success)
{
         //String Kısıtlara uyar
}
else
{
         //String kısıtlara uymaz
}

Bu kodumuzda regular expressionları kullanarak stringimizin 1 ile 40 alfanumerik karakterler arasında kalmasını sağlıyoruz. Kullanıcının girdisini kontrol etmenin en güvenli yolu budur. Bu işlemi terstende uygulayabilirsiniz. Yani yasak karakterleri teker teker yasaklayarak. Fakat burada unutulmaması gereken bir husus var ki bu işlem yapılırken yapacağımız ufak bir dikkatsizlik saldırı yememize neden olabilir. Bu yüzden izin verilmeyen karakterleri yasaklamak yerine izin verilen karakter olup olmadığına bakmak daha güvenli bir yoldur.
Bu saldırıları önlemenin ikinci yoluysa bu özel karakterleri daha güvenli karakterlerle değiştirme yöntemidir. Ama birinci yöntem kesinlikle daha güvenlidir.

4)Asla sa İzniyle Hareket Etme

Şimdi de biraz SQL Injectionları inceleyelim. Bilindiği gibi birçok yazılım geliştirici kullanıcılardan değer alarak very tabanı üzerinde bu değerlerle birlikte işlem yaparlar.
Aşağıdaki kodu biraz inceleyelim;

void DoQuery(string Id) {
    SqlConnection sql=new SqlConnection(@"data source=localhost;" +"user id=sa;password=password;");
    sql.Open();
    sqlstring= "SELECT hasshipped" +
            " FROM shipping WHERE id='" + Id + "'";
    SqlCommand cmd = new SqlCommand(sqlstring,sql);

Birçoğumuz yukarıdaki gibi bir kod yazmıştır muhtemelen. Fakat bize tanıdık gelen bu kod aslında o kadar da masum değil. 3 kusuru var bize tanıdık gelen bu kodun. İlk olarak, database e ulaşım system administrator(sa) hesabı kullanılarak yapılmaya çalışılmış. Sa hesabı için belirlenen mükemmel şifremiz password olarak belirlenmiş. Ama bunlara rağmen bu koddaki asıl sorun string birleştirme işlemi yaparak SQL statementı oluşturuyor olmasıdır. Bu durumda eğer kullanıcı Id değeri için 1001 yazarsa ve bu string işletilirse hiçbir sorun çıkmaz ve muhtemel olarak aşağıdaki gibi bir kod işletilir.

SELECT hasshipped FROM shipping WHERE id = '1001'

Maalesefki saldırganlar bu kadar iyi niyetli değil. Id=1001 yazmak yerine aşağıdaki gibi bir kod işletmeyi deneyebilirler;
SELECT hasshipped FROM
shipping WHERE id = '1001' 
DROP table shipping -- ';

Yukarıdaki sorgu istediğimiz select işlemini yapıyor olmasına rağmen devamında gelen kodlar sayesinde shipping tablosunuda siliyoruz ki bu istemediğmiz bir olay. – operatorü sayesinde sonrasında gelen kodlar yorumlanmıyor. Biraz once sa olarak veri tabanına bağlanmıştık ve şimdide bir tablo sildik. Peki bu tür bir olay sadece select yetkisi verilmiş bir username ile veritabanına bağlanılmış olsaydı başımıza gelirmiydi. Cevap çok basit tabiki hayır. Bu yüzden veri tabanına bağlanırken dikkat edilmesi gereken en önemli konulardan biri veri tabanına asla system administrator yetkisiyle bağlanmamaktır.
Peki nasıl SQL Injection yemekten koruyabilriz kodumuzu. Bunun için dinamik sql kodları kulanmak yerine stored procedure lar kullanmak en akıllıca olan yollardan biridir. Tabiki yine bir numaralı altın kuralımızı unutmayarak kullanıcı girdilerinin istediğimiz formatta olup olmadığını da control etmeliyiz. Örnek kod;

Regex r = new Regex(@"^\d{4,10}$");
if (!r.Match(Id).Success)
    throw new Exception("Invalid ID");

SqlConnection sqlConn= new SqlConnection(strConn);
string str="sp_HasShipped";
SqlCommand cmd = new SqlCommand(str,sqlConn);
cmd.CommandType = CommandType.StoredProcedure;
cmd.Parameters.Add("@ID",Id);

Unutmayalımki cross-side scripting, buffer overruns ve SQL Injection ların hepsi kullanıcı girdisine güvenme sonrasında çıkmıştır. Bu yüzden altın kuralımızı her zaman hatırlamalıyız.

5)Asla Kendi Ürettiğin Encryption Sistemini Kullanma

Eğer bir kriptolama işlemi yapıcaksanız asla kendi ürettiğiniz kripto algoritmasını uygulayarak yapmayın. Pek çok insan kendi ürettikleri kripto algoritmalarının kırılmasının çok zor olduğunu düşünerek bu tür bir yolu seçerler fakat yanıldıkları en büyük nokta kriptoladıkları kodların muhtemelen birkaç dakika içerisinde kırılabilecek düzeyde olmasıdır. Bu yüden c# dilinde kriptolama işlemi yapacaksak kripto kütüphanelerini kullanmamız daha iyi sonuçlar doğuracaktır.


6)Least Privilage Prensibine Uyun

İşletim sistemleri ve common language runtime(C# kodumuzun makine diline çevirildiği yer) bir çok nedenden dolayı güvenlik prensiplerine sahiptir. Bunun da temel amacı kullanıcıların erişime yetkisi olmayan yerlerde verilere ulaşmalarını engellemek ve kötü niyetli kişilerin veriliremizle oynamasını engellemektir ve genellikle bunu serilization işlemlerini engelleyerek yaparlar. Güvenlik prensiplerini kodumuzu çevreleyen bir duvar şeklinde düşünebiliriz. Erişime izni olanları içeriye alır, izni olmayanları duvar dışında bırakır.
Yukarıda söylediğim güvenlik prensipleri dışında bize düşen bazı görevler daha vardır. Burada asıl amaç hiçbir zaman gereğinden fazla yetkiyi vermemektir. Şöyle bir örnek düşünelim;
Elimizde veritabanımızdaki verileri gösteren bir yapı olsun. Burada amacımızı gerçekleştirebilmemiz için bize sadece vritabanımızdan select yetkisi almış olan bir connection yetecektir. Çünkü tüm yapmak istediğimiz verileri veritabanından çekmektir. Eğer bir şekilde kötü niyetli bir kişi web sayfamızın diger açıklarından faydalanıp oynamalar yapmaya çalışıyorsa tek yapabileceği bizim kullanıcılara göstermiş olduğumuz verileri alabilmektir. Asla veriler üzerinde değişiklik yapamaz. Ama bu örneğimizde veritabanına erişim yetkimizi sadece select olarak değilde update ve delete de dahil olacak şekilde bir yetki vermiş olsaydık işte o zaman kötü niyetli saldırgan verilerimizi değiştirebilr ve bizim istediğimiz verilerimizi sergilememizi engeleyebilirdi. Hatta ve hatta daha ileriye giderek veritabanımızdaki verilerimizi silebilirdi bile.
İşte yukarıdaki gibi durumlara maruz kalmamak için her zaman işlerimizi yapabileceğimiz en düşük yetki seviyesinde yapmalıyız. Her zaman least privilege ilkesine uymalıyız.

7)Hata Denetimine Yeterli Önemi Ver

Bu yazıyı okuduğunuza gore kod yazma işine bir tarafından dahil olduğunuzu düşünüyorum. Hepimiz kod yazıyoruz öyle değil mi? Peki kaçımız bu yazdığımız kodların test kısmına gerekli önemi veriyoruz ya da error handling mekanizmalarını yeterince kullanıyoruz. Bu üzerinde genellikle yüzeysel olarak durduğumuz konulardan. Oysaki en az yukarıda konuştuğumuz durumlar kadar önemli bir durum bu.
Test edilmeden kullanılan programlar genelde büyük güvenlik açıklarına sahiptirler. Bu güvenlik açıklarına maruz kalmamak için kodlarımızın test bölümüne yeterli önemi vermeliyiz. Elbetteki bütün şartlar için test edemeyiz fakat ne kadar çok test yaparsak ileride programımızın çökme olasılığı da o derecede iner. Ne kadar az test yaparsakta güvenliğin temel ilkelerinden olan sürdürülebilirliği sağlamamız da o derece zorlaşır.
Bir de kodlarımızı yazarken error handling sağlayabilmemiz için gerekli yerlerde try-catch bloklarını koymaya özen göstermeliyiz. Olağan dışı oluşan durumlarda ya da olası olusabilecek hatalarda programımızın çökmesi ya da yanlış çalışması yerine bir uyarı mesajı vererek progamımızın güvenilirliğini artırmamızı sağlar.

Kaynaklar








30 Aralık 2010

Posted In: Gezegen, Guncel ve Teknoloji, microsoft

Twitter Auto Publish Powered By : XYZScripts.com