Yeni bir VPS'i ilk saatte sertleştir

Bir saattir çevrimiçi olan bir sunucuda journalctl -u ssh komutunu izleyin; ilk gördüğünüzde hacim endişe verici gelecektir. Aslında öyle olmamalı. Gördüğünüz şey internetin fon gürültüsüdür: bazıları akademik, bazıları ticari, bazıları suç amaçlı bir avuç tarama operasyonu, tüm IPv4 uzayını kesintisiz olarak numaralandırır ve sonuçları kimlik bilgisi tahmin eden botlara teslim eder. Adresinize ulaşılmasının nedeni, sayısal sırada var olmasıdır ve siz ne yaparsanız yapın birkaç saat içinde tekrar ulaşılacaktır.

Bu, sorunun şeklini kullanışlı bir biçimde değiştirir. Sizi seçmiş ve uyum sağlayacak bir düşmana karşı değil, sabit bir repertuara sahip bir betiğe karşı savunma yapıyorsunuz — root, admin, ubuntu, test, git, oracle, postgres ve sızıntı dökümlerinde ortaya çıkmış yirmi bin parola. Bunun sabrı yoktur, yaratıcılığı yoktur ve ilk denemede yanıt vermeyen bir makineyle hiç ilgilenmez. Parola kimlik doğrulamasını kapatmak bu saldırganı yavaşlatmaz. Onu tahtadan tamamen kaldırır.

Bilinmesi gereken iki ayrıntı var. Birincisi, IPv6 çarpıcı biçimde daha sessizdir, çünkü bir /64 tümüyle taranamaz — ama AAAA kaydınız herkese açık olduğu ya da makinenizin adresi bir e-posta başlığında veya bir certificate-transparency günlüğünde göründüğü an bu sessizlik biter. IPv6'yı asla bir saklanma yeri olarak görmeyin; daha küçük bir saman yığını olarak görün. İkincisi, bir IPv4 adresinin bir geçmişi vardır. Sizden önce bir kiracısı olmuştur ve o kiracı bir posta sunucusunu kötü yönettiyse ya da listeye giren bir şey barındırdıysa, itibarı o silinene kadar siz devralırsınız. E-posta sizin için önemliyse, üzerine bir şey inşa etmeden önce adresi alışılagelmiş kara listelerde kontrol edin — bu, beş dakikalık bir kontrol, iki haftalık teslim edilebilirlik hata ayıklamasından tasarruf ettirir.

Küçük bir sunucunun neredeyse her gerçek ele geçirilme vakası şu iki yerden birinde başlar: tahmin edilebilecek bir parola veya dinlemede olmaması gereken halde dinlemede olan bir servis. Bunlara karşılık gelen düzeltmeler PasswordAuthentication no ve varsayılan politikası drop olan bir güvenlik duvarıdır. Gösterişsizdirler, ikisi birlikte on beş dakika sürer ve bu sayfadaki diğer tüm önlemlerin toplamından daha değerlidirler.

Bunun nedeni istatistiksel değil yapısaldır. İkisi de varsayılan olarak kapalıdır — güvenli tarafa doğru başarısız olurlar. Sadece anahtarla çalışan bir sshd, kaç deneme gelirse gelsin kaba kuvvetle kırılamaz, çünkü kodda parola kabul eden bir yol yoktur. Varsayılan reddet bir güvenlik duvarı, henüz kurmadığınız servisleri de korur — üç ay sonra ekleyip localhost'a bağlamayı unutacağınız veritabanı dahil. Bir sertleştirme kontrol listesindeki geri kalan her şey kötülüklerin bir dökümüdür: kapatılacak belirli şeylerin bir listesi, ki bu da yalnızca listenin kendisi kadar eksiksiz olabilir.

Bu yüzden tek bir bölüm okuyup sekmeyi kapatacaksanız, bunu okuyun, aşağıdaki 2'den 5'e kadar olan adımları uygulayın ve saati iyi harcanmış sayın. Geri kalanı gerçekten faydalı ve gerçekten ikincildir.

Debian 13 ve Ubuntu 24.04'te /etc/ssh/sshd_config, bir Include /etc/ssh/sshd_config.d/*.conf satırıyla başlar ve cloud imajları bu dizine — genellikle 50-cloud-init.conf adıyla — PasswordAuthentication'ı zaten ayarlayan bir dosya koyar. Ana dosyayı düzenleyip kendi direktiflerinizi en alta eklemek doğal gelir, ama söylediğini yapmayan bir yapılandırma üretir.

Kural, sshd hakkında neredeyse herkesi şaşırtan tek şeydir: her anahtar kelime için elde edilen ilk değer geçerli olur. Bu, kullandığınız hemen hemen her diğer yapılandırma birleştirme sisteminin tam tersidir. Include ana dosyanın en üstüne yakın durur, bu yüzden bir drop-in, sshd_config'in gövdesinden önce okunur — ve drop-in'ler arasında alfabetik sıra belirleyicidir. 10-hardening.conf adlı bir dosya, 50-cloud-init.conf'u geride bırakır. 60-hardening.conf adlı bir dosyaysa ona sessizce kaybeder ve bunu başarı raporu veren bir yeniden başlatmadan öğrenemezsiniz.

Bu yüzden az önce yazdığınız dosyaya asla güvenmeyin. Daemon'a gerçekte neyi çözümlediğini sorun:

sshd -t                 # syntax check — silence means valid
sshd -T | grep -Ei '^(permitrootlogin|passwordauthentication|pubkeyauthentication|kbdinteractive|allowusers|port) '

sshd -T, her include, geçersiz kılma ve varsayılan çözümlendikten sonraki etkin yapılandırmayı yazdırır. Bu çıktı passwordauthentication yes diyorsa, diskteki herhangi bir dosyanın ne iddia ettiğinden bağımsız olarak parola kimlik doğrulaması açıktır. Başka hiçbir şey doğrulama sayılmaz.

İkinci tuzak da aynı aileden. Ubuntu 24.04, sshd'yi socket etkinleştirmesi (socket activation) yoluyla başlatır: dinleme portunun sahibi ssh.socket'tir ve sshd_config içindeki Port tamamen yok sayılır. systemctl is-enabled ssh.socket ile kontrol edin; etkinse ve farklı bir port istiyorsanız, bunu sshd_config içinde değil — orada ayar doğru görünüp hiçbir işe yaramaz — systemctl edit ssh.socket ile ve bir ListenStream= geçersiz kılmasıyla değiştirin.

Bu konuda dürüst olalım, çünkü internet dürüst değil. sshd'yi port 2222'ye veya 47000'e taşımak, yetkin hiçbir saldırganı durdurmaz. Tek bir hostun tam bir TCP taraması saniyeler sürer, servis kendini banner'da ele verir ve özellikle sizi hedef almaya karar vermiş biri, kahvesini bitirmeden onu bulur.

Yaptığı şey, kimlik doğrulama günlüğünüzü kabaca yüzde 95 azaltmaktır ve bunun gerçek bir değeri vardır: göz gezdirdiğiniz günlüklerle gerçekten okuduğunuz günlükler arasındaki farktır. Görebildiğiniz sinyal, gömdüğünüz sinyalden üstündür. Herhangi bir şeyi izliyorsanız, sessiz bir auth.log bir anomaliyi görünür kılmanın en ucuz yoludur.

Maliyetler küçüktür ama gerçektir ve bunu önerilen değil isteğe bağlı olarak nitelendirmemizin nedeni de budur. Sekiz ay sonra geri döndüğünüzde portu unutacaksınız. 1024 üzerindeki standart olmayan bir port, sshd herhangi bir an dinlemiyor olursa, prensip olarak ayrıcalıksız bir süreç tarafından ele geçirilebilir. İstemci ağlarındaki kısıtlayıcı giden güvenlik duvarları alışılmadık portları engeller, bu yüzden zaman zaman bir ofisten veya bir otelden kendi sunucunuza ulaşamazsınız. Ve socket ile etkinleştirilen bir sistemde bunu, bir önceki bölüme göre doğru yerde değiştirmeniz gerekir. Sessiz günlükler sizin için önemliyse yapın. Yapıp da kendinizi güvende hissetmeyin ve bunu asla sadece-anahtar kimlik doğrulamasının yerine yapmayın.

Neyi engelleyeceğini listeleyen bir güvenlik duvarı bir dosyalama sistemidir. Neye izin vereceğini listeleyen bir güvenlik duvarıysa bir güvenlik önlemidir. Bu ayrım işin tamamıdır, çünkü yalnızca ikincisi gelecek ay kuracağınız servisi, bir cuma günü açtığınız debug portunu ve kendini dışarı açmaya karar veren konteyneri de kapsar.

Platformumuzda iki katman vardır ve birbirlerinden bağımsızdırlar. Kenar filtresi isteğe bağlıdır, panelden sunucu başına yapılandırılır ve hipervizör üzerinde uygulanır; böylece engellenen trafik guest'inize hiç ulaşmaz — çekirdeğinizin bir döngüsünü harcamasından önce uygulanmasını istediğiniz katman-4 kuralları için ve ele geçirilmiş bir guest'i siz üzerinde çalışırken erişilemez tutmak için kullanışlıdır. Guest güvenlik duvarı tamamen sizindir: nftables, iptables, pf, imajınız ne getiriyorsa. Biz ona asla dokunmayız. Makine önemliyse ikisini birden kullanın; en azından ikincisini her zaman kullanın.

5. adımdaki kural setinde iki şey açıklanmayı hak ediyor, çünkü kopyala-yapıştır kural setlerinin çoğu bunları yanlış yapıyor. Tüm ICMP'yi düşürmeyin (drop). Bu düzenli hissettirir ama path-MTU keşfini bozar, ki bu da olabilecek en kötü hata sınıfını üretir: küçük istekler çalışır, büyük yanıtlar takılır ve günlüklerinizde güvenlik duvarından söz eden hiçbir şey yoktur. En azından destination-unreachable, time-exceeded ve parameter-problem'i kabul edin. Listeyi bilmiyorsanız ICMPv6'yı türe göre filtrelemeyin. IPv6, komşu keşfi ve yönlendirici duyurusu için ICMPv6'ya bağımlıdır; onu geniş kapsamlı engellerseniz IPv6 bağlantınız bir yönlendirme sorunu gibi görünen bir şekilde ölür. Tek bir host üzerinde tüm ICMPv6'yı kabul etmek makul bir değiş tokuştur ve aşağıdaki kural seti tam olarak bunu yapar.

flush ruleset'i çalıştırmadan önce bir uyarı: Docker kuruluysa, bu satır Docker'ın yazdığı NAT ve filter kurallarını kaldırır ve systemctl restart docker onları geri koyana kadar konteyner ağı durur. Önce kural setinizi yükleyin, sonra Docker'ı yeniden başlatın ve tek bir konteyner portu bile yayınlamadan önce bir sonraki bölümü okuyun.

Makineye neyi dinlediğini sorun. Ne kurduğunuzu sandığınızı değil — şu anda neyin bağlı olduğunu:

ss -tulpn | grep -vE '127\.0\.0\.1|\[::1\]'

Bu filtreden sağ çıkan her şey, makinenin kendisi dışında bir yerden erişilebilir demektir. Standart bir imajda alışılagelmiş bulgular, 111 portundaki rpcbind (çalıştırdığınız hiçbir şey buna ihtiyaç duymaz), temel kurulumdan kalma bir exim4 dinleyicisi ve loopback üzerinde zararsız olan ama öyle değilse açık bir resolver'a dönüşen bir systemd-resolved stub'ıdır. Tehlikeli olanlar daha sonra, bilerek kurduğunuz yazılımlarla gelir: bir rehber listen_addresses'ı düzenlemeyi söylediği için 0.0.0.0:5432 üzerinde PostgreSQL; Redis, ömrünün büyük bölümünde varsayılan olarak parolası olmadığı için parolasız Redis; bir Elasticsearch düğümü; bir Prometheus exporter'ı; bir Jupyter notebook. Bunların her biri, gerçek bir ihlalin ilk adımı olmuştur, hem de defalarca.

Şimdi dikkatli insanları bile yakalayan tuzak. Docker, güvenlik duvarınızdan izin istemez. -p 5432:5432 yazdığınızda, Docker nat tablosunun PREROUTING zincirine DNAT kuralları ekler; çekirdek bunu, input zinciniz paketi görmeden önce değerlendirir; trafik ardından konteynere yönlendirilir. Varsayılan reddet input politikanıza hiç danışılmaz, ufw status portu kapalı gösterir ve veritabanı herkese açık internettedir. Bu, belgelenmiş bir Docker davranışıdır, on yıldır bu şekildedir ve çok sayıda veritabanını açığa çıkarmıştır.

Düzeltme tek bir dizedir ve edinilmeye değer alışkanlık da budur:

# wrong — reachable from the entire internet, whatever your firewall says
docker run -p 5432:5432 postgres

# right — bound to loopback, reachable only through an SSH tunnel or a proxy
docker run -p 127.0.0.1:5432:5432 postgres

Son olarak, dışarıdan bir görüş alın. Sunucudan yapılan bir port taraması size çekirdeğin ne düşündüğünü söyler; başka bir yerden yapılan bir tarama ise size dünyanın ne gördüğünü söyler, ki önemli olan tek sayı da budur. nmap -Pn -p- <your-ip> komutunu makineden değil dizüstü bilgisayarınızdan çalıştırın ve sonucu beklediğiniz listeyle karşılaştırın.

Küçük sunucuların ele geçirilmesine yol açan pencere, zero-day değildir. Çalışan bir proof-of-concept'le birlikte bir CVE'nin kamuya açıklanmasıyla sizin bir sonraki girişiniz arasındaki dört haftadır. Saldırı araçları yeni bir uzaktan açığı günler içinde özümser; “sırası gelince” yamalayacağınız bir makine bu aralığın tamamı boyunca açıkta kalır ve dürüst her operatör bu aralığın gerçekte ne kadar uzun olduğunu bilir.

Otomatik güncellemelere yönelik itiraz, bir şeylerin bozulması korkusudur ve bunu ciddiye almakta fayda var — ardından kapsamını daraltmakta. Otomasyonu, bakımcıların yeni upstream sürümleri göndermek yerine düzeltmeleri paketlenmiş sürüme geri taşıdığı (backport) dağıtımınızın security bölümüyle sınırlayın. openssl'e yapılan bir Debian güvenlik güncellemesi, zaten çalıştırdığınız sürümün yamalı bir derlemesidir; davranışını değiştirme riski, uzaktan bir açığı bir ay boyunca açık bırakma riskinden çok daha küçüktür. Özellik yükseltmeleri ise ait oldukları yerde, elle yapılan işlemler olarak kalır.

İnsanların atladığı kısım, yeniden başlatmadır. Diskteki yamalı bir libssl, başlangıçta eski olanı belleğe eşlemiş süreç için hiçbir şey ifade etmez ve bir çekirdek güncellemesi, siz onunla yeniden başlatana kadar hiçbir işe yaramaz. Ya seçtiğiniz bir zaman aralığında gözetimsiz bir yeniden başlatmayı kabul edin ya da needrestart'ı kurup hangi servislerin silinmiş kütüphanelere karşı çalıştığını size söylemesine izin verin — ama ikisinden birini yapın. uptime 340 gün gösterirken “otomatik güncellemeler açık” demek rahatlatıcı bir yanılsamadır ve gördüğümüz en yaygın yanılsama da budur.

fail2ban günlüklerinizi okur, bir adresten gelen tekrarlanan başarısızlıkları fark eder ve o adresi bir süreliğine yasaklar. CrowdSec da aynısını yapar ve kararları katılımcılardan oluşan bir ağ genelinde paylaşır; böylece başka bir yerde kötü davranmış bir adresi o size ulaşmadan önce engelleyebilirsiniz. İkisi de iyi yazılımdır. Ama sadece anahtarla çalışan bir SSH sunucusunda ikisi de çoğu insanın sandığı şeyi yapmaz.

PasswordAuthentication, no olduğunda bir SSH kaba kuvvet saldırısı başarılı olamaz. “Başarılı olması olası değildir” değil — ortada bir kod yolu yoktur. Bu yüzden beş başarısızlıktan sonra bir adresi yasaklamak hiçbir şeyi önlemez; sadece günlük hacmini ve önemsiz miktarda CPU'yu azaltır. Bu gerçek bir faydadır, sadece bir güvenlik faydası değildir ve bu değiş tokuş bedava da değildir: yanlış günlüğü izleyen kötü yazılmış bir jail, saldırganları dışarıda bırakmaktan çok daha fazla yöneticiyi kendi sunucularının dışında bırakmıştır.

Bu araçların gerçekten yerini bulduğu yer, bir katman yukarısı, gerçekten dışarı açtığınız servislerdir: bir giriş formu, bir WordPress admin paneli, hız sınırlı bir API, SMTP AUTH kullanan bir posta sunucusu. Bunlar parola kabul eder, kaba kuvvetle kırılabilir ve bir yasaklama listesi tam olarak doğru önlemdir. Dolayısıyla kararımız dar ve nettir. SSH jail'ini atlayın. CrowdSec veya fail2ban'ı parola alanı olan şeyin önüne koyun. Ve hangisini seçerseniz seçin, önce kendi yönetim adresinizi beyaz listeye alın — ignoreip, aksi halde yanlış nedenlerle hatırlayacağınız akşam için vardır.

Önleme, bir saat içinde yapabileceğiniz şeydir. Tespit ise size o saatin yeterli olmadığını söyleyen şeydir. Karmaşık olması gerekmez; tek bir sunucuda üç ucuz önlem işin çoğunu kapsar.

Günlükleri saklayın. Birçok imajda journal, /run içinde yaşar ve yeniden başlatmada buharlaşır; bu da bir olayın kaydının, onu izleyen yeniden başlatmada kaybolması demektir. /var/log/journal'ı oluşturmak tek satırlık bir düzeltmedir ve bu bölümdeki en değerli şeydir.

Girişlerden haberdar olun. Her oturum başlangıcında logger'ı tetikleyen /etc/ssh/sshrc içindeki bir satır hiçbir şeye mal olmaz ve size sshd'nin kendi gevezeliğinden ayrı, temiz, grep'lenebilir bir kayıt verir. İnsanları yakalayan bir uyarı var: kullanıcının kendi ~/.ssh/rc dosyası varsa sshd, /etc/ssh/sshrc yerine onu çalıştırır; yani sistem geneli dosya, tam olarak özelleştirilmiş bir dotfile'a sahip olma ihtimali en yüksek hesap için atlanır. Gölgelenemeyecek bir hook'a ihtiyacınız varsa bunun yerine pam_exec kullanın.

Dosya sisteminin ilk günde nasıl göründüğünü bilin. AIDE, ikili dosyalarınızın, kütüphanelerinizin ve unit dosyalarınızın hash'lerini kaydeder ve o zamandan beri neyin değiştiğini raporlar. Buradaki sorun temel bir sorundur ve genellikle göz ardı edilir: izlediği makinede saklanan bir veritabanı, makineyi ele geçiren kişi tarafından yeniden oluşturulabilir ve bundan sonra kontrol sonsuza kadar “değişiklik yok” raporlar. Veritabanını kutunun dışına kopyalayın, ya da en azından hash'ini başka bir yerde kaydedin; ancak o zaman araç yirmi dakikasına değer hale gelir. Yerinde bırakıldığında sadece bir teselli battaniyesidir.

Genel ilke, tek başına belirtilmeye değer: güvenemeyeceğiniz günlük, ele geçirilmiş makinedeki günlüktür. Gerçekten güvenmeyi düşündüğünüz her şeyin — bir journal, bir bütünlük veritabanı, bir yedek — aynı saldırganın kontrol etmediği bir yerde bir kopyası olmalıdır. Başka bir yargı bölgesindeki ikinci, küçük bir sunucu buna meşru bir cevaptır ve beş dolarlık biri bile yeterlidir.

Yukarıdakilerin tamamı çevre güvenliği çalışmasıdır ve kilitli bir ön kapıyı bir kasayla karıştırmamanız için sınırı net bir şekilde belirtmekte fayda var.

Çalışan bir makinedeki veriyi korumaz. Sertleştirilmiş bir çekirdek ve kapalı bir güvenlik duvarı, hipervizör erişimi olan biri için ve makine açıkken RAM'in içeriği için önemsizdir. Derdiniz sunucu kapalıyken, el konulmuşken ya da hizmet dışı bırakılmışken diskse, bu disk şifrelemedir ve farklı bir başarısızlık moduna sahip farklı bir prosedürdür — bkz. LUKS ile VPS diskini şifreleme.

Sizi anonim yapmaz. Bir sunucu kusursuzca sertleştirilmiş olabilir ve yine de bir WHOIS kaydı, yeniden kullanılmış bir SSH anahtarı, bir analitik etiketi, evden bir sıçrama noktası olmadan bağlanan bir SSH istemcisi ya da iki kimliği birbirine bağlayan bir sertifika aracılığıyla kime ait olduğunu ilan edebilir. Monero ile ödeme yapıp ardından kendi adresinizden giriş yapmak, o ödemeyi boşa çıkarır. Bu başarısızlık modunun kendi sayfası var: sizi deşifre eden hatalar.

Uygulamanızı düzeltmez. Bir SQL injection, kimlik doğrulaması olmayan bir admin endpoint'i ya da içinde backdoor bulunan bir bağımlılık, sshd ayarlarınızı umursamaz. İyi yönetilen sunucuların çoğu ele geçirilme vakası, bilerek ve isteyerek açtığınız, yazdığınız veya kurduğunuz bir servise ait porttan gelir.

Bir yedek değildir. Fidye yazılımı, değişkeni boş kalmış bir rm -rf ve başarısız bir yükseltme hepsi aynı şekilde biter. Bir kopya alın, başka bir yere koyun ve ihtiyacınız olmadan önce bir kez ondan geri yükleyin — başka bir sunucuya taşınmayı atlatılabilir kılan aynı disiplin, kötü geçen bir Salı gününü de atlatılabilir kılar.

Bunların hiçbiri o saate karşı bir argüman değildir. Bu, o saatin size tam olarak ne kazandırdığını bilmeniz gerektiğine dair bir argümandır.