Информационная безопасность - это не продукт, это процесс.

Комиссарова Валерия ( Kochergi@mail.ru )

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

Всё это мы рассмотрим с разных точек зрения: то с точки зрения системного администратора, то с позиции главы фирмы ( работодателя ). Таким образом, статья является своеобразной антологией наиболее ценных наработок в этой области, а также попыткой связать их в единое целое. Приступим.

Корпоративная сеть.

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

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

Начнём со стороны системного администратора. Здесь процесс обеспечения ИБ также делится надвое: внешняя безопасность ( защищённость от атак извне ) и внутренняя ( локальная ). Оправданность такого подхода очевидна - достаточно вспомнить взлом хостинга ipowerweb.com. Снаружи машина была защищена прекрасно ( хотя уязвимый phpBB также должен был быть удалён с сервера ), взломщик не смог проникнуть на сервер обычными сетевыми методами, но он воспользовался социальной инженерией и получил тестовый доступ. И что же ? Оказалось, что локальная настройка сервера была выполнена чрезвычайно безалаберно и не обеспечивала минимального уровня безопасности. Итог: взломщик нашёл лазейку в системе и приобрёл в ней наивысшие привилегии. Можно также привести в пример технологию взлома Reverse IP Lookup, когда посредством взлома сайта, физически находящегося на том же сервере, что и цель взломщика, можно получить шелл - доступ и "ощупать" сервер изнутри. Понятно, что грамотно настроенная локальная политика безопасности может существенно снизить степень риска для сервера при такой атаке. Особенно заботиться о противостоянии технологии Reverse IP Lookup должны хостеры.

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

Не будем говорить о выборе аппаратной платформы. Допустим, что сервер построен на платформе x86.

Выбор ОС. Моё мнение таково: для создания защищённого сервера *nix - системы подходят куда больше, нежели Windows. Вспомним об изначальном предназначении обоих типов систем: если *nix ( xBSD и т.д. ) - системы с момента своего создания применялись на таких стратегически важных площадках как разведывательные структуры, министерства обороны различных стран ( с помощью встраиваемых Linux - систем проводится разминирование в Афганистане ) и проч. , то Windows проектировалась с расчётом на пользовательский сегмент рынка, поэтому её установка на сервер представляется нецелесообразной. Кроме того, если посмотреть историю взломов, окажется, что Windows уже долгое время занимает в ней лидирующую позицию. Можно сравнить степень опасности найденных уязвимостей в обоих типах систем ( вспомним RPC DCOM ); не стоит забывать и о том, что мы зависим от производителей системы, ведь при обнаружении очередной критической уязвимости приходится ждать от них заплатки, а последует ли она - вопрос ( новый сервис MSA ( Microsoft Security Advisories ) ситуацию практически не меняет ), в то время как в *nix - системах можно хотя бы попытаться решить проблему своими силами. Да и способ тестирования большинства *nix - систем по принципу "базара" ( за исключением таких относительно закрытых как, например, OpenBSD, в непосредственной разработке которой принимает участие ограниченное число людей ) по - прежнему сильно выигрывает в сравнении с "соборным" стилем написания кода Windows. Можно приводить ещё массу доводов, но статья не об этом, так что выбор за Вами. Я же предполагаю, что Вы остановились на *nix - системах. Теперь необходимо выбрать среди огромного количества *nix - клонов. Думаю, оптимальным вариантом будет любая ОС из линейки xBSD, особенно OpenBSD. Из других систем - Sun Solaris и, конечно , великолепный QNX, который, полноценно поддерживая стандарт POSIX, лучше всего подходит для профессионального системного администратора. Если же Вы хотите построить сервер на базе одной из разновидностей Linux`а, то, благодаря своей похожей на порты FreeBSD системе обновления программ из Интернета ( команда emerge ), прекрасно подойдёт Gentoo. Естественно, сказанное не является аксиомой: профессионально настроенный Mandrakelinux будет безопаснее безграмотно настроенного OpenBSD. Установка операционной системы. Тут можно дать советы по разбивке винчестера на разделы и по выбору и установке сервисов. Винчестер можно разбить так:

   /     -  корневой раздел системы
   /home -  каталоги пользователей
   /tmp  -  папка временных файлов системы
   /var  -  папки для хранения логов и т.д.
   /usr  -  исходные коды системы, пользовательские программы и библиотеки
   

Такая разбивка даёт возможность устанавливать флаги на конкретные разделы, например: noexec - запрет на исполнение файлов, nosuid - запрещение suid - битов на файлах и т.д. Для просмотра полного списка доступных флагов в Вашей системе нужно набрать команду man mount. Также не стоит забывать об установке флагов на конкретные файлы ( man chflags, chattr, lsattr ).

Лично я люблю выделять каталог /boot в отдельный раздел, а ещё лучше - производить загрузку системы со сменного носителя. После запуска системы носитель с каталогом /boot можно спокойно извлечь, что частично защитит от подмены ядра.

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

Следует подумать о выборе конкретных программ. Например, настраивая почтовый сервер, задаёшься вопросом: какой вариант предпочесть ? Sendmail, qmail, postfix... Это заслуживает отдельного разговора.

Во-первых, хотелось бы отговорить от использования суперсервера inetd/xinetd. Этот суперсервер используется ( использовался ) в основном для запуска сервисов, не "умеющих" работать в standalone - режиме. Стоит ли говорить, что сейчас абсолютное большинство нормальных сервисов спокойно может работать в режиме standalone, а те, что не могут, вряд ли имеет смысл оставлять на серьёзном ответственном сервере. Если же необходимость в использовании суперсервера всё - таки есть, лучше использовать его более безопасные аналоги, например, tcpserver ( http://cr.yp.to/ucspi-tcp/ ) Дэна Бернстайна. Недостатки inetd/xinetd очевидны: любая Dos ( DDos ) атака на суперсервер немедленно обернётся крахом всех поддерживаемых им серверных процессов. Это уже достаточное основание его не использовать. ПРИМЕЧАНИЕ: в русскоязычной литературе не закреплено различие между Dos ( Denial of service – атака на отказ в обслуживании ) и DDos ( Distributed Denial of service – распределённая атака на отказ в обслуживании ), поэтому во избежание путаницы я везде привожу оба варианта.

Всегда нужно обращать внимание на историю взломов и список найденных уязвимостей за всё существование программы и уже на основании этих данных выбирать сервер ( если, конечно, у Вас нет каких - то конкретных предпочтений в этом вопросе или Вы не администрируете сервер, установленный до Вас ). Одна из Ваших самых главных забот - непрерывное слежение за всеми появляющимися в багтраке сообщениями о найденных уязвимостях в используемых Вами сервисах. Тут осознаёшь всю прелесть механизма обновления Gentoo ( это касается и FreeBSD ): прописываешь в crontab команду emerge sendmail и всё ! MTA ( MailTransferAgent - почтовый агент ) Sendmail отныне будет обновляться самостоятельно, без вашей помощи. Но это, конечно, не означает, что теперь на Sendmail можно не обращать никакого внимания. Всему нужен постоянный контроль.

После базового конфигурирования сервера перейдём к защите от внешних атак. Важный этап защиты - выбор, установка и конфигурирование брандмауэра. Брандмауэры подразделяются на программные и аппаратные. Рассмотрим их.

Для *nix ( xBSD ) - систем основные файерволлы - IPTables ( http://netfilter.org/files/ ), IPChains для Linux ( http://www.rustcorp.com/linux/ipchains/ ), ipfw, IPFilter ( http://coombs.anu.edu.au/ipfilter ) для FreeBSD и pf для OpenBSD ( страница порта под FreeBSD - http://pf4freebsd.love2party.net/ ). IPChains, предшественник IPTables, предназначается для ядер 2.2.x, а IPTables - для 2.4.x и выше. Естественно, нет никакого резона работать со столь старыми и уязвимыми ядрами как 2.2.x, поэтому IPTables - отличный вариант. Когда - то это был не лучший файерволл ( особенно в сравнении с pf ), но с выходом комплекта патчей Patch-o-Matic ( http://netfilter.org/files/ ) всё изменилось. Теперь IPTables умеет делать OSFingerPrint, искать подстроку в пакете, временно активизировать правила, оговаривать максимальное количество подключений к конкретному порту и проч. и проч. Так что установка Patch-o-Matic является даже не желательной, а обязательной. Pf может всё то же, что и IPTables с установленным Patch-o-Matic и даже больше. Среди возможностей этих двух файерволлов можно также отметить компоновку портов и ip - адресов в одном правиле. Ну и, разумеется, NAT ( не обсуждается ), которым возможности этих файерволлов не исчерпываются. Ipfw и IPFilter ничем особенным не отличаются.

Пример аппаратного брандмауэра - маршрутизаторы CISCO ( в частности CISCO PIX - встроенный брандмауэр маршрутизатора CISCO ). Гибкий механизм конфигурирования через списки доступа ( access - lists ) и механизмы борьбы с перегрузками - это несомненные плюсы данных маршрутизаторов. Минусы - внушительная история уязвимостей ( причём довольно глупых ), найденных в этом проекте. Например, переполнение буфера при обработке очень длинного URL - адреса HTML - интерфейсом маршрутизатора или уязвимость в telnetd - демоне ( при обработке D - опций ) и др. Тем не менее, при грамотной настройке использование CISCO PIX даёт неплохие результаты. Маршрутизаторы CISCO обладают уймой полезных для корпоративной сети возможностей: туннелирование, policy routing ( алгоритмы маршрутизации ), NAT, стратегии очередей и многое другое, что не имеет прямого отношения к теме статьи.

Важный аспект - фильтрация почтового оборота компании. Необходимо "прикрутить" к почтовой системе спам - фильтр и антивирус. Из спам - фильтров для *nix - серверов можно выделить SpamAssassin ( http://spamassassin.apache.org ), для Windows - серверов - Kaspersky AntiSpam ( web - страница всех продуктов лаборатории Касперского - http://www.kasperskylab.ru , приобрести их можно в интернет - магазине SoftKey ( http://www.softkey.ru ). Из антивирусов - Dr.Web и AVP для *nix и Kaspersky Anti - Virus для Windows - серверов ( также Kaspersky Anti - Virus Business Optimal ). Фильтрация писем при приёме корреспонденции позволяет в большой степени снизить ущерб от неграмотных пользователей рабочих станций корпоративной сети. Таким образом, мы вплотную подошли к проблеме "ликвидации безграмотности". Отвлечёмся ненадолго от нашего повествования и поговорим об этом.

Человеческий фактор - наиболее уязвимое звено в системе обеспечения безопасности любой сети или персонального компьютера. Доверчивые пользователи, запускающие файлы "ClickMeNow.exe", открывающие и запускающие неизвестные им аттачи в письмах, реагирующие на все предложения, содержащиеся в спаме, - находка для хакера. Грамотная разъяснительная работа с пользователями обязательна. Собственные меры безопасности по отношению к пользователям - тем более. Необходимо запрещать пользователям ставить слишком простые пароли, контролировать их сложность и длину, а также не забывать периодически их менять, что справедливо и для root`а ( то бишь для Администратора ). Весь этот процесс можно облегчить и автоматизировать с помощью специальных утилит и их дополнительных возможностей, да и встроенные средства Windows/*nix при должной настройке сильно упрощают задачу.

Старайтесь фильтровать нежелательные письма и вложения ещё до того, как они дойдут до пользователя ( разъяснительные беседы не всегда помогают ). Шифрование проходящей по сети информации и корреспонденции уменьшит возможный ущерб от несанкционированной установки и запуска вирусов, троянских коней, снифферов и т.д. Необходимо уделять настройке безопасности клиентских машин много внимания: настроить антивирусы, файерволлы, своевременно обновлять важные программы и устанавливать на систему патчи. В настройке помогают две вещи: Software Restriction Policy и шаблоны безопасности. Шаблоны позволяют настроить какую - либо одну машину, создать файл, содержащий эти настройки, а затем применять его на любом количестве машин. А Software Restriction Policy подразделяет программы на те, которые можно и которые нельзя запустить на машине.

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

Самое время поговорить об IDS. IDS - это Intrusion Detection System ( система обнаружения атак ). IDS делятся на сетевые ( NIDS - Network Based IDS) и локальные ( HIDS - Host Based IDS ), активные и пассивные. Сетевые контролируют несанкционированную сетевую активность, а локальные - соответственно локальную ( руткиты и т.д. ). Активные IDS способны моментально отреагировать на попытку атаки сервера, например, сканирование, и не только занести событие в логи, но и заблокировать ip - адрес/подсеть атакующего. Пассивные же могут только залогировать событие и отправить администратору сообщение на e - mail, мобильный и т.д. Поэтому пассивные IDS требуют куда больше внимания, чем активные ( регулярного просмотра логов как минимум ). А теперь рассмотрим наилучшие и самые популярные IDS.

Из сетевых IDS лучшая, несомненно, Snort ( http://www.snort.org ). Она отслеживает сканирование портов ( в том числе stealth ), посылку shell - кода на порт, Dos ( DDos ) атаки и т.д. Snort удобно конфигурируется. Но у этой IDS есть и минусы: во - первых, с момента создания в ней было обнаружено несколько уязвимостей, позволяющих заполучить удалённый контроль над системой. Логи взломщик может стереть ( впрочем, это относится ко всем логирующим IDS ). Ну и второе - Snort, к сожалению, пассивен. А вот portsentry ( http://prdownloads.sourceforge.net/sentrytools ) - утилита, предназначенная для детектирования сканирования портов, хорошая и активная. Она логирует все попытки сканирования и противостоит им. К ней прилагается утилита logsentry для преобразования логов IDS в удобный для чтения формат. Но portsentry бессилен против ручного сканирования портов, что справедливо для большинства IDS.

Перейдём к локальным IDS. Среди утилит этого класса стоит выделить tripwire и chkrootkit. Tripwire ( http://www.tripwire.org ) - утилита для осуществления аудита доступа к системным файлам. Обойти tripwire можно с помощью модификации действующих конфигов. Противоядие: переопределить пути tripwire в системе, переименовать запускной файл IDS, удалить файлы, описывающие действующие политики. Chkrootkit ( http://freshmeat.net/redir/chkrootkit ) - утилита обнаружения установленных в системе руткитов, бэкдоров и т.д. Способ обхода - правка исходников. Защита - постоянная проверка контрольной суммы chkrootkit.

Переходим к обеспечению локальной безопасности сервера. Аудит md5 - сумм хорош не только для chkrootkit - такой способ контроля полезен для любых стандартных утилит системы ( ps, ls, netstat...), которые часто модифицируются взломщиком для своих нужд ( для сокрытия файлов, процессов, сетевых соединений и т.д. ). Программы вроде компилятора, дизассемблера и проч. на работающей и отлаженной машине не нужны. Едва ли их отсутствие сильно затруднит взломщику его работу ( так как скомпилированный эксплойт можно спокойно закачать на уязвимый сервер и запустить ), но всё же. Совет: не оставляйте рутовых паролей в .bash_history ! Это одна из самых распространённых ошибок, которую нередко допускают даже грамотные системные администраторы. Есть простой и удобный способ решения проблемы - прилинковать .bash_history к /dev/null. Кроме того, необходимо организовать немедленную пересылку логов на машину, предназначенную специально для этого. Неплохо было бы установить для этих целей подходящую БД ( базу данных ).

Следующие два мощных механизма обеспечения локальной безопасности сервера - chroot и systrace.

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

chroot имя_нового_корневого_каталога [команда[аргументы]]

Преимущества chroot: программы, находящиеся вне конкретного chroot, могут его изменять, а программы, находящиеся внутри него - нет. Таким образом, взломщик, получив привилегии на сервере, работающем в chroot, может сколько угодно изменять находящиеся там файлы - на реальной системе это никак не отразится. Например, если скопировать в chroot системный файл /etc/passwd, взломщик, добавив нового пользователя в систему, не сможет применить эти изменения для настоящего /etc/passwd. Так что это ещё один серьёзный барьер на пути хакера.

Systrace - это механизм, определяющий для каждой программы набор разрешённых ей системных вызовов. Область его применения достаточно широка: можно, например, запретить какому - либо сервису открывать новые порты. В этом случае предназначенный для сервиса shell - код, открывающий через его процесс порт для шелла, останется не у дел. Техническая реализация механизма systrace довольно сложна и рассмотреть её во всех подробностях в данной статье не представляется возможным - это тема отдельного, обстоятельного разговора. За дальнейшей информацией советую обратиться к http://www.citi.umich.edu/u/provos.

Существует множество патчей к ядру, в той или иной мере позволяющих защититься от хакерских атак, ориентированных на переполнение буфера, стека и т.д. На первом месте патч grsecurity ( http://www.grsecurity.net/ ), защищающий от переполнений стека и памяти. Далее следует патч ( http://www.openwall.com/linux/ ), блокирующий всевозможные несанкционированные действия, в частности переполнения стека. RSX - патч ( http://www.starzetz.com/software/rsx ) предотвращает запуск кода в стеке или куче после переполнения, но работает, к сожалению, только на ядрах 2.4.x. Вышеперечисленные патчи под *nix, пожалуй, наилучшие из доступных. Для Windows хороший вариант - знаменитый AntiCracker Shield ( http://www.softsphere.com/cgi-bin/redirect.pl?Name=ACSHIELD ) Ильи Рабиновича. Эта гибкая утилита обеспечивает несколько уровней защиты: low, medium, high и ultra. На уровне low разрешено выполнение кода как в стеке, так и в куче, а на ultra - запрещено. Уровни medium и high запрещают выполнение кода в стеке, а кучу контролируют. Кроме того, AntiCracker Shield обеспечивает рандомизацию стека и кучи. И это далеко не полный список возможностей данного продукта ! Так что его использование обязательно. Доступны серверная и пользовательская версии ACSHIELD, а также русский файл справки к ней ( http://www.softsphere.com/files/acshield.chm ).

Если у Вашей фирмы есть свой веб - сайт, необходимо тщательно следить за информацией в багтраке обо всех уязвимостях в установленных скриптах и самостоятельно тестировать их, ведь сообщение об уязвимости в багтраке может и не появиться, но это не повод снижать контроль за web - содержимым сайта. Вы можете не заметить ошибки на своей веб - странице ( или просто взломщик окажется умнее Вас ), поэтому важные данные ( например, базы данных ) НИ В КОЕМ случае НЕЛЬЗЯ размещать на публичном web - сервере ( из - за SQL - Injection в частности ). Они должны находиться за демилитаризованной зоной ( DMZ ). Тем более что сейчас очень популярен Google - Hack ( взлом при помощи поисковых запросов Google ), и если Вы будете хранить важные документы на сервере, да ещё допустите ошибку в его настройке, это приведёт к тому, что поисковый робот Google сможет их проиндексировать и предоставить взломщику ссылки на них. Думаю, не надо объяснять последствия. Кроме того, нужно отконфигурировать файл robots.txt, который определит, какие данные на сервере могут проиндексировать поисковые роботы. Хорошие результаты даёт правильная настройка cPanel ( если таковая на Вашем сервере имеется ).

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

Есть ещё мелочи, которые могут привести к несанкционированному взлому Вашего сервера. Могут найтись слабые места и в вышеперечисленных методиках. Мы не поговорили о настройке уровней безопасности ядра, настройке ответов на некоторые сетевые запросы ( что поможет в случае невозможности использования IDS ), о средствах sysctl для повышения безопасности сервера ( переменные sysctl имеют огромное число возможностей, включая реализацию защиты от DDos ( Dos ) атак, сканирования nmap`ом и т.д. ) и проч. От сканирования nmap`ом защитят специальные механизмы в файерволле pf, использование специальных патчей ( например, IPPersonality под Linux, изменяющий поведение сетевого стека и позволяющий замаскировать сервер под любое сетевое устройство ). Также мы не рассмотрели такую интересную вещь как honeypot ( впрочем, она имеет косвенное отношение к теме статьи ), не поговорили о патчах для Linux`а ( RSBAC, SELinux ), реализующих в системе Role Based Access Control ( RSBAC ), Domen Type Enforcement ( DTE ) и т.д. Отдельная тема - мандатные модели доступа ( Mandatory Access Control ). Не стоит забывать и о CSS ( XSS ) атаках. Но один из главных принципов сохранности данных - бэкап. Резервное копирование всегда поможет избежать необратимой потери данных. А ещё бывает так, что незначительный скачок напряжения в сети наносит больший вред, чем все хакерские атаки вместе взятые. Выход один - UPS.

Таким образом, процесс обеспечения информационной безопасности корпоративной сети можно считать завершённым. Желаю высоких uptime`ов и чистых от атак хакеров логов !

Персональная и корпоративная пользовательские машины.

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

Банальный совет: установите антивирус и файерволл. Kaspersky Internet Security Suite - комплексное решение, сокращающее время настройки и предотвращающее возможные конфликты между программным обеспечением. Также подходят Kaspersky Anti Virus, Kaspersky Anti Hacker, Agnitum Outpost Firewall ( http://www.agnitum.ru ) и, пожалуй, Dr.Web ( http://www.drweb.ru ). Связка продуктов от Касперского блокирует вредоносные скрипты, модули, вирусы, хакерские атаки и др. К плюсам Agnitum Outpost Firewall относится, в частности, блокирование баннеров. Его дополнительную функциональность для других продуктов можно реализовать с помощью стороннего ПО. Dr.Web - обыкновенный антивирус, главным достоинством которого является сравнительно небольшая загрузка ресурсов. К зарубежным файерволлам и антивирусам ( Norton Anti Virus, Panda Anti Virus, Kerio, Sygate Personal Firewall и т.д. ) после длительного опыта общения с ними я отношусь крайне неодобрительно. По качеству и скорости работы они значительно уступают отечественным продуктам.

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

Во - первых, следует отключить ненужные сервисы, как - то: "Удалённый реестр", "Telnet" и все службы, предоставляющие возможность удалённого управления системой. На обычной рабочей станции они, как правило, не нужны. Ни в коем случае не позволяйте пользователям работать под аккаунтом администратора или root`а. Это относится и к домашним пользователям - несколько неосторожных действий, и восстановить систему будет чрезвычайно трудно/невозможно. Такая мера предосторожности поможет защититься от вредоносных программ: многие задачи вируса ( троянского коня и т.д. ) могут быть реализованы только при наличии повышенных привилегий в системе. Вирус, запущенный в непривилегированном режиме, существенно ограничен в своих возможностях. Очень полезно подменить cmd - интерпретатор команд ( точнее его название ) с последующим редактированием соответствующей переменной среды. А своевременное обновление антивирусных баз и наложение патчей на систему - непреложное правило.

Следует помнить, что угроза системе безопасности корпоративной сети исходит не только из внешней среды, но и от локальных пользователей сети. Поэтому необходимо определить, к каким ресурсам ( устройствам ) сети и рабочего компьютера пользователь может иметь доступ. Нет смысла позволять всем подряд работать, например, с CD - приводами и/или флоппи - дисководами. Часто разрушительный вирус проникает в корпоративную сеть не в результате хакерской атаки, а с диска, с которого пользователь по незнанию или намеренно инсталлировал вредоносную ( заражённую ) программу. Реализовать политику разграничения доступа призваны стандартные средства Windows ( например, апплет настройки групповых политик gpedit.msc ) и отдельные программные продукты сторонних разработчиков.

Большая проблема локальных сетей - сниффинг. Перехват информации в последнее время одно из самых любимых "развлечений" пользователей локальных сетей. Метод защиты - использование специальных программ для детектирования активных снифферов и шифрование передаваемых по сети данных, что осуществляется посредством замены небезопасных версий сетевых протоколов на их более защищённые аналоги. Но так как в большинстве случаев такую замену произвести невозможно, разумно пользоваться защитами, работающими на третьем уровне, например, IPSec. Ещё один способ - определить, в каком сетевом режиме находится пользователь; если в promiscuous, то это верный признак того, что пользователь в данный момент занимается сниффингом.

И последнее: защита от локальных хакеров. Некоторые пользователи не прочь сделать дефейс главной страницы web - сайта фирмы, в которой работают. Есть много способов защиты от этой напасти, например, отконфигурировать squid ( и любую другую программу, через которую проходит траффик локальной сети компании ) на блокирование пакетов с заданными shell - кодами и т.п. и при обнаружении оных выводить пользователю соответствующее сообщение.

Написание защищённого кода как один из главных аспектов обеспечения информационной безопасности программных продуктов.

Хакерские атаки в 90% случаев используют уязвимости в программном обеспечении. Написать программное обеспечение без ошибок невозможно, но халатное отношение большинства разработчиков к безопасности своего кода очевидно. Защищённый код должен быть приоритетом при разработке программного обеспечения. Необходимо, во - первых, знать основные принципы создания защищённого кода и уметь грамотно применять их, а во - вторых, нелишне использовать специальные утилиты, патчи к компиляторам и т.д. для облегчения задачи программиста. Обсудим это.

Следует различать безопасность кода, написанного на C и на Perl. В так называемых web - языках ( Perl, Php, Asp ) программист должен главным образом заботиться о параметрах, передаваемых скрипту. В остальных языках ( C, Pasсal ) нужно в первую очередь решать проблемы, связанные с переполнением буфера и тому подобными вещами. Сделаем краткий обзор основных постулатов создания защищённого кода:

1. Всегда проверять длину строки ( и всего остального ) перед копированием в буфер;
2. Динамически задавать размер буфера в зависимости от пользовательского ввода;
3. Использовать более защищённые аналоги повседневных функций: fgets вместо gets, strncpy вместо strcpy, snprinf вместо sprintf и т.д.;
4. Если задать/проверить длину передаваемых данных по каким - либо причинам невозможно, нужно использовать защиту на основе canary word. Её суть: при объявлении буфера его размер определяется на четыре байте больше, чем нужно. Перед использованием буфера в эти четыре лишних байта записывается случайно сгенерированное двойное слово ( canary word ), которое также копируется в независимую глобальную переменную. По завершении работы с буфером нужно лишь сравнить глобальную переменную с четырьмя байтами хвоста буфера. Если совпадают - всё нормально, если нет - буфер переполнен, и необходимо предпринимать соответствующие меры. В качестве примера приведу пару несложных исходников:

Пример хрестоматийный, но актуальности своей не потерял, поскольку огромное число приложений до сих пор грешит такими ошибками. Что нужно, чтобы приложение могло защитить себя ? Всего ничего: заменить некоторые функции на их более безопасные аналоги, т.е. вместо strcpy ( buf, string );

нужно

strncpy ( buf, string, 9 );,

а вместо gets использовать fgets.

Можно модифицировать этот пример, обрамив вызов strcpy if/else:


If ( strlen ( string ) < 10 )
{
strcpy ( buf, string );
}
else
{
MessageBox, return...
}; и таким образом проконтролировать длину передаваемых в буфер данных.

Существует много разновидностей переполнений: переполнения массивов, структур; переполнения при работе с памятью ( а также неправильный доступ к ней, некорректное освобождение...), например:
while ( true )
{
malloc ( 1 );
}; арифметические переполнения: DWORD summa ( DWORD a, DWODR b )
{
return a+b;
} и др. Переполнить можно практически всё, каждый конкретный случай требует особого подхода, и программисты давно пытаются облегчить труд себе и другим, создавая патчи к ядру и компиляторам, отдельные утилиты; модифицируя или реализуя новые технологии защиты от переполнений ( например, неисполняемый стек ) и проч. и проч. Рассмотрим самые интересные из них, обеспечивающие как защиту от переполнений, так и детектирующие ошибки при работе с памятью ( утечку и т.д. ).

Начнём с *nix - систем. Про патчи к ядру я уже говорила - они, скорее, для системных администраторов, нежели для программистов. Для вторых же есть следующие инструменты:

1. Memwatch - определяет ошибки работы с памятью. Работает с Gcc, Microsoft Visual C++ ( 16, 32 ) и т.д. Многопоточность и C++ практически не поддерживаются.
2. dmalloc ( http://dmalloc.com ) - библиотека, замещающая собой стандартные функции для работы с памятью: malloc, calloc, realloc и др. Работает с утечками памяти, выходами за границы переполнения буферов и т.п. Существуют версии как под Windows, так и под многочисленные клоны и разновидности UNIX.
3. Stack Guard ( http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard ) - патч для Gcc, хорошо реализующий защиту с помощью canary word.
4. ProPolice - патч для Gcc, реализующий защиту от срыва стека и основанный на StackGuard. Входит в дистрибутив OpenBSD и Trusted Debian.

  Use CGI qw (:standart);
  $email=param ( 'email' );
  open ( MAIL,"|usr/sbin/sendmail -t $email" );
  print MAIL "From:administrator@yandex.ru\n";
  print MAIL "Subject:Thanks\n\n Thank you!\n";
  close ( MAIL );

   die print "Incorrect e-mail adress!\n" if ( $email=~/[\|;]/||
   $email~!/\@/);
   open ( MAIL,"|usr/sbin/sendmail" );
   print MAIL "To:$email\n";