Web sitesi güvenlik açığı taraması: ham çıktıdan doğru karara

Tarayıcının çıktısını açtınız ve gözünüzün önünde 47 kırmızı madde var. Bunlardan biri «Critical» ve saat gece 11. Gerçek soru tarayıcının ne söylediği değil; gerçek soru bu 47 maddeden hangisinin sunucunuzda gerçekten istismar edilebilir olduğudur. Eğer şimdi hepsini alfabetik sırayla kapatmaya başlarsanız, iki gün harcarsınız ve asıl açık el değmemiş kalabilir.

Güvenlik açığı taraması bir anlık fotoğraftır, teşhis değil. Araç yalnızca «gördüğüm sürümün deseni bilinen bir CVE ile uyuşuyor» der. Bu, «bu sunucu istismar edilebilir» demekten uzaktır. İlk günkü tüm işiniz, bu iddiayı savunulabilir bir evet veya hayıra dönüştürmektir.

Taramadan önce kapsamı kâğıda dökün

Kapsamsız tarayıcı yalnızca gürültü üretir. İlk çalıştırmadan önce üç şeyi belirleyin: sahibi olduğunuz alan adları ve alt alan adları, gerçekten hizmet veren portlar ve üzerlerinde test yapma izniniz olan servisler. Kiralık altyapı üzerinde çalışıyorsanız, koordinasyonsuz ağır tarama sağlayıcı gözünde saldırı gibi görünebilir ve IP'nizin bloklanmasına yol açabilir.

Pratik bir not: unutulmuş alt alan adlarında ana alan adından daha fazla açık bulunur. Altı ay önce oluşturulmuş ve hâlâ eski WordPress sürümüyle açılan bir staging.example.com, genellikle en kolay giriş noktasıdır. Alt alan adları listesini SSL sertifikalarından ve DNS kayıtlarından oluşturun; DNS ve ağ sorgulama araçları tam da bu aşama içindir.

Ücretsiz araçları nasıl ve hangi bayraklarla çalıştırmalıyız

Web yüzeyi için Nmap ve Nuclei iyi bir çalışma kombinasyonudur. Nmap saldırı yüzeyini görmek için, Nuclei bilinen desenleri eşleştirmek için.

nmap -sV -Pn -T3 --top-ports 1000 -oA scan-web example.com

-sV bayrağı servis sürümünü okur, -Pn başlangıç ping'ini atlar (birçok güvenlik duvarı ICMP'yi kapatır ve bu bayrak olmadan tarama boş döner) ve -T3 hızı muhafazakâr modda tutar. -T4 ile daha hızlı olur ama paylaşımlı bağlantılarda paket kaybedersiniz ve sonuç eksik çıkar.

Nuclei için önce şablonları güncelleyin, sonra belirli bir şiddetle çalıştırın:

nuclei -update-templates
nuclei -u https://example.com -severity critical,high -rl 30 -o nuclei-out.txt

-rl 30 bayrağı istek hızını saniyede 30'da tutar. Bu olmadan Nuclei küçük bir siteye küçük bir saldırı kadar istek gönderebilir ve kendisi 503 hatasına neden olur. Site DDoS koruması arkasındaysa, kendinizin bloklanmaması için bu hızı daha da düşürün.

Sunucu içinden tarama, yalnızca dışarıdan değil

Dış tarama yalnızca açık portları görür. Eski paketleri, localhost üzerinde dinleyen servisleri ve dosya izinlerini görmek için içeriden de bakmalısınız:

ss -tulpn
apt list --upgradable 2>/dev/null | grep -i security

ss çıktısı sıklıkla hiçbir dış tarayıcının göremediği şeyleri gösterir: 0.0.0.0:3306 üzerinde dinleyen bir MySQL, oysa yalnızca 127.0.0.1 üzerinde olmalıydı. Bu gerçek bir bulgudur ve kapatması beş dakika sürer.

Neden her bulgu gerçek bir güvenlik açığı değildir

Üç bulgu kategoriniz var ve bunlara ayrı ayrı yaklaşmalısınız.

Yanlış pozitifi ne küçümseyin ne de büyütün. WordPress sürümünü meta etiketten okuyan bir tarayıcı, siz sürümü functions.php içinde kaldırdığınızda ama önbellek hâlâ eski sürümü sunduğunda yanlış uyarı verir. Doğrulama yolu manuel istektir:

curl -sI https://example.com/wp-content/plugins/foo/readme.txt | head -5

404 alırsanız bulgu kapanmıştır. Sürüm numarasıyla 200 alırsanız bulgu gerçektir ve listenin başına gitmelidir.

Burada hata yapıyorlar

Gördüğüm en yaygın hata şudur: ekip tüm «High» bulgularını kapatır ve tarayıcının iş mantığını hiçbir zaman görmediğini unutur. Sonuç şu olur: üç hafta sonra, zayıf parolalı bir yönetici, deneme sınırlaması olmayan bir panelden tüm siteyi ele geçirir. Tarayıcı o yolu «sağlıklı» olarak işaretlemişti çünkü bilinen hiçbir CVE'si yoktu.

İşareti de açıktır: güvenlik panosu yeşildir, ama giriş kaydında tek bir IP'den yüzlerce başarısız deneme görülür. Denetim kaydını el değmemiş tutmuyorsanız, bunu bile göremezsiniz; denetim kaydı saklama her periyodik taramanın ön koşuludur, yan iş değil.

Zaman azken doğru düzeltme sırası

1. İnternetten erişilebilen ve kimlik doğrulaması olmayan her şey: açık yönetici paneli, genel phpMyAdmin, tahmin edilebilir adlı yedek dosya.
2. Yayımlanmış genel exploit'i olan savunmasız sürümler. Bunları saldırgan özel bilgi olmadan çalıştırır.
3. Yanlış yapılandırma: dosya izinleri, güvenlik başlıkları, REST API erişimi.
4. Küçük bilgi ifşası: servis sürümü, tam hata mesajı, dizin listeleme.

Bu sırayı değiştirmeyin. Dördüncü maddeyi birinciden önce kapatmak ilerleme hissi verir ama gerçek riski azaltmaz.

Maliyetle ilgili bir uyarı: otomatik periyodik tarama çok gürültü ve az bakım gerektirir; insan yorumuyla manuel tarama daha kesindir ama her seferinde birkaç saat alır. Sitenizde ondan az servis varsa, ben aylık manuel taramayı seçerim. Elliden fazla servisiniz varsa otomasyon zorunludur, ama biri çıktıyı haftalık gözden geçirmelidir, yoksa raporlar okunmadan depolanır.

Düzeltmeden sonra tekrar tarayın ve farkı kaydedin

Doğrulama taraması olmadan yapılan her düzeltme bir varsayımdır. Bir bulguyu kapattıktan sonra aynı komutu tekrar çalıştırın ve önceki ile sonraki çıktıyı yan yana tutun. Bunun iki faydası vardır: düzeltmenin gerçekten işe yaradığını doğrular ve hangi bulguların her seferinde geri döndüğünü size gösterir. Üst üste üç taramada geri dönen bir bulgu, kökünü kapatmadığınız anlamına gelir; yalnızca işaretini silmişsinizdir.

WordPress üzerinde çalışıyorsanız, bu bulguların büyük kısmı iki yerden gelir: terk edilmiş eklentiler ve açık REST API. Bir sonraki taramadan önce WordPress REST API güvenliği ve WordPress sıkılaştırma işlemlerini yapın ki liste daha kısa başlasın.

Ve sıklıkla gözden kaçan bir nokta: sunucunuz bir ağ koruma katmanının arkasında değilse, tarama resmin yalnızca bir parçasıdır. Raporda görmediğiniz saldırıların bir kısmı, uygulamaya ulaşmadan önce filtrelenmesi gerekenlerdir. DDoS koruması bu katmanı kapsar ve taramanın tamamlayıcısıdır, yerine geçmez.

Bu döngüyü bir rutine dönüştürmek istiyorsanız, küçük ve sınırlı bir taramayla başlayın, çıktıyı manuel yorumlayın ve ancak hangi bulguların altyapınız için anlam taşıdığını anladıktan sonra otomasyona geçin. Bu süreçte ihtiyaç duyacağınız servisler için ServerNet sunucu güvenliği hizmetleri iyi bir başlangıç noktasıdır.

Sık sorulan sorular

Web sitesi güvenlik açığı taraması siteyi yavaşlatır mı?

Evet, istek hızını sınırlamazsanız. Nuclei gibi tarayıcılar -rl bayrağı olmadan saniyede yüzlerce istek gönderebilir ve küçük sunucularda yanıt süresinin artmasına veya 503 hatasına neden olabilir. Saniyede 20 ila 30 istek hızıyla ve taramayı düşük trafikli saatlerde çalıştırarak, gerçek kullanıcılar üzerinde belirgin bir etki görmezsiniz.

Tarayıcı neden bir şey bulmuyor ama site hacklenmiş?

Çünkü tarayıcı yalnızca bilinen desenleri görür. Sızma zayıf parola, token ifşası veya özel kodunuzdaki mantıksal bir güvenlik açığı yoluyla gerçekleştiyse, eşleştirilecek hiçbir CVE yoktur. Bu durumda tarayıcıya değil, erişim kayıtlarına, değiştirilmiş dosyalara ve şüpheli kullanıcı hesaplarına bakmalısınız.

Ne sıklıkla tarama yapmalıyım?

Çok sayıda eklenti içeren dinamik siteler için ayda en az bir kez. Her büyük güncellemeden veya yeni eklenti kurulumundan sonra da hedefli bir tarama gerekir. Sabit altyapıda günlük tarama genellikle gürültü üretir ve kimse çıktıyı okumaz.

Dışarıdan tarama yeterli mi yoksa sunucu içinden de çalıştırmalı mıyım?

Her ikisi de gereklidir. Dış tarama gerçek saldırı yüzeyini gösterir, ama yalnızca localhost üzerinde dinleyen servisleri veya yanlış dosya izinlerini görmez. Sunucunun kendisinde ss -tulpn komutu, saniyeler içinde hiçbir dış tarayıcının erişemeyeceği şeyleri ortaya çıkarır.