2b315845

Эхо боя, оптимизация логов


DL
16.8.2001

Дал знакомому посмотреть сайт, который дома тестирую. Он посмотрел, похвалил, а я решил посмотреть, что он видел. Открываю логи Апача, смотрю и через некоторое время обнаруживаю, что кроме товарища ещё кто-то лазил на мой домашний сервер.

Вот он, вирус CodeRed, о котором так долго твердили большевики.

"GET /default.ida?XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u780

1%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u90

90%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0

000%u00=a HTTP/1.0" 404 270

В те моменты, когда я подключался к сети по диалапу со включенным Апачем, ко мне, словно звуки далёкой канонады, приходили такие запросы. Учитывая то, что в IPv4 2^32 адресов, по которым вирус рассылается случайным образом, можно восхищаться масштабами его распространения.

Заодно перенастроил правила в Atguard, чтобы не разрешать соединяться с Апачем откуда-то ни было кроме 127.0.0.1.

Кстати, именно как по эху? вернее как по кругам на воде ? недавно замерили активность и направленность DoS-атак во всём интернете (русский комментарий к результатам ? ) []. При отправке запроса на соединение хулиган, чтобы не быть пойманным, меняет обратный адрес IP-пакета на случайный. Имея много ip-адресов, можно собирать приходящие ответы от атакуемых серверов и делать расчёты. Интересно, можно ли, слушая запросы из сети и имея алгоритм выбора случайного числа вируса CodeRed (насколько я понял из сетевых обзоров, две его версии можно отличить по строке запроса), подсчитывать количество заражённых? RomikChef прислал описание оптимизации работы с логами.

О! Какая статья интересная, а я и не читал :-( А может, и хорошо, что не читал, потому что всё по-другому сделал. Мне кажется, что у Димы не очень удачная организация базы.

У меня запись занимает ровно 20 байт. может быть, это тоже не самая удачная, но, сами понимаете, размер на порядок, а то и на два меньше.


id ? 4 байта

ip ? 4 байта



таймстамп ? 4 байта

дальше идут ссылки на словари, каждая по 2 байта

page ? $PHP_SELF

agent ? бровзер

реферер ? реферер

баннер ? баннер

Теперь по пунктам.

- ip, упакованный в 4 байта, это, конечно, короче, чем хост. Тем более, что толку от хоста в базе нет. И группировать по int, мне кажется, база будет быстрее, чем по строкам. Да, вывод информации происходит медленнее, поскольку надо ресолвить сразу кучу адресов. Но я могу и подождать ? при просмотре торопиться некуда. Имхо. А вот при записи на ресолвинг времени не тратится.

- таймстамп не родной, а юниксовский. И не потому, что родной занимает на 1 байт больше, а потому, что когда пришлось логи малость подправить, сами понимаете, стампы все сбились.

- page. Это понятно. Словарь всех страниц сайта. Таблица небольшая, всё летает.

- агент. То же самое.

- баннер ? тоже понятно. Какой баннер был показан.

- реферер. Самое шаткое место. Да, таблица растет. но, как вы понимаете, 90% рефереров ? со своего сайта. В принципе, одиночные реферера можно и почистить. Query_string у внутренних рефереров отсекается. У чужих ? отсекается тоже и пишется отдельно, для анализов.

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

И ещё. Вопрос. Кто как отличает роботов от людей? Я определяю по включенной графике. И в принципе, моя статистика не сильно разнится со спайлоговской.

Что там у меня было раньше?

CREATE TABLE logs ( date datetime DEFAULT '0000-00-00 00:00:00' NOT NULL, (можно TIMESTAMP)

ip varchar(16) NOT NULL, host varchar(255) NOT NULL, browser varchar(64) NOT NULL, referer varchar(255) NOT NULL, request_uri varchar(255) NOT NULL, );

Признаться, я делал эту систему, когда не знал существования функций [] и []. Потом переделывать руки не доходили. А преобразуется ip-адрес в целое число переведением всех четырёх чисел адреса в двоичный код (с дополнительными нулями: 255 переводится в 11111111, а 4 ? в 00000100), убираются точки, и получившееся число переводится обратно в десятичный. В IPv4 может быть 2^32 адресов, т.е. (2^8)^4 ? итого число занимает четыре байта.



Timestamp из Юникса пишется просто ? функция UNIX_TIMESTAMP. Выбирается так же просто ? для группировки по дням, неделям, дням недели или чему-то ещё используется стандартная функция MySQL FROM_UNIXTIME:

SELECT DATE_FORMAT(FROM_UNIXTIME(date),'%e.%m.%Y') AS date_group, COUNT(ip) AS visits FROM logs GROUP BY date_group ORDER BY DATE_FORMAT(FROM_UNIXTIME(date),'%Y%m%d');

Чем больше узнаёшь возможностей MySQL, тем больше кажется, что ты ничего не знаешь. Каких там функций только нет!

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

$page_result = mysql_query("SELECT id FROM page WHERE address='$PHP_SELF'");

if (@mysql_num_rows($page_result)==1)

  $page_id = mysql_result($page_result, 0);

elseif (!mysql_error()) {

  mysql_query("INSERT INTO page (address) VALUES ('$PHP_SELF')");

  $page_id = mysql_insert_id();

  };

Не хочется объединять таблицы при запросе, хотя меньше данных надо обрабатывать ? в главной таблице объём файла становится гораздо меньше, что ускоряет работу. Неясно, правда, сколько дополнительного времени это займёт при записи логов. По этому вопросу и мне, и Ромику хотелось бы услышать мнение общественности. Прошу высказываться в отзывах.




Содержание раздела