Jump to content
Sign in to follow this  
yurasek

Некорректное определение завершения TCP сессии

Recommended Posts

Здравствуйте.

В бета версии KES 11, как и в KES 10 SP2 с последним приватным патчем, присутствует одна серьёзная проблема, которой не было в KES 10  SP1 MR4 и KES 10 SP2: суть проблемы заключается в том, что если в KES настроен сетевой экран, в котором создано правило для протокола TCP, конкретного порта и входящего направления, то при завершении соединения бета KES 11 блокирует этот процесс. Было протестировано три разных версии KES на Windows Server 2012 R2, в каждой версии одинаковым образом был настроен сетевой экран: отключены все правила по умолчанию, создано первое правило, которое разрешает входящие соединения по TCP на порт 10101, затем второе правило, которое блокирует входящие и исходящие соединения по TCP на порт 10101 (для наглядного логгирования некорректного поведения), и последнее правило, которое блокирует все. В результате тестирования устанавливалось соединение с машины, на которой не был установлен какой-либо сетевой экран, отправлялся 1 байт данных и завершалось соединение:

1. KES 10 SP1 MR4

Настройки KES 10 SP1 MR4: KES10_SP1_MR4.cfg

Трассировки KES 10 SP1 MR4: KES10_SP1_MR4_traces.rar

Лог Wireshark для KES 10 SP1 MR4: KES10_SP1_MR4.pcapng

KES10_SP1_MR4_wireshark.thumb.png.452d31b0067c99d47c534bb10bedff7f.png

2. KES 10 SP2

Настройки KES 10 SP2: KES10_SP2.cfg

Трассировки KES 10 SP2: KES10_SP2_traces.rar

Лог Wireshark для KES 10 SP2: KES10_SP2.pcapng

KES10_SP2_wireshark.thumb.png.5b053df884d49969291fc0e8641a44a5.png

3. KES 11 бета

Настройки KES 11 бета: KES11_beta.cfg

Трассировки KES 11 бета: KES11_beta_traces.rar

Лог Wireshark для KES 11 бета: KES11_beta.pcapng

KES11_beta_wireshark.thumb.png.b1503521fc97e88621cf3150098206db.png

P.S. Надеюсь, техподдержка и разработчики со всей серьёзностью отнесутся к проблеме, потому что баги и особенности сетевого экрана порядком достали.

Edited by yurasek

Share this post


Link to post
5 hours ago, yurasek said:

Здравствуйте.

В бета версии KES 11, как и в KES 10 SP2 с последним приватным патчем, присутствует одна серьёзная проблема, которой не было в KES 10  SP1 MR4 и KES 10 SP2: суть проблемы заключается в том, что если в KES настроен сетевой экран, в котором создано правило для протокола TCP, конкретного порта и входящего направления, то при завершении соединения бета KES 11 блокирует этот процесс. Было протестировано три разных версии KES на Windows Server 2012 R2, в каждой версии одинаковым образом был настроен сетевой экран: отключены все правила по умолчанию, создано первое правило, которое разрешает входящие соединения по TCP на порт 10101, затем второе правило, которое блокирует входящие и исходящие соединения по TCP на порт 10101 (для наглядного логгирования некорректного поведения), и последнее правило, которое блокирует все. В результате тестирования устанавливалось соединение с машины, на которой не был установлен какой-либо сетевой экран, отправлялся 1 байт данных и завершалось соединение:

1. KES 10 SP1 MR4

Настройки KES 10 SP1 MR4: KES10_SP1_MR4.cfg

Трассировки KES 10 SP1 MR4: KES10_SP1_MR4_traces.rar

Лог Wireshark для KES 10 SP1 MR4: KES10_SP1_MR4.pcapng

KES10_SP1_MR4_wireshark.thumb.png.452d31b0067c99d47c534bb10bedff7f.png

2. KES 10 SP2

Настройки KES 10 SP2: KES10_SP2.cfg

Трассировки KES 10 SP2: KES10_SP2_traces.rar

Лог Wireshark для KES 10 SP2: KES10_SP2.pcapng

KES10_SP2_wireshark.thumb.png.5b053df884d49969291fc0e8641a44a5.png

3. KES 11 бета

Настройки KES 11 бета: KES11_beta.cfg

Трассировки KES 11 бета: KES11_beta_traces.rar

Лог Wireshark для KES 11 бета: KES11_beta.pcapng

KES11_beta_wireshark.thumb.png.b1503521fc97e88621cf3150098206db.png

P.S. Надеюсь, техподдержка и разработчики со всей серьёзностью отнесутся к проблеме, потому что баги и особенности сетевого экрана порядком достали.

Добрый день.

К сожалению, не до конца ясен сценарий. Какая сетевая активность происходит после завершения соединения? Каково ожидаемое поведение компонента? После завершения соединения удаленный хост не может повторно его установить, т.к. Сетевой экран переходит к обработке следующего правила? Что при этом пишется в отчеты Сетевого экрана?

Спасибо.

Share this post


Link to post

Здравствуйте, Кирилл.

Прежде всего начну с того, что я хочу донести: в KES 11 изменилась логика (поведение) при одном и том же сценарии по сравнению с актуальными версиями (KES 10 SP2 и KES 11 SP1 MR4). Тогда возникает вопрос: изменение логики - это ошибка или так задумано, потому что раньше было не правильно. Я склоняюсь к тому, что это ошибка.

Цитата

К сожалению, не до конца ясен сценарий.

Сценарий прост, попробую его ещё раз описать: KES 11 установлен на машине, на которой открыт TCP порт 10101 для входящих соединений, с другой машины происходит подключение и передача 1 байта. В KES 11 жёстко настроен сетевой экран, который разрешает только входящие соединения на TCP порт 10101.

Цитата

Какая сетевая активность происходит после завершения соединения?

После того, как KES 11 считает, что соединение завершено, клиент продолжает дублировать пакеты серверу о завершении сессии (на машину с KES 11), в это время KES 11 разрешает эти дублирующиеся пакеты, но блокирует исходящие пакеты сервера, которые подтверждают завершение сессии.

Цитата

После завершения соединения удаленный хост не может повторно его установить, т.к. Сетевой экран переходит к обработке следующего правила?

Ваш вопрос, возможно, не совсем корректен. После завершения соединения удаленный хост может повторно установить соединение, с этим проблем нет.

Т.к. KES 11 некорректно отрабатывает завершение TCP сессии, то, конечно же, Сетевой экран переходит к обработке следующего правила, которым блокирует пока ещё легитимные пакеты.

Цитата

Что при этом пишется в отчеты Сетевого экрана?

В первом сообщении я не привёл отчёты Сетевого экрана, поэтому вот они:

1. Отчёт KES 10 SP1 MR4:

KES10_SP1_MR4_report.png.9110660ddacef285ab69c22746ab16f9.png

2. Отчёт KES 10 SP2:

KES10_SP2_report.png.8e3d590fa1c97e137104406a8a14451d.png

3. Отчёт KES 11 бета:

KES11_beta_report.png.6ac166dae12915431ee10e1b7b25833c.png

Как видно, при одном и том же сценарии KES 11 блокирует часть пакетов при завершении соединения со стороны клиента.

Для пущей наглядности приведу скриншоты Wireshark в сценарии с KES 11 и без него (слева машина с KES 11 - сервер, справа машина без KES - клиент):

KES11_beta_wireshark_server_client.thumb.png.c937277cfb1cee91920d1e5dce1bed47.png

Without_KES11_wireshark_server_client.thumb.png.90ff6b2fc61f99c1aeadb2ff5fc09328.png

Прошу обратить внимание на мои комментарии на последней картинке.

P.S. В первом сообщении я допустил ошибку: все версии KES устанавливались на Windows 7 x64 SP1.

Edited by yurasek

Share this post


Link to post

Здравствуйте!

Для большей ясности укажите пожалуйста более полно ожидаемый результат, и текущий результат.

Спасибо!

Share this post


Link to post

Здравствуйте, Константин.

Я не являюсь специалистом по протоколу TCP, поэтому поясню это так, как понимаю.

Ожидаемый результат: клиент, инициируя завершение TCP соединения, посылает пакет с флагами FIN и ACK, а сервер с установленным KES 11 получает этот пакет, после чего KES 11 не должен считать сессию завершённой и должен (хотя бы в течение какого-то ограниченного временного интервала) разрешить отправку сервером в ответ клиенту подтверждающего пакета с флагом ACK, а также своего пакета клиенту на завершение соединения с флагами FIN и ACK, после чего клиент получает эти пакеты и отправляет серверу последний в сеансе подтверждающий пакет с флагом ACK, теперь сессия может считаться завершённой.

Текущий результатклиент, инициируя завершение TCP соединения, посылает пакет с флагами FIN и ACK, а сервер с установленным KES 11 получает этот пакет, после чего KES 11 считает сессию завершённой и блокирует отправку сервером в ответ клиенту подтверждающего пакета с флагом ACK, а также своего пакета на завершение соединения с флагами FIN и ACK, а так как клиент не получает подтверждающий пакет с флагом ACK от сервера, то клиент повторяет пакет с флагами FIN и ACK 5 раз, эти пакеты не блокируются KES 11 на сервере, но блокируется исходящий пакет с флагами FIN и ACK и пакет с флагом ACK, которые сервер пытается повторно отправить несколько раз, что видно в отчёте, в котором можно насчитать не менее 9-ти заблокированных пакетов.

Share this post


Link to post
6 hours ago, yurasek said:

Здравствуйте, Константин.

Я не являюсь специалистом по протоколу TCP, поэтому поясню это так, как понимаю.

Ожидаемый результат: клиент, инициируя завершение TCP соединения, посылает пакет с флагами FIN и ACK, а сервер с установленным KES 11 получает этот пакет, после чего KES 11 не должен считать сессию завершённой и должен (хотя бы в течение какого-то ограниченного временного интервала) разрешить отправку сервером в ответ клиенту подтверждающего пакета с флагом ACK, а также своего пакета клиенту на завершение соединения с флагами FIN и ACK, после чего клиент получает эти пакеты и отправляет серверу последний в сеансе подтверждающий пакет с флагом ACK, теперь сессия может считаться завершённой.

Текущий результатклиент, инициируя завершение TCP соединения, посылает пакет с флагами FIN и ACK, а сервер с установленным KES 11 получает этот пакет, после чего KES 11 считает сессию завершённой и блокирует отправку сервером в ответ клиенту подтверждающего пакета с флагом ACK, а также своего пакета на завершение соединения с флагами FIN и ACK, а так как клиент не получает подтверждающий пакет с флагом ACK от сервера, то клиент повторяет пакет с флагами FIN и ACK 5 раз, эти пакеты не блокируются KES 11 на сервере, но блокируется исходящий пакет с флагами FIN и ACK и пакет с флагом ACK, которые сервер пытается повторно отправить несколько раз, что видно в отчёте, в котором можно насчитать не менее 9-ти заблокированных пакетов.

Здравствуйте,

может описать реальную проблему, которая возникает из-за этой особенности работы продукта ?

Какая реальная трудность возникает в вашей инфраструктуре по этой причине ?

Каков практический смысл ?

Спасибо.

 

Share this post


Link to post

Здравствуйте, Дмитрий.

Цитата

может описать реальную проблему, которая возникает из-за этой особенности работы продукта ?

1. В случае логгирования запрещённых соединений в лог попадает информация о как-будто блокировании легитимных соединений, что кардинально усложняет процесс тонкой настройки сетевого экрана и отладки нештатных ситуаций.

2. Сетевое оборудование шлёт и получает лишние (не те) пакеты.

3. Драйвер TCP на клиентской и серверной стороне расходует ресурсы на соединение, которые можно было освободить ещё 19 секунд назад.

Цитата

Какая реальная трудность возникает в вашей инфраструктуре по этой причине ?

Этот вопрос пока не до конца изучен и ясен.

Цитата

Каков практический смысл ?

Практический смысл заключается в том, что Сетевой экран бета KES 11 на низком уровне работает некорректно, блокируя пакеты корректного завершения TCP сессии, такой проблемы не было в KES 10 SP1 MR 4 и KES 10 SP2. В одном из приватных патчей для KES 10 SP2 эта проблема появилась, когда пытались решить какую-то другую проблему, и эта проблема перекочевала в бету KES 11.

Какие ещё могут быть подводные камни с этой проблемой я пока не знаю, но если Вам никто больше не сообщил о проблеме, то это не значит, что её нет.

Я уверен, что разработчикам на исправление потребуется не больше 5-ти минут. Самое главное, чтобы кто-то эту проблему до них донёс.

Share this post


Link to post
8 minutes ago, yurasek said:

Здравствуйте, Дмитрий.

1. В случае логгирования запрещённых соединений в лог попадает информация о как-будто блокировании легитимных соединений, что кардинально усложняет процесс тонкой настройки сетевого экрана и отладки нештатных ситуаций.

2. Сетевое оборудование шлёт и получает лишние (не те) пакеты.

3. Драйвер TCP на клиентской и серверной стороне расходует ресурсы на соединение, которые можно было освободить ещё 19 секунд назад.

Этот вопрос пока не до конца изучен и ясен.

Практический смысл заключается в том, что Сетевой экран бета KES 11 на низком уровне работает некорректно, блокируя пакеты корректного завершения TCP сессии, такой проблемы не было в KES 10 SP1 MR 4 и KES 10 SP2. В одном из приватных патчей для KES 10 SP2 эта проблема появилась, когда пытались решить какую-то другую проблему, и эта проблема перекочевала в бету KES 11.

Какие ещё могут быть подводные камни с этой проблемой я пока не знаю, но если Вам никто больше не сообщил о проблеме, то это не значит, что её нет.

Я уверен, что разработчикам на исправление потребуется не больше 5-ти минут. Самое главное, чтобы кто-то эту проблему до них донёс.

Вы правы.

Можете указать в каком PF для SP 2 вы заметили это неправильное поведение ?

Разработчикам будет легче найти проблему, если сократить поиск до патча, который вошёл в 11 версию, а не искать во всем компоненте файерволла.

Спасибо.

 

Share this post


Link to post
6 hours ago, yurasek said:

Проблема началась с pf3070.

Спасибо за подробное описание проблемы!

Заведена ошибка 2449310 для исследования причин такого поведения и получения разъяснений от разработчиков.

Share this post


Link to post
On 10/30/2017 at 4:02 AM, Kirill Tsapovsky said:

Спасибо за подробное описание проблемы!

Заведена ошибка 2449310 для исследования причин такого поведения и получения разъяснений от разработчиков.

Разработчик сообщает, что некорректное определения завершения TCP-сессии исправлено в релизной версии KES 11.

Спасибо.

Share this post


Link to post

Кирилл, спасибо за информацию.

А будет ли выпущен приватный патч для KES 10 SP2?

Share this post


Link to post
On 11/2/2017 at 8:38 PM, yurasek said:

Кирилл, спасибо за информацию.

А будет ли выпущен приватный патч для KES 10 SP2?

В основной раздел форума напишите, пожалуйста.

Спасибо! 

Share this post


Link to post

В версии Kaspersky Endpoint Security 11.0.0.6485 проблема сохранилась.

Share this post


Link to post

Добрый день. 

Приложите, пожалуйста, диагностические данные собранные на тестовом компьютере. 

Опишите как происходила установка KES 11 11.0.0.6485 ?  Устанавливалась ли данная версия взамен старой или тестовый стенд был развернут с нуля ?

Share this post


Link to post
Sign in to follow this  

×
×
  • Create New...

Important Information

We use cookies to make your experience of our websites better. By using and further navigating this website you accept this. Detailed information about the use of cookies on this website is available by clicking on more information.