После сканирования я рекомендую вам выйти из SATAN, зарегистрироваться в системе как обыкновенный пользователь (сейчас вы были зарегистрированы как пользователь root), заново запустить SATAN и спокойно просматривать результаты сканирования (Reporting and Data Analysis). Долго работать с SATAN под пользователем root не рекомендуется, как и переходить на другой сайт, не завершив работу SATAN. При переходе на другой узел Netscape передаст ему переменную HTTP_REFERER, в которой будут указаны идентификатор сессии и номер порта сервера SATAN.
Для редактирования конфигурационного файла SATAN можно воспользоваться утилитой Configuration Management, хотя можно редактировать файл satan.cf и вручную.
Среди прочих параметров есть одновременно интересный и опасный параметр: max_proximity_level.
Этот параметр задает уровень сканирования соседей. По умолчанию этот параметр равен нулю и соседние сети не сканируются. Чтобы лучше понять, что это такое, представьте себе такую ситуацию. SATAN сканирует узел host.depl.company.ru. Сканер определяет, что домен depl.company.ru обслуживает сервер DNS ns.depl.company.ru. Пусть одна из записей NS этого сервера указывает на узел ns.company.ru. Автоматически домен company га попадает в число сканируемых. Поэтому никогда не устанавливайте значение параметра max_proximity_level большее 2, иначе это может закончиться сканированием всего Интернета.
Вам, наверное, надоело получать письма спаммеров примерно такого содержания:
Вы можете заработать в течение следующих 180 дней на рассылке e-mail
КАЖЕТСЯ НЕВОЗМОЖНЫМ?? Прочитайте детали, в этом нет никакой каверзы или обмана.
И при этом они (спаммеры) нагло заявляют: «ЭТО НЕ СПАМ !!!» А еще больше раздражают вирусописатели, которые распространяют сетевые вирусы (черви). Наверняка в вашей сети найдется хоть один доверчивый пользователь, который щелкнет на ссылке Cool Girl! Enjoy It!. И тогда злостный вирус-червь (Worm) поползет по просторам вашей сети. Не очень приятная ситуация… С вирусами немного проще: в предыдущей главе мы уже рассматривали как установить AVP на почтовом сервере, сейчас же займемся борьбой со спаммерами.
Для ограничения пересылки почты через сервер используется файл /etc/mail/access (точнее access.db, в который преобразуется файл access). Данный файл используется программой sendmail. В нем вы можете указать узлы, которым разрешено (запрещено) использовать ваш SMTP-сервер. Формат этого файла такой:
узел|сеть|пользователь действие
Например:
localhost.localdomain RELAY
localhost RELAY
127.0.0.1 OK
[email protected] REJECT
spamworld.com ERROR:"550 Access denied"
192.168.1 RELAY
host.mydomain.ruREJECT
mydomain.ru RELAY
В первой-третьей строках мы разрешаем самим себе использовать SMTP-сервер. Затем мы запрещаем пересылку почты пользователю [email protected], а также всему домену spamworld.com. Шестая строка разрешает пересылку почты всей нашей локальной подсети — 192.168.1.*. Последняя строка разрешает использовать SMTP-сервер нашему домену, а предпоследняя запрещает использовать наш сервер одному узлу из домена mydomain.ru — host.
Разница между действием OK и RELAY заключается в том, что в первом случае (OK) пересылка разрешается, даже если другие правила sendmail запретили пересылку почты, например, имя узла не разрешено (при использовании DNS).
Для запрещения пересылки можно просто использовать REJECT. Тогда пользователь увидит сообщение «Access denied». Действие ERROR более информативно, так как вы можете указать любое свое сообщение (установить реакцию на ошибку). Действие ERROR можно записать по-другому: ERROR:D.S.N:Message, где D.S.N — это код ошибки в соответствии с RFC 1893. Для того чтобы новые правила доступа вступили в силу, введите команду: makemap hash /etc/mail/access < /etc/mail/access
Изменения вступят в силу сразу после завершения работы программы makemap. Перезагружать sendmail при этом не нужно!
23.3. Ограничение системных ресурсов
Иногда пользователи жалуются, что администраторы сильно «урезают» их права. Однако делается это с благой целью — обеспечить здоровье системы. Например, представьте, что пользователь-вредитель Пупкин запустит такой сценарий:
#!/bin/bash
# Сценарий loop
echo "Бесконечный цикл"
./loop
Этот сценарий выводит строку «Бесконечный цикл», а потом запускает самого себя. Получается что-то наподобие прямой рекурсии. Рано или поздно такой сценарий использует все системные ресурсы, и при запуске полезного процесса вы получите сообщение: Unable to fork
То есть невозможно создать процесс. Этого можно легко избежать, если вы определите параметр nproc в файле /etc/security/limits.conf. В файле limits.conf задаются ограничения ресурсов системы для пользователя или группы пользователей. Формат файла таков:
<domain> <type> <item> <value>
Первое поле (domain) может содержать:
1. Имя пользователя.
2. Имя группы. Перед именем группы нужно указать символ «@».
3. Символ «*». Данное ограничение будет ограничением по умолчанию.
Второе поле (type) — это тип ограничения: мягкое (soft) или жесткое (hard). Мягкое ограничение определяет число системных ресурсов, которое пользователь все еще может превысить, жесткое ограничение превысить невозможно. При попытке сделать это, пользователь получит сообщение об ошибке. Что касается элемента ограничения (item), то им может быть:
core — ограничение размера файла core (Кб).
data — максимальный размер данных (Кб).
fsize — максимальный размер файла (Кб).
memlock — максимальное заблокированное адресное пространство (Кб).
nofile — максимальное число открытых файлов.
stack — максимальный размер стека (Кб).
cpu — максимальное время процессора (минуты).
nproc — максимальное число процессов.
as — ограничение адресного пространства.
maxlogins — максимальное число одновременных регистрации в системе.
locks — максимальное число файлов блокировки.
Рассмотрим несколько примеров. Например, нам нужно установить максимальное число процессов для пользователя user. Это можно сделать с помощью таких записей:
user soft nproc 50
user hard nproc 60
Первая строка определяет мягкое ограничение (равное 50), а вторая — жесткое.
Допустим, у вас есть группы dialup1 и dialup2. В каждую группу входят 30 пользователей. При этом у вас есть всего 30 входящих линий, поэтому нужно обеспечить одновременную работу не более 15 пользователей из каждой группы. Это делается так:
@dialup1 - maxlogins 14
@dialup2 - maxlogins 14
В первом и втором случае из каждой группы пользователей одновременно работать смогут не более 15 (maxlogins 14 — отсчет начинается с нуля). При регистрации шестнадцатый пользователь увидит сообщение:
Too many logins for 'dialup1'
Иногда бывает полезным ограничить самого себя, то есть пользователя root. Рассмотрим, как это сделать. В файле /etc/securetty, который уже упоминался выше, указываются терминалы и виртуальные консоли, из которых может регистрироваться пользователь root. Я рекомендую вообще запретить регистрацию пользователя root из консоли. Для этого удалите (или закомментируйте) все строки в файле /etc/securetty. Если вам будут нужны максимальные привилегии, используйте команду su (super user). После ввода этой команды, программа запросит у вас пароль пользователя root, и если пароль правилен, вы получите привилегии пользователя root.
Напоследок — несколько рекомендаций по администрированию сервера. После того, как вы установили и настроили операционную систему, нужно регулярно «присматривать» за сервером, не полагаясь на надежность и защищенность Linux. Конечно, если у вас обыкновенный роутер, после настройки системы вы с чистой совестью можете поставить ваш сервер на полку и забыть о нем до тех пор, пока не понадобится внести новые правила фильтрации.
Если же ваш сервер выполняет более серьезные задачи, например, является сервером аутентификации, Web или FTP-сервером компании, нужно хотя бы один раз в день просматривать системные протоколы с целью обнаружить несанкционированный доступ к системе.
Что же делать, если вы обнаружили следы атаки на ваш сервер? Нужно деактивировать тот сервис, через который злоумышленник проник в вашу систему. Можно даже вообще отключить сервер из сети (компьютерной, а не сети питания!), если вы можете себе такое позволить. Затем нужно попытаться «заштопать дыру»: если взлом произошел из-за неправильной (или неполной) настройки сервера, подправьте конфигурационный файл сервиса, который был взломан. Если же взлом произошел из-за недоработок сервиса со стороны разработчиков, посетите сайт разработчиков и скачайте новую версию сервиса или патч к ней, исправляющий данную ошибку. Перед этим убедитесь, что эта ошибка исправлена в новой версии или в патче, в противном случае сообщите об ошибке разработчикам. Желательно проверить другие сервисы системы и установить в случае необходимости к ним «заплатки».
