Что происходит: исходящее сообщение НетФильтр недополучает, данные внезапно заканчиваются, завершающей точки нет.

Буду разбираться.

Давайте еще подробнее про tightvnc.

Нужен отладочный лог НетФильтра (Spider Mail), так не понять, слишком широк простор.

Попробуйте исключение *.exe «По указанным IP-адресам и портам» и задать 10.52.0.0/16:* -- какой будет эффект?

В целом, воспроизведение проклюнулось. Работаем над фиксом.

А если любопытный пользователь в курсе существования веб-версии Скайпа? Тогда вообще нет смысла?

Вот web.skype.com заблокировать как раз проще всего.

https://drive.google.com/file/d/1iRZ5GIBeYezR8uPOklNUHiVL9DZYQ71e/view?usp=sharing

Обновил новым дампом, только что сделанным.

Я вам в ЛС отправил ссылку на тестовый билд НетФильтра, если можете, проверьте пожалуйста, как дела с ним.

Нужен дамп процесса dwnetfilter.exe -- понять, на чем там крутим...

Так и есть: от прокси приходит все одним куском и если бы не заголовок Transfer-Encoding: chunked, все было бы нормально. Прокси оставляет этот заголовок и это баг Squid.

 

Интересно, что там вообще передается в таком виде. Можете сделать лог Wireshark без НетФильтра (т.е. без Gate/Mail)?

Последний (нуль-размерный) кусок и конец строки в юниксовом стиле.

Возвращаясь к "быть педантичным при отправке и терпимым на приёме" - исключения быть не должно: пустая строка это ноль, что, опять-таки, в стиле юниксов.

Стандарт четко прописывает, как этот последний кусок должен выглядеть:

last-chunk     = 1*("0") [ chunk-ext ] CRLF

Т.е. удалить компоненты Spider Mail и Spider Gate, скачать Wireshark и собрать с его помощью логи? Кстати WiresharkPortable подойдёт?

Ещё бы разобраться как ей пользоваться.

Портабл наверное подойдет. Там надо запустить сбор пакетов (выбрать сетевой интерфейс), а потом сохранить.

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

Да, там должен быть размер — см. https://tools.ietf.org/html/rfc7230#section-4.1

Интересно, что там вообще передается в таком виде. Можете сделать лог Wireshark без НетФильтра (т.е. без Gate/Mail)?

В приведенном фрагменте лога два разных потока: в первом идет установка соединения, а во втором поймали исключение. Они никак не связаны между собой.

Это понятно, что не связаны.
Непонятно - как понять, обращение к какому IP-адресу вызвало ошибку?

Отследить тред по логу.
 

Поясните, что вы имеете в виду? Сейчас на Windows 7+ используется WFP.

netstat -no|find ":21"
  TCP    192.168.1.2:53146      95.173.102.59:21       ESTABLISHED     2284
tasklist /fi "pid eq 2284"|find " 2284 "
dwnetfilter.exe               2284 Services                   0    98 464 КБ

А между тем, соединение инициировано браузером.

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

Лог предназначен в первую очередь для технического сбора информации, необходимой при обращении в службу поддержки.
 

Время от времени в логе netfilter появляется примерно такое (сложено):

[15/12/2017 19:15:32 00000a80] <DEBUG:1> Trying to connect to: x.x.x.x:80
[15/12/2017 19:15:32 00000e18] <DEBUG:1> Exception caught: net_exception (COverlappedSocket::Flush, 196). Error code 10053.
[15/12/2017 19:15:32 00000e18] <DEBUG:1> Disconnecting.

В приведенном фрагменте лога два разных потока: в первом идет установка соединения, а во втором поймали исключение. Они никак не связаны между собой.
 

С кочки зрения пользователя это выглядит как подвисание при загрузке страницы в браузере.
Претензий несколько:
1. Протоколировать ошибку на отладочном уровне - несколько странно. Адекватный вариант - info или notice/warning;

Сейчас у лога только два уровня: стандартный (без префикса + DEBUG:1) и подробный (добавляется DEBUG:2).
 

2. Неизвестно, обращение к какому адресу вызвало ошибку;
3. Если ошибка "глотается" (без передачи приложению) - netfilter должен повторять запрос.

"Ошибки" НетФильтр не "глотает", а передает дальше доступными средствами. Запрос может повторять только тот, кто его инициировал -- клиент -- согласно своей логике.
Более того, многие "ошибки" -- вариант нормального течения событий.
 

P.S. Есть планы выкинуть из netfilter поддержку "пре-Windows 7" и перейти к обработке трафика на уровне WFP? Без перехвата трафика на уровне приложения?

 
Поясните, что вы имеете в виду? Сейчас на Windows 7+ используется WFP.

Я тоже считаю что мы не должны ничего блокировать, если там нет угрозы. malformed http headers угрозы не представляют и должны отдаваться "наверх" как есть, пока не будет PoC с эксплуатацией.

Вот потому и прикручу к настройке "блокировать поврежденные объекты" -- оно как раз для вот таких случаев и по умолчанию выключено.

Мы не проверяем Location, мы ждем, когда все заголовки передадут, а нам вместо этого -- обрыв соединения. Мы работаем "прозрачно", поэтому статус Bad gateway нам не совсем подходит.

 

"Вы, батюшка, определитесь ...".
Если прозрачно, то передаются все строки заголовка, которые передал сервер и все байты тела сообщения: A client, server, or proxy MAY close the transport connection at any time

Определяюсь: термин «прозрачно» применительно к работе НетФильтра означает, что мы представляемся сервером клиенту и наоборот, а не каким-либо промежуточным звеном — прокси-сервером, шлюзом, и т.п. В частности, это подразумевает полную замену ответа в случае обнаружения в нем угрозы: код 503 и заголовки, соответствующие содержимому (странице блокировки).

Также, я еще раз подчеркиваю, что в данном случае имеет место неопределенное поведение из-за нарушения протокола. Возможно, это повод применять для рассматриваемого случая настройку «Блокировать поврежденные объекты».

 

Над решением думаю.

Согласитесь, что в данном конкретном случае блокировки не будет, но не отдать последнюю строку заголовка - неправильно в любом случае. Если мы педантично чтим rfc, то подходящий статус - 502 (Bad gateway) и у вас есть формальное оправдание: возвращён неполный ответ.

Сразу бросаться проверять Location - тоже не самое лучшее решение. С моей кочки зрения правильным будет сделать "быструю проверку, не требующую выхода в тыртырнет". Если результат "быстрой проверки" отрицательный (родительский/офисный контроль или "известные рассадники") - возвращаем "403 Ферботтен". Если положительный - возвращаем исходный ответ (возможно подкорректировав на формальную корректность) и начинаем остальные проверки тогда, когда UA сделает переход на Location.

Мы не проверяем Location, мы ждем, когда все заголовки передадут, а нам вместо этого -- обрыв соединения. Мы работаем "прозрачно", поэтому статус Bad gateway нам не совсем подходит.

Я уже писал про неопределенное поведение (undefined behaviour): здесь мы не[до]получили ответ сервера, а согласно настройкам мы должны его еще и проверить. Если в сообщении вредоносное программное обеспечение -- ответ 301 предполагает, что там может быть контент, -- то мы должны вообще заблокировать, а для этого и статус другой нужен.

Над решением думаю.

 

Здесь в ответе сервера (RECV/S) две строки: статус и первый заголовок. Пустой строки, отделяющей заголовки от контента (в данном случае пустого) нет -- сразу идет обрыв соединения.
 
Стандарт же описывает структуру сообщения следующим образом (ссылка):

Вы педантичны там, где должны быть толерантны. Если соединение закрыто - сообщение завершено: пункт пять раздела 4.4

 

Весь раздел 4.4 освещает нюансы относительно размера message-body, а здесь только заголовки передаются (разделитель еще не получен). Но насчет педантичности соглашусь :-)

 

Итак, ситуация выглядит следующим образом:

Здесь в ответе сервера (RECV/S) две строки: статус и первый заголовок. Пустой строки, отделяющей заголовки от контента (в данном случае пустого) нет -- сразу идет обрыв соединения.

А что из этого следует?

Из этого следует то, что мы недополучили сообщение и undefined behaviour.

Итак, ситуация выглядит следующим образом:

[09/08/2017 16:06:11 0000073c] <DEBUG:2> - SEND/S 16="GET / HTTP/1.0\0d\0a"
[09/08/2017 16:06:11 0000073c] <DEBUG:2> - SEND/S 30="User-Agent: Wget/1.12 (msys)\0d\0a"
[09/08/2017 16:06:11 0000073c] <DEBUG:2> - SEND/S 13="Accept: */*\0d\0a"
[09/08/2017 16:06:11 0000073c] <DEBUG:2> - SEND/S 19="Host: www.yota.ru\0d\0a"
[09/08/2017 16:06:11 0000073c] <DEBUG:2> - SEND/S 24="Connection: Keep-Alive\0d\0a"
[09/08/2017 16:06:11 0000073c] <DEBUG:2> - SEND/S 2="\0d\0a"
[09/08/2017 16:06:11 0000073c] <DEBUG:2> - RECV/S 32="HTTP/1.1 301 Moved Permanently\0d\0a"
[09/08/2017 16:06:11 0000073c] <DEBUG:2> - RECV/S 32="Location: https://www.yota.ru/\0d\0a"
[09/08/2017 16:06:11 0000073c] <DEBUG:2> Server disconnected, error=00000000
[09/08/2017 16:06:11 0000073c] <DEBUG:2> Server closed the connection
[09/08/2017 16:06:11 0000073c] <DEBUG:2> - SEND/C 32="HTTP/1.1 301 Moved Permanently\0d\0a"
[09/08/2017 16:06:11 0000073c] <DEBUG:2> Shutdown: Client, SD_BOTH

Здесь в ответе сервера (RECV/S) две строки: статус и первый заголовок. Пустой строки, отделяющей заголовки от контента (в данном случае пустого) нет -- сразу идет обрыв соединения.

Стандарт же описывает структуру сообщения следующим образом (ссылка):

     HTTP-message   = start-line
                      *( header-field CRLF )
                      CRLF
                      [ message-body ]

Поизучаем тему.

Нужен полный отчет "для техподдержки"

Отбой по отчету -- есть воспроизведение.

Хорошо, поглядим.

3. Смотрим на IP-адрес с которым устанавливается соединение и получаем 10.x.x.x.
Отсюда получаем, что 72.52.4.90 != 10.x.x.x, а это значит что соединение устанавливается не с вредоносным ресурсом, а значит блочить его не надо.

Нет гарантии, что по адресу 10.x.x.x не находится прокси-сервер, перенаправляющий запрос на 72.52.4.90.