Geçenlerde ISC‘de, networklerdeki rogue gatewaylerin nmap ile nasıl tespit edilebileceğini anlatan güzel bir yazı yayınlandı. [1] Buna göre, nmap’in ip-forwarding scriptini kullanarak networkteki cihazların her birine özel bir icmp-ehco requesti gönderip, dönen cevaplardan ip forwarding’i etkin olan yani üzerinden trafik geçirebilecek durumda olan cihazları bulabiliyorsunuz. Bir başka deyişle, böyle bir taramada default gateway’iniz dışında ip forwarding’i açık olan bir cihaz listelenirse, ağınızda kontrolünüz dışında bir çıkış kapısı daha var demek olabilir ki arp poisoning ile tüm trafik bu noktadan geçiyor ve bu şekilde networkünüz sniff ediliyor bile olabilir.

Yukarıdaki örnek bir senaryo olsa da özellikle raspberry pi gibi küçük bilgisayarların networklerde arka kapı oluşturmak için kolayca kullanılabileceği bilindiğinden aslında pek de hafife alınacak bir konu değildir.

Netwörküzde böyle bir tarama yapmak için ip-forwarding scriptini şu şekilde kullanabilirsiniz:

nmap -sn 10.0.0.0/24 --script ip-forwarding --script-args="target=www.google.com"

Bu komuta göre öncelikle 10.0.0.0/24 networkünde ping scan yapılacak ve up durumdaki hostlar tespit edilecektir. Sonrasında da bu hostlara ip-forwarding scripti kullanılarak www.google.com için özel bir icmp-echo paketi gönderilecek ve ip forwarding yapan host var ise aşağıdaki gibi listelenecektir:

Nmap scan report for 10.0.0.98
Host is up (0.047s latency).
MAC Address: F4:6D:04:9D:92:ED (Asustek Computer)

Host script results:
| ip-forwarding:
|_  The host has ip forwarding enabled, tried ping against (www.google.com)

Bu şekilde de default gateway’iniz dışında ip forwarding yapan makinaları tespit etmeniz mümkün olacaktır.

Yazının orjinali şurada mevcut; detaylar için gözatabilirsiniz:

[1] http://isc.sans.edu/diary/Do+you+have+rogue+Internet+gateways+in+your+network+Check+it+with+nmap/16198

FreeBSD 9.1’in bootonly ISO’su yaklaşık 140 MB ebatında olduğu için hızlıca CD’den çalışan bir FreeBSD sistem elde etmek için full kuruluma göre epey ideal.

Aynı zamanda sistemi boot ettikten sonra network üzerinden (ftp vs.) tam kurulum da yapabiliyorsunuz. Normal kurulumdan tek farkı sistem için gerekli dosyaları media yerine internetten almak olduğundan, hem minimal kurulumlar için hem de uzun uzadıya cd ya da dvd imajları ile uğraşmak zorunda kalmadığınız için pratik bir yol.  Bu yüzden FreeBSD kurmam icap ettiğinde hep bootonly iso’su üzerinden kurulum yapıyorum. Sizin de benzer bir ihtiyacınız varsa aşağıdaki yönergeleri izleyerek kurulumu gerçekleştirebilirsiniz.

Yazinin devami icin tiklayin.

Amazon AWS üzerinde bir ec2 micro instance’ım var. Bu sunucu sadece 615 MB memory’e sahip olduğu için üzerinde koşan uygulamalara ram’i damlalıkla vermek icap ediyor. Böyle durumlarda oldukça lightweight olmasından ötürü Nginx kullanmak mantıklı bir seçim olabilir. Nginx özellikle static content serve etmek konusunda oldukça başarılı ve reverse proxy olarak da yaygın olarak kullanılıyor. Ayrıca, php konusunda da php-fpm üzerinden epey iyi iş çıkarıyor.

Sonuç olarak kaynaksızlıktan kırılan zavallı bir sunucunuz varsa nginx kullanmayı deneyebilirsiniz. Aşağıda centos 6.4 üzerinde php ve mysql destekli bir nginx kurulumunun nasıl yapılabileceğini bulabilirsiniz.

Yazinin devami icin tiklayin.

Uzun zamandır yazdığım scriptleri vs. muhafaza etmek için git kullanıyorum. Git, hem hafif hem de kullanışlı olması açısından development ile alakası yönetimsel scriptler yazmaktan öteye gitmeye sistem adminleri için de ideal.

Kodlarınızı, bitbucket vs. gibi private git repository hizmeti veren online servisler üzerinde depolayabileceğiniz gibi benim yaptığım gibi mütevazi bir vps üzerinde kendi git sunucunuzu çalıştırabilirsiniz. Bu yazıda CentOS 6.4 üzerinde git sunucu kurulumu ve git depolarına http üzerinden erişim sağlamak üzere gitweb kurulumu ve apache entegrasyonundan bahsedeceğim.

Yazinin devami icin tiklayin.

Apache üzerinde performansa direk etkisi olan en önemli konulardan birisi de “AllowOverride” direktifi ile devreye alınan htaccess kullanımıdır. Directory ya da vhost bazlı yapılandırma işlerinde oldukça kolaylık sağlayan bir özellik olmasına rağmen, bilindiği gibi AllowOverride direktifi None dışındaki bir değere set edildiğinde, apache kök dizini ve tüm alt dizinlerde .htaccess dosyası arayıp genel yapılandırmayı override edecek herhangi bir yapılandırma direktifi olup olmadığını kontrol eder. Özellikle çok sayıda alt dizinden oluşan bir klasör yapısı olan durumlarda performansa doğrudan etkisi olur.

Yukarıda bahsettiğim bu nedenden ötürü apache ile ilgili performans tavsiyelerinde mümkünse htaccess kullanımından tamamen kaçınılması, bunun yerine .htaccess içerisinde tanımlanması gereken direktifleri doğrudan ana yapılandırma dosyasında Directory blokları içerisinde belirtilmesi  önerilmektedir. Elbette ana yapılandırma dosyalarına erişemeyen vhost sahipleri için AllowOverride direktifini kullanmanız elzem olabilir ancak böyle bir ihtiyaç yoksa bu direktifi None yapabilir ve  apache’nin bahsi geçen .htaccess arama işi ile uğraşmasının önüne geçebilirsiniz.

 Yazının başlığında bahsettiğim htacess combiner da sunucunuzda halihazırda htaccess dosyaları olması durumunda (örnek olarak birden çok wordpress, drupal vs. gibi cms yayınlanıyorsa), tüm htaccess içeriklerini okuyarak hepsini kombine eden ve ana yapılandırma dosyanıza (httpd.conf vs.) ekleyebileceğiniz hale getiren bir shell script. https://gist.github.com/colinmollenhour/459311 adresinde yayınlanan bu scripti web sunucunuzun en üst dizininde çalıştırdığınızda aynı dizinde .htaccess-combined isimli bir dosya oluşturarak sunucudaki tüm .htaccess dosyalarının içeriğini doğru syntax ile bu dosyaya yazıyor. Bahsi geçen bu içeriği ana yapılandırma dosyanıza ekleyip, AllowOverride direktifini de None yaparsanız (apache restart sonrası) sunucu üzerinden yük almış oluyorsunuz.

Elimde, yönettiğim bir spam gateway’e ait, yaklaşık 2 yıl öncesinden beri tutulan trafik logları mevcut. Özellikle bu tip logları uzun süre muhafaza etmek, içlerinden spam trafiğine ait bilgileri çekip istatistiki veri oluşturmak açısından faydalı oluyor. Daha önce de benzer şekilde bir istatistk yayınlamıştım.

Bugün de bahsi geçen bu log dosyalarından Temmuz 2011 –  Nisan 2013 arasında gerçekleşmiş smtp aktivitesini ve spam trafiğine ait rakamları çıkardım. İlgili sununucu  üzerinde spamassassin, clamav, qsheff ve (spamcop.net ve sorbs.net üzerinde sorgulama yapan) rblsmtpd  çalışıyor. Spam gateway öncelikle smtp source ip için  rbl’de check işlemi yapıyor ve  eğer ip block listlerde bulunmuyorsa, bağlantı kabul ediliyor. Sonraki aşama olarak da gelen eposta spamassassin + clamav ve qheff’den geçiriliyor ve spam’dir ya da değildir deniyor.

Check işlemleri iki aşamalı olduğu için İstatistiği de RBL kontrolü ve Spam kontrolü olmak üzere iki ayrı başlıkta topladım.

Yazinin devami icin tiklayin.

Veri şifreleme / imzalama işleri için GnuPG kullanıyorum ve (sık olmamakla birlikte) bazen anahtarlarımı bir bilgisayardan diğerine taşımam icap edebiliyor. Normalde gpg için kgpg vs. gibi bir frontend kullanıyorsanız anahtarların export/import işleri gui üzerinden kolaylıkla yapılabiliyor. Ancak bir masaüstü ortamınız yoksa aynı işi komut satırından yapmak için aşağıdaki native yöntem kullanılabilir.

Bu yöntemde public ve private key’i export edip transfer etmeden önce şifreliyoruz. Özel anahtar şifreli olduğundan dolayı da doğrudan erişilebilir olmuyor.

Yazinin devami icin tiklayin.

Özgür Yazılım ve Linux Günleri 2013 kapmasında verdiğim Nagios semineri ile ilgili dosyaya aşağıdaki linkte erişebilirsiniz.

http://www.syslogs.org/docs/NagiosSunumu-05.04.2013.pdf