А программы эти, как известно, норовят активно использовать Сеть. Пароли, скажем, Ваши отправить злоумышленнику, адресную книгу — спаммерам, а то и включить зараженный компьютер в планируемую DOS-атаку или спам-бот. Не знаете, что это такое? Поинтересуйтесь у Google. Я же только скажу, что за последние несколько месяцев пара-тройка моих клиентов оказывалась в результате подобных инцидентов blacklisted на спам-копах и лишалась, таким образом, минимум на неделю возможности отправки e-mail. Ощутимый удар для какого-нибудь рекламного агентства или издательства. Так что: бди, сисадмин!

Ничего подобного, конечно, не случится, если Вы фильтруете исходящий трафик. Факт заражения локальной станции при этом, однако, иметь место может. А мало ли какие еще фантазии были у вирусописателя? Да и вычислительные ресурсы, которых всегда не хватает, как-то жалко отдавать вирусу — не для этого покупались. Словом, зараженную машину нужно лечить, и, желательно — поскорее.

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

Анализ логов файрвола, как средство поиска поражённых станций — само собой напрашивающееся решение. Если Вы используете моду Performance Graphs, то график "Firewall hits over the last day" всегда покажет, насколько высока была запрещённая активность за последние сутки (а при желании — и за последние неделю, месяц, год). "Всплеск" такой активности — указание на то, что что-то неблагополучное происходит. И если уж такое случилось, то стоит поинтересоваться, кто был виновником этого "всплеска".

Беда в том, что просмотр в окне браузера десятков (а то и сотен — случалось) страниц firewall log — не человеческая задача. В смысле: не для человека. Функция "Export" позволит получить исходный лог (нетрудно догадаться, что это — всего лишь результат фильтрации по времени /var/log/messages), а потом его уже анализировать с помощью grep, wc и т.п. (полагаю, вы знаете что это такое). Уже — лучше. Но, open source это или "где"?! Неужели нельзя заставить smoothwall самого находить зараженные станции? Можно, отчего же. И даже — более того.

Пишем.... Точнее, сначала обращаем внимание на имя cgi-скрипта, выполняющего вывод firewall log. Это, как выясняется, firewalllog.dat. Поскольку корневой каталог http-сервера известен, то полный путь к нужному файлу будет: /httpd/cgi-bin/logs.cgi/firewalllog.dat. Предложение простое: добавить на страницу firewall log ещё одну кнопку и выводить по её нажатию интересующую информацию.

Первое решается вставкой строк

    <TD WIDTH='10%' ALIGN='CENTER'>
      <INPUT TYPE='submit' NAME='ACTION' VALUE='$tr{'info'}'>
    </TD>

Сразу вслед за аналогичными строками, выводящими кнопки "Update" и "Export". Смысл этой операции должен быть очевиден любому мало-мальски знакомому с html.

Так же, как приведенный ниже фрагмент кода должен быть понятен любому, когда-либо писавшему cgi-скрипты.

if ($cgiparams{'ACTION'} eq $tr{'info'}) { # вх. параметр — info
  my %lhosts; # хэш ip станций
  my %netsettings; # хэш параметров сети
  # читаем параметры сети:
  &readhash("${swroot}/ethernet/settings", \%netsettings);
  print "Content-type: text/plain\n\n";
  print "SmoothWall firewall log\r\n";
  print "Date: $cgiparams{'DAY'} $longmonths[$cgiparams{'MONTH'}]\r\n\r\n";

print "station ip\tfirewall hits\r\n\r\n"; # имена колонок
  foreach $_ (@log) { # для всех строк лога
    # заданой даты:
    /(^${monthstr} ${daystr} ..:..:..) [\w\-]+ kernel: (.*)/; 
    my $packet = $2; # описание пакета
    # если пакет исходящий
    if ($packet=~/^IN=$netsettings{'GREEN_DEV'} \S+ SRC=(\S+)/) { 
      my $src=$1; # от кого?
      # дополняем, если нужно, хэш ip станций:
      unless (exists $lhosts{$src}) { $lhosts{$src}=1 }
      # или инкрементируем счётчик вхождений:
      else { $lhosts{$src}+=1 } } }
      # распечатываем с сортировкой по числу вхождений:
  foreach $key (sort {$lhosts{$b}<=>$lhosts{$a}} keys %lhosts) {
      print "$key\t\t$lhosts{$key}\r\n" }

exit 0;
}

Место вставки — перед фрагментом, выполняемым в случае, если входным параметром будет export ($cgiparams{'ACTION'} eq $tr{'export'}). Фрагмент не покажется Вам сложным, если Вы обратите внимание, что он на 90% (и в принципе написания) повторяет фрагмент для входного параметра export. На мой взгляд, это даже программированием назвать было бы слишком смело. Результат, однако, вполне удовлетворителен: выбираем дату (если интересуют не текущие сутки), жмём на Info — получаем список станций в порядке убывания количества попыток нарушения правил файрвола.

Наиболее рьяным сторонникам автоматизации можно предложить написать аналогичный независимый скрипт и выполнять его по cron. Раз в сутки, например. С отправкой сообщения на Ваш e-mail, если количество нарушений правил файрвола отдельной станцией превысит, например 500-т. Или — в виде SMS на мобильный, если Ваш оператор принимает SMS-сообщения, отравленные посредством e-mail. И так далее, насколько позволит Ваша фантазия.

А теперь — немного об идеологии. Возможны ли "самоделки", подобные описанной выше, при работе с закрытым коммерческим продуктом? В большинстве случаев — нет. Хотя и закрытый продукт может предоставлять API или средства разработки plugin-ов. Последнее, всё-таки, чаще исключение, чем правило, но не будем на этом останавливаться. Главное, мне кажется, в ином. Отличается сам подход. Пресловутый "unix way", что ли?

Я не знаю, что есть "unix way" в применении к пользовательскому десктопу. Для сервера — более-менее понятно (читайте ESR-а), но, сдаётся мне, что в данном случае уместнее говорить не о собственно "unix way", как его определяет Рэймонд, а об идеологии, которая предшествовала его реализации. Современные программные комплексы настолько сложны, что только независимая разработка компонент допускает участие в них множества программистов, не являющихся сотрудниками одной компании. "Отцы-основатели" unix предложили концепцию, подразумевающую раздельную разработку компонент, движение open source дополнило её требованием открытости кода... и мы имеем "то, что имеем".

Так, стек протоколов TCP/IP, драйверы wi-fi адаптеров, wireless tools Жана Турилье (Jean Tourrilhes), wpa_supplicant Жуни Малинена (Jouni Malinen) и хренова куча сетевых менеджеров wi-fi разрабатываются достаточно независимо. Распространённый на win-форумах запрос "нужна прога" звучит при таких условиях довольно глупо. "Проги", которая сама по себе обеспечила бы поддержку адаптера, протокола 802.11, аутентификацию, шифрование и выбор сети просто не существует. Складывается впечатление, что для движения open source unix way — оптимальная (если не единственно возможная) идеология.

Вопрос в том, хорошо это или плохо. Вон, в ms win большая часть из вышеперечисленного является частью ОС одного производителя. Не достаёт, как правило, только драйвера устройства... Хорошо ведь! Но это — только пользовательская точка зрения. Для индустрии же разнообразие и количество независимых разработок — благо. В любом из смежных секторов экономики подобный вопрос был бы совершенно излишним. Автомобилестроителям не приходит в голову предать анафеме картинг или объявить бесполезной тратой средств разработку болидов Формулы-1. Все понимают, что без картинга не вырастут толковые механики (инженеры, гонщики), а отсутствие Формулы-1 вряд ли пойдёт на пользу прогрессу в отрасли. Претензии к удобству сидения в карте и отсутствию крыши в болиде одинаково глупы. Как и отрицание востребованности комфортабельных седанов или автобусов (в классификации Нила Стивенсона), впрочем.

С другой стороны, проприетарная модель разработки ПО, демонстрирующая исключительную способность лучшим образом соответствовать пожеланиям покупателя, несёт в себе неизбежные изъяны. Ибо основное назначение товара — быть проданным. Рациональность постановки задачи и её оптимальное решение — не главное, был бы покупатель: "за Ваши деньги — любую глупость". Бизнес ИТ-технологий ничем в этом плане не отличается от любого иного. "It's busyness...", как любили повторять мои корейские коллеги по СП, пытаясь оправдать этим любую глупость или мерзость.

Монополия M$ на ОС и проприетарная модель разработки сводит всё многообразие ПО к "системе" и "прогам". В результате монополия с каждым годом усиливается, количество продаж — растёт и только эффективность использования средств ВТ что-то никак не повысится. А с чего бы ей повышаться? Впрочем, кого... волнует?

Комментарии