Bu, Arcivéo Monitor kurulumu, yapılandırması ve bakımı için bir kılavuzdur. Bölümler gruplandırılmıştır: genel bakış, panelin dağıtımı, güvenlik araçlarının bağlanması, yerleşik modüller ve tanılama. Komutlar sağdaki düğmeyle kopyalanabilir.
Panel kurulumu ayrı adım adım sayfalarda anlatılıyor. Bir yöntem seçin:
Arcivéo Monitor, sunucu güvenliği panelidir. Kurulu araçlardan (Fail2ban, UFW, Lynis, ModSecurity, AIDE, ClamAV, Auditd, CrowdSec, Suricata, Falco vb.) verileri toplar ve bunları gösterge paneli, saldırı haritası ve her araç için ayrıntılı sayfalar içeren tek bir arayüzde gösterir.
Monitor aktif bir koruma aracı değildir; saldırıları kendisi engellemez. Görevi, halihazırda çalışan araçlardan gelen bilgileri toplayıp bunları anlaşılır bir biçimde sunmaktır.
Monitör yalnızca yerel olarak çalışır — izlediği sunucunun üzerine kurulması gerekir. Herhangi bir SSH veya uzak API yoktur.
Tüm komutlar (fail2ban-client, ufw status, ipset list vb.) panel tarafından web sunucusu kullanıcısı adına (genellikle www-data, hosting panellerinde site hesabı) çalıştırılır; bunlar dar kapsamlı sudo izinleridir — yalnızca belirli araçlara, genel root erişimi olmadan. Sonuçlar ayrıştırılıp tarayıcıda gösterilir.
Puan en yüksek değerden başlar ve tespit edilen her sorun için düşer:
PermitRootLogin yes) — −20Sonuç: 80+ = Korumalı, 60–79 = Dikkat, <60 = Tehlikede.
WebAuthn — donanım anahtarı ile parolasız kimlik doğrulama standardıdır. YubiKey, Touch ID, Face ID, Windows Hello ve Passkey destekler.
Parolayla giriş yaptıktan sonra sistem, kayıtlı anahtar üzerinden onay ister. Parola sızsa bile fiziksel anahtar veya biyometri olmadan giriş yapılamaz.
Yapılandırmak için yan menüden WebAuthn Anahtarları bölümünü açın ve “Anahtar kaydet” düğmesine tıklayın. Hemen iki anahtar kaydedin: tek anahtarınız kaybolur veya bozulursa, panele o anahtarla giriş yapamazsınız.
Panel, güvenlik raporunu Telegram'a ve e-postaya gönderebilir (düğmeyle veya zamanlanmış). “Ayarlar” bölümünden yapılandırılır.
Telegram. bot token ve chat id gerekir:
@BotFather → /newbot yazın → 123456:ABC... biçiminde bir token alın.@userinfobot botuna yazın veya https://api.telegram.org/bot<TOKEN>/getUpdates adresini açıp "chat":{"id":...} değerini bulun.E-posta. “Ayarlar” → E-posta bölümünde iki yöntemden biri:
re_...) ve doğrulanmış gönderen alan adını girin.Rapor durumu: “DİKKAT” veya “OK”. Başlık yalnızca gerçek bir sorun ya da bekleyen bir eylem varsa “DİKKAT” olur: ClamAV tehdidi bulundu, AIDE'de dosya değişiklikleri, kritik Falco olayları (son 24 saatte Emergency/Alert/Critical), Monit'te çöken bir servis, yeniden başlatma gerekiyor, SSL süresi doluyor (≤14 gün) veya güvenlik güncellemeleri bekliyor. Arka plan gürültüsü — botların SSH deneme saldırıları, fail2ban tarafından yasaklanan IP'ler, Suricata uyarıları, Lynis uyarıları ve ModSecurity'nin zaten savuşturduğu istekler — durumu yükseltmez, bu yüzden rapordaki bu sayılar tek başına “DİKKAT” anlamına gelmez.
Ayrıntılı izleme modülleri (Lynis, UFW, ModSecurity, saldırı haritası, AIDE, ClamAV vb.) yalnızca geçerli bir lisans varken açılır. Lisans olmadan da panel, ayarlar ve hesap çalışır, ancak modüller "Lisans gerekli" kartını gösterir.
Hesaptan satın aldıktan sonra ARCIVEO-XXXX-XXXX-XXXX-XXXX biçiminde bir etkinleştirme kodunuz olur. Bu kodu panelinizin alan adında "etkinleştirmeniz" gerekir — böylece kod, panele yapıştırdığınız imzalı bir lisans dosyasına ([license] bloğu) dönüşür.
Nasıl etkinleştirilir (3 adım):
my.arciveo.com hesabı → "Lisanslar" / "Lisans etkinleştirme" bölümü — ARCIVEO-… kodunu kopyalayın.monitor.example.com). Etkinleştir'e basın — sistem bu alan adına bağlı bir lisans dosyası oluşturur ve "Kopyala" düğmesiyle birlikte alanda gösterir.Panel anahtarı kriptografik olarak doğrular: imza, alan adı bağlantısı ve geçerlilik süresi.
config.php içindeki APP_URL sabitinden alın ve yalnızca ana bilgisayar adını girin — https:// ve www öneki olmadan. Etkinleştirme tek seferliktir: kod, girilen alan adı için bir lisansa dönüşür ve yeniden etkinleştirilemez — alan adında hata olursa anahtar panelinize uymaz ve kod harcanmış olur. Bu nedenle alan adını dikkatle girin.
Panelin tüm temel parametreleri, kök dizindeki (public/ klasörünün yanında) tek bir config.php dosyasında sıradan define() sabitleriyle tanımlanır. Dosya kurulum sırasında oluşturulur; elle düzenlemeniz nadiren gerekir — çoğunlukla domain değişikliği, taşıma ya da başka bir veritabanına bağlanma durumunda. Herhangi bir düzenlemeden sonra PHP-FPM'i yeniden başlatın (aksi hâlde OPcache nedeniyle değişiklikler uygulanmaz).
Kendi değerlerinizi vurgulanan yerlere yazın; geri kalanını olduğu gibi bırakın:
Veritabanı. MySQL/MariaDB bağlantı bilgileri:
DB_HOST — veritabanı sunucusu, neredeyse her zaman localhost;DB_NAME — panelin veritabanı adı;DB_USER — veritabanı kullanıcısı (yalnızca kendi veritabanına erişim);DB_PASS — bu kullanıcının parolası;DB_CHARSET — bağlantı kodlaması, utf8mb4 olarak bırakın.Uygulama.
APP_URL — panelin tam adresi (örn. https://monitor.example.com). Lisansın etkinleştirildiği domain ile aynı olmalı — aksi hâlde anahtar reddedilir (bkz. “Lisans” bölümü);TIMEZONE — PHP saat dilimi: yalnızca panelin tarih ve saati nasıl gösterdiğini etkiler. Cron görevlerinin çalışma zamanını etkilemez — orada sistemin saat dilimi geçerlidir (bkz. “Tüm cron görevleri”).Oturum süresi. SESSION_LIFETIME — saniye cinsinden oturum boşta kalma zaman aşımı (kayan: her etkinlikte yenilenir). Varsayılan olarak 28800 = 8 saat; bu boşta kalma süresinden sonra panel yeniden giriş yapmanızı ister. Örneğin, 3600 = 1 saat, 86400 = bir gün.
Hata günlükleme. Hatalar ziyaretçilere asla gösterilmez, logs/php_errors.log dosyasına yazılır — bunları “Uygulama günlükleri” sayfasında görebilirsiniz. Bu satırları (display_errors=0, log_errors=1, error_log yolu) genellikle değiştirmenize gerek yoktur — ayarlar doğrudan dosyada tanımlıdır ve php.ini'ye bağlı değildir.
public/ yanında) bulunur, bu panelin web kökü (DocumentRoot) ise tam olarak panel köküdür, public/ değil. Dosyanın kendisi “sızmaz”: kök .htaccess içinde onun için açık bir yasak vardır (Require all denied) — sunucu 403 döndürür. Bu kural olmadan bile kaynak sızmazdı: bu PHP'dir — sunucu onu çalıştırır, metin olarak vermez. Her ihtimale karşı: bunu herkese açık depolara koymayın ve gerçek parolayla destek ekibine göndermeyin. Dosya izinleri — 640.
UFW (Uncomplicated Firewall), nftables/iptables için basit bir arayüzdür. Açıkça izin verilenler dışındaki tüm gelen bağlantı noktalarını kapatır. “UFW Güvenlik Duvarı” sayfası durumu ve kuralları gösterir.
ufw enable öncesinde mutlaka SSH'a izin verin (ufw allow OpenSSH), aksi halde sunucuya erişimi kaybedersiniz.
deny kuralıyla kapatılan bir bağlantı noktası dışarıdan erişilebilir sayılmaz.
Skipping adding existing rule bir hata değildir. UFW bu şekilde aynı kuralın zaten var olduğunu ve tekrar eklemediğini bildirir. Otomatik yapılandırma yeniden çalıştırıldığında (idempotenttir) bu normal bir mesajdır — tepki vermenize gerek yoktur.
Başarısız giriş denemesi sayısı aşıldığında IP adresini otomatik engeller. SSH, nginx, Apache ve diğer servislerin günlüklerini analiz eder.
Temel kurulum yukarıda. Burada, onlarca etkin jail ve binlerce yasak sağlayan çalışan yapılandırma var: genel ayarlar, temel jail'lar ve ipsum listesinden zararlı IP'lerin otomatik yasaklanması.
/etc/fail2ban/jail.local dosyası — genel ayarlar ve en önemli jail'lar:
ignoreip içine kendi IP'nizi ve güvenilir ağları mutlaka ekleyin, aksi halde kendinizi yasaklayabilirsiniz. Değişikliklerden sonra: sudo fail2ban-client reload.
ipsum engel listesinin otomatik yüklenmesi — root cron içine (sudo crontab -e): level 1 (100+ bin IP), güvenlik duvarında engellenen ipsum kümesine yüklenir (ayrıntılar için “IPset engel listesi” bölümüne bakın):
ipsum olmalıdır — panoyu bu okur (“IPset ipsum” kartı). Seviyeler: levels/1.txt — maksimum kapsam, levels/3.txt — daha kesin (3+ kaynak).
“Güvenlik Monitörü” neden iki bölgeye ayrılmıştır. Koruma iki düzeyde çalışır ve pano bunları karıştırmaz:
sshd, apache-*, nginx-* vb. jail'lar) ve ısrarlı tekrar edenler (recidive jail'ı — daha önce birkaç kez yasaklananlar). Bunlar size gerçekten saldıran IP'lerdir; saldırı haritasında ve “Zaman çizelgesi”nde yer alırlar.ipset ipsum, güvenlik duvarında DROP kuralıyla engellenir. Bu adresler çoğunlukla sunucunuza hiç dokunmamıştır — önceden kesilirler; “IPset ipsum” sayacı, önleyici olarak ne kadarının kesildiğini gösterir.Fark basit: reaktif — “bunlar saldırdı ve yasak yedi”, önleyici — “bunlar denemeden önce engellendi”. Önceden recidive'e yapay olarak ipsum list-3 yükleniyordu (eski “listeli recidive” ayrımı buradan geliyor); artık recidive yalnızca gerçek tekrar edenlerdir, önleme ise tamamen güvenlik duvarındadır.
ipsum — günlük olarak güncellenen, kötü amaçlı IP'lerin herkese açık listesidir. Monitor, yüklenen adres sayısını panoda ve saldırı haritasında gösterir ve Güvenlik Puanı'nda hesaba katar (küme yüklü değilse −10).
fail2ban olmadan en basit yöntem — iptables ile engelleme yapan ayrı bir ipsum kümesidir:
@reboot'a bağlayın. Ayrıca create … -exist komutu maxelem 300000 limitini belirler (varsayılan 65536 — level 1 sığmaz, “Hash is full” hatası verir):
ipsum kümesine yükler ve güvenlik duvarını yükleyici yönetiyorsa (yeni VPS — “Tam”/“Hafif” profiller), kümeyi bir DROP kuralıyla UFW'ye bağlar — bu IP'lerden gelen trafik gerçekten engellenir. Kural ESTABLISHED,RELATED kuralından sonra gelir, bu yüzden mevcut bağlantılar (SSH'niz dahil) kopmaz — yalnızca listeden gelen yeni bağlantılar kesilir. Küme, ipsum-load.service servisi yüklenirken güvenlik duvarından önce geri yüklenir (yoksa UFW başlamazdı) ve 04:00'teki cron ile güncellenir. Zaten yapılandırılmış bir sunucuda (panel, kendi güvenlik duvarı) yükleyici güvenlik duvarına dokunmaz — orada ipsum pano ve saldırı haritası için bir liste olarak kalır, istenirse DROP kuralı elle eklenir (en basit yöntem iptables … --match-set ipsum … -j DROP ile — yukarıda). Otomatik kurulumda elle bir şey yapmanıza gerek yoktur.
Fail2ban'ın kolektif tehdit istihbaratına sahip modern alternatifi: topluluk kaynaklı engellemelerin yanı sıra kendi kurallarınız. Engellemeleri güvenlik duvarına uygulamak için ayrı bir bouncer gerektirir.
systemctl is-active crowdsec ile denetler). Başlatmak için: sudo systemctl enable --now crowdsec; çökerse sudo journalctl -u crowdsec -n 30 çıktısına bakın. “Çalışmıyor” durumundaki her servis için aynı kural geçerlidir (Suricata, Falco, Monit, MySQL).
stream halted / engellemeler uygulanmıyor. Bu, sahipsiz bir api anahtarıdır: bouncer cscli bouncers list içinden silinmiş ama eski anahtarı /etc/crowdsec/bouncers/*.yaml içinde kalmıştır. Bouncer'ı yeniden kaydedin ve yeni anahtarı girin:
AIDE (Advanced Intrusion Detection Environment) dosya sisteminin anlık görüntüsünü alır ve her kontrolde /etc, /bin, /usr içindeki değişiklikleri bildirir. Kurulumdan sonra veritabanının başlatılması (aideinit) zorunludur.
aideinit sırasında terminal 5–15 dakika Running aide --init... satırında bekler — bu normaldir (tüm dosya sisteminin hash'lenmesi, disk yükü). Ctrl+C ile kesmeyin. İşlem “takılı” görünüyor ama bir şey yazmıyorsa — muhtemelen gizli bir Overwrite existing aide.db.new [Yn]? sorusuna yanıt bekliyordur (Y tuşuna basın). Başka bir oturumdan etkinliği kontrol edin: pgrep -af aide.
aideinit hatası: “21_aide_spamassassin … printf: invalid number” (return code 20) — Ubuntu 22.04'te AIDE yapılandırma parçacığının bilinen bir hatası. Veritabanı oluşturulmaz. Bozuk parçacığı taşıyıp tekrar deneyin:
aideinit çalıştırılmadı, ya da (Ubuntu 24.04) /var/lib/aide dizini 700 modunda oluşturuldu ve www-data erişemiyor — sudo chmod 755 /var/lib/aide ile çözülür (yukarıdaki bloğa bakın). “Kontrol yapılmadı” = veritabanı var ama kontrol henüz çalıştırılmadı — bu bir hata değildir. Monitör sonuçları /var/log/aide/aide.log dosyasından okur.
/etc/cron.daily/aide, yeni Ubuntu/Debian'da /var/log/aide/aide.log dosyasını gerekli biçimde yazmayabilir (ve aide.wrapper onlarda artık yok). Daha güvenilir olanı, açık --config ile kendi cron görevinizi eklemektir — logu root altında 644 modunda yazar ve monitör onu ek grup olmadan okur:
chmod 755 /var/lib/aide ve saat 02:00'deki kontrol cron'u — elle bir şey yapmanıza gerek yok.
sudo aideinit && sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db.
Linux için antivirüs tarayıcısı. Özellikle /var/www dizinini PHP kabuklarına ve zararlı koda karşı taramak için kullanışlıdır.
enable --now sonrasında “Etkin değil” mi gösteriyor? Üç tipik neden:
1. Yapılandırmada Example satırı kalmış — bu satır durdukça clamd başlamayı reddeder:
2. İmza veritabanı indirilmemiş — clamd onsuz başlamaz:
3. Sadece yükleniyordur — clamd ~8 milyon imzayı 30–60 saniyede belleğe yükler. Bekleyin ve kontrol edin: systemctl is-active clamav-daemon (activating durumu → hâlâ yükleniyor).
sudo journalctl -u clamav-daemon -n 30 --no-pager.
clamd servisi yalnızca imzaları bellekte tutar, kendisi zamanlanmış hiçbir tarama yapmaz. Panel planlı tarama sonuçlarını gösterir, bu yüzden tarayıp günlüğe yazan bir cron gerekir. Otomatik kurulum /usr/local/bin/clamav-scan.sh sarmalayıcısını ve 01:30 için bir cron kurar — ilk çalıştırmadan sonra “Taranan dosya” ve “Son tarama” dolar. Zamanlamayı beklemeden hemen çalıştırmak için: sudo /usr/local/bin/clamav-scan.sh.
Linux Malware Detect (LMD) — web tehditlerine yönelik kötü amaçlı yazılım tarayıcısı: PHP shell'leri, web arka kapıları, yükleyiciler. ClamAV motorunu kullanır ve onu kendi imzalarıyla tamamlar.
maldet --report.
update-rc.d: error: unable to read /etc/init.d/maldet satırı görülebilir — bu zararsızdır. maldet init.d kullanmaz; imza güncellemeleri ve taramalar /etc/cron.daily/maldet üzerinden çalıştırılır. Aşağıda installation completed görüyorsanız her şey kurulmuş demektir.
apt ile değil /usr/local/maldetect içine kurulur ve open_basedir etkinken varlığı shell üzerinden kontrol edilir — “Veriler sunucuda olduğu halde sayfa boş” bölümüne bakın.
Ağ tabanlı saldırı tespit sistemi: trafiği paket düzeyinde analiz eder ve binlerce saldırı imzasını tanır. ModSecurity'yi tamamlar (o HTTP düzeyinde, Suricata ise TCP/IP düzeyinde çalışır).
/var/log/suricata/eve.json dosyasını root altında, dizinde 750 modunda yazıyor ve web sunucusu (www-data) bunu okuyamıyor. Dizini geçişe açın — içindeki dosyalar korunmuş kalır:
eBPF/kernel module aracılığıyla sistem çağrılarını yakalar ve anormallikleri gerçek zamanlı olarak tespit eder: nginx'ten shell, web sürecinin /etc/passwd dosyasını okuması, /bin dizinine yazma vb.
journalctl -u falco üzerinden okur (sudo olmadan — systemd-journal grubu üzerinden). www-data'nın bu grupta olduğundan emin olun — bkz. manuel kurulum sayfasındaki “sudo Yapılandırması” (madde 2).
/etc/passwd okuma, sistem dizinlerine yazma). Sakin bir sunucuda günde sıfır kritik olay sağlıklı bir durumdur.
journalctl üzerinden okuma, günlüğe erişim izni gerektirir; panelin olayları kararlı biçimde görebilmesi için otomatik kurulum Falco'da file_output → /var/log/falco/falco.log özelliğini etkinleştirir ve hizmete UMask=0022 ayarını verir (günlük web sunucusu tarafından okunur). Yeni bir kurulumda bunu elle yapılandırmaya gerek yoktur.
ModSecurity — Apache veya Nginx için bir web güvenlik duvarı (WAF). Uygulama katmanındaki saldırıları engeller: SQL enjeksiyonları, XSS, dizin geçişi, tarayıcılar.
IncludeOptional /etc/modsecurity/*.conf satırıyla dâhil eder, ancak paket yalnızca modsecurity.conf-recommended dosyasını koyar — bu da *.conf maskesine uymaz. Onu modsecurity.conf olarak kopyalamazsanız SecRuleEngine değeri Off kalır: modül yüklüdür, CRS kuralları yüklüdür, fakat trafik denetlenmez ve denetim günlüğü oluşturulmaz. Ara mod DetectionOnly istekleri engellemeden yalnızca olayları günlüğe yazar — panel bunu sarı renkte gösterir.
Panelin denetim günlüğüne erişimi. /var/log/apache2/modsec_audit.log günlüğü root'a aittir (640 izinleri) ve web kullanıcısı onu okuyamaz. Panel verileri bir sarmalayıcı üzerinden alır — bunu oluşturun:
SecRuleEngine yönergesini alır: girintili satırlar <LocationMatch>/<Directory> bloklarının içindedir (örneğin phpMyAdmin için WAF'ın devre dışı bırakılması) ve genel modu belirlemez.www-data, HestiaCP'de sitenin havuzu site sahibinin adına çalışır (örneğin admin) — grep -E '^user' /etc/php/*/fpm/pool.d/monitor.example.com.conf ile kontrol edin.X-Forwarded-For başlığından alır. İstatistiklere yalnızca bir kuralın tetiklendiği işlemler dahil olur: SecAuditLogRelevantStatus yönergesi denetim günlüğüne tüm 4xx/5xx yanıtlarını yazar, bu nedenle oraya sıradan 403/500'ler de dahil olur — panel bunları WAF olayı saymaz.---RULES--- bloğu “Tüm etkin kurallar” bölümü için gereklidir — panel yalnızca tetiklenenleri değil, yüklenmiş tüm CRS + özel kuralları gösterir. for f in … döngüsündeki üç yol — CRS kuralları ve yerel eklemeler için tipik konumlardır; farklı bir düzeniniz varsa (paket dosyaları kendi dizinine koyuyorsa veya özel kurallar /etc/modsecurity/custom-rules.conf içinde değilse), gerçek yolları sudo grep -rl 'IncludeOptional\|^Include ' /etc/apache2/mods-enabled/security2.conf /etc/apache2/conf-enabled/*.conf 2>/dev/null komutuyla bulun ve listeye ekleyin. Sarmalayıcı eskiyse (bu bölüm yoksa) — bölüm yalnızca “kullanılamıyor” uyarısı gösterir, sayfanın geri kalanı eskisi gibi çalışır.
Auditd (Linux Audit Daemon), sistem çağrılarını çekirdek düzeyinde kaydeder: oturum açma ve kapatma işlemleri, sudo komutları, başarısız kimlik doğrulama denemeleri, dosya değişiklikleri. Monitor, bugünkü oturum açmaları, başarısız denemeleri ve sudo komutlarını gösterir.
ausearch (/usr/sbin/ausearch) aracılığıyla ve gerektiğinde /var/log/audit/audit.log dosyasından tail komutuyla okur. Her ikisi de sudoers içinde olmalıdır.
Servisleri (nginx, php-fpm, mysql vb.) izler ve çöktüklerinde yeniden başlatır. E-posta ile uyarı gönderebilir.
monit status üzerinden alır. /etc/monit/monitrc içinde HTTP arayüzü etkin olmalıdır (allow localhost içeren set httpd bloğu), aksi hâlde monit status hata döndürür.
monitrc içinde set httpd satırı yorum satırı hâlinde (varsayılan olarak # set httpd port 2812 … şeklinde gelir). Bloğun yorumunu kaldırın ve localhost'a izin verin. (2) Etkin bir httpd tek başına hiçbir şey izlemez — Monit yalnızca check stanzalarında tanımlananları sayar; bunlar olmadan arayüz çalışsa bile liste boş kalır. Asgari çalışan yapılandırma:
conf.d yerleştirir — yeni bir kurulumda elle ayarlamaya gerek yoktur.
PSAD iptables günlüğünü analiz ederek port taramalarını ve ağ saldırılarını tespit eder ve her kaynağa bir tehdit seviyesi (1–5) atar. fail2ban ve Suricata'yı tamamlar.
psad --Status üzerinden okur (sudoers içinde gereklidir). iptables günlük kaydı olmadan sayfa boş görünür — herhangi bir tarama olana kadar bu normaldir.
Mandatory Access Control, bir programın hangi dosya ve kaynaklara erişebileceğini kısıtlar; program ele geçirilse bile bu kısıtlama geçerlidir. Ubuntu/Debian'da varsayılan olarak AppArmor kullanılır (genellikle kurulu ve etkin durumdadır).
aa-status üzerinden okur (sudoers'ta olması gerekir). enforce/complain modundaki profil sayısını ve profilsiz süreçleri gösterir.
“Yüklenen profiller” sayısının enforce + complain toplamından fazla olması normaldir. AppArmor 4.x'te (Ubuntu 24.04 ve sonrası) unconfined modu geldi: profil çekirdeğe yüklenir ancak hiçbir şeyi kısıtlamaz. Ubuntu, user namespaces kullanan programlar için (tarayıcılar, torrent istemcileri ve benzerleri) onlarca profili böyle işaretler. Böyle profiller olduğunda “Yüklenen profiller” kartı kehribar rengine döner ve sayılarını gösterir — örneğin 120 yüklü ve 26 enforce içinde iken unconfined: 90. Gerçekte yalnızca enforce modundaki profiller koruma sağlar; Ubuntu 22.04'te (AppArmor 3.x) bu mod yoktur ve sayılar her zaman tutar.
unconfined bıraktığı profilleri enforce moduna almak yalnızca bilinçli yapılmalıdır: bunlar hata sonucu değil, aksi halde programların kendisi bozulacağı için kapatılmıştır. complain modundaki profiller ise farklıdır: orada kurallar zaten yazılmıştır, yalnızca uygulanmıyordur.
debsums, kurulu paketlerin dosyalarının depodaki sağlama toplamlarıyla eşleştiğini denetler — değiştirilmiş sistem ikili dosyalarını tespit eder (AIDE'yi tamamlar). Tam denetim 1–2 dakika sürer, bu yüzden cron ile çalıştırılır; panel sonucu data/debsums/debsums.log dosyasından okur ve kendisi kategorilere ayırır (yalnızca ikili dosyalar ve kütüphaneler önemlidir).
Görev root-cron'a eklenir (sudo crontab -e). Hazır debsums-scan.sh sarmalayıcısı /usr/local/bin/ içine konur (chmod +x; bkz. cron görevleri özeti) ve raporu kendisi panelin data/debsums/ dizinine yazar.
debsums-scan.sh sarmalayıcısı panelin data/ dizinini kendisi bulur — yolu belirtmeye gerek yoktur.
/etc/ (yapılandırmalar) ve /usr/share/ (kaynaklar) içindeki değişiklikler genellikle normaldir — panel bunları ayrı bir renkle işaretler. İkili dosyalardaki ve kütüphanelerdeki değişiklikler (/bin, /sbin, /usr/lib vb.) endişe vericidir — “İkili dosyalar / kütüphaneler” kartı tam da bunları gösterir.
Lynis elle veya cron ile çalıştırılır. Rapor, projenin data/lynis/ klasörüne kaydedilmelidir — monitör lynis-report.dat dosyasını okur.
lynis-scan.sh betiğini doğrudan panelden arka planda çalıştırır (cron'u beklemeden): “Taranıyor…” gösterir ve tamamlanınca raporu kendisi günceller. Bunun için web kullanıcısının betiği çalıştıracak bir sudoers satırına ihtiyacı vardır — kurulumcu bunu otomatik olarak /etc/sudoers.d/monitor dosyasına ekler. Panel elle/daha önce kurulduysa, dosyada zaten belirtilen kullanıcıyla bu satırı ekleyin:
Logwatch, günlük raporları projenin data/logwatch/ klasörüne .txt biçiminde kaydetmelidir. Monitor son raporu ve arşivi gösterir.
Ağ monitörü kurulum gerektirmez — bu, panelin yerleşik bir sayfasıdır. Sunucunun ağ durumunu yerel kaynaklardan gösterir:
/proc/net/dev üzerinden;ip aracılığıyla;ss aracılığıyla;journalctl -k aracılığıyla.İlk üç kaynak sudo olmadan çalışır, bu yüzden arayüzler, trafik, bağlantılar ve portlar anında görünür. “Çekirdek olayları” bloğu journalctl -k kullanır — bu, systemd-journal grubu üzerinden okunur (“sudo yapılandırması”, madde 2), sudo gerekmez. Her şeyin web kullanıcısına erişilebilir olduğunu doğrulamak için:
UFW BLOCK kayıtları buraya düşmez — bunlar “UFW güvenlik duvarı” ve “Saldırı haritası” sayfalarındadır. Yeşil onay işaretli boş blok = son 24 saatte ağ arızası olmadı.
Yerleşik sayfa üç şey gösterir:
df); ≥%90'da çubuk kırmızıya döner;lsblk), yalnızca gerçek olanlar (loop/snap gizlidir);smartctl).Alan ve aygıt listesi ayar gerektirmeden hemen çalışır. SMART için smartmontools paketi gerekir. Web süreci disk aygıtlarına doğrudan erişemediğinden, SMART cron ile data/disk/smart.txt dosyasına yazılır, panel de onu okur.
Görev root cron'a eklenir (sudo crontab -e). Hazır sarmalayıcı smart-scan.sh, /usr/local/bin/ dizinine konur (chmod +x; cron görevleri özetine bakın) ve panelin data/disk/ dizinine kendisi yazar.
Sarmalayıcı smart-scan.sh panelin data/ dizinini kendisi bulur — yol belirtmeniz gerekmez. İçeride lsblk -e7,11 loop/cdrom'u hariç tutar.
Bu sayfa sunucunun son 24 saatteki yük geçmişini gösterir — Load Average, CPU kullanımı ve I/O bekleme, RAM/Swap, ağ trafiği (alım/gönderim), disk I/O (okuma/yazma), disk ve inode doluluğu, açık dosya tanımlayıcıları ve MySQL bağlantıları, ayrıca güncel TCP bağlantı ve süreç sayısı.
Verileri cron/collect_metrics.php toplar — 5 dakikada bir sayaçların bir “ham” anlık görüntüsünü (/proc/loadavg, /proc/meminfo, /proc/stat, /proc/net/dev, /proc/diskstats, df/df -i, /proc/sys/fs/file-nr, SHOW GLOBAL STATUS LIKE 'Threads_connected') system_metrics veritabanı tablosuna yazar; yüzdeleri ve hızları sayfa, komşu anlık görüntüler arasındaki farka göre kendisi hesaplar (disk/inode/tanımlayıcı doluluğu ve MySQL bağlantıları anlık değerlerdir, yeniden hesaplanmaz). Sudo gerekmez — kaynaklar root yetkisi olmadan okunur. 24 saatten eski noktalar her yazma işleminde otomatik silinir.
Sarmalayıcı collect-metrics-all.sh (cron görevleri özetine bakın) sunucudaki tüm kurulu panel örneklerini kendisi bulur ve her birinin cron/collect_metrics.php dosyasını site sahibi adına çalıştırır.
Yük uyarıları (“Ayarlar” → “Yük uyarıları” bölümü) — CPU/RAM/disk/inode eşiği aşıldığında panel Telegram/E-posta üzerinden bildirim gönderir (günlük raporla aynı kanallar — uyarılar için ayrıca etkinleştirmeye gerek yok), metrik normale döndüğünde de bir bildirim daha. Eşik aşımı sürerken tekrar tekrar bildirim göndermez: bir sonraki bildirim ancak “normale döndü → yeniden aşıldı” döngüsünden sonra gelir.
collect_metrics.php tarafından kontrol edilir — ayrı bir cron gerekmez. “Zaten bildirildi / henüz bildirilmedi” durumu data/alerts_state.json içinde, eşikler ise panel ayarlarında tutulur.
“Saldırı haritası” sayfası, IP adresinin ülkesini geoiplookup komutuyla belirler. GeoIP paketi olmadan ülkeler belirlenmez ve haritada noktalar görünmez:
/usr/share/GeoIP/GeoIP.dat veritabanı herkes tarafından okunabilir, sonuçlar tmp/geoip_cache.json içinde önbelleğe alınır. Haritanın kendisi (Leaflet + OpenStreetMap döşemeleri) tarayıcıda yüklenir — panelin açık olduğu bilgisayarda internet gerekir.
Bir aracın “açık/kapalı” olmasını değil, sunucunun gerçek güvenlik durumunu gösteren iki yerleşik pano kartı. Kurulum gerektirmez, sudo olmadan yerel olarak okunur.
Dış maruz kalma — kaç servisin tüm arayüzleri (0.0.0.0/[::]) dinlediği ve dışarıdan erişilebilir olduğu. Dışarıya bir veritabanı veya önbellek açıksa (MySQL, PostgreSQL, Redis, MongoDB, Memcached, Elasticsearch) kırmızı işaretler — bu doğrudan bir açıktır (Güvenlik Puanına −10). Kaynak: ss -tuln.
127.0.0.1 adresine bağlayın (MySQL/PostgreSQL yapılandırmasında bind-address, Redis'te bind 127.0.0.1) veya UFW'de portu kapatın.
127.0.0.1 (loopback) dinleyen bir servis yalnızca sunucunun kendisine görünür — port “açık” olsa bile dışarıdan erişilemez. Bu yüzden loopback'e bağlı 25 portundaki Postfix güvenlidir: otomatik yapılandırma inet_interfaces = loopback-only ayarını yapar (ayrıca nötr bir smtpd_banner — sürüm ifşasına ilişkin Lynis MAIL-8818 uyarısını kapatır). “Dış maruz kalma” kartı, dışarıya yalnızca 0.0.0.0/[::] dinleyenleri sayar; loopback servisleri buna girmez.
/etc/postfix/main.cf içinde smtpd_banner = $myhostname ESMTP (sürüm ve işletim sistemi olmadan) ve inet_interfaces = loopback-only ayarlayın, ardından sudo systemctl restart postfix.
Güvenlik güncellemeleri — kaç güvenlik yamasının kurulmayı beklediği ve çekirdek güncellemesi sonrası yeniden başlatma gerekip gerekmediği (yama varsa Güvenlik Puanına −5). Kaynak: /usr/lib/update-notifier/apt-check, /var/run/reboot-required dosyası. Ayrıntılı liste “Güvenlik güncellemeleri” sayfasında.
update-notifier-common). apt-check yoksa monitör yamaları apt-get -s upgrade ile sayar.
Otomatik güvenlik güncellemeleri (unattended-upgrades) — “Güvenlik güncellemeleri” sayfasındaki ayrı bir kart, güvenlik yamalarının otomatik kurulumunun etkin olup olmadığını ve en son ne zaman çalıştığını gösterir. Sudo gerekmez — durum apt-config dump ile okunur.
Yedek en önemli güvencedir: veri kaybı her türlü saldırıdan daha kötüdür. İki şey gerekir — sunucu/site yedeği ve ayrıca panel veritabanı yedeği (orada kullanıcılar, WebAuthn anahtarları, ayarlar, lisans bulunur).
Seçenek A — HestiaCP: kullanıcının Backup sekmesi → yedek oluşturma düğmesi (veya sunucu ayarlarında zamanlanmış olarak). Yedek, siteleri ve veritabanlarını kapsar.
Seçenek B — elle (cron): veritabanı dökümü + panelin data/ dizininin arşivi:
Yeni sürüme güncelleme. Önce yedek alın. Ardından kod dosyalarını verilerinizi koruyarak yeniden yükleyin:
public/, includes/, assets/, cron/, database/, ayrıca kök dizindeki .htaccess (ön denetleyici — yönlendirme eski sürümden kalamaz), manifest.json, sw.js;config.php (veritabanı bilgileri), data/ (raporlar), logs/, tmp/ (oturumlar ve önbellek).SSH_FX_PERMISSION_DENIED — Permission denied diyor. Panel dosyaları www-data sahipliğindedir (kurulumda böyle ayarlandı), SFTP istemcisi ise yazma izni olmayan kendi kullanıcınızla bağlanır. Tüm paneli “çalışsın diye” www-data'ya vermek tam da bu hataya yol açan şeydir; aşağıda üç yol var, herhangi biri sorunu çözer.
data/ (raporlar), tmp/ (oturumlar ve önbellek), logs/; bunlar www-data'da kalır. Geri kalanı koddur ve web sunucusunun ona yalnızca 644 izinleriyle www-data grubunun verdiği okuma erişimi gerekir. Yan fayda: PHP'de bir açıkta panel dosyaları artık yeniden yazılamaz. Barındırma panellerinde (HestiaCP ve benzerleri) A seçeneği gerekmez: orada site dosyaları zaten SFTP ile bağlandığınız hesaba aittir ve web sunucusu onları grup üzerinden okur.
chmod, ACL maskesini sıfırlar ve erişim sessizce kaybolur. “İzinleri düzene sokma” işleminden sonra yükleme yine Permission denied hatasına takılırsa — her iki setfacl komutunu tekrarlayın.
2 biti setgid'dir: SFTP ile yüklenen dosyalar www-data grubunda kalır, aksi hâlde panel onların üzerine yazamaz. C seçeneğinden sonra FileZilla'da yeniden bağlanın — yeni grup ancak yeni bir oturum açmada geçerli olur. Kontrol: id deploy (www-data grubu görünmelidir) ve ls -ld /path/to/monitor (drwxrwsr-x — s harfi setgid'in ayarlandığı anlamına gelir).
Başka bir sunucuya taşıma:
config.php, data/ ile birlikte kopyalayın.mysqldump → yenide içe aktarma; config.php içindeki veritabanı bilgilerini düzeltin.adm grubuna üyelik, cron görevleri.Giriş yapamıyorsanız her şey doğrudan sunucudaki veritabanından düzeltilebilir. Veritabanını açın (adı config.php içinde):
WebAuthn anahtarı kayboldu (ikinci faktör geçilemiyor) — 2FA'yı devre dışı bırakın, parolayla giriş yapın ve yeni bir anahtar kaydedin:
Parolayı unuttunuz — yeni bir hash belirleyin (sunucuda oluşturup yerine koyun):
IP filtresiyle kendinizi engellediniz — kısıtlamayı devre dışı bırakın:
sudo mysql, ya da phpMyAdmin / hosting panelindeki veritabanı bölümü. Kurtarmadan sonra WebAuthn ve IP filtresini yeniden etkinleştirin.
Görevlerin özeti — sunucunun root cron'unda (sudo crontab -e ile eklenir). Yalnızca kullandığınız araçlara ait satırları bırakın; yolları kendi sunucunuza göre düzenleyin.
sudo crontab -l ve cron hizmetinin etkin olduğunu.
config.php içindeki TIMEZONE değil. TIMEZONE sabiti yalnızca PHP'yi etkiler (panelin tarihleri nasıl gösterdiğini), ancak cron arka planı görevleri işletim sisteminin sistem saatine göre çalıştırır. Sunucunun dilimi sizinkiyle uyuşmuyorsa “08:00” raporu yanlış saatte gelir. Örnek: sunucu başka bir dilimde (Europe/Berlin, UTC+2), siz ise İstanbul'dasınız (UTC+3) → “08:00” raporu sizin saatinizle 09:00'da gelir. Kontrol edin ve gerekirse sistem dilimini kendinize göre ayarlayın:
0 8 * * * satırı yerel saatle 08:00'de çalışır. Aksi halde cron'un kendisini kaydırmak gerekirdi, ancak yaz/kış saatine geçişte kayma yine bozulur — bu nedenle sistem dilimini ayarlamak daha doğrudur.
crontab.txt) proje yanındaki system/ klasöründe, public_html dışında bulunur. Bu sitenin parçası değildir — web köküne yüklemeniz gerekmez; sunucuda sistem yollarına yerleştirin (yukarıdaki crontab'daki gibi):
lynis-scan.sh → /usr/local/bin/ (chmod +x) — lynis audit system çalıştırır, tarama süresince /tmp/lynis-running bayrağını koyar ve lynis-report.dat dosyasını panelin data/lynis/ dizinine kopyalar;logwatch_daily.sh → /usr/local/bin/ (chmod +x) — günlük Logwatch raporunu (sshd, fail2ban, sudo, postfix) data/logwatch/ içine oluşturur;smart-scan.sh → /usr/local/bin/ (chmod +x) — disk durumunu (smartctl) data/disk/ içine alır;debsums-scan.sh → /usr/local/bin/ (chmod +x) — paket bütünlüğünü (debsums) data/debsums/ içinde kontrol eder;clamav-scan.sh → /usr/local/bin/ (chmod +x) — tehlikeli yollarda (web, home, temp) ClamAV virüs taraması; özeti /var/log/clamav/scan.log dosyasına yazar, ClamAV sayfası onu buradan okur (yukarıdaki crontab'da 01:30 satırı);load-ipsum.sh → /usr/local/bin/ (chmod +x) — ipsum ipset kümesini (level 1) yerinde günceller, etkin güvenlik duvarı kurallarını bozmadan (yukarıdaki crontab'daki 04:00 satırı);daily-report-all.sh → /usr/local/bin/ (chmod +x) — panelin cron/daily_report.php raporunu çalıştırır (yukarıdaki crontab'da 08:00 satırı);daily_report.php — zaten panele dahildir (cron/daily_report.php), daily-report-all.sh aracılığıyla çalışır, ayrıca kurmaya gerek yoktur;collect-metrics-all.sh → /usr/local/bin/ (chmod +x) — panelin cron/collect_metrics.php betiğini çalıştırır (“Performans” sayfası, yukarıdaki crontab'da */5 satırı); collect_metrics.php zaten panele dahildir, ayrıca kurmaya gerek yoktur;crontab.txt (system/cron/) — görev örneği; gereken satırları sudo crontab -e ile ekleyin./usr/local/bin/ dizinine nasıl koyarsınız. Doğrudan FileZilla'dan oraya yazılamaz — dizin root sahipliğindedir ve SFTP istemcisi SSH_FX_PERMISSION_DENIED alır. Sıra şudur: önce dosyayı /tmp dizinine yükleyin (oraya herkes yazabilir), sonra tek komutla yerine taşıyın:
/tmp gerekir — /var/tmp değil, panelin kendi içindeki tmp/ de değil (sonuncusu www-data sahipliğindedir ve sizin kullanıcınıza kapalıdır). FileZilla ağacında /tmp, var'ın yanındaki üst düzey bir daldır, onun içinde değil.
/usr/local/bin/ içine, günlük — /var/log/arciveo-cron.log) — elle bir şey yapmanıza gerek yok.
/home/*/web/*/public_html ve /var/www/* yollarını tarayarak panel kurulumlarını bulur ve raporları onların data/ dizinine koyar. Panel başka bir yoldaysa — betiklerin içindeki for app in … satırına o yolu ekleyin, aksi halde Lynis/SMART/debsums/Logwatch raporları panele ulaşmaz.
logs/cron.log dosyasını ilk olarak root cron oluşturur — dosya root sahipliğinde olur ve paneldeki “cron Günlüğü” sekmesi onu ne okuyabilir ne de temizleyebilir. Dosyayı önceden web kullanıcısı adına oluşturun (site dizininin sahibi; HestiaCP'de bu, ör. admin hesabıdır) — böylece root cron sahibi değiştirmeden yalnızca ekleme yapar:
stat -c %U /path/to/monitor.
sudo crontab -e), aksi halde iki kez çalışır.
sudo crontab değil (bu, panel oturumuna erişen herkes için root'a doğrudan yükseltme olurdu), yalnızca kendi bloğuna hizmet yorumları arasında dokunan, iki komutlu (list/set) dar bir betik. Bir kez kurun:
www-data'dan farklı olabilir — sitenin PHP-FPM havuzunun hangi kullanıcı altında çalıştığını kontrol edin (ps -o user= -C php-fpm) ve onu sudoers satırına koyun.
public/crontab_monitor.php dosyası FTP/SFTP ile diğer site dosyalarından farklı bir sistem kullanıcısıyla (örneğin root) yüklendiyse, web sunucusu onu okuyamaz. Sahibini ve izinleri komşu dosyayla karşılaştırıp eşitleyin:
Monitor, araçların varlığını dpkg-query — APT paket veritabanı üzerinden belirler. Araç apt ile kurulmadıysa (elle, snap ile ya da kaynaktan), dpkg onu görmez.
500 hatası — PHP, nginx ve monitörün kendi loglarını kontrol edin:
www-data altında değil, kullanıcı hesabı altında çalışır (örneğin admin — site dizininin sahibi). Tüm sudo kuralları ve grup üyelikleri (adm, systemd-journal) bu kullanıcı için tanımlanmalıdır, aksi halde servisler çalışırken modüller “Etkin değil / 0” gösterir. Gerçek PHP kullanıcısını öğrenmek için: ps -o user= -C php-fpm | sort -u veya site dizininin sahibi stat -c '%U' /path/to/monitor. Ardından aşağıdaki tüm komutlarda www-data yerine onu yazın. Otomatik kurulum web kullanıcısını kendisi belirler ve sudoers'ı ona göre tanımlar.
Veriler görüntülenmiyor — neredeyse her zaman tanımlanmamış sudo izinleri yüzündendir. İlgili komutu web kullanıcısı adına kontrol edin (www-data yerine kendi kullanıcınızı yazın). -n bayrağı = PHP'deki gibi parolasız — parola isterse, sudoers'ta kural yok demektir:
sudo aa-status profilleri gösteriyor, ama “AppArmor” sayfası “Etkin değil” diyor). Nedeni: web kullanıcısının o modülün komutu için sudo izni yok. Onu yukarıdaki listeden kontrol edin: parola isterse — /etc/sudoers.d/monitor dosyasına eksik satırı ekleyin (“sudo ayarı”). Sık karşılaşılan “yeni” komutlar: /usr/sbin/aa-status (MAC), /usr/sbin/psad --Status (PSAD).
apache2ctl, ausearch, aa-status ya da ss izinli değil, veya web kullanıcısı adm/systemd-journal gruplarında değil (fail2ban/auth/modsec logları ve journalctl — Falco ve çekirdek olayları buradan okunur).
Belirti: sunucuda veri var (shell üzerinden görünüyor), ancak sayfa “veri yok” gösteriyor veya yanlış durum bildiriyor — örneğin veritabanı oluşturulmuş olmasına rağmen AIDE “Başlatılmadı” yazıyor.
Neden open_basedir: birçok panel ve barındırma sağlayıcısı PHP-FPM havuzunu domain dizinine kısıtlar, bu yüzden sistem yollarındaki (/var/lib/aide, /var/log, /proc…) file_exists(), file_get_contents(), filemtime() PHP fonksiyonları engellenir. Monitör bunu, söz konusu yolları standart sistem komutlarıyla (cat, test, stat) okuyarak aşar.
open_basedir'dir. Doğru çözüm sistem komutlarıyla okumadır (AIDE ve Ağ monitörü için zaten yapıldı). open_basedir ayarını /var, /proc yollarına genişletmek gerekmez ve daha az güvenlidir.
Monitör, sertifikaları alan adlarına 443 portu üzerinden doğrudan bağlanarak kontrol eder. Alan adı sunucunun kendisinden erişilemiyorsa veya port güvenlik duvarınca kapalıysa kontrol başarısız olur.
/etc/nginx/sites-enabled/, /etc/nginx/conf.d/) ve Apache (/etc/apache2/sites-enabled/) yapılandırmalarından, ayrıca HTTP_HOST üzerindeki geçerli ana bilgisayardan alır.
Monitor, MySQL'e config.php içindeki, yalnızca kendi veritabanına erişimi olan kullanıcıyla bağlanır. MySQL, information_schema içinde yalnızca yetkisi olan veritabanlarını gösterir; bu yüzden diğerleri görünmez.
Monitorün tüm veritabanlarını görebilmesi için bu kullanıcıya yalnızca okuma yetkisi verin (root ile bir kez; config.php içindeki kullanıcı adını girin):
sudo mysql kullanmaz: veritabanı listesi kendi PDO bağlantısı üzerinden alınır.
PostgreSQL, postgres kullanıcı düzeyinde erişim gerektirir; panelin web kullanıcısında ise bu erişim yoktur. PHP üzerinden geniş yetkili sudo psql açmak güvenli değildir — bunun yerine panel, yalnızca sürümü, bağlantı sayısını ve veritabanlarının boyutlarıyla listesini yazan, parametresiz dar bir sarmalayıcı çağırır. Bunu oluşturun:
monitor-pgstat satırını sudoers'tan kaldırın (manuel kurulumun 13. adımı) ve betiği hiç oluşturmayın: PostgreSQL kartı yalnızca etkin olmayan durumda kalır.
Panel ne olduğunu gösterir; aşağıda ise tipik durumlarda ne yapılacağı var. Genel ilke: paniğe kapılmayın, meşru etkinlikle (kendi işlemleriniz, güncellemeler, yedekler) karşılaştırın ve ciddiyetine göre tepki verin.
ignoreip içinde olduğundan emin olun./etc ve /usr/share dışında) — olası bir değiştirme. Paketi karşılaştırın: debsums PACKAGE_NAME, şüphe halinde yeniden kurun (apt install --reinstall).127.0.0.1 adresine bağlayın veya UFW'de portu kapatın. Bu gerçek bir açıktır.certbot renew komutunu veya panel ayarlarını kontrol edin).sudo apt update && sudo apt upgrade; çekirdek güncellemesinden sonra sunucuyu yeniden başlatın.