|
Son zamanlarda, bazı özel faktörler nedeniyle bir MySQL sunucusu ortaya çıktı“HATA 1129 (00000): Host 'xxx' birçok bağlantı hatası nedeniyle engellenmiştir. 'mysqladmin flush-hosts' ile engeli kaldırın”Sorun çözüldükten sonra, parametre max_connect_errors hakkında daha fazla bilgi edinirken, farklı ağ verilerinin çelişkili açıklamaları beni biraz şaşırttı (bu hata hakkında, temel sebep aynı IP'nin kısa sürede çok fazla kesintili veritabanı bağlantısı (maksimum max_connect_errors değerini aşması) üretmiş olmasıdır ve aşağıda ise sorunlarımı inceleme, analiz etme ve şüpheleri netleştirme süreci var. Öncelikle, internette bazı bilgileri aradım, çoğu şifre giriş girişi sayısı max_connect_errors değişkeni aşırsa MySQL'in bu istemci girişini engelleyeceğine dair yeminler yaptım ve ardından aşağıda gösterildiği gibi max_connect_errors'nin tanıtımıyla ilgili resmi bilgileri buldum, MySQL 5.6/5.7 aynı Bir ana bilgisayardan gelen bu ardışık bağlantı talebinin bu kadar sayısı başarılı bir bağlantı olmadan kesintiye uğrarsa, sunucu o ana bilgisayarın daha fazla bağlantıya erişimini engeller. Engellenen ana bilgisayarları önbelleğini temizleyerek engeli açabilirsin. Bunu yapmak için bir FLUSH HOSTS ifadesi verin veya mysqladmin flush-hosts komutunu çalıştırın. Önceki bir bağlantı kesildikten sonra max_connect_errors denemeden az sürede bir bağlantı başarıyla kurulursa, ana bilgisayarın hata sayısı sıfıra indirilir. Ancak, bir ana bilgisayar engellendikten sonra, ana önbelleği temizlemek onu engellemenin tek yoludur. Varsayılan 100. Yukarıda gösterildiği gibi, çeviri yaklaşık olarak şöyledir: MySQL sunucusu aynı ana bilgisayardan ardışık istekler alırsa ve bu ardışık isteklerin tamamı bağlantı kurulamadan kesintiye uğrarsa, bu ardışık isteklerin kümülatif değeri max_connect_errors belirlenen değerden büyük olduğunda, MySQL sunucusu bu konaktan gelen tüm sonraki istekler engeller. Bu bilgiyi başta gördüğünüzde, saldırıya uğrayacağınızı düşünüyorum“Bir ana bilgisayardan gelen birçok ardışık bağlantı talebi başarılı bir bağlantı olmadan kesintiye uğrar”Aslında kafam karıştı, bunun sebebi veritabanı bağlantısının ağ anormallikleri nedeniyle iptal edilmesidir. İnternette böyle bilgiler aradım: Bu değişken etrafında bir karışıklık var gibi görünüyor. Aslında tekrar eden geçersiz şifreler için ana bilgisayarları engellemiyor, ancak ağ hataları nedeniyle iptal edilen bağlantılar için engelliyor. O zaman kendimiz deneyip doğrulayabiliriz ve hangisinin doğru olduğunu öğrenebiliriz. MySQL veritabanında bir test hesabı oluşturun ve ardından max_connect_errors değişkenini şu şekilde ayarlıyoruz3. Sonra başka bir test makinesi kullanarak MySQL veritabanına yanlış şifreyle bağlanıyoruz; aşağıda gösterildiği gibi, önceki üç yanlış şifre girilse bile, dördüncü giriş yukarıdaki hatayla karşılaşmaz.O zaman bu değişkenin yanlış şifre girişiyle ilgili olduğunu ede bırakabilirsiniz. [root@mytestlnx02 TMP]# mySQL -h10.20.57.24 -utest -p Şifreyi girin: HATA 1045 (28000): Kullanıcı 'test'@'mytestlnx02' için erişim reddedildi (şifre kullanılarak: EVET) [root@mytestlnx02 TMP]# mySQL -h10.20.57.24 -utest -p Şifreyi girin: HATA 1045 (28000): Kullanıcı 'test'@'mytestlnx02' için erişim reddedildi (şifre kullanılarak: EVET) [root@mytestlnx02 TMP]# mySQL -h10.20.57.24 -utest -p Şifreyi girin: HATA 1045 (28000): Kullanıcı 'test'@'mytestlnx02' için erişim reddedildi (şifre kullanılarak: EVET) [root@mytestlnx02 TMP]# mySQL -h10.20.57.24 -utest -p Şifreyi girin: HATA 1045 (28000): Kullanıcı 'test'@'mytestlnx02' için erişim reddedildi (şifre kullanılarak: EVET) [root@mytestlnx02 tmp] # Aslında, bir IP yanlış şifre girerse, MySQL bunu performance_schema veritabanının altındaki host_cache tablosuna kaydeder. COUNT_AUTHENTICATION_ERRORS tarlalarda kümülatif olarak şu şekilde kaydedilmiştir:
Resmi bilgilere göre, host_cache alanı istatistiksel olarak şu şekilde kabul edilir“Tıkanıklık”bağlantı hataları (max_connect_errors sistem değişkenlerine göre değerlendirilir). Sadece protokol el sıkışma hataları sayılır ve yalnızca kimlik doğrulamalı hostlar için kullanılır (HOST_VALIDATED = EVET). SUM_CONNECT_ERRORS "Engelleme" olarak kabul edilen bağlantı hatalarının sayısı (max_connect_errorssistem değişkeni). Sadece protokol el sıkışma hataları sayılır ve sadece doğrulamayı geçen (HOST_VALIDATED = EVET) hostlar için geçerlidir. MySQLİstemcinin veritabanıyla bağlantı kurmak için üç kez el sıkışma protokolü başlatması gerekir, normal koşullarda bu süre çok kısadır, ancak ağ anormalliği, ağ zaman aşımı ve diğer faktörler ortaya çıktığında, el sıkışma protokolü tamamlanamaz, MySQL'in bir parametresi connect_timeout, MySQL sunucu sürecinin bağlantının kurulmasını saniyeler içinde bekleme zamanıdır. Protokol el sıkışması connect_timeout zaman diliminden sonra hâlâ tamamlanmazsa, MySQL istemcisi aşağıdaki gibi bir istisna mesajı ile bir istisna alacaktır: 'XXX' konumunda MySQL sunucusuna bağlantı kayboldu, sistem hatası: errno, değişken varsayılan olarak 10 saniye olur:
Ağ zaman aşımına bağlı veritabanı bağlantısının kesildiği bir durum oluşturalım, Linux'ta netem ve tc komutlarını kullanarak karmaşık bir ortamda ağ iletim gecikmesini simüle ederiz, aşağıdaki ayarlardan sonra, test sunucusundan MySQL sunucusuna erişim için 11 saniyelik bir gecikme olur: [root@gettestlnx02 ~]# ping 10.20.57.24 PING 10.20.57.24 (10.20.57.24) 56(84) bayt veri. 10.20.57.24'ten itibaren 64 bayt: icmp_seq=1 ttl=62 time=0.251 ms 10.20.57.24'ten itibaren 64 bayt: icmp_seq=2 ttl=62 time=0.330 ms 10.20.57.24'ten itibaren 64 bayt: icmp_seq=3 ttl=62 zaman=0.362 ms 64 bayt 20.10.57.24'ten itibaren: icmp_seq=4 ttl=62 time=0.316 ms 10.20.57.24'ten itibaren 64 bayt: icmp_seq=5 ttl=62 zaman=0.281 ms 64 bayt 10.20.57.24'ten itibaren : icmp_seq=6 ttl=62 zaman=0.377 ms ^C --- 10.20.57.24 ping istatistikleri --- 6 paket iletildi, 6 alındı, %0 paket kaybı, zaman 5716ms rtt min/avg/max/mdev = 0.251/0.319/0.377/0.047 ms [root@gettestlnx02 ~]# tc qdisc add dev eth0 root netem delay 11000ms [root@gettestlnx02 ~]# ping 10.20.57.24 PING 10.20.57.24 (10.20.57.24) 56(84) bayt veri. 64 bayt 20.10.57.24'ten itibaren: icmp_seq=1 ttl=62 time=11000 ms 64 bayt 10.20.57.24'ten: icmp_seq=2 ttl=62 time=11000 ms 10.20.57.24'ten itibaren 64 bayt: icmp_seq=3 ttl=62 time=11000 ms 10.20.57.24'ten itibaren 64 bayt: icmp_seq=4 ttl=62 time=11000 ms 10.20.57.24'ten itibaren 64 bayt: icmp_seq=5 ttl=62 time=11000 ms 64 bayt 10.20.57.24'ten itibaren: icmp_seq=6 ttl=62 time=11000 ms 64 bayt 20.10.57.24'ten başlayarak: icmp_seq=7 ttl=62 time=11000 ms
Aşağıda gösterildiği gibi get testlnx02 test sunucusunda MySQL veritabanına bağlanıyoruz (bu sunucuya ssh ile bağlanıyorsanız, şu anda gettestlnx02'de çalışmak oldukça yavaş olacaktır.) Tabii ki, MySQL sunucusunda ağ gecikmesini simüle edebilirsiniz veya hem connect_timeout hem de ağ gecikmesini küçültebilirsiniz) [root@gettestlnx02 ~]# mysql -h10.20.57.24 -utest -p Şifreyi girin: ERROR 2013 (HY000): 'Yetkilendirme paketi okunur' sırasında MySQL sunucusuna bağlantı kaybedildi, sistem hatası: 0 [root@gettestlnx02 ~] # Yukarıda gösterildiği gibi, 10 saniyeden fazla ağ gecikmesi nedeniyle MySQL bağlantısı başarısız oldu; bu sırada, MySQL sunucusunda host_cache tablosunu sorguladığınızda, SUM_CONNECT_ERRORS'in 1 olduğunu ve COUNT_HANDSHAKE_ERRORS'nin de değiştiğini göreceksiniz1.
Sonra böyle üç kez tekrar attık ve SUM_CONNECT_ERRORS 3 olur, COUNT_HANDSHAKE_ERRORS ise 3 olur. Sonra netem ve tc komutlarıyla test sunucusunda ağ gecikmesi simülasyonunu iptal ederiz ve ardından aşağıdaki testte gösterildiği gibi MySQL veritabanına test bağlantısına gideriz: [root@gettestlnx02 ~]# TC qdisc del dev eth0 root netem delay 11000ms [root@gettestlnx02 ~]# mysql -h10.20.57.24 -utest -p Şifreyi girin: ERROR 1129 (HY000): Host '192.168.27.180' birçok bağlantı hatası nedeniyle engellenmiştir; 'Mysqladmin flush-hosts' ile bloku kaldırın [root@gettestlnx02 ~] #
Şu anda inşa edilebilir“ERROR 1129 (HY000): Host '192.168.27.180' birçok bağlantı hatası nedeniyle engellenmiştir; 'Mysqladmin flush-hosts' ile bloku kaldırın”Yanlış. çözüm Çözüldü HATA 1129 (00000): Host 'xxx' birçok bağlantı hatası nedeniyle engellendi. 'mysqladmin flush-hosts' ile Unblock hatasını almanın birçok yolu var, ancak bazıları geçicidir. Geçici plan, göstergelerin kök nedeni ele almamasıdır. Anahtar, ağ hatalarını düzeltmek (ki bunlar genellikle ağ yöneticilerine veya sistem yöneticilerine danışma gerektirir) Çözüm: 1, değişkenin değerini max_connection_errors daha büyük bir değere ayarlayın
Bu geçici çözüm, IP'nin yasaklanması için sadece bir gecikme tetikleme koşuludur ve karmaşık durumlarda veya yüksek eşzamanlılıkta büyük bir değer ayarlamak gerekir, aksi takdirde kolayca tekrar tetiklenir. Ayrıca, değişkenler yalnızca mevcut ortamda etkili olur ve yeniden başlatılırsa süresi döner. 2: kullanımFlört hostları mysql> flush hostlar; Sorgu tamam, 0 satır etkilendi (0.00 saniye) mysql> performance_schema.host_cache'den * seçin; Boş set (0.00 saniye) mysql> Tabii ki, mysqladmin flush-hosts komutunu da kullanarak ana bilgisayarın önbellek bilgilerini temizleyebilirsiniz [root@DB-Server ~]# mysqladmin --port=3306 -uroot -p flush-host Şifreyi girin: Peki ana önbellek nedir? Resmi giriş şu şekildedir: MySQL sunucusu, istemciler hakkında bilgi içeren bir ana önbelleği barındırır: IP adresi, ana bilgisayar adı ve hata bilgileri. Sunucu, bu önbelleği yerel olmayan TCP bağlantıları için kullanır. Bir loopback arayüz adresi (127.0.0.1 veya ::1) kullanılarak kurulan TCP bağlantıları veya Unix soket dosyası, adlandırılmış boru veya paylaşılan bağlantılar için önbelleği kullanmaz Anı. Basitçe söylemek gerekirse, MySQL sunucusu istemci bilgilerini içeren bir önbellek tutar: IP adresi, ana adı, hata mesajı vb. Sunucu, yerel olmayan TCP bağlantı bilgilerini önbelleyer. Loopback arayüz adresleri (127.0.0.1 veya ::1) kullanılarak yapılan TCP bağlantılarını veya Unix soket dosyaları, adlandırılmış boru hatları veya paylaşılan bellek kullanılarak yapılan bağlantıları önbellemez. Ana önbellek bilgisi performance_schema veritabanındaki host_cache tablosu üzerinden sorgulanabilir. 3: Değişkeni host_cache_size olarak ayarlayın0 Aslında, MySQL sunucusunun ana önbellek bilgilerini kaydetmemesi için bunun en güvenilmez çözüm olduğunu söyleyebilirim. Bu yöntem tamamen göz ardı edilebilir.
| 
Yayınlandı 8.04.2019 11:01:48
|
|
|
|
