Bir sunucunun kap\u0131lar\u0131, dijital d\u00fcnyadaki evinizin giri\u015fine benzer. Bu kap\u0131lardan biri olan Port 22, SSH (Secure Shell) protokol\u00fc sayesinde uzaktan g\u00fcvenli eri\u015fim imkan\u0131 sunar. Ancak bu kolayl\u0131k, do\u011fru yap\u0131land\u0131r\u0131lmad\u0131\u011f\u0131nda kabusa d\u00f6n\u00fc\u015febilir. Bu makalede, benim ya\u015fad\u0131\u011f\u0131m SSH lockout (eri\u015fim engelleme) deneyimini, bu deneyimin beni Port 22’yi sonsuza dek kapatmaya nas\u0131l itti\u011fini ve sunucular\u0131n\u0131z\u0131 siber tehditlere kar\u015f\u0131 nas\u0131l daha g\u00fcvenli hale getirebilece\u011finizi ad\u0131m ad\u0131m ke\u015ffedece\u011fiz. Kendi tecr\u00fcbelerimden yola \u00e7\u0131karak, s\u0131f\u0131rdan ba\u015flay\u0131p ileri seviyeye kadar SSH g\u00fcvenli\u011fi stratejilerini inceleyecek ve bir daha asla ayn\u0131 hataya d\u00fc\u015fmemeniz i\u00e7in pratik \u00e7\u00f6z\u00fcmler sunaca\u011f\u0131m.<\/p>\n
SSH, yani Secure Shell (G\u00fcvenli Kabuk), internet \u00fczerinden iki bilgisayar aras\u0131nda \u015fifrelenmi\u015f bir ba\u011flant\u0131 kurmak i\u00e7in kullan\u0131lan bir a\u011f protokol\u00fcd\u00fcr. Temel amac\u0131, g\u00fcvensiz bir a\u011f \u00fczerinden bile g\u00fcvenli bir \u015fekilde komut sat\u0131r\u0131 (CLI – Command Line Interface) eri\u015fimi sa\u011flamakt\u0131r. Sunucu y\u00f6neticileri, geli\u015ftiriciler ve hatta baz\u0131 ileri d\u00fczey kullan\u0131c\u0131lar i\u00e7in SSH, uzak sunuculara eri\u015fimin, dosya transferlerinin ve komut \u00e7al\u0131\u015ft\u0131rman\u0131n olmazsa olmaz arac\u0131d\u0131r. Bu protokol, verilerinizi \u015fifreleyerek \u00fc\u00e7\u00fcnc\u00fc \u015fah\u0131slar\u0131n (man-in-the-middle sald\u0131r\u0131lar\u0131 gibi) ba\u011flant\u0131y\u0131 dinlemesini veya m\u00fcdahale etmesini engeller. Bu sayede, hassas bilgilerinizin ve komutlar\u0131n\u0131z\u0131n g\u00fcvenli\u011fi sa\u011flanm\u0131\u015f olur.<\/p>\n
SSH’in \u00e7al\u0131\u015fma prensibi olduk\u00e7a basittir ancak alt\u0131nda yatan kriptografik (\u015fifreleme bilimi) mekanizmalar olduk\u00e7a g\u00fc\u00e7l\u00fcd\u00fcr. Bir SSH ba\u011flant\u0131s\u0131 kuruldu\u011funda, istemci (sizin bilgisayar\u0131n\u0131z) ve sunucu (eri\u015fmek istedi\u011finiz uzak makine) aras\u0131nda bir el s\u0131k\u0131\u015fma (handshake) s\u00fcreci ba\u015flar. Bu s\u00fcre\u00e7te, sunucu kimli\u011fini kan\u0131tlar ve bir oturum anahtar\u0131 (session key) olu\u015fturulur. Bu anahtar, ba\u011flant\u0131 s\u00fcresince t\u00fcm ileti\u015fimi \u015fifrelemek i\u00e7in kullan\u0131l\u0131r. Kimlik do\u011frulama genellikle parola veya SSH anahtar \u00e7iftleri (public\/private key pair) ile yap\u0131l\u0131r. Parola tabanl\u0131 kimlik do\u011frulama daha yayg\u0131n olsa da, SSH anahtarlar\u0131 \u00e7ok daha g\u00fcvenli bir y\u00f6ntem sunar ve \u00e7o\u011fu profesyonel ortamda tercih edilir.<\/p>\n
Peki, SSH neden bu kadar hayati \u00f6neme sahiptir? Dijital d\u00fcnyada, sunucular\u0131m\u0131z genellikle fiziksel olarak uzakta bulunur ve onlara eri\u015fim sa\u011flamak i\u00e7in g\u00fcvenli bir kanala ihtiya\u00e7 duyar\u0131z. SSH, bu kanal\u0131 sa\u011flar. Bir web sunucusu y\u00f6netiyor, bir veritaban\u0131 sunucusuna ba\u011flan\u0131yor veya bulut tabanl\u0131 bir sanal makine \u00fczerinde \u00e7al\u0131\u015f\u0131yorsan\u0131z, SSH sizin i\u00e7in bir k\u00f6pr\u00fc g\u00f6revi g\u00f6r\u00fcr. \u00d6rne\u011fin, bir web sitesi g\u00fcncellemesi yaparken, dosyalar\u0131 sunucuya g\u00fcvenli bir \u015fekilde aktarmak i\u00e7in SCP (Secure Copy Protocol) veya SFTP (SSH File Transfer Protocol) gibi SSH tabanl\u0131 ara\u00e7lar\u0131 kullan\u0131r\u0131z. Ayr\u0131ca, sunucu \u00fczerindeki log dosyalar\u0131n\u0131 incelemek, yaz\u0131l\u0131m paketlerini g\u00fcncellemek veya sistem hizmetlerini yeniden ba\u015flatmak gibi g\u00f6revler de SSH \u00fczerinden ger\u00e7ekle\u015ftirilir. K\u0131sacas\u0131, SSH olmadan modern sunucu y\u00f6netimi neredeyse imkans\u0131z hale gelir. Bu nedenle, SSH ba\u011flant\u0131lar\u0131n\u0131n g\u00fcvenli\u011fi, genel sistem g\u00fcvenli\u011fimizin temel ta\u015flar\u0131ndan biridir. Ancak bu temel ta\u015f, bazen beklenmedik ve can s\u0131k\u0131c\u0131 sorunlara yol a\u00e7abilir, t\u0131pk\u0131 benim ya\u015fad\u0131\u011f\u0131m lockout deneyiminde oldu\u011fu gibi.<\/p>\n
Her \u015fey, yeni bir sunucu yap\u0131land\u0131rmas\u0131 \u00fczerinde \u00e7al\u0131\u015f\u0131rken ba\u015flad\u0131. Bir proje i\u00e7in h\u0131zl\u0131ca bir sanal sunucu (VPS – Virtual Private Server) kurmam gerekiyordu ve her zaman yapt\u0131\u011f\u0131m gibi temel g\u00fcvenlik ayarlar\u0131n\u0131 yapmaya ba\u015flad\u0131m. Amac\u0131m, sunucuyu daha g\u00fcvenli hale getirmek ve kaba kuvvet (brute-force) sald\u0131r\u0131lar\u0131na kar\u015f\u0131 korumakt\u0131. Plan\u0131m \u015fuydu: root (y\u00f6netici) kullan\u0131c\u0131s\u0131n\u0131n do\u011frudan SSH eri\u015fimini kapatmak, parola ile kimlik do\u011frulamay\u0131 devre d\u0131\u015f\u0131 b\u0131rakmak ve sadece anahtar tabanl\u0131 kimlik do\u011frulamas\u0131n\u0131 etkinle\u015ftirmek. Bu ad\u0131mlar, SSH g\u00fcvenli\u011fi i\u00e7in alt\u0131n standart olarak kabul edilir ve genellikle sorunsuz bir \u015fekilde uygulan\u0131r.<\/p>\n
Yap\u0131land\u0131rma dosyas\u0131 olan Klavyemden Bu an, bir sunucu y\u00f6neticisinin ya\u015fayabilece\u011fi en k\u00f6t\u00fc senaryolardan biriydi. Sunucu hala \u00e7al\u0131\u015f\u0131yordu, web sitesi yay\u0131ndayd\u0131 ama ben ona eri\u015femiyordum. Sanki kendi evinizin anahtar\u0131n\u0131 kaybetmi\u015f ve kap\u0131da kalm\u0131\u015fs\u0131n\u0131z gibi bir durumdu. Yedek bir eri\u015fim y\u00f6ntemim yoktu. Konsol eri\u015fimi (VNC veya web tabanl\u0131 konsol) de ne yaz\u0131k ki o an i\u00e7in mevcut de\u011fildi. G\u00fcnlerce s\u00fcren bir projenin tam ortas\u0131ndayken, t\u00fcm ilerlemem tehlikedeydi. O anki \u00e7aresizlik hissi, beni Port 22’ye kar\u015f\u0131 k\u00f6kl\u00fc bir karar almaya itecekti. Bu deneyim, bana g\u00fcvenlik yap\u0131land\u0131rmalar\u0131n\u0131 test etmenin ve yedek eri\u015fim yollar\u0131n\u0131 her zaman haz\u0131r bulundurman\u0131n ne kadar kritik oldu\u011funu ac\u0131 bir \u015fekilde \u00f6\u011fretti.<\/p>\n SSH, sundu\u011fu g\u00fcvenlik katman\u0131na ra\u011fmen, varsay\u0131lan yap\u0131land\u0131rmalar\u0131 ve standart port kullan\u0131m\u0131 nedeniyle s\u00fcrekli siber sald\u0131r\u0131lar\u0131n hedefi haline gelmektedir. \u00d6zellikle Port 22, SSH’in varsay\u0131lan portu oldu\u011fu i\u00e7in, internete a\u00e7\u0131k her sunucu i\u00e7in potansiyel bir zay\u0131fl\u0131k noktas\u0131d\u0131r. Siber su\u00e7lular ve botnetler, s\u00fcrekli olarak interneti tarayarak a\u00e7\u0131k Port 22’ye sahip sunucular\u0131 tespit etmeye \u00e7al\u0131\u015f\u0131r. Tespit ettiklerinde ise, bu sunuculara kar\u015f\u0131 kaba kuvvet (brute-force) sald\u0131r\u0131lar\u0131 ba\u015flat\u0131rlar. Kaba kuvvet sald\u0131r\u0131lar\u0131, belirli bir kullan\u0131c\u0131 ad\u0131 (genellikle ‘root’ veya ‘admin’) ve milyonlarca olas\u0131 parola kombinasyonunu deneyerek sunucuya yetkisiz eri\u015fim sa\u011flamay\u0131 ama\u00e7lar.<\/p>\n Bu sald\u0131r\u0131lar genellikle otomatik botnetler taraf\u0131ndan ger\u00e7ekle\u015ftirilir. Bu botnetler, d\u00fcnyan\u0131n d\u00f6rt bir yan\u0131ndaki binlerce hatta milyonlarca zombi bilgisayardan olu\u015fur ve e\u015f zamanl\u0131 olarak farkl\u0131 IP adreslerinden sunucunuza sald\u0131rmaya \u00e7al\u0131\u015f\u0131r. Sunucunuzun log dosyalar\u0131n\u0131 (\u00f6rne\u011fin Bu loglar, sunucunuzun s\u00fcrekli olarak sald\u0131r\u0131 alt\u0131nda oldu\u011funu g\u00f6sterir. Ba\u015far\u0131l\u0131 bir kaba kuvvet sald\u0131r\u0131s\u0131, sunucunuzun tamamen ele ge\u00e7irilmesine, veri ihlallerine, k\u00f6t\u00fc ama\u00e7l\u0131 yaz\u0131l\u0131m y\u00fcklenmesine veya sunucunuzun bir botnet’in par\u00e7as\u0131 haline gelmesine neden olabilir. Bu nedenle, Port 22’nin g\u00fcvenli\u011fini sa\u011flamak, sunucu y\u00f6netiminin en temel ve en \u00f6nemli g\u00f6revlerinden biridir. Varsay\u0131lan ayarlar, \u00e7o\u011fu zaman yeterli korumay\u0131 sa\u011flamaz ve ek g\u00fcvenlik \u00f6nlemleri al\u0131nmas\u0131 zorunludur. Benim lockout deneyimim, bu \u00f6nlemlerin ne kadar kritik oldu\u011funu ve yanl\u0131\u015f bir ad\u0131m\u0131n nelere mal olabilece\u011fini ac\u0131 bir \u015fekilde kan\u0131tlad\u0131.<\/p>\n Unutmamak gerekir ki, g\u00fcvenlik bir s\u00fcre\u00e7tir, tek seferlik bir i\u015flem de\u011fil. S\u00fcrekli olarak yeni tehditler ortaya \u00e7\u0131kmakta ve mevcut sistemlerin g\u00fcncellenmesi gerekmektedir. Port 22’nin hedef olmas\u0131, sadece bir ba\u015flang\u0131\u00e7 noktas\u0131d\u0131r. SSH g\u00fcvenli\u011fini art\u0131rmak i\u00e7in at\u0131lacak ad\u0131mlar, sadece kaba kuvvet sald\u0131r\u0131lar\u0131n\u0131 de\u011fil, ayn\u0131 zamanda di\u011fer potansiyel zafiyetleri de hedef almal\u0131d\u0131r. Bu, hem sunucu y\u00f6neticileri hem de siber g\u00fcvenlik uzmanlar\u0131 i\u00e7in s\u00fcrekli bir m\u00fccadeledir.<\/p>\n SSH lockout deneyimimden sonra, sunucu g\u00fcvenli\u011fi konusunda \u00e7ok daha titiz davranmaya ba\u015flad\u0131m. Port 22’yi tamamen kapatma karar\u0131ma gelmeden \u00f6nce, SSH g\u00fcvenli\u011fini art\u0131rmak i\u00e7in uygulanabilecek temel yap\u0131land\u0131rmalar\u0131 detayl\u0131 bir \u015fekilde ara\u015ft\u0131rd\u0131m ve uygulad\u0131m. Bu ad\u0131mlar, \u00e7o\u011fu sunucu i\u00e7in ba\u015flang\u0131\u00e7 seviyesinde dahi b\u00fcy\u00fck bir g\u00fcvenlik art\u0131\u015f\u0131 sa\u011flar ve kaba kuvvet sald\u0131r\u0131lar\u0131na kar\u015f\u0131 \u00f6nemli bir bariyer olu\u015fturur. \u0130\u015fte bu temel ad\u0131mlar:<\/p>\n Parolalar, ne kadar karma\u015f\u0131k olursa olsunlar, her zaman kaba kuvvet sald\u0131r\u0131lar\u0131na veya sosyal m\u00fchendislik (social engineering) taktiklerine kar\u015f\u0131 savunmas\u0131zd\u0131r. SSH anahtar \u00e7iftleri (public\/private key pair), \u00e7ok daha g\u00fcvenli bir alternatif sunar. Bir anahtar \u00e7ifti olu\u015fturdu\u011funuzda, \u00f6zel anahtar\u0131n\u0131z (private key) bilgisayar\u0131n\u0131zda g\u00fcvende tutulur ve asla sunucuya g\u00f6nderilmez. Genel anahtar\u0131n\u0131z (public key) ise sunucudaki Anahtar olu\u015fturma ve kopyalama ad\u0131mlar\u0131 genellikle \u015f\u00f6yledir:<\/p>\n Bu komut, 4096 bit RSA anahtar \u00e7ifti olu\u015fturur. Bir parola (passphrase) belirlemeniz \u015fiddetle tavsiye edilir.\n <\/li>\n Alternatif olarak, genel anahtar dosyas\u0131n\u0131n i\u00e7eri\u011fini (genellikle Anahtar tabanl\u0131 kimlik do\u011frulamas\u0131n\u0131 etkinle\u015ftirdikten sonra, Root kullan\u0131c\u0131s\u0131, Linux sistemlerinde en y\u00fcksek yetkilere sahip kullan\u0131c\u0131d\u0131r. Bu nedenle, siber sald\u0131rganlar\u0131n birincil hedefidir. Root kullan\u0131c\u0131s\u0131n\u0131n do\u011frudan SSH \u00fczerinden oturum a\u00e7mas\u0131n\u0131 engellemek, sunucunuzun g\u00fcvenli\u011fini \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131r\u0131r. Bunun yerine, normal bir kullan\u0131c\u0131 hesab\u0131 ile oturum a\u00e7\u0131p, gerekti\u011finde Bu de\u011fi\u015fiklikten sonra, root olarak SSH ile ba\u011flanma denemeleri ba\u015far\u0131s\u0131z olacakt\u0131r. Normal kullan\u0131c\u0131 hesab\u0131n\u0131z\u0131n Port 22, SSH’in standart portu oldu\u011fu i\u00e7in s\u00fcrekli taran\u0131r ve sald\u0131r\u0131ya u\u011frar. SSH portunu farkl\u0131, standart olmayan bir porta (\u00f6rne\u011fin 2222, 22222 veya rastgele y\u00fcksek bir port numaras\u0131) de\u011fi\u015ftirmek, otomatik botnet sald\u0131r\u0131lar\u0131n\u0131n b\u00fcy\u00fck bir k\u0131sm\u0131n\u0131 engeller. Bu, “g\u00fcvenlik i\u00e7in belirsizlik” (security through obscurity) olarak adland\u0131r\u0131lsa da, pratik anlamda sald\u0131r\u0131 y\u00fczeyinizi \u00f6nemli \u00f6l\u00e7\u00fcde daralt\u0131r. Bu de\u011fi\u015fikli\u011fi yapt\u0131ktan sonra, g\u00fcvenlik duvar\u0131n\u0131zda (firewall) yeni portu a\u00e7may\u0131 unutmay\u0131n! Aksi takdirde, kendinizi yine bir lockout durumunda bulabilirsiniz. \u00d6rne\u011fin, UFW (Uncomplicated Firewall) kullan\u0131yorsan\u0131z: SSH eri\u015fimine izin verilen kullan\u0131c\u0131lar\u0131 veya gruplar\u0131 a\u00e7\u0131k\u00e7a tan\u0131mlamak, yetkisiz kullan\u0131c\u0131lar\u0131n sisteme s\u0131zmas\u0131n\u0131 zorla\u015ft\u0131r\u0131r. Bu ayarlar, sadece belirtilen kullan\u0131c\u0131lar\u0131n veya belirtilen gruplara \u00fcye olan kullan\u0131c\u0131lar\u0131n SSH ile ba\u011flanmas\u0131na izin verir.<\/p>\n T\u00fcm bu de\u011fi\u015fiklikleri yapt\u0131ktan sonra, SSH hizmetini yeniden ba\u015flatmay\u0131 ve yeni bir terminal penceresinden<\/strong> ba\u011flant\u0131y\u0131 test etmeyi unutmay\u0131n. Eski oturumunuzu a\u00e7\u0131k tutarak, olas\u0131 bir lockout durumunda geri d\u00f6nebilir ve hatalar\u0131 d\u00fczeltebilirsiniz. Bu, benim lockout deneyimimden \u00e7\u0131kard\u0131\u011f\u0131m en \u00f6nemli derslerden biriydi.<\/p>\n Port 22’yi tamamen kapatmak, baz\u0131 durumlarda a\u015f\u0131r\u0131 bir \u00f6nlem gibi g\u00f6r\u00fcnebilir. Ancak benim ya\u015fad\u0131\u011f\u0131m deneyim, bu radikal karar\u0131n arkas\u0131nda yatan mant\u0131\u011f\u0131 anlamam\u0131 sa\u011flad\u0131. Yine de, her zaman Port 22’yi kapatmak zorunda de\u011filsiniz. \u00c7e\u015fitli alternatif g\u00fcvenlik stratejileri mevcut olup, bu stratejilerle SSH ba\u011flant\u0131lar\u0131n\u0131z\u0131 \u00f6nemli \u00f6l\u00e7\u00fcde g\u00fc\u00e7lendirebilirsiniz. Bu b\u00f6l\u00fcmde, Port 22’yi a\u00e7\u0131k tutarken bile g\u00fcvenli\u011fi art\u0131rman\u0131n yollar\u0131n\u0131 ke\u015ffedece\u011fiz.<\/p>\n Bir g\u00fcvenlik duvar\u0131, sunucunuza gelen ve giden trafi\u011fi kontrol eden ilk savunma hatt\u0131d\u0131r. Sadece belirli IP adreslerinden veya belirli a\u011flardan SSH eri\u015fimine izin vermek, kaba kuvvet sald\u0131r\u0131lar\u0131n\u0131 b\u00fcy\u00fck \u00f6l\u00e7\u00fcde azalt\u0131r. \u00d6rne\u011fin, UFW (Uncomplicated Firewall) veya iptables gibi ara\u00e7larla bu kurallar\u0131 kolayca yap\u0131land\u0131rabilirsiniz. E\u011fer belirli bir ofis IP adresiniz veya VPN a\u011f\u0131n\u0131z varsa, sadece o IP adreslerinden Port 22’ye eri\u015fime izin verebilirsiniz:<\/p>\n Bu kurallar, Fail2ban, sunucunuzdaki log dosyalar\u0131n\u0131 (g\u00fcnl\u00fck kay\u0131tlar\u0131n\u0131) izleyen ve belirli bir s\u00fcre i\u00e7inde \u00e7ok say\u0131da ba\u015far\u0131s\u0131z oturum a\u00e7ma denemesi yapan IP adreslerini otomatik olarak engelleyen bir intrusion prevention (izinsiz giri\u015f \u00f6nleme) yaz\u0131l\u0131m\u0131d\u0131r. Bu, kaba kuvvet sald\u0131r\u0131lar\u0131na kar\u015f\u0131 en pop\u00fcler ve etkili \u00e7\u00f6z\u00fcmlerden biridir. Fail2ban, SSH ba\u011flant\u0131lar\u0131n\u0131n yan\u0131 s\u0131ra web sunucular\u0131, FTP ve e-posta sunucular\u0131 gibi di\u011fer hizmetler i\u00e7in de yap\u0131land\u0131r\u0131labilir. Kurulumu ve yap\u0131land\u0131rmas\u0131 nispeten kolayd\u0131r:<\/p>\n Bu yap\u0131land\u0131rma, 3 ba\u015far\u0131s\u0131z denemeden sonra IP adresini 1 saat (3600 saniye) boyunca engeller.<\/li>\n<\/ol>\n Fail2ban, sunucunuzun s\u00fcrekli taranan Port 22’sini korumak i\u00e7in vazge\u00e7ilmez bir ara\u00e7t\u0131r ve botnet sald\u0131r\u0131lar\u0131n\u0131n etkisini \u00f6nemli \u00f6l\u00e7\u00fcde azalt\u0131r.<\/p>\n Daha y\u00fcksek g\u00fcvenlik seviyeleri i\u00e7in, sunucular\u0131n\u0131za do\u011frudan internet \u00fczerinden eri\u015fmek yerine bir VPN (Sanal \u00d6zel A\u011f) veya bir bastion host (s\u0131\u00e7rama tahtas\u0131 sunucusu) kullanmay\u0131 d\u00fc\u015f\u00fcnebilirsiniz. Bu y\u00f6ntemlerde, SSH ba\u011flant\u0131lar\u0131n\u0131z \u00f6nce g\u00fcvenli bir VPN a\u011f\u0131 \u00fczerinden veya internete a\u00e7\u0131k tek bir “g\u00fcvenli” sunucu (bastion host) \u00fczerinden yap\u0131l\u0131r. Ard\u0131ndan, bu VPN a\u011f\u0131 veya bastion host \u00fczerinden i\u00e7 a\u011fdaki sunucular\u0131n\u0131za eri\u015fim sa\u011flars\u0131n\u0131z. Bu, sald\u0131r\u0131 y\u00fczeyini tek bir noktaya indirger ve i\u00e7 sunucular\u0131n\u0131z\u0131n do\u011frudan internete a\u00e7\u0131k olmas\u0131n\u0131 engeller. \u00d6zellikle birden fazla sunucu y\u00f6netiyorsan\u0131z, bu merkezi eri\u015fim noktas\u0131 \u00e7ok daha g\u00fcvenli ve y\u00f6netilebilir bir \u00e7\u00f6z\u00fcm sunar.<\/p>\n Parola veya SSH anahtarlar\u0131na ek olarak, \u00e7ok fakt\u00f6rl\u00fc kimlik do\u011frulama (MFA – Multi-Factor Authentication) kullanmak, g\u00fcvenli\u011fi en \u00fcst d\u00fczeye \u00e7\u0131kar\u0131r. Bu, genellikle bir mobil uygulama (Google Authenticator gibi) taraf\u0131ndan \u00fcretilen tek kullan\u0131ml\u0131k bir kod veya fiziksel bir g\u00fcvenlik anahtar\u0131 (YubiKey gibi) ile sa\u011flan\u0131r. MFA etkinle\u015ftirildi\u011finde, bir kullan\u0131c\u0131 SSH ile ba\u011flanmak istedi\u011finde, hem do\u011fru anahtar\u0131\/parolay\u0131 girmesi hem de ek bir do\u011frulama fakt\u00f6r\u00fcn\u00fc sa\u011flamas\u0131 gerekir. Bu, bir sald\u0131rgan\u0131n sadece anahtar\u0131n\u0131z\u0131 veya parolan\u0131z\u0131 ele ge\u00e7irmesi durumunda bile sisteme eri\u015fmesini engeller.<\/p>\n Bu stratejiler, Port 22’yi tamamen kapatmadan bile sunucunuzun SSH g\u00fcvenli\u011fini \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131rabilir. Her bir y\u00f6ntemin kendi avantajlar\u0131 ve uygulama zorluklar\u0131 vard\u0131r. En iyi g\u00fcvenlik yakla\u015f\u0131m\u0131, genellikle bu stratejilerin bir kombinasyonunu kullanmakt\u0131r. Ancak benim i\u00e7in, ya\u015fanan lockout deneyiminin travmas\u0131 ve s\u00fcrekli sald\u0131r\u0131 loglar\u0131n\u0131 g\u00f6rmenin verdi\u011fi rahats\u0131zl\u0131k, daha radikal bir karara itti: Port 22’yi tamamen kapatmak.<\/p>\n Ya\u015fad\u0131\u011f\u0131m SSH lockout deneyimi ve sonras\u0131nda sunucu loglar\u0131nda g\u00f6rd\u00fc\u011f\u00fcm bitmek bilmeyen kaba kuvvet sald\u0131r\u0131s\u0131 denemeleri, beni Port 22’nin standart kullan\u0131m\u0131na kar\u015f\u0131 k\u00f6kl\u00fc bir karara itti. Her ne kadar yukar\u0131da bahsetti\u011fim g\u00fcvenlik \u00f6nlemlerinin \u00e7o\u011fu etkili olsa da, s\u00fcrekli bir “kedi-fare” oyununun i\u00e7inde olmak yorucuydu. Sunucumun, sadece varsay\u0131lan bir portta \u00e7al\u0131\u015ft\u0131\u011f\u0131 i\u00e7in s\u00fcrekli sald\u0131r\u0131 alt\u0131nda olmas\u0131 fikri beni rahats\u0131z ediyordu. Bu nedenle, sunucu g\u00fcvenli\u011fimi en \u00fcst d\u00fczeye \u00e7\u0131karmak ve zihinsel olarak daha rahat etmek ad\u0131na Port 22’yi tamamen kapatma karar\u0131 ald\u0131m. Bu, benim i\u00e7in bir g\u00fcvenlik duru\u015fu ve siber tehditlere kar\u015f\u0131 kesin bir mesajd\u0131.<\/p>\n Peki, Port 22’yi kapatt\u0131ktan sonra sunucular\u0131ma nas\u0131l eri\u015fiyorum? Cevap, \u00e7ok basit: SSH portunu de\u011fi\u015ftirmek ve sadece belirli IP adreslerinden eri\u015fime izin vermek. Art\u0131k t\u00fcm sunucular\u0131mda SSH hizmeti, standart Port 22 yerine rastgele se\u00e7ilmi\u015f, y\u00fcksek numaral\u0131 bir portta (\u00f6rne\u011fin 49152 ile 65535 aras\u0131ndaki bir port) \u00e7al\u0131\u015f\u0131yor. Ayr\u0131ca, g\u00fcvenlik duvar\u0131 kurallar\u0131m\u0131 (UFW veya iptables) yap\u0131land\u0131rarak, sadece kendi statik IP adresimden veya g\u00fcvendi\u011fim VPN a\u011f\u0131ndan bu yeni porta eri\u015fime izin veriyorum. Bu, iki katmanl\u0131 bir g\u00fcvenlik sa\u011fl\u0131yor: birincisi, portun standart olmamas\u0131 nedeniyle otomatik taray\u0131c\u0131lar taraf\u0131ndan kolayca bulunamamas\u0131; ikincisi, bulunsa bile sadece belirlenmi\u015f g\u00fcvenilir kaynaklardan eri\u015fime izin verilmesi.<\/p>\n Bu radikal karar\u0131n bana sa\u011flad\u0131\u011f\u0131 en b\u00fcy\u00fck fayda, tart\u0131\u015fmas\u0131z zihinsel rahatl\u0131kt\u0131. Art\u0131k sunucu loglar\u0131mda her g\u00fcn y\u00fczlerce ba\u015far\u0131s\u0131z SSH denemesi g\u00f6rm\u00fcyorum. Sunucular\u0131m\u0131n “sessiz” ve g\u00fcvende oldu\u011funu bilmek, bana b\u00fcy\u00fck bir huzur veriyor. Elbette, bu yakla\u015f\u0131m\u0131n baz\u0131 k\u00fc\u00e7\u00fck dezavantajlar\u0131 da yok de\u011fil. \u00d6rne\u011fin, her yeni sunucuya ba\u011flan\u0131rken veya farkl\u0131 bir konumdan eri\u015fim sa\u011flamam gerekti\u011finde, g\u00fcvenlik duvar\u0131 kurallar\u0131n\u0131 g\u00fcncellemem veya yeni bir IP adresini beyaz listeye almam gerekiyor. Ancak bu k\u00fc\u00e7\u00fck zahmetler, elde etti\u011fim g\u00fcvenlik ve huzur kar\u015f\u0131s\u0131nda devede kulak kal\u0131yor.<\/p>\n Bu deneyimden \u00e7\u0131kard\u0131\u011f\u0131m ders \u015fuydu: G\u00fcvenlik, sadece teknik bir konu de\u011fil, ayn\u0131 zamanda bir zihniyet meselesidir. Risk tolerans\u0131n\u0131z\u0131 belirlemeli ve ona g\u00f6re \u00f6nlemler almal\u0131s\u0131n\u0131z. Benim i\u00e7in Port 22’yi kapatmak, bu risk tolerans\u0131m\u0131 s\u0131f\u0131ra indirme karar\u0131yd\u0131. Herkesin bu kadar radikal bir ad\u0131m atmas\u0131 gerekmeyebilir, ancak herkesin SSH g\u00fcvenli\u011fini ciddiye almas\u0131 ve en az\u0131ndan temel \u00f6nlemleri uygulamas\u0131 \u015fartt\u0131r. Unutmay\u0131n, en zay\u0131f halka kadar g\u00fc\u00e7l\u00fcs\u00fcn\u00fczd\u00fcr. Kendi g\u00fcvenlik zincirinizdeki Port 22’nin g\u00fc\u00e7l\u00fc oldu\u011fundan emin olun.<\/p>\n SSH g\u00fcvenli\u011fi ve Port 22 ile ilgili merak edilen baz\u0131 sorular\u0131 burada yan\u0131tlamak istedim:<\/p>\n C: Her zaman gerekli olmasa da, sunucunuzun g\u00fcvenlik duru\u015funu \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131r\u0131r. E\u011fer statik bir IP adresiniz varsa veya VPN kullan\u0131yorsan\u0131z, Port 22’yi kapat\u0131p SSH’i farkl\u0131 bir portta sadece bu g\u00fcvenli kaynaklardan eri\u015fime a\u00e7mak \u00e7ok daha g\u00fcvenlidir. Bu, kaba kuvvet sald\u0131r\u0131lar\u0131n\u0131 b\u00fcy\u00fck \u00f6l\u00e7\u00fcde engeller.<\/p>\n<\/li>\n C: Hay\u0131r, tek ba\u015f\u0131na yeterli de\u011fildir. Port de\u011fi\u015ftirme, otomatik botnet taramalar\u0131n\u0131 engellese de, kararl\u0131 bir sald\u0131rgan port taramas\u0131 yaparak yeni portunuzu bulabilir. Bu nedenle, anahtar tabanl\u0131 kimlik do\u011frulama, Fail2ban ve g\u00fcvenlik duvar\u0131 kurallar\u0131 gibi ek \u00f6nlemlerle birlikte kullan\u0131lmal\u0131d\u0131r.<\/p>\n<\/li>\n C: \u00d6zel anahtar\u0131n\u0131z\u0131 (private key) bilgisayar\u0131n\u0131zda g\u00fcvenli bir yerde saklay\u0131n ve asla kimseyle payla\u015fmay\u0131n. \u00dczerine bir parola (passphrase) eklemek, ek bir g\u00fcvenlik katman\u0131 sa\u011flar. Ayr\u0131ca, anahtar dosyalar\u0131n\u0131n izinlerini (permissions) C: En iyi senaryo, sunucu sa\u011flay\u0131c\u0131n\u0131z\u0131n size bir konsol (VNC, web tabanl\u0131 konsol) eri\u015fimi sunmas\u0131d\u0131r. Bu sayede sunucuya do\u011frudan eri\u015fip C: Fail2ban, kaba kuvvet sald\u0131r\u0131lar\u0131na kar\u015f\u0131 \u00e7ok etkili bir savunma mekanizmas\u0131d\u0131r, ancak tamamen engellemez. Belirli bir s\u00fcre i\u00e7inde \u00e7ok say\u0131da ba\u015far\u0131s\u0131z deneme yapan IP’leri engeller. Ancak \u00e7ok say\u0131da farkl\u0131 IP adresinden gelen da\u011f\u0131t\u0131k (distributed) sald\u0131r\u0131lara kar\u015f\u0131 tek ba\u015f\u0131na yeterli olmayabilir. Di\u011fer g\u00fcvenlik \u00f6nlemleriyle birlikte kullan\u0131lmas\u0131 \u00f6nerilir.<\/p>\n<\/li>\n<\/ul>\n Bu makalede, SSH lockout deneyimimden yola \u00e7\u0131karak Port 22’nin g\u00fcvenlik risklerini, SSH’i g\u00fcvenli hale getirme y\u00f6ntemlerini ve nihayetinde neden Port 22’yi tamamen kapatma karar\u0131 ald\u0131\u011f\u0131m\u0131 anlatt\u0131m. Umar\u0131m bu bilgiler, kendi sunucular\u0131n\u0131z\u0131n g\u00fcvenli\u011fini art\u0131rman\u0131za yard\u0131mc\u0131 olur ve sizi benim ya\u015fad\u0131\u011f\u0131m t\u00fcrden bir kabustan korur. G\u00fcvenli\u011finiz her zaman \u00f6nceli\u011finiz olsun!<\/p>\n #SSH #SunucuG\u00fcvenli\u011fi #SiberG\u00fcvenlik #Port22 #Linux #SistemY\u00f6netimi<\/p>\n\/etc\/ssh\/sshd_config<\/code> \u00fczerinde gerekli de\u011fi\u015fiklikleri yapt\u0131m. PermitRootLogin no<\/code> ve PasswordAuthentication no<\/code> sat\u0131rlar\u0131n\u0131 ekledim veya mevcut olanlar\u0131 d\u00fczenledim. Ard\u0131ndan, kendi kullan\u0131c\u0131 hesab\u0131m i\u00e7in bir SSH anahtar \u00e7ifti olu\u015fturup, genel anahtar\u0131m\u0131 (public key) sunucuya kopyalad\u0131m. Her \u015fey yolunda g\u00f6r\u00fcn\u00fcyordu. Yap\u0131land\u0131rma de\u011fi\u015fikliklerinin etkili olmas\u0131 i\u00e7in SSH hizmetini yeniden ba\u015flatmam gerekiyordu. B\u00fcy\u00fck bir \u00f6zg\u00fcvenle sudo systemctl restart sshd<\/code> komutunu girdim. \u0130\u015fte tam bu an, felaketin kap\u0131s\u0131 araland\u0131. Komut sorunsuz \u00e7al\u0131\u015fm\u0131\u015f gibi g\u00f6r\u00fcn\u00fcyordu ve herhangi bir hata mesaj\u0131 almad\u0131m. Eski SSH oturumumu kapat\u0131p, yeni ayarlar\u0131n do\u011fru \u00e7al\u0131\u015f\u0131p \u00e7al\u0131\u015fmad\u0131\u011f\u0131n\u0131 test etmek i\u00e7in yeni bir ba\u011flant\u0131 denemesi yapt\u0131m.<\/p>\nssh benimkullanicim@sunucu_ip_adresi<\/code> komutunu girdim ve enter tu\u015funa bast\u0131m. Birka\u00e7 saniye s\u00fcren bekleyi\u015fin ard\u0131ndan, bekledi\u011fim gibi bir parola istemi gelmedi. Ancak bekledi\u011fim SSH kabu\u011fu (shell) yerine, \u015fu mesajla kar\u015f\u0131la\u015ft\u0131m: Permission denied (publickey).<\/code> \u0130lk ba\u015fta panik yapmad\u0131m. Muhtemelen anahtar\u0131m\u0131 yanl\u0131\u015f kopyalad\u0131m veya izinleri (permissions) yanl\u0131\u015f ayarlad\u0131m diye d\u00fc\u015f\u00fcnd\u00fcm. H\u0131zl\u0131ca kontrol etmek i\u00e7in tekrar denedim, farkl\u0131 bir anahtarla denedim, hatta root olarak ba\u011flanmay\u0131 bile denedim (ki bu zaten kapat\u0131lm\u0131\u015ft\u0131). Her denememde ayn\u0131 Permission denied<\/code> hatas\u0131n\u0131 ald\u0131m. Birka\u00e7 dakika sonra, kalbim h\u0131zla \u00e7arpmaya ba\u015flad\u0131. Sunucuya art\u0131k eri\u015femiyordum. Ne parola ile ne de SSH anahtar\u0131 ile. T\u00fcm kap\u0131lar \u00fczerime kapanm\u0131\u015ft\u0131.<\/p>\nG\u00fcvenlik A\u00e7\u0131klar\u0131 ve Port 22’nin Hedef Olmas\u0131<\/h2>\n
\/var\/log\/auth.log<\/code> veya \/var\/log\/secure<\/code>) inceledi\u011finizde, bu t\u00fcr sald\u0131r\u0131lar\u0131n ne kadar yayg\u0131n oldu\u011funu deh\u015fetle g\u00f6rebilirsiniz. Ba\u015far\u0131s\u0131z oturum a\u00e7ma denemeleriyle dolu y\u00fczlerce, hatta binlerce sat\u0131rla kar\u015f\u0131la\u015fmak i\u015ften bile de\u011fildir. \u0130\u015fte size tipik bir log \u00e7\u0131kt\u0131s\u0131ndan bir \u00f6rnek:<\/p>\n\nDec 15 10:30:01 sunucum sshd[12345]: Failed password for root from 192.0.2.1 port 54321 ssh2\nDec 15 10:30:02 sunucum sshd[12346]: Failed password for invalid user admin from 198.51.100.2 port 12345 ssh2\nDec 15 10:30:03 sunucum sshd[12347]: Failed password for root from 203.0.113.3 port 67890 ssh2\n <\/code><\/pre>\n<\/p><\/div>\nSSH G\u00fcvenli\u011fini Art\u0131rman\u0131n \u0130lk Ad\u0131mlar\u0131: Temel Yap\u0131land\u0131rmalar<\/h2>\n
1. Parola Yerine Anahtar Tabanl\u0131 Kimlik Do\u011frulama Kullan\u0131m\u0131<\/h3>\n
~\/.ssh\/authorized_keys<\/code> dosyas\u0131na yerle\u015ftirilir. Ba\u011flant\u0131 kuruldu\u011funda, sunucu genel anahtar\u0131n\u0131z\u0131 kullanarak \u00f6zel anahtar\u0131n\u0131z\u0131n sizde olup olmad\u0131\u011f\u0131n\u0131 kriptografik olarak do\u011frular. Bu y\u00f6ntem, parolalar\u0131n tahmin edilmesini veya \u00e7al\u0131nmas\u0131n\u0131 neredeyse imkans\u0131z hale getirir.<\/p>\n\n
\nssh-keygen -t rsa -b 4096\n <\/code><\/pre>\n<\/p><\/div>\n\nssh-copy-id kullaniciadi@sunucu_ip_adresi\n <\/code><\/pre>\n<\/p><\/div>\n~\/.ssh\/id_rsa.pub<\/code>) sunucudaki ~\/.ssh\/authorized_keys<\/code> dosyas\u0131na manuel olarak kopyalayabilirsiniz.\n <\/li>\n<\/ol>\n\/etc\/ssh\/sshd_config<\/code> dosyas\u0131nda PasswordAuthentication no<\/code> yaparak parola ile oturum a\u00e7may\u0131 tamamen devre d\u0131\u015f\u0131 b\u0131rakmal\u0131s\u0131n\u0131z. Bu, benim lockout ya\u015famama neden olan kritik ad\u0131mlardan biriydi, ancak do\u011fru uyguland\u0131\u011f\u0131nda en \u00f6nemli g\u00fcvenlik art\u0131r\u0131c\u0131 \u00f6nlemdir.<\/p>\n2. Root Eri\u015fimi Kapatma<\/h3>\n
sudo<\/code> komutunu kullanarak y\u00f6netici yetkileri alman\u0131z \u00f6nerilir. Bu ayar\u0131 yapmak i\u00e7in \/etc\/ssh\/sshd_config<\/code> dosyas\u0131nda \u015fu sat\u0131r\u0131 d\u00fczenleyin:<\/p>\n\nPermitRootLogin no\n <\/code><\/pre>\n<\/p><\/div>\nsudo<\/code> yetkisine sahip oldu\u011fundan emin olun.<\/p>\n3. SSH Portunu De\u011fi\u015ftirme (Non-Standard Port)<\/h3>\n
\/etc\/ssh\/sshd_config<\/code> dosyas\u0131nda \u015fu sat\u0131r\u0131 d\u00fczenleyin:<\/p>\n\nPort 2222\n <\/code><\/pre>\n<\/p><\/div>\nsudo ufw allow 2222\/tcp<\/code>.<\/p>\n4. \u0130zin Verilen Kullan\u0131c\u0131lar\u0131 ve Gruplar\u0131 Belirleme<\/h3>\n
\/etc\/ssh\/sshd_config<\/code> dosyas\u0131nda AllowUsers<\/code> veya AllowGroups<\/code> direktiflerini kullanabilirsiniz:<\/p>\n\nAllowUsers benimkullanicim digerkullanici\nAllowGroups sshusers\n <\/code><\/pre>\n<\/p><\/div>\nPort 22’yi Kapatmak Yerine Alternatif G\u00fcvenlik Stratejileri<\/h2>\n
1. G\u00fcvenlik Duvar\u0131 (Firewall) Kullan\u0131m\u0131<\/h3>\n
\n# UFW ile belirli bir IP'den SSH eri\u015fimine izin verme\nsudo ufw allow from 203.0.113.100 to any port 22\n\n# iptables ile ayn\u0131 kural\nsudo iptables -A INPUT -p tcp --dport 22 -s 203.0.113.100 -j ACCEPT\nsudo iptables -A INPUT -p tcp --dport 22 -j DROP\n <\/code><\/pre>\n<\/p><\/div>\n203.0.113.100<\/code> IP adresinden gelen ba\u011flant\u0131lar d\u0131\u015f\u0131ndaki t\u00fcm SSH ba\u011flant\u0131lar\u0131n\u0131 reddeder. Bu, \u00f6zellikle sabit bir IP adresine sahipseniz veya bir VPN \u00fczerinden ba\u011flan\u0131yorsan\u0131z son derece etkili bir y\u00f6ntemdir.<\/p>\n2. Fail2ban Entegrasyonu<\/h3>\n
\n
sudo apt install fail2ban<\/code> (Debian\/Ubuntu)<\/li>\n\/etc\/fail2ban\/jail.local<\/code> dosyas\u0131n\u0131 d\u00fczenleyerek SSH i\u00e7in bir b\u00f6l\u00fcm ekleyebilirsiniz:\n\n[sshd]\nenabled = true\nport = ssh\nfilter = sshd\nlogpath = \/var\/log\/auth.log\nmaxretry = 3\nbantime = 3600\n <\/code><\/pre>\n<\/p><\/div>\n3. VPN veya Bastion Host Kullan\u0131m\u0131<\/h3>\n
4. \u00c7ok Fakt\u00f6rl\u00fc Kimlik Do\u011frulama (MFA)<\/h3>\n
Benim Nihai Karar\u0131m: Port 22’yi Sonsuza Dek Kapatmak<\/h2>\n
S\u0131k\u00e7a Sorulan Sorular<\/h3>\n
\n
chmod 400 ~\/.ssh\/id_rsa<\/code> gibi komutlarla yaln\u0131zca sizin okuyabilece\u011finiz \u015fekilde ayarlay\u0131n.<\/p>\n<\/li>\nsshd_config<\/code> dosyas\u0131n\u0131 d\u00fczeltebilirsiniz. E\u011fer konsol eri\u015fiminiz yoksa, sa\u011flay\u0131c\u0131n\u0131zla ileti\u015fime ge\u00e7erek sunucunuzu kurtarma modunda (rescue mode) ba\u015flatmalar\u0131n\u0131 veya size ge\u00e7ici bir eri\u015fim sa\u011flamalar\u0131n\u0131 isteyebilirsiniz. Her zaman bir yedek eri\u015fim plan\u0131n\u0131z\u0131n olmas\u0131 kritik \u00f6neme sahiptir.<\/p>\n<\/li>\n