WEBVTT

00:00.660 --> 00:01.710
Öğretim Görevlisi: Bu

00:01.710 --> 00:04.920
derste yük dengeleyicilerin önemi hakkında konuşacağız.

00:04.920 --> 00:06.120
Artık içerik anahtarı

00:06.120 --> 00:08.340
olarak da bilinen yük dengeleyiciler,

00:08.340 --> 00:10.410
gelen talepleri bir sunucu formu veya

00:10.410 --> 00:11.910
bir bulut altyapısı içindeki

00:11.910 --> 00:15.330
bir dizi sunucuya dağıtmak için kullanılmaktadır.

00:15.330 --> 00:17.370
Büyük bir web sitesi veya hizmet işletiyorsanız,

00:17.370 --> 00:20.040
bunların hepsini tek bir sunucuda yapamazsınız.

00:20.040 --> 00:22.680
Örneğin, şu anda kurslarımı alan ve videolarımı

00:22.680 --> 00:23.513
izleyen birkaç

00:23.513 --> 00:25.680
yüz bin öğrencim var.

00:25.680 --> 00:29.100
Tek bir sunucunun bu kadar yükü kaldırmasına imkan yok.

00:29.100 --> 00:30.630
Bu yüzden bunu dünyanın dört bir

00:30.630 --> 00:32.460
yanındaki pek çok farklı sunucuya dağıtmamız

00:32.460 --> 00:33.810
gerekiyor.

00:33.810 --> 00:36.300
Ancak bir öğrenci web sitemi ziyaret etmek istediğinde,

00:36.300 --> 00:38.340
belirli bir sunucu seçmek zorunda değil.

00:38.340 --> 00:41.070
Bunun yerine, sadece diontraining'e gidiyorlar. com'a yönlendirir ve yük

00:41.070 --> 00:43.230
dengeleyicimiz ve içerik anahtarımız

00:43.230 --> 00:45.960
bu isteği işleyebilmek için bir sonraki uygun sunucuya

00:45.960 --> 00:47.460
yönlendirir.

00:47.460 --> 00:49.590
Aslında, tüm bu farklı talepleri karşılamak

00:49.590 --> 00:50.880
için dünyanın her yerinde

00:50.880 --> 00:53.100
bulunan tonlarca farklı sunucumuz var.

00:53.100 --> 00:55.230
Aynı şey Netflix, Hulu, Facebook

00:55.230 --> 00:57.480
ya da Amazon'da da oluyor ama çok

00:57.480 --> 00:59.280
daha büyük ölçekte.

00:59.280 --> 01:01.920
Tüm bu büyük web siteleri bir yük dengeleyici kullanmak zorundadır,

01:01.920 --> 01:03.570
aksi takdirde tek bir sunucu yük altında

01:03.570 --> 01:06.263
çökecek ve web sitelerinin popülerliği nedeniyle kendi kendilerine

01:06.263 --> 01:08.400
uygulanan bir Hizmet Reddi Saldırısına maruz

01:08.400 --> 01:10.650
kalacaklardır.

01:10.650 --> 01:12.510
Şimdi bir yük dengeleyici, sunucularınızın

01:12.510 --> 01:13.500
önünde oturarak ve müşterinin

01:13.500 --> 01:15.120
talebini herhangi bir zamanda bu talepleri

01:15.120 --> 01:17.310
yerine getirmek için en uygun olan sunuculara yönlendirerek

01:17.310 --> 01:20.970
esasen bir trafik polisi görevi görür.

01:20.970 --> 01:23.940
Bu, kullanıcıya yanıt verme hızını en üst düzeye çıkarır ve

01:23.940 --> 01:25.530
tüm kullanıcı talepleriniz için

01:25.530 --> 01:28.170
sunucularınız için mevcut kapasitenizin tamamını daha

01:28.170 --> 01:30.060
verimli bir şekilde kullanır.

01:30.060 --> 01:32.220
Bir yük dengeleyicinin bu kadar önemli olmasının nedeni,

01:32.220 --> 01:34.230
Hizmet Reddi Saldırısına veya Dağıtılmış Hizmet

01:34.230 --> 01:36.750
Reddi Saldırısına karşı savunmaya yardımcı olmak için yapabileceğimiz

01:36.750 --> 01:39.270
temel şeylerden biri olmasıdır.

01:39.270 --> 01:41.730
Şimdi, Hizmet Reddi Saldırısı nedir?

01:41.730 --> 01:43.560
Hizmet Reddi Saldırısı, kurban sistemlerin

01:43.560 --> 01:46.410
sürekli olarak hizmet talepleriyle dolup taşmasını,

01:46.410 --> 01:48.090
sistemin belleğinin tükenmesine

01:48.090 --> 01:50.070
ve sonunda çökmesine neden olmasını

01:50.070 --> 01:51.570
içerir.

01:51.570 --> 01:52.830
Ancak artık çoğu modern sistem

01:52.830 --> 01:55.230
tek bir makine tarafından çökertilemiyor.

01:55.230 --> 01:58.230
Saldırganlar bunun yerine DDoS ya da Dağıtılmış Hizmet

01:58.230 --> 02:00.540
Engelleme Saldırısı kullanırlar.

02:00.540 --> 02:02.490
Dağıtılmış Hizmet Reddi Saldırısında,

02:02.490 --> 02:04.920
bir sunucuyu hedef alan tek bir saldırgan yerine,

02:04.920 --> 02:07.200
sunucuyu çevrimdışı olmaya zorlamak için

02:07.200 --> 02:10.050
aynı anda bu saldırıyı başlatan yüzlerce hatta binlerce

02:10.050 --> 02:11.670
makine vardır.

02:11.670 --> 02:14.040
Örneğin Mart 2018'de GitHub bugüne kadarki

02:14.040 --> 02:16.410
en büyük DDoS saldırısına maruz kalmıştır.

02:16.410 --> 02:18.570
On binlerce benzersiz uç nokta koordineli

02:18.570 --> 02:20.160
bir saldırı gerçekleştirerek

02:20.160 --> 02:22.230
sunucuyu 1 katına varan bir trafik artışıyla

02:22.230 --> 02:25.620
vurmuştur. Saniyede 35 terabit.

02:25.620 --> 02:28.980
Bu durum siteyi beş dakikalığına çevrimdışı hale getirdi.

02:28.980 --> 02:30.750
Ancak asıl soru şu: Bu saldırılardan

02:30.750 --> 02:32.670
birinde nasıl hayatta kalabilir ve kuruluşumuzun

02:32.670 --> 02:35.760
sunucularını çökertmesini nasıl önleyebiliriz?

02:35.760 --> 02:37.620
En iyi uygulamalardan bazıları için

02:37.620 --> 02:39.330
Amazon'a bakmamız yeterli.

02:39.330 --> 02:41.520
Gördüğünüz gibi, 2020 yılının Şubat ayında Amazon,

02:41.520 --> 02:44.130
GitHub'dan bile daha büyük, bugüne kadarki en büyük DDoS

02:44.130 --> 02:45.630
tarafından vuruldu.

02:45.630 --> 02:47.130
Ve bu sunucuya 2 katına çıkan

02:47.130 --> 02:49.230
bir trafik artışıyla vurmak için koordineli

02:49.230 --> 02:52.410
bir saldırı yapıldı. Saniyede 3 terabit, ancak sahip

02:52.410 --> 02:55.470
oldukları iyi güvenlik mimarisi ve bu saldırıyı sürdürmek

02:55.470 --> 02:58.950
için kaynakları ölçeklendirme yetenekleri sayesinde, GitHub'ı

02:58.950 --> 03:01.650
çökertenden %70 daha büyük olmasına rağmen saldırı

03:01.650 --> 03:05.880
sırasında hiçbir kesinti yaşamadılar.

03:05.880 --> 03:07.410
Kullandıkları ilk teknik kara

03:07.410 --> 03:09.750
delik ya da sinkholing olarak biliniyor.

03:09.750 --> 03:10.800
Bu, saldıran IP adreslerini

03:10.800 --> 03:13.020
tanımlayan ve tüm trafiğini boş bir arayüz

03:13.020 --> 03:14.400
üzerinden var olmayan bir

03:14.400 --> 03:17.160
sunucuya yönlendiren ve saldırıyı etkili bir şekilde

03:17.160 --> 03:19.410
durduran bir tekniktir.

03:19.410 --> 03:22.050
Ne yazık ki, saldırganlar her zaman yeni bir IP'ye geçebilir

03:22.050 --> 03:23.760
ve saldırıyı yeniden başlatabilir.

03:23.760 --> 03:25.950
Yani bir DDoS'u sonsuza kadar engellemeyecektir,

03:25.950 --> 03:27.480
ancak diğer hafifletmeler üzerinde

03:27.480 --> 03:29.640
çalışırken size biraz zaman kazandıracaktır.

03:29.640 --> 03:32.070
IPS'ler veya İzinsiz Giriş Önleme Sistemleri, Hizmet

03:32.070 --> 03:33.510
Reddi Saldırılarını belirlemek

03:33.510 --> 03:35.730
ve bunlara yanıt vermek için de kullanılabilir.

03:35.730 --> 03:37.560
Bu, ağınıza yönelik küçük ölçekli saldırılar

03:37.560 --> 03:38.520
için işe yarayabilir,

03:38.520 --> 03:40.920
ancak Amazon'un hedef alındığı gibi gerçekten büyük

03:40.920 --> 03:42.780
ölçekli bir saldırıyla başa çıkmak için yeterli

03:42.780 --> 03:45.060
işlem gücüne sahip olmayacaktır.

03:45.060 --> 03:46.920
Şu anda en etkili yöntemlerden biri

03:46.920 --> 03:49.140
elastik bulut altyapısı kullanmaktır, çünkü

03:49.140 --> 03:52.290
gerektiğinde ölçeklendirmenize olanak tanır, böylece saldırıyı

03:52.290 --> 03:54.300
atlatabilirsiniz.

03:54.300 --> 03:55.770
Ancak bu stratejiyle ilgili sorun,

03:55.770 --> 03:57.090
çoğu hizmet sağlayıcının sizi

03:57.090 --> 03:58.920
kullandığınız kapasite ve kaynaklara göre

03:58.920 --> 04:00.510
ücretlendirecek olmasıdır.

04:00.510 --> 04:02.190
Dolayısıyla ölçek büyüttükçe, bu durum

04:02.190 --> 04:04.380
bulut hizmet sağlayıcımızdan çok daha büyük bir

04:04.380 --> 04:05.940
fatura almamıza neden olur ve bu,

04:05.940 --> 04:07.320
herhangi bir yatırım getirisi

04:07.320 --> 04:09.390
elde edemediğimiz bir şey olabilir, çünkü tüm

04:09.390 --> 04:12.030
bu trafik kuruluşumuz için herhangi bir gelir yaratmıyordu,

04:12.030 --> 04:13.110
hepsi sadece saldırının

04:13.110 --> 04:15.090
bir parçasıydı.

04:15.090 --> 04:17.280
Bununla birlikte, en azından ödeme yapan müşterilerinize hizmet

04:17.280 --> 04:18.750
vermek için çevrimiçi kalıyorsunuz.

04:18.750 --> 04:20.400
Dolayısıyla mesele, DDoS saldırısının

04:20.400 --> 04:22.140
devam edebileceğinden daha uzun süre dayanmayı

04:22.140 --> 04:24.213
göze alıp alamayacağınızla ilgilidir.