Günlüklerimizde istek veya kullanıcı temsilcisi olmadan 408 hata alıyorum

Apache günlüklerimizde buna benzer görünen çok fazla istek alıyorum

www.example.com:80 10.240.1.8 - - [06/Mar/2013:00:39:19 +0000] "-" 408 0 "-" "-" -

İstek ve kullanıcı aracısı yok gibi görünüyor. Bunu daha önce gören oldu mu?

Web sunucularınızı Amazon'da bir Elastik Yük Dengeleyicisinin arkasında çalıştırma şansınız var mı?

Sağlık kontrolleri nedeniyle 408 fazla cevap ürettikleri görülüyor .

Bu forum başlığındaki bazı çözümler:

• RequestReadTimeout header=0 body=0

  Bir istek zaman aşımına uğrarsa, bu 408 yanıtını devre dışı bırakır.

• ELB sağlık kontrolünü farklı bir port olarak değiştirin.

• ELB IP adresleri için günlüğü şu şekilde devre dışı bırakın:

  SetEnvIf Remote_Addr "10\.0\.0\.5" exclude_from_log
  CustomLog logs/access_log common env=!exclude_from_log
  

Ve bu blog gönderisinden :

• İsteğiniz zaman aşımını 60 veya üstü olacak şekilde ayarlayın.

Bir şey bağlantı noktasına bağlanıyor ve ardından hiçbir zaman veri göndermiyor. HTTP 408 bir "zaman aşımı" hatasıdır. Burada güzel bir yazı var: http://www.checkupdown.com/status/E408.html

Burada zaten birkaç iyi cevap var, ancak özel olarak ele alınmamış bir ek notu tehlikeye atmak istiyorum. Daha önce bahsedilen yorum yapanların çoğunun belirttiği gibi, 408 zaman aşımına uğradığını; ve zaman aşımının bir web sunucusunda gerçekleştiği bir dizi koşul vardır.

Bununla birlikte, sunucunuzun istismara karşı tarandığı çeşitli durumlarda 408 hata üretilebilir. Bu gibi durumlarda istemciler nadiren bir kullanıcı aracısı sunarlar ve çoğu zaman aniden bağlantılarını sonlandırırlar ve bu bağlantı için 408 hatası oluşturabilecek çok kısa bir kapanma ortaya çıkar.

Örneğin, interneti, POODLE güvenlik açığına karşı hala savunmasız olan bilgisayarlar için tarayan, korkunç bir hacker olduğumu varsayalım. Bu nedenle, SSL sürüm 3'ü kabul edecek sunucuları bulmak için büyük IP adresleri bağlantılarını açan bir komut dosyası yazdım - daha sonra bu listeyi özellikle POODLE istismarını taramak için kullanacağım. Tüm bu ilk betiğin yaptığı, SSLv3'ü kontrol etmek için openssl kullanarak bir bağlantı kurmak, şöyle:

openssl s_client -connect [IP]:443 -ssl3

Bu komut, Apache'nin birçok konfigürasyonunda, tam olarak tanımladığınız gibi bir 408 mesajı ile sonuçlanacaktır. Bu komutu kendi sunucularımdan ikisinde gerçekleştirmek, bu girişe erişim günlüğüne neden oldu:

<remote IP address>  - - [04/Nov/2015:08:09:33 -0500] "-" 408 - "-" "-"

Bunu, OP'nin herhangi bir yük dengeleme biçimi kullanmadığı, hatta bazı durumlarda 408 hata meydana gelebileceği durumlarda bile açık yapmak istedim - bazıları kötü niyetli, bazıları müşteriyle sorun belirten ve bazıları sunucuyla sorun olduğunu gösterir. (OP tarafından sağlanan kayıt defterinde yerel bir IP'nin uzak IP olarak belirtildiğini fark ettim, ancak OP özellikle yük dengeleyici kullanımından bahsetmedi, bu yüzden OP'nin sadece amaçlara yönelik olarak yönlendirilemeyen bir IP kullanıp kullanmadığından emin değildim. URL ile yaptığı gibi gösteri

Her neyse, görevim açıkça OP'ye yardım etmek için günün geç saatlerinde çok geç olsa bile, umarım bu lanet olası zaman aşımı hatalarının tümüne çözüm bulmak için buraya gelenlere yardımcı olabilir.

408 Zaman Aşımının çeşitli nedenleri vardır. Ancak, her şeyin yolunda olduğu bir öncülden başlayalım, sonra bir noktada bu 408'ler erişim günlüğünüzde görünmeye başlar - yani 408 0 "-" "-".

İnternetteki birçok nokta gibi, 408 bağlantı yapıldığını gösterir ancak uygun zaman ölçeğinde istek gönderilmez, bu nedenle sunucu 408 ile bağlantıyı keser. Kibirli bir kişi aslında bu konuda yardım isteyen birine yanıt verdi. - "Zaman aşımının hangi kısmını anlamadın?".

Bunun çok acemi bir cevap olduğunu ve bazı güvenlik yöntemlerinin web sunucusu yazılımıyla nasıl işlediğini anlama konusunda tam bir eksikliği olduğunu düşünüyorum.

O zaman başa dönelim, neden bu 408'lerin hepsini görüyorum. Bir sunucuyu yönetirken geri kalanımızla ortak olacağınız bir şey, günlük olarak alacağınız büyük miktarda saldırıdır. Şimdi, bunlar hakkında ne yapıyorsunuz? Peki, seçtiğiniz güvenlik yöntemlerini onlarla başa çıkmak için kullanıyorsunuz, işte bu değişiyor.

Çok kolay bir örnek alalım, bir IP adresi bırakın. Bir iptabes dosyasına (rules.v4) dahil olan "-A ufw-user-input -s 37.58.64.228 -j DROP" 'a sahipsiniz. Böylece 37.58.64.228 geliyor, güvenlik duvarı IP'yi tanır ve bağlantıyı keser. Birçok konfigürasyonda, kapıya çarptığını bile bilemezsiniz.

Şimdi daha gelişmiş bir örnek alalım, Bağlantıyı bazı ölçütlere göre bırakın. Bir iptabes dosyasına dahil (rules.v4) "-A INPUT -p tcp -m tcp --dp 80 -m string --string" cgi "--algo bm - to 1000 -j DROP" a sahip. Bu farklı çünkü bu iptable kuralında istek dizesinin ilk 1000 baytına bakıp "cgi" nin bir alt dizesini bulabilecek misiniz ve bu alt dizeyi bulursanız herhangi bir şey yapıp yapamayacağınıza bakın. dahası, sadece bağlantıyı bırakın.

Burada güvenlik yöntemi iyidir, ancak kayıtların yanıltıcı olacağı sürece. Üretilen 408 0 "-" "-" bu koşullar altında yapılabilecek en iyi apachedir. Bağlantı yapıldı ve 408 ile sonuçlanan dize karşılaştırma kuralını uygulamak için talebin bir noktaya kadar kabul edilmesi gerekiyordu çünkü kuralınız bağlantının kopması için gerekli kriterleri karşıladı. Demek küçük acemi sevgililerimiz deneselerdi daha yanlış olamazdı. Bir bağlantı yapıldı ve bir istek alındı ​​(bu şartlar altında sadece bunun netliğini göremezsiniz). Bir 408 oluşturulmuş olmasına rağmen, bir 'Zaman Aşımı' değildir; Sunucunuz bağlantıyı, güvenlik duvarı kuralınızla ilişkili olarak yapıldıktan sonra kolayca kesmiştir. Aynı 408 durumu yaratacak başka kurallar da var. Don'

İdeal olarak, başka bir Apache tarafından üretilen Hata Kodu olacaktır; örneğin - 'Sunucu İsteğinizi Okuyup Karar Verirken Size Sizi Eğlendirmekten Rahatsız Edilmedi' - Haha'yı Sod Off.

En son web sunucusu yazılımıyla DOS saldırılarını pratik olarak hariç tutabilirsiniz ve tahmin yeteneklerini içeren yeni tarayıcı jeneratörü, bazılarının önerdiği gibi bu soruna neden olmaz.

Kısacası, 408, sunucu talebe cevap vermediği için üretilir, çünkü müşteri ilgili bağlantı zaman aşımına uğradıysa, gerçekte sunucu isteği okuduğunda ancak bağlantıyı bekleyen bir zamanaşımı dışındaki nedenlerle bıraktığında bir istek.

Bu problemi yaşadık ve bir süredir şaşırdık. Karşılaştığımız en iyi çözüm AWS desteğinin ELB ekibi tarafından önerildi. Temelde httpd sunucunuzun zaman aşımı ayarlarının ELB idle timeoutayarınızdan daha büyük olmasını sağlar (varsayılan olarak 60 saniyedir).

• Apache Timeoutyönergesi değerinin, idle timeoutELB ayarınızın iki katı olduğundan emin olun .
• Özelliği açın , çok büyük KeepAliveolduğundan emin olun MaxKeepAliveRequests(sonsuz için 0 veya yüksek, 2000 gibi) ve bunun KeepAliveTimeoutELB'nizden daha büyük olduğundan emin olun idle timeout.

Biz bulduk KeepAlive(ve ilişkili ayarlar) özellikle (biz birkaç bakın, ama çok az) etkili bir şekilde 0'a 408s miktarını azaltılır ayarı.

Bu sorunu AWS Elastik Yük Dengeleyicisinin arkasında yaşadım. Sağlık kontrolleri kayıt defterinde çok fazla 408 yanıt üretti.

Benim için çalıştı tek çözüm sahip olmaktı yük dengeleyicinin Boşta Zaman Aşımı ayarı düşük olan daha sağlık kontrolü en Yanıt Zaman Aşımı .

Bir meslektaşım yakın zamanda, son yazımın bir 408'in güvenlik önlemi ile ilişkisine nasıl sahip olabileceği konusunda geçerli bir açıklama yaparken, çözüm önermediğini belirtti.

Piped Access log benim kişisel çözümüm.

Aşağıdakiler, çoğu Ubuntu konfigürasyonunda ve diğer Apache konfigürasyonlarında minimum kontrol ile kullanıma hazır olmalıdır. PHP'yi seçtim çünkü anlaşılması en kolay olanı. İki komut dosyası vardır: ilki, 408’in erişim günlüğünüze yazılmasını önler. İkinci komut dosyası, tüm 408'leri ayrı bir günlük dosyasına gönderir. Her iki durumda da sonuç erişim günlüğünüzde artık 408 değil. Hangi komut dosyasını uygulamak sizin seçiminizdir.

En sevdiğiniz metin editörünü kullanın, nano kullanıyorum. 'LogFormat' ve 'CustomLog' yönergelerinizin bulunduğu dosyayı açın. Orijinalleri her zamanki gibi # ile yorumlayın ve aşağıdakileri ekleyin. Bu direktifleri aşağıdaki dosyada bulabilirsiniz.

sudo nano / etc / apache2 / sites kullanılabilir / varsayılan

LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" AccessLogPipe

CustomLog "|/var/log/apache2/PipedAccessLog.php" AccessLogPipe env=!dontlog

NOT: Görüntüleri erişim günlüğüme kaydetmiyorum. Etc / apache2 / httpd.conf dosyamda satırı ekliyorum

SetEnvIfNoCase Request_URI ".(gif)|(jpg)|(png)|(css)|(js)|(ico)$" dontlog

Bu size hiçbir ilgi ise, kaldırmak env=!dontloggelen CustomLogdirektif.

Şimdi şu PHP komut dosyalarından birini (yaratmak #!/usr/bin/phpyeri sisteminiz için doğru olduğundan emin olun, tercüman konuma bir referanstır - istemi $ at yazarak bunu yapabilirsiniz; whereis php- Böyle bir şey dönmelidir php: /usr/bin/php /usr/bin/X11/php /usr/share/man/man1/php.1.gzsize şöyle. #!/usr/bin/phpbenim kurulum için doğru olduğunu görebilirsiniz ).

sudo nano /var/log/apache2/PipedAccessLog.php

#!/usr/bin/php
<?php
  $file = '/var/log/apache2/access.log';
  $no408 = '"-" 408 0 "-" "-"';
  $stdin = fopen ('php://stdin', 'r');
  ob_implicit_flush (true);
  while ($line = fgets ($stdin)) {
    if($line != "") {
      if(stristr($line,$no408,true) == "") {
        file_put_contents($file, $line, FILE_APPEND | LOCK_EX);
      }
    }
  }
?>

sudo nano /var/log/apache2/PipedAccessLog.php

#!/usr/bin/php
<?php
  $file = '/var/log/apache2/access.log';
  $file408 = '/var/log/apache2/408.log';
  $no408 = '"-" 408 0 "-" "-"';
  $stdin = fopen ('php://stdin', 'r');
  ob_implicit_flush (true);
  while ($line = fgets ($stdin)) {
    if($line != "") {
      if(stristr($line,$no408,true) != "") {
        file_put_contents($file408, $line, FILE_APPEND | LOCK_EX);
      }
      else {
        file_put_contents($file, $line, FILE_APPEND | LOCK_EX);
      }
    }
  }
?>

PipedAccessLog.phpSenaryoyu kaydettikten sonra ; $ isteminde aşağıdakini yürüterek kökün sahip olduğundan emin olun.

sudo chown -R root:adm /var/log/apache2/PipedAccessLog.php

PipedAccessLog.phpKomut okuma / yazma ve izinleri böylece istemi $ at aşağıdaki yürütmek gerek olacaktır.

sudo chmod 755 /var/log/apache2/PipedAccessLog.php

Sonunda her şeyin çalışabilmesi için Apache servisini yeniden başlatmanız gerekir. $ İsteminde aşağıdakini yürütün.

sudo service apache2 restart

Apache günlükleriniz başka bir yerde bulunuyorsa, yapılandırmanıza uygun yolları değiştirin. İyi şanslar.

Hem sayı hem de frekansta 408 hatanın arttığını gördüm. Kaynak oldukları IP adresleri de artmaktadır (bunlar kendi ayrı dosyalarına kaydedilir). Aynı IP gruplarından art arda 408'ler gösteren normal kayıt zaman aşımlarına bağlı olmayan ve aynı zamanda döngüsel bir düzen içinde 2 ya da 3 saniye arayla bağlantı kurmaya çalıştığından (diğerinin önünde zaman aşımı beklemeyin diye beklemeyen) belirgin kayıt kalıpları da vardır. bağlantı girişimi) Bunları basit DDOS tarzı bağlantı girişimleri olarak görüyorum. Benim görüşüme göre bunlar bir sunucunun çevrimiçi olduğuna dair gönderenlere yönelik bir onay mesajıdır ... daha sonra farklı araçlarla geri gelirler .... Zaman aşımı aralığını arttırırsanız, çalıştırmaları için daha büyük bir time_allocation vermiş olursunuz. onların içinde kesmek programları.