Daha önce Linux Akademi’nin Blog’unda Ossec (HIDS) Kurulumu ve Yapılandırma‘sını anlatan bir döküman yayınlamıştım. İlgili dökümandan hareketle kurulan Ossec sistemlerinde, agent’lar üzerinde yapılacak dosya bütünlük kontrolü, rootkit tespiti ve log monitoring gibi işlemlerde hangi dosya/dizinlerin izleneceği vs. gibi tüm yapılandırma işlemleri default olarak uzak host üzerinde bulunan ossec yapılandırma dosyası üzerinde tanımlanmaktadır. Bu durum monitor ettiğiniz hostlarda tek tek düzenleme yapılması anlamına geldiği için özellikle fazla sayıda host’u monitor etmek iş gücü anlamında maliyetli bir durum oluşturmaktadır. Böylesi bir durumda agent yapılandırmalarını merkezi olarak düzenleyebilmek isteyebilirsiniz.  İşte bu sebeple Ossec, syscheck (dosya bütünlük kontrolü) rootkit tespiti ve log monitoring tanımlamalarının merkezi yapılabilmesine olanak sağlamaktadır.

Yazinin devami icin tiklayin.

auditd,  *nix sistemlerde özellikle güvenlik ile ilgili olayların derinlemesine incelenmesi ve raporlanması için kullanılan ve RedHat tarafından geliştirilen çok gelişmiş bir denetleme mekanizmasıdır. auditd ile herhangi bir dosya bütünlük kontrolü aracının yaptığına benzer şekilde sistem dosyalarında meydana gelen değişiklikler takip edilebildiği gibi kernel seviyesinde çalışmasından mütevellit daha derinlere inilerek herhangi bir sistem çağrısının neden olduğu değişiklikler de takip edilerek detaylı olarak loglanabilmektedir.

Bu anlamda Linux ya da Unix sistemlerde olup bitenle ilgili detaylı analiz yapılması gereken noktalarda auditd oldukça işe yaramaktadır. Zira, hangi dosyanın ne zaman kim tarafından değiştirildiğinden, belirli sistem çağrılarının sistemde meydana getirdiği değişiklikleri detaylı olarak analiz edilebilmesi, “sızılmış” bir sisteme hangi yollar ile girildiği ve sistemde ne gibi değişiklikler yapıldığı, arka kapı bırakılıp bırakılmadığının tespiti gibi konuların aydınlatılması açısından oldukça faydalı bir durumdur.

Yazının devamında, auditd ile ilgili detaylı bilgi bulabilir, kurulumu ve yapılandırması ile ilgili notlara erişebilirsiniz… Yazinin devami icin tiklayin.

Bu makaleyi, Linux Akademi blog’unda Ossec (HIDS ) Kurulumu ve Yapılandırması ismi ile yayınlamıştım; şimdi Syslogs üzerinden de yayınlıyorum.

Özellikle dağıtık yapılarda, sunucu güvenliği konusunda süreklilik sağlamak en önemli noktalardan birisidir. Zira, tüm sistemlerin bir şekilde izlenmesi ve olası anormalliklerin hemen tespit edilip müdahale edilmesi proaktif sistem yönetiminin başlıca kurallarından birisidir. Bu noktada network trafiğini izleyerek saldırı tespiti yapmanın yanı sıra her bir sunucu/cihaz üzerinde de bir HIDS (host-based intrusion detection) uygulaması kullanarak log monitoring, dosya bütünlük kontrolü ve rootkit tespiti gibi genel işlemler gerçekleştirilmelidir.

İşte bu yazıda, bahsedilen bu ihtiyacı karşılamak üzere OSSEC isimli HIDS uygulamasından bahsedip, server/client mimarisi ile kurulumunu ve yapılandırmasını anlatacağım.

Yazinin devami icin tiklayin.

Öntanımlı olarak sendmail kullanan sistemlerde, localhost’u kullanarak email gönderimi yapan (örneğin üyelik mailleri gönderen bir web sitesi gibi)  bir uygulama çalışıyorsa, giden mailleri localhost yerine, işi sadece email göndermek olan bir SMTP sunucusu/servisi üzerinden iletmek isteyebilirsiniz. Bunun için sendmail’de “dışarı” giden her postayı belirlediğiniz smtp sunucusu üzerinden göndermesi için SMART_HOST tanımlaması yapabilirsiniz.

Aşağıda, FreeBSD sistemlerde bu tanımlamanın nasıl yapıldığına değineceğim.

Yazinin devami icin tiklayin.

OTRS, bu zamana kadar rastladığım ve kurcaladığım ticket sistemleri içerisinde en çok beğendiklerimin başında geliyor. Özellikle e-mail üzerinden iş takibi yapan ve destek veren departmanlar için oldukça kullanışlı bir uygulama. Apache, PHP ve MySQL (ya da PostgreSQL) üzerinde çalışmakta olan OTRS’nin bir çok gelişmiş özelliği var.

Bir ticket sistemine ihtiyaç duyuyorsanız yazının devamında yer alan uygulama detaylarına ve CentOS sistemler için kurulum ve yapılandırma notlarına göz atmak isteyebilirsiniz.
Yazinin devami icin tiklayin.

Bildiğiniz gibi HAProxy isimli küçük ve kullanışlı bir load balancer uygulaması bulunuyor. Hemen her *nix sistemde çalışan bu balancer HTTP’nin yanı sıra TCP üzerinde çalışan diğer servisler için de kullanılabildiğinden ötürü sadece web servislerini değil tcp üzerinde çalışan hemen her türlü uygulama için yük dengelemesi yapabiliyorsunuz.

Kolay kurulumu ve yapılandırılması, yüksek load değerlerinde stabil olarak çalışabilmesi, web tabanlı durum ve istatistik raporu sunması, Access Contol List ve Pattern extraction desteği sayesinde detaylı koşullar belirlemeye olanak sağlaması gibi güzel özellikleri bulunuyor. Üstelik Haproxy’nin, Fedora, Twitter, Reddit, GitHub gibi kullanıcıları da bulunuyor.

Ben Haproxy’yi, giden mailleri birden fazla smtp sunucuya eşit olarak dağıtmak, böylece outbound smtp trafiği için dağıtık bir yapı oluşturmak üzere kullanıyorum. Sizin de buna benzer bir ihtiyacınız  yazının devamında HAProxy kurulumu ve 4 smtp sunucusu için round-robin load balance servisi verecek şekilde yapılandırılmasından bahsedeceğim. İşinize yarayabilir.
Yazinin devami icin tiklayin.

Nagios, host’ların up olup olmadığını kontrol etmek için ICMP üzerinde çalışan check_ping komutunu kullandığından dolayı, bir nedenden ötürü ICMP erişimi kapalı sistemlerin up/down kontrolleri bu yolla yapılamaz.

Bu gibi durumlarda izleyebileceğiniz iki yol bulunuyor. Birincisi en kolay yoldan sisteme ICMP üzerinden erişimi sağlamak, ikincisi de özellikle ICMP erişimini sağlamak kendi kontrolünüzde değilse check_host_alive işlemini ICMP yerine açık olduğunu bildiğiniz herhangi bir TCP portu üzerinden yapmaktır. Örnek olarak, hostun up olduğunu anlamak için nrpe (ya da nsclient++) portunu (tcp 5666) check edebilirsiniz.

Ben bu gibi ihtiyaçlar için Nagios’a check-host-alive-noicmp-nrpe ismi ile bir komut ve template ekliyorum, böylece ICMP üzerinden erişilemeyen hostları bu template ile monitor edebiliyorum.

Yazının devamında, bu işlem için gerekli nagios’a eklenecek yapılandırma bilgilerini bulabilirsiniz.

Yazinin devami icin tiklayin.

Gönderdiğiniz maillerin gerçekten sizin tarafınızdan gönderildiğini ispat etmeye yönelik bir kimlik doğrulama metodu olan DKIM konusuna önceki bir yazımda değinmiş ve qmail sunucularda giden maillerin DKIM (DomainKeys Identified Mail) ile imzalanmasının nasıl sağlanabileceğini anlatmıştım. Özellikle toplu mail gönderileri yapıyorsanız maillerinize mutlaka uygulanması gereken DKIM bildiğiniz gibi Domainkeys denilen bir diğer kimlik doğrulama metodunun geliştirilmiş ve yaygın olarak kullanılan versiyonudur.

DKIM ile DomainKeys aynı şeyi amaçlayıp aynı teknolojiyi kullanıyor olsalar ve sadece DKIM kullanmak yeterli gibi görünse de gönderdiğiniz mailleri hem DKIM hem de Domainkeys ile imzalamak elbette daha iyi olacaktır. Zira bazı sistemlerde sadece DKIM doğrulaması yapılırken bazılarında sadece DomainKeys kullanılıyor olabilir. Bu nedenle her iki yöntemi kullanarak yapılan imzalama, iki yöntemden sadece birini kullanan alıcı sistemlerle de iyi geçinmek anlamına gelir. Yazının devamında, daha önceki yazıma ek olarak qmail sistemlerde giden maillerin DKIM’in yanı sıra DomainKeys kullanılarak da imzalanmasından bahsedeceğim.

Yazinin devami icin tiklayin.