Kaspersky Antivirus & Internet Security 2009

[nikikom]

Здравей nikssi. Stealth Test не засяга ICMP протокола, а може би само ако позволиш изходящ трафик за Destination unreachable.

 

http://store.picbg.net/pubpic/04/5E/3913524bd4a4045e.JPG

 

Същия резултат го постигам с Windows-та защитна стена.

Ето и снимка от самото сканиране

 

http://store.picbg.net/pubpic/B3/07/2919953cb03eb307.JPG

 

Между другото били ми обяснил тези правила, че не мога да ги разбера

 

http://store.picbg.net/pubpic/3D/A6/439b78ba3f713da6.JPG

 

Един съвет, никога не блокирай изцяло входящите или пък изходящите ICMP пакети.

 

С малко пипане и става

[nikikom]

Ето различните ICMP пакети. Съдържанието зависи от Типът и Кодът.

ICMP участва в Path Mtu Discovery и за това не е хубаво да се забранява изцяло.

 

http://store.picbg.net/pubpic/A0/6D/0d4694b29f18a06d.JPG

http://store.picbg.net/pubpic/EF/A8/c52b2bd6e075efa8.JPG

[mihnev_sz]

Ето различните ICMP пакети. Съдържанието зависи от Типът и Кодът.

ICMP участва в Path Mtu Discovery и за това не е хубаво да се забранява изцяло.

Да, при повечето защитни стени са забранени ICMP пакетите по-подразбиране.Outpust/PC Tools и др.

Ето моите правила за пакетите,с които съм нямал проблеми до сега,аналогично и за 2009 :

http://share.pacomlan.com/images/Fye91337.jpg

[nikikom]

Не е задължително да имаш проблеми, но интернет връзката може да се оптимизира, но за целта не трябва да се спира целия входащ трафи на ICMP, също трябва да се направят някой промени. Тук ще поставя един цитат който съм си запазил в документ, а и не ми се търси сега статията в интернет

 

По подразбиране Satellite TCP не е активирано в повечето версии на Windows (само в XP SP2, Windows Server 2003 и Vista). Това е поправка на Receive Window Size в TCP протокола. Нормално тази опция може да има стойности от 0 до 65535. Обаче ако имаме трасета, в които няма загуби, но имат много високи закъснения, и скорост ще постигнем ефекта, че максималната теоретична достижима скорост на една сесия ще бъде 64KB*1000/RTT за секунда, или при RTT от 2000мс максималната скорост ще бъде 32KB/сек, ограничена от самият TCP протокол. Големите закъснения ошашкват и механизма за потвърждение на получените данни. Например ако една секунда нямаме потвърждение, това на какво се дължи – на закъснение или на загубени данни? Ако препращаме данните отново и отново всяка секунда, ако не са потвърдени, при 4 сек RTT ние ще сме ги изпратили 4 пъти, без да е имало нужда, или ще сме заели 4 пъти повече капацитет от необходимото. За това се появява едно RFC1323, в което се добавят няколко нови екстри. Първо Timestamp опция, с която се замерват закъсненията – всяка страна отбелязва timestamp времето в което изпраща пакет, и връща това, което отсрещната страна и е пратила. Така всяка страна може да разбере какво е било времето за стигане на този пакет до другата страна, и какво е RTT времето отделно, за отиване и връщане. Отделно чрез хитър механизъм се увеличава максималният прозорец за потвърждение, защото квантуването вече не е в байтове, а в MSS сегменти (които можем на кратко да оприличим на максимален размер на данните на пакет). Така теоретично можем да постигнем скорост от над 4GB за RTT, без да имаме рискове от безсмислено повторение на данните поради големи закъснения. Новите опции се договарят по време на установяването на сесията – едната страна предлага, другата потвърждава. На пръв поглед всичко е чудесно. Но не и за Windows. Тези опции не са активирани по подразбиране да се договарят с отсрещната страна. Така комуникация Windows-Windows ще бъде по старият метод (понеже нито една страна няма да предложи тези опции), или ще си работи бавно. За да се активира това трябва да се пипне отново registry key:

 

В HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters се създава DWORD Key с име „Tcp1323Opts” и стойност 3 (0 е изключено, 1 е MSS и Window Scaling, 2 е TimeStampOnly и 3 e MSS и TimeStamp).

PMTU е Path Mtu Discovery. MTU е максималният по размер пакет преминаващ през дадена медия. Например по подразбиране за Ethernet тази стойност се движи в промеждутъка между 1514 и 10000 байта. Но IP пакета може да бъде до 65535 байта дълъг. За да бъде пренесен през медия, която поддържа по-малки пакети той се фрагментира на фрагментчета, които натоварват процесора на маршрутизаторите и особено в миналото фрагментацията е забавяла значително скоростта на комуникация. И тук идеята е проста – ако изпращащата данни машина ги форматира в пакети не по-големи от най-малкото MTU по пътя на трафика, никога няма да се налага фрагментация и комуникацията ще върви спрямо RFC1323 (MSS, виж предната опция) максимално бързо и с големи сегменти. Обаче как да разберем кое е най-малкото MTU? И тук идва PMTU-то. Използва малък трик – слага бит в IP пакета, който забранява фрагментацията. Така маршрутизатор, който види медия с по-малко MTU от размера на пакета няма да го фрагментира. Вместо това той ще го дропне и ще върне ICMP MTU Error в чието съдържание ще запише размера на MTU-то. Изпращащата машина ще го вземе в предвид и няма да изпраща повече към този peer пакети с по-голяма от посочената дължина. Този трик оптимизира ефективно работата най-вече на RFC1323, но е приложим и в други ситуации. За съжаление е изключен по подразбиране от масовият Windows, и се налага да си го включвам на ръка:

 

В HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters се създава DWORD Key с име „EnablePMTUDiscovery” и стойност 1.

 

PMTU Black Hole Detection е необходимо в следните ситуации – понякога стари маршрутизатори не връщат MTU-то на медията, заради която дропват по-големият пакет. Но по-лошото е ако ICMP-то е изфилтрирано. В не малко Интернет доставчици работят хора с „ъкъл море – глава шамандура”, които не знаят как работят протоколите в Интернет и излизат с идеи, които са крайни и смешни. Когато по Windows се разпространяваха червеи проверяващи на къде да отидат с ICMP echo request, те филтрираха всички ICMP-та. Без да разбират че ICMP е контролен протокол, той се използва и в нормалната комуникация (например ICMP source quench е NACK алгоритъма на TCP-то) и не съществува без причинно и никога не трябва да се изфилтрирва. Винаги има друг начин от бруталното отрязване на цялото ICMP. Така или иначе ефекта бе че ICMP не минава и следователно PMTU-то не минава. Представете си как реагира TCP-то в този случай – изпраща пакет от 1500-байта, той се дропва някъде защото е много голям, но машината не разбира това понеже няма ICMP. Тя си мисли че е дропнат поради претоварване например. И го изпраща пак – 1500 байта. И се получава същото. Така няколко пъти, докато на края сесията се прекъсне или Window Size не падне под размера на MTU-то по пътя. Ефекта за потребителя – сесията се отваря, тръгва бързо и изведнъж зависва, и започва да влачи много бавно, от време на време някакви данни. Случвало ли ви се е? На мен непрестанно. Имаше един момент, когато бе направо епидемия в България. Това не е от Интернета, нито от протоколите, а от умни администратори не разбиращи как работят комуникациите в Интернет. Този ефект се нарича MTU black hole. И има различни алгоритми за откриването му (например ако получим ICMP отговор без MTU вътре слагаме MSS-а на най-малкото възможно разрешено MTU – 576, ако пък не получаваме ICMP за отговор на определени времена правим проби – с различни размери, често директно падаме до 576). Black Hole Detection по принцип не би трябвало да е необходим ако най-големия враг на комуникацията не са хората, които конфигурират мрежите. Но за съжаление е необходим. В Windows той е изключен по подразбиране. Освен в Windows 2003 SP2, Windows XP SP3 (oще не излязъл) и Windows Vista SP1. Ето как се активира изрично:

 

В HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters се създава DWORD Key с име „EnablePMTUBHDetect” и стойност 1.

[mihnev_sz]

Не е задължително да имаш проблеми, но интернет връзката може да се оптимизира, но за целта не трябва да се спира целия входащ трафи на ICMP, също трябва да се направят някой промени.

От шота, който дадох има разрешен входящ ICMP трафик.

Благодаря за инфото,определено е от полза.

[tanganika]

Странна работа,това нормално ли е ?

 

Logfile of HijackThis v1.99.1

 

O23 - Service: Kaspersky Anti-Virus 6.0 (AVP) - Unknown owner - C:\Program Files\Kaspersky Lab\Kaspersky Anti-Virus 6.0 for Windows Workstations\avp.exe" -r (file missing)

[damto]

Странна работа,това нормално ли е ?

 

Logfile of HijackThis v1.99.1

 

O23 - Service: Kaspersky Anti-Virus 6.0 (AVP) - Unknown owner - C:\Program Files\Kaspersky Lab\Kaspersky Anti-Virus 6.0 for Windows Workstations\avp.exe" -r (file missing)

 

http://img145.imageshack.us/img145/386/cliph.jpg

[tanganika]

http://img145.imageshack.us/img145/386/cliph.jpg

Да разбирам че е напълно нормално ли ?

[Night_Raven]

Да, напълно нормално е.

[tanganika]

Mihnev, коя версия ползваш KIS 7.0.1.325 или KIS 7.0.1.321 ?

[mihnev_sz]

Mihnev, коя версия ползваш KIS 7.0.1.325 или KIS 7.0.1.321 ?

На единия съм с KIS 7.0.1.325 на другия с KIS 2010 463 CF1 на третия с Avast!Home ,какво имаш на в предвид?

[tanganika]

На единия съм с KIS 7.0.1.325 на другия с KIS 2010 463 CF1 на третия с Avast!Home ,какво имаш на в предвид?

Реших да пробвам версия 7 но не бях сигурен дали след 7.0.1.325 няма и друга.

[mihnev_sz]

Реших да пробвам версия 7 но не бях сигурен дали след 7.0.1.325 няма и друга.

Не това е последната, стабилна от 7-ците. Няма HIPS ,но евристиката все още е на ниво.Има леко забавяне при първоначално стартиране за разлика от 2009/2010

http://downloads2.kaspersky-labs.com/produ...omeuser/kis7.0/

[tanganika]

Не това е последната, стабилна от 7-ците. Няма HIPS ,но евристиката все още е на ниво.Има леко забавяне при първоначално стартиране за разлика от 2009/2010

http://downloads2.kaspersky-labs.com/produ...omeuser/kis7.0/

Да така е държи се прилично,забавяне на интернет също не установявам.Да видим до къде ще я докарам без HIPS

 

Ако някой реши да посещава адреса от снимката може да си навлече неприятности !!!

 

http://i32.tinypic.com/qyh3co.jpg

[damto]

Танганайка чудя се ТИ сега ли намери да пробваш версия от преди две години? Ако те интересума Kaspersky Internet Security 7.0.0.125 е най стабилната от всички седмици