QUOTE(Bl@cK C@pt@iN @ 8.12.2008 22:17)

21:20:52 81.176.69.85 Узел заблокирован на 60 мин. SCAN (6404, 45828, 49668)
20:53:04 81.176.69.85 Узел заблокирован на 60 мин. SCAN (5124, 15876, 9220)
21:19:18 Блокировать IN TCP 81.176.69.85 80 <МОЙ IP> 1203 FIN ACK Заблокировано Детектором атак
21:18:13 Блокировать IN TCP 81.176.69.85 80 <МОЙ IP> 1203 FIN ACK Заблокировано Детектором атак
21:17:08 Блокировать IN TCP 81.176.69.85 80 <МОЙ IP> 1203 FIN ACK Заблокировано Детектором атак
21:16:35 Блокировать IN TCP 81.176.69.85 80 <МОЙ IP> 1203 FIN ACK Заблокировано Детектором атак
Это из отчёта брандмауэра. Что бы это значило?..
P.S. 81.176.69.85 - это, если кто не знает, IP-адрес forum.kaspersky.com
"Просмотр"(или "чтение") форума - не есть понятие сугубо простое и тривиальное.
Во время сего процесса по протоколу HTTP устанавливается с десяток параллельных соединений с сервером("форумом"), каждое отвечающее за "скачивание" своего, определенного "куска"(jpg/png файлов-иконок-аватаров, html страниц и прочего swf), указанных клиенту в виде URL-ссылок в скаченном по-умолчанию index.htm(l) после обращения к "главной" странице.
Так вот особенность HTTP, как
потокового протокола, заключается в том, что чаще всего закрывает соединение именно сервер, а не клиент. И, сл-но, может возникнуть такая ситуация при которой от сервера в фиксированную единицу времени придет N-ное количество TCP-пакетов с возведенными флагами <FIN,ACK>, которые будут обсчитаны эвристикой детектора атак клиента, как FIN-сканирование сервером.
Для избежания подобной ситуации, необходимо "подкрутить" детектор атак самостоятельно(кол-во попыток в единицу времени), если имеется возможность ручной настройки, либо обратиться к производителю защитного ПО.
Вариации на тему также могут происходть из-за "затора" где-то на промежуточном узле связи, а потом резкого прихода отставших пакетов клиенту. Так что, каждая конкретная ситуация не однозначна и никто вас даже и не думает сканировать, побойтесь бога.