Защита офиса нефтегазовой корпорации

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

Межсетевой обмен

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

Определение периметра

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

Точка риска

Этот термин был выбран вместо точки атаки, так как последняя предполагает преступную деятельность с другой стороны соединения. Компрометация или искажение информации часто не являются результатом преступной деятельности, хотя результат может оказаться таким же. Модем, присоединенный к сетевому узлу, представляет собой точку риска, если отвечает на телефонные звонки и предоставляет возможность соединения удаленному пользователю. Фактически, если такой модем присоединен к сети, то есть меняет свой статус и становится интернетом. В каждой точке доступа к интернету должно быть реализовано управление доступом, независимо от того, является ли она соединением с интернетом или модемом.

Управление доступом

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

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

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

Обмен данными

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

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

Аутентификация

Этот вопрос упоминается несколько раз при описании политики, так как он играет большую роль в каждой области, в которой он упоминается. Аутентификация в точке риска между интернетами - это первый шаг по управлению доступом к информационным ценностям с другой стороны точки риска. Если уровень привилегий обоих сторон одинаков, то можно реализовать обычные механизмы аутентификации. Примерами не столь сильных технологий является использование r-команд Unixа, с помощью которых два узла доверяют друг другу с помощью взаимной верификации на основе идентификатора пользователя и узла; традиционные идентификатор пользователя и пароль тоже не очень сильная технология, так как она уязвима к компрометации неосторожным пользователем. Более сильные технологии включают процессы, которые менее уязвимы к компрометации. Это могут быть одноразовые пароли, которые никогда не используются снова. Одноразовые пароли могут генерироваться программой и печататься на листах бумаги или они могут генерироваться смарт-картами на основе текущего времени и даты, случайных чисел, или других методов, приводящих к получению уникального пароля. Усиленная аутентификация может быть реализована с помощью технологии запрос-ответ. В этом случае аутентифицирующейся сущности дается случайное число-запрос, которое она должна зашифровать и отослать зашифрованный результат.

Сервер аутентификации

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

Доступ к Интернету

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

Разрешенные службы

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

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

Корпорация поддерживает Службу Доменных Имен Интернет. Ни при каких обстоятельствах Корпорация не будет разрешать зональные передачи списков имен узлов Корпорации, кроме случаев, когда доверенный вторичный сервер имен запрашивает зональную передачу; сервера имен Корпорации всегда будут отвечать на UDP-запросы имен.

Администраторы безопасности отвечают за принятие решения в отношении допустимости обмена узлов Корпорации сообщениями по протоколу ICMP с другими узлами Интернета. Кроме того, они отвечают за принятие решения в отношении допустимости команды traceroute на основе протокола UDP в сетях Корпорации и границ допустимости применения этой команды.

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

Подразделения внутри Корпорации могут принять решение сделать некоторую информацию доступной для публичного доступа. Это должно делаться путем создания сервера для WWW и/или анонимного FTP. Администраторы сетевой безопасности должны обеспечить помощь в этом, согласованную с их другими обязанностями по установке таких информационных серверов. Если администраторы безопасности решат поместить сервер за периметром обороны, они должны проконсультироваться с ответственной организацией в отношении процедур, которым надо будет следовать в том случае, если сервер окажется разрушен преступниками за пределами Корпорации. Если сервер нужно установить в одном из интернетов в низкими привилегиями, администраторы безопасности отвечают за гарантию того, что пользователи таких служб не смогут обойти защиту в этих приложениях и получить доступ к информационным ценностям Корпорации.

Программная защита

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

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

FreeBSD пользуется популярностью как стабильная, надежная ОС. Активно поддерживается разработчиком.

Уязвимости в безопасности также могут быстро обнаруживаться командой по безопасности. Когда появляются новые утилиты или возможности ядра пользователю просто надо прочесть один файл (Release Notes, Замечания по релизу), который публично доступен на главной странице веб-сайта FreeBSD.

Безопасность очень важна для Группы подготовки релизов FreeBSD.

· Все инциденты и исправления, связанные с безопасностью проходят через Команду по безопасности и выпускаются, как публично доступные Бюллетени по безопасности (Advisories). Команда по безопасности имеет хорошую репутацию за быстрое решение известных проблем с безопасностью. Полная информация относительно процедур работы с безопасностью во FreeBSD и где искать информацию по безопасности доступна на http://www.FreeBSD.org/security/.

· Одна из проблем, связанная с Open Source программным обеспечением - это точное количество пригодных приложений. Существуют почти что десятки тысяч проектов Open Source приложений, и каждый с различными уровнями ответной реакции на инциденты, связанные с безопасностью. FreeBSD приняла этот вызов вместе с VuXML. Всё программное обеспечение, поставляемое с операционной системой FreeBSD, так же, как и любое программное обеспечение доступное в Коллекции портов сравнивается с базой данных известных, неисправленных уязвимостей. Администратор может использовать portaudit утилиту, чтобы быстро определить, есть ли на FreeBSD системе уязвимое программное обеспечение, и если есть, получить описание проблемы и URL, содержащее более детальное описание уязвимости.

FreeBSD также предоставляет множество механизмов, которые позволяют администратору настраивать операционную систему под его нужды, связанные с безопасностью:

· Утилита jail позволяет администратору ''заключать процесс в тюрьму''; это идеально для приложений, которые не имеют собственного chroot окружения.

· Утилита chflags улучшает безопасность, предлагаемую традиционными Unix разрешениями. Она может, к примеру, предотвратить изменение или удаление указанных файлов даже суперпользователем.

· FreeBSD предлагает 3 встроенных файерволов, предлагая больше возможностей для выбора набора правил наиболее подходящего для нужд безопасности.

· Ядро FreeBSD легко модифицируется, позволяя администратору убирать ненужную функциональность. FreeBSD также имеет поддержку загрузочных модулей ядра и предоставляет утилиты для просмотра, загрузки и выгрузки модулей ядра.

· Механизм sysctl позволяет администратору просматривать и изменять состояние ядра на лету без перезагрузки.

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

Служба информационной безопасности FreeBSD выпускает бюллетени безопасности для нескольких разрабатываемых веток FreeBSD. Это Ветки -STABLE и Ветки Security. (Бюллетени не выпускаются для Ветки -CURRENT.)

· Обычно здесь присутствует только одна ветка -STABLE, хотя в процессе перехода от одной основной линии разработки к другой (например, с FreeBSD 4.x на 5.x) имеется временной интервал, в котором существуют две ветки -STABLE. Тэги ветки -STABLE носят имена типа RELENG_4. Соответствующие версии носят названия типа FreeBSD 4.6-STABLE.

· Каждому релизу FreeBSD поставлена в соответствие ветка безопасности (Security Branch). Метки веток безопасности именуются как RELENG_4_6. Соответствующие построенные версии носят названия типа FreeBSD 4.6-RELEASE-p7.

Каждая ветка поддерживается службой безопасности ограниченное время, обычно до 12 месяцев после релиза. Важно правильно настроить ОС. Без этого, какой бы совершенной она не была, говорить о ИБ преждевременно. Итак, приступим.

Безопасная настройка FreeBSD

В этом разделе приведу некоторые рекомендации, которые помогут настроить наиболее защищенный сервер. Здесь описывается использование некоторых приложений, которые включены в дерево портов FreeBSD, эти приложения помогут сделать сервер еще более защищенным. Также, я опишу использование chrootkit - программа для проверки наличия в системе root-kit-ов. rdate - замена для ntp. cvsup и portupgrade для обновления системы и дерева портов.

1. Инсталяция:

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

Разметка диска будет выглядеть вот так:

none(swap)

/

/tmp

/usr

/usr/home

/var

/root

2. Настройка

Отключаем inetd. В этом случае никто не сможет использовать telnet, rlogin или ftp для доступа к компьютеру.

Отключаем port_map

Откажемся от ntp, вместо этого мы используем rdate, при обновлении будут использоваться ntp-сервера. Установим коллекцию портов, которая будет расположена в /usr/ports

Установим следующие порты

/usr/ports/security/chkrootkit

/usr/ports/security/portaudit

/sysutils/rdate

/sysutils/portupgrade

/net/cvsup-without-gui (я считаю, что на серверах не должно быть графического интерфейса)

Пользователи

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

Создадим группу для пользователей, которые могут иметь удаленный доступ

vi /etc/group

sshusers:*:1001:список пользователей находящихся в этой группе Сохраним файл и выйдем из vi, для этого зажмите кнопку shift и нажмите дважды кнопку zz.

(далее это действие будет обозначаться как ZZ)

4. Сообщение дня

cp /etc/motd /etc/motd.old

rm /etc/motd

vi /etc/motd

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

cp /etc/motd /etc/issue # мы будем использовать motd для показа

# при удаленной регистрации.

# см. также /etc/ssh/sshd_config

5. OpenSSH Мы настроим авторизацию через DSA ключи, без использования паролей. Конечно если кто-то получит доступ к ssh-клиенту с dsa ключами, возникнут проблемы, точно также если кто-то узнает пароль. Используя dsa ключи мы избавляемся от возможности взломать нашу систему путем перебора паролей. Можно использовать dsa-ключи или пароли, но никогда нельзя пользоваться telnet-ом для удаленного доступа.

Secure Shell был разработан как альтернатива rsh, rlogin и других Berkeley r* команд, но SSH можно использовать и вместо таких приложений как telnet и ftp. У SSH много возможностей, но его по большей части используют для шифрования соединения, чтобы не дать возможности подсмотреть текстовые пароли и остальные данные, передаваемые в "чистом виде".

Откроем и отредактируем файл /etc/ssh/sshd_config для настроек параметров демона, к которому обращаются пользователи при удаленном доступе к серверу.

vi /etc/ssh/sshd_config

Port 22

Protocol 2

#Hostkey /etc/ssh/ssh_host_key

PermitRootLogin no

MaxStartups 5:50:10 # после 5 неправильных регистраций,

# отторгать 50% новых подключений, и

# не отвечать совсем, если число

# неправильных регистраций превысило 10

X11Forwarding no

PrintLastLog yes

SyslogFacility auth # писать информацию о регистрациях в

# лог-файл to /var/log/auth.

LogLevel VERBOSE # обычно OpenSSH это единственный путь

# удаленного доступа к системе, мы

# хотим получать наиболее полную

# информацию от этого сервиса.

PasswordAuthentication no

PermitEmptyPasswords no

Banner /etc/issue

AllowGroups sshusers # группа, которой разрешена

# регистрация через SSH можно указать

# несколько групп через запятую.

Сохраняем и выходим из vi.

ZZ

Теперь откроем и отредактируем файл /etc/ssh/ssh_config

vi /etc/ssh/ssh_config

ForwardAgent no

ForwardX11 no

PasswordAuthentication no

CheckHostIP yes

Port 22

Protocol 2

Сохраняем и выходим из vi.

ZZ

Теперь, сгенерируем DSA ключи для авторизации с пользователем, AKA <noprivuser>

su - noprivuser

ssh-keygen -d

На экране появится строка

Generating public/private dsa key pair.

Enter file in which to save the key (Введите файл в который сохранить ключ.)

(/home/<nonprivuser>/.ssh/id_dsa): # значение по умолчанию

Enter pass phrase (empty for no pass phrase): # введите пароль для ключа или без пароля

Enter pass phrase (empty for no pass phrase): # подтверждение пароля

Your identification has been saved in /home/<nonprivuser>/.ssh/id_dsa.

Идентификационный ключ сохранен в ....

Your public key has been saved in /home/<nonprivuser>/.ssh/id_dsa.pub

Публичный ключ сохранен в ...

The key fingerprint is (отпечаток ключа): xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx <nonprivuser>@<host>

[user@server /dir]#cd .ssh

[user@server /dir]#cat id_dsa.pub > authorized_keys2

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

Выйдем из регистрационной записи пользователя.

Удалим файл с ключом из директории .ssh пользователя.

6. rc.conf

[user@server /dir]#vi /etc/rc.conf

inetd_enable="NO" # выключить inetd

syslogd_enable="YES" # Конечно мы хотим вести регистрацию событий. Если вы планируете настроить

icmp_drop_redirect="YES" # Отключаем прием и отправку переадресовующих ICMP пакетов.

icmp_log_redirect="YES" # Регистрировать переадресовующие ICMP пакеты в журнальном файле

clear_tmp_enable="YES" # Очищать директорию /tmp при загрузке.

portmap_enable="NO" # Если не используется NFS

icmp_bmcastecho="NO" # Предотвращает springboarding и smurf атаки, запрещая серверу отвечать

# на широковещательные ping-пакеты.

fsck_y_enable="YES" # При ошибках файловой системы на этапе загрузки утилита fsck будет

# запущена с флагом -y (man fsck)

update_motd="NO" #Не обновлять файл с сообщением дня /etc/motd

tcp_drop_synfin="YES" # Отбрасывать synfin пакеты.

log_in_vain=1 # Позволяем записывать все попытки подключения

# к закрытым портам сервера.

sshd_enable="YES" # Это позволит сделать удаленный доступ к серверу более защищенным.

Сохраняем и выходим из vi.

ZZ

7. login.conf & auth.conf Алгоритм md5 использующийся для шифрования паролей

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

безопасности. Как было сказано на встрече в Нью-Йорке наличие надежного

алгоритма криптования паролей похоже на прихожую которая отлично защищена.

Никто не может справится с этой защитой, но есть много других способов что бы

обойти прихожую. Будут сделаны дополнительные настройки для защиты паролей,

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

[user@server /dir]#vi /etc/login.conf

Делаем исправления в секции default:\

:passwd_format=blf:\ # заменяем алгоритм криптования паролей на

# Blowfish вместо идущего по умолчанию md5.

:passwordtime=52d:\ # период устаревания паролей 52 дня.

:mixpasswordcase=true:\ # предупреждать пользователей о том что пароли должны содержать

# разные символы (mixed-case passwords)

:minpasswordlen=9:\ # минимальная длина пароля 9 символов

:idletime=32:\ # автоматически отключать пользователей после

# 32-х минут бездействия

Сохраняем и выходим из vi.

ZZ

Теперь делаем базу.

cap_mkdb /etc/login.conf

Теперь необходимо изменить пароли всех пользователей, для того, что бы они были закриптованы при помощи алгоритма Blowfish.

Для пользователей, которые будут использовать bash должно быть написано /usr/local/bin/bash. Для пользователей, которые не должны иметь права регистрироваться в системе, например пользователь www для Apache, должно быть написано /sbin/nologin

Удалим пользователя toor

нажимаем dd на строке с пользователем toor

Теперь сделаем что бы пароли пользователей, которые будут добавляться в

дальнейшем криптовались алгоритмом Blowfish.

vi auth.conf

crypt_default=blf

Сохраняем и выходим из vi.

ZZ

8. sysctl.conf

vi /etc/sysctl.conf

net.inet.tcp.blackhole=2 # Это превращает машину в черную дыру при попытке подключиться к портам,

# которые не обслуживаются сервером.

net.inet.udp.blackhole=1

kern.ps_showallprocs=0 # только пользователь root может видеть все запущенные процессы

9. fstab

Теперь добавим некоторые параметры к некоторым точкам монтирования. Например,

нет надобности кому-либо иметь возможность запускать программы из /tmp

Есть более серьезные ограничения, которые можно сделать при помощи настроек

в файле /etc/fstab. Например, можно сделать некоторые точки монтирования

только читаемые, такие как /usr/local/, но это значит, что надо иметь

копию менее ограничивающего файла /etc/fstab на случай обновлений системы или

установки дополнительного программного обеспечения. В нашем случае, мы

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

#Device Mountpoint FStype Options Dump Pass#

/dev/ad0s1b none swap sw 0 0

/dev/ad0s1a / ufs rw 1 1

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

/dev/ad0s1g /usr ufs rw 2 2

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

/dev/ad0s1i /var ufs rw,noexec 2 2

/dev/fd0 /floppy MSDOS rw,noauto,noexec,nosuid,nodev,noatime 0 0

/dev/acd0c /cdrom cd9660 ro,noauto 0 0

proc /proc procfs rw 0 0

Список опций, которые были заданы:

ro: только чтение

rw: чтение запись (устанавливается по умолчанию)

sw: своп

nosuid: опция suid не работает

noexec: запрет на запуск файлов

nodev: запрещает отображение файлов в виде устройств

noauto: не монтируется автоматически во время загрузки

noatime: препятствует файловой системе делать запись о доступе к файлу.

10. CVSup

Для того, что бы исходные коды и документация всегда были обновленными, мы должны регулярно запускать cvsup при помощи задач cron. Мы не используем обновление портов, мы просто будем регулярно обновлять необходимые исходные коды.

[user@server /dir]# cp /usr/share/examples/cvsup/stable-supfile /root

[user@server /dir]# cd /root

[user@server /dir]# vi stable-supfile

Исправим следующие строки:

*default host= # на странице http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvsup.html

# найдем cvsup зеркало, которое наиболее быстрее будет отвечать на запросы,

# при помощи команды ping и введем его здесь. Это 68 строка в файле.

*default release=cvs tag=RELENG_4_7 # зависит от версии операционной системы. Это 73 строка файла.

#src-all # закомментирем это, хотя бы потому что нам не нужны исходные коды src-game. Это 84 строка в файле.

В следующей секции файла раскомментируме, разделы исходных кодов которые хотим обновлять, можно также включить и src-games.

11. Cron Jobs

chmod 0600 /etc/crontab # только пользователь root должен иметь доступ к файлу настройки cron

touch /var/cron/deny # добавим в этот файл всех пользователей, которым запрещено использовать cron

chmod 0600 /var/cron/deny

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

vi /etc/crontab

0 2 * * * root /usr/libexec/locate.updatedb # обновлять базу данных утилиты locate

каждое утро в 2 часа.

0 2 * * * root /usr/local/sbin/rdate yourNTPserver # запускать rdate каждое утро в 2 часа.

1 3 * * * root /usr/local/sbin/chkrootkit # запускать chkrootkit каждый месяц.

12. Kernel Changes (изменения в ядре)

Сделаем следующие изменения в конфигурационном файле ядра, и

перекомпилируем его. Можно найти эти и другие опции ядра в файле

/usr/src/sys/i386/conf/LINT.

#pseudo-device bpf #Berkley Packet Filter. защита от снифинга на уровне ядра. Не убираем эту опцию, так как собираемся использовать dhcp

options SC_NO_HISTORY # отменяем историю команд на виртуальных терминалах

options SC_DISABLE_REBOOT # отменяем перезагрузку по комбинации клавиш ctl-alt-del

options SC_DISABLE_DDBKEY # отменяем debug key

options TCP_DROP_SYNFIN # см. выше в разделе rc.conf.

options RANDOM_IP_ID # случайный идентификатор IP пакетов препятствует

# idlescan-style сканирования. Мешает взломщику

# определить разряд(rate) генерации пакетов.

options ICMP_BANDLIM # Если разрешить пакеты icmp к серверу, этот

# параметр, ограничит количество ответов, что помогает при

# защите от DOS атак.

13. Права доступа к файлам.

При помощи команды chmod 600, мы разрешаем доступ только пользователю root на

запись и чтение файла.

При помощи команды chmod 700, мы также даем возможность пользователю root

возможность запускать файл.

chmod 0700 /root

chmod 0600 /etc/syslog.conf

chmod 0600 /etc/rc.conf

chmod 0600 /etc/newsyslog.conf

chmod 0600 /etc/hosts.allow

chmod 0600 /etc/login.conf

chmod 0700 /usr/home/*

14. Сетевой Протокол Времени (Network Time Protocol).

В crontab файле (файл настройки системы crontab) мы используем rdate вместо ntp для синхронизации часов сервера с мировым временем. Точное время на сервере является очень важным пунктом для правильного ведения журнальных файлов и часто помогает при разрешении конфликтов и устранении неисправностей.

vi /etc/ntp.conf

restrict default ignore # не работать в качестве ntp сервера.

15. TCP Wrappers

vi /etc/hosts.allow

sshd : localhost : allow

sshd : x.x.x.x, x.x.x.x : allow # разрешить ssh запросы только из сетей x.x.x.x

sshd : all : deny # запретить запросы ssh из остальных сетей

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

Убедимся что настроили права доступа для других служб, добавим это:

ftpd : ALL : deny

16. Console Access (доступ к консоли).

Блокируем доступ от неавторизованного доступа в однопользовательском режиме. Изменение прав доступа к первой консоли означает что нельзя войти в систему в однопользовательском режиме, не зная пароля пользователя root.

vi /etc/ttys

console none unknown off insecure # запрашивать пароль пользователя root в однопользовательском режиме.

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

# Virtual terminals

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

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

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

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

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

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

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

Если поставить режим insecure для всех виртуальных терминалов, то чтобы войти на сервер из локального терминала, необходимо сначала зарегестрировать пользователем из группы wheel, а уж потом su.

17. Bash Shell

vi /usr/share/skel/.bash_logout # Файл .bash_logout созданный в домашнем каталоге каждого

# пользователя с командой 'clear' будет очищать экран при

# выходе пользователя из системы. Скопируем в домашний

# каталог пользователя root.

clear

18. chflags

Команда chflags увеличивает уровень безопасности (the level of security) на указанных файлах. Эта команда особенно полезна для исполняемых или конфигурационных файлов, код или информация которых может быть испорчены другими программами/действиями.

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

Запуск команды производится следующим образом:

chflags [no]appnd или [no]schg имя файла

Наберем ls -ol (буквы o и l в маленьком регистре) для просмотра измененных свойств файла. Должны быть два флажка.

sappnd Переводит файл в append-only режим, и только для пользователя root. Другими словами, в файл можно добавить любые данные, но первоначальная информация не может быть изменена/удалена.

schg Делает файл изменяемым только для пользователя root.

Обе команды имеют префиксы. "u" перед sappnd или schg применяет те же опции, но при этом добавляет владельца файла в список пользователей которые будут иметь доступ к этому файлу.

"no" перед sappnd или schg отменит chflag опцию на файле.

19. Зачистка

Убедимся что все строки в файле /etc/inetd.conf закомментированы.

sockstat -4 #убедимся что ничего лишнего не запущено

tcpdump -xX #пока сервер только появился в сети, посмотрим кто обращается к нему.

Атрибуты файла и файловой системы

Полезные атрибуты файла:

- A отключает создание метки atime для записи времени последнего

доступа к файлу, что позволяет сократить количество операций обращения

к носителю. Не поддерживается многими версиями ядра (до версии 2.0). В

некоторых случаях лучше смонтировать файловую систему с параметром

noatime.

- a Только дозапись данных. Устанавливается суперпользователем.

- d Такой файл будет пропущен при создании backup'а системы.

- i Файл нельзя переименовывать, создавать на него ссылки,

модифицировать.

- s При удалении файла занимаемое им место заполняется нулями.

- S При модификации файла все изменения синхронно фиксируются на НМЖД.

Использование команды:

#Чтение атрибутов:

user$ lsattr my_file.txt

-------- my_file.txt

#Установка атрибутов:

user$ chattr +c my_file.txt

user$ chattr +s my_file.txt

user$ chattr +d my_file.txt

#Чтение атрибутов:

user$ lsattr my_file.txt

s-c---d- my_file.txt

#Снятие атрибутов:

user$ chattr -d my_file.txt

s-c----- my_file.txt

Команда chattr +i используется для запрещения изменения всех файлов

программ в каталогах /bin, /usr/bin, /sbin, /usr/sbin, /lib и т.п. Эти

файлы обычно обновляются редко и желательно знать обо всех случаях,

когда это необходимо.

Securelevel

Ядро BSD поддерживает такую функцию, как securelevel. Securelevel - это уровень защиты, который использует ядро.

# man 8 init

Ядро работает с четырьмя другими уровнями безопасности. Любой процесс суперпользователя может увеличить уровень безопасности, но только init может уменьшить его. Уровни безопасности:

· -1 Небезопасный режим. Лучше его не использовать.

· 0 Небезопасный режим. Флаги невозможности изменения и добавления могут быть выключены. Со всеми устройствами можно производить операции записи и чтения

· 1 Безопасный режим. Диски для монтирования файловых систем, устройства /dev/mem и /dev/kmem могут быть закрыты для записи.

· 2 Очень безопасный режим. Тоже, что и безопасный режим. Кроме того: диски закрыты от записи (исключая команду mount(2)) вне зависимости от того смонтированы они или нет. Этот уровень предотвращает подделку файловых систем с помощью их демонтирования и выполнение команды newfs(8) в многопользовательском режиме.

Если уровень безопасности первоначально -1, то init оставит это неизменным. В противном случае, init установит уровень 0 для однопользовательского режима и уровень 1 для многопользовательского режима. Если нужен уровень 2 - то его можно устанавить в однопользовательском режиме, например, в сценарии запуска /etc/rc, используя sysctl(8).

Чтобы изменить securelevel:

# sysctl -w kern.securelevel=X где X - 0, 1 или 2.

Файл /boot.config может использоваться, чтобы изменить ядро, используемое при загрузке. Для того, чтобы это было невозможно сделать, следует сделать следующее:

# touch /boot.config

# chflags schg /boot.config

Хорошо также выполнить команду chflags schg для директорий /sbin и /bin. Это сделает более трудным доступ к "черным ходам" в системе (особенно при использовании securelevel).

# chflags schg /bin/*

# chflags schg /sbin/*

Поскольку /sbin может быть перемещен и после этого создан новый /sbin, следует провести туже самую операцию над каталогами:

# chflags schg /bin; chflags schg /sbin

Способы защиты от флуда и DDoS атак.

Черные дыры.

net.inet.tcp.blackhole=2

net.inet.udp.blackhole=1

Это превращает машину в черную дыру при попытке подключиться к портам, которые не слушают. Nmap по настоящему не любит это.

Защита очереди сокета от SYN атак

Основной из самых популярных атак остается SYN флуд, при которой очередь сокета атакуемого хоста переполняется некорректными попытками соединений. Для защиты от таких атак некоторые из UNIX поддерживают отдельные очереди для входящих запросов на соединение. Одна очередь для полуоткрытых сокетов (SYN получен, SYN|ACK послан), другая очередь для полностью открытых сокетов, ждущих вызова accept() от программы. Эти две очереди должны быть увеличены, чтобы атаки малой и средней интенсивности почти не влияли на стабильность и доступность сервера.

kern.ipc.somaxconn=1024

Редиректы (Перенаправления)

Атакующий может использовать IP redirect для изменения таблицы марщрутизации на удаленном хосте. В хорошо разработанной сети редиректы на конечные станции не должны требоваться. Оба - отправка и принятие редиректов должны быть отключены.

net.inet.icmp.drop_redirect=1

net.inet.icmp.log_redirect=1

net.inet.ip.redirect=0

net.inet6.ip6.redirect=0

Настройка стека IP в системах UNIX на оптимальную производительность:

На размер буфера приема и передачи TCP напрямую влияет параметр размера TCP окна. Увеличенный размер окна позволит более эффективно передавать данные, особенно при интенсивной передаче, такой как FTP и HTTP. Значение по умолчанию не является оптимальным и должно быть увеличено до 32768 байт. Это значение не должно быть более 64Кб, если вы не знаете об ограничениях RFC1323 и RFC2018, и если нет поддержки с обеих сторон.

FreeBSD:

sysctl -w net.inet.tcp.sendspace=32768

sysctl -w net.inet.tcp.recvspace=32768

Очистка ARP:

Существует возможность, что атакующий создаст нехватку ресурсов или уменьшение производительности заполнив кэш маршрутизации IP с помощью неправильных записей в ARP таблице. Этот параметр рекомендуется выставить в 20 минут по умолчанию.

FreeBSD:

sysctl -w net.link.ether.inet.max_age=1200

Маршрутизация отправителя:

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

FreeBSD:

sysctl -w net.inet.ip.sourceroute=0

sysctl -w net.inet.ip.accept_sourceroute=0

Установка TIME_WAIT

На загруженном web сервере многие сокеты могут задерживаться в состоянии TIME_WAIT. Это вызвано неправильно написанными клиентскими программами, которые неправильно закрывают сокеты. Это так же может быть использовано для DDoS атак. Нет рекомендаций по настройке.

Ответ на широковещательный ECHO.

Эти атаки работают с помощью отправки сообщения ICMP 8 0 (запрос ECHO) на широковещательный адрес с фальшивого адреса. Некоторые стеки IP ответят по умолчанию на такие сообщения. Это должно быть отключено. Более того, если хост является фаерволом или раутером, то он не должен пропускать проямые широковещательные запрсы.

FreeBSD:

sysctl -w net.inet.icmp.bmcastecho=0

Другие пробы с помощью широковещания:

Существуют 2 вида проб. Запрос маски адреса может быть использован для определения размера блока сети и установки диапазона для дальнейших проб. Широковещательный запрос временного штампа (timestamp) - еще одно средство выявления хостов и определения их операционных систем (fingerprinting)

FreeBSD:

sysctl -w net.inet.icmp.maskrepl=0

Другие средства защиты

Во FreeBSD существует еще множество средств защиты. Я не в силах рассмотреть их все, так что на этом придется закончить.

Надо только добавить, что необходимо также настроить аппаратные фареволы, которые стоят на точках выхода в Интернет и корпоративную сеть.

Вывод

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

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

Я разработала систему безопасности для одного из офисов компании «British Petrolium». Действуя в соответствии с принципом слабого звена я постаралась охватить все аспекты безопасности, но в связи с очень большим объемом работы, мне пришлось бы писать книгу, если бы я охватила действительно все то что стоит вниманиям.

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

Литература

1. http://kiev-security.org.ua

2. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/index.html

3. http://people.freebsd.org/~jkb/howto.html

4. http://www.FreeBSD.org

5. FreeBSD. Энциклопедия пользователя /Майкл Э., Брайан Т.; 4-е издпние; Пер. с англ., - СПб.: ООО «ДиаСофтЮП», 2005. - 864с.

6. А.А. Большаков, А.Б. Петpяев, В.В. Платонов, Л.М. Ухлинов. Основы обеспечения безопасности данных в компьютеpных системах и сетях, - 1995.

7. Гайкович В.Ю., Ершов Д.В. Основы безопасности информационных технологий