Пара ремарок перед началом чтения:

1. Несмотря на то, что на сайте 3proxy.ru гордо отображается сообщение о том, что антивирусы могут воспринимать 3proxy как вирус, я с таким не сталкивался. Возможно, это относится к исходникам и компиляции, а не к бинарникам. Все же современные антивирусы могут собрать статистику, что файл с такой-то контрольной суммой скачан 100500 раз и не начинают голосить почем зря. Кто знает...
2. Несмотря на то, что оригинал статьи не новый (в оригинале речь идет про версию 0.5.2, а на текущий момент стабильная версия 0.8.13), все подойдет и будет работать. Начинайте читать и совсем скоро вы увидите, что этот proxy действительно может быть простым.

Что это вообще такое?

3proxy - это прокси сервер (proxy, socks, pop3proxy) для Windows, Linux, Unix. Исходники открыты, бинарники скомпилировны, инструкции по компиляции указаны. Много лет развития. Что еще надо? Вперед!

Проще некуда

Для затравки, если уж "для чайников", да простят меня читатели, то вот простой конфиг 3proxy.cfg:

auth none
log
proxy

Куда уж проще... Вообще, 3proxy хорош тем, что он может быть и очень простым и лаконичным. Да и запуск его не сложен вовсе.

Скачали с сайта архив, распаковали в c:\3proxy, создали тектовый файл 3proxy.cfg и положили его в папку с exe-файлом, запустили cmd:

C:\Users\>cd "C:\3proxy\bin"
C:\3proxy\bin>3proxy.exe 3proxy.cfg
200318221136.662 3128 00000 - 0.0.0.0:0 0.0.0.0:0 0 0 0 Accepting connections [8996/8360]

Все, ничего не устанавливая, мы запустили proxy сервер, который принимает соединения на порт 3128. Можно прописать даже у себя в браузере, 127.0.0.1 3128 и все уже начинает работать, вы сразу увидите, как в консоли побегут строчки лога.

В этом конфиге:

• log без параметров означает выводить лог на stdout (на экран, в общем)
• proxy - запускаем именно прокси, а не socks, на стандартном порту 3128
• auth none - не запрашивать авторизацию, открытый прокси.

Оригинал с правками

Автор статьи: Kurmaeff Halit
halit_at_mail_dot_ru

Хочу поделиться своим опытом по настройке замечательного прокси-сервера от Заразы - 3proxy. Долгое время пользовался другим интересным прокси-сервером ES Proxy http://esproxy.org.ua от Георгия Павленко - маленького (всего один exe-шник на 300 кБ), довольно простого в настройке и очень нетребовательного к ресурсам - по крайней мере, при почти сотне пользователей он умудрялся работать на старинном P133, почти не затыкаясь. И только вот это <почти> - иногда все же проксик самопроизвольно пожирал 100% процессора, хотя и продолжал частично или полностью справляться со своими обязанностями - а также то, что автор уже почти 2 года как не подает никаких признаков жизни, то есть продукт замер в развитии - привели к поискам другого подходящего сервера. Скажу сразу - прокси-сервера с красивыми GUI меня привлекали мало, я сторонник принципа <Мне чтобы ехать>, а красивый интерфейс - это, конечно, хорошо, но не в ущерб производительности. Перепробовав не от хорошей жизни 5-6 разных продуктов (среди них Usergate, Proxy+, Lan4net....) и не оставшись довольным получаемыми результатами (должен заметить, что известный продукт от Майкрософт я решительно отмел ввиду его высокой стоимости), решил попробовать таки 3proxy, тем паче слышал в основном хорошие отклики. Если кто и жаловался на него, то только на сложность настройки, в чем, должен скачать, немного забегая вперед, я и имел возможность убедиться.

Каждый компьютер, подключенный к Интернет, является потенциальным объектом хакерских атак. Если компьютер подключается к сети через модем, да и то на 10 минут в день, то единственным достоянием хакера может стать только Ваш пароль на вход в Интернет (и, естественно, деньги, лежащие на счету у провайдера). Так как Ваш сервер, очевидно, имеет постоянное высокоскоростное соединение с Интернет, он является очень лакомым куском для хакера, и в том, что рано или поздно (скорее - рано) он подвергнется атаке - можно не сомневаться. Поэтому, прежде чем описвать дальнейшую настройку таких служб, как DHCP, DNS, VPN и др., необходимо защитить сервер от возможных непрятностей. В этой главе будут даны только начальные сведения по защите, и предложена настройка, способная отбить большинство непрофессиональных атак, и некоторые общие правила работы. Данная глава не предендует на статус полного руководства по защите, но на первое время хватит и этих данных. В дальнейшем Вам будет необходимо изучить вопросы безопасности более плотно, причем не откладывая этого дела в долгий ящик (практически на каждой из доступных мне машин, имеющих постоянное подключение к Интернет периодически (не реже раза в месяц) обнаруживаются следы попыток незконного проникновения...)

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

Вот тут то и самая большая сложность, которая возникла у меня при написании этой главы: каждый, кто пишет книги, статьи и руководства по защите, придумывает свою классификацию, основываясь на разных признаках атак. Поэтому я пойду другим путем, и не буду говорить что все атаки разделяются на 3 (5,7,19 или 244) класса, а опишу, по каким характеристикам их можно классифицировать.

Итак, у каждой хакерской атаки есть:

• Цель. Целью хакера может быть получение какой-то секретной информации, изменение информации (например, 10 баксов к себе на счет) или ее уничтожение, использование мощностей атакуемого объекта в личных целях (рассылка спама, экономия на "российском" и "зарубежном" трафике, использование "захваченной" машины в качестве плацдарма для атаки на другие машины), вывод объекта из строя (например, "подвесить" веб-сервер конкурента), для тренировки, самоудовлетворения и т.д.
• Используемые "дыры". Для атаки на компьютер хакер может использовать ошибки в программном обеспечении, ошибки администрирования (например, случайно доступная простому пользователю возможность изменения конфигурационных файлов операционной системы), незащищенность среды и протоколов передачи данных (например, "подслушивание" паролей пользователей, находящихся в одной сети с хакером), социальный инжениринг (например, подбор пароля администратора последовательным перебором имен всех его бывших любовниц и их номеров телефонов), метод "грубой силы" (подбор пароля простым перебором всех возможных комбинаций или по словарю), человеческие ошибки. Хакер, так-же, может использовать несколько "дыр" для одной атаки (например, используя сетевой снифер получить зашифрованный пароль администратора, и расшифровать его методом грубой силы).
• Направаление. Атака может быть как активно инициирована хакером (например, прямой перебор паролей или прослушивание сети), так и произведена с помощью какой-либо ловушки (например, "хитрый" JavaScript на веб-странице, зайдя на которую пользователь "поделится" с хакером какой-нибудь нужной информацией).
• Характер воздействия. Атака может быть активной (хакер непосредственно обращается к атакуемому компьютеру или тесно связвнным с ним системами) или пассивной (например, прослушивание сетевого трафика атакуемой системы). Пассивные атаки почти невозможно обнаружить.
• Количество атакующих. Атаковать систему может один хакер, группа хакеров, или один хакер с использованием нескольких компьютеров в сети. Групповые атаки обычно направлены на выведение системы из строя (DDoS).
• Местонахождение атакующего. Хакер может атаковать систему, находясь к по отношению к ней в разных зонах доверия. В нашем случае (сервер доступа для домашней сети) это следующие зоны: интернет, обслуживаемая домашняя сеть, доверенная зона (компьютер администратора, дополнительные сервера (файловый, баз данных), при общении с которыми защизаемый сервер использует более "мягкие" правила безопасности), внутри самой системы (например, хакер имеет права доступа обычного пользователя, и атакует учетную записть сисадмина).

Естественно, атаки можно классифициорвать и по другим признакам - данный список не претендует на полноту.

Для защиты от хакерских атак необходимо знать и понимать методы, используемые хакерами. Далее предлагаю рассмотреть несколько наиболее распоcтраненных (впрочем, я могу и ошибаться) типов атак и методов защиты от них.

Атака "переполнение буфера"
Атаки данного типа эксплуатируют "неявные" ошибки в прграммном обеспечении, обычно не влияющие на нормальную работу программы, но способные привести к взлому системы, или выведению ее из строя.

Предположим, существует некоторая программа, выпоняющаяся на атакуемой машине, и принимающая некоторые данные от пользователей (не важно, что она с ними потом делает). Пусть это будет, к примеру... web-сервер. Итак, Web-сервер позволяет пользователю подключиться к определенному порту, передать свой запрос, состоящий из нескольких полей, и передающий некоторые данные в ответ на запрос. Формат запроса к Web-серверу:

GET /название/страницы.html HTTP/1.1 Параметр: значение Параметр: значение

...и так далее. В "параметрах" броузер может передать, например, желаемую им кодировку текста, содержимое Cookie и т.д. Пусть сервер обрабатывает запрос следующим участком программы на языке C:

int ReadParam() { static char* s; static int c; char namebuf[256]; // область памяти для записи имени параметра char namevalue[1024]; // область пямяти для записи значение параметра s=namebuf; while( (c=NetReadChar()) != ':' && !NetworkError() ) *s++=c; .... далее что-то с этим делаем ...

Что делает этот участок кода: выделяет в стеке некоторый объем памяти для сохранения названия параметра и его значения, читает из пользовательского запроса символы до первого появления символа двоеточия и последовательно записывает их в предназначенную для этого область памяти. Здесь уже есть ошибка! Программист при написании программы точно знал, что наименование параметра никогда не будет длинее, чем 30-40 символов, и отвел 256 байт с запасом, чтобы не мучаться с дополнительной обработкой ошибок - "влезет" строка в память или нет, и что потом делать дальше. При этом количество реально записанных в память символов он уже не проверяет.

Казалось бы, что случится, если название параметра будет длинее, чем 256 символов? Ну не обслужит сервер такой запрос - а нечего слать непредусмотренные запросы... однако, точно зная структуру программы хакер может загнать в качестве названия параметра строку, содержащую выполняемый машинный код. Казалось бы - ну и пусть, ведь его-же никто не выполнит. Ну "повиснет" сервер, делов-то... Однако, адрес возврата из процедуры чтения параметров в основную программу тоже хранится в стеке (т.е. в той-же области памяти, из которой программист выделил место под хранение названия параметра), и хакер имеет все возможности изменить его (опять же, точно зная структуру программы), и заставить программу веб-сервера выполнить его код.

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

Бороться с такими атаками практически невозможно. Большинство специалистов по безопасности предлагают отключить все ненужные сервисы (ну зачем, скажите, на вашем сервере доступа, например, NIS?) и устанавливать все свежие патчи. От себя могу посоветовать затруднить хакеру возможность правильного определения версии вашего программного обеспечения: большинство сетевых программ вставляют в свои ответы еще и подпись - "Ответ сгенерирован программой такой-то, версия такая-то". Например, сервер www.hub.ru (очевидно, вы читаете этот текст именно с этого сайта) в свой ответ вставляет следующую информацию:

		Server: Apache/1.3.26 (Unix) PHP/4.2.2 mod_deflate/1.0.12 rus/PL30.14

Исходя из этой информации хакер может начать поиск либо готовых экспоитов для данной версии, либо самостоятельно начать анализировать исходные коды Apache. Чтобы помешать хакеру определить версию программного обеспечения, нужно заставить сервер выдавать вместо своего "паспорта" что-либо другое. С системой FreeBSD поставляются исходные коды практически всех используемых в ней программ, а многие программы вообще позволяют настраивать свой "паспорт", только этим никто не пользуется. Хакер же, увидев вместо вышеприведенной строки что-нибудь вроде "Server: SmartW3Daemon/0.3.12beta" будет вынужден сначала поискать этот SmartW3Daemon, а потом, когда поймет, что его надули, ему придется долго определять настоящую версию сервера по косвенным признакам.

Прослушивание сетевого трафика
Существует множество протоколов (таких как POP3, telnet, ftp и др.), передающих по сети незашифрованные данные, в том числе и пароли. Принцип же действия сети Ethernet таков, что любой посланный системой пакет доступен для просмотра всем членам домена коллизий, из которого послан пакет, а так-же всем членам доменов коллизий, через которые пакет пройдет на пути к адресу назначения.

Программное или аппаратное средство, позволяющее просматривать все проходящие мимо пакеты данных называется снифер. Программные сниферы существуют под любую операционную систему, и способны работать с практически любыми сетевыми картами. К счастью, в последнее время в сетях перестал встречаться коаксиальный кабель, а хабы (просто ретранслирующие пакеты на все порты) стали заменяться на коммутаторы, переправляющие пакет только адресату, однако и коммутаторы небезгрешны - если коммутатор специально не защищен от подобного рода атак, его можно за несколько секунд превратить в хаб, забив его внутренние таблицы коммутации большим количеством пакетов с сотен и тысяч фиктивных MAC-адресов. К сожалению, при разработке оборудования производители меньше всего думают о безопасности.

Если ваша сеть построена с использованием хабов, Вы сможете сами попробовать перехватить трафик ваших соседей, установив на свой компьютер, например, триальную версию пакета CommView компании TamoSoft (Для Windows).

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

Атака "Фальшивый Сервер"
Предположим (для простоты описания) что хакер находится в одной сети с администратором и сервером, а администратор предпочитает "рулить" сервером не непосредственно с его консоли, а делает это через сеть (и я его понимаю :)).

Итак, администратор набирает в командной строке ssh server.home.net, и надеется, что через несколько секунд он окажется на сервере. Ничего подобного! Умный хакер, использовав весь арсенал из предыдущего способа атаки, перехватывает запрос к серверу DNS, который посылает система администратора для получения IP-адреса компьютера с именем server.home.net. Хакеру остается только успеть раньше настоящего сервера DNS отправить системе администратора фальшивый ответ, указав в качестве адреса свою, заранее подготовленную систему, и понаблюдать, как администратор вводит свой пароль. Грамотный хакер может даже самостоятельно установить соединение ssh с сервером, и передавать введенные администратором данные на сервер (а администратору, соответственно, ответы), так что администратор ничего не заметит.

В данной атаке самое важное - успеть ответить на запрос раньше, чем это сделает настоящий сервер, а здесь у хакера есть все преимущества: перед тем, как дать ответ, сервер должен просмотреть свою базу данных, на что ему требуется некоторе время. Хакер же может держать "фальшивый" пакет уже наготове, и съэкономить на этом драгоценные миллисекунды. Кроме того, у хакера есть возможность предварительно загрузить сервер большим количеством запросов (легкая DoS-атака), что значительно увеличит время, требуемое серверу для выдачи ответа.

Ошибки в программах и скриптах
Пожалуй, больше всего ошибок, связанных с безопасностью, допускают web-программисты в cgi-скриптах. Особенно часто такие ошибки гнездятся в скриптах, посылающих почтовые сообщения по адресу, указанному пользователем. Вот примерный код такого скрипта на языке perl:

$email=param('email'); open(MAIL,"| sendmail $email"); print MAIL "......"

Этот скрипт в первой строчке получает введенный пользователем адрес, после чего организуют конвейер (или пайп - механизм, принятый в unix и DOS, позволяющий "вывод" одной программы переправить на "ввод" другой). "Хитрый" хакер может вместе с адресом электронной почты ввести символы, "продожающие" конвейр, например cool@hacker.ru | rm -Rf /bin. Результатом подстановки такого адреса во вторую строку будет двойной конвейр: open(MAIL,"| sendmail cool@hacker.ru | rm -Rf /bin"). При выполнении этой команды текст письма будет перенаправлен на ввод команде sendmail, а вот ее вывод будет перенаправлен на ввод команде rm, которая в данном случае (если у процесса, исполняющего скрипт, хватит полномочий), удалит из системы все основные программы, расположенные в каталоге /bin.

Внутрисистемная атака
Нижеописанным способом практически при мне (но без моего участия) студентами был взломан компьютер института, и получены полномочия root. Эта атака весьма похожа не предыдущую, с той только разницей, чтохакер уже имел права обычного пользователя в системе.

В операционных системах семейства UNIX процессы выполняются от имени и с полномочиями пользователя, их запустившего. Исключение составляют программы, на который установлен аттрибут SETUID, заставляющий систему выполнить программу от имени и с полномочиями владельца программы.

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

Ошибочка состояла в следующем: в своей программе администратор пользовался услугами другой программы (ну, предположим, passwd - изменение пользовательского пароля), и запускал ее функций execlp. В отличие от обычного execl, функции execlp не нужно передавать полный путь к программе (/bin/passwd), а достаточно передать только имя файла - passwd. Путь к программе execlp находит сама, пользуясь для этого переменной окружения PATH... казалось бы - ничего страшного, PATH то обычно и начинается с этого самого /bin... однако, пользователь имеет право менять свою собственную переменную PATH, которую и получит программа.

Юными хакерами была написана собственная программа, названа passwd, выложена в собственном каталоге. Переменная PATH была соответсвенным образом изменена, в результате чего программа администратора вместо /bin/passwd запустила на выполнение /home/.../passwd с правами администратора. К счастью для института, и несчастью для хакеров, взлом был довольно быстро обнаружен сиситемой слежения (хакерам не хватило опыта), но система после этого не работала неделю - искали оставленные хакерами "закладки".

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

Предотвращение атак

Во-первых, необходимо отказаться от использование не необходимых служб на сервере. Если Вам необходим какой-то сервис, но его можно вынести на другую машину - сделайте это. Естественно, эти машины должны быть как можно меньше логически связаны между собой - на каждой из них должна быть собственная система авторизации, пароли администраторов и пользователей, имеющих какие-либо административные привелегии не должны совпадать. Машины не должны "слепо" доверять друг-другу только потому, что они стоят в одной комнате - любое общение между ними должно быть защищено. Если какой-то сервис необходимо оставить на одной машине с критично-важными данными - попробуйте поискать информацию про известные уязвимости, и про более защищенные альтернативные реализации. Для самостоятельного изучения оставлю так-же такие средства безопасности отдельных приложений, как chroot и jail.

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

Вот примерный спикок сервисов, которые могут оказаться запущеными на Вашем сервере, и которые желательно "пристрелить", если в них нет необходимости:

Не менее важно для безопасности системы и само поведение администратора в системе. Учетная запись root - самый лакомый кусочек для хакера, и задача администратора - постараться не дать хакеру возможности ее заполучить, даже если хакер уже пробился в систему с пользовательскими правами, или имеет возможность перехвата сетевого трафика. Чем меньше администратор совершает действий с привилегиями учетной записи root, тем меньше риск ошибки. Вот пример того, как администратор (правда, системы Windows NT) "подарил" хакеру свой пароль. А все только потому, что воспользовался браузером из под административной учетной записи.

Хорошим правилом является заведение себе отдельной учетной записи, не обладающей административными привелегиями. Обычных пользовательских прав хватает для выяснения причин возникновения проблемы, а для ее исправления обычно достаточно выполнения всего одной-двух команд с привелениями root - для этого удобно воспользоваться командой su, которая временно даст Вам полномочия root (естественно, только после ввода пароля. Кроме того, для возможности запуска команды su пользователь должен быть членом встроенной группы wheel).

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

Обнаружение и нейтрализация атак

Наравне с задачей защиты системы от взлома стоит и задача своевременного обнаружения атаки и уменьшения ущерба от взлома. Ущерб, и способы его уменьшения зависят больше от функций, выполняемых системой, поэтому какие-то рекомендации, кроме набившей уже оскомину "делайте резервные копии", дать сложно. А вот обнаружение атаки на разных стадиях - дело вполне алгоритмируемое.

Одним из первых инструментов хакера при атаке на систему является сканер портов - некая программа, пытающаяся подключиться к удаленной системе по множеству известных ей протоколов для выяснения дальнейших возможных путей взлома. Функции этих программ могут быть весьма продвинутыми, а могут ограничиваться и последовательным перебором всех портов протоколов TCP и UDP, но в любом случае процесс сканирования портов можно засечь и принять соответствующие меры. Понятно, что постоянно сидеть и следить за системой администратор не будет, поэтому существуют программные средства, способные самомтоятельно засекать такие атаки, и отбивать их. Одна из таких программ - portsentry.

Установить PortSentry можно из набора портов - /usr/ports/security/portsentry (для установки программы подключитесь к сети Интернет, перейдите в этот каталог, и введите команду make install - программа будет скачана с сайта производителя и автоматически установлена в системе). После установки программы ее необходимо будет сконфигурировать, отредактировав файл /usr/local/etc/portsentry.conf.
Для начала нужно составить списки портов, попытка подключения к которым будет расцениваться, как криминал. Для этого нужно создать собственные строки TCP_PORTS и UDP_PORTS, или воспользоваться одной из имеющихся. Естественно, в список "криминальных" портов не следует включать те, на которых в Вашей системе существуют "легальные" сервисы. После создания списка "криминальных" портов необходимо настроить действие, предпринимаемое portsentry для отбивания атаки. Если в вашей системе установлен файрвол, то найдите и раскомментируйте (удалите начальный значек '#' ) строку:
KILL_ROUTE="/sbin/ipfw add 1 deny all from $TARGET$:255.255.255.255 to any"

При данной настройке portsentry запретит прохождение любых пакетов с атакующего хоста добавлением правила в файрвол. Если файрвол на вашей машине не установлен - найдите и раскомментируйте строчку:
KILL_ROUTE="route add -net $TARGET$ -netmask 255.255.255.255 127.0.0.1 -blackhole"

При данной настройке пакеты от атакующего хоста по-прежнему смогут достигать Вашего сервера, но ответные пакеты будут направлены в "черную дыру" (blackhole), и уничтожены. Это почти так-же эффективно, как и запрещение входящих пакетов с помощью firewall, но не помогает от DoS-атак.

Внимание! После перезагрузки все добавленные в файрвол правила, и добавленные в таблицу роутинга маршруты будут забыты, поэтому хакер опять сможет получить доступ к Вашей машине до первой попытки сделать что-либо запрещенное. Если Ваш сервер перезагружется достаточно часто - напишите собственный скрипт, который будет не только вносить правило в firewall, но и приписывать его к файлу настройки firewall, исполняемому при загруке системы.

К сожалению, в поставке portsentry пока не идет скрипт автоматической загрузки программы при старте системы, поэтому Вам самостоятельно придется создать файл /usr/local/etc/rc.d/portsentry.sh со следующим содержимым:

#!/bin/sh PSENTRY="/usr/local/bin/portsentry" case "$1" in start) ${PSENTRY} -tcp ${PSENTRY} -udp echo " PortSentry " ;; stop) killall portsentry ;; *) echo " " echo "start or stop parameter required." echo " " ;; esac

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

Следующая полезная утилита - tripwire, которую Вы можете установить из /usr/ports/security/tripwire. Не забудьте обновить дерево портов - из того порта, что идет вместе с FreeBSD 4.7 tripwire не устанавливается (по крайней мере, на моей машине не установилось). Самый простой вариант обновления - скачать содержимое каталога ftp4.ru.freebsd.org/pub/FreeBSD/ports/ports-stable/security/tripwire к себе в /usr/ports/security/tripwire. Более сложный, но гораздо более правильный метод - использовать CVSUpdate, но это отдельная большая тема.

Эта утилита (tripwire) предназначена для отслеживания состояния системных файлов. Хакер, проникший в систему, скорее всего попытается оставить для себя "закладки на будущее" - программы, или настройки стандартых программ, обеспечивающие хакеру более простые способы добраться до системы в следующий раз. Таких мин может быть раскидано достаточно много, в расчете на то, что администратор сервера, заметив взлом, найдет не все закладки. Tripwire облегчает поиск таких закладок, сообщая администратору о всех изменениях в потенциально опасных каталогах и файлах.

В процессе установки tripwire создаст базу данных, в которую будут занесены сведения о всех системных и конфигурационных фалйх. База по умолчанию создается в каталоге /var/db/tripwire, но в этом случае хакер может ее изменить после установки "закладок", поэтому базу желательно хранить на защищенной от записи дискете. Для этого при установке tripware надо использовать команду make install TRIPEWIRE_FLOPPY=YES. При этом, естественно, в дисководе должна находиться чистая форматированная дискета. Если на машине установлено много всякого барахла - база на дискету может и не влезть. В этом случае Вам придется самому переписать ее, например, на CDRW: если система настроена и стабильно работает, то изменения в системные файлы вносятся не часто, и перенос базы tripwire на внешние носители не будет слишком обременительным.

Информация в базе содержится в зашифрованном виде, поэтому при установке tripwire попросит Вас придумать два пароля - одним будут закодированы настройки, а другим сама база. Пароли забывать не стоит - могут пригодиться при изменении настроек и "принятия к сведению" легальных изменений в файловой системе.

При создании базы tripwire начнет ругаться на отсутствие у Вас некоторых каталогов вроде /usr/tmp и т.п. Самое обидное, что эта же ругань будет и в ежедневных отчетах. Поэтому придется немного поизучать настройку tripwire. Самый главный файл настройки - /usr/local/etc/tripwire/twpol.txt. Это обычный текстовый файл, в котором описано, какие файлы надо проверять, и с какой степенью придирчивости это делать. Файл логически состоит из двух частей: общие настройки и правила проверки. В общих настроках прописываются пути к основным файлам tripwire, и задаются символические имена для уровней "придирчивости". Список правил - это собственно и есть указания, какие каталоги проверять. Правило состоит из заголовка и тела. Заголовок имеет следующий вид:

( rulename = "Root's home", severity = $(SIG_HI), emailto="admin@host.domain" )

, где rulename - название правила, severity - уровень "придирчивости", emailto - кому сообщать о происшествиях. Строки emailto приходится к каждому правилу добавлять вручную. Тело правила выглядит следующим образом:

{ /.profile -> $(SEC_CRIT) ; /.cshrc -> $(SEC_CRIT) ; /.forward -> $(SEC_CRIT) ; /root -> $(SEC_CRIT) (recurse = true) ; !/root/.history ; !/root/.bash_history ; }

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

twpol.txt не используется при работе tripwire напрямую. Используется его зашифрованная версия, получить которую из текстового файла можно следующим образом:
/usr/local/sbin/twadmin -m P /usr/local/etc/tripwire/twpol.txt

при этом Вам придется ввести пароль. Сам текстовый файл с настройкой политики желательно тоже хранить в недоступном хакеру месте (на дискете в ящике стола), т.к. по этому файлу он сможет вычислить области с меньшей параноидальностью проверки.

Если Вы произвели какие-то изменения в системе, и не хотите, чтобы tripwire каждый день о них рассказывал - переинициализируйте базу командой /usr/local/sbin/tripwire --update (для обновления базы) или /usr/local/sbin/tripwire --init для создания базы "с нуля". Естественно, понадобится пароль - иначе хакер тоже сможет изменить базу.

Неплохо так-же переместить все относящиеся к tripwire файлы куда-нибудь в глубины файловой системы, например /usr/src/sys/libkern/patch/7.40, чтобы уменьшить вероятность обнаружения хакером нашей системы слежения, но при этом все-равно останется "след" - где-то должен сидеть автоматический запуск tripwire с некоторой периодичностью. Стандартный способ запуска - добавить в /etc/crontab строчку

15 6 * * * root /usr/local/sbin/tripwire --check --silent --email-report

для запуска проверки каждый день в 6:15 утра, но это будет слишком быстро вычислено хакером. Более замороченным способом будет вставка вызова tripwire в какой-нибудь другой регулярно запускаемый служебный скрипт (например, подсчет статистики), достаточно сложный и неинтересный, чтобы хакеру хотелось в нем копаться, либо внесение изменения в код какого-либо постоянно исполняемого системой демона (благо исходные коды есть почти для всех программ). Переименование всех файлов tripwire во что-нибудь более безобидное тоже пойдет на пользу - тупой перебор всех каталогов на поиск слова tripwire не принесет хакеру желаемого результата.

Если предприняты меры по "прятанью" tripwire от глаз хакера, придется так-же выполнить make clean в каталоге /usr/ports/security/tripwire и удалить /usr/ports/distfiles/tripwire* для сокрытия следов сборки и установки tripwire. Правда, после этого останутся еще следы в протоколе работы почтовой системы, т.к. доставка администратору сообщений от tripwire должна быть регулярной, но tripwire можно настроить и для использвания внешнего почтового сервера. После этого можно быть уже относительно спокойным за скрытность работы tripwire. Конечно, останется еще вероятность того, что хакер будет работать в системе одновременно с работой tripwire, засечет какой-то чрезмерно активный процесс, и найдет наш замаскированный tripwire по этой ниточке, но с этим ничего не сделаешь (разве что поставить второй сервер специально для tripwire, и проверять диски через сеть), но вероятность такого обнаружения довольно мала.

Настройка tripewire - дело достаточно тонкое, т.к. неправильно настроенная tripewire засыпет Вас ложными сообщениями о неполадках в системе, в то время как настоящие нарушения могут быть пропущены. К сожалению, действительно хорошего руководства на русском языке в Интернете обнаружить не удалось, а насчет достаточности собственного опыта для написания действительно толкового полного руководства я не уверен. Тем не менее рекомендую почитать:
'http://bog.pp.ru/work/tripwire.html/'
'http://tcb.spb.ru/other/docum/linuxsos/ch12_1.html/'
а так-же все, что найдет yandex и google по этому поводу. Возможно, из моего рассказа что-то осталось непонятным - надеюсь, в этих статьях Вы сможете найти ответ на интересующие Вас вопросы по установке и первоначальному конфигурированию.

На этом предлагаю закончить экскурсию в сумасшедший дом по отделению параноиков, и в следующей главе обсудить настройку firewall'а - вещи, полезной как в плане безопасности, так и длятонкой настройки работы сервера доступа.

(C) 2002 by Kuzmich