bedoNIX

Bir Node.js projesi yazıp sunucuya koyduğunuzda iş bitmiyor aslında yeni başlıyor. Kullandığınız kütüphaneler zamanla eskiyor, içlerinde güvenlik açıkları bulunuyor, ve kodunuzun tek kopyası sunucudaysa bir gün o sunucu bozulduğunda elinizde hiçbir şey kalmayabilir.

Bu yazıda, üç ayrı Node.js projesini nasıl "bakımdan geçirdiğimi" adım adım anlatıyorum: her komutu neden çalıştırdığımı, çıkan sonucu nasıl okuduğumu, ve hangi durumda "dur, burada dikkatli olmam lazım" dediğimi. Terminal komutu daha önce hiç kullanmamış biri bile takip edebilsin diye yazdım.

1. Adım: Projeniz Git'te mi?

Bakıma başlamadan önce sorulacak en temel soru bu. Git, kodunuzun her değişikliğini kaydeden bir zaman makinesi gibi düşünülebilir. Projeniz git'te değilse, sunucunuzun diski bozulduğu ya da yanlışlıkla bir dosyayı sildiğiniz an, o kod bir daha geri gelmez.

Bir klasörün git deposu olup olmadığını şöyle kontrol edersiniz:

cd benim-projem
git status

Eğer "not a git repository" gibi bir hata alıyorsanız, projeniz hiç versiyon kontrolü altında değil demektir. Şöyle başlarsınız:

git init
git add .
git commit -m "İlk sürüm"

Ama dikkat: git add . demeden önce mutlaka bir sonraki adımı (.gitignore) tamamlayın. Yoksa şifrelerinizi, gerçek müşteri verilerinizi, hatta gigabaytlarca gereksiz dosyayı yanlışlıkla kod deposuna gömebilirsiniz — ve bir kere git geçmişine giren bir şeyi tamamen silmek gerçekten zahmetlidir.

.gitignore: Neyi asla depoya almamalı?

Projenizin kök klasöründe .gitignore adında bir dosya, git'e "şunları asla takip etme" der. Bakım yaparken en çok karşıma çıkan, gitignore'a eklenmesi gereken şeyler şunlar:

• node_modules/ — kütüphanelerin indirildiği klasör. Devasa olabilir (yüzlerce MB) ve package.json'dan her zaman yeniden indirilebilir, o yüzden depoda taşımaya gerek yok.
• .env — veritabanı şifreniz, API anahtarlarınız gibi gizli bilgilerin durduğu dosya. Bunu asla git'e eklemeyin (private bir depo bile olsa).
• Gerçek kullanıcı verisi içeren dosyalar — Excel çıktıları, veritabanı dökümleri, yüklenen fotoğraflar. Kod ile veri farklı şeylerdir; veri koda değil, yedeğe gider.
• Tarayıcı otomasyonu oturum klasörleri — eğer botunuz Puppeteer/Selenium gibi bir araçla tarayıcı açıyorsa, oturum bilgilerinin tutulduğu klasörler hem devasa boyuta ulaşabilir hem de içinde oturum çerezleri (şifre muadili hassas veri) barındırabilir.
• Çöküş dökümleri (core dosyaları) — bir program çöktüğünde işletim sisteminin bıraktığı, genelde yüz megabaytları bulan dosyalar. Koda ait değiller, silinebilirler.

Örnek bir .gitignore:

node_modules/
.env
core
*.xlsx
logs/
oturum_verisi_*/

Bunu ekledikten sonra git add . çalıştırıp git status ile "hangi dosyalar işleme eklenecek" listesine bakın. Beklemediğiniz büyüklükte bir dosya ya da isim görürseniz, önce onu neden gördüğünüzü anlayın, sonra devam edin.

Kodun bir kopyası da GitHub'da dursun

Git, tek başına sadece yerel bir geçmiş tutar — sunucunun diski giderse o geçmiş de gider. Bu yüzden kodu ayrıca GitHub gibi bir yere de gönderin (push edin). Gerçek kullanıcı verisi barındırmayan ama iş mantığınızı içeren bir proje için depoyu private (özel) yapmayı unutmayın — bu sayede kod sizin kontrolünüzde kalır ama internete açık olmaz.

---

2. Adım: Kütüphaneleriniz Ne Kadar Eski?

Bir Node.js projesi, package.json dosyasında listelenen onlarca-yüzlerce dış kütüphaneye dayanır. Bunlar zamanla güncellenir; siz güncellemezseniz projeniz "donmuş" bir zaman diliminde kalır. Mevcut durumu görmek için:

npm outdated

Bu komut size üç sütun gösterir:

• Current — şu an kurulu olan sürüm.
• Wanted — package.json'daki kurala göre (örn. ^3.1.0) izin verilen en güncel sürüm.
• Latest — paketin gerçekten en güncel sürümü (Wanted'dan büyük olabilir, çünkü bazen kural o kadar ileriye izin vermez).

Burada bilmeniz gereken bir kavram var: semver (semantic versioning). Bir sürüm numarası 4.19.2 gibi üç parçadan oluşur:

Parça	Anlamı	Kırılma riski
4.19.2 — Major	Büyük, uyumsuz değişiklikler	Yüksek — kodunuz bozulabilir
4.19.2 — Minor	Yeni özellik, geriye uyumlu	Düşük
4.19.2 — Patch	Hata düzeltmesi	Neredeyse yok

Yani npm outdated çıktısında Current ile Wanted arasındaki fark küçükse (patch/minor), rahatça güncelleyebilirsiniz. Current ile Latest arasında bir major fark varsa (örneğin 4.x'ten 5.x'e), acele etmeyin — o kütüphanenin "neler değişti" (changelog) sayfasına bakmadan güncellemeyin.

Basit güncelleme

Sadece patch/minor farkları için:

npm update

Bu, package.json'daki kurallara sadık kalarak (majör sürüm atlamadan) her şeyi en güncel izin verilen sürüme çeker.

---

3. Adım: Güvenlik Açıklarını Bulmak

Kütüphanelerin sadece "eski" olması bir sorun değildir; asıl önemlisi içlerinde bilinen bir güvenlik açığı olup olmadığıdır. Bunu şöyle öğrenirsiniz:

npm audit

Çıktı size her açığı bir önem derecesiyle listeler: low → moderate → high → critical. En altta da bir özet görürsünüz, örneğin:

12 vulnerabilities (4 moderate, 7 high, 1 critical)

Bu rakamı görünce panik yapmayın — genelde göründüğünden çok daha az kaynağa iniyor. Detaylı, makine tarafından okunabilir hâlini görmek için:

npm audit --json

"via" ne demek? Zincirleme bağımlılık

Az önce yaşadığım gerçek bir örnekle anlatayım. Bir projede npm audit 12 açık buldu. İlk bakışta korkutucu görünüyordu: sequelize (bir veritabanı kütüphanesi), exceljs (Excel dosyası oluşturan kütüphane), connect-session-sequelize (oturum yönetimi) hepsi "açıklı" görünüyordu.

Ama detaya bakınca gerçek tablo şuydu: bu üç kütüphanenin kendisinde hiçbir sorun yoktu — hepsi zaten en güncel sürümdeydi. Sorun, bu kütüphanelerin arka planda kullandığı, çok daha küçük ve genelde fark edilmeyen dört pakette gizliydi: tar, nanoid, brace-expansion, uuid. Yani sequelize, kendi içinde eski bir uuid sürümü taşıdığı için "açıklı" görünüyordu — sequelize'in kendi kodunda bir sorun yoktu.

Bunu anlamanın yolu, her açığın via (üzerinden, aracılığıyla) alanına bakmak:

sequelize (moderate)
  -> via dep: uuid

connect-session-sequelize (moderate)
  -> via dep: sequelize

Bu, bir zincir gösteriyor: connect-session-sequelize → sequelize'e bağımlı → sequelize da uuid'e bağımlı → asıl sorun uuid'de. Zinciri takip ettiğinizde, kaç "açık" göründüğü değil, kaç gerçek kaynak olduğu ortaya çıkıyor. Az önceki örnekte 12 görünen açık, aslında sadece 4 kaynağa iniyordu.

"fixAvailable" alanına dikkat — kör kör güncellemeyin

npm audit her açık için bir "düzeltme mevcut mu" bilgisi de verir. İki türü var:

tar | critical | fixAvailable: true

puppeteer | high | fixAvailable: {"name":"puppeteer","version":"19.8.0","isSemVerMajor":true}

Birinci örnekte fixAvailable: true — bu, "majör sürüm değiştirmeden, package.json kurallarına sadık kalarak güvenle düzeltebilirim" demek. İkincisinde ise bir obje var ve içinde "isSemVerMajor":true yazıyor — bu da "düzeltmek için bu paketi başka bir majör sürüme geçirmem lazım" demek.

Burada durup düşünün. npm bazen "düzeltme" olarak paketi ileri değil geriye götürmenizi önerir — çünkü kendi bağımlılık çözücüsü, "hiç açık kalmasın" diye bazen paketi eskiye, açığın henüz eklenmediği bir sürüme çekmeyi tercih eder. Gerçek bir örnekte npm bana sequelize'i güncel 6.x sürümünden 3.x'e (yıllar öncesine) düşürmemi önerdi. Bunu kör kör kabul etseydim, tüm veritabanı kodum çalışmaz hâle gelirdi. npm audit fix --force komutu tam olarak bunu yapar — sormadan, "en kolay" çözümü uygular. Production'da asla ilk elden kullanmayın.

---

4. Adım: Güvenli Bir Şekilde Düzeltme

İşte gerçekte izlediğim, güvenli sıra:

Önce, force'suz dene

npm audit fix

Bu, sadece fixAvailable: true olan (majör değiştirmeyen) açıkları düzeltir. Genelde açık sayınızı ciddi oranda azaltır, hiçbir şeyi kırma riski neredeyse sıfırdır.

Kalanlar için: "overrides" ile hedefli müdahale

Yukarıdaki uuid örneğine dönelim. sequelize zaten en güncel sürümdeydi ama içinde hâlâ eski bir uuid taşıyordu ve npm bunu "düzeltmek" için sequelize'i düşürmemi öneriyordu. Bunun yerine package.json'a şunu ekledim:

{
  "overrides": {
    "uuid": "^11.1.1"
  }
}

Bu satır npm'e şunu söyler: "Kim uuid isterse istesin, ona en az 11.1.1 sürümünü ver — package.json'da öyle yazmasa bile." npm install çalıştırdığınızda bu, tüm bağımlılık ağacında zorla uygulanır. uuid gibi API'si çok stabil, basit paketlerde bu genelde güvenlidir (temel fonksiyonlar sürümler arası neredeyse hiç değişmez). Karmaşık, çok özellikli bir pakette (örneğin bir web framework'ünde) aynı şeyi yapmadan önce daha dikkatli olun.

Gerçekten düzeltmesi olmayan açıklar da var

Bazen karşınıza çıkan açığın hiçbir güncel çözümü olmadığını görürsünüz. Bunu anlamanın yolu basit — paketin gerçekten en güncel sürümünün ne olduğuna bakmak:

npm view paket-adi version

Eğer bu komutun döndürdüğü sürüm, sizde zaten kurulu olan sürümle aynıysa — yani "en güncel" dediği paket zaten elinizdeki paketse — o açığın gerçekten upstream'de (paketi yazan kişide) henüz bir çözümü yok demektir. Bu durumda iki seçeneğiniz var:

1. Alternatif bir pakete geçmek (varsa ve geçiş maliyeti makulse).
2. Riski bilinçli olarak kabul etmek — ama bunu sessizce değil, gerekçesiyle not ederek yapın: bu açık ne işlemiyor, gerçekte kimden gelen veriyi işliyor, kötüye kullanılma ihtimali ne kadar gerçekçi?

Örneğin bir projede extract-zip paketinde çözümsüz bir "sembolik link" açığı buldum. Ama bu paket sadece kendi sunucumun, güvendiğim bir kaynaktan (tarayıcı yazılımının resmi indirme adresinden) indirdiği bir dosyayı açmak için kullanılıyordu — dışarıdan, bir kullanıcının yüklediği bir dosyayı değil. Yani gerçek saldırı yüzeyi çok dardı. Bunu riski kabul edip ilerleyerek not aldım; eğer aynı paket kullanıcıdan gelen dosyaları açıyor olsaydı, karar tamamen farklı olurdu.

---

5. Adım: Değiştirdikten Sonra Doğrulayın — "Dua Etmeyin"

Bir bağımlılığı güncelledikten sonra iş bitmiyor. Şunları yapmadan "tamamdır" demeyin:

1. Söz dizimi kontrolü. Dosyada bariz bir yazım hatası var mı, hızlıca bakın:

   node --check src/server.js

2. Uygulamayı yeniden başlatın. Sunucunuzda uygulamaları pm2 gibi bir "process manager" ile çalıştırıyorsanız:

   pm2 restart uygulama-adi

3. Hata loglarına bakın. Yeniden başlattıktan hemen sonra:

   pm2 logs uygulama-adi --err --lines 30

   Burada veritabanı bağlantı hatası, "bulunamadı" hatası gibi bir şey görürseniz, güncelleme bir şeyi kırmış demektir.
4. Gerçek bir işlemi deneyin. Uygulamanızda bir sayfayı açın, bir formu gönderin, bir kaydı kaydedin — "çalışıyor" demeden önce gerçekten çalıştığını görün. Loglarda "Veritabanı bağlantısı başarılı" gibi olumlu bir satır ya da gerçek bir isteğin (200 OK) geçtiğini görmek, en güvenilir kanıttır.

İpucu: Değişiklik yapmadan hemen önce package.json ve package-lock.json'un bir kopyasını alın (cp package.json package.json.yedek). Bir şeyler ters giderse eski hâline dönmek saniyeler sürer. Zaten git kullanıyorsanız bu adım gereksiz — git checkout -- package.json package-lock.json aynı işi görür.

---

6. Adım: Loglarınız Diskinizi Doldurmasın

Uzun süre çalışan bir sunucu, sürekli log (kayıt) dosyası üretir. Bunlara dokunmazsanız bir gün diskiniz dolar ve tüm sunucu çöker. pm2 kullanıyorsanız, pm2-logrotate modülünü kurup şu ayarları yapmak yeterli:

pm2 install pm2-logrotate
pm2 set pm2-logrotate:max_size 10M
pm2 set pm2-logrotate:retain 30

Bu, her log dosyası 10MB'ı geçtiğinde otomatik olarak döndürür (eskisini sıkıştırıp yeni bir dosyaya geçer) ve en fazla 30 günlük geçmiş tutar. Kurduktan sonra unutabilirsiniz — arka planda kendi kendine çalışır.

---

7. Adım: Yedekleme — Git Tek Başına Yeterli Değil

Git, kodunuzu korur ama veritabanınızı korumaz. Kullanıcı kayıtları, işlem geçmişi gibi veriler ayrı bir yedekleme gerektirir. Basit bir başlangıç: sunucunuzda bir cron job (zamanlanmış görev) ile her gece veritabanının bir dökümünü almak:

# crontab -e ile açıp şu satırı eklemek, her gece 03:00'te yedek alır
0 3 * * * mysqldump -u kullanici -p'sifre' veritabani_adi > /yedekler/$(date +\%F).sql

Bu yedeklerin de sunucunun dışında bir yerde durması önemli — sunucu tamamen kaybolursa, yedek de onunla beraber gitmesin diye.

---

Özet: Bakım Kontrol Listesi

Elinizdeki her Node.js projesi için, ayda bir bu adımları takip edin:

1. ☐ Proje git'te mi, son değişiklikler push edildi mi?
2. ☐ .gitignore güncel mi — yeni eklenen bir klasör/dosya türü var mı?
3. ☐ npm outdated — patch/minor farkları için npm update.
4. ☐ npm audit — kaç gerçek kaynak var, kaçında "fixAvailable: true"?
5. ☐ Force'suz npm audit fix ile güvenli olanları temizle.
6. ☐ Kalanlar için: majör sürüm gerektiren her paketi tek tek değerlendir, kör kör --force kullanma.
7. ☐ Değişiklik sonrası: syntax kontrolü, restart, log kontrolü, gerçek işlem testi.
8. ☐ Log rotasyonu kurulu mu, disk dolmuyor mu?
9. ☐ Veritabanı yedeği düzenli alınıyor mu, sunucu dışında bir yerde duruyor mu?

Bu adımların hiçbiri tek başına karmaşık değil — asıl beceri, hangi sonucun güvenle uygulanabileceğini, hangisinin dikkat istediğini ayırt edebilmek. Bir sonraki bakımınızda, her "majör sürüm" uyarısında durup bir nefes alın, önce ne değiştiğini okuyun, sonra karar verin.

nginx ile "Dağıtık" Saldırılara Karşı Alt Ağ Bazlı Rate Limiting

Ya da: 70 farklı IP'den gelen ama hiçbiri tek başına şüpheli görünmeyen bir saldırıyı nasıl durdururuz?

Bir gün sunucum aniden yavaşlamaya başladı. Log'lara baktığımda klasik bir "tek kötü IP" görüntüsü yoktu — bunun yerine aynı /24 bloğundan (yani "192.168.1.X" tarzı, sadece son rakamı değişen) 70'e yakın farklı IP, her biri kendi başına makul sayıda istek atıyordu. Hiçbiri tek başına alarm verecek kadar agresif değildi, ama hepsi birden sunucuyu dize getiriyordu.

Bu yazıda, bu tarz "dağıtık ama düşük yoğunluklu" saldırılara karşı nginx'in kendi imkanlarıyla (üçüncü parti araç, Cloudflare falan olmadan) nasıl önlem alınacağını, sıfırdan anlatıyorum.

---

1. Önce temel: nginx'te "hız sınırlama" nasıl çalışır?

nginx, gelen istekleri bir kovaya damlayan su gibi düşünür (buna "leaky bucket" algoritması denir). Şöyle bir kural tanımlarsın:

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;

Türkçesi: "Her IP için ayrı bir kova aç (`$binary_remote_addr` = IP adresi). Bu kova saniyede 10 isteklik bir akışı sindirebilsin. Bütün kovaları tutmak için 10MB'lık bir bellek alanı ayır (`zone=mylimit:10m`)."

Sonra bu kuralı bir yere uygulaman lazım:

location / {
    limit_req zone=mylimit burst=20 nodelay;
}

• burst=20: ani patlamalarda 20 isteklik ekstra tampon tanı (yoksa gerçek bir kullanıcının açtığı sayfadaki 5-6 paralel istek bile anında engellenir).
• nodelay: bu tampondaki istekleri bekletmeden hemen işle, sadece tampon dolunca reddet. (Bunu koymazsan nginx istekleri sıraya koyup yavaşça işler — bu da gerçek kullanıcıyı fark ettirmeden yavaşlatır.)

Eşik aşılınca nginx varsayılan olarak 503 Service Unavailable döner.

2. Peki neden bu bazen yetmiyor?

Kritik nokta şu: kova, anahtar ne ise ona göre açılır. Yukarıdaki örnekte anahtar $binary_remote_addr, yani IP adresi. Bu demek oluyor ki:

100 farklı IP saldırıyorsa, nginx 100 ayrı kova açar. Hiçbiri diğerini etkilemez. Saldırgan, her IP'yi eşiğin biraz altında tutarak bu korumayı tamamen atlatabilir — ki botnet'ler zaten genelde böyle çalışır.

Benim yaşadığım durum tam olarak buydu: 70 farklı IP, hepsi aynı /24 bloğundan (örnek: 57.141.0.3, 57.141.0.61, 57.141.0.64...), hiçbiri tek başına eşiği geçmiyordu.

3. Çözüm: map ile "sahte" bir ortak anahtar üretmek

İhtiyacımız olan şey: 70 farklı IP'nin aynı kovaya düşmesi. nginx'te "bu IP'nin /24'ü nedir" diye hazır bir değişken yok, ama map direktifiyle kendimiz üretebiliyoruz:

map $remote_addr $subnet_key {
    default                                   $remote_addr;
    "~^(?<net>\d+\.\d+\.\d+)\.\d+$"            $net;
}

Bu satır korkutucu görünebilir ama parça parça çok basit. Bir IP adresi üzerinden (57.141.0.71) soldan sağa gidelim:

Parça	Anlamı
~	"Bu bir düz metin değil, bir regex kalıbı" (nginx map'e özel bir işaret)
^ ... $	"Metnin başından sonuna kadar tamamen eşleşsin"
\d	"Bir rakam" (0-9)
\d+	"Bir veya daha fazla rakam"
\.	"Gerçek bir nokta karakteri" (düz . regex'te "her şey" demek, o yüzden \ ile "gerçekten nokta" yapıyoruz)
(?<net>...)	"Bu parantezin içinde eşleşeni bir kenara ayır, adını net koy, sonra $net diye kullanayım"

Şimdi bunu 57.141.0.71 üzerine uygulayalım:

^                → başlangıç
\d+              → "57"
\.               → "."
\d+              → "141"
\.               → "."
\d+              → "0"      ┐
                             ├─ bunlar (?<net>...) İÇİNDE → net = "57.141.0"
\.               → "."      ┘   (parantez burada kapanıyor)
\d+              → "71"     ← SON rakam grubu parantez DIŞINDA, yani atılıyor
$                → bitiş

Sonuç: $net = "57.141.0" — son oktet (.71) kırpıldı. 57.141.0.3 için de aynı işlemi yapsan yine "57.141.0" çıkar. İşte tam istediğimiz şey: son rakamı ne olursa olsun, aynı /24 bloğundaki her IP artık aynı $subnet_key'e sahip.

Genel kural olarak aklında kalsın: \d+ = rakam(lar), \. = gerçek nokta, (?<isim>...) = "bu kısmı işaretle", ^...$ = "baştan sona tam eşleşsin". Bu dört kalıp, günlük regex ihtiyaçlarının büyük kısmını karşılar.

4. Hepsini birleştirmek

Artık $subnet_key değişkenimiz var, onu normal limit_req_zone'da anahtar olarak kullanabiliriz:

http {
    # ... nginx.conf'un http{} bloğu içinde, herhangi bir server{} bloğunun dışında:

    map $remote_addr $subnet_key {
        default                                   $remote_addr;
        "~^(?<net>\d+\.\d+\.\d+)\.\d+$"            $net;
    }

    limit_req_zone $subnet_key zone=subnet_limit:10m rate=30r/s;

    server {
        server_name example.com;

        location / {
            limit_req zone=subnet_limit burst=60 nodelay;
            # ... geri kalan config'in (proxy_pass vb.) aynen kalıyor
        }
    }
}

Not: map ve limit_req_zone sadece http{} seviyesinde tanımlanabilir (server/location içinde olmaz). limit_req (uygulama satırı) ise istediğin server{} veya location{} içine yazılır — böylece sadece saldırı gördüğün siteyi etkiler, diğerlerine dokunmaz.

5. Neden her yere değil, tek tek siteye uyguluyoruz?

Aynı sunucuda birden fazla site barındırıyorsan, bu kuralı hepsine birden http{} seviyesinde yazmak cazip gelebilir — teknik olarak mümkün, çünkü nginx ayarları üstten alta miras alınır. Ama önermiyorum, çünkü:

• Her sitenin trafik "kişiliği" farklıdır. Bir webmail sayfası sürekli arka planda "yenile" isteği atar, bir blog sayfası öyle çalışmaz — tek bir sayı ikisine de adil oturmaz.
• Yanlış ayarın etki alanı. Rakamları ilk seferde muhtemelen tam doğru tutturamazsın (kalibrasyon zaman alır). Global yazarsan bir hata TÜM siteleri aynı anda etkiler; tek siteye yazarsan hata payı orada sınırlı kalır.
• Sadece kanıt olan yere uygula. Saldırı gördüğün siteye özel önlem al; saldırı görmediğin siteye körlemesine kısıtlama koyup gerçek kullanıcıları riske atma.

6. Uygularken dikkat edilecekler

1. Önce mutlaka syntax testi yap:

   nginx -t

   "syntax is ok" / "test is successful" görmeden asla reload etme.
2. Reload et (restart değil):

   service nginx reload

   Reload, aktif bağlantıları kesmeden config'i tazeler.
3. İlk birkaç gün error log'unu izle:

   grep "limiting requests" /var/log/nginx/error.log

   Bu satırlar, kuralın gerçekten kimi/ne zaman engellediğini gösterir. Gerçek kullanıcılar burada görünmeye başlarsa, rate/burst değerlerini yukarı çek. Saldırı hâlâ geçiyorsa aşağı çek.

Özet

Klasik IP-bazlı rate limiting, saldırı tek bir kaynaktan geldiğinde işe yarar. Saldırı onlarca/yüzlerce IP'ye dağıtılmışsa (ki modern botnet'ler genelde böyle çalışır), tek çare, isteği hangi IP attığına değil, hangi ağ bloğuna ait olduğuna göre saymaktır. Bunun için nginx'e hazır bir özellik yok, ama map direktifiyle üç-beş satırlık bir regex'le kendi çözümünü yazabiliyorsun — üçüncü parti bir servise ihtiyaç duymadan, tamamen kendi sunucunda.

 

Merhaba,

FreeBSD 13.2-RELEASE sistemimi 14.0-RELEASE’e freebsd-update aracı ile güncelledim ve sonrasında ssh üzerinden sisteme bağlandığımda su komutu ile root olmak istediğimde şifre sorulmadığını fark ettim. su komutu verdiğim anda root olabiliyordum. Sorunun neden kaynaklandığını tespit edemesem de basit bir çözümü var. passwd komutu ile root şifrenizi yeniden set ederseniz problem çözülüyor.

 

Merhaba,

Şunda hem fikirizdir ki, güvenlik yamalarını zamanında uygulamak ve işletim sistemini daha yeni bir sürüme yükseltmek, sistem yönetiminin önemli yönleridir. FreeBSD, her iki görevi de gerçekleştirmek için kullanılabilen, freebsd-update adı verilen bir yardımcı program içerir.

Bu yardımcı program yardımıyla, yamayı veya yeni bir çekirdeği manuel olarak derleyip yüklemeye gerek kalmadan FreeBSD’yi güncellemek mümkündür. Bu da güncelleme işlemini sistem yöneticisi açısından kolaylaştıran bir durum.

freebsd-update programı minör sistem güncellemeleri yapabildiği gibi başka bir sürüm dalına yükseltmeleri de destekler. Örnek vermek gerekirse; mesela 13.1_RELEASE kullanıyorsunuz. Bu sürüm dalında güncelleme yaparak örneğin 13.1-RELEASE-p9 sürümüne güncelleme yapabilirsiniz. Ya da sürüm dalını tamamen güncelleyerek 13.1 sürümünden 13.2 sürümüne geçiş de yapabilirsiniz. Şimdi ilk durumu nasıl yapabileceğimizi inceleyelim, aslında bu çok kolay. Vermemiz gereken sadece iki komut var;

# freebsd-update fetch
# freebsd-update install

bu iki komut ve ardından sistemi yeniden başlattığımızda bulunduğumuz sürüm dalı içindeki son gücellemeleri sisteme uygulamış oluyoruz. Bu makalede asıl irdeleyeceğimiz güncelleme başka bir sürüm dalına yapılacak güncelleme olacak. Dilerseniz bu işlemi de madde madde inceleyelim..

Adım 1:

Her zaman olduğu gibi işleme başlamadan önce sistemdeki kritik tüm veriyi yedeklemeniz önemli. Sistemdeki kritik verilerin yedeklendiğine emin olmadan lütfen güncelleme yapmayınız..

Adım2:

Kurulu olan sürüm dalımızı en son güncellemeye getirelim;

# freebsd-update fetch
# freebsd-update install

Aslında bu yukarıda da bahsettiğimiz işlem. Sürüm dalı güncellemeden önce sistemimizi içinde bulunduğumuz dalın en güncel haline çıkarıyoruz. Bu komutlar zaten güncel bir dalda olmamız durumunda şöyle bir çıktı üretecektir;

src component not installed, skipped
Looking up update.FreeBSD.org mirrors... 2 mirrors found.
Fetching metadata signature for 13.1-RELEASE from update2.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.
 
No updates needed to update system to 13.1-RELEASE-p9.

Sistemi yeniden başlatalım;

# reboot

Adım 3:

Sistemde halihazırda bulunan tüm paketleri güncelleyelim.. Ben pkg kullanıyorum bu işlemi gerçekleştirmek için verilmesi gereken komutlar;

# pkg update
# pkg upgrade

Adım 4:

FreeBSD 13.1 sürümünden 13.2 sürümüne geçmek için gerekli komutu verelim;

# freebsd-update -r 13.2-RELEASE upgrade

Bu komutu verdikten sistem kontrol edilecek ve size bulunanların uygun görünüp görünmediği sorulacaktır. Y ile onaylayıp bu aşamayı geçin. İşlemler tamamlandıktan sonra değişiklikleri uygulamak için;

# freebsd-update install

komutunu verin. Bu aşamada sunucunuz SSH ile uzaktan eriştiğiniz bir sunucu ise minik bir kontrol yapmak hayatınızı kolaylaştırabilir;

# /usr/sbin/sshd -t

komutu ile SSH servisinde bir sorun olup olmadığını test edelim. Bir sorun yoksa sistemi yeniden başlatalım;

# reboot

sistem yeniden açıldıktan sonra bir kez daha;

# freebsd-update install

komutunu veriyoruz.

Adım 5:

Sistemde kurulu paketleri güncellemeye başlıyoruz. Öncelikle pkg’nin kendisini güncelliyoruz;

# pkg-static install -f pkg

Bu komutun çıktısı şöyle olacaktır;

Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 1 package(s) will be affected (of 0 checked):
 
Installed packages to be REINSTALLED:
	pkg-1.19.1_1
 
Number of packages to be reinstalled: 1
 
8 MiB to be downloaded.
 
Proceed with this action? [y/N]: y
[1/1] Fetching pkg-1.19.1_1.pkg: 100%    8 MiB   2.9MB/s    00:03    
Checking integrity... done (0 conflicting)
[1/1] Reinstalling pkg-1.19.1_1...
[1/1] Extracting pkg-1.19.1_1: 100%

Şimdi sırası ile şu komutları verelim;

# pkg update
# pkg upgrade
# freebsd-update fetch
# freebsd-update install

Son bir kez sistemi yeniden başlatıyoruz;

# reboot

Adım 6:

Sistemimizin gerçekten de 13.2 sürümüne yükselip yükselmediğini kontrol edelim;

# freebsd-version
# uname -r

bu komutların çıktıları sıra ile;

# 13.2-RELEASE-p2
# 13.2-RELEASE-p2

Tebrikler, FreeBSD işletim sisteminizi başarı ile 13.1 sürümünden 13.2 sürümüne çıkarttınız.

Umarım işinize yarayan bir makale olmuştur..

Merhaba,

Bugün sizlere sanallaştırma ortamında kurduğumuz FreeBSD sistemimizin HDD boyutunu nasıl arttıracağımızdan bahsetmek istiyorum. İlk kurulum esnasında sisteme tanımladığımız disk boyutu bazı nedenlerle bazen yetersiz kalabilmekte, diski yeniden nasıl boyutlandıracağımızı ZFS kullanılmış bir kurulum için nasıl yapmanız gerektiğini anlatmaya çalışacağım.

ÖNEMLİ NOT! Burada sizlere anlatacağım işlemler diskin kullanılmaz hale gelmesine yol açabileceği için lütfen tüm kritik verilerinizi doğru şekilde yedeklediğinizden emin olmadan uygulamaya geçmeyiniz.

Adım 1:

Öncelikle kullandığımız sanallaştırma aracında sanal makinemiz için tanımladığımız disk alanını büyütmekle işe başlıyoruz. Bu işlem sanallaştırma ortamınıza göre farklılık gösterebileceği için detaya girmiyorum. Ben işlemi Proxmox VE üzerinde yaptım. Bu işlemi kolayca sanal makinenin içerisine girip Donanım seçeneğine giderek Disk Boyutlandır seçeneği ile yaptım ve sanal makineme 4 GB ek disk alanı eklenmesini sağladım.

Adım 2:

Sanal makinemizde konsole gidip şu komutu çalıştırıyoruz;

root@web:/home/bedo # gpart show
=> 40 33554352 da0 GPT (20G) [CORRUPT]
40 1024 1 freebsd-boot (512K)
1064 984 – free – (492K)
2048 4194304 2 freebsd-swap (2.0G)
4196352 29358040 3 freebsd-zfs (14G)

gördüğünüz gibi en üstte CORRUPT olduğu görülüyor diskin. Öncelikle bu durumu düzeltelim. Bunun için çalıştırmamız gereken komut;

root@web:/home/bedo # gpart recover /dev/da0
da0 recovered

da0 recover edildi. Durumu kontrol edelim;

root@web:/home/bedo # gpart show
=> 40 41942960 da0 GPT (20G)
40 1024 1 freebsd-boot (512K)
1064 984 – free – (492K)
2048 4194304 2 freebsd-swap (2.0G)
4196352 29358040 3 freebsd-zfs (14G)
33554392 8388608 – free – (4.0G)

evet eklediğimiz 4 GB ilave disk alanı free olarak görünüyor artık.

Adım 3:

4 GB olarak görünen free alanı freebsd-zfs’e eklememiz gerekiyor. Vermemiz gereken komut;

root@web:/home/bedo # gpart resize -i 3 da0
da0p3 resized

buradaki “-i 3” parametresi gpart show komutu çıktısında yer alan freebsd-zfs’in numarası fark ettiğiniz gibi. Son drumu kontrol edelim;

root@web:/home/bedo # gpart show
=> 40 41942960 da0 GPT (20G)
40 1024 1 freebsd-boot (512K)
1064 984 – free – (492K)
2048 4194304 2 freebsd-swap (2.0G)
4196352 37746648 3 freebsd-zfs (18G)

evet ilave 4 GB alan artık freebsd-zfs’e eklenmiş halde.

Adım 4:

Yapmamız gereken son bir işlem var;

root@web:/home/bedo # zpool online -e zroot da0p3

komutunu verip işlemi tamamlıyoruz. zpool list komutunun ilave alan eklemeden önceki ve sonraki çıktılarını paylaşıyorum sizlerle;

Öncesi;

root@web:/home/bedo # zpool list
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
zroot  13.5G 9.72G 3.78G – – 59% 72% 1.00x ONLINE –

Sonrası;

root@web:/home/bedo # zpool list
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
zroot 17.5G 9.72G 7.78G – – 46% 55% 1.00x ONLINE –

SIZE 13.5 G değerinden 17.5 G değerine yükselmiş durumda. Yeni alanı kullanmaya başlayabilirsiniz.

Saygılarımla..

 

Herkese Yeniden Merhaba,

FreeBSD işletim sistemini ilginç kılan özelliklerinden birisi bildiğiniz gibi “Port Ağacı”. Bu yazıda port ağacının detaylarına girmeden port ağacında kullanabileceğiniz make komutları hakkında yazmak istedim. İşte make komutlarının en çok kullanılanları ve ne işe yaradıkları;

make extract: Kaynak kodu indirip work dizinine açar.

make config: Portun konfigürasyon ekranını gösterir

make fetch: Portun kaynak kodlarını indirir, bunun dışında hiç bir işlem yapmaz

make: Kaynak kodu indirir ve derler ama kurmaz

make build: Portu derler

make install: Kaynak kodu indirir, derler ve kurar

make clean: Derlenmiş kodları (portun içindeki work dizinindeki) siler

make install clean: Kaynak kodu indirir, derler, kurar sonrasında derlenmiş kodları (portun içindeki work dizinindeki) siler

make distclean: Derlenmiş kodları (portun içindeki work dizinindeki) siler ayrıca kaynak kod dosyasını da siler

make deinstall: Portu kaldırır

make reinstall: Kurulu bir portu yeniden kurar ve yükler.

make package: Portu paketler

make check: Portun testlerini çalıştırır

Faydalı olması ümidi ile..

 

 

Merhaba,

Bu yazıda sizlerle fail2ban uygulamasını FreeBSD bir sistem üzerinde PF (Packet Filter) kullanarak nasıl çalıştırabileceğinizi anlatmak istiyorum. fail2ban’a neden ihtiyaç duydum öncelikle bundan bahsederek konuya giriş yapalım. Bir kaç gün önce nginx web sunucuma çok anlamsız ve çok sayıda istekler geldiğini ve bu istekler yüzünden php-fpm sürecinin yoğun çalışarak sistemi zorladığını ve zaman zaman da durduğunu fark ettim. Gelen bu istekleri analiz edip nasıl engellerim diye araştırırken fail2ban uygulamasını fark ettim. Peki nedir bu fail2ban? Kısaca izah etmeye çalışayım;

fail2ban, sunucuları kötü niyetli giriş denemelerine karşı korumak için kullanılan açık kaynaklı bir yazılımdır. Bu yazılım, özellikle SSH, FTP, HTTP, SMTP ve diğer hizmetlere yönelik brute-force saldırılarını tespit etmek ve engellemek için yaygın olarak kullanılır. Fail2ban, sistem loglarını izleyerek belirli bir süre içinde belirli bir sayının üzerinde başarısız oturum açma girişimi veya diğer kötü niyetli faaliyetleri tespit eder. Tespit edilen bu IP adresleri, belirli bir süre boyunca engellenir. Engelleme, genellikle bir firewall kuralı ekleyerek veya mevcut olanı değiştirerek yapılır. Biz de firewall olarak FreeBSD ile birlikte gelen PF firewall yazılımını kullanacağız. O zaman kurulumla işe başlayalım. fail2ban kurmak aslında gayet kolay, vermemiz gereken tek komut;

# pkg install py311-fail2ban

paket ismi önündeki py311 ifadesi sisteminizdeki Python versiyonuna göre değişebilir. Bunu kontrol etmek için pkg veritabanını arama yaparak tarayabilirsiniz. Yukarıdaki komut fail2ban yazılımını sisteme kuracaktır. Yazılımın ayarlarını yapmak için /usr/local/etc/fail2ban dizinine gidelim. Bu dizinde öncelikle bir dosyayı farklı bir isimle kopyalamamız lazım;

# cp jail.conf jail.local

Bu işlemi neden yaptık? Güncellemeler sırasında jail.conf üzerine yazılabileceği ve bizim yaptığımız düzenlemeler kaybolabileceği için bu kopyalama işlemini yaptık. fail2ban’ın çalışma mantığından bahsedelim biraz da. fail2ban, “jails” adı verilen bölümler kullanarak çalışır. Her jail, belirli bir hizmeti izler ve belirli bir filtre kullanır. Filtreler, genellikle regex (düzenli ifade) kullanarak log dosyalarını tarar ve kötü niyetli faaliyetleri tespit eder. Filtre kurallarını filter.d dizini altına filtre_adi.conf formatında dosyalar oluşturup bu dosyalara yazıyoruz. Hemen nginx için bir filtre oluşturalım, favori metin editörünüz ile filter.d dizini altında örneğin ddos.conf adında bir dosya oluşturalım ve bu dosyaya şunu ekleyelim;

[Definition]
failregex = <HOST> -.*”(GET|POST).*” 200
ignoreregex =

Bu filtre nginx access.log dosyasında belirli bir ifadeyi arıyor gördüğünüz gibi. Filtre kuralını ekledik, şimdi bu filtreyi kullanabilmek için jail.local dosyasını açalım ve en sona şu ifadeyi ekleyelim;

[ddos]
enabled = true
port = http,https
filter = ddos
logpath = /var/log/nginx/access.log
maxretry = 100
bantime = 3600
findtime = 60

Bu yapılandırmada:

• enabled = true ifadesi, bu jail’i etkinleştirir.
• port = http,https ifadesi, HTTP ve HTTPS portlarına gelen trafiği denetler.
• filter = ddos ifadesi, ddos adında bir filtreyi kullanır.
• logpath = /var/log/nginx/access.log ifadesi, Nginx log dosyasının yolunu belirtir.
• maxretry = 100 ifadesi, bir IP’nin kaç kez başarısız deneme yapabileceğini belirtir.
• bantime = 3600 ifadesi, IP’nin ban süresini (saniye olarak) belirtir.
• findtime = 60 Bu süre zarfında belirtilen maxretry sayısının aşılması durumunda IP adresi engellenir. Bu örnekte 1 dakika (60 saniye) olarak ayarlanmıştır.

Bu jail kuralı access.log dosyasında 60 saniye içinde bir ip numarasından 100 adet istek tespit ederse o ip adresine 1 saat boyunca ban koyacaktır.

Bu noktaya kadar işin fail2ban kısmında çalıştık. Şimdi PF için bir kaç ayar yapmamız lazım. fail2ban bir aksiyonu nasıl yapacağına action.d dizinindeki dosyalara bakarak karar veriyor. PF ile ilgili bir ayar dosyası var ancak ben bunu kaldırıp yerine daha sade bir dosya koydum.

# cp pf.conf pf.conf.ori

pf.conf dosyasını açarak içerine şunları ekleyelim;

[Definition]
actionstart =
actionstop =
actioncheck =
actionban = /sbin/pfctl -t <tablename> -T add <ip>/32
actionunban = /sbin/pfctl -t <tablename> -T delete <ip>/32
[Init]
tablename = fail2ban

jail.local dosyasında yapmamız gereken bir şey kaldı. Dosyayı açarak şu parametreleri bulun ve aşağıdaki gibi değiştirin;

banaction = pf[actiontype=<allports>]
banaction_allports = pf[actiontype=<allports>]

Hemen hemen hazırız. PF için bir kural eklememiz gerekiyor, /etc/pf.conf dosyasını açalım/yoksa oluşturalım ve içerisine uygun yerde olacak şekilde şu satırları ekleyelim;

table <fail2ban> persist

block in quick log on vmx0 from <fail2ban> to any

Lütfen vmx0 yazan yere kendi ağ arayüzünüzü yazın. Bu bilgiye ifconfig komutunu kullanarak erişebilirsiniz. Yapmamız gereken son şey /etc/rc.conf dosyasına gerekli satırları eklemek ve uygulamaları başlatmak. rc.conf dosyamızı açalım ve şu satırları ekleyelim;

fail2ban_enable=”YES”
pf_enable=”YES”
pf_rules=”/etc/pf.conf”
pf_flags=””
pflog_enable=”YES”
pflog_logfile=”/var/log/pflog”

Uygulamaları başlatalım;

# /usr/local/etc/rc.d/fail2ban start
# service pf enable

Bir sorun olmadı ise fail2ban nginx access.log dosyamızı izlemeye başlamış olmalı ve verdiğimiz kurala uygun ip numaralarına PF kullarak ban koymalıdır.  Sistemin çalışıp çalışmadığını anlamanın pratik bir yolu fail2ban-client ve pfctl komutlarını kullanmak. Aşağıdaki komut bize ban konuşmuş bir ip olup olmadığını verecektir;

# fail2ban-client status ddos

Bu komutun çıktısı şuna benzemeli;

Status for the jail: ddos
|- Filter
| |- Currently failed: 2
| |- Total failed: 107
| `- File list: /var/log/nginx/access.log
`- Actions
|- Currently banned: 0
|- Total banned: 0
`- Banned IP list:

Gördüğünüz gibi şu anda sistem henüz hiç bir ip ye ban koymamış. Bu listede “Banned IP list” alanında gördüğünüz ip numaralarını şu komutu verdiğinizde de görüyorsanız her şey yolunda demektir;

# pfctl -t fail2ban -T show

Bu komut da o anda PF tarafından fail2ban tablosunda engellenmiş olan ip numaralarının listesini verecektir. Önceki komuttaki ip ler ile bu listedeki ip ler bire bir birbirini tutuyorsa sistemi düzgün şekilde konfigüre etmişsiniz demektir.

Sonuç olarak; fail2ban pek çok yerleşik filtre ile birlikte gelen sizin de yeni filtreler oluşturabileceğiniz, hayal gücünüz ile genişleme kapasitesine sahip güzel bir güvenlik aracı. Umarım makale faydalı olmuştur.

Saygılarımla..

Herkese Merhaba,

Bugün sizlere pfx uzantılı dosyalardan bahsetmek istiyorum. pfx uzantılı dosyaların kısa bir tanımı ile başlayıp bu dosya ile neden çalışmam gerektiğini ve üzerinde yaptığım işlemleri ileride yine lazım olur diyerek kayıt altına almak isterim. pfx nedir, ne işe yarar, nerelerde kullanılır gibi sorularla başlayalım;

PFX dosyası (Personal Information Exchange), bir sertifika dosya biçimidir ve genellikle .pfx veya .p12 uzantısıyla kullanılır. Bu dosya türü, dijital sertifikalar ve özel anahtarlar gibi güvenlik bilgilerini saklamak ve taşımak için kullanılır. PFX dosyası genellikle aşağıdaki bileşenleri içerir:

1. Dijital Sertifikalar:

   • Bu sertifikalar, kimlik doğrulama ve güvenlik için kullanılan genel anahtarları içerir. Bir sunucu veya istemcinin kimliğini doğrulamak için kullanılır.

2. Özel Anahtarlar:

   • Özel anahtarlar, dijital imzaların oluşturulması ve şifreleme/deşifreleme işlemleri için kullanılır. Bu anahtarlar gizli tutulmalı ve yalnızca yetkili kişiler tarafından erişilebilir olmalıdır.

3. Kök ve Ara Sertifikalar:

   • Kök sertifikalar, güven zincirinin en üstündeki sertifikalardır ve genellikle bir sertifika otoritesi (CA) tarafından imzalanmıştır. Ara sertifikalar ise kök sertifikalar ile son kullanıcı sertifikaları arasında bir köprü görevi görür.

PFX Dosyasının Kullanım Alanları

1. Sunucu Kimlik Doğrulaması:

   • Web sunucuları (örneğin, HTTPS üzerinden erişilen web siteleri) genellikle SSL/TLS sertifikalarını kullanarak kimliklerini doğrular. PFX dosyası, bu tür sertifikaları ve özel anahtarları tek bir dosyada saklayarak sunucu yapılandırmasını kolaylaştırır.

2. İstemci Kimlik Doğrulaması:

   • İstemci sertifikaları, istemcilerin (örneğin, bir web sitesine erişen kullanıcıların) kimliklerini doğrulamak için kullanılır. PFX dosyası, bu sertifikaları ve özel anahtarları içererek güvenli erişimi sağlar.

3. E-posta Güvenliği:

   • S/MIME protokolü ile e-postaların şifrelenmesi ve dijital olarak imzalanması için sertifikalar kullanılır. PFX dosyası, bu sertifikaları ve özel anahtarları saklayarak e-posta güvenliğini artırır.

PFX Dosyasının İçeriğini İncelemek

PFX dosyasının içeriğini incelemek ve sertifika bilgilerini görüntülemek için openssl gibi araçlar kullanılabilir. Örneğin, aşağıdaki komut ile bir PFX dosyasının içeriği görüntülenebilir:

Bu dosyalar genelde IIS üzerinde SSL tanımlaması için kullanılıyorlar. Bana da böyle bir sunucudan alınarak verildi ve Nginx üzerinde kullanmam gerekti. Bunu yapmak için fullchain.pem ve privkey.pem dosyalarını pfx dosyasından çıkartmak gerekiyor. Şimdi bu işlemi OpenSSL ile nasıl yapabileceğimizi görelim. İhtiyacımız olan şeyler pfx dosyası ve bu dosyanın varsa şifresi. Linux/Unix makinemizde komut satırına giderek şu komutu veriyoruz;

# openssl pkcs12 -in dosya.pfx -out fullchain_and_key.pem -nodes

Bu komut pfx dosyamız şifrelenmiş ise bizden şifre isteyecektir. Şifreyi girip işlemi tamamladığımızda çalışma dizininde fullchain ve privkey bilgilerini taşıyan fullchain_and_key.pem isimli bir dosya oluşacaktır. Bu dosyadan ihtiyacımız olan iki pem dosyasını elde edelim şimdi de;

# openssl pkey -in fullchain_and_key.pem -out privkey.pem

# openssl crl2pkcs7 -nocrl -certfile fullchain_and_key.pem | openssl pkcs7 -print_certs -out fullchain.pem

Evet pfx dosyamızdan fullchain.pem ve privkey.pem ayrılmış oldu. Bu iki dosya ile Apache ve Nginx üzerinde SSL ayarlamalarınızı yapabilirsiniz.

Saygılarımla..