Hata Nasıl Ortaya Çıkıyor?

Bu zafiyet, iki farklı mimari tercihin bir araya gelmesiyle tetikleniyor: PAM (Pluggable Authentication Modules) desteği olmadan derlenmiş OpenSSH ve hafif sistemlerde yaygın olarak tercih edilen musl libc kütüphanesi.

Saldırının gerçekleşme mantığı şu üç adıma dayanır:

1. Eksik Salt Değerinin Ödünç Alınması: PAM desteği olmayan sshd, parola denetimini standart crypt() fonksiyonu üzerinden yürütür. /etc/shadow dosyasında parola alanı * olan (yani şifre belirlenmemiş, yalnızca SSH anahtarıyla girmesi planlanan) hesaplarda bir hash salt değeri bulunmaz. sshd, bu durumda sistemde geçerli bir parolası bulunan başka bir kullanıcının $5$ (SHA-256) veya $6$ (SHA-512) formatındaki salt değerini geçici olarak ödünç alır.
2. musl libc’nin Hata Kodu Üretmesi: Saldırgan, hedef hesaba oturum açarken 256 bayttan uzun (genellikle 257–1024 bayt arası) rastgele bir parola gönderir. musl libc kütüphanesindeki crypt() fonksiyonu, 256 bayt sınırını aşan girdilerde hata koruması olarak geriye doğrudan * karakterini döndürür.
3. Eşleşmenin Sağlanması ve Giriş: sshd, fonksiyondan dönen hata karakteri (*) ile /etc/shadow dosyasında parolasız hesabın karşısında duran değeri (*) karşılaştırır. İki değer birebir eşleştiği için sistem parolayı doğrulanmış kabul eder ve saldırgana anında kabuk (shell) erişimi verir.

İşlem için parola tahminine ya da brute-force denemesine gerek yoktur; doğru uzunluktaki bir dize ilk denemede girişi sağlar.

Hangi Sistemler Risk Altında, Hangileri Güvende?

Açığın ortaya çıkması için sistemin musl libc tabanlı olması ve sshd servisinin PAM olmadan çalışması gerekir.

Risk Altındaki Sistemler

• Alpine Linux: Standart openssh-server paketi PAM olmadan derlenir.
• Gömülü ve Hafif Linux Sistemleri: musl libc ile derlenmiş OpenWrt, Buildroot, Yocto kurulumları.
• Alpine Tabanlı Konteynerler: İçerisinde harici erişime açık sshd servisi barındıran Docker/Podman imajları.

Etkilenmeyen Sistemler

• AlmaLinux, CentOS, RHEL, Rocky Linux
• Ubuntu, Debian
• SUSE / openSUSE

Bu dağıtımlar varsayılan olarak glibc ve PAM (UsePAM yes) kullandığından bu açıktan etkilenmez.

Sunucunuzun Savunmasız Olduğunu Nasıl Anlarsınız?

Alpine veya musl tabanlı bir sistem yönetiyorsanız aşağıdaki komutlarla denetim yapabilirsiniz:

# 1. Parola ile giriş açık mı? (yes dönüyorsa risk)
sshd -T | grep -i passwordauthentication

# 2. Risk altındaki parolasız (*) hesapları listeleyin:
awk -F: '$2 == "*" {print $1}' /etc/shadow

# 3. Tuz ödünç verilebilecek hash'li ($5$ veya $6$) başka kullanıcı var mı?
grep -E ':\$(5|6)\$' /etc/shadow

Bu üç koşul aynı anda sağlanıyorsa sunucu doğrudan saldırıya açıktır.

Çözüm ve Alınması Gereken Önlemler

Paket Güncellemesi ve Servis Yeniden Başlatma

Kalıcı çözüm için sisteminizi güncelleyin. Paket güncellemesinden sonra çalışan sshd sürecini bellekte yenilemek için servisi yeniden başlatmak şarttır:

apk update
apk upgrade openssh
rc-service sshd restart

Güvenli Asgari Sürümler:

• Alpine v3.24: 10.3_p1-r2 veya üzeri
• Alpine v3.23: 10.2_p1-r1 veya üzeri
• Alpine v3.22: 10.0_p1-r11 veya üzeri
• Alpine v3.21: 9.9_p2-r1 veya üzeri
• Alpine Edge / Upstream: 10.6_p2-r0 (10.6p2) veya üzeri

Parola ile Girişi Kapatmak

Güncellemeyi hemen uygulayamıyorsanız geçici çözüm için SSH parola doğrulamasını tamamen kapatıp yalnızca SSH anahtarı kullanımını zorunlu kılmak zafiyeti anında bertaraf eder:

# Drop-in yapılandırma dosyası ekleyin
mkdir -p /etc/ssh/sshd_config.d
echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf

# Ana yapılandırma dosyasını güncelleyin
sed -i.bak -e '1i PasswordAuthentication no' \
  -e 's/^\(\s*PasswordAuthentication[^y#]*\)yes/\1no/i' \
  /etc/ssh/sshd_config

# Yapılandırmayı test edip servisi yeniden başlatın
sshd -t && rc-service sshd restart

Uygulamanın aktifleştiğini sshd -T | grep -i passwordauthentication komutuyla (passwordauthentication no çıktısını görerek) teyit edebilirsiniz.

Saldırı İhlal Tespiti

Sisteminizin bu açıktan yararlanılarak hedef alınıp alınmadığını anlamak için /var/log/messages dosyasındaki başarılı parola girişlerini inceleyin:

grep "Accepted password" /var/log/messages

Parolası olmaması gereken (root, alpine veya sadece anahtarla giriş yapan özel servis hesapları) bir kullanıcı adına verilmiş Accepted password for ... log kaydı görüyorsanız, sunucuya yetkisiz erişim sağlanmış demektir. Bu durumda yetki yükseltme geçmişi ve /home/*/.ssh/authorized_keys dosyaları incelenmelidir.

The post OpenSSH’de Kritik Açık! (CVE-2026-123158) Kimler Risk Altında, Nasıl Korunulur? appeared first on inetmar Hosting & Teknoloji Blog Haber Sayfası.

PHP, milyonlarca web sitesinin ve web uygulamasının temelinde çalışan en yaygın sunucu tarafı programlama dillerinden biri. Ancak PHP’nin kendi altyapısında ortaya çıkan kritik bir güvenlik açığı, yalnızca tek bir web sitesini değil, aynı sunucu üzerinde çalışan birden fazla uygulamayı da riske atabiliyor. Ekim 2026’da gündeme gelen CVE-2026-109618 ve CVE-2026-109619 numaralı açıklar, bu riskin ne kadar ciddi olabileceğini bir kez daha gösteriyor.

Araştırmacılar tarafından php2shell adıyla anılan güvenlik açıklarının, uzaktan kod çalıştırma (RCE) saldırılarına imkân verebileceği bildirildi. PHP güvenlik ekibi, iki açığı da CVSS v4.0 ölçeğinde 9,2 puanla kritik seviyede değerlendirdi. Resmî duyuruda, etkilenen ve düzeltilen sürümlerin güvenlik güncellemesiyle birlikte açıklanacağı belirtildi.

Bu yazıda PHP2Shell olarak anılan açıkların ne anlama geldiğini, PHP kullanan sunucuların neden risk altında olabileceğini ve sistem yöneticilerinin güvenliklerini artırmak için neler yapabileceğini ele alıyoruz.

PHP2Shell güvenlik açığı nedir?

PHP2Shell, CVE-2026-109618 ve CVE-2026-109619 numaralı iki kritik güvenlik açığı için araştırmacılar arasında kullanılan isimdir. Bu isim, PHP çalışan bir sunucuda uzaktan komut çalıştırılabilmesi ihtimaline işaret ediyor.

Uzaktan kod çalıştırma, bir saldırganın hedef sistemde fiziksel erişim sağlamadan veya sunucuya doğrudan giriş yapmadan kod çalıştırabilmesine olanak tanıyan güvenlik açıklarını ifade eder. Açığın koşullarına bağlı olarak saldırgan; dosya oluşturma, sistem bilgilerini toplama, zararlı yazılım indirme veya sunucu üzerindeki diğer kaynaklara erişmeye çalışma gibi eylemlerde bulunabilir.

Ancak burada önemli bir ayrım var: PHP2Shell açıklarının ayrıntılı teknik çalışma biçimi, ilk duyurular sırasında henüz yayımlanmamıştı. Bu nedenle hangi bileşenin etkilendiği, saldırının hangi koşullarda mümkün olduğu ve belirli bir yapılandırmanın gerekip gerekmediği konusunda kesin konuşmak mümkün değil. Açıkların RCE riski taşıdığına ilişkin bilgiler, teknik ayrıntılar yayımlanmadan önceki araştırmacı değerlendirmelerine dayanıyor.

PHP kullanan hangi sistemler risk altında olabilir?

PHP yalnızca özel olarak PHP ile geliştirilmiş web sitelerinde kullanılmıyor. İçerik yönetim sistemleri, e-ticaret platformları, sunucu yönetim panelleri ve bazı ticari yazılımlar da PHP çalıştırabiliyor.

Bu nedenle olası risk değerlendirmesi yapılırken yalnızca ana web sitesinin kullandığı PHP sürümüne bakmak yeterli olmayabilir.

Özellikle aşağıdaki sistemlerin kontrol edilmesi gerekiyor:

• WordPress: PHP tabanlı web siteleri ve bunların kullandığı sunucu ortamları.
• Drupal ve Joomla: PHP ile çalışan içerik yönetim sistemleri.
• Magento: PHP tabanlı e-ticaret altyapıları.
• cPanel ve Plesk: Web barındırma ve sunucu yönetimi için kullanılan kontrol panelleri.
• Özel web uygulamaları: Şirket içinde geliştirilen veya üçüncü taraflardan temin edilen PHP yazılımları.
• PHP içeren Windows yazılımları: Kendi içinde php.exe veya php-cgi.exe gibi bileşenler barındıran uygulamalar.

Burada dikkat edilmesi gereken nokta, bir yazılımın bu listede yer almasının tek başına savunmasız olduğu anlamına gelmemesidir. Gerçek risk; kullanılan PHP sürümüne, yazılımın çalışma biçimine ve açığın teknik koşullarına bağlıdır.

PHP sürümü nasıl kontrol edilir?

Bir sunucuda hangi PHP sürümünün çalıştığını belirlemek, güvenlik güncellemesi hazırlığının ilk adımlarından biridir.

SSH üzerinden erişilen Linux sunucularda aşağıdaki komut kullanılabilir:

php -v

Bu komut, komut satırında kullanılan PHP sürümünü gösterir. Ancak bazı sunucularda komut satırı PHP’si ile web uygulamalarını çalıştıran PHP sürümü farklı olabilir.

Örneğin web sitesi PHP-FPM üzerinden çalışırken terminalde görülen sürüm başka bir kuruluma ait olabilir. Bu nedenle yalnızca php -v çıktısına güvenmek yerine PHP-FPM servislerini, web sunucusu yapılandırmasını ve kullanılan paketleri de incelemek gerekir.

PHP’nin CGI modunda çalıştığı Windows sistemlerde ise uygulamanın kullandığı php-cgi.exe dosyasının sürümü ayrıca kontrol edilmelidir.

Sunucuda birden fazla PHP sürümü kuruluysa hepsinin envantere alınması önemlidir. Ayrıca barındırma panelinin kendi PHP kurulumları veya uygulamayla birlikte gelen bağımlılıklar da gözden geçirilmelidir.

PHP2Shell açıkları nasıl istismar edilebilir?

Bir güvenlik açığının istismar edilmesi, saldırganın hedef sistemde beklenmeyen bir davranış oluşturmasını ve bu davranıştan yararlanmasını içerir. RCE açıklarında amaç, hedef sunucunun saldırgan tarafından belirlenen kodları çalıştırmasını sağlamaktır.

PHP2Shell için ilk duyurular sırasında yayımlanmış doğrulanmış teknik ayrıntılar bulunmadığından, açığın hangi istek veya parametre üzerinden tetiklendiğini açıklamak mümkün değildi. Bu nedenle belirli bir URL’nin, kod parçasının veya yapılandırmanın bu açığı kesin olarak tetiklediğini iddia etmek doğru olmaz.

Bununla birlikte, PHP tabanlı sunucularda RCE saldırılarının ardından görülebilen bazı davranışlar güvenlik ekipleri için yararlı göstergeler olabilir.

Örneğin normalde web isteğini işlemekle görevli bir PHP sürecinin beklenmedik biçimde komut kabuğu, betik yorumlayıcısı veya dosya indirme aracı başlatması incelenmelidir.

Linux sistemlerde sh, bash, curl, wget, python ve perl; Windows sistemlerde ise cmd.exe, powershell.exe ve certutil.exe gibi süreçlerin PHP çalışanlarından başlatılması şüpheli olabilir. Ancak bu araçların her kullanımının zararlı olmadığı unutulmamalıdır. Meşru yönetim işlemleri de benzer süreçler oluşturabilir.

Bu nedenle süreç adı tek başına yeterli değildir. Komut satırı, işlemi başlatan üst süreç, çalışma zamanı ve sunucunun normal davranışı birlikte değerlendirilmelidir.

PHP güvenlik açığı nasıl kapatılır?

PHP2Shell gibi kritik açıklar karşısında en etkili yöntem, ilgili PHP sürümü için yayımlanan güvenlik düzeltmesini uygulamaktır. Ancak güncellemenin doğru yapılabilmesi için önce sunucunun hangi sürümü kullandığının ve bu sürümün resmî düzeltme alıp almadığının belirlenmesi gerekir.

1. Resmî güvenlik duyurusunu kontrol edin

Güncel bilgiler için PHP’nin resmî güvenlik duyuruları takip edilmelidir:

PHP resmî güvenlik duyurusu

Güncelleme yayımlandığında etkilenen sürümler, düzeltilmiş sürümler ve teknik açıklamalar bu duyuru üzerinden kontrol edilmelidir. PHP paketlerini işletim sistemi deposundan veya bir barındırma sağlayıcısından alan kullanıcılar, ilgili sağlayıcının güncellemesini de incelemelidir.

2. Güncellemeden önce yedek alın

Özellikle üretim ortamlarında PHP sürümünü değiştirmeden önce web dosyalarının, veritabanlarının ve önemli yapılandırma dosyalarının yedeği alınmalıdır.

Güncellemenin test ortamında denenmesi, kullanılan eklentilerin ve uygulamaların yeni sürümle uyumluluğunun kontrol edilmesi önerilir. Bununla birlikte kritik bir güvenlik açığı söz konusu olduğunda test süreci, gerekli güvenlik önlemlerini gereksiz yere geciktirmemelidir.

3. Destek dışı PHP sürümlerini yükseltin

Eski PHP sürümleri, güvenlik güncellemesi alamadıkları için daha büyük bir risk oluşturabilir. PHP’nin destek dışı bir sürümünü kullanan sistem yöneticileri, yalnızca tek bir açık için geçici çözüm aramak yerine desteklenen bir sürüme geçiş planlamalıdır.

Sürüm yükseltmesi hemen yapılamıyorsa sistemin internete açık olup olmadığı değerlendirilmelidir. Gerekli olmayan erişimler kapatılabilir, uygulama VPN arkasına alınabilir veya uygun bir web uygulaması güvenlik duvarıyla korunabilir. Bunlar riski azaltmaya yardımcı olsa da güvenlik yamasının yerini tutmaz.

4. Şüpheli süreçleri ve dosyaları inceleyin

Sunucuda beklenmedik süreç hareketleri görülürse yalnızca ilgili işlemi sonlandırmakla yetinilmemelidir. Web sunucusu ve PHP günlükleri korunmalı; web kök dizinindeki yeni dosyalar, olası webshell’ler, bilinmeyen kullanıcı hesapları ve zamanlanmış görevler incelenmelidir.

Bir ihlalden şüpheleniliyorsa sunucunun ağ erişimini kontrollü biçimde kısıtlamak ve olay müdahalesi sürecini başlatmak daha doğru olacaktır. Günlüklerin korunması, saldırının nasıl gerçekleştiğini anlamak ve tekrarını önlemek açısından önemlidir.

PHP2Shell saldırıları başladı mı?

İlk duyuruların yayımlandığı sırada Huntress, izlediği sistemlerde bu iki güvenlik açığının gerçek saldırılarda kullanıldığına ilişkin bir bulgu görmediğini bildirmişti. Ayrıca açıklar için doğrulanmış bir PoC yayımlanmış değildi.

Bununla birlikte, kamuya açıklanmamış güvenlik açıklarına ilişkin teknik bilgilerin sızması, saldırganların araştırmalarını hızlandırabilir. Düzeltmeler yayımlandıktan sonra saldırganların güncellemeleri inceleyerek savunmasız sistemleri belirlemeye çalışması, güvenlik alanında bilinen bir risktir.

Bu yüzden saldırıların henüz doğrulanmamış olması, sistemlerin güvenli olduğu anlamına gelmez. Özellikle internete açık sunucuların güncel tutulması ve olağan dışı süreç hareketlerinin izlenmesi gerekir.

Sonuç: PHP sunucularını güncel tutmak kritik önem taşıyor

PHP2Shell adıyla gündeme gelen CVE-2026-109618 ve CVE-2026-109619 açıkları, yaygın kullanılan bir yazılımın temel katmanında ortaya çıkan güvenlik sorunlarının ne kadar geniş bir etki alanına sahip olabileceğini gösteriyor.

Sistem yöneticileri için ilk adım, tüm PHP kurulumlarını belirlemek ve resmî güvenlik güncellemelerini takip etmek. Bunun yanında destek dışı sürümlerin internete açık olup olmadığını kontrol etmek, süreç hareketlerini izlemek ve olası bir ihlalde kullanılmak üzere günlükleri korumak da önem taşıyor.

En doğru yaklaşım, doğrulanmamış istismar yöntemlerine dayanarak tahminde bulunmak yerine resmî teknik açıklamaları izlemek ve etkilenen sürümler için yayımlanan düzeltmeleri gecikmeden uygulamaktır.

The post PHP2Shell Alarmı: Kritik Güvenlik Açıkları Sunucuları Tehdit Ediyor appeared first on inetmar Hosting & Teknoloji Blog Haber Sayfası.

Açığın en önemli özelliği, belirli WordPress sürümlerinde saldırganların herhangi bir kullanıcı hesabına ihtiyaç duymadan uzaktan kod çalıştırabilmesine (RCE) kadar ilerleyebilen bir saldırı zincirinin oluşturulabilmesi.

Üstelik söz konusu açık üçüncü parti bir eklentiden veya temadan kaynaklanmıyor. Doğrudan WordPress Core içerisinde yer alan iki farklı güvenlik açığının birlikte kullanılmasından oluşuyor.

Bu nedenle WordPress kullanan tüm site sahiplerinin sürümlerini kontrol etmesi ve gerekli güncellemeleri vakit kaybetmeden yapması önem taşıyor.

wp2shell Nedir?

wp2shell, iki farklı WordPress Core güvenlik açığının birlikte kullanılabildiği bir saldırı zincirini ifade ediyor:

• CVE-2026-63030: WordPress REST API içerisindeki batch endpoint ile ilgili bir route confusion güvenlik açığı
• CVE-2026-60137: WP_Query içerisindeki author__not_in parametresini etkileyen SQL Injection açığı

Bu açıkların birlikte kullanılması, saldırganların herhangi bir kullanıcı hesabına sahip olmadan WordPress sitelerine yönelik saldırılar gerçekleştirmesine ve saldırıyı daha ileri taşıyarak uzaktan kod çalıştırmasına olanak sağlayabiliyor.

Bu nedenle wp2shell, yalnızca bir WordPress eklentisinin güncellenmesiyle çözülebilecek sıradan bir güvenlik problemi değil, WordPress Core seviyesinde ele alınması gereken kritik bir güvenlik sorunu.

Saldırı Nasıl Gerçekleşebiliyor?

Saldırının teknik ayrıntılarına girmeden genel olarak süreç şu şekilde ilerliyor:

1. Saldırgan WordPress’in REST API’sine özel hazırlanmış bir istek gönderiyor.
2. REST API’deki güvenlik açığından yararlanılıyor.
3. SQL Injection açığı kullanılarak sistem üzerinde yetki elde edilmeye çalışılıyor.
4. Saldırgan yönetici seviyesine ulaşırsa WordPress üzerinden zararlı kod veya arka kapı yerleştirebiliyor.
5. Son aşamada site üzerinde yetkisiz işlemler gerçekleştirebiliyor.

Bu nedenle saldırganın ilk aşamada WordPress kullanıcı adı veya şifresini bilmesi gerekmeyebiliyor.

Hangi WordPress Sürümleri Risk Altında?

WordPress tarafından yayınlanan güvenlik güncellemeleriyle sorun giderildi.

Riskli sürümler:

• WordPress 6.9.0 – 6.9.4
• WordPress 7.0.0 – 7.0.1
• WordPress 6.8.0 – 6.8.5 sürümleri ise ilgili SQL Injection açığından etkileniyor.

Güvenli sürümler:

• WordPress 6.9.5
• WordPress 7.0.2
• WordPress 6.8.6

WordPress, açığın ciddiyeti nedeniyle etkilenen sürümlerde otomatik güvenlik güncellemelerini de devreye aldı.

Ancak sitenizin otomatik olarak güncellendiğini varsaymak yerine WordPress sürümünüzü kendiniz kontrol etmeniz önemlidir.

Mümkünse eski bir sürümde kalmak yerine WordPress’in desteklenen en güncel sürümünü kullanmanız önerilir.

WordPress Sitenizi Nasıl Koruyabilirsiniz?

1. WordPress’i Güncelleyin

İlk ve en önemli adım WordPress Core’u güncellemektir.

WordPress yönetim panelinizde:

Başlangıç → Güncellemeler

bölümünü kontrol ederek sitenizin güncel olup olmadığını görebilirsiniz.

2. Eklenti ve Temalarınızı Güncel Tutun

WordPress Core kadar eklenti ve temaların da güncel olması önemlidir. Kullanmadığınız veya uzun süredir güncellenmeyen eklentileri ve temaları kaldırmanız sitenizin genel saldırı yüzeyini azaltacaktır.

3. Yönetici Hesaplarınızı Kontrol Edin

WordPress panelinizde Kullanıcılar bölümünü kontrol edin. Tanımadığınız bir yönetici hesabı görürseniz hesabı hemen silin çünkü bilinmeyen bir yönetici hesabı, sitenizin daha önce ele geçirilmiş olduğuna dair önemli bir işaret olabilir.

4. Şüpheli Dosya ve Değişikliklere Dikkat Edin

Sitenizde aniden ortaya çıkan:

• Tanımadığınız PHP dosyaları
• Bilginiz dışında eklenen eklentiler
• Beklenmeyen yönlendirmeler
• Spam içerikler
• Değiştirilmiş tema veya site dosyaları

gibi durumlar fark ederseniz sitenizin güvenlik kontrolünden geçirilmesi gerekir.

5. Parolalarınızı Güçlü Tutun

WordPress yönetici hesabınızda güçlü ve benzersiz bir parola kullanın. Aynı parolayı WordPress, cPanel, FTP veya başka servislerde kullanmayın. Mümkün olan durumlarda iki aşamalı doğrulamayı (2FA) etkinleştirmeniz de hesabınızın güvenliğini önemli ölçüde artıracaktır.

Siteniz Daha Önce Saldırıya Uğramış Olabilir mi?

Burada önemli bir noktaya dikkat etmek gerekiyor:

WordPress’i bugün güncellemek, sitenizin daha önce saldırıya uğramadığını garanti etmez.

Eğer siteniz uzun süre boyunca savunmasız bir WordPress sürümü kullandıysa, saldırganlar güncellemeden önce sisteme erişmiş olabilir.

Bu nedenle güncelleme sonrasında da sitenizde;

• Bilinmeyen yönetici hesapları,
• Şüpheli eklentiler,
• Tanımadığınız dosyalar,
• Beklenmeyen yönlendirmeler,
• Spam içerikler,
• Anormal site davranışları

olup olmadığını kontrol etmek önemlidir.

Şüpheli bir durum fark ederseniz sitenizi temiz bir yedeğe döndürmek veya profesyonel bir güvenlik kontrolü yaptırmak gerekebilir.

WordPress Hosting Seçiminiz de Güvenlik Kadar Önemli

WordPress güvenliği yalnızca sitenin kendi ayarlarından ibaret değildir. Sitenin barındırıldığı sunucunun güvenlik altyapısı da oldukça önemlidir. 20 yılı aşkın sektör tecrübesine sahip İnetmar ailesi olarak WordPress siteleriniz için performans ve güvenliği birlikte hedefleyen hosting altyapıları sunuyoruz. Özellikle WordPress kullanıcıları için hazırladığımız Imunify360 destekli WordPress Hosting hizmetlerimiz ile sitelerinizi yalnızca barındırmakla kalmayıp, sunucu seviyesinde gelişmiş güvenlik katmanlarından da yararlanmanızı hedefliyoruz. WordPress siteniz için güvenli ve profesyonel bir hosting altyapısı arıyorsanız WordPress Hosting paketlerimizi tercih edebilirsiniz.

wp2shell, WordPress Core seviyesinde ortaya çıkan ve belirli sürümlerde saldırganların kimlik doğrulaması olmadan sistemlere erişmesine kadar ilerleyebilen kritik bir güvenlik açığıdır.

Bu nedenle WordPress kullanıcılarının:

Güncellemesi → Kontrol etmesi → Güvenli bir hosting altyapısı kullanması

büyük önem taşıyor.

Özellikle WordPress siteniz eski bir sürüm kullanıyorsa güncellemeyi ertelemeyin.

Unutmayın:

Güncel WordPress + güncel eklenti ve temalar + güçlü parolalar + güvenli hosting altyapısı = daha güvenli bir web sitesi

Sitenizin güvenliği konusunda herhangi bir şüpheniz varsa profesyonel destek almaktan çekinmeyin.

The post wp2shell (CVE-2026-63030): WordPress’i Sarsan Kritik RCE Zafiyeti ve Korunma Yolları! appeared first on inetmar Hosting & Teknoloji Blog Haber Sayfası.

Veri size ait değilse, işiniz de tam olarak size ait değildir. Kendi VDS altyapınız üzerinde bir mail sunucusu kurmak; bağımsızlıktır, güvenliktir ve uzun vadede devasa bir maliyet avantajıdır.

Fakat e-posta mimarisi, internetin en eski, kuralcı ve karmaşık sistemlerinden biridir. Bu yazımızda “şu kodu yaz geç” demek yerine sektörü domine eden en modern araçlarla, hata payı bırakmayan bir mühendislik yaklaşımıyla ilerliyoruz. Karmaşık IPv6 protokollerini bir kenara bırakıp, saf IPv4 gücüyle, sorunsuz teslimat oranlarına (10/10) ulaşacağınız o muazzam sistemi kurmaya başlıyoruz.

Altyapı ve DNS

İlk olarak mail sunucusu kurarken başarının %50’si sunucu konfigürasyonunda, geri kalan %50’si ise ağ altyapınızın temizliğindedir. Blacklist’e girmemiş, port kısıtlaması olmayan ve IP itibarı yüksek bir sunucu şarttır. E-posta trafiğinizin belkemiğini oluşturacak, %100 NVMe SSD performansına ve kusursuz ağ izolasyonuna sahip VDS paketlerimizi inceleyerek projenize sağlam bir temel atabilirsiniz.

DNS Kayıtları

Sunucuya SSH ile girmeden önce DNS yöneticiniz üzerinden kayıtları açın.

• A Kaydı: mail.siteniz.com -> VDS_IP_Adresi
• MX Kaydı: siteniz.com -> mail.siteniz.com (Öncelik: 10)

PTR (Reverse DNS) Kaydı Neden Hayatidir?

Normal DNS (A kaydı), “Bu alan adı hangi IP’ye gidiyor?” sorusunu cevaplar. PTR kaydı ise karşı tarafın size sorduğu şu sorunun cevabıdır: “Bu IP adresi kime ait?” Eğer Gmail IP’nizi sorguladığında boş bir cevap görürse, mailinizi direkt reddeder. inetmar.com müşteri panelinizde bulunan **Hizmetlerim > IP Adreslerim** bölümünden IP adresinizin PTR kaydını mail.siteniz.com olarak mutlaka güncelleyin.

Ana Bileşenlerin Kurulumu ve İzolasyon

Sunucumuza root olarak bağlanıyoruz. Ubuntu 24.04 LTS üzerinde sistemimizi güncelleyip Postfix ve Dovecot yazılımlarımızı kuruyoruz.

Bu kurulumda e-posta imzalama ve spam filtreleme işlemleri için eski nesil yazılımlar yerine modern, C++ tabanlı ve düşük kaynak tüketimi sunan Rspamd ve Redis kullanacağız:

apt update && apt upgrade -y
apt install postfix postfix-pcre dovecot-imapd dovecot-lmtpd redis-server rspamd certbot nginx -y

(Postfix kurulum ekranı geldiğinde “Internet Site” seçeneğiyle ilerleyin ve Sistem Mail Adı olarak siteniz.com girin.)

Sistem Kullanıcılarını Ayırmak

Mail kullanıcıları ile sunucu kullanıcılarını aynı tutmak güvensiz bir yöntemdir. Bunun için tüm mailleri diskte tutacak yetkisiz tek bir sanal kullanıcı (vmail) oluşturuyoruz:

useradd -m -s /usr/sbin/nologin -G mail vmail
mkdir -p /home/vmail/Mail/Inbox
chown -R vmail:vmail /home/vmail/Mail

Postfix (MTA) ve Dovecot (MDA) Entegrasyonu

Postfix

/etc/postfix/main.cf dosyasını yapılandırıyoruz. Amacımız IPv4 kullanımını zorunlu kılmak, dışarıdan gelen SMTP yetkilendirmelerini Dovecot’a devretmek ve şifresiz veri akışını yasaklamak. Ayrıca Postfix’i yeni nesil filtremiz Rspamd’ye bağlıyoruz.

inet_protocols = ipv4
# Şifreler ağda düz metin dolaşmasın, TLS zorunlu olsun:
smtpd_tls_auth_only = yes

# Yetkilendirmeyi Dovecot yapsın:
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes

# Hangi e-posta adresi hangi kullanıcıya ait haritası:
virtual_alias_maps = hash:/etc/postfix/virtual

# Rspamd (DKIM ve Anti-Spam) Entegrasyonu:
milter_default_action = accept
milter_protocol = 6
smtpd_milters = inet:localhost:11332
non_smtpd_milters = inet:localhost:11332

E-posta adreslerimizi /etc/postfix/virtual dosyasına tanımlıyoruz:

admin@siteniz.com   vmail
info@siteniz.com    vmail

Sisteme bu dosyayı okutmak için hash’liyoruz: postmap /etc/postfix/virtual

Dovecot

Maillerin webmail’den okunabilmesi için Dovecot’u yapılandırıyoruz. /etc/dovecot/dovecot.conf dosyasını açın:

ssl = required
# Şifrelerin tutulacağı özel dosya:
passdb {
  driver = passwd-file
  args = scheme=CRYPT /etc/dovecot/users
}
userdb {
  driver = passwd-file
  args = /etc/dovecot/users
}
# Postfix'in Dovecot üzerinden doğrulama yapabilmesi için güvenli soket:
service auth {
  unix_listener /var/spool/postfix/private/auth {
    mode = 0660
    user = postfix
    group = postfix
  }
}

/etc/dovecot/users dosyasını oluşturun. Şifrelerinizi Linux üzerinde doveadm pw -s CRYPT komutuyla şifreleyerek bu dosyaya admin@siteniz.com:{CRYPT}$2y$... formatında ekleyin. Dosya izinlerini chmod 644 /etc/dovecot/users olarak ayarlayın.

SPF, Rspamd ile DKIM, DMARC

Maillerinizin doğrudan spame düşmemesi için bu kayıtları kusursuz yapılandırmalısınız.

1. SPF (Sender Policy Framework): DNS ayarlarınız üzerinden TXT kaydı ekleyin:
v=spf1 mx a:mail.siteniz.com ip4:VDS_IPv4_Adresiniz -all

2. DKIM İmzalama:
Sunucumuzda alan adımız için DKIM anahtarımızı üretiyoruz:

mkdir -p /var/lib/rspamd/dkim/
rspamadm dkim_keygen -b 2048 -s mail -k /var/lib/rspamd/dkim/mail.private > /var/lib/rspamd/dkim/mail.txt
chown -R _rspamd:_rspamd /var/lib/rspamd/dkim/
chmod 600 /var/lib/rspamd/dkim/mail.private

Rspamd’ye bu anahtarı kullanmasını söylüyoruz. /etc/rspamd/local.d/dkim_signing.conf dosyasını oluşturup içine şunu yazın:

allow_username_mismatch = true;
domain {
    siteniz.com {
        path = "/var/lib/rspamd/dkim/mail.private";
        selector = "mail";
    }
}

Ardından servisi yeniden başlatın: systemctl restart rspamd.
Oluşturulan /var/lib/rspamd/dkim/mail.txt dosyasını açın. İçindeki uzun metni yani anahtarı DNS ayarlarınızın bulunduğu panelde mail._domainkey adıyla TXT kaydı olarak ekleyin.

3. DMARC:
DNS ayarlarınıza TXT kaydı olarak _dmarc adıyla şunu ekleyin:
v=DMARC1; p=quarantine; rua=mailto:admin@siteniz.com; fo=1

Roundcube & Docker

Güvenlik açıklarını ana sisteme sıçratmamak için Webmail arayüzümüzü Docker ile kuruyoruz. Bir dizin açın ve docker-compose.yml dosyası oluşturun:

services:
  roundcube:
    image: roundcube/roundcubemail:latest-apache
    ports:
      - "127.0.0.1:8080:80"
    environment:
      - ROUNDCUBEMAIL_DEFAULT_HOST=tls://VDS_IPv4_Adresiniz
      - ROUNDCUBEMAIL_SMTP_SERVER=tls://VDS_IPv4_Adresiniz

docker compose up -d ile arayüzü ayağa kaldırın.

Nginx ve SSL Entegrasyonu

Roundcube şu an sadece 8080 portunda çalışıyor. Let’s Encrypt ile ücretsiz SSL alıyoruz: certbot certonly --standalone -d mail.siteniz.com

Nginx /etc/nginx/sites-available/mail.siteniz.com dosyasını ayarlayarak 443 (HTTPS) üzerinden gelen trafiği güvenli şekilde Docker’a proxy’liyoruz:

server {
    listen 443 ssl;
    server_name mail.siteniz.com;
    ssl_certificate /etc/letsencrypt/live/mail.siteniz.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/mail.siteniz.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Aktifleştirip systemctl reload nginx komutunu verdiğinizde webmail arayüzünüz yayındadır!

UFW, Fail2ban ve SRS

Nasıl ki kritik bir Sanal POS entegrasyonu için sunucunuzda IP izinlerini ince ince ayarlayıp, PowerShell üzerinden bağlantının sağlıklı kurulduğunu milimetrik olarak teyit ediyorsanız; mail sunucusunda da açtığınız her portun tam olarak ne işe yaradığını aynı ciddiyetle bilmelisiniz.

Sadece gerekli olan IPv4 portlarını açıyoruz:

ufw allow 22/tcp
ufw allow 25/tcp
ufw allow 143/tcp
ufw allow 443/tcp
ufw allow 465/tcp
ufw allow 587/tcp
ufw allow 993/tcp
ufw enable

Brute-Force Koruması: systemctl enable --now fail2ban ile servisi etkinleştirin. Gerekirse şifre deneme yanılma yapan botları engellemek için postfix filtrelerini aktif edebilirsiniz.

Forwarding ve SRS

info@siteniz.com adresine gelen mailleri kişisel Gmail’inize yönlendirirseniz, orijinal göndericinin SPF kaydı sizin sunucu IP’nizle eşleşmeyeceği için Gmail maili anında reddeder.

Bunu SRS (Sender Rewriting Scheme) ile çözüyoruz.
apt install postsrsd -y komutuyla paketi kurun. Postfix main.cf dosyasına şu bloğu ekleyin:

# SRS - Forward edilen mailler için Envelope Rewrite
sender_canonical_maps = tcp:127.0.0.1:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:127.0.0.1:10002
recipient_canonical_classes = envelope_recipient,header_recipient

Bu ayar sayesinde yönlendirilen mailin “Gönderen” (Envelope Sender) bilgisi sizin alan adınıza çevrilir, kendi SPF’inizden geçer ve Gmail’in Inbox’ına sorunsuz düşer. Postfix’i yeniden başlatın (systemctl reload postfix).

Uçtan Uca Webmail Testi ve Troubleshooting

Sistemi kurduk, servisler yeşil yanıyor. Şimdi doğrulama vakti.

Webmail Arayüzüne Giriş

Tarayıcınızı açın ve https://mail.siteniz.com adresine gidin.

• Kullanıcı Adı: admin@siteniz.com (Domain ile birlikte tam e-posta adresini yazmalısınız).
• Parola: Belirlediğiniz parola ile giriş yapın.

İlk Maili Gönderme ve Gmail’de Analiz

Sol üstten “Oluştur” butonuna tıklayın. Kişisel Gmail adresinize bir test maili gönderin.
Mail Gmail kutunuza düştüğünde, maili açın, sağ üstteki üç noktaya tıklayıp “Aslını Göster” (Show Original) seçeneğine tıklayın.

İşte tüm o emeğin karşılığını burada, Rspamd’nin kusursuz imzalarıyla göreceğiz:

• SPF: PASS (IP adresiniz siteniz.com adına başarıyla yetkilendirildi)
• DKIM: PASS (Rspamd imzanız doğrulandı)
• DMARC: PASS (Kurallarınız başarıyla işletildi)

İçeriye Mail Alma ve Nihai Skor

Kişisel Gmail hesabınızdan, kendi sunucunuzdaki admin@siteniz.com adresinize mail göndererek içeriye alımı test edin.
Sonrasında hatalarımızı görmek için https://mail-tester.com adresine gidin. Verilen geçici adrese Roundcube üzerinden mail gönderin.

Adımları eksiksiz uyguladıysanız, temiz bir IP altyapısı üzerinde o muazzam 10/10 skorunu göreceksiniz!

Kendi mail sunucunuzu kurmak bir vizyon meselesidir. Rspamd gibi yeni nesil araçları kullanarak sistemi modern mimariye uygun şekilde inşa etmek, size ömür boyu sürecek bir dijital özgürlük, yüksek performans ve eşsiz bir gizlilik sunar.

Doğru konfigüre edilmiş bir sistem ve güçlü bir VDS altyapısı birleştiğinde, iletişiminiz üzerinde %100 kontrol sahibi olduğunuz, güvenilir ve stabil bir yapıya kavuşursunuz. Kurumsal iletişiminizin kalbini oluşturacak, ağ kısıtlamalarından uzak, performanslı VDS Sunucu çözümlerimizi inceleyerek bu dijital bağımsızlık yolculuğunda en sağlam adımı atabilirsiniz.

The post Mail Sunucusu Nasıl Kurulur? Mail Sunucusu Kurma appeared first on inetmar Hosting & Teknoloji Blog Haber Sayfası.

Zafiyetin Arka Planı ve Teknik Detayları

Dirty Frag aslında Linux dünyasının yabancı olmadığı bir saldırı silsilesinin son halkası. 2022’deki meşhur “Dirty Pipe” (CVE-2022-0847) ve geçtiğimiz günlerde gündeme oturan “Copy/Fail” (CVE-2026-31431) açıklarının bir devamı niteliğinde.

• Temel Mantık: Saldırganlar, çekirdeğin bir ikili dosyayı (binary) yüklerken okuduğu sayfa önbelleğini (page cache) manipüle ediyor.
• Kapsam: Linux çekirdeğinin 4.14 ve sonrası (2017’den günümüze) tüm sürümleri bu risk altında.
• Durum: 7 Mayıs 2026’da duyurulan bu açık için henüz resmi CVE kodu “Dirty Frag” özelinde güncellenme aşamasında olsa da, ana dağıtımların (Ubuntu, AlmaLinux, CloudLinux) mühendislik ekipleri konu üzerinde çalışıyor.

Etkilenen İşletim Sistemleri

Şu an itibarıyla aşağıdaki sistemlerin savunmasız olduğu teyit edilmiştir:

Geçici Çözüm

Resmi yamalar yayınlanana kadar sunucu hizmetlerinizi güvence altına almak için zafiyete kapı aralayan belirli kernel modüllerini devre dışı bırakmanız ve önbelleği temizlemeniz önerilmektedir.

1. Modülleri Devre Dışı Bırakma:

Root yetkisiyle aşağıdaki komutu çalıştırarak riskli protokollerin yüklenmesini engelleyin:

sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"

2. Sayfa Önbelleğini Temizleme:

Bellekteki olası manipülasyonları ortadan kaldırmak için önbelleği şu komutla boşaltın:

echo 3 > /proc/sys/vm/drop_caches

Önemli Not: Bu işlemler sunucunuzda IPsec (esp) veya özel RPC (rxrpc) protokollerini kullanan servisleri etkileyebilir. Uygulamadan önce servis bağımlılıklarınızı kontrol etmeniz tavsiye ederiz.

Şu an için CloudLinux ve AlmaLinux tarafında ön duyurular yapılmış durumda. Gözünüz sistem güncellemelerinde (yum update / apt upgrade) olsun resmi yamalar yayınlandığı anda bu geçici önlemleri kaldırıp kernel güncellemesini tamamlamak en kalıcı çözüm olacaktır.

The post Linux Kernel’da Kritik “Dirty Frag” Zafiyeti Tespit Edildi! appeared first on inetmar Hosting & Teknoloji Blog Haber Sayfası.

Başlıca Tehdit: CVE-2026-23918 (CVSS: 8.8)

Sistem yöneticilerini asıl alarma geçiren sorun Apache’nin HTTP/2 protokolü uygulamasında tespit edilen bir bellek bozulması (double-free) hatası. Sistem, aynı bellek bölgesini iki kez serbest bırakmaya çalıştığında bellek yapıları bozuluyor. Bu açık saldırganlara sistemin çalışma akışını kendi istedikleri yöne çekme ve doğrudan Uzaktan Kod Çalıştırma (RCE) fırsatı veriyor.

Doğrudan 2.4.66 sürümünü hedef alan bu zafiyet, dünya çapındaki kurumsal altyapılar için çok ciddi bir risk oluşturuyor. Bu güncelleme paketiyle birlikte ayrıca, sunucu kaynaklarını tüketebilen veya çökmelere (DoS) yol açabilen üç farklı düşük seviyeli açık (CVE-2026-28780, CVE-2026-29168 ve CVE-2026-29169) daha giderilmiş durumda.

Sunucunuzu Nasıl Güvenceye Alırsınız?

Bu kritik RCE zafiyetinin tek kesin çözümü vakit kaybetmeden 2.4.67 sürümüne geçiş yapmaktır. Eğer acil bir güncelleme yapma imkanınız yoksa geçici bir önlem olarak sunucunuzda HTTP/2’yi devre dışı bırakmayı değerlendirebilirsiniz. Ancak cPanel ve EasyApache 4 kullanan bir sunucu altyapısına sahipseniz bu hayati güvenlik yamasını doğrudan terminal üzerinden uygulayarak sisteminizi hızlıca koruma altına alabilirsiniz. İşletim sisteminize uygun olarak aşağıdaki adımları izlemeniz yeterlidir:

AlmaLinux Sistemler İçin:

SSH üzerinden sunucunuza root yetkisiyle bağlanın, paket önbelleğini temizleyin ve güncellemeyi başlatın:

dnf clean all
dnf makecache
dnf -y update ea-apache*


Ubuntu Sistemler İçin:

Debian/Ubuntu tabanlı bir altyapınız varsa, paket listelerinizi tazeleyip yalnızca EasyApache paketlerini hedefleyerek yükseltme işlemini şu komutlarla yapabilirsiniz:

apt update
apt install --only-upgrade "ea-apache24*"

İşlemi tamamlandıktan sonra Apache servisinizin sorunsuz bir şekilde yeniden başladığından ve sisteminizin güvenlik yamasını içeren güncel sürümde çalıştığından emin olmak için servis kontrolü (httpd -v) yapmayı unutmayın.

The post Apache HTTP Sunucularında Kritik RCE Zafiyeti! CVE-2026-23918 (CVSS: 8.8) appeared first on inetmar Hosting & Teknoloji Blog Haber Sayfası.

Bu İşlem Teknik Olarak Nasıl Mümkün?

Eskiden bu tarz işlemler pahalı ekipmanlar ve ileri düzey teknik bilgi gerektirirken, günümüzde VoIP (Voice over IP) teknolojisinin yaygınlaşmasıyla oldukça kolaylaşmıştır. İnternet üzerinden arama yapmayı sağlayan protokoller, kullanıcıya “gönderen kimliği” bilgisini manuel olarak düzenleme imkanı tanır. Basit bir yazılım veya üçüncü taraf bir uygulama aracılığıyla, sistem üzerinden herhangi bir numara sisteme arayan numara olarak tanımlanabilir.

Neden Kullanılır? İyi ve Kötü Senaryolar

Her teknoloji gibi, numara maskeleme de her zaman kötü niyetli amaçlarla kullanılmaz. Ancak madalyonun iki yüzü vardır:

1. Meşru ve Yasal Kullanımlar

• Gizlilik: Bir doktorun, hastasını kendi özel cep telefonundan ararken hastane santral numarasını göstermesi.
• Kurumsal Kimlik: Büyük şirketlerin, saha çalışanlarının aramalarını tek bir merkezi ofis numarası altında toplaması.

2. Kötü Niyetli Kullanımlar (Siber Suçlar)

• Sosyal Mühendislik: Kendini polis, savcı veya banka temsilcisi olarak tanıtarak kişisel verileri veya banka şifrelerini ele geçirme girişimi.
• Neighborhood Spoofing: Kişinin güvenini kazanmak için ona tanıdık gelen, kendi alan koduyla başlayan numaralardan arama yapılması.
• Harassment (Taciz): Gerçek kimliği gizleyerek birini rahatsız etmek veya takip etmek.

Kendinizi Nasıl Korursunuz?

Caller ID Spoofing ile mücadele etmenin en zor yanı, telefon ağlarının bu kimlik bilgilerini her zaman doğrulayamamasıdır. Ancak şu adımlar güvenliğinizi artırabilir:

• Şüpheci Yaklaşın: Beklemediğiniz bir anda gelen ve sizden kişisel bilgi, şifre veya para talep eden aramalara karşı her zaman mesafeli olun.
• Geri Arayın: Eğer arayan kişi bir banka veya resmi kurum olduğunu iddia ediyorsa, görüşmeyi sonlandırın. Kurumun resmi numarasını kendiniz tuşlayarak durumu teyit edin.
• Numara Filtreleme Uygulamaları: Güvenilir spam engelleme uygulamaları, veritabanlarındaki şüpheli numaraları sizin için işaretleyebilir.
• Paylaşmayın: Telefon üzerinden hiçbir zaman tek kullanımlık şifrelerinizi (OTP) veya tam kimlik bilgilerinizi paylaşmayın. Unutmayın; hiçbir resmi kurum sizden telefon üzerinden şifre istemez.

Özetlemek gerekirse teknoloji geliştikçe, dolandırıcılık yöntemleri de daha ikna edici hale geliyor. Caller ID Spoofing, sadece bir teknik hata değil, dijital dünyanın en yaygın manipülasyon araçlarından biridir. Ekranınızda gördüğünüz numaraya güvenmek yerine, aramanın içeriğine ve sizden istenenlere odaklanmak, en güçlü savunma mekanizmanızdır.

The post Caller ID Spoofing Nedir? appeared first on inetmar Hosting & Teknoloji Blog Haber Sayfası.

Basit bir ifadeyle DLP verinin nerede olduğunu bilen, nasıl hareket ettiğini izleyen ve riskli bir durum sezdiğinde müdahale eden dijital bir denetim mekanizmasıdır.

DLP Neden Kritik Bir Öncelik?

Kurumlar için veri kaybı, sadece teknik bir sorun değil aynı zamanda prestij kaybı, ağır para cezaları ve rekabet gücünün zayıflaması demektir. DLP çözümlerini zorunlu kılan üç temel unsur şunlardır:

• Yasal Uyumluluk: KVKK, GDPR ve HIPAA gibi düzenlemeler, kişisel verilerin korunmasını yasal bir yükümlülük haline getirir. DLP, bu regülasyonlara uyumu otomatize eder.
• Fikri Mülkiyetin Korunması: Şirket sırları, tasarım planları veya stratejik dökümanların rakip firmaların eline geçmesi, telafisi güç zararlar doğurur.
• Görünürlük: Verinin kim tarafından, hangi cihaz üzerinden ve nereye gönderildiğini anlık olarak raporlayarak kurum içindeki veri trafiğine tam hakimiyet sağlar.

VDS Sunucu Fiyatları İçin Websitemizi Ziyaret Edebilirsiniz.

Veri Güvenliğinde Üç Katmanlı Koruma

DLP sistemleri, verinin içinde bulunduğu duruma göre üç farklı alanda uzmanlaşır:

• Data in Use: Kullanıcıların uç noktalarda gerçekleştirdiği işlemler üzerindeki denetimdir. USB bellek kullanımı, kopyala-yapıştır eylemleri veya ekran görüntüsü alma gibi riskli hareketleri sınırlar.
• Data in Motion: Kurumsal ağdan dışarıya sızmaya çalışan verileri hedefler. E-postalar, web formları veya anlık mesajlaşma uygulamaları üzerinden gönderilen dosyaları tarar ve kural dışı trafiği durdurur.
• Data at Rest: Sunucularda, bulut depolama alanlarında veya veri tabanlarında saklanan verileri tanımlar. “Kritik veri nerede saklanıyor?” sorusuna yanıt vererek, yanlış yerde duran hassas verilerin temizlenmesini sağlar.

Başarılı Bir DLP Stratejisi İçin Yol Haritası

DLP sadece bir yazılım kurulumu değil, bir süreç yönetimidir. Etkili bir koruma için şu adımlar izlenmelidir:

1. Sınıflandırma: Hangi verinin “hassas” olduğuna karar verilmelidir. Finansal veriler, müşteri bilgileri ve teknik dökümanlar önceliklendirilmelidir.
2. Kural Setlerinin Belirlenmesi: “Kim, hangi veriyi, hangi kanalla gönderebilir?” sorularına dayalı net politikalar oluşturulmalıdır.
3. Sürekli İzleme ve Analiz: Tehditler sürekli evrilir. DLP sisteminden gelen alarmlar analiz edilerek kurallar düzenli olarak güncellenmelidir.

Verinin sınır tanımadan aktığı modern iş dünyasında, kale duvarlarını yükseltmek artık yeterli değildir. Önemli olan, duvarın içindeki hazineyi yani veriyi takip edebilmektir. DLP, kurumlara bu takip yeteneğini sunarak dijital varlıkların güvenliğini reaktif bir savunmadan proaktif bir koruma kalkanına dönüştürür.

The post DLP (Data Loss Prevention) Nedir? appeared first on inetmar Hosting & Teknoloji Blog Haber Sayfası.

Ngrok Ne Demek?

Ngrok localhost yani yerel makinenizde çalışan bir servisi, güvenli bir tünel üzerinden internete açan bir “reverse proxy” hizmetidir. Normal şartlarda yerel bir web sitesini internete açmak için modemden port yönlendirme yapmak, statik IP edinmek veya bir sunucuya deploy etmek gerekir. Ngrok, tüm bu karmaşık süreçleri tek bir komutla devre dışı bırakır.

Nasıl Çalışır?

Sisteminizde bir Ngrok istemcisi çalıştırdığınızda, bu istemci Ngrok bulut sunucu servislerine bir bağlantı kurar. Ngrok size xyz.ngrok-free.app gibi genel bir URL atar. Bu URL’ye gelen tüm istekler, Ngrok sunucuları üzerinden tünellenerek doğrudan sizin bilgisayarınızdaki yerel porta iletilir.

Temel Kullanım Alanları

• Webhook Testleri: GitHub, Stripe veya Slack gibi platformlardan gelen Webhook bildirimlerini anlık olarak yerel bilgisayarınızda test etmek.
• Demo Sunumları: Hazırladığınız bir projeyi sunucuya yüklemeden, müşteriye veya ekip arkadaşınıza bir link üzerinden hızlıca göstermek.
• Mobil Uygulama Geliştirme: Telefonunuzdaki uygulamanın, bilgisayarınızdaki backend servisiyle konuşmasını sağlamak.

Ngrok Riskleri

Ngrok ne kadar pratikse, yanlış ellerde veya dikkatsiz yapılandırmalarda o kadar tehlikeli olabilir. İşte dikkat edilmesi gereken kritik güvenlik açıkları:

Yetkisiz Erişim ve Veri Sızıntısı

Ngrok ile bir tünel açtığınızda, varsayılan olarak bu URL dünya üzerindeki herkese açıktır. Eğer yerel servisinizde güçlü bir kimlik doğrulama mekanizması yoksa, URL’yi bir şekilde ele geçiren (brute force veya sızıntı yoluyla) herhangi bir saldırgan, doğrudan bilgisayarınızdaki dosyalara veya veritabanına erişebilir.

Shadow IT Tehlikesi

Kurumsal şirketlerde çalışanların, BT departmanının haberi olmadan Ngrok kullanması ciddi bir risk teşkil eder. Şirketin güvenlik duvarları dışarıdan gelen bağlantıları engellemek için tasarlanmıştır; ancak Ngrok bağlantıyı içeriden dışarıya doğru başlattığı için bu duvarları “bypass” eder. Bu durum, kurumsal ağda kontrolsüz bir arka kapı yani backdoor açılması demektir.

Zararlı Yazılım ve Phishing Aracı Olarak Kullanımı

Siber saldırganlar, phishing sayfalarını barındırmak için sık sık Ngrok kullanır. Ngrok’un sağladığı URL’ler “ngrok-free.app” gibi güvenilir görünen bir ana alan adına sahip olduğu için, e-posta filtrelerini ve kullanıcıların şüphelerini daha kolay aşabilirler. Ayrıca komuta kontrol (C2) merkezleri için gizli tüneller oluşturmak amacıyla da tercih edilmektedir.

Trafiğin İzlenmesi

Tünellenen tüm trafik Ngrok’un kendi sunucuları üzerinden geçer. Her ne kadar uçtan uca şifreleme seçenekleri olsa da, ücretsiz veya yanlış yapılandırılmış planlarda trafiğin metadata bazlı analizi veya (teorik olarak) araya girilmesi mümkündür. Hassas verilerle çalışırken bu bir risk faktörüdür.

Güvenli Bir Şekilde Ngrok Nasıl Kullanılır?

Ngrok kullanırken riskleri minimize etmek için şu adımları mutlaka uygulayın:

1. Auth Token Kullanın: Her zaman hesabınıza özel authtoken ile kimlik doğrulaması yapın.
2. Kimlik Doğrulaması Ekleyin: Ngrok’un sunduğu --auth="kullanıcı:şifre" parametresini kullanarak tünelinize bir giriş katmanı ekleyin veya Google/GitHub ile OAuth yapılandırmasını aktif edin.
3. IP Kısıtlaması (Whitelist): Sadece belirli IP adreslerinin tünelinize erişmesine izin verin (Ücretli planlarda mevcuttur).
4. İşiniz Bitince Kapatın: Test işleminiz biter bitmez tüneli aktif olarak sonlandırın; açık bırakılan her tünel, unutulmuş bir açık kapıdır.

Özetlemek gerekirse Ngrok geliştirici verimliliğini artıran harika bir araç olsa da, ağ güvenliği konusunda bilinçli kullanılmalıdır. Özellikle kurumsal ortamlarda “güvenlik duvarını aşma” yeteneği, onu potansiyel bir tehdit haline getirir. Kural basit erişimi kısıtlayın, trafiği izleyin ve asla tünelleri başıboş bırakmayın.

The post Ngrok Nedir? Ngrok’un Riskleri appeared first on inetmar Hosting & Teknoloji Blog Haber Sayfası.

Karşılaştığınız erişim problemini çözmek için aşağıdaki adımlardan size uygun olanı tercih edebilirsiniz:

1. Yöntem: VPN Eklentisi Kullanmak

Tarayıcınızda halihazırda bulunan veya yeni kuracağınız herhangi bir VPN eklentisini aktifleştirin. Farklı bir sunucu üzerinden siteye bağlandığınızda indirme işlemi sorunsuz bir şekilde başlayacaktır.

2. Yöntem: Online Proxy Kullanmak (VPN Gerektirmez)

Cihazınıza veya tarayıcınıza ekstra bir VPN eklentisi kurmak istemiyorsanız web tabanlı proxy servislerini kullanabilirsiniz.

1. Arama motorunuza “online proxy” yazarak güvenilir bir proxy sitesine giriş yapın.
2. Sitenin URL arama çubuğuna doğrudan indirme bağlantısı olan https://www.malwarebytes.com/mwb-download adresini yapıştırın ve ilerleyin.
3. Kurulum dosyası cihazınıza inmeye başlayacaktır.

The post Malwarebytes 403 Error Hatası Çözümü appeared first on inetmar Hosting & Teknoloji Blog Haber Sayfası.