Linux VPS’i vps-audit ile Denetleme—ve Sonuçları Doğru Şekilde Okuma

Hızlı VPS Denetimi Bir Başlangıç Noktasıdır, Bir Karar Değildir

Web siteniz yüklenir ve SSH yanıt verir, ancak bu bekleyen güncellemeleri, izin verici SSH ayarlarını veya beklenmedik dinleyicileri ortaya koymaz. İlk geçiş denetimi bu soruları ortaya çıkarır.

vps-audit, Debian ve Ubuntu için yerel yapılandırma, bakım, dinleyici ve kaynak sinyallerini renkli kodlanmış bir rapora dönüştüren bir Bash kontrol listesidir. Bir araç panosunda olduğu gibi, her nedeni tanılamadan incelenmesi gereken alanları gösterir.

Bu kılavuz, sabitlenmiş vps-audit v0.2.0‘ı güvenli bir şekilde çalıştırır, önemli sonuçları yerel araçlarla kontrol eder ve bunları önceliklere dönüştürür. Örnek, Ubuntu 24.04 LTS çalıştıran bir AlexHost Ubuntu VPS kullanır. Diğer sağlayıcı görüntüleri farklı olabilir ve yönetilmeyen konuk işletim sistemi operatörün sorumluluğu altında kalır.

vps-audit’in Kontrol Ettiği Şeyler—ve Kanıtlayamadığı Şeyler

vps-audit yerel göstergeleri kontrol eder, ancak hiçbir alanı kapsamlı olarak incelemez. Bu tablo, her sonucun size ne söyleyebileceğini—ve ne söyleyemeyeceğini—gösterir.

SUID, bir programın dosya sahibinin etkili ayrıcalıklarıyla çalışmasını sağlar. Yasal sistem programları bunu kullanır, bu nedenle beklenmeyen bir SUID dosyasını silmek yerine araştırın. Fail2ban ve CrowdSec düşmanca trafiği engelleyebilir, ancak kurulum veya etkin durum tek başına amaçlanan hizmeti koruduğunu kanıtlamaz.

Betik, kaynak kullanımı, hizmetler, başarısız girişler ve dinleyicilere genel eşikler uygular. Bunlar iş yüküne duyarlı risk puanları değildir; farklı VPS rolleri aynı renge farklı nedenlerle ulaşabilir.

Araç kötü amaçlı yazılım, bilinen güvenlik açıkları, uygulamalar, kapsayıcılar, sağlayıcı güvenlik duvarları, uyum veya eğilimleri incelemez. README’si “Etkin İnternet Bağlantıları”ndan bahsetse de, v0.2.0 yalnızca genel IP’yi getirir ve yerel dinleyicileri envanterler. Ayrıcalıklı görünürlüğe ihtiyaç duyduğundan, önce hangi dosyanın sudo erişimi aldığını kontrol edin.

İndirilen Bir Betiğe sudo Vermeden Önce

Bu Debian/Ubuntu iş akışı SSH erişimi, sudo ve aşağıda kullanılan standart araçları gerektirir. Tek kullanımlık bir dizinde çalışın. Bir araç eksikse, temeli değiştirmek yerine durdurun.

Örnek, 10 Ağustos 2026’da yayınlanan ve 8 Eylül 2026’da kontrol edildiğinde hala en son olan vps-audit v0.2.0 kullanır.

Etiketi commit 57c323d46b48026740f0b35b9bad6cd6127c757b işaret eder. Sabitleme, değişken main dalından sonraki bir değişikliği önler.

Özel bir dizin oluşturun ve bu tam etiketli betiği HTTPS üzerinden indirin:

mkdir -p "$HOME/vps-audit-test"
cd "$HOME/vps-audit-test"
curl -fL --proto '=https' --tlsv1.2 
  -o vps-audit.sh 
  https://raw.githubusercontent.com/nuver-labs/vps-audit/v0.2.0/vps-audit.sh

Bu, vps-audit.sh dosyasını yeni dizine kaydeder. -f seçeneği HTTP hatalarında başarısız olur, -L ise yönlendirmeleri izler.

Ardından, yerel bir SHA-256 parmak izi kaydedin ve bu izlenecek yol için ilgili ayarları görüntüleyin:

sha256sum vps-audit.sh
grep -nE '^(VPS_AUDIT_VERSION|RESOURCE_(WARN|FAIL)|SERVICES_(WARN|FAIL)|LOGINS_(WARN|FAIL)|OPEN_PORTS_(WARN|FAIL)|PASSWORD_MINLEN|DEFAULT_REPORT_DIR|ENABLE_CHOWN)=|api.ipify.org' vps-audit.sh

Çıktı dosyayı parmak izler ve rapor yolunu, eşikleri ve api.ipify.org isteğini gösterir. Tam etiketli kaynak ayrıca yerel durumu okur, apt-get -s upgrade simüle eder ve SUID dosyalarını özyinelemeli olarak arar. Salt okunur değildir: bir rapor yazar, dizinini oluşturabilir ve harici bir hizmetle iletişim kurar. Yükseltilmiş ayrıcalıklar veriyorsanız ve shell kodunu okuyabiliyorsanız kaynağı gözden geçirin.

Kaynak eşikleri WARN için %50 ve FAIL için %80’dir. Çalışan hizmetler 20/40, başarısız girişler 10/50, dinleyiciler nominal olarak 10/20 ve parola uzunluğu 12 kullanır. Sınırlamalar bölümü dinleyici durumunun bu değişkenleri neden takip etmediğini açıklar.

⚠️ Uyarı: Sabitleme, hashing, hedefli inceleme ve sözdizimi kontrolü yeniden üretilebilirliği iyileştirir ancak güven kurmaz. Commit imzasız ve sürüm hiçbir sağlama toplamı veya imza varlığı sağlamaz.

Özeti denetim notlarıyla birlikte tutun. Bir çalıştırmadan önce, bunu dosyayla karşılaştırın. Eşleşme, kopyaların aynı baytları içerdiğini gösterir. Bir fark, başka bir sürümden, değiştirilmiş bir indirmeden veya yerel bir düzenlemeden gelebilir. Etiketi ve özeti kaydetmek, her raporu onu üreten betiğe bağlar.

Son olarak, dosyayı normal komutlarını çalıştırmadan ayrıştırın, ardından ayrıştırma başarılı olursa yalnızca yürütme izni ekleyin:

bash -n vps-audit.sh 
  && chmod +x vps-audit.sh 
  && printf 'Syntax check: PASS; execute permission addedn'

Bu yalnızca Bash’in dosyayı ayrıştırabileceğini ve yürütme izninin eklendiğini doğrular. Sabitlenmiş betik artık bir değişmemiş çalıştırma için hazırdır.

vps-audit’i Çalıştırın ve Raporu Bulun

Betik sistem ayrıntılarını ve renkli durumları yazdırır, ardından düz metin raporu yazar. Özyinelemeli SUID araması çalışma zamanını değişken hale getirir, bu nedenle ölçün.

Sabitlenmiş dosyayı bir kez çalıştırın ve shell işleminin çıkış durumunu koruyun:

printf 'Audit started: '
date -u '+%Y-%m-%d %H:%M:%S UTC'
TIMEFORMAT=$'Elapsed real: %3R secondsnUser CPU: %3U secondsnSystem CPU: %3S seconds'
time sudo ./vps-audit.sh
AUDIT_STATUS=$?
printf 'Audit exit status: %sn' "$AUDIT_STATUS"

Test edilen VPS’de denetim 14 Eylül 2026’da 13:12:10 UTC’de başladı ve 58.412 saniyede tamamlandı. 0 döndürdü ve ./vps-audit-report-20260914_131210.txt kaydetti.

Elapsed real duvar saati zamanıdır; kullanıcı ve sistem değerleri CPU zamanını ölçer. Çıkış durumu 0, işlemin tamamlandığı anlamına gelir, her kontrolün geçtiği anlamına gelmez. v0.2.0, FAIL sonuçları olsa bile 0 döndürür.

Yeni raporu seçin, meta verilerini inceleyin ve sayıları ve örnekleri hassas dosyayı tam olarak görüntülemeden çıkarın.

REPORT=$(ls -1t ./vps-audit-report-*.txt 2>/dev/null | head -n 1)
if [ -z "$REPORT" ]; then
    printf 'No vps-audit report found in the current directory.n' >&2
    exit 1
fi
printf 'Report selected: %sn' "$REPORT"
sudo stat --format='Owner: %U:%G | Mode: %A (%a) | Size: %s bytes | Modified: %y' "$REPORT"

for status in PASS WARN FAIL; do
    count=$(sudo grep -c "^\[$status\]" "$REPORT" || true)
    printf '%s: %sn' "$status" "$count"
done

sudo grep -E '^[(PASS|WARN|FAIL)] (Running Services|Disk Usage|Password Policy)' "$REPORT"

Raporun 13:13:08 UTC değiştirilme zamanı çalıştırmayla eşleşti. On yedi sonuç içeriyordu: altı PASS, üç WARN ve sekiz FAIL. Bunlar sınıflandırmalar, güvenlik puanı değildir.

Durum toplamları aynı sürümün çalıştırmaları karşılaştırırken yararlıdır, ancak her zaman bir değişikliğin arkasındaki satırları inceleyin. Daha düşük bir FAIL sayısı, iyileştirmeden ziyade farklı giriş veya ayrıştırıcı davranışından kaynaklanabilir. Değişmeyen bir toplam, çözülen bir sorunu ve yeni bir sorunu gizleyebilir.

2.665 baytlık rapor root:root‘a ait ve 644 modu (-rw-r--r--) ile, sudo ve stok ENABLE_CHOWN=false ile beklendiği gibi. Grup ve diğer kullanıcılar, dizin izinleri dosyaya ulaşmalarına izin verirse bu modu okuyabilir. Yalnızca root sahipliği onu özel yapmaz.

❗ Önemli: Rapor ana bilgisayar adını, genel IP’yi, sistem ayrıntılarını ve bulguları içerir. Özel tutun ve paylaşmadan önce tanımlayıcıları, istemleri ve hassas hizmet bilgilerini düzeltin.

Gelecekteki bir çalıştırma bir durumdan yoksunsa, VPS’yi bir renk üretmek için yeniden yapılandırmak yerine bu yokluğu kaydedin.

PASS, WARN ve FAIL Sonuçlarını Aşırı Tepki Vermeden Okumak

Dashboard etiketleri her testin v0.2.0 kurallarıyla nasıl eşleştiğini gösterir:

Gözlemi tavsiyeden ayırın. “22 hizmet çalışıyor” ifadesinde sayı gözlem, “saldırı yüzeyini azalt” ise genel bir eşiğe dayalı tavsiyedir. Sayıyı doğrulayın, hizmetleri tanımlayın ve ardından bu tavsiyenin sunucuya uygun olup olmadığına karar verin.

Her sonuç için üç soru sorun: Değer doğru mu? Kasıtlı mı? Gerçekçi etkisi nedir? Yerel komutlar değeri kontrol eder; iş yükü bağlamı geri kalanını belirler.

SSH-port WARN politika tabanlıdır: v0.2.0 port 22’yi işaretler. SSH’yi taşımak otomatik gürültüyü azaltabilir ancak güçlü kimlik doğrulamayı veya erişim kontrollerini değiştiremez. Port 22’deki bilinen bir hizmet, bilinmeyen bir wildcard dinleyicisinden daha az önemli olabilir.

FAIL için kuralı düzeltme önerisinde bulunmadan önce inceleyin. Root-login testi yalnızca PermitRootLogin no değerini kabul eder, bu nedenle farklı prohibit-password ayarı yine başarısız olur. Harekete geçmeden önce OpenSSH’yi doğrudan kontrol edin.

PASS da bağlam gerektirir. unattended-upgrades için script yalnızca paketin var olduğunu doğrular—yapılandırmasını veya çalıştırma geçmişini değil.

Yüksek Etkili Bulguları Yerel Komutlarla Doğrulayın

SSH erişimini, ana bilgisayar filtrelemesini ve yerel dinleyicileri kontrol etmek için salt okunur yerel komutları kullanın. İlk olarak, OpenSSH’nin varsayılanlar ve dahil edilen konfigürasyon birleştirildikten sonra gerçekte neyi çözdüğünü sorun:

sudo sshd -T 
  | grep -E '^(port|listenaddress|permitrootlogin|passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication) '

Ubuntu, /etc/ssh/sshd_config.d/*.conf dosyalarını ana konfigürasyonunun başlangıcında yükler. sshd -T birleştirilmiş ayarları çözer, bu da tek bir dosyayı grep’lemekten daha güçlü kanıt olur.

OpenSSH, port 22’yi joker IPv4 ve IPv6 adreslerinde çözmüştür. Ayrıca permitrootlogin yes, passwordauthentication yes, pubkeyauthentication yes ve kbdinteractiveauthentication no döndürmüştür. Çözülen konfigürasyon, komut dosyasının root-login ve password-authentication bulgularını doğrular, ancak hesap durumu, PAM ve Match kuralları belirli bir oturum açmayı etkileyebilir.

İkinci olarak, UFW’nin kendi durumu ve yönetilen politikası hakkında ne bildirdiğini sorun:

sudo ufw status verbose

Ubuntu, UFW’yi varsayılan güvenlik duvarı ön ucu olarak belgeler. Burada düşük seviye günlüğe kaydetme ve gelen ve yönlendirilmiş trafik için varsayılan reddetme politikaları ile etkindir. Kurallar IPv4 ve IPv6 üzerinden 22, 80, 443 ve 37985 numaralı bağlantı noktalarına gelen trafiğe izin vermiştir. Bu, UFW’nin durumunu doğrular, her kuralın uygun olup olmadığını değil.

Üçüncü olarak, yerel TCP ve UDP dinleyicileri, bağlama adreslerini ve sahip olan işlemleri listeleyin:

sudo ss -lntup

Seçenekler sayısal TCP ve UDP dinleyicilerini seçer ve işlem ayrıntılarını talep eder. 53, 62789, 8404 ve 11111 numaralı bağlantı noktaları yalnızca loopback idi; 22, 80, 2096, 5678 ve 37985 numaralı bağlantı noktaları joker adresler kullandı. İşlem ayrıntıları görünmedi, bu nedenle sahipleri ve amaçları bilinmiyor.

process listener
    → bind address / interface
    → host firewall
    → provider-edge firewall or NAT
    → external network path

22, 80 ve 37985 numaralı bağlantı noktalarının hem joker dinleyicileri hem de UFW izin kuralları vardı. UFW, dinleyici olmadan 443’e izin verirken, 2096 ve 5678’in görüntülenen izin kuralları olmadan dinleyicileri vardı.

Bir güvenlik duvarı kuralı ve bir dinleyici farklı soruları yanıtlar. Kural, hizmeti kabul etmek için bir hizmet varsa trafiğe izin verir; dinleyici bir hizmetin beklediğini gösterir, ancak ağ trafiğinin ona ulaşıp ulaşamayacağını değil. Her ikisini birlikte okumak, harici maruziyeti iddia etmeden araştırmayı daraltır.

📝 Not: ss yerel bağlama durumunu gösterir ve UFW bir ana bilgisayar güvenlik duvarını gösterir. İkisi de sağlayıcı güvenlik duvarları veya NAT’ı aşan İnternet erişilebilirliğini kanıtlamaz; bu, başka bir sistemden yetkili test gerektirir.

v0.2.0 yine de bağlama adreslerini atıp aynı listeyi “Total” ve “Public” olarak etiketler, ancak dokuz TCP bağlantı noktasından dördü yalnızca loopback idi. LISTEN filtresi ayrıca UNCONN olarak işaretlenen UDP satırlarını kaçırır. Bu sonucu yerel TCP bağlantı noktası sayısı olarak okuyun, genel maruziyeti değil.

Doğrulanmış Bulguları Pratik Bir İşlem Kuyruğuna Dönüştürün

Önceliği güven, maruz kalma, etki ve niyet temelinde belirleyin. Öncelik 1, işlem gerektiren doğrulanmış zayıflıkları kapsar. Öncelik 2, hala araştırma gerektiren önemli bulguları kapsar; Öncelik 3, daha düşük riskli veya politika odaklı öğeleri kapsar. Bir ayar kasıtlıysa, nedenini, herhangi bir telafi edici kontrolü ve ne zaman gözden geçireceğini belgelendirin.

Tablo bu yaklaşımı bu çalıştırmaya uygular; eksik kanıt bir önceliği geçici tutar:

Öncelik 2 zararsız anlamına gelmez; kanıt eksik kalır. Her çözülmemiş öğeye bir sahip ve son tarih verin. Doğrulama maruz kalmayı veya zayıflığı doğrularsa yükseltin. Kasıtlıysa ve kontrol altındaysa, kararı açıkça kaydedin.

Rapor etiketi sırayı belirlemez: doğrulama ve bağlam belirler.

⚠️ Uyarı: Bu komut dizisinden SSH kimlik doğrulamasını veya uzak güvenlik duvarı kurallarını değiştirmeyin. Bir hata sizi kilitleyebilir. Düzeltmeden önce test edilmiş anahtar erişimini doğrulayın ve yeni yapılandırmayı doğrulayın. İkinci bir oturumu açık tutun ve konsol veya kurtarma erişiminin çalıştığından emin olun.

Her düzeltmeyi ayrı bir iş akışı olarak işleyin. Hizmetleri durdurmadan önce bağımlılıkları eşleyin, güncellemeleri planlamadan önce sınıflandırın ve SUID izinlerini değiştirmeden önce sahipliği ve sağlama toplamlarını doğrulayın.

vps-audit’ın Görünümünün Durduğu Yer

vps-audit v0.2.0 belirli bir zaman noktasında Bash kontrol listesidir. Harici maruziyeti belirleyemez, güvenlik açıklarını veya kötü amaçlı yazılımları tespit edemez, iş yüklerini inceleyemez, depolanan günlükleri analiz edemez veya sürekli izleme sağlayamaz. Bu bir penetrasyon testi veya CIS Benchmark değerlendirmesi değildir.

Kod önemli uyarılar ekler.

• Port durumu üç ayrıştırılmış TCP portunun altında PASS, üç veya dört tanesinde WARN ve beş veya daha fazlasında FAIL olur—nominal 10/20 değişkenlerine rağmen.
• Bir unattended-upgrades PASS yalnızca paketi kontrol eder, yapılandırmasını, zamanlayıcısını veya çalıştırma geçmişini değil.
• Güncelleme testi, genel apt-get -s upgrade için önbelleğe alınmış meta verileri kullanır, ardından listelenen her paketi “güvenlik güncellemesi” olarak adlandırır.

sudo-logging testi yalnızca /etc/sudoers dosyasını okur, /etc/sudoers.d/ ve normal journal veya syslog kayıtlarını kaçırır. Issue #33, 8 Eylül 2026’de kontrol edildiğinde açık, Ubuntu 20.04 ve 24.04’te yanlış FAIL belgelenmiştir. Ayrıştırma, İngilizce olmayan çıktıyla da başarısız olabilir; bu durum açık issue #37‘de izlenmektedir. README ifadesine rağmen, bu sürüm kurulu bağlantıları listelemez.

Gerektiğinde incelemeyi genişletin. Şüpheli davranış, depolanan günlük ve iş yükü analizi gerektirir. Önemli bir VPS için, test edilmiş yedeklemeleri doğrulayın ve yetkili harici testi düşünün. Kritik veya düzenlenmiş sistemler Lynis, Ubuntu 24.04 CIS Benchmark veya profesyonel incelemeyi gerektirebilir.

Sonuç: Doğrulayın, Önceliklendirin ve Yeniden Kontrol Edin

Orijinal raporu gizli tutun ve redakte edilmiş bir kopya saklayın. Betiğin SHA-256, etiketi ve commit’ini çalışma zamanı, amaçlanan hizmetler, doğrulama sonuçları ve eylem kuyruğu ile birlikte kaydedin.

1. Sunucuyu değiştirmeden önce yüksek etkili bulguları yerel komutlarla doğrulayın.
2. Onaylanan yüksek riskli sorunları güvenle düzeltin, bilinmeyenleri araştırın ve kasıtlı istisnalar belgelendirin.
3. Değişikliklerden sonra veya düzenli olarak aynı sabitlenmiş sürümü yeniden çalıştırın, ardından raporları manuel olarak karşılaştırın.

Raporları karşılaştırırken kimlik doğrulama değişiklikleri, güvenlik duvarı kuralları, dinleyiciler ve çözülen bulgulara odaklanın. Zaman damgaları ve kaynak okumaları değişecektir. Sonraki gözlemcinin sonuçların neden farklı olduğunu anlaması için kasıtlı değişiklikleri not alın.

vps-audit’in temel veri tabanı, zamanlayıcı, trend analizi veya karşılaştırma motoru yoktur. Değeri tekrarlanabilir bir alışkanlıktan gelir: çalıştırın, doğrulayın, önceliklendirin ve yeniden kontrol edin.