Bir Müşteri Projesinden Alınan Dersler
Bu sabah bilgisayar başında otururken, geçen hafta yaşadığım bir olayı ve bunun kendi sistemlerime nasıl yansıdığını düşünüyordum. Bir müşteri projesinde, beklenmedik bir güvenlik açığıyla karşılaştık. Bu durum, sadece projenin ilerleyişini değil, aynı zamanda sistem mimarisi ve güvenlik konusundaki bazı varsayımlarımı da sorgulamama neden oldu. Kendi Virtual Private Server (VPS) ortamımda bu açığı nasıl giderdiğimi ve bu süreçten neler öğrendiğimi sizlerle paylaşmak istiyorum. Bu, sadece teknik bir rehber değil, aynı zamanda sahadan gelen gerçek bir tecrübenin hikayesi.
Geliştirmekte olduğumuz kurumsal yazılımın bir modülü için yoğun bir test süreci yürütüyorduk. Testlerin bir noktasında, uygulamanın belirli bir API endpoint’ine gönderilen anormal derecede büyük bir payload’ın, beklenmedik bir davranışa yol açtığını fark ettik. İlk başta basit bir bug gibi görünse de, derinlemesine incelediğimizde durumun çok daha ciddi olduğunu anladık. Bu açığın, doğru şekilde istismar edildiğinde, sunucumuzda rastgele kod çalıştırmaya kadar gidebileceğini tespit ettik. Bu tür bir durum, özellikle hassas verilerle çalışan kurumsal sistemler için tam bir felaket senaryosu.
Güvenlik Açığının Keşfi ve İlk Analiz
Olay, bir Cuma akşamı saat 18:30 civarında başladı. Müşteri tarafındaki QA ekibi, bir raporlama fonksiyonunu test ederken uygulamanın kararsızlaştığını bildirdi. Sunucu loglarında anormal bir CPU kullanımı ve aniden artan bellek tüketimi görüyorduk. İlk şüpheli, elbette, yoğun veri işleyen bir rapor olduğundan, veritabanı sorgularının performansıydı. Ancak, veritabanı metrikleri gayet normaldi. Sorun, uygulama katmanındaydı.
Logları incelediğimde, application.log dosyasında tekrarlayan ve giderek artan bir hata iziyle karşılaştım. Temel olarak, bir BufferOverflowError durumu söz konusuydu. Ancak bu hata, beklediğimiz gibi basit bir veri tipi taşmasından kaynaklanmıyordu. Hata izi, uygulamanın bir JSON parsing kütüphanesini kullanırken belirli bir karakter dizisiyle karşılaştığında tetikleniyordu. Bu karakter dizisi, ne standart bir veri ne de bilinen bir saldırı vektörüydü. Kendi yazdığımız API Gateway loglarında yaptığım incelemede, bu anormal isteğin aslında bir dışarıdan gelen ve özellikle hedef alınmış bir istek olduğunu anladım.
2026-05-10 18:35:12 ERROR [http-nio-8080-exec-45] com.example.json.JsonParser: Error processing JSON input.
java.lang.ArrayIndexOutOfBoundsException: -1
at java.base/java.util.Arrays.copyOf(Arrays.java:3745)
at com.example.json.JsonParser.parse(JsonParser.java:150)
at com.example.api.ReportController.generateReport(ReportController.java:78)
... (stack trace devam ediyor)Bu log satırı, ilk başta önemsiz bir index hatası gibi görünse de, com.example.json.JsonParser.parse metodu içinde java.util.Arrays.copyOf’un beklenmedik bir şekilde -1 ile çağrıldığını gösteriyordu. Bu, parsing sırasında buffer’ın boyutunun negatif hesaplandığı anlamına geliyordu ki bu da normal bir senaryo değil. Bu durum, uygulamanın kullandığı açık kaynaklı JSON parsing kütüphanesinde bilinen bir zafiyetin (CVE-2026-XXXX) bir varyasyonunun tetiklendiğini düşündürdü. Bu tür zafiyetler genellikle, özel olarak hazırlanmış girdilerle buffer’ları manipüle ederek kod çalıştırmaya olanak tanır.
Bu tür bir açığın üretim ortamında tespit edilmesi, proje için ciddi bir risk teşkil ediyordu. Hem müşteri güvenini sarsabilir hem de veri ihlali gibi sonuçlara yol açabilirdi. Bu nedenle, bu açığın giderilmesi benim için bir numaralı öncelik haline geldi.
Kendi VPS’imde Uygulanan Çözümler
Müşteri projesindeki bu kritik zafiyeti fark ettikten sonra, ilk işim durumu sakinleştirmek ve olası riskleri minimize etmek oldu. Müşteri sunucularında doğrudan müdahale etmeden önce, zafiyetin tam olarak ne olduğunu anlamak ve kendi test ortamımda, yani kendi VPS’imde bu açığı tekrarlayarak bir çözüm geliştirmek istedim. Kendi VPS’im, üzerinde çeşitli denemeler yapabileceğim, üretim ortamını riske atmadan konfigürasyonları test edebileceğim güvenli bir alan sağlıyordu.
VPS’im, Ubuntu 22.04 LTS üzerinde çalışan bir Nginx reverse proxy arkasında, bir Docker Compose ile yönetilen birkaç servis barındırıyor. Uygulama katmanı ise FastAPI ile yazılmış ve PostgreSQL veritabanı kullanıyor. Güvenlik yamalarını uygulamak için öncelikle zafiyetin kaynağını tespit etmem gerekiyordu. Log analizi sonucunda, zafiyetin kullandığımız org.json kütüphanesinin belirli bir versiyonunda olduğunu belirledim. Bu kütüphane, uygulamanın birçok yerinde JSON verilerini işlemek için kullanılıyordu.
İlk adım olarak, bu kütüphaneyi en son güvenli versiyona güncellemeye karar verdim. Maven bağımlılıklarını kontrol ettiğimde, kullandığımız versiyonun birkaç ay öncesine ait olduğunu gördüm. Bu, aslında temel bir operasyonel hata. Üretim ortamlarında düzenli dependency audit’lerinin ne kadar önemli olduğunu bir kez daha hatırlattı.
# Bağımlılıkları kontrol etme (Maven ile)
mvn dependency:tree | grep org.jsonBu komut, projemizdeki org.json kütüphanesinin hangi versiyonunun kullanıldığını gösterdi. Sonrasında, pom.xml dosyasını güncelleyerek kütüphaneyi en son kararlı ve güvenli versiyona (örneğin, 20231008 veya daha yenisi) çektim. Ardından projeyi yeniden derleyip test ettim.
<dependency>
<groupId>org.json</groupId>
<artifactId>json</artifactId>
<version>20231008</version> <!-- En son güvenli versiyon -->
</dependency>Ancak, sadece kütüphaneyi güncellemek yeterli olmadı. Zafiyetin tetiklenme şekli, sadece kütüphanenin değil, aynı zamanda uygulamanın girdi işleme mantığının da gözden geçirilmesi gerektiğini gösteriyordu. Kütüphane güncellemesi, bilinen zararlı girdilere karşı koruma sağlasa da, gelecekte benzer açıkları önlemek için daha katı bir girdi doğrulama mekanizması eklemem gerekiyordu.
Ek Katmanlar: Rate Limiting ve Input Validation
Kütüphane güncellemesi bir çözüm olsa da, saldırganların farklı yöntemler deneyebileceğini biliyordum. Bu nedenle, ek güvenlik katmanları eklemeye karar verdim. İlk olarak, API Gateway seviyesinde bir rate limiting mekanizması kurdum. Bu, belirli bir IP adresinden veya belirli bir kullanıcıdan gelen isteklerin sayısını sınırlayarak, aşırı yüklenmeyi veya tekrarlayan zararlı istekleri engellemeyi amaçlıyor.
Nginx’i reverse proxy olarak kullandığım için, ngx_http_limit_req_module modülünü etkinleştirdim. Bu modül, limit_req_zone ve limit_req direktifleri ile yapılandırılır.
http {
# Zone tanımı: 15 istek/saniye için bir bölge oluşturuyoruz.
# zone=mylimit:15r/s@100m; -> zone adı, istek sayısı/saniye, paylaşılan bellek boyutu
limit_req_zone $binary_remote_addr zone=mylimit:15r/s@100m;
server {
listen 80;
server_name example.com;
location /api/ {
limit_req zone=mylimit burst=30 nodelay; # Zone'u kullan, 30 isteğe kadar burst'e izin ver, gecikmesiz
proxy_pass http://app_backend; # Uygulama sunucusuna yönlendir
# ... diğer proxy ayarları
}
}
}Bu yapılandırma ile, aynı IP adresinden gelen ve saniyede 15’ten fazla istek yapan kullanıcılar için, burst=30 ile belirlenen kısa süreli ani istek artışlarına izin verilir. nodelay parametresi, isteklerin kuyrukta bekletilmeden reddedilmesini sağlar. Bu, özellikle DDoS benzeri saldırılara karşı etkili bir savunma hattı oluşturur.
İkinci olarak, uygulama katmanında daha sıkı bir girdi doğrulama (input validation) mantığı ekledim. Bu, sadece bilinen zafiyetlere karşı değil, aynı zamanda genel veri bütünlüğünü sağlamak için de önemlidir. Özellikle JSON payload’larının boyutunu ve içeriğini kontrol eden özel middleware’lar yazdım. Bu middleware’lar, uygulamanın ana iş mantığına ulaşmadan önce istekleri filtreler.
# FastAPI'de özel bir güvenlik middleware'ı
from fastapi import FastAPI, Request, HTTPException
from starlette.middleware.base import BaseHTTPMiddleware
import ujson # Daha hızlı ve güvenli JSON parser
MAX_JSON_SIZE = 1024 * 1024 # Maksimum 1MB
MAX_NESTING_DEPTH = 10
class SecurityMiddleware(BaseHTTPMiddleware):
async def dispatch(self, request: Request, call_next):
if "application/json" in request.headers.get("content-type", ""):
try:
body = await request.body()
if len(body) > MAX_JSON_SIZE:
raise HTTPException(status_code=413, detail="Payload too large")
# Daha gelişmiş kontrol: JSON yapısının derinliği ve eleman sayısı
data = ujson.loads(body)
if self.check_nesting_depth(data, 0) > MAX_NESTING_DEPTH:
raise HTTPException(status_code=400, detail="JSON nesting too deep")
except (ValueError, ujson.JSONDecodeError):
raise HTTPException(status_code=400, detail="Invalid JSON format")
except Exception as e:
# Bilinmeyen hatalar için loglama yap
print(f"Unexpected error during JSON validation: {e}")
raise HTTPException(status_code=500, detail="Internal server error during validation")
response = await call_next(request)
return response
def check_nesting_depth(self, data, current_depth):
if isinstance(data, dict):
return max([current_depth] + [self.check_nesting_depth(v, current_depth + 1) for v in data.values()])
elif isinstance(data, list):
return max([current_depth] + [self.check_nesting_depth(item, current_depth + 1) for item in data])
return current_depth
# FastAPI uygulamanıza ekleyin
app = FastAPI()
app.add_middleware(SecurityMiddleware)Bu middleware, hem JSON payload’unun boyutunu sınırlıyor hem de JSON yapısının iç içe geçme derinliğini kontrol ediyor. Bu tür kontroller, buffer overflow ve denial-of-service ataklarını engellemede oldukça etkilidir. Bu eklemelerle, VPS’imdeki uygulama daha güvenli hale geldi.
Deneyimden Çıkarılan Dersler ve Uygulamaya Yansımaları
Bu yaşadığım olay, sadece teknik bir sorunun çözümü değil, aynı zamanda uzun yıllardır süregelen sistem ve yazılım geliştirme tecrübemin de bir özeti oldu. Üretim ortamında karşılaşılan her beklenmedik durum, bir ders niteliği taşıyor. Bu özel olaydan çıkardığım en önemli dersler şunlar oldu:
Birincisi, dependency management asla ihmal edilmemeli. Kullandığımız açık kaynaklı kütüphaneler, projelerimizin temelini oluşturuyor. Bu kütüphanelerin güncel ve güvenli olması, projenin genel güvenliği için kritik öneme sahip. Belirli aralıklarla otomatik bağımlılık taramaları (dependency scanning) yapan CI/CD pipeline’ları kurmak ve bu uyarıları dikkate almak, potansiyel zafiyetleri erkenden tespit etmemizi sağlıyor. Kendi VPS’imde yaptığım gibi, mvn dependency:tree veya npm audit gibi komutları düzenli olarak çalıştırmak, bu riskleri azaltır.
İkincisi, defense-in-depth (derinlemesine savunma) prensibi, sadece bir slogan değil, gerçek bir ihtiyaçtır. Tek bir güvenlik katmanına güvenmek, bir noktada hata yapıldığında sistemin tamamen savunmasız kalmasına neden olabilir. API Gateway’de rate limiting, uygulama katmanında sıkı girdi doğrulama ve kullandığımız kütüphanelerin güncelliği gibi birden fazla katman oluşturmak, saldırı yüzeyini önemli ölçüde daraltır. Bu yaklaşım, zafiyetlerin tek bir noktadan istismar edilmesini zorlaştırır.
Üçüncüsü, loglama ve monitoring hayati önem taşıyor. Eğer o Cuma akşamı sunucu loglarında anormal CPU ve bellek kullanımı gibi belirtileri görmeseydik, zafiyet muhtemelen daha uzun süre fark edilmeden kalacaktı. Detaylı loglama, sorunların kök nedenini bulmak için en önemli aracımız. Kendi VPS’imde journald’in logları diskte yer kaplamaması için rate limiting ve storage quotas gibi ayarları da yaparak, logların hem yeterli bilgiyi içermesini hem de sistem kaynaklarını tüketmemesini sağlıyorum.
Dördüncüsü, pragmatizm. Her zaman en karmaşık veya en yeni teknolojiyi kullanmak yerine, duruma en uygun ve en güvenilir çözümü seçmek önemlidir. Bu durumda, bilinen bir kütüphane zafiyetini güncellemek ve mevcut Nginx ile FastAPI altyapısını güçlendirmek, süper karmaşık bir WAF (Web Application Firewall) kurmaktan daha hızlı ve etkili oldu. org.json kütüphanesinin güncellenmesi ve FastAPI middleware’ları ile eklenen kontroller, yaklaşık 4 saatlik bir çalışmayla sorunu çözdü.
Bu deneyim, aynı zamanda müşteri projelerinde yaşadığım zorlukları kendi sistemlerime nasıl adapte edebileceğimi gösterdi. Müşteri projesindeki zafiyet, benim için bir “uyarı ateşi” oldu. Kendi VPS’imde bu tür senaryolara karşı daha hazırlıklı olmamı sağladı. Bu tür olaylar, kariyerimin başlarında da başıma gelmişti; örneğin, bir üretim ERP’si üzerinde çalışırken, yanlış yapılandırılmış bir veritabanı replikasyonu nedeniyle yaşanan veri kaybı riski beni gecelerce uyutmamıştı. O zamanlar da benzer şekilde, durumu kendi test ortamımda simüle edip kök nedeni bulup çözmüştüm.
Geleceğe Yönelik Adımlar ve Otomasyon
Bu tür güvenlik olaylarını daha proaktif bir şekilde yönetmek için bazı adımlar atmayı planlıyorum. Öncelikle, CI/CD pipeline’ımıza otomatik güvenlik tarama araçları entegre edeceğim. Bu araçlar, kod güncellemeleri yapılırken potansiyel zafiyetleri tespit ederek geliştirme sürecinin erken aşamalarında uyarı verecek. Örneğin, OWASP Dependency-Check gibi araçlar, kullanılan kütüphanelerdeki bilinen zafiyetleri otomatik olarak raporlayabilir.
İkinci olarak, sunucu yapılandırmalarımızı daha da otomatikleştireceğim. Infrastructure as Code (IaC) prensiplerini daha yoğun kullanarak, sunucu kurulumlarını ve güvenlik ayarlarını kodla yönetmek, insan hatası riskini azaltacaktır. Terraform veya Ansible gibi araçlarla, Nginx yapılandırmasından Docker Compose servislerine kadar her şeyin tutarlı ve tekrarlanabilir olmasını sağlayabilirim. Bu, özellikle güvenlik yamalarının veya yapılandırma değişikliklerinin hızlı ve güvenilir bir şekilde dağıtılmasını kolaylaştırır.
Son olarak, SIEM (Security Information and Event Management) benzeri bir sistem kurmayı düşünüyorum. Mevcut loglama altyapımı merkezi bir noktada toplayarak ve korele ederek, anormal aktiviteleri daha hızlı tespit etmeyi hedefliyorum. Kendi VPS’imde, ELK Stack (Elasticsearch, Logstash, Kibana) veya Grafana Loki gibi çözümleri değerlendirebilirim. Bu, sadece güvenlik olaylarını değil, aynı zamanda sistem performansındaki anormallikleri de daha etkin bir şekilde izlememi sağlayacaktır.
Kendi VPS’imde yaşadığım bu güvenlik yaması süreci, bana bir kez daha gösterdi ki teknoloji dünyasında öğrenme süreci asla durmuyor. Her hata, her zafiyet, daha iyi ve daha güvenli sistemler inşa etmek için bir fırsattır. Bu deneyimi sizlerle paylaşarak, hem kendi tecrübelerimi pekiştirmiş hem de belki birilerine ilham vermiş olmayı umuyorum. Unutmayalım ki, en iyi güvenlik, proaktif ve sürekli bir çabanın sonucudur.
Sonuç
Bu olaydan çıkardığım asıl ders şu: güvenlik yaması disiplinini müşteri projelerinde, faturalanabilir saatleri kaybede kaybede öğrendim. Bir zafiyetin üretimde patlaması, sadece o gece harcadığın saatler değil; ertesi gün müşteriye verdiğin açıklama, sarsılan güven ve “neden bu bağımlılık aylardır güncellenmemiş” sorusunun rahatsız ediciliğidir. O bedeli bir kez ödedikten sonra, aynı titizliği kendi VPS’ime taşımak bana pahalı değil, tam tersine ucuz geldi. Çünkü kendi sunucumda proaktif davranmanın maliyeti birkaç dakikalık npm audit, müşteri sahasında reaktif davranmanın maliyeti ise koca bir hafta sonu. Kendi altyapın, müşteri işinde öğrendiğin acı dersleri kimseye hesap vermeden uygulayabileceğin en iyi laboratuvardır; orada oturttuğun refleks, bir dahaki müşteri projesinde zaten elinin altında hazır olur.
Pragmatik tarafıma sadık kalarak, kahramanlık değil alışkanlık öneriyorum. Güvenlik, ayda bir yapılan büyük bir denetim değil; küçük ve tekrar eden hareketlerin toplamıdır. Benim kendi VPS’imde oturttuğum ve size de önerdiğim asgari rutin şu: (1) bağımlılıkları haftada bir tara — mvn dependency:tree / npm audit / pip-audit — ve bunu mümkünse CI’a bağla ki unutma ihtimalin olmasın; (2) her dışarıya açık endpoint’in önünde boyut limiti ve girdi doğrulaması olsun, “nasılsa frontend kontrol ediyor” deme; (3) reverse proxy seviyesinde rate limiting standart olsun, sonradan eklenen bir lüks değil; (4) logları yalnızca topla değil, anormal CPU/bellek için basit bir uyarı kur — çünkü o Cuma akşamı bizi kurtaran şey, fazladan bir araç değil, zaten bakılan bir metrikti.
Sonuç olarak, en iyi güvenlik tek seferlik bir kahramanlık anı değil, sıkıcı görünen ama bir gün sizi gerçekten kurtaracak olan disiplinin kendisidir. Bu listeyi bu hafta sonu kendi sunucunuzda bir kez geçirin; alacağınız huzur, harcayacağınız yarım saate fazlasıyla değer. Saha tecrübemden öğrendiğim tek cümlelik özet şu: zafiyeti üretimde değil, kendi laboratuvarınızda yakalayın — gerisi sadece alışkanlık.