Genel

  • Kategori: genel
  • Gösterim: 164

Zimbra Sunucularını Tehdit Eden Kritik Güvenlik Açığı: CVE-2026-73570

Kurumsal e-posta altyapılarında yaygın olarak kullanılan Zimbra Collaboration Suite için yayımlanan CVE-2026-73570 numaralı güvenlik açığı, sistem yöneticilerinin ve Zimbra kullanıcılarının dikkat etmesi gereken kritik güvenlik problemleri arasında yer alıyor.

CVSS 8.9 (High) seviyesinde değerlendirilen açık, saldırganların herhangi bir kullanıcı hesabına sahip olmadan uzaktan özel hazırlanmış SMTP istekleri aracılığıyla sunucuda işletim sistemi komutları çalıştırabilmesine yol açabiliyor.

Üstelik konu yalnızca teorik bir güvenlik riski değil. CVE-2026-73570, 21 Ağustos 2026 tarihinde CISA'nın Known Exploited Vulnerabilities (KEV) kataloğuna dahil edildi. Bu da açığın gerçek saldırılarda aktif olarak kullanıldığını gösteriyor.

CVE-2026-73570 Nedir?

CVE-2026-73570, Zimbra Collaboration Suite içerisindeki bir bileşenin gelen verileri yeterince güvenli şekilde işleyememesinden kaynaklanan bir komut enjeksiyonu ve uzaktan kod çalıştırma açığıdır.

Açığın önemli taraflarından biri, saldırganın Zimbra hesabına giriş yapmasına gerek olmamasıdır.

Özel olarak hazırlanmış bir SMTP isteği ile saldırı gerçekleştirildiğinde, uygun yapılandırmaya sahip sistemlerde saldırganın sunucu üzerinde Zimbra servis kullanıcısının yetkileriyle işletim sistemi komutları çalıştırması mümkün hale gelebilir.

Bu nedenle söz konusu açık, yalnızca web arayüzüne yönelik klasik bir güvenlik problemi olarak değerlendirilmemelidir.

Kimler Risk Altında?

Zimbra Collaboration Suite kullanan her sistemin aynı seviyede risk altında olduğunu söylemek doğru değildir.

CVE-2026-73570 için temel risk koşulları şunlardır:

  • Zimbra Collaboration Suite 10.1.20 öncesi bir sürümün kullanılması
  • Açığın etkilediği isteğe bağlı bileşenin sistemde bulunması
  • İlgili bildirim mekanizmasının etkin olması

Dolayısıyla yalnızca Zimbra sürümüne bakarak kesin bir güvenlik değerlendirmesi yapmak yeterli değildir. Sunucunun mevcut paketleri, servisleri ve yapılandırmasının birlikte incelenmesi gerekir.

Zimbra tarafından yayımlanan düzeltmenin bulunduğu sürüm 10.1.20 olarak belirtilmektedir.

Bu Açık Sömürülürse Ne Olabilir?

CVE-2026-73570'in en önemli özelliği, başarılı bir saldırı sonucunda saldırganın sunucu üzerinde uzaktan işletim sistemi komutları çalıştırabilmesidir.

Bu durum, yalnızca birkaç e-postanın ele geçirilmesi anlamına gelmez.

Başarılı bir saldırı sonrasında saldırgan;

  • Sunucu üzerinde yetkisiz dosyalar oluşturabilir,
  • Zararlı yazılım veya web shell yerleştirebilir,
  • E-posta sistemine ve sunucudaki verilere erişmeye çalışabilir,
  • Zimbra servislerinin çalışmasını bozabilir,
  • Sistemde kalıcılık sağlamaya çalışabilir,
  • Sunucuyu başka saldırılar için kullanabilir,
  • Kurumun e-posta trafiğini ve iletişim altyapısını tehlikeye atabilir.

Güvenlik araştırmacıları, açığın gerçek dünyadaki istismarlarında Zimbra'nın web uygulaması dizinlerine kalıcı erişim sağlayabilecek zararlı dosyaların bırakıldığını da bildirdi.

Başka bir ifadeyle, saldırganın elde ettiği erişim yalnızca "mail sunucusuna erişim" olarak değerlendirilmemelidir. Ele geçirilen bir e-posta sunucusu, kurumun diğer sistemlerine yönelik saldırılar için de önemli bir başlangıç noktası haline gelebilir.

Neden Bu Kadar Önemli?

E-posta sunucuları doğaları gereği internet üzerinden erişilebilir sistemlerdir.

Bu nedenle saldırganın kurumun iç ağına fiziksel olarak erişmesine veya VPN hesabına sahip olmasına gerek kalmadan, internet üzerinden saldırı gerçekleştirmeye çalışması mümkündür.

CVE-2026-73570'in kimlik doğrulama gerektirmemesi ve ağ üzerinden tetiklenebilmesi, açığın önemini artıran başlıca faktörler arasında yer alıyor.

Ayrıca açığın CISA KEV kataloğuna eklenmiş olması, kurumların bu güvenlik açığını yalnızca "ileride güncelleriz" şeklinde değerlendirmemesi gerektiğini gösteriyor.

Zimbra Sunucunuz Güvende mi?

Zimbra sunucunuzun güvenli olup olmadığını yalnızca versiyon numarasına bakarak anlamak mümkün değildir.

Sunucunun;

  • Zimbra sürümü,
  • Kurulu bileşenleri,
  • Aktif servisleri,
  • İlgili yapılandırmaları,
  • Log kayıtları,
  • Şüpheli dosya ve süreçleri

birlikte kontrol edilmelidir.

Özellikle internet üzerinden hizmet veren eski Zimbra kurulumlarında yalnızca güncelleme yapmak değil, olası bir saldırı izinin bulunup bulunmadığını kontrol etmek de önemlidir.

Çünkü bir sunucunun güncel hale getirilmesi, daha önce saldırıya uğramadığı anlamına gelmez.

SunucuPark ile Zimbra Güvenlik Açığı Kapatma Hizmeti

SunucuPark olarak Zimbra altyapılarınızın güvenlik kontrollerini ve CVE-2026-73570 kapsamında gerekli güncelleme ve güvenlik çalışmalarını gerçekleştiriyoruz.

Çalışma kapsamında Zimbra sunucunuzun mevcut durumu incelenerek riskli yapılandırmalar tespit edilir ve uygun güvenlik işlemleri uygulanır.

Gerekli durumlarda;

✓ Zimbra sürüm ve paket kontrolü
✓ Güvenlik açığına karşı yapılandırma analizi
✓ Gerekli Zimbra güncelleme işlemleri
✓ Servis ve sistem kontrolleri
✓ Şüpheli dosya ve süreçlerin incelenmesi
✓ Log analizi ve olası saldırı izlerinin kontrolü
✓ Güncelleme sonrası servis kontrolleri

gerçekleştirilir.

Amacımız yalnızca açığı kapatmak değil, Zimbra e-posta altyapınızın güvenli ve sağlıklı şekilde çalışmaya devam etmesini sağlamaktır.

Zimbra Sunucunuzun Güvenliğini Kontrol Ettirin

Zimbra sunucunuzun CVE-2026-73570 açısından risk altında olup olmadığını öğrenmek veya gerekli güvenlik güncellemesini yaptırmak için SunucuPark ile iletişime geçebilirsiniz.

Özellikle eski Zimbra sürümleri kullanan ve internet üzerinden hizmet veren sunucular için güvenlik kontrolünün geciktirilmemesini öneriyoruz.

SunucuPark — Zimbra Güvenlik Güncelleme ve Sunucu Güvenliği Hizmetleri

  • Kategori: genel
  • Gösterim: 138

SolusVM to Proxmox Migration Services | SunucuPark

Looking to migrate your existing virtualization infrastructure to Proxmox VE?

At SunucuPark, we provide Proxmox VE migration services for VPS and virtual server infrastructures running on different virtualization platforms.

With years of experience and well-established migration and infrastructure management processes, we provide these services to hosting companies, data centers, VPS providers, and organizations looking to move their existing virtualization infrastructure to Proxmox VE.

Why Migrate from SolusVM to Proxmox?

As virtual server infrastructures grow, the manageability, flexibility, and scalability of the virtualization platform become increasingly important.

Proxmox VE is a powerful virtualization platform that offers KVM-based virtualization, centralized management, clustering, flexible storage options, backup capabilities, and advanced networking features.

However, migrating an existing VPS infrastructure—or hundreds of virtual servers—to a new virtualization platform is not a simple process.

Especially for VPS environments running production workloads, several factors need to be carefully managed, including:

  • Minimizing the risk of data loss
  • Keeping downtime as short as possible
  • Transferring virtual disks correctly
  • Maintaining network configurations
  • Ensuring operating systems boot correctly on the new hypervisor
  • Verifying that existing services continue to operate after migration

At SunucuPark, we manage the migration process from end to end.

SunucuPark's SolusVM → Proxmox Migration Experience

We have migrated numerous KVM-based virtual servers running on SolusVM to Proxmox VE infrastructure, gaining hands-on experience with different VPS configurations, storage structures, and disk usage scenarios in real production environments.

Throughout these projects, we have focused not only on transferring virtual machines, but also on comprehensive pre- and post-migration checks.

For each virtual server, our migration process includes:

  1. Analyzing the existing infrastructure
  2. Identifying VPS resources and disk structures
  3. Planning the appropriate migration method
  4. Transferring virtual disks to the target infrastructure
  5. Creating the appropriate VM configuration on Proxmox
  6. Configuring disks and networking
  7. Booting the virtual server on the new infrastructure
  8. Verifying the operating system and running services

Each migration is carefully planned and executed according to the specific requirements of the existing infrastructure.

How Does Our Migration Process Work?

1. Existing Infrastructure Analysis

We start by analyzing your existing SolusVM infrastructure and VPS environment.

We evaluate factors such as:

  • CPU and RAM resources
  • Disk capacity and utilization
  • Disk structure
  • Operating system
  • Network configuration
  • Number of VPS instances
  • Storage infrastructure

Based on this analysis, we create a migration plan tailored to your infrastructure.

2. Migration Planning

Every infrastructure has different migration requirements.

The migration method is determined based on factors such as the number of VPS instances, disk sizes, storage architecture, operating systems, and the criticality of the services running on the servers.

For production environments, minimizing downtime is one of our primary priorities.

For this reason, we create a detailed migration plan based on the characteristics and requirements of your servers before starting the migration.

3. VPS Disk Migration

One of the most critical stages of the migration process is transferring virtual disks from the source infrastructure to the Proxmox storage environment.

Based on the architecture of the source infrastructure, we determine the appropriate disk transfer method and migrate the VPS disks to the target Proxmox infrastructure.

The transferred disks are then attached to the corresponding virtual machines created on Proxmox.

4. Proxmox VM Configuration

Virtual machines are configured on Proxmox to match the requirements of the existing environment.

This includes:

  • CPU
  • RAM
  • Disk
  • Network
  • Boot configuration

The required checks are performed to ensure that the operating system can operate correctly with the new virtual hardware.

5. Network Configuration and Testing

Network connectivity is another critical part of the migration process.

We verify the IP address, gateway, routing configuration, and virtual network interface.

We also test both outbound connectivity from the VPS and inbound accessibility to ensure that the server is properly connected to the network.

6. Post-Migration Service Checks

A VPS successfully booting does not mean that the migration process is complete.

After migration, we verify the operating system and running services.

Depending on the purpose of the server, we can check services and components such as:

  • Web services
  • MySQL / MariaDB
  • Mail services
  • DNS
  • Docker
  • Applications
  • Cron jobs
  • SSL certificates
  • SSH access

Our goal is not simply to say “Your VPS is now running on the new server.”

We verify that the system and its critical services are actually operating correctly on the new infrastructure.

What Types of Infrastructure Do We Support?

We provide migration services for organizations looking to move their existing virtualization infrastructure to Proxmox VE, including:

  • Hosting companies
  • Data center operators
  • VPS providers
  • System integrators
  • Corporate IT infrastructures

Having a large number of VPS instances does not mean that migration is impractical.

From infrastructures with a small number of virtual servers to environments hosting hundreds of VPS instances, we can analyze your existing architecture and create an appropriate migration plan.

Is Data Loss Possible During Migration?

Data integrity is one of the most important aspects of any migration project.

Before migration, we perform the necessary checks to understand the source environment and identify potential risks.

During the migration process, the appropriate transfer method is selected according to the infrastructure, and post-migration disk and service checks are performed.

Before starting the migration, we analyze your existing infrastructure and provide information about potential risks and the expected downtime based on the migration scenario.

Why Choose SunucuPark?

Migration is not simply a matter of moving a server's disk from one system to another.

Especially in production VPS environments, an improperly planned migration can result in:

  • Extended downtime
  • Boot failures
  • Network connectivity issues
  • Disk-related problems
  • Applications or services failing to start

At SunucuPark, we combine our experience from migrating our own infrastructure with our operational expertise across different server and hosting environments.

We carefully plan each migration project and adapt the process to the architecture and requirements of the customer.

Our goal is not simply to move your VPS instances, but to migrate your existing infrastructure to Proxmox in the most controlled and reliable way possible.

Looking for a Proxmox Migration Service?

If you are planning to migrate your existing SolusVM infrastructure to Proxmox VE but are unsure where to start, we can help you evaluate your environment.

We can analyze your servers, VPS count, disk structure, storage architecture, and existing virtualization environment to create a custom Proxmox migration plan for your infrastructure.

Contact us for SolusVM → Proxmox migration services.

At SunucuPark, we analyze your existing virtualization infrastructure, plan the migration process, and migrate your VPS environment to Proxmox VE.

SunucuPark — Professional migration solutions for your virtualization infrastructure.

  • Kategori: genel
  • Gösterim: 945

Plesk Panelinde Manuel WordPress Kurulumu: Adım Adım Rehber

Pek çok hosting sağlayıcısı artık tek tıkla WordPress kurulumu sunuyor. Peki bu yöntem her zaman ideal mi? Cevap: hayır. Otomatik kurucular genellikle sürüm konusunda tercih hakkı tanımaz ve veritabanı isimlerini sizin için rastgele belirler. Eğer bu şekilde tercih etmezseniz manuel kurulum yapabilirsiniz.

Manuel kurulum biraz daha vakit alır ama karşılığında size, tamamen kontrolünüzde olan bir WordPress sitesi sunar. Bu yazıda Plesk panelini kullanarak WordPress'i sıfırdan, doğru şekilde nasıl kuracağınızı anlatacağım.

Kuruluma Başlamadan Önce Gerekenler

İşlemlere geçmeden önce şu üç şeyin elinizde olduğundan emin olun:

  • Plesk panel erişim bilgileri (kullanıcı adı + şifre)
  • Alan adınızın Plesk hostinginize yönlendirilmiş olması (DNS ayarları)
  • Bilgisayarınıza indirilmiş güncel WordPress paketi — wordpress.org/download adresinden ya da Türkçe için tr.wordpress.org üzerinden indirebilirsiniz.

İndirdiğiniz dosya wordpress-x.x.x.zip şeklinde bir arşiv olacak. Bunu açmadan saklayın; az sonra direkt Plesk'e yükleyeceğiz.

Adım 1: Plesk Paneline Giriş Yapın

Hosting firmanız size genellikle https://sunucuadresi:8443 ya da https://panel.alanadiniz.com gibi bir Plesk giriş adresi vermiştir. Bu adrese tarayıcınızdan girip kullanıcı adı ve şifrenizle oturum açın.

Plesk panel giriş ekranı

Giriş yaptıktan sonra solda alan adlarınızın listelendiği bir panel göreceksiniz. WordPress kuracağınız alan adına tıklayın. Bu, o alan adına özel araçların açıldığı yönetim sayfasını getirecek.

Adım 2: Veritabanı Oluşturun

WordPress bir veritabanı gerektirir; içerikleriniz, kullanıcılar, ayarlar — hepsi burada saklanır. Sağ tarafta ya da alan adı kartının içinde "Databases" (Veritabanları) seçeneğini bulup tıklayın.

Açılan sayfada "Add Database" (Veritabanı Ekle) butonuna tıklayın.

Plesk'te yeni veritabanı ekleme

Açılan formda şu bilgileri doldurun:

  • Database name (Veritabanı adı): siteniz_wp gibi sade ve anlamlı bir isim verin. Plesk genellikle başına otomatik bir ek ekler.
  • Related site: WordPress'i kuracağınız alan adını seçin.
  • Database server: Tek bir seçenek varsa onu seçin (genellikle MariaDB / MySQL localhost).

Hemen altında "Create a database user" kutucuğunu işaretleyin ve bir kullanıcı oluşturun:

  • Database user name: wpuser gibi tahmin edilmesi zor bir isim.
  • Password: Güçlü bir şifre üretin. Plesk'in "Generate" butonunu kullanmak en güvenlisidir. Bu şifreyi mutlaka bir yere not edin, az sonra ihtiyacınız olacak.

"OK" butonuna basın. Artık WordPress'in bağlanacağı veritabanı hazır.

Aklınızda tutun:

  • Veritabanı adı
  • Veritabanı kullanıcı adı
  • Şifre
  • Veritabanı sunucusu (genellikle localhost)

Adım 3: WordPress Dosyalarını Yükleyin

Sol menüden "Files" (Dosyalar) seçeneğine ya da alan adı kartında "File Manager" linkine tıklayın. Bu, Plesk'in dahili dosya yöneticisini açar.

Açılan ekranda alan adınıza ait httpdocs klasörünü göreceksiniz. Bu, sitenizin ana dizinidir. İçine girin.

httpdocs içinde varsayılan olarak gelen index.html, info.php gibi örnek dosyalar olabilir. Bunları seçip silin — temiz bir kuruluma ihtiyacımız var.

Üst menüden "Upload" butonuna tıklayın ve bilgisayarınızdaki wordpress-x.x.x.zip dosyasını seçin. Yükleme tamamlandığında dosyanın üzerine sağ tıklayın ve "Extract Files" (Dosyaları Çıkar) seçeneğini seçin.

Zip açıldığında, dosyaların bir wordpress adlı alt klasör içine çıktığını fark edeceksiniz. Bu önemli bir noktadır: WordPress dosyalarının doğrudan httpdocs içinde olması gerekir, alt klasörde değil. Aksi takdirde siteniz alanadiniz.com/wordpress/ adresinde çalışır ki bu istenmez.

Çözüm: wordpress klasörünün içine girin, tüm dosyaları seçin (Ctrl+A), kesin (Cut) ve httpdocs klasörüne yapıştırın. Ardından boşalan wordpress klasörünü ve artık gereksiz olan .zip dosyasını silin.

Adım 4: Dosya İzinlerini Kontrol Edin

Manuel kurulumlarda sıklıkla atlanan ama kritik bir adım. File Manager üzerinden:

  • Tüm klasörlerin izninin 755
  • Tüm dosyaların izninin 644

olduğundan emin olun. Bir dosyaya sağ tıklayıp "Change Permissions" seçeneğiyle bunu kontrol edebilirsiniz. Genellikle çıkartma sırasında doğru izinler atanır ama yine de hızlıca göz atın.

Adım 5: WordPress Kurulum Sihirbazını Çalıştırın

Tarayıcınızda alan adınızı açın: https://alanadiniz.com

Karşınıza WordPress'in meşhur dil seçim ekranı gelecek. "Türkçe" seçip devam edin

Sonraki ekran size veritabanı bilgilerini soracak. Adım 2'de oluşturduğunuz bilgileri buraya girin:

  • Veritabanı Adı: Oluşturduğunuz veritabanı (Plesk'in eklediği önekle birlikte tam adı)
  • Kullanıcı Adı: Oluşturduğunuz veritabanı kullanıcısı
  • Parola: Not aldığınız şifre
  • Veritabanı Sunucusu: localhost (Plesk farklı bir adres bildirmediyse)
  • Tablo Öneki: Varsayılan wp_ yerine wp_xyz_ gibi özel bir önek kullanın. Bu basit değişiklik, otomatik saldırı denemelerine karşı koruma sağlar.
  • "Gönder" tıkladığınızda WordPress bağlantıyı test edecek. Hata aldıysanız, en yaygın sebep ya yanlış şifre ya da veritabanı adının önekini eksik yazmaktır. Bilgileri tekrar kontrol edin.

Bağlantı başarılıysa "Kurulumu Çalıştır" butonu görünecek. Tıklayın.

Son ekranda site bilgilerini girersiniz:

  • Site Başlığı: Sitenizin adı (sonradan değiştirilebilir)
  • Kullanıcı Adı: "admin" KULLANMAYIN. En çok denenen kullanıcı adıdır. mehmet_yonetici gibi özgün bir isim seçin.
  • Parola: Otomatik üretilen güçlü şifreyi olduğu gibi kullanın ve güvenli bir yere kaydedin.
  • E-posta: Aktif olarak kullandığınız bir e-posta. Şifre sıfırlama bunun üzerinden gider.
  • Arama Motoru Görünürlüğü: Site henüz hazır değilse "Arama motorlarının siteyi indekslemesini engelle" kutucuğunu işaretleyin. Site canlıya çıktığında kaldırmayı unutmayın.
  • "WordPress'i Kur" butonuna basın. Birkaç saniye içinde başarı ekranı karşınıza gelecek. Tebrikler — WordPress siteniz artık çalışıyor.

Adım 6: Kurulum Sonrası Güvenlik Düzenlemeleri

Kurulum bitti ama iş bitmedi. Şu üç şeyi mutlaka yapın:

1. wp-config.php iznini 600 yapın. File Manager'dan wp-config.php dosyasına sağ tıklayıp izni 600 olarak değiştirin. Bu dosya veritabanı şifrenizi içerir ve hassastır.

2. Plesk üzerinden SSL sertifikası kurun. Alan adı yönetim sayfasında "SSL/TLS Certificates" seçeneğinden ücretsiz Let's Encrypt sertifikasını birkaç tıkla aktive edebilirsiniz. Bunu yapmadan önce sitenize girmeyin.

Sonuç

Manuel WordPress kurulumu, ilk bakışta otomatik kurucudan daha karmaşık görünür ama göründüğünden çok daha basittir ve size her aşamada kontrol verir. En önemlisi, hangi kullanıcı adı, hangi şifre, hangi veritabanı isminin kullanıldığını bilmek; problem çıktığında nereye bakacağınızı bilmek demektir.

Bu rehberi takip ettiyseniz şu anda temiz, güvenli ve sizin yönetiminizdeki bir WordPress siteniz var.

Sunucupark'tan WordPress Hosting alabilir, tek tıkla otomatik kurulum ya da manuel kurulum ile WordPress sitenizi yayınlayabilirsiniz.

  • Kategori: genel
  • Gösterim: 187

SolusVM’den Proxmox’a Migration Hizmeti | SunucuPark

Mevcut sanallaştırma altyapınızı Proxmox VE’ye taşımak mı istiyorsunuz?

SunucuPark olarak farklı sanallaştırma platformlarında çalışan VPS ve sanal sunucu altyapılarının Proxmox VE’ye migration işlemlerini gerçekleştiriyoruz.

Yıllardır edindiğimiz deneyim ve geliştirdiğimiz operasyon süreçleriyle bu hizmeti farklı firmaların ve veri merkezi altyapılarının ihtiyaçlarına yönelik olarak da sunuyoruz.

Neden SolusVM’den Proxmox’a Geçiş?

Sanal sunucu altyapıları büyüdükçe kullanılan sanallaştırma platformunun yönetilebilirliği, esnekliği ve gelecekteki ihtiyaçlara cevap verebilmesi daha önemli hale geliyor.

Proxmox VE; KVM tabanlı sanallaştırma, merkezi yönetim, cluster yapısı, farklı storage seçenekleri, yedekleme ve gelişmiş network özellikleriyle birçok kurumun tercih ettiği sanallaştırma platformlarından biri.

Ancak mevcut VPS altyapısını tamamen değiştirmek veya yüzlerce sanal sunucuyu yeni bir platforma taşımak kolay bir süreç değil.

Özellikle aktif olarak hizmet veren VPS'lerde;

  • Veri kaybı riskinin minimize edilmesi,
  • Kesinti süresinin mümkün olduğunca kısa tutulması,
  • Disklerin doğru şekilde aktarılması,
  • Network yapılandırmasının korunması,
  • İşletim sistemlerinin yeni hypervisor üzerinde sorunsuz açılması,
  • Mevcut servislerin migration sonrasında çalışmaya devam etmesi

gibi birçok detayın birlikte yönetilmesi gerekiyor.

SunucuPark olarak bu migration sürecini uçtan uca yönetiyoruz.

SunucuPark'ın SolusVM → Proxmox Migration Deneyimi

SolusVM üzerinde çalışan birçok KVM tabanlı sanal sunucuları Proxmox VE altyapısına taşıyarak, farklı VPS yapılarını ve farklı disk kullanım senaryolarını gerçek üretim ortamında deneyimledik.

Bu süreçte yalnızca sanal makinelerin taşınmasına değil, migration öncesi ve sonrası kontrollerin tamamına odaklandık.

Her sanal sunucu için;

  1. Mevcut altyapının analiz edilmesi,
  2. VPS kaynaklarının ve disk yapısının belirlenmesi,
  3. Migration yönteminin planlanması,
  4. Sanal disklerin hedef altyapıya aktarılması,
  5. Proxmox üzerinde uygun VM yapısının oluşturulması,
  6. Disk ve network yapılandırmasının yapılması,
  7. Sanal sunucunun yeni altyapıda başlatılması,
  8. İşletim sistemi ve servis kontrollerinin gerçekleştirilmesi

gibi aşamaları planlı şekilde uyguluyoruz.

Migration Sürecimiz Nasıl İlerliyor?

1. Mevcut Altyapının Analizi

İlk aşamada mevcut SolusVM altyapınızı ve VPS yapınızı inceliyoruz.

Sunucuların;

  • CPU ve RAM kaynakları,
  • Disk kapasitesi ve kullanım oranları,
  • Disk yapısı,
  • İşletim sistemi,
  • Network yapılandırması,
  • VPS sayısı,
  • Storage altyapısı

gibi bilgilerini değerlendiriyoruz.

Bu analiz sonucunda altyapınıza uygun migration planını oluşturuyoruz.

2. Migration Planının Oluşturulması

Her altyapının migration yöntemi aynı değildir.

VPS sayısı, disk boyutları, kullanılan storage yapısı, işletim sistemleri ve hizmetlerin kritikliği gibi faktörlere göre migration yöntemi belirlenir.

Özellikle üretim ortamlarında çalışan sistemlerde kesinti süresinin mümkün olduğunca azaltılması önceliklerimiz arasında yer alıyor.

Bu nedenle migration öncesinde sunucuların durumuna göre detaylı bir çalışma planı oluşturuyoruz.

3. VPS Disklerinin Taşınması

Migration sürecinin en kritik aşamalarından biri sanal disklerin kaynak altyapıdan Proxmox storage ortamına aktarılmasıdır.

Kaynak altyapının yapısına göre uygun disk aktarım yöntemi belirlenerek VPS diskleri hedef Proxmox altyapısına taşınır.

Ardından ilgili diskler Proxmox üzerinde oluşturulan sanal makinelere tanımlanır.

4. Proxmox VM Yapılandırması

Proxmox üzerinde oluşturulan sanal makinelerde kaynak sistemle uyumlu olacak şekilde;

  • CPU,
  • RAM,
  • Disk,
  • Network,
  • Boot ayarları

yapılandırılır.

İşletim sisteminin yeni sanal donanım üzerinde doğru şekilde çalışabilmesi için gerekli kontroller gerçekleştirilir.

5. Network Kontrolleri

Migration sonrasında en önemli konulardan biri network bağlantısının doğru şekilde çalışmasıdır.

IP adresi, gateway, routing ve sanal network interface kontrolleri gerçekleştirilir.

VPS'in internete erişimi ve dışarıdan erişilebilirliği test edilir.

6. Migration Sonrası Servis Kontrolleri

VPS'in açılması migration işleminin tamamlandığı anlamına gelmez.

Migration sonrasında işletim sistemi ve çalışan servisler kontrol edilir.

Sunucunun kullanım amacına göre;

  • Web servisleri,
  • MySQL / MariaDB,
  • Mail servisleri,
  • DNS,
  • Docker,
  • Uygulamalar,
  • Cron görevleri,
  • SSL sertifikaları,
  • SSH erişimi

gibi servislerin çalışması kontrol edilir.

Böylece müşteriye yalnızca “VPS'iniz yeni sunucuda açıldı” demek yerine, sistemin gerçekten çalışır durumda olduğunu doğrulamayı hedefliyoruz.

Hangi Altyapılar İçin Migration Hizmeti Veriyoruz?

Özellikle mevcut sanallaştırma altyapısını Proxmox VE'ye taşımak isteyen;

  • Hosting firmaları,
  • Veri merkezi işletmeleri,
  • VPS sağlayıcıları,
  • Sistem entegratörleri,
  • Kurumsal IT altyapıları

için migration hizmeti sunuyoruz.

Mevcut altyapınızda çok sayıda VPS bulunması migration işleminin gerçekleştirilemeyeceği anlamına gelmez.

Az sayıda sanal sunucudan yüzlerce VPS bulunan altyapılara kadar, mevcut yapınızı analiz ederek uygun migration planını oluşturabiliriz.

Migration Sırasında Veri Kaybı Olur mu?

Migration işlemlerinde en önemli konularımızdan biri veri bütünlüğüdür.

Kaynak sistemdeki verilerin hedef sisteme eksiksiz şekilde aktarılması için migration öncesinde gerekli kontroller gerçekleştirilir ve aktarım sonrasında disk ve servis kontrolleri yapılır.

Migration öncesinde mevcut sisteminiz incelenerek olası riskler ve tahmini kesinti süreci sizinle paylaşılır.

Neden SunucuPark?

Migration işlemleri yalnızca bir sunucunun diskini başka bir sunucuya taşımaktan ibaret değildir.

Özellikle üretim ortamlarında çalışan VPS altyapılarında yanlış yapılan bir işlem;

  • Uzun süreli kesintilere,
  • Boot problemlerine,
  • Network erişim sorunlarına,
  • Disk problemlerine,
  • Uygulama veya servislerin çalışmamasına

neden olabilir.

SunucuPark olarak hem kendi altyapımızda gerçekleştirdiğimiz migration çalışmalarından hem de farklı sunucu ve hosting altyapılarındaki operasyonel deneyimimizden yararlanarak migration sürecini planlı şekilde yürütüyoruz.

Amacımız yalnızca VPS'lerinizi taşımak değil, mevcut altyapınızı mümkün olan en kontrollü şekilde yeni Proxmox ortamınıza geçirmek.

Proxmox Migration Hizmeti Almak İster misiniz?

Mevcut SolusVM altyapınızı Proxmox VE'ye taşımayı planlıyor ancak nereden başlayacağınızı bilmiyorsanız, altyapınızı birlikte değerlendirebiliriz.

Sunucularınızı, VPS sayınızı, disk yapınızı ve mevcut sanallaştırma altyapınızı analiz ederek size özel bir Proxmox migration planı oluşturabiliriz.

SolusVM → Proxmox migration hizmeti için bizimle iletişime geçin.

SunucuPark olarak mevcut sanallaştırma altyapınızı analiz ediyor, migration sürecini planlıyor ve VPS'lerinizi yeni Proxmox VE altyapınıza taşıyoruz.

SunucuPark — Sanallaştırma altyapınız için profesyonel migration çözümleri.

  • Kategori: genel
  • Gösterim: 858

FTP Dosya İzinleri Nasıl Olmalı? (chmod 755, 644 Ne Anlama Geliyor?)

Web sitenizi FTP ile yönetiyorsanız, er ya da geç şu uyarılardan biriyle karşılaşırsınız: "Permission denied", "500 Internal Server Error" ya da daha kötüsü, sitenizin hacklendiğine dair bir mail. Bu sorunların büyük çoğunluğunun arkasında tek bir konu vardır: yanlış yapılandırılmış dosya izinleri.

Pek çok kullanıcı "çalışmıyor" diyerek hızlıca bütün klasörlere 777 izni veriyor. Bu, evin anahtarını kapının önündeki paspasın altına koymak gibidir — evet, sorununuzu çözer, ama aynı zamanda kötü niyetli herkese kapıyı açar. Bu yazıda FTP izinlerinin nasıl çalıştığını, hangi dosyaya hangi iznin verilmesi gerektiğini ve sık yapılan hataları anlatacağız.

İzinler Neden Bu Kadar Önemli?

Linux tabanlı sunucularda her dosya ve klasör, kimin neye erişebileceğini belirleyen bir izin setine sahiptir. Yanlış izinler iki tür soruna yol açar:

  • Eksik izin verirseniz: Siteniz çalışmaz. PHP betikleri hata verir, yükleme klasörleri çalışmaz, eklentiler kurulmaz.
  • Fazla izin verirseniz: Sitenize giren bir saldırgan, sunucudaki diğer dosyaları da değiştirebilir, zararlı kod yerleştirebilir
  • Doğru izin yapılandırması, çalışan bir site ile güvenli bir site arasındaki dengeyi sağlar.

İzin Sistemi Nasıl Çalışır?

Linux dosya sisteminde her dosyanın üç farklı kullanıcı sınıfı için izni vardır:

  • Owner (Sahip): Dosyayı oluşturan kullanıcı
  • Group (Grup): Sahibin ait olduğu kullanıcı grubu
  • Other (Diğer): Yukarıdakilerin dışındaki herkes

Her sınıf için üç farklı izin tipi tanımlanır:

İzinSembolSayısal DeğerAnlamı
Read r 4 Okuma izni
Write w 2 Yazma/değiştirme izni
Execute x 1 Çalıştırma izni (klasörlerde içine girme)

Bu sayıların toplamı, o sınıfın iznini belirler. Örneğin:

  • 7 = 4 + 2 + 1 = okuma + yazma + çalıştırma (tam izin)
  • 6 = 4 + 2 = okuma + yazma
  • 5 = 4 + 1 = okuma + çalıştırma
  • 4 = sadece okuma

Üç sınıf için bu sayıları yan yana yazdığımızda, sık duyduğunuz 755, 644, 777 gibi izin kodları ortaya çıkar.

Örnek: chmod 755 izni şu anlama gelir:

  • Owner: 7 (okuma + yazma + çalıştırma)
  • Group: 5 (okuma + çalıştırma)
  • Other: 5 (okuma + çalıştırma)

Sembolik gösterimde ise aynı izin rwxr-xr-x şeklinde görünür. FileZilla gibi FTP istemcilerinde her iki gösterimi de görebilirsiniz.

Hangi Dosyaya Hangi İzin Verilmeli?

İşte yazının en kritik kısmı. Pratikte kullanabileceğiniz değerler:

Klasörler: 755

Klasörlerin içine girilebilmesi için execute (x) iznine ihtiyaç vardır. Bu yüzden klasörlere genellikle 755 verilir. Yani sahibi tam yetkili, diğerleri sadece görüntüleyebilir.

Normal Dosyalar: 644

HTML, CSS, JS, görseller, PHP dosyaları gibi standart web dosyaları için 644 idealdir. Sahibi okuyup yazabilir, diğer herkes sadece okuyabilir. Bu, web sunucusunun dosyayı kullanıcıya servis etmesi için yeterlidir.

Hassas Yapılandırma Dosyaları: 600 veya 400

wp-config.php, .env, veritabanı bağlantı bilgileri içeren dosyalar gibi hassas veriler barındıran dosyalar için 600 (sadece sahibi okuyup yazabilir) ya da 400 (sadece sahibi okuyabilir) tercih edilmelidir. Bu dosyalar genellikle web sunucusu tarafından doğrudan kullanıcıya servis edilmez, içeriği bir PHP süreci tarafından okunur. Dolayısıyla "other" kullanıcılara izin vermek gereksiz bir risktir.

Yükleme Klasörleri (uploads, cache, tmp): 755

WordPress'in wp-content/uploads klasörü gibi, web sunucusunun dosya yazması gereken klasörler için kesinlikle 777 vermeyin. Doğru ayarlanmış bir sunucuda 755 yeterlidir, çünkü web sunucusu zaten dosyaların sahibidir. Eğer 755 ile çalışmıyorsa, sorun izinlerde değil, dosya sahipliğindedir — hosting sağlayıcınızla konuşmalısınız.

CGI / Shell Scriptleri: 755

Çalıştırılması gereken betikler için execute iznine ihtiyaç vardır, bu yüzden 755 kullanılır.

Pratik Özet Tablosu

Dosya TipiÖnerilen İzin
Klasörler 755
Normal dosyalar 644
Hassas yapılandırma (wp-config, .env) 600
Yükleme klasörleri 755
CGI/Shell scriptleri 755
.htaccess 644

777'den Neden Kaçınmalısınız?

777, "dünyadaki herkes bu dosyada her şeyi yapabilir" demektir. Birisi sunucunuza herhangi bir yolla sızdığında, 777 izinli klasörlere zararlı PHP dosyaları yükleyebilir, mevcut dosyalarınızı silebilir ya da değiştirebilir. Paylaşımlı hostinglerde başka kullanıcılar bile bu klasörlere müdahale edebilir.

Bir geliştirici olarak şu kuralı asla unutmayın: 777 bir çözüm değil, sorunun bir başka biçimidir. Eğer 755 veya 644 ile çalışmayan bir yapı kurduysanız, dosya sahipliğini (chown) kontrol edin ya da hosting desteğine danışın.

FileZilla ile İzin Nasıl Değiştirilir?

FileZilla, en yaygın kullanılan ücretsiz FTP istemcisidir. İzin değiştirmek için:

  1. Sunucuya bağlanın.
  2. İzin değiştirmek istediğiniz dosya veya klasöre sağ tıklayın.
  3. Açılan menüden "File permissions..." (Dosya izinleri) seçeneğini tıklayın.
  4. Açılan pencerede ya checkboxları işaretleyerek ya da en alttaki "Numeric value" kutusuna 755 gibi sayısal bir değer yazarak izni belirleyin.
  5. Klasör üzerinde değişiklik yapıyorsanız, "Recurse into subdirectories" seçeneği ile alt dizinlere de uygulayabilirsiniz — ama dikkat: alt klasörlere uygulanacak iznin sadece klasörler ya da sadece dosyalar için olduğunu belirtmeyi unutmayın.

Sık Yapılan Hatalar

1. Recursive 777 uygulamak. "Hızlı çözüm" diye bütün siteye 777 vermek, sitenizi internet üzerinde herkese erişime açık hale getirirsiniz.

2. Klasör ve dosyalara aynı izni vermek. Klasörlerin 755, dosyaların 644 olması gerekir. "Hepsine 755 verdim" demek, dosyalarınızı gereksiz yere çalıştırılabilir yapar, bu da güvenlik riski oluşturur. FileZilla'da recursive izin değiştirirken "Apply to directories only" ve "Apply to files only" seçeneklerini ayrı ayrı kullanmalısınız.

3. wp-config.php'yi 644 bırakmak. WordPress sitelerinde en kritik dosyalardan biridir, mutlaka 600 yapılmalıdır.

4. Sahiplik (ownership) sorununu izinlerle çözmeye çalışmak. Dosya sahibi yanlışsa, 777 vererek değil, doğru kullanıcıya devrederek (chown) çözmelisiniz.

Linux ve Windows Hosting Farkı

Şunu da bilmek gerekir: yukarıda anlattığım her şey Linux tabanlı hostingler için geçerli. Windows sunucularda (IIS) chmod kavramı çalışmaz. Windows'ta izinler ACL (Access Control List) üzerinden, genellikle hosting kontrol paneli aracılığıyla yönetilir. Eğer Plesk ya da cPanel kullanıyorsanız, kontrol panelinin dosya yöneticisinden de izin değiştirebilirsiniz.

 

Standart bir kurulumda klasörler 755, dosyalar 644, hassas yapılandırma dosyaları 600 olmalıdır. 777'ye ihtiyacınız olduğunu düşündüğünüz her durumda, aslında çözmeniz gereken farklı bir sorun vardır.

Bu basit kurallara uyarsanız, hem siteniz sorunsuz çalışır hem de yıllar boyunca sürebilecek güvenlik açıklarını baştan kapatmış olursunuz.

Sunucupark Destek

Alt Kategoriler