Делаем FreeBSD безопасной Сергей Можайский aka techniX Xakep, номер #069, стр. 069-116-1 ([email protected]) FreeBSD: Top Security Итак, ты решил построить сервер на базе FreeBSD. Хороший выбор. Однако любой сервер является лакомым кусочком для хакера, и даже не стоит сомневаться в том, что рано или поздно он подвергнется атаке. Поэтому в первую очередь стоит заняться не настройкой различных сервисов, а защитой системы от взлома. Конечно, в системе, установленной с настройками по умолчанию, защита находится на достаточном уровне. Однако мы можем сделать наш сервер настоящим крепким орешком. Ну что, начнем строить защиту своей FreeBSD-системы? Консольные твики Как известно, загрузившись в однопользовательском режиме, можно изменить пароль суперпользователя. Нам следует устранить эту досадную недоработку. Отредактируем файл /etc/ttys таким образом, чтобы при загрузке с опцией boot -s система запрашивала пароль Code: console none unknown off insecure Также следует запретить прямой вход с консоли пользователя root. Для этого в том же файле нужно сменить статус консоли на insecure. Вот пример для нулевой консоли: Code: ttyv0 "/usr/libexec/getty Pc" cons25 on insecure Для того чтобы только пользователь root мог видеть все запущенные процессы, добавь в /etc/sysctl.conf следующую запись: Code: kern.ps_showallprocs=0 Ваши права? Права доступа к файлам - одна из отличительных особенностей UNIX-систем. Давай назначим эти права как следует. На некоторые системные файлы стоит установить такие флаги доступа, чтобы они были доступны только суперпользователю. Вот примерный список: Code: # 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 строки Code: kern_securelevel_enable="YES" kern_securelevel="2" Текущий уровень защиты можно посмотреть командой $ sysctl kern.securelevel А повысить его без перезагрузки - Code: # sysctl -w kern.securelevel=2 Отмечу, что при уровне защиты 1 или выше пересобрать userland и ядро тебе не удастся, поскольку на важных системных файлах стоят модификационные флаги. Меняем алгоритм шифрования Заменим алгоритм шифрования паролей с md5 на еще более надежный Blowfish. Делаем исправления в файле /etc/login.conf в секции default: Code: // заменяем алгоритм шифрования на 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: Code: # mkdir /etc/gbde Инициализируем зашифрованный диск: # gbde init /dev/ad4s1c -i -L /etc/gbde/ad4s1c Откроется редактор, в котором можно указать различные настройки. Для файловых систем UFS1 и UFS2, используемых в FreeBSD, следует указать значение переменной sector_size равным 2048. Не забудь выбрать хороший пароль для доступа к диску. Подключаем диск: Code: # gbde attach /dev/ad4s1c -l /etc/gbde/ad4s1c Система попросит ввести ключевую фразу для доступа к зашифрованному диску. Теперь содержимое этого диска доступно при обращении к файлу устройства /dev/ad4s1c.bde. Создадим на нем новую файловую систему и монтируем его: Code: # newfs -U -O2 /dev/ad4s1c.bde # mount /dev/ad4s1c.bde /mnt Теперь можно работать с содержимым зашифрованного диска. Обрати внимание, что скорость файловых операций с зашифрованными разделами почти в 4 раза ниже, чем при работе с обычными дисками. Если ты пользуешься утилитой sysinstall, имей в виду, что она несовместима с зашифрованными разделами и их нужно отключать перед запуском этой утилиты. Также заметь, что зашифрованные диски невозможно подключать автоматически из /etc/fstab, потому не стоит применять шифрование к системным разделам (/, /usr, /var). По окончании работы с зашифрованным разделом размонтируем устройство и отключим шифрованный диск: Code: # umount /dev/ad4s1c.bde # gbde detach /dev/ad4s1c IP-протоколы Теперь займемся защитой от атак, связанных с недостатками протокола TCP/IP. Начнем с фильтрации SYNFIN-пакетов. Это TCP-пакеты с одновременно установленными флагами начала и завершения соединения, пользы от них практически никакой, зато они часто используются при хакерских атаках. Одновременно займемся ICMP-протоколом и включим в ядро еще парочку полезных опций: Code: // ох уж эти 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 позволит нам фильтровать пакеты по заданным критериям и вести учет. Для того чтобы включить файрвол, нужно добавить в ядро вот эти опции: Code: options IPFIREWALL options IPFIREWALL_VERBOSE После чего добавить в /etc/rc.conf строки firewall_enable="YES" firewall_type="open" Однако тип файрвола "open" подходит для чего угодно, но только не для защищенного сервера. Поэтому для более надежной защиты можно выбрать одну из стандартных конфигураций: Code: // защита только сервера 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. Чтобы добавить правило, воспользуйся командой Code: # ipfw add <номер> <правило> а чтобы его удалить: # ipfw delete <номер> Для просмотра списка правил есть команда ipfw list, а ipfw show покажет трафик и количество пакетов, обработанных каждым из правил. В качестве примера для настройки файрвола можно посмотреть файл /etc/rc.firewall, а также ознакомиться с руководством по ipfw. Напоследок добавим в /etc/rc.conf строчку log_in_vain="YES" Теперь все попытки подключения к закрытым портам твоего сервера будут занесены в логи. Демонов - под контроль Не ко всем службам, запущенным на твоем сервере, стоит давать доступ. Если заблокировать доступ к отдельным портам можно с помощью правильной настройки файрвола, то доступ к службам проще ограничить с помощью файла /etc/hosts.allow. Для примера ограничим доступ по ssh только несколькими сетями: Code: # 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
Полезная статья. Хотя к сожалению автор не проверял вживую то, о чем написал ибо советует использовать две в принципе не совместимые настройки: в разделе "Демонов - под контроль" - автор рекомендует использовать hosts.allow для ограничения доступа к отдельным службам... после чего автор благополучно отключает inetd (без оговорок того, что hosts.allow при выключенном inetd - РАБОТАТЬ НЕ БУДЕТ) В остальном все очень даже ничего. Хотя можно добавить в раздел сетевой защиты: net.inet.udp.blackhole=1 - отбрасывать пакеты для закрытых портов В rc.conf - log_in_vain="YES" - я бы включил только при условии что есть ограничение на размер логг файла - ибо в противном случае - эта строчка создает предпосылку Dos путем переполнения log. (Как возможный вариант решения ядро собираем с options IPFIREWALL_VERBOSE_LIMIT=100)
Жалко у меня сцуки домен отобрали, я бы вам ссылку на статью по безопасности на фрихи скинул бы, там побольше будет
Может просто внимательно прочитать прежде чем делать выводы? Если никакие из демонов, запускаемых из inetd, тебе не нужны, отключи его.
Слава Богу внимательно. Да есть такая фраза. все правильно. Но логика здесь в другом. Фраза скорее показывает возможности работы inetd "Если никакие из демонов, запускаемых из inetd, тебе не нужны, отключи его" НО никак НЕ связь с работой TCP Wrappers и это факт (если только косвенно - Но это извините понятно только тем, кто на практике делал чтото подобное, но не широкому кругу интересующихся людей. (а статья то в основном для тех кто учится - поправте если ошибаюсь и рассчитана а не только на таких как я - который сможет откритиковать и такого как Вы - который подобное описание сочтет нормальным - извиняйте но такие пошаговые руководства прсто требуют подобных уточнений! ). Еще раз спасибо автору за попытку собрать все воедино.
Статья неплохая и весьма полезная. Только в ней автор не рассматривает вопросы, связанные с защитой вэб-сервера 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 Прикроем дырки этого сервиса для начала нам необходимо задать ограничения в конфиге для каждого вхоста. Добавляем следующие параметры: Code: <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. Ставим: Code: # cd /usr/ports/www/mod_security/ && make install clean После установки – идем конфигурировать. Открываем любой конфиг виртуального хоста, например 001.admin.hosting.ru, над которым мы уже экспериментировали. Все значения надо вводить между тегами <Virtualhost *:80> и </Virtualhost>. Code: # Включаем 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 закоментите: Code: #SecFilterScanOutput #OUTPUT #OUTPUT_STATUS У этого модуля – на редкость удачная дефолтная конфигурация. К ней мало, что можно добавить, так как большинство настроек – специфичны. Общий принцип составления правил мы рассмотрели, а остальное можно добавить по своему усмотрению. 1.2) PHP В дополнение смотри пункт – 2.1 Рассмотрим самое уязвимое место хостинговой системы – выполняемые файлы, в частности, PHP скрипты. Открываем конфиг PHP: Code: # ee /usr/local/etc/php.ini Меняем следующие параметры: Code: magic_quotes_gpc = Off # Экранирование спецсимволов disable_functions = system, exec, passthru # Выключаем опасные функции: Выключить эти функции очень важно. Хоть они и недоступны при включенном safe mode, пользователь может без труда провести успешную атаку, указав в файле .htaccess: Code: 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 и добавляем: Code: # Имя профиля 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 и пишем туда следующее: Code: # Запрещает юзерам видеть процессы соседа&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 можно изменять и динамически: Code: sysctl <параметр>=<значение> Например: Code: sysctl kern.maxprocperuid=1000 Должно быть похоже на # sysctl kern.maxprocperuid=1000 kern.maxprocperuid: 3546 -> 1000 Теперь необходимо продублировать часть настроек в /etc/rc.conf: Дублируем настройки sysctl Code: icmp_drop_redirect="YES" icmp_log_redirect="YES" icmp_bmcastecho="NO" tcp_drop_synfin="YES" 2.3) Логи Очень важным аспектом системного администрирования является слежение за сервера. Но ковырять логии самому заморочено тогда для ленивых существует отличная утилита logcheck ее и поставим. Code: # cd /usr/ports/security/logcheck && make install clean Утилита написана на sh скриптах, и занимает всего 29 Кб в архиве. После установки в /usr/local/etc у вас появятся четыре конфига: переименуй их, убрав из названия файла «sample»: Code: logcheck.hacking – о каких странностях сообщать; logcheck.violations – о каких попытках взлома сообщать; logcheck.ignore – какие странности игнорировать; logcheck.violations.ignore – какие попытки взлома игнорировать. В целом и общем, первый файл от второго ничем не отличается, равно как и третий от четвертого .Просто разработчики скрипта решили разнести сообщения о подозрительной активности и сообщения о явной атаке в разные конфиги. Запускаем скрипт по крону, хотя бы раз в сутки. Дописываем в cron: Code: 0 4 * * * /bin/sh /usr/local/etc/logcheck.sh При большой активности хостящихся сайтов, логи веб-сервера начнут занимать немало места. И в то же время их надо сохранять. Можно использовать утилиту logrotate Code: # /usr/ports/sysutils/logrotate && make install clean III) Общие меры 3.1) HDD Сделаем в fstab некоторые изменения для предотвращения нехороших действий. Укажем где и что можно и нельзя делать системе. Code: /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могли зайти без пароля рута в однопользовательском режиме делаем так: Code: # ee /etc/ttys Измените в строчке console пункт secure на insecure. Если вы сделаете это, FreeBSD даже при загрузке в однопользовательском режиме будет запрашивать пароль root. Будьте осторожны при изменении этого значения на insecure. Если вы забудете пароль root, загрузка в однопользовательский режим сильно усложнится. Это все еще возможно, но несколько более сложно. Code: # 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 в песочницу Code: # 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
Автор пишет: "Меняем следующие параметры: Код: magic_quotes_gpc = Off" Может я ошибаюсь, но помоему magic_quotes_gpc =On - противодействует sql ИНЪЕКЦИЯМ. экранируя слеши, кавычки и ядовитые нули. Поправте если ошибаюсь.
Да, происходит экранирование всех данных, т.е. там, где это нужно и там, где это совсем не нужно... и как следствие - потеря производительности. Сам разработчик php рекомендует отключать эту директиву: Code: Волшебные кавычки (Magic Quotes) - это процесс автоматического экранирования входящих данных PHP скрипта. Желательно отключать директиву magic quotes и вместо этого экранировать данные в процессе разработки, если это необходимо. В php есть файл php.ini-recommended(рекомендуемые разработчиком настройки), в котором директива magic_quotes_gpc отключена Code: [B]Переносимость.[/B] Возможность присваивания значений on или off сказывается на переносимости. Используйте get_magic_quotes_gpc() для проверки и пишите код соответствующим образом. [B]Производительность.[/B] Так как не все данные заносятся в базу данных, то присутствует потеря производительности при экранировании всех данных. Простой вызов экранирующих функций (например, addslashes()) во время выполнения более эффективен. Хотя php.ini-dist включает эти директивы по умолчанию, php.ini-recommended отключает их. Эта рекомендация соответствует, в основном, по причинам производительности. [B]Неудобство.[/B] Так как не все данные должны быть экранированы, то часто досадно видеть экранированные данные там, где этого не должно быть. Например, при отправке письма из формы можно наблюдать связку \' в самом письме. Для того, чтобы это исправить, требуется дополнительно использовать stripslashes(). _http://ru.php.net/magic_quotes
