Hi\u00e7 merak ettiniz mi, internet dedi\u011fimiz devasa a\u011f\u0131n k\u0131r\u0131lganl\u0131\u011f\u0131 nerede ba\u015fl\u0131yor? \u0130\u015fte ben de tam olarak bu sorunun pe\u015fine d\u00fc\u015ft\u00fcm. \u00dc\u00e7 adet sunucu kiralad\u0131m, kimseye tek kelime etmedim ve sonra olanlar\u0131 izledim. Bu deneyim, dijital d\u00fcnyan\u0131n ne kadar karma\u015f\u0131k ve ayn\u0131 zamanda ne kadar hassas oldu\u011funu bana bir kez daha g\u00f6sterdi. Bu makalede, bu s\u00fcreci, teknik detaylar\u0131 ve neler \u00f6\u011frendi\u011fimi sizlerle payla\u015faca\u011f\u0131m. Amac\u0131m, internetin altyap\u0131s\u0131na dair bir fark\u0131ndal\u0131k yaratmak ve potansiyel riskleri g\u00f6zler \u00f6n\u00fcne sermek.<\/p>\n
Bu deneyin temel amac\u0131, izole bir ortamda, d\u0131\u015f m\u00fcdahale olmaks\u0131z\u0131n, basit bir altyap\u0131n\u0131n nas\u0131l beklenmedik sorunlara yol a\u00e7abilece\u011fini g\u00f6zlemlemekti. \u00dc\u00e7 sunucu se\u00e7memin birka\u00e7 nedeni vard\u0131. Birincisi, bir sunucunun tek ba\u015f\u0131na yaratabilece\u011fi etki s\u0131n\u0131rl\u0131 olurdu. \u0130kincisi, birden fazla sunucu, a\u011f ileti\u015fimi ve veri ak\u0131\u015f\u0131n\u0131n karma\u015f\u0131kl\u0131\u011f\u0131n\u0131 daha iyi sim\u00fcle etme imkan\u0131 sunuyordu. \u00dc\u00e7\u00fcnc\u00fc ve belki de en \u00f6nemlisi, bu sunucular\u0131 bir “deney” i\u00e7in kulland\u0131\u011f\u0131m\u0131 kimseye s\u00f6ylememem, ger\u00e7ek d\u00fcnya senaryolar\u0131ndaki “bilinmeyen fakt\u00f6rler”i daha iyi taklit etmemi sa\u011flad\u0131. Bir sistemin d\u0131\u015far\u0131dan nas\u0131l alg\u0131land\u0131\u011f\u0131, ne t\u00fcr zafiyetlere a\u00e7\u0131k oldu\u011fu ve beklenmedik bir y\u00fck alt\u0131nda nas\u0131l tepki verdi\u011fi gibi konular\u0131, olabildi\u011fince do\u011fal bir \u015fekilde g\u00f6zlemlemek istedim. Bu gizlilik, ayn\u0131 zamanda olas\u0131 bir sorunun kayna\u011f\u0131n\u0131 bulma s\u00fcrecinin ne kadar zorlay\u0131c\u0131 olabilece\u011fini de ortaya koyacakt\u0131.<\/p>\n
Bu deneyin teknik derinli\u011fine dalmadan \u00f6nce, baz\u0131 temel kavramlar\u0131 netle\u015ftirmekte fayda var. \u0130nternet, temelde birbirine ba\u011fl\u0131 bilgisayarlar ve sunuculardan olu\u015fan devasa bir a\u011fd\u0131r. Sunucular, web siteleri, uygulamalar ve di\u011fer dijital hizmetler i\u00e7in veri depolayan ve bu verileri kullan\u0131c\u0131lara ileten g\u00fc\u00e7l\u00fc bilgisayarlard\u0131r. A\u011f ileti\u015fimi ise bu sunucular ve kullan\u0131c\u0131lar aras\u0131ndaki veri paketlerinin (data packets) iletilmesini sa\u011flar. Veri ak\u0131\u015f\u0131 (data flow) ise bu paketlerin a\u011f \u00fczerinde nas\u0131l hareket etti\u011fini ifade eder. Her bir sunucunun belirli bir IP adresi (Internet Protocol address) vard\u0131r ve bu adres, a\u011f \u00fczerindeki kimli\u011fini belirler. DNS (Domain Name System) ise, hat\u0131rlanmas\u0131 kolay alan adlar\u0131n\u0131 (\u00f6rne\u011fin, Deneyimim boyunca, bu \u00fc\u00e7 sunucuyu birbirleriyle ve d\u0131\u015f d\u00fcnya ile nas\u0131l konfig\u00fcre etti\u011fimi de detayland\u0131rmak istiyorum. Sunucular\u0131m\u0131, basit bir web sunucusu (web server), bir veritaban\u0131 sunucusu (database server) ve bir de \u00f6nbellekleme sunucusu (caching server) olarak yap\u0131land\u0131rd\u0131m. Bu \u00fc\u00e7l\u00fc yap\u0131, bir\u00e7ok modern web uygulamas\u0131n\u0131n temelini olu\u015fturur. Web sunucusu, gelen istekleri al\u0131r ve ilgili sayfalar\u0131 veya verileri haz\u0131rlar. Veritaban\u0131 sunucusu, bilgileri kal\u0131c\u0131 olarak saklar ve gerekti\u011finde web sunucusuna sunar. \u00d6nbellekleme sunucusu ise, s\u0131k kullan\u0131lan verileri ge\u00e7ici olarak saklayarak sunucular\u0131n y\u00fck\u00fcn\u00fc azalt\u0131r ve yan\u0131t s\u00fcrelerini iyile\u015ftirir. Bu \u00fc\u00e7 bile\u015fenin uyum i\u00e7inde \u00e7al\u0131\u015fmas\u0131, h\u0131zl\u0131 ve g\u00fcvenilir bir hizmet sunman\u0131n anahtar\u0131d\u0131r.<\/p>\n A\u011f yap\u0131land\u0131rmas\u0131 a\u00e7\u0131s\u0131ndan, sunucular\u0131m\u0131 birer sanal a\u011f (virtual network) i\u00e7ine yerle\u015ftirdim. Bu, d\u0131\u015far\u0131dan eri\u015fimi kontrol etmeme ve kendi i\u00e7 a\u011f trafi\u011fimi y\u00f6netmeme olanak tan\u0131d\u0131. G\u00fcvenlik duvar\u0131 (firewall) kurallar\u0131 ile sadece belirli portlara (port) izin verdim. \u00d6rne\u011fin, web sunucusuna HTTP (Hypertext Transfer Protocol) ve HTTPS (Hypertext Transfer Protocol Secure) portlar\u0131ndan (80 ve 443) eri\u015fim sa\u011flad\u0131m. Veritaban\u0131 sunucusuna ise sadece web sunucusundan eri\u015fim izni verdim, d\u0131\u015far\u0131dan do\u011frudan eri\u015fimi kapatt\u0131m. Bu, veritaban\u0131m\u0131n g\u00fcvenli\u011fini sa\u011flamak ad\u0131na kritik bir ad\u0131md\u0131. \u00d6nbellekleme sunucusuna ise yine sadece web sunucusundan ve belirli bir porttan eri\u015fim tan\u0131d\u0131m.<\/p>\n Veri ak\u0131\u015f\u0131n\u0131 sa\u011flamak i\u00e7in ise, web sunucusunun gelen istekleri nas\u0131l i\u015fleyece\u011fini ve veritaban\u0131ndan nas\u0131l veri \u00e7ekece\u011fini belirledim. Bu s\u00fcre\u00e7te, a\u011f protokollerinin (network protocols) nas\u0131l \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 yak\u0131ndan izleme f\u0131rsat\u0131 buldum. TCP\/IP (Transmission Control Protocol\/Internet Protocol) y\u0131\u011f\u0131n\u0131n\u0131n (stack) her katman\u0131n\u0131n (layer) veri iletimindeki rol\u00fcn\u00fc ve olas\u0131 darbo\u011fazlar\u0131 (bottlenecks) anlamak, deneyimin en \u00f6\u011fretici yanlar\u0131ndan biriydi. \u00d6rne\u011fin, bir iste\u011fin DNS \u00e7\u00f6z\u00fcmlemesinden ba\u015flay\u0131p, sunucuya ula\u015fmas\u0131, i\u015flemesi ve cevab\u0131n geri d\u00f6nmesi aras\u0131ndaki ad\u0131mlar\u0131 takip etmek, internetin ne kadar karma\u015f\u0131k bir dans oldu\u011funu g\u00f6steriyordu.<\/p>\n Deneyime ba\u015flarken, \u00f6ncelikli hedefim, olabildi\u011fince basit ama i\u015flevsel bir sistem kurmakt\u0131. Se\u00e7ti\u011fim \u00fc\u00e7 sunucu, bulut sa\u011flay\u0131c\u0131lar\u0131ndan (cloud provider) kiralanm\u0131\u015f sanal makinelerdi (virtual machines). \u0130\u015fletim sistemi olarak pop\u00fcler Linux da\u011f\u0131t\u0131mlar\u0131ndan birini tercih ettim, \u00e7\u00fcnk\u00fc bu sistemlerin esnekli\u011fi ve topluluk deste\u011fi benim i\u00e7in \u00f6nemliydi. Her bir sunucuya, temel a\u011f ayarlar\u0131n\u0131 yapt\u0131m, SSH (Secure Shell) ile g\u00fcvenli eri\u015fimi sa\u011flad\u0131m ve ard\u0131ndan gerekli yaz\u0131l\u0131mlar\u0131 y\u00fckledim. Bu a\u015famada en \u00f6nemli nokta, “minimalizm” ilkesine ba\u011fl\u0131 kalmakt\u0131. Sadece i\u015fimi g\u00f6recek kadar yaz\u0131l\u0131m ve hizmeti kurdum, gereksiz karma\u015f\u0131kl\u0131ktan ka\u00e7\u0131nd\u0131m.<\/p>\n Web sunucusu i\u00e7in Nginx (bir web sunucusu, ters proxy, y\u00fck dengeleyici ve HTTP \u00f6nbelle\u011fi olarak kullan\u0131lan bir yaz\u0131l\u0131m) kurdum. Veritaban\u0131 i\u00e7in PostgreSQL (a\u00e7\u0131k kaynakl\u0131, nesne-ili\u015fkisel veritaban\u0131 sistemi) ve \u00f6nbellekleme i\u00e7in Redis (bellekte veri yap\u0131s\u0131 deposu, ayn\u0131 zamanda veritaban\u0131, \u00f6nbellek ve mesaj arac\u0131s\u0131 olarak kullan\u0131l\u0131r) se\u00e7tim. Bu se\u00e7imler, performans ve g\u00fcvenilirlik a\u00e7\u0131s\u0131ndan iyi bir denge sunuyordu. Yap\u0131land\u0131rma dosyalar\u0131n\u0131 (configuration files) dikkatlice g\u00f6zden ge\u00e7irdim, varsay\u0131lan ayarlar\u0131 ihtiyac\u0131ma g\u00f6re d\u00fczenledim. \u00d6rne\u011fin, Nginx’in worker process say\u0131s\u0131n\u0131, dosya tan\u0131t\u0131c\u0131 (file descriptor) limitlerini ve zaman a\u015f\u0131mlar\u0131n\u0131 (timeouts) ayarlad\u0131m. PostgreSQL’in bellek kullan\u0131m\u0131n\u0131, ba\u011flant\u0131 limitlerini ve g\u00fcnl\u00fckleme (logging) ayarlar\u0131n\u0131 optimize ettim. Redis’in ise bellek kullan\u0131m\u0131n\u0131 ve kal\u0131c\u0131l\u0131k (persistence) ayarlar\u0131n\u0131 yap\u0131land\u0131rd\u0131m.<\/p>\n Sunucular aras\u0131ndaki ileti\u015fimi sa\u011flamak i\u00e7in temel a\u011f protokollerini kulland\u0131m. HTTP ve HTTPS protokolleri \u00fczerinden web sunucusu ile istemciler aras\u0131ndaki ileti\u015fimi y\u00f6nettim. Veritaban\u0131 sunucusuna eri\u015fim i\u00e7in TCP\/IP \u00fczerinden \u00f6zel bir port kulland\u0131m. \u00d6nbellekleme sunucusuna eri\u015fim i\u00e7in de yine TCP\/IP \u00fczerinden farkl\u0131 bir port belirledim. Bu portlar\u0131, g\u00fcvenlik duvar\u0131 kurallar\u0131yla s\u0131k\u0131 bir \u015fekilde kontrol alt\u0131na ald\u0131m. Sadece gerekli olan IP adreslerinden ve portlardan gelen trafi\u011fe izin verdim. Bu, d\u0131\u015far\u0131dan gelebilecek olas\u0131 sald\u0131r\u0131lara kar\u015f\u0131 ilk savunma hatt\u0131m\u0131 olu\u015fturuyordu. Her \u015fey, sessizce, kimsenin haberi olmadan, dijital bir kumdan kale in\u015fa etmek gibiydi.<\/p>\n Deneyin bu ilk a\u015famas\u0131nda, sistemin kararl\u0131l\u0131\u011f\u0131n\u0131 test etmek i\u00e7in basit bir web sayfas\u0131 ve birka\u00e7 test verisi olu\u015fturdum. Sayfan\u0131n h\u0131zl\u0131 y\u00fcklenmesi, veritaban\u0131 sorgular\u0131n\u0131n k\u0131sa s\u00fcrmesi ve \u00f6nbelle\u011fin do\u011fru \u00e7al\u0131\u015fmas\u0131 gibi temel performans metriklerini (performance metrics) g\u00f6zlemledim. Her \u015fey planland\u0131\u011f\u0131 gibi gidiyordu. Ancak, bu “kusursuz” g\u00f6r\u00fcnen sistemin, ger\u00e7ek d\u00fcnyaya ad\u0131m att\u0131\u011f\u0131nda ne gibi s\u00fcrprizlerle kar\u015f\u0131la\u015faca\u011f\u0131n\u0131 hen\u00fcz bilmiyordum. Bu sessiz ba\u015flang\u0131\u00e7, asl\u0131nda b\u00fcy\u00fck bir f\u0131rt\u0131nan\u0131n habercisiydi.<\/p>\n Deneyin en kritik ve ayn\u0131 zamanda en \u015fa\u015f\u0131rt\u0131c\u0131 a\u015famas\u0131, i\u015fte tam da buras\u0131yd\u0131. Sunucular\u0131m\u0131 kurup, k\u00fc\u00e7\u00fck bir test verisiyle \u00e7al\u0131\u015ft\u0131rd\u0131ktan sonra, “beklenmedik” bir trafik ak\u0131\u015f\u0131 ba\u015flad\u0131. Bu trafik, benim taraf\u0131mdan ba\u015flat\u0131lmam\u0131\u015ft\u0131 ve herhangi bir bilinen kaynaktan da gelmiyordu. Sanki internetin derinliklerinden, g\u00f6r\u00fcnmez bir el taraf\u0131ndan y\u00f6nlendiriliyordu. Ba\u015flang\u0131\u00e7ta, bunun bir t\u00fcr botnet (zararl\u0131 yaz\u0131l\u0131m bula\u015fm\u0131\u015f bilgisayarlar a\u011f\u0131) sald\u0131r\u0131s\u0131 olabilece\u011fini d\u00fc\u015f\u00fcnd\u00fcm. Ancak, trafi\u011fin niteli\u011fi biraz daha farkl\u0131yd\u0131. Bu, rastgele IP adreslerinden gelen, ancak belirli bir desene uyan isteklerdi.<\/p>\n Bu trafik, sunucular\u0131m\u0131 h\u0131zla kaynak t\u00fcketimine zorlamaya ba\u015flad\u0131. CPU (Central Processing Unit) kullan\u0131m\u0131 tavan yapt\u0131, bellek kullan\u0131m\u0131 artt\u0131 ve a\u011f bant geni\u015fli\u011fi (network bandwidth) h\u0131zla doldu. \u00d6zellikle web sunucum, s\u00fcrekli olarak yeni ba\u011flant\u0131 istekleri al\u0131yordu. Bu istekler, genellikle basit bir GET iste\u011fiydi ve belirli bir URL’yi hedefliyordu. Ancak, bu isteklerin say\u0131s\u0131 o kadar fazlayd\u0131 ki, sunucu bunlar\u0131 i\u015flemekte zorlan\u0131yordu. Bu durum, “hizmet reddi” (Denial of Service – DoS) veya “da\u011f\u0131t\u0131lm\u0131\u015f hizmet reddi” (Distributed Denial of Service – DDoS) sald\u0131r\u0131lar\u0131n\u0131 an\u0131msat\u0131yordu. Ancak, sald\u0131r\u0131n\u0131n kayna\u011f\u0131n\u0131 belirleyemedi\u011fim i\u00e7in, durumu tam olarak analiz etmekte g\u00fc\u00e7l\u00fck \u00e7ekiyordum.<\/p>\n Bu noktada, deneyimin “kimseye s\u00f6ylemedim” k\u0131sm\u0131n\u0131n ne kadar \u00f6nemli oldu\u011funu anlad\u0131m. E\u011fer birileri bu sunucular\u0131n bana ait oldu\u011funu bilseydi, belki de bu trafik ba\u015fka bir y\u00f6ne \u00e7ekilebilirdi veya benim taraf\u0131mdan m\u00fcdahale edilmesi daha kolay olurdu. Ancak, bu sessizlik, bana olay\u0131n i\u00e7 y\u00fcz\u00fcn\u00fc daha net g\u00f6rme imkan\u0131 tan\u0131yordu. Sanki bir laboratuvar ortam\u0131nda, kontrol alt\u0131nda tutulan bir deney yerine, ger\u00e7ek bir d\u00fcnyan\u0131n kaotik dinamiklerine maruz kalm\u0131\u015ft\u0131m.<\/p>\n Trafi\u011fin bir k\u0131sm\u0131, do\u011frudan web sunucusuna y\u00f6nelse de, bir k\u0131sm\u0131 da DNS sunucular\u0131n\u0131 hedef al\u0131yordu. Bu, “DNS amplification” gibi bilinen DDoS sald\u0131r\u0131 vekt\u00f6rlerini d\u00fc\u015f\u00fcnd\u00fcr\u00fcyordu. DNS sunucular\u0131, alan adlar\u0131n\u0131 IP adreslerine \u00e7eviren kritik altyap\u0131lard\u0131r. E\u011fer bu sunucular a\u015f\u0131r\u0131 y\u00fcke maruz kal\u0131rsa, bu durum, di\u011fer hizmetlerin de eri\u015filemez hale gelmesine neden olabilir. Deneyimim boyunca, bu t\u00fcr bir zincirleme reaksiyonun (chain reaction) ne kadar kolay tetiklenebilece\u011fini g\u00f6rd\u00fcm. \u00dc\u00e7 sunuculuk basit bir altyap\u0131, internetin genel sa\u011fl\u0131\u011f\u0131 \u00fczerinde bile potansiyel bir etki yaratabiliyordu. Bu, a\u011f g\u00fcvenli\u011fi konusunda ne kadar dikkatli olmam\u0131z gerekti\u011fini bir kez daha g\u00f6steriyordu.<\/p>\n Yo\u011fun trafik alt\u0131nda, sistemin baz\u0131 zafiyetleri (vulnerabilities) ve zay\u0131f noktalar\u0131 (weaknesses) belirginle\u015fmeye ba\u015flad\u0131. \u0130lk olarak, sunucular\u0131m\u0131n kaynaklar\u0131 s\u0131n\u0131rl\u0131yd\u0131. \u00dc\u00e7 adet orta seviye sanal sunucu, beklenmedik ve yo\u011fun bir trafik dalgas\u0131na kar\u015f\u0131 koymakta yetersiz kal\u0131yordu. Bu durum, modern internet altyap\u0131s\u0131n\u0131n bile ne kadar hassas olabilece\u011fini g\u00f6steriyordu. Birka\u00e7 bin veya milyon botun tek bir hedefe odaklanmas\u0131, en g\u00fc\u00e7l\u00fc sistemleri bile \u00e7\u00f6kertme potansiyeline sahipti.<\/p>\n \u0130kinci olarak, g\u00fcvenlik duvar\u0131 (firewall) yap\u0131land\u0131rmamda baz\u0131 eksiklikler vard\u0131. Trafi\u011fin kayna\u011f\u0131n\u0131 tam olarak belirleyemedi\u011fim i\u00e7in, belirli IP adreslerini engellemek yerine, sadece genel portlara izin vermi\u015ftim. Bu, sald\u0131rganlar\u0131n benim belirledi\u011fim portlar \u00fczerinden s\u00fcrekli olarak istek g\u00f6ndermesine olanak tan\u0131d\u0131. \u0130deal olarak, gelen trafi\u011fi analiz edip, anormal davran\u0131\u015flar sergileyen IP adreslerini dinamik olarak engellemek gerekirdi. Ancak, bu deneyde b\u00f6yle bir otomatik m\u00fcdahale mekanizmas\u0131 kurmam\u0131\u015ft\u0131m.<\/p>\n \u00dc\u00e7\u00fcnc\u00fc bir zafiyet ise, yaz\u0131l\u0131mlar\u0131n kendisindeydi. Kullan\u0131lan Nginx, PostgreSQL ve Redis s\u00fcr\u00fcmleri, g\u00fcvenlik g\u00fcncellemeleri (security updates) a\u00e7\u0131s\u0131ndan tam olarak g\u00fcncel de\u011fildi. Her ne kadar bilinen b\u00fcy\u00fck bir g\u00fcvenlik a\u00e7\u0131\u011f\u0131 (vulnerability) olmasa da, zamanla ke\u015ffedilebilecek k\u00fc\u00e7\u00fck kusurlar, yo\u011fun y\u00fck alt\u0131nda sistemin kararl\u0131l\u0131\u011f\u0131n\u0131 bozabilirdi. Bu, her zaman en g\u00fcncel yaz\u0131l\u0131m s\u00fcr\u00fcmlerini kullanman\u0131n ve g\u00fcvenlik yamalar\u0131n\u0131 (security patches) d\u00fczenli olarak uygulaman\u0131n \u00f6nemini vurguluyordu.<\/p>\n Bir di\u011fer \u00f6nemli nokta ise, a\u011f protokollerinin kendisindeki baz\u0131 zay\u0131fl\u0131klard\u0131. \u00d6rne\u011fin, HTTP protokol\u00fcn\u00fcn durumsuz (stateless) yap\u0131s\u0131, her iste\u011fin ayr\u0131 ayr\u0131 i\u015flenmesini gerektiriyordu. Bu, yo\u011fun istekler alt\u0131nda sunucunun performans\u0131n\u0131 d\u00fc\u015f\u00fcren bir fakt\u00f6rd\u00fc. Ayr\u0131ca, DNS protokol\u00fcndeki baz\u0131 zay\u0131fl\u0131klar, DNS amplification gibi sald\u0131r\u0131 vekt\u00f6rlerine zemin haz\u0131rl\u0131yordu. Bu t\u00fcr protokol seviyesindeki zay\u0131fl\u0131klar, genellikle altyap\u0131n\u0131n tamam\u0131n\u0131 etkileyen daha b\u00fcy\u00fck sorunlara yol a\u00e7abiliyordu.<\/p>\n Son olarak, en b\u00fcy\u00fck zafiyetlerden biri de benim deneyimin “gizli” olmas\u0131yd\u0131. E\u011fer sistemde bir sorun oldu\u011funu erken fark edip, yard\u0131m isteseydim veya durumu daha geni\u015f bir kitleyle payla\u015fsayd\u0131m, belki de sorunun kayna\u011f\u0131n\u0131 daha h\u0131zl\u0131 bulabilir ve \u00e7\u00f6zebilirdim. Ancak, bu deneyde amac\u0131m, sistemin kendi ba\u015f\u0131na nas\u0131l tepki verdi\u011fini g\u00f6zlemlemekti. Bu, ayn\u0131 zamanda ger\u00e7ek d\u00fcnyada ya\u015fanan siber sald\u0131r\u0131lar\u0131n (cyber attacks) ne kadar izole ve anla\u015f\u0131lmas\u0131 zor olabilece\u011fini de g\u00f6steriyordu. Bir sald\u0131r\u0131 ger\u00e7ekle\u015fti\u011finde, ilk olarak “ne oluyor?” sorusu sorulur, ard\u0131ndan “kim yap\u0131yor?” ve “nas\u0131l durduraca\u011f\u0131z?” sorular\u0131 gelir. Bu zincirleme sorular\u0131n yan\u0131t\u0131n\u0131 bulmak, \u00e7o\u011fu zaman zaman al\u0131r.<\/p>\n Bu deney, internetin ne kadar k\u0131r\u0131lgan bir yap\u0131ya sahip oldu\u011funu g\u00f6zler \u00f6n\u00fcne serdi. \u00dc\u00e7 adet sanal sunucu, do\u011fru ko\u015fullar alt\u0131nda, geni\u015f \u00e7apl\u0131 bir etki yaratabiliyordu. Bu, internetin temelinde yatan protokollerin ve sistemlerin, do\u011fru \u015fekilde y\u00f6netilmedi\u011finde veya beklenmedik y\u00fcklere maruz kald\u0131\u011f\u0131nda ne kadar hassas olabilece\u011fini g\u00f6steriyor. Bir DDoS sald\u0131r\u0131s\u0131, sadece hedef al\u0131nan sunucular\u0131 de\u011fil, ayn\u0131 zamanda bu sunuculara ba\u011fl\u0131 di\u011fer hizmetleri ve hatta genel internet trafi\u011fini bile yava\u015flatabilir veya tamamen durdurabilir.<\/p>\n D\u00fc\u015f\u00fcn\u00fcn ki, bu \u00fc\u00e7 sunucu, internetin sadece k\u00fc\u00e7\u00fck bir par\u00e7as\u0131. Milyarlarca cihaz, trilyonlarca veri paketi her an hareket halinde. Bu devasa ekosistemde, bir noktadaki zay\u0131fl\u0131k, domino etkisi yaratarak geni\u015f \u00e7apl\u0131 \u00e7\u00f6k\u00fc\u015flere yol a\u00e7abilir. \u00d6rne\u011fin, pop\u00fcler bir DNS sa\u011flay\u0131c\u0131s\u0131n\u0131n (DNS provider) hedef al\u0131nmas\u0131, d\u00fcnya \u00e7ap\u0131nda bir\u00e7ok web sitesinin ve \u00e7evrimi\u00e7i hizmetin eri\u015filemez hale gelmesine neden olabilir. Benzer \u015fekilde, bir b\u00fcy\u00fck internet servis sa\u011flay\u0131c\u0131s\u0131n\u0131n (Internet Service Provider – ISP) omurgas\u0131nda (backbone) ya\u015fanacak bir sorun, milyonlarca kullan\u0131c\u0131n\u0131n internet eri\u015fimini kesebilir.<\/p>\n Deneyimim boyunca, trafi\u011fin sadece benim sunucular\u0131m\u0131 de\u011fil, ayn\u0131 zamanda benim sunucular\u0131m\u0131n bulundu\u011fu veri merkezinin (data center) a\u011f\u0131n\u0131 da etkiledi\u011fini g\u00f6zlemledim. Yo\u011fun trafik, sadece benim sunucular\u0131m\u0131n bant geni\u015fli\u011fini de\u011fil, ayn\u0131 zamanda veri merkezinin genel a\u011f kapasitesini de zorluyordu. Bu, bir binadaki bir dairede \u00e7\u0131kan yang\u0131n\u0131n, t\u00fcm binay\u0131 tehdit etmesi gibi bir durumdu. \u0130nternet altyap\u0131s\u0131 da benzer \u015fekilde birbirine ba\u011fl\u0131d\u0131r ve bir noktadaki sorun, t\u00fcm sistemi etkileyebilir.<\/p>\n Bu deneyin en \u00e7arp\u0131c\u0131 sonu\u00e7lar\u0131ndan biri, “g\u00fcvenlik” kavram\u0131n\u0131n ne kadar g\u00f6receli oldu\u011fuydu. Kendi k\u00fc\u00e7\u00fck a\u011f\u0131mda kurdu\u011fum g\u00fcvenlik \u00f6nlemleri, ger\u00e7ek d\u00fcnyan\u0131n ac\u0131mas\u0131zl\u0131\u011f\u0131 kar\u015f\u0131s\u0131nda yetersiz kald\u0131. Bu, sadece bireysel kullan\u0131c\u0131lar veya k\u00fc\u00e7\u00fck i\u015fletmeler i\u00e7in de\u011fil, ayn\u0131 zamanda b\u00fcy\u00fck \u015firketler ve hatta devletler i\u00e7in de ge\u00e7erli bir durum. Siber tehditler s\u00fcrekli evrimle\u015fiyor ve en geli\u015fmi\u015f g\u00fcvenlik sistemleri bile zaman zaman a\u015f\u0131labilir hale geliyor. Bu nedenle, s\u00fcrekli tetikte olmak, g\u00fcncel kalmak ve potansiyel risklere kar\u015f\u0131 haz\u0131rl\u0131kl\u0131 olmak hayati \u00f6nem ta\u015f\u0131yor.<\/p>\n Sonu\u00e7 olarak, internetin k\u0131r\u0131lganl\u0131\u011f\u0131, onun g\u00fcc\u00fcn\u00fcn bir yan \u00fcr\u00fcn\u00fcd\u00fcr. Milyarlarca cihaz\u0131n ve hizmetin bir araya gelmesi, muazzam bir potansiyel yarat\u0131rken, ayn\u0131 zamanda b\u00fcy\u00fck bir risk bar\u0131nd\u0131r\u0131r. Bu deneyim, bana bu k\u0131r\u0131lganl\u0131\u011f\u0131n fark\u0131nda olman\u0131n ve dijital g\u00fcvenli\u011fe daha fazla \u00f6nem vermenin ne kadar kritik oldu\u011funu bir kez daha hat\u0131rlatt\u0131.<\/p>\n Bu deneyimden \u00e7\u0131kard\u0131\u011f\u0131m en \u00f6nemli ders, internetin g\u00f6r\u00fcnd\u00fc\u011f\u00fcnden \u00e7ok daha karma\u015f\u0131k ve hassas bir yap\u0131ya sahip oldu\u011fudur. Basit bir altyap\u0131n\u0131n bile, beklenmedik bir trafik dalgas\u0131 alt\u0131nda nas\u0131l \u00e7\u00f6kebilece\u011fini g\u00f6rmek, dijital d\u00fcnyan\u0131n ger\u00e7eklerini y\u00fcz\u00fcme vurdu. \u0130\u015fte bu deneyimden \u00e7\u0131kard\u0131\u011f\u0131m temel dersler ve daha ileri d\u00fczeydeki kullan\u0131c\u0131lar i\u00e7in baz\u0131 ipu\u00e7lar\u0131:<\/p>\n Bu deney, bana sadece teknik bir ders vermekle kalmad\u0131, ayn\u0131 zamanda dijital d\u00fcnyan\u0131n ne kadar dinamik ve \u00f6ng\u00f6r\u00fclemez oldu\u011funu da g\u00f6sterdi. Siber g\u00fcvenlik, s\u00fcrekli bir m\u00fccadeledir ve en iyi savunma, proaktif bir yakla\u015f\u0131md\u0131r.<\/p>\n Soru 1: Bu deneyde kulland\u0131\u011f\u0131n\u0131z sunucular ne t\u00fcr bir altyap\u0131dayd\u0131?<\/strong> Soru 2: Trafi\u011fin kayna\u011f\u0131n\u0131 neden belirleyemediniz?<\/strong> Soru 3: Bu deney, genel internet g\u00fcvenli\u011fi hakk\u0131nda ne gibi dersler i\u00e7eriyor?<\/strong> Soru 4: Benzer bir durumla kar\u015f\u0131la\u015fmamak i\u00e7in neler yapmal\u0131y\u0131m?<\/strong> #Teknoloji #SiberG\u00fcvenlik #A\u011fAltyap\u0131s\u0131 #SunucuY\u00f6netimi<\/p>\ngoogle.com<\/code>) bu IP adreslerine \u00e7eviren bir sistemdir. Bu temel bile\u015fenlerin her birinde olu\u015facak en ufak bir aksakl\u0131k, t\u00fcm a\u011f\u0131n i\u015fleyi\u015fini etkileyebilir.<\/p>\nDeneyin Ba\u015flang\u0131c\u0131: Sessizce \u0130n\u015fa Edilen Altyap\u0131<\/h2>\n
Beklenmedik Y\u00fck: \u0130nternetin Kap\u0131s\u0131n\u0131 \u00c7alan Trafik<\/h2>\n
Zafiyetlerin Ortaya \u00c7\u0131k\u0131\u015f\u0131: Nerede Hata Yapt\u0131m?<\/h2>\n
\u0130nternetin K\u0131r\u0131lganl\u0131\u011f\u0131: K\u00fc\u00e7\u00fck Bir K\u0131r\u0131nt\u0131dan B\u00fcy\u00fck Bir \u00c7\u00f6k\u00fc\u015fe<\/h2>\n
Deneyimimden \u00c7\u0131kar\u0131lan Dersler ve \u0130leri D\u00fczey \u0130pu\u00e7lar\u0131<\/h2>\n
\n
S\u0131k\u00e7a Sorulan Sorular (SSS)<\/h2>\n
\n Cevap: \u00dc\u00e7 adet bulut sa\u011flay\u0131c\u0131s\u0131ndan kiralanm\u0131\u015f sanal sunucuydu. Bu sunucular, \u00f6zel bir sanal a\u011f i\u00e7inde yap\u0131land\u0131r\u0131lm\u0131\u015ft\u0131.<\/p>\n
\n Cevap: Trafik, b\u00fcy\u00fck olas\u0131l\u0131kla botnet’ler veya zombi bilgisayarlar (zombie computers) \u00fczerinden geliyordu. Bu t\u00fcr trafik kaynaklar\u0131 genellikle s\u00fcrekli de\u011fi\u015fir ve ger\u00e7ek kimliklerini gizlemek i\u00e7in \u00e7e\u015fitli teknikler kullan\u0131rlar. Bu nedenle, kayna\u011f\u0131 kesin olarak belirlemek zordu.<\/p>\n
\n Cevap: \u0130nternetin temel altyap\u0131s\u0131n\u0131n bile beklenmedik y\u00fcklere kar\u015f\u0131 hassas oldu\u011funu g\u00f6steriyor. K\u00fc\u00e7\u00fck bir zafiyetin bile zincirleme reaksiyonlara yol a\u00e7abilece\u011fi ve siber sald\u0131r\u0131lar\u0131n ne kadar etkili olabilece\u011fi konusunda bir fark\u0131ndal\u0131k yarat\u0131yor.<\/p>\n
\n Cevap: Sistemlerinizi d\u00fczenli olarak g\u00fcncelleyin, g\u00fcvenlik duvar\u0131 kurallar\u0131n\u0131z\u0131 s\u0131k\u0131la\u015ft\u0131r\u0131n, kaynaklar\u0131n\u0131z\u0131 do\u011fru y\u00f6netin ve olas\u0131 trafik art\u0131\u015flar\u0131na kar\u015f\u0131 haz\u0131rl\u0131kl\u0131 olun. DDoS koruma hizmetlerini de\u011ferlendirin.<\/p>\n