Форум АНТИЧАТ - Делаем FreeBSD безопасной (Xakep № 69)

Делаем FreeBSD безопасной

Сергей Можайский aka techniX

Xakep, номер #069, стр. 069-116-1

(technix@frenzy.org.ua)

FreeBSD: Top Security

Итак, ты решил построить сервер на базе FreeBSD. Хороший выбор. Однако любой сервер является лакомым кусочком для хакера, и даже не стоит сомневаться в том, что рано или поздно он подвергнется атаке. Поэтому в первую очередь стоит заняться не настройкой различных сервисов, а защитой системы от взлома. Конечно, в системе, установленной с настройками по умолчанию, защита находится на достаточном уровне. Однако мы можем сделать наш сервер настоящим крепким орешком. Ну что, начнем строить защиту своей FreeBSD-системы?

Консольные твики

Как известно, загрузившись в однопользовательском режиме, можно изменить пароль суперпользователя. Нам следует устранить эту досадную недоработку. Отредактируем файл /etc/ttys таким образом, чтобы при загрузке с опцией boot -s система запрашивала пароль

Код:

console none unknown off insecure

Также следует запретить прямой вход с консоли пользователя root. Для этого в том же файле нужно сменить статус консоли на insecure. Вот пример для нулевой консоли:

Код:

ttyv0 "/usr/libexec/getty Pc" cons25 on insecure

Для того чтобы только пользователь root мог видеть все запущенные процессы, добавь в /etc/sysctl.conf следующую запись:

Код:

kern.ps_showallprocs=0

Ваши права?

Права доступа к файлам - одна из отличительных особенностей UNIX-систем. Давай назначим эти права как следует. На некоторые системные файлы стоит установить такие флаги доступа, чтобы они были доступны только суперпользователю. Вот примерный список:

Код:

# chmod 700 /root



# cd /etc



# chmod 600 syslog.conf rc.conf newsyslog.conf hosts.allow login.conf

Некоторые системные файлы стоит защитить даже от суперпользователя. Для этого существуют модификационные флаги, установить которые можно командой chflags. К ним относятся флаг appnd, который переводит файл в режим добавления данных, и флаг chg, делающий файл изменяемым только для пользователя root. Подробности по использованию этой команды можно прочесть на странице руководства, посвященного chflags (man chflags).

Файловую систему с пользовательскими каталогами лучше смонтировать с параметром -nosuid, который игнорирует suid-биты на файлах. Вот пример строчки из /etc/fstab, монтирующий /usr/home с флагом nosuid (nodev здесь также не помешает - прим.ред.):

/dev/ad0s1h /usr/home ufs rw,nosuid 2 2

Утилита suidcontrol (www.watson.org/fbsd-hardening/suidcontrol.html) поможет установить правильную политику в отношении suid/sgid-файлов в системе.

Чтобы при загрузке удалялось содержимое каталога /tmp, добавляем в /etc/rc.conf строку

clear_tmp_enable="YES"

Уровни защиты ядра

Ядро FreeBSD может работать на нескольких уровнях защиты (securelevel). Значение этого уровня варьируется от -1 до 3. Для нас интересны последние три режима. В режиме 1 (безопасный режим) нельзя снимать модификационные флаги с файлов, а смонтированные дисковые устройства и файлы устройств /dev/mem, /dev/kmem не могут быть открыты для записи. В режиме 2 (режим повышенной безопасности), в дополнение к предыдущему, запрещена прямая запись на диски, независимо от того, смонтированы они или нет. В режиме 3 (режим безопасности сети), кроме ограничений второго режима, запрещено изменение правил файрволов и ограничений скорости канала. Для включения уровней защиты следует добавить в /etc/rc.conf строки

Код:

kern_securelevel_enable="YES"



kern_securelevel="2"

Текущий уровень защиты можно посмотреть командой

$ sysctl kern.securelevel

А повысить его без перезагрузки -

Код:

# sysctl -w kern.securelevel=2

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

Меняем алгоритм шифрования

Заменим алгоритм шифрования паролей с md5 на еще более надежный Blowfish. Делаем исправления в файле /etc/login.conf в секции default:

Код:

// заменяем алгоритм шифрования на Blowfish



:passwd_format=blf:\



// устанавливаем период устаревания паролей



:passwordtime=52d:\



// предупреждаем о том, что пароли должны содержать разные символы



:mixpasswordcase=true:\



// задаем минимальную длину пароля



:minpasswordlen=9:\



Теперь обновляем базу (login.conf.db):



# cap_mkdb /etc/login.conf

Проверим, получилось ли у нас. Посмотри содержимое /etc/master.passwd. Если зашифрованный пароль теперь начинается с "$2", все ОК. Осталось сделать так, чтобы пароли новых пользователей шифровались алгоритмом Blowfish. Редактируем файл /etc/auth.conf:

crypt_default=blf

Шифруем файловую систему

Файлы, которые могут представлять интерес для взломщиков, надежнее всего зашифровать. Нет, не думай, что я опять буду рассказывать про PGP. Для создания зашифрованных дисков можно обойтись стандартными средствами FreeBSD - GEOM и BDE. Что такое GEOM? Это новая система работы с дисками, появившаяся в 5-й ветке FreeBSD. Благодаря своей модульной структуре, она позволяет делать с файловой системой все что угодно. Нас интересует один из ее модулей - BDE (block device encryption) - поддержка шифрования файловой системы. Для начала добавим в ядро опцию

options GEOM_BDE

Создадим новый каталог, в котором будут лежать конфиги GBDE:

Код:

# mkdir /etc/gbde



Инициализируем зашифрованный диск:



# gbde init /dev/ad4s1c -i -L /etc/gbde/ad4s1c

Откроется редактор, в котором можно указать различные настройки. Для файловых систем UFS1 и UFS2, используемых в FreeBSD, следует указать значение переменной sector_size равным 2048. Не забудь выбрать хороший пароль для доступа к диску. Подключаем диск:

Код:

# gbde attach /dev/ad4s1c -l /etc/gbde/ad4s1c

Система попросит ввести ключевую фразу для доступа к зашифрованному диску. Теперь содержимое этого диска доступно при обращении к файлу устройства /dev/ad4s1c.bde. Создадим на нем новую файловую систему и монтируем его:

Код:

# newfs -U -O2 /dev/ad4s1c.bde



# mount /dev/ad4s1c.bde /mnt

Теперь можно работать с содержимым зашифрованного диска. Обрати внимание, что скорость файловых операций с зашифрованными разделами почти в 4 раза ниже, чем при работе с обычными дисками. Если ты пользуешься утилитой sysinstall, имей в виду, что она несовместима с зашифрованными разделами и их нужно отключать перед запуском этой утилиты. Также заметь, что зашифрованные диски невозможно подключать автоматически из /etc/fstab, потому не стоит применять шифрование к системным разделам (/, /usr, /var).
По окончании работы с зашифрованным разделом размонтируем устройство и отключим шифрованный диск:

Код:

# umount /dev/ad4s1c.bde



# gbde detach /dev/ad4s1c

IP-протоколы

Теперь займемся защитой от атак, связанных с недостатками протокола TCP/IP. Начнем с фильтрации SYNFIN-пакетов. Это TCP-пакеты с одновременно установленными флагами начала и завершения соединения, пользы от них практически никакой, зато они часто используются при хакерских атаках. Одновременно займемся ICMP-протоколом и включим в ядро еще парочку полезных опций:

Код:

// ох уж эти SYNFIN-пакеты



options TCP_DROP_SYNFIN



// ограничиваем количество ICMP-ответов, что помогает при защите от DoS атак



options ICMP_BANDLIM



// генерируем случайный идентификатор IP-пакетов



options RANDOM_IP_ID



// блокируем RST-пакеты



options TCP_RESTRICT_RST



Но этого еще недостаточно, добавляем в /etc/rc.conf:



// отбрасываем SYNFIN-пакеты



tcp_drop_synfin="YES"



// отключаем прием и отправку переадресовывающих ICMP-пакетов



icmp_drop_redirect="YES"



// в системном журнале регистрируем переадресовывающие ICMP-пакеты



icmp_log_redirect="YES"



// предотвращаем springboarding и smurf-атаки



icmp_bmcastecho="NO"



Далее прописываем в /etc/sysctl.conf строчки



net.inet.tcp.blackhole=2



net.inet.udp.blackhole=1

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

Огненная стена

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

Код:

options IPFIREWALL



options IPFIREWALL_VERBOSE



После чего добавить в /etc/rc.conf строки



firewall_enable="YES"



firewall_type="open"

Однако тип файрвола "open" подходит для чего угодно, но только не для защищенного сервера. Поэтому для более надежной защиты можно выбрать одну из стандартных конфигураций:

Код:

// защита только сервера



firewall_type="client"



// защита сервера и локальной сети



firewall_type="simple"

или же написать свой файл с правилами файрвола. Немного разберемся с созданием правил. Общий формат правила ipfw такой:

<действие> <протокол> from <откуда> to <куда> <дополнительные условия>

В качестве выполняемого действия файрвол может разрешить (allow, pass, accept, permit) прохождение пакета или запретить (deny, drop, reject) его, а также посчитать (count), перенаправить по нужному адресу (fwd, forward) или другой программе (divert). Протоколы могут быть ip или all (для всех протоколов стека TCP/IP), а также tcp, udp, icmp и т.п.

Формат поля источника (from) и приемника (to) пакета может быть записан в различных формах: доменное имя, ip-адрес, подсеть в формате IP:MASK (192.168.1.0:255.255.255.0) или IP/LENGTH (192.168.1.0/24), а также в виде специального слова any (любой адрес) или me (все адреса локальной машины). Для tcp и udp протокола после адреса источника или приемника можно через пробел указать еще и порт. И, наконец, из дополнительных условий самыми полезными являются направление пакета (in или out - входящий и исходящий соответственно), интерфейс, через который будет проходить пакет (например, via fxp0), и даже идентификатор пользователя (uid) или группы (gid), для которых это правило будет работать. Теперь не составит труда разобраться, что правило deny tcp from any to 192.168.1.0/24 in via fxp0

запрещает прохождение любых входящих tcp-пакетов через интерфейс fxp0 к сети 192.168.1.0/24, а правило

count ip from 192.168.1.0/24 to me uid 1001

будет вести учет трафика, который получит из сети 192.168.1.0/24 пользователь с UID, равным 1001.

Каждое правило файрвола должно иметь свой уникальный номер. Правила проверяются в порядке возрастания своих номеров. Для управления файрволом существует команда ipfw. Чтобы добавить правило, воспользуйся командой

Код:

# ipfw add <номер> <правило> 



а чтобы его удалить:



# ipfw delete <номер>

Для просмотра списка правил есть команда ipfw list, а ipfw show покажет трафик и количество пакетов, обработанных каждым из правил. В качестве примера для настройки файрвола можно посмотреть файл /etc/rc.firewall, а также ознакомиться с руководством по ipfw. Напоследок добавим в /etc/rc.conf строчку

log_in_vain="YES"

Теперь все попытки подключения к закрытым портам твоего сервера будут занесены в логи.

Демонов - под контроль

Не ко всем службам, запущенным на твоем сервере, стоит давать доступ. Если заблокировать доступ к отдельным портам можно с помощью правильной настройки файрвола, то доступ к службам проще ограничить с помощью файла /etc/hosts.allow. Для примера ограничим доступ по ssh только несколькими сетями:

Код:

# vi /etc/hosts.allow



sshd : localhost : allow 



sshd : 192.168.1. : allow



sshd : 10.1.1.0/255.255.255.240 : allow



sshd : ALL : deny

Формат файла, как видишь, достаточно простой. Сначала мы указываем имя службы, затем имя или адрес хоста или сети, затем действие. Правило ALL указывает, как поступать в случаях, не предусмотренных предыдущими правилами.

Теперь займемся демоном inetd, который играет весьма важную роль в обеспечении безопасности системы. Через него работают telnetd, ftpd, talk и прочие службы. Если никакие из демонов, запускаемых из inetd, тебе не нужны, отключи его. Для этого надо указать в /etc/rc.conf:

inetd_enable="NO"

Если тебе все же нужен inetd и службы, которые запускаются из него, то стоит включить протоколирование событий и при большой нагрузке увеличить количество одновременных обращений к inetd (по умолчанию это число равно 256). Для этого добавь в /etc/rc.conf строчку

inetd_flags="-l -R 1024"

Последние штрихи

Вот мы и закончили, все изменения в конфигурационные файлы внесены, настройки сделаны. Осталось пересобрать ядро и перезагрузить систему. Посмотрим, чего мы добились.
$ netstat -na | grep LISTEN

Эта команда покажет нам, на каких портах висят сервисы. Чем их меньше, тем лучше. Также попробуй просканить свою машину nmap'ом. Итак, теперь твоя система намного более защищена, чем раньше. Не забывай регулярно обновлять ее и следить за логами. Удачи!

Система безопасности TrustedBSD MAC

В FreeBSD 5 появилась новая система безопасности ядра, TrustedBSD MAC Framework. MAC расшифровывается как Mandatory Access Control - принудительный контроль доступа. Система MAC с помощью установки так называемых меток на различные компоненты системы ограничивает доступ к ним на основе созданных администратором политик. Например, с помощью MAC вполне реально создать систему контроля доступа к файловой системе, аналогичной файрволу ipfw, разграничить видимость процессов и многое другое. Если тебя заинтересовала эта тема, обратись к соответствующему разделу FreeBSD HandBook, а также страницам руководства (man 4 mac).

DANGER

Используй SSH для удаленного управления сервером, иначе никакие рекомендации по безопасности тебе не помогут. Никогда не пользуйся telnet для удаленного доступа.

WWW

www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/security.html

www.freebsd.org/security/security.html

www.watson.org/fbsd-hardening/

www.antioffline.com/deviation/bsd.html

defcon1.org/html/Security/Secure-Guide/secure-guide.html

Статья неплохая и весьма полезная. Только в ней автор не рассматривает вопросы, связанные с защитой вэб-сервера apache, php, mysql, ftp...
Предлагаю вашему вниманию статью, в которой рассмотрены именно эти вопросы, в числе прочих:

Автор: Raven2000.

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

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

Защиту разделим по двум видам:
I) Защита от внешних атак
II) Защита от внутренних атак

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

Теперь определим фронт защиты:

I) Атака извне:
1.1) Apache - http.conf + mod_security
1.2) PHP - php.ini + mod_security + отключение опасных функций + Ограничения ресурсов
1.3) FTP – Разделение привилегий + chroot + квоты + отдельный HDD
1.4) Firewall – грамотно настроенный фаервол
1.5) Сhroot

II) Атака внутри:
2.1) Ограничения ресурсов - /etc/login.conf + /etc/sysctl.conf
2.2) Разделение привилегий - /etc/sysctl.conf + chmod + структура папок
2.3) Логии (logcheck)
2.4) top/ps

III) Общие меры
3.1) Разбор fstab
3.2) Доступ к серверу
3.3) DNS – chroot + noroot

Теперь пройдем по пунктам (некоторые пункты будут вкратце описаны т.к. обший принцип
защиты пересекается с другими пунктами) как и чем можно защитить и ограничить:

I) Прикрытие внешних дыр.

1.1) Apache + виртуальные хосты + mod_security
Прикроем дырки этого сервиса для начала нам необходимо задать ограничения
в конфиге для каждого вхоста. Добавляем следующие параметры:

Код:

<IfModule mod_php4.c>

# Включаем Safe mode

php_admin_flag safe_mode on

php_admin_flag safe_mode_gid on

php_admin_value open_basedir /home/domain.ru

# Папка, выше которой скрипт не может видеть

php_admin_value safe_mode_exec_dir /home/domain.ru

# Temp диры юзера 

php_admin_value upload_tmp_dir /home/domain.ru/tmp

# Не начинать PHP сессию автоматически

php_admin_flag session.auto_start off

# Где сохранять файлы сессий

php_admin_value session.save_path /home/domain.ru/tmp

</IfModule>

Как известно, немалая часть взломов (SQL Injection, XSS атаки, инклюдинг) происходит
по сути посредством хитрого HTTP запроса. Логично предположить, что эти самые
запросы неплохо было бы фильтровать. Решение проблемы существует в виде модуля к
Апачу, и называется оно mod_security. Ставим:

Код:

# cd /usr/ports/www/mod_security/ && make install clean

После установки – идем конфигурировать. Открываем любой конфиг виртуального хоста,
например 001.admin.hosting.ru, над которым мы уже экспериментировали. Все значения
надо вводить между тегами <Virtualhost *:80> и </Virtualhost>.

Код:

# Включаем mod_security

SecFilterEngine On

# Проверяем запросы

SecFilterScanPOST On

# Проверяем ответы

SecFilterScanOutput On

# Проверяем, правильно ли закодирован URL

SecFilterCheckURLEncoding On

# Включаем этот параметр, если сайт в Unicode

SecFilterCheckUnicodeEncoding Off

# Задаем диапазон байтов

SecFilterForceByteRange 1 255

# Сохраняем в лог только срабатывания механизма

SecAuditEngine RelevantOnly

# Где живет лог :)

SecAuditLog logs/audit_log

# Возвращаем ошибку 500 при срабатывании

SecFilterDefaultAction "deny,log,status:500"

# Перекрываем dots-bug

SecFilter "\.\./"

# Не забываем про XSS

SecFilter "<(.|\n)+>"

# SQL injection, куда же без него :)

SecFilter "<[[:space:]]*script"

SecFilter "delete[[:space:]]+from"

SecFilter "insert[[:space:]]+into"

SecFilter "select.+from"

# Перекрываем возможность передачи переменных PHP

SecFilterSelective ARG_b2inc "!^$"

# Исключаем возможность раскрытия пути

SecFilterSelective OUTPUT "Fatal error:"

Для и для apache 1.x в httpd.conf закоментите:

Код:

#SecFilterScanOutput

#OUTPUT

#OUTPUT_STATUS

У этого модуля – на редкость удачная дефолтная конфигурация. К ней мало, что можно
добавить, так как большинство настроек – специфичны. Общий принцип составления
правил мы рассмотрели, а остальное можно добавить по своему усмотрению.

1.2) PHP
В дополнение смотри пункт – 2.1
Рассмотрим самое уязвимое место хостинговой системы – выполняемые файлы, в частности,
PHP скрипты. Открываем конфиг PHP:

Код:

# ee /usr/local/etc/php.ini

Меняем следующие параметры:

Код:

magic_quotes_gpc = Off                            # Экранирование спецсимволов

disable_functions = system, exec, passthru  # Выключаем опасные функции:

Выключить эти функции очень важно. Хоть они и недоступны при включенном safe mode,
пользователь может без труда провести успешную атаку, указав в файле .htaccess:

Код:

php_flag safe_mode off

1.3) FTP
Настройка Proftpd установите далее по разделение привилегий смотрим -2.1
в котором я указал то что вам нужно, а по Chroot см раздел 1.5 Желательно ftp
ставить на отдельный HDD чтобы непроизошло переполнения раздела и все
шайтан майфун :) а если у вас он на /etc или /var находился все хана логам и тд :)

1.4) IPFW - штатный файрволл FreeBSD

1.5) Chroot
Chroot - песочница это конечно с одной стороны хорошо с другой – потеря
производительности, для некоторых программ лишний дополнительный
модуль + конфиг к нему. Я считаю грамотный chmod дает тот же результат , но без
заморочек и потерь ресурсов. В основном к chroot прибегают, когда нужно обезопасить
сервис, который не совсем безопасный как например BIND(о нем ниже).
Jail - мы не будем это рассматривать ось внутри оси довольно заморочено и плохо
документировано, а если все вхосты придется загонять в jail то мало непокажется.
Я пока небуду jail рассматривать :)

II) Настраиваем тыл внутренние защитные меры.

2.1) Ограничения ресурсов
Бывает так кроме основного действия PHP скрипта функция N зацикливается, попутно
вычисляя некое сложное действие. Как результат – высокая загрузка процессора.
Это очень типичная ситуация для хостинга. Чтобы предотвратить подобные ненамеренные
(и намеренные) атаки, необходимо ограничивать юзера в плане ресурсов. У *BSD для
таких целей существует система профилей пользователей. Это значит, что мы можем
легко ограничить ресурсы каждого пользователя в отдельности.
Открываем /etc/login.conf и добавляем:

Код:

# Имя профиля

hosting: \

:copyright=/etc/COPYRIGHT: \

:welcome=/etc/motd: \

:setenv=MAIL=/var/mail/$,BLOCKSIZE=K: \

:path=~/bin /bin /usr/bin /usr/local/bin: \

:manpath=/usr/share/man /usr/local/man: \

:nologin=/var/run/nologin: \      

# Мах время использования процессора

:cputime=1h30m: \

# Мах кол-во памяти, выделяемой программе под данные

# Сам код программы и стэк не учитываются

:datasize=10M: \

# Сколько выделяем для стека программы

:stacksize=3M: \

# Мах размер физической памяти, выделяемой процессу

:memoryuse=16M: \

# Мах размер файла

:filesize=50M: \

# Мах размер core файлов

:coredumpsize=1M: \

# Сколько файлов может открывать каждый процесс

:openfiles=128: \

# Сколько процессов может запускать пользователь

:maxproc=64: \

# Пускать юзера в систему только если его домашняя дира существует и доступна юзеру

:requirehome:true \

# Время устаревания пароля

:passwordtime=90d: \

# Остальное берем из профиля default             

:tc=default:

Здесь я указал лишь основные параметры.
Список всех параметров и их описание можно найти в Handbook.
Теперь перейдем к настройке операционки. Открываем /etc/sysctl.conf и пишем туда
следующее:

Код:

# Запрещает юзерам видеть процессы соседа&root

security.bsd.see_other_uids=0

# Запрещает видеть групповые процессы

security.bsd.see_other_gids=0

# Пускаем запросы на закрытые порты в черные дыры

net.inet.tcp.blackhole=2

net.inet.udp.blackhole=1

# Указываем размер очереди сокета

kern.ipc.somaxconn=1024

# Отрубаем ip-редиректы

net.inet.icmp.drop_redirect=1

net.inet.icmp.log_redirect=1

net.inet.ip.redirect=0



# Назначаем размеры буфера для TCP-подключений. Если на сервер ожидается большая 

# нагрузка, и у него много памяти – лучше поставить 65535. Значение выше 65535 

# не рекомендуется.

net.inet.tcp.sendspace=32768

net.inet.tcp.recvspace=32768

# Обновляем ARP-таблицу каждые 20 минут

net.link.ether.inet.max_age=1200

# Запрещаем отвечать на все лишние запросы.

net.inet.icmp.maskrepl=0

net.inet.ip.sourceroute=0

net.inet.ip.accept_sourceroute=0

net.inet.icmp.bmcastecho=0

Здесь указаны не все параметры sysctl остальные смотрим MAN SYSCTL(8)
Есть статья Некоторые опции sysctl но она еще не совсем дописана (просьба просить lissyara чтобы доконца перевел ;)).
Многие параметры для sysctl можно изменять и динамически:

Код:

sysctl <параметр>=<значение>

Например:

Код:

sysctl kern.maxprocperuid=1000

Должно быть похоже на

# sysctl kern.maxprocperuid=1000
kern.maxprocperuid: 3546 -> 1000

Теперь необходимо продублировать часть настроек в /etc/rc.conf:
Дублируем настройки sysctl

Код:

icmp_drop_redirect="YES"

icmp_log_redirect="YES"

icmp_bmcastecho="NO"

tcp_drop_synfin="YES"

2.3) Логи
Очень важным аспектом системного администрирования является слежение за сервера.
Но ковырять логии самому заморочено тогда для ленивых существует отличная утилита
logcheck ее и поставим.

Код:

# cd /usr/ports/security/logcheck && make install clean

Утилита написана на sh скриптах, и занимает всего 29 Кб в архиве. После установки
в /usr/local/etc у вас появятся четыре конфига: переименуй их,
убрав из названия файла «sample»:

Код:

logcheck.hacking – о каких странностях сообщать;

logcheck.violations – о каких попытках взлома сообщать;

logcheck.ignore – какие странности игнорировать;

logcheck.violations.ignore – какие попытки взлома игнорировать.

В целом и общем, первый файл от второго ничем не отличается, равно как и третий
от четвертого :).Просто разработчики скрипта решили разнести сообщения о подозрительной
активности и сообщения о явной атаке в разные конфиги.

Запускаем скрипт по крону, хотя бы раз в сутки. Дописываем в cron:

Код:

0 4 * * * /bin/sh /usr/local/etc/logcheck.sh

При большой активности хостящихся сайтов, логи веб-сервера начнут
занимать немало места. И в то же время их надо сохранять.
Можно использовать утилиту logrotate

Код:

# /usr/ports/sysutils/logrotate && make install clean

III) Общие меры

3.1) HDD
Сделаем в fstab некоторые изменения для предотвращения нехороших действий.
Укажем где и что можно и нельзя делать системе.

Код:

/dev/ad4s3b                none                swap        sw                        0 0

/dev/ad4s3a                /                ufs        rw                        1 1

/dev/ad4s3e                /tmp                ufs        rw,noexec                2 2

/dev/ad4s3f                /usr                ufs        rw                        2 2

/dev/ad4s3f                /usr/home        ufs        rw,nosuid,nodev                2 2

/dev/ad4s3d                /var                ufs        rw,nodev                2 2

noexec – эта опция дает понять что на данном разделе запрещено запускать что
либо даже правах на файл chmod 777 (Я знаю что некоторые защищенные сервера ломали
именно через /tmp :) в последствии админы советовали прикрывать эту дыру.
И незабываем, что в /tmp может писать почти любой сервис в системе)

nosuid – при этом значении система игнорирует suid-биты. Юзер не сможет сделать
#su и подняться до рута, даже если он знает его пароль рута и находится в группе
wheel (но необходимо понять что нужным юзверям которым нужно #su домашняя директория
будет /usr, а тем кого нужно ограничит директория будет /usr/home)

nodev – запрещаем создание\существование в данном разделе специальных устройств.

3.2) Доступ
Доступ к серверу следует ограничить. Т.е. серверы убрать в недоступное простым
смертным людям и закрыть на ключ. В дополнение не забываем, снять с них все причиндалы
мониторы клавы мышки и т.д. Для чего это должно быть понятно, например если я вижу
общедоступный \ физически сервер FreeBSD я тут же по любопытности хочу в него залезть
и поковыряться в нем. Но вы скажете, а как же пароль root и т.д. то слушаем дальше,
если вы забыли чужой пароль :) а так бывает то делаем так:

А) Загружаемся в однопользовательском режиме , для этого в приглашении загрузчика
введите boot –s
Б) Смонтируйте командой mount –u / корневой раздел в режим чтения-записи.
Затем с помощью mount –a примонтируем все что есть (т.е. только что указанно
в fstab без опции noauto)
B) Теперь меняйте пароль рута. :)

Чтобы люди не cмогли зайти без пароля рута в однопользовательском режиме делаем так:

Код:

# ee /etc/ttys

Измените в строчке console пункт secure на insecure. Если вы сделаете это,
FreeBSD даже при загрузке в однопользовательском режиме будет запрашивать пароль root.
Будьте осторожны при изменении этого значения на insecure. Если вы забудете пароль
root, загрузка в однопользовательский режим сильно усложнится.
Это все еще возможно, но несколько более сложно.

Код:

# name  getty                           type    status          comments

#

# If console is marked "insecure", then init will ask for the root password

# when going to single-user mode.

console none                            unknown off insecure

3.3) DNS
Засунем DNS в песочницу

Код:

# named –u 53 –t /var/named

-u – значение UID присваемое процессу named
-t – указывает корневой каталог для демона
Незабываем, что корневой каталог недолжен, быть пустым, он должен содержать все файлы
необходимые для нормальной работы демона. Если named скомпилирован так чтобы
библиотеки компоновались статически и не нужно было думать что ему надо еще в корневую
положить чтобы он запустился :) Так же некоторые советуют в конфиге DNS убрать строчку
об версии демона дескать оно сможет помочь атакующему и т.д. я не считаю это критически
она может подсказкой и самому админу.

Литература:
1) Unix руководство системного администратора (3 изд.)
2) Хакер спец 07/68/июль/2006
3) Жизнь :)

Статья взята отсюда: _http://www.lissyara.su/?id=1450