Ложное срабатывание ???
Ложное срабатывание ???
в логах иногда проскакивают странные записи типа:
2006-02-16 09:51:15 Virus-detect: aaa.bbb.ccc.ddd - http://www.cbonds.info/emissions/proc_f ... te%5D=true (urls rule: witold.pl)
2006-02-16 09:57:40 Virus-detect: aaa.bbb.ccc.ddd - http://www.google-analytics.com/__utm.g ... none%29%3B (urls rule: calamarco.com)
Чаще всего это бывает с доменом google-analytics.com
В чем причина?
2006-02-16 09:51:15 Virus-detect: aaa.bbb.ccc.ddd - http://www.cbonds.info/emissions/proc_f ... te%5D=true (urls rule: witold.pl)
2006-02-16 09:57:40 Virus-detect: aaa.bbb.ccc.ddd - http://www.google-analytics.com/__utm.g ... none%29%3B (urls rule: calamarco.com)
Чаще всего это бывает с доменом google-analytics.com
В чем причина?
Сталкивался, искал причину, не нашел, похоже где-то ошибка в режике. К счастью, встречается это редко.
Попробуйте подредактировать redirector.c вставив строчки обнуления переменных:
/***********************
****** Work cycle *****/
// Get input string
while (fgets(str,ML_URL,stdin)!=NULL)
{
// Init vars
*input_ident=0;
*input_ident_un=0;
*input_ip=0;
*input_url=0;
*input_url_un=0;
*input_method=0;
*input_host=0;
*change_reason=0;
// convert input string to input structure->(url,who,ident,method)
if(parse_input(str))
{
Попробуйте подредактировать redirector.c вставив строчки обнуления переменных:
/***********************
****** Work cycle *****/
// Get input string
while (fgets(str,ML_URL,stdin)!=NULL)
{
// Init vars
*input_ident=0;
*input_ident_un=0;
*input_ip=0;
*input_url=0;
*input_url_un=0;
*input_method=0;
*input_host=0;
*change_reason=0;
// convert input string to input structure->(url,who,ident,method)
if(parse_input(str))
{
Вот что еще выяснил (redirector.c пока я не правил.)
Эта ошибка возникает в следующей ситуации:
1. Редиректор работает под нагрузкой (например, когда активизируется троян и шлет запросы сразу на 50 адресов)
2. В логе у ложного срабатывания поле rule: перетекает из предыдущей блокировки.
3. Ложное срабатывание происходит при проверке "длинного" url
Эта ошибка возникает в следующей ситуации:
1. Редиректор работает под нагрузкой (например, когда активизируется троян и шлет запросы сразу на 50 адресов)
2. В логе у ложного срабатывания поле rule: перетекает из предыдущей блокировки.
3. Ложное срабатывание происходит при проверке "длинного" url
Я так же пытался отловить эту ошибку и к сожалению, пока не смог. Дело в том, что она не детерминирована.
Проще говоря, не получается зафиксировать условия возникновения ошибки, что бы её можно было отследить и исправить.
У себя я её видел один раз, двое людей писали, что так же наблюдали такую ошибку.
и все...
на сколько часто она у Вас проявляется?
Можно было бы сделать логирование всех запросов и определить, в каком случае она происходит.
1. Скачайте и откомпилите http://www.rejik.ru/download/logger.c
2. Подключите его до режика:
a. Сделайте файлик r.sh следующего содержания:
/usr/local/rejik/logger | /usr/local/rejik3/redirector
b. Пропишите r.sh в качестве редиректора в сквиде.
После этого, в /usr/local/rejik3/elog будет сыпаться все то, что получает режик от сквида.
Задача состоит в том, что бы найти такие строки в elog, от которых режик пишет в лог неправильные сообщения.
сделать это можно например так: cat elog | /usr/local/rejik3/redirector
если после такой команды в логе появляются неправильные данные, значит нашли.
Вышлите мне такой elog, что бы я смог повторить проблему у себя и исправить ошибку.
Проще говоря, не получается зафиксировать условия возникновения ошибки, что бы её можно было отследить и исправить.
У себя я её видел один раз, двое людей писали, что так же наблюдали такую ошибку.
и все...
на сколько часто она у Вас проявляется?
Можно было бы сделать логирование всех запросов и определить, в каком случае она происходит.
1. Скачайте и откомпилите http://www.rejik.ru/download/logger.c
2. Подключите его до режика:
a. Сделайте файлик r.sh следующего содержания:
/usr/local/rejik/logger | /usr/local/rejik3/redirector
b. Пропишите r.sh в качестве редиректора в сквиде.
После этого, в /usr/local/rejik3/elog будет сыпаться все то, что получает режик от сквида.
Задача состоит в том, что бы найти такие строки в elog, от которых режик пишет в лог неправильные сообщения.
сделать это можно например так: cat elog | /usr/local/rejik3/redirector
если после такой команды в логе появляются неправильные данные, значит нашли.
Вышлите мне такой elog, что бы я смог повторить проблему у себя и исправить ошибку.
Логирование при реальной работе вряд ли поможет. Ситуация очень плохо повторяема.
Ложные срабатывания бывают только на длинных урлах (более 600 символов), причем правило, на которое ложно сработал режик необязательно подставляется из предыдущего срабатывания (бывает и так, но бывает, что и нет). Если копирую урл ложного срабатывания из лога в браузер и пробую сделать запрос, то иногда тоже получаю ложное срабатывание (бывает очень редко, чаще всего все отрабатывает нормально).
У меня при количестве запросов за день 2-3 млн. кол-во ложных срабатываний (примерно) от нескольких едениц до нескольких десятков.
Как мне кажется, единственный способ найти баг, - смоделировать плотную бомбежку сквида набором из длинных правил, на которые режик ранее ложно сработал. Взять десяток правил, и посылать их десятью программами в цикле как можно более часто. И смотреть что получается.
Пока не приходит в голову как это можно сделать. Но может кто придумает.
Ложные срабатывания бывают только на длинных урлах (более 600 символов), причем правило, на которое ложно сработал режик необязательно подставляется из предыдущего срабатывания (бывает и так, но бывает, что и нет). Если копирую урл ложного срабатывания из лога в браузер и пробую сделать запрос, то иногда тоже получаю ложное срабатывание (бывает очень редко, чаще всего все отрабатывает нормально).
У меня при количестве запросов за день 2-3 млн. кол-во ложных срабатываний (примерно) от нескольких едениц до нескольких десятков.
Как мне кажется, единственный способ найти баг, - смоделировать плотную бомбежку сквида набором из длинных правил, на которые режик ранее ложно сработал. Взять десяток правил, и посылать их десятью программами в цикле как можно более часто. И смотреть что получается.
Пока не приходит в голову как это можно сделать. Но может кто придумает.
Это, к сожалению не определяет проблему. Возможно, что проблема проявляется при некотором наборе запросов (более одного), идущих подряд, которые в логе режика не увидишь.asket писал(а):что-то я не догоняю.
Что я уже делал, -
беру правило из redirector.log на которое режик ложно сработал и посылаю его на редиректор - и он на него не срабатывает.
А вот если подключить logger, то он сохранит в отдельный файл все запросы от сквида к режику. И этот лог файл, можно подать на стандартный вход режику (cat elog | ./redirector) и режик должен записать в свои логи ту самую крамольную строку, где сказано, что блокировал какой нить гугл, по правилу порно.ком. Чего быть не может.
Мало вероятно, в режике везде контроль вводимого по длине.Rus писал(а):Похоже что при обработке "длинных" URL происходит ошибка класса "переполнение буфера".
Стоит наверно проверить в исходниках защиту от "переполнения", да и вообще можно ограничится парой сотней символов а остальное отсекать.
Более вероятен вариант, при котором урл пропускается как слишком длинный или непонятный к разбору режику, после чего, следующий урл принимает часть данных в переменных как свои.. сложно гадать, надо бы пощупать...