Sunucu Güvenliği : SSL – Secure Sockets Layer

Zamanında özellikle banka poslarini kullandığım websitelerinde başımı bir hayli ağrıtmıştı SSL işleri. O zamanlar bankalar ( şimdi öyle mi bilmiyorum ) özellikler kredi kartı bilgilerinin alındığı sayfada kullanmanızı istiyorlar, sitenin geneli yerine sadece bu sayfayı kontrol ediyorlardı. Tabi bu kontrol o browserda aşağıdaki resmi görmekten ibaretti diye düşünüyorum.

ssl

Browser adres kısmında o sayfanın o sayfada SSL kullanıldığını ve kullanılmakla kalmayıp SSL’in sağlıklı çalıştığını bu şekilde anlıyoruz. Peki özellikle alışveriş sitelerinde gördüğümüz ve nihayetinde artık Google tarafindan tüm sitelerin kullanmasını tavsiye ettiği bu SSL nedir ?

SSL siteniz ile kullanıcılar arasındaki veri alışverişini sifreleyerek dışardan erişimler olursa bu verinin okunmasına engel olmak için kullanılan bir standart. Bu biraz yaptığı ise göre SSL için aslında süslü bir cümle. Çünkü SSL sadece bunu yapıyor. Siteniz için bunun da ötesinde bir güvenlik sağlamıyor. Hala XSS veya CSRF aciklariniz sitenizde olabilir. Hala acik olmamasi gereken portlariniz ornegin UFW gibi bir firewall ile kontrol edilmiyor olabilir.

Peki SSL ubuntu temelli bir sunucu da apache2 bir websitesine nasil kuruluyor?

Bunun için eskiden ( 2007-2008 yıllarından söz ediyorum ) SSL sertifikası sağlayan bir firma bulup, sitenize ait bilgileri bu siteye girerek belirli bir ücret karşılığında sertifika dosyalarını alıyordunuz. Sonra da shared bir hosting ise Cpanel veya plesk kısmından dosya ve bilgileri girerek SSL’i aktif ediyordunuz. Para vermenizin nedeni browserlarin bu ücretli SSL sertifikalarını ( özellikle IE ) tanıması gerekmesiydi. Diğer türlü “tam da güvenemediğim bir SSL sertifikası var ama girmek ister misin bu siteye” tadında bir uyarı görüyordu ziyaretçi. Bu da güvenli göstermeye çalıştığınız siteyi tam tersi kullanıcıya durduk yere sanki güvensiz gibi gösteriyordu.

Şimdi işler biraz daha ucuz ( aslında artık bedava ) ve kolay. Chrome vb. yaygın browserlar ücretsiz verilen sertifikaları da tanıyor. Benim tavsiye edeceğim ( ömrü uzun olsun ) Certbot  sitesidir.

Certbot seçtiğiniz sunucu yazılımı ve işletim sistemini seçtikten sonra sizi bir kurulum ekranına yönlendiriyor. Bu ekranda sisteme nasıl kuracaginiza dair talimatları bulabilirsiniz. Bayağı basit bir kurulumu var ubuntu sistemler için. Ben de zaten apache2 ve ubuntu 16.04 LTS ile denedim. Gayet memnun kaldım. Çünkü sizde sertifika kurulumu yaparken göreceksiniz ki apache virtualhost dosyalarına bile müdehale edip sertifika satırlarını iliskilendirmesini yapıyor bu terminal uygulaması.

Bu noktada WordPress içine SSL kuracağım nasıl yapacağım diyenler shared hostinglerinde ssh erişimi olmadığı için uzuleceklerdir. fakat hepsini biraz linux öğrenip kendi vpslerini örneğin digitalocean üzerinde açarak pratik yapmaya davet edebiliriz. aylık 5 dolar ile eskiden çok daha pahalıya patlayacak tecrübeyi edinebilirsiniz. Gerçi sadece blog yazıyorsanız bana göre google blog servisini kullanın çok daha iyi.

Kurulumu talimatları izleyip yaptığınızı ve kurulum sırasında sorulan redirect opsiyonu ile https olmayan adreslerinizi yonlendirdiginizi varsayiyorum. Peki el emeği göz nuru yaptığınız sitede hala çalışmıyorsa SSL neden ? Büyük ihtimalle yazdığınız kod içerisinde https olmayan medya ( image, object, video  …) dosyalari cagriyor olmanizdan. Evet SSL veri transferinin tamamini sifreleyerek browsera gondermek istedigi icin sizde bu medya cagrilarini http degil https ile cagirmalisiniz. O zaman sorununuz çözülecektir. WordPress gibi hazır yazilimlarda ve symfony, laravel gibi iyi frameworklerde ( kurallara uyduysaniz ) bunu yapmak çok basit zaten. Bir stackoverflow aramasina bakar.

Bu yazıda SSL’in nasıl çalıştığına ve nasıl vps, dedicated sunucunuza kurabileceginize değindim. Fakat unutmayın ki SSL demek güvenliğin tamamını sağladınız demek değil. Sunucu güvenliği ile ilgili diğer yazılarıma da mutlaka bakın.

Bir de her SSL ile ilgili türkçesini bulamadığım su haber ile ilgili sizi haberdar etmis olayim. Zira CloudFlare DDos forumlarda ataklarindan korunmak için ve pratik SSL kullanmak için pek övülmekte.

Herkese iyi çalışmalar…

Sunucu Güvenliği : UFW – Uncomplicated firewall

Sunucu güvenliği konusunda portlar önemli. Zira sisteme veri alışverişinin büyük bir bölümünü portlar aracılığı ile yapıyor. Peki portları nasıl kontrol edeceğiz ve izinlerini nasıl düzenleyeceğiz ?

Linux için aslında bu büyük bir problem değil. Çünkü kurulduğu zaman tüm dışarı çıkışlar serbest, tüm içeri girişler kapalı şekilde kuruluyor. Linuxun bu işi yaptığı ana enstrümanı da yine kendisinin bir parçası IP Tables. IP tables linux çekirdeğinin etkileşimini modifiye edilebilen çeşitli kurallarla düzenliyor. Bunu da tabi ki IPv4 ve IPv6 için yapabiliyor.

Fakat IP tables sistemci değilseniz kullanması o kadar da kolay bir yapı değil. Bence bir yazılım geliştirici ve sistemcinin ayrılmaya başladığı noktalardan birisi IP Tables olabilir. Linux çekirdeği ve etrafındaki yapılar bence tam olarak sistemci işleri. Peki yazılım geliştiriciler için sistemci olmadan yapabilecekleri bir şeyler yok mu?

Linux kapsamında bildiğim en iyi cevap UFW. Açılımı Uncomplicated Firewall yani karışık olmayan ateş duvarı. Bu basit firewall tabi ki her zaman desteklediğim üzere bir terminal aracı. GUI ile kullanılıp kullanılmadığını bilmiyorum. Terminal içinde çalışmayan guilerden de uzak durmanızı tavsiye ediyorum. Unutmayın ki her grafik arayüz sizinle verinin arasına girecek başka bir yanıltıcı unsur, başka bir sistem yükü olacak. Bu sebeble komut yazmaktan korkmayın, bir gün arayüzlerle uğraşmaktan daha hızlı olacağını göreceksiniz.

Öğüt kısmını tamamladığıma göre gelelim UFW nasıl kullanılıyor kısmına. Ubuntu server kullanıcıları için şöyle başlayalım.

Kurulumdan hemen sonra başınız ağrıdığında yardımcı olsun diye reset atmayı görelim. Öğrenmek için yaptıklarınızı resetlemeniz kolay olsun.

UFW’yi aktif hale getirmek için;

diyoruz. Haliyle durdurmak için de dışable kullanılıyor.

Gelen ve giden trafikleri de toptan kontrol etmek mümkün. Fakat bunu yaparken sunucunuza kurduğunuz SSH bağlantısı üzerinde yapmadığınıza emin olun derim. Sonra bağlantınız koparsa tekrar kapattığınız portlara erişemezsiniz. Kendi bilgisayarınızda denemek daha iyi bir fikir.

ya da engellemek için allow yerine deny kullanıyorsunuz. Bu komutları bence hiç kullanmayın. Toptan bir iş neredeyse hiç yapılmamalı. Çünkü genellikle linuxda toplu uygulamaları geriye döndürmek zordur. Kazara toptan chmod değiştirmek gibi.

Tüm portları kapalı varsaydığımız için önce web sunucumuzun ( apaçhe veya nginx gibi ) ve ssh erişimizin erişime açıldığına emin olalım.

FTP de aynı şekilde açılabiliyor. Fakat ben FTP de kullanmanızı tavsiye etmiyorum. Bunun yerine scp ve rsynç komutlarını bir başka blogda anlatacağım.

Peki işler bu kadar basit mi? Hemen bitti mi ? Tabi ki hayır. Bu noktada biraz daha derine inelim. Örneğin SSH portumuzu sunucumuzu olası bir saldırıdan korumak için değiştirdiysek ne olacak ? Tabi ki bu komut çalışmıyor. UFW, SSH için yazılmış confiğe girip portu okuyarak bu işi yapmıyor. Default portu yani 22 nolu portu kullanıyor. Port açmak komut basit tabi.

bu şekilde 22 nolu portumuzu erişime açtık. İyi güzel de bu portlara kuralları tanımlayınca sonra nasıl göreceğiz ?

Karşınıza düzenlediği kuralları çıkartacaktır. Tabi sadece ufw statüs de çalışır ama numaralı listeme yaparsak kuralı numara ile silmemiz kolay olacaktır. Kural silmek demişken;

3 nolu tanımımızı sildik. Kuralları toptan silmek için reset atmanız gerektiğini söylemiştim.

Port ayalarında değişiklikler yaptıktan sonra UFW’yi reload etmeyi unutmayın.

UFW hakkında yeni tecrübe ve bilgiler edinirsem yine bu blog kapsamında paylaşacağım. Herkese iyi çalışmalar.

Sunucu Güvenliği: CSRF – Cross Site Request Forgery

Türkçesi siteler arasında talep sahteciliğidir. XSRF olarak da kısaltılır. Çok basit anlamıyla sitenize istek gerçekten sitenizden mi geliyor sorusuna net cevap veremiyorsanız CSRF açığınız olabilir. İlk örnek olarak bir kullanıcı giriş formunun gerçekten acemi bir yazılımcının elinde GET sorgusu ile yapıldığını düşünelim. Form yaklaşık şöyle olsun.

Bu form gonderildiginde

gibi bir ürl oluşturacaktır. Peki bu ÜRL gerçekten bizim sitemizdeki giriş formu ile mi oluşturuluyor ? Yoksa başka bir websitesinden ya da client ile sitemizde çeşitli kullanıcı adı ve şifre kombinasyonlarını denemek üzere sorgu üretmek için mi gönderildi ? Haliyle beklentimiz, olması gereken formun bizim siteden gönderilmiş olması. buna emin olabilmemiz. Bunun ile ilgili alınabilecek ilk tedbir madem GET metodu ile gönderilen formlarda böyle bir risk oluşuyor, biz de POST methödü ile formu göndeririz olabilir. Bu oldukça basit, basit olduğu kadar da geçersiz bir tedbir maalesef. Zira linux terminalden curl ile bir POST yapmak şu kadar basittir:

Demek ki POST yeterli değil. Fakat gereksiz de değil tabi ki. Zira aynı browser programını kullanan iki farklı kullanıcının birbirinin parolasını görmesini de istemeyiz. Peki başka ne yapabiliriz? Giriş formları için her formda benzersiz olacak şekilde biletler oluşturabiliriz. Formdan veri geldiği zaman da bu biletleri bizim o oturum için kaydettiğimiz bilet mi değil mi kontrol ederek giriş işlemlerine devam edebiliriz. Örneğin;

Bu gizli form elemanı ile oluşturduğumuz bilet kodumuzu giriş taleplerinde değerlendirmek üzere session değişkeni olarak kaydediyoruz. Giriş talebi geldiği zaman bakalım bu kod ile bizim kaydettiğimiz aynı anlamayı deniyoruz.

Peki bu şekilde token oluşturmamız ve session ile kullanmamız güvenli mi? Hayır ama GET değerini POST yapmaktan daha ciddi bir adım attığımız kesin. Peki neden güvenli değil ? Çünkü session anahtarınız bir şekilde XSS açıkları ile veya başka bir şekilde çalınırsa sizin formunuz için üretilmiş bir bilet kodu da saldırganın eline geçmiş olur ve sistemde geçerli olur. Peki bu durumda daha fazla güvenlik için ne yapılıyor ?

İşte artık pek çok sitede gördüğünüz insan miyiz ? sorusuna geldik yani captcha ! Bu aşamaya kadar yaptığımız her şeyi koruyoruz ve artık kullanıcıların sitemizden POST methödü ile giriş yaptığını biliyor, form gönderilerinde bilet kodumuzu kontrol ediyor ve aynı zamanda sitemizde bilet kodu ile birlikte giriş denemesi ile eşleştirilen bir bilgi daha kullanıyoruz. Resim içerisinde insanların okuyabileceği şekilde yazılmış rasgele 3-6 karakter gibi. Örnek verelim;

Bu kisimda giris formu;

Artık kullanıcı oluşturduğumuz bu resmi okuyarak onayını bir form elemanına yazıyor. Bu sayede artık sitemizde her yeni istek yapmak isteyen saldırganın bilet kodumuzu çalsa da captcha yazması gerekiyor. Saldırganı biraz daha yavaşlattık. Artık bilet koduna gerçekten ihtiyacımız yok çünkü kullanıcı çaptcha ile kodu zaten yazmış oluyor. Ama method olarak POST kullanmaya devam ediyoruz.

Fakat yeterli mi ? Maalesef yine hayır. Çünkü Hindistan’da belirli meblağlar karşılığında bu çaptchaları sizin için okuyan bir takım çeteler var. Evet şaka değil insanlar size tam anlık olmasa da bu verileri okuyup para karşılığı gönderiyor. Bu yüzden kendiniz çaptcha üretmek yerine pek çok sitede gördüğünüz çaptcha servislerini kullanmanızı tavsiye ederim. Zira bu servisler sizin fazladan kod yazmanızı gerektirmeden çaptchayı deneme sayısını arttıran kullanıcı için zorlaştırıyorlar. Örneğin ilk denemesinde sadece çaptcha kutusunu işaretleten servis zamanla resim hatta ses dinleterek çaptcha onay aşamasını uzatıyor. Tabi siz de her denemede çaptcha karakterini uzatabilirdiniz ama bu sefer de başka yerlerde bolca deneme yapmış şüpheli bir kullanıcıya işin başında zor bir çaptcha sunmak için nedeniniz olmayacaktı. İşte bu servisler vpn kullanan, cookie kabul eden, virtual browser kullanan kullanıcıları genel olarak mimleyerek tüm internetin güvenliğine katkıda bulunuyorlar. Servis alternatiflerine bu adresden ulaşabilirsiniz.

Peki işimiz kullanıcı giriş formu ile bitti mi? Maalesef yine hayır. Özellikle XSS açığı bulanan bir websiteniz var ve sitenizde frame kullanımı apaçhe ayarlarınızda açıksa şöyle bir sorununuz daha var demektir. Kullanıcı şifresi değiştirme sorguları. Şöyle ki bir kullanıcınız sitenize giriş yaptı. Bir şekilde saldırgan giriş yapmış bu kullanıcıya kendi sitesini de ziyaret ettirtti. Kendi sitesinden ise daha önce üye olarak sitenizden aldığı parola değiştirme kısmının kodlarını aldı ve JS ile bu kodları masum kullanıcınıza çaktırmadan tetikleyip parolasını kendi belirlediği bir parola ile değiştirdi. Kullanıcımız yazdığınız koda göre logout olabilir ya da oturumu bittiği zaman bir daha siteye giremeyebilir. Çünkü saldırgan çoktan değiştirmiştir şifreyi.

Bu durumda ne yapmalısınız ? Benim önerim ve her zaman yaptığım şey, kullanıcınız yönetici türünde bile olsa profil bilgilerini güncellerken mutlaka şifre sormanız. Bu şekilde parolasını bilmeyen saldırgan parola güncelleme sayfasında işlem yapamayacaktır.

Artık canınız sıkıldı belki ama yine soralım peki bu yeterli mi ? Hayır. Çünkü saldırgan kullanıcı hesabını geçirmekten öte kullanıcı adına çaptcha ya da şifresini oturum sırasında tekrar girmediği yerlerde POST işlemleri yapabilir. Örneğin kullanıcılar arası mesajlaşma imkanı olan bir sitede bir kullanıcıdan diğerine mesaj göndererek spam sayfasına link gönderebilir. Bu durumda en önemli güvenlik tedbiri XSS açıklarını kapattığınıza emin olmaktır. XSS ile ilgili yazım için buraya tıklayabilirsiniz. 

CSRF saldırıları ile ilgili yeni bilgiler edinirsem bu blog kapsamında paylaşmaya devam edeceğim. Herkese iyi çalışmalar…