Коллектив авторов - Защита от хакеров корпоративных сетей
- Название:Защита от хакеров корпоративных сетей
- Автор:
- Жанр:
- Издательство:неизвестно
- Год:неизвестен
- ISBN:нет данных
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Коллектив авторов - Защита от хакеров корпоративных сетей краткое содержание
В книге рассматривается современный взгляд на хакерство, реинжиниринг и защиту информации. Авторы предлагают читателям список законов, которые определяют работу систем компьютерной безопасности, рассказывают, как можно применять эти законы в хакерских технологиях. Описываются типы атак и возможный ущерб, который они могут нанести компьютерным системам. В книге широко представлены различные методы хакинга, такие, как поиск различий, методы распознавания шифров, основы их вскрытия и схемы кодирования. Освещаются проблемы безопасности, возникающие в результате непредсказуемого ввода данных пользователем, методы использования машинно-ориентированного языка, возможности применения мониторинга сетевых коммуникаций, механизмы туннелирования для перехвата сетевого трафика. В книге представлены основные сведения о хакерстве аппаратных средств, вирусах, троянских конях и червях. В этой книге читатель узнает о методах, которые в случае неправильного их применения приведут к нарушению законодательства и связанным с этим последствиям.
Лучшая защита – это нападение. Другими словами, единственный способ остановить хакера заключается в том, чтобы думать, как он. Эти фразы олицетворяют подход, который, по мнению авторов, позволит наилучшим образом обеспечить безопасность информационной системы.
Перевод: Александр Петренко
Защита от хакеров корпоративных сетей - читать онлайн бесплатно ознакомительный отрывок
Интервал:
Закладка:
Умалчиваемая правда заключается в том, что большинство людей продолжает доверять своим клиентам и полностью отказываются от идентификационных фраз. Это сильно раздражает администраторов информационных технологий, которые, отключая возможность использования паролей, думают, что тем самым они подталкивают людей к действительно хорошим криптографическим решениям, у которых нет огромных, настежь раскрытых дыр в системе защиты. На самом деле идентификационные фразы ничуть не лучше паролей. В протоколе SSH предусмотрены улучшенные варианты использования идентификационных фраз, которые позволяют распространить один-единственный ввод идентификационной фразы на сравнительно большое число попыток идентификации. Осуществляется это при помощи агента, который может быть размещен где угодно и который занят вычислением личного ключа для выполняющихся под его управлением клиентов SSH. (Это означает, и это важно, что только SSH-клиенты, выполняющиеся под управлением агента, получают доступ к его ключу.) Идентификационная фраза передается агенту, который расшифровывает личный ключ и позволяет клиентам получить доступ без фактического знания пароля. Ниже приведен пример простой реализации сказанного, в котором предполагается, что ключ создается так же, как и в предыдущем примере. Сгенерированный ключ действителен как при обращении к адресу 10.0.1.11, так и к адресу 10.0.1.10.
Прежде всего запустим агента. Обратите внимание на поименованную дочернюю оболочку. Если читатель не укажет ее имя, то будет получено сообщение об ошибке: «Нельзя открыть соединение к вашему агенту аутентификации (Could not open a connection to your authentication agent)».effugas@OTHERSHOE ~ $ ssh-agent bash
После запуска агента добавляем ключи. В случае отсутствия аргумента будет добавлен ключ SSH1:
effugas@OTHERSHOE ~
$ ssh-add
Enter passphrase for effugas@OTHERSHOE:
Identity added: /home/effugas/.ssh/identity
(effugas@OTHERSHOE)При наличии аргумента добавляется ключ SSH2:
effugas@OTHERSHOE ~
$ ssh-add ~/.ssh/id_dsa
Enter passphrase for /home/effugas/.ssh/id_dsa:
Identity added: /home/effugas/.ssh/id_dsa (/home/effugas/
.ssh/id_dsa)Теперь попытаемся подключиться к паре хостов, которые были запрограммированы для получения обоих ключей:
effugas@OTHERSHOE ~
$ ssh -1 effugas@10.0.1.10
Last login: Mon Jan 14 06:20:21 2002 from 10.0.1.56
[effugas@localhost effugas]$ ^D
effugas@OTHERSHOE ~
$ ssh -2 effugas@10.0.1.11
FreeBSD 4.3-RELEASE (CURRENT-12-2-01) #1: Mon Dec 3
13:44:59 GMT 2001
$Добившись подключения к удаленному хосту, следует решить, что делать дальше. С помощью SSH-соединения можно стартовать команду на удаленном сервере или выполнить различные сетевые действия. Можно даже сделать и то, и другое, иногда предоставляя самому себе сетевой путь к только что инициированному серверу.
Переадресация команд: применение переадресации команд для непосредственного выполнения скриптов и каналов
Переадресация (перенаправление) команд – одна из наиболее полезных возможностей протокола SSH. Она вытекает из его основополагающих принципов построения, когда был заново реализован целый ряд приложений r* операционной системы UNIX. У протокола SSH есть хорошо понятная возможность выполнения удаленных команд так, как будто это локальные команды. Например, вместо ввода
effugas@OTHERSHOE ~
$ ssh effugas@10.0.1.11
effugas@10.0.1.11”s password:
FreeBSD 4.3-RELEASE (CURRENT-12-2-01) #1: Mon Dec 3
13:44:59 GMT 2001
$ uptime
3:19AM up 18 days, 8:48, 5 users, load averages: 2.02,
2.04, 1.97
$можно ограничиться следующими командами:
effugas@OTHERSHOE ~
$ ssh effugas@10.0.1.11 uptime
effugas@10.0.1.11”s password:
3:20AM up 18 days, 8:49, 4 users, load averages: 2.01,
2.03, 1.97Действительно, можно образовать канал вывода между хостами, например так, как это показано в приведенном ниже простейшем примере:
effugas@OTHERSHOE ~
$ ssh effugas@10.0.1.11 “ls –l” | grep usocks
effugas@10.0.1.11”s password:
drwxr-xr-x 2 effugas effugas 1024 Aug 5 20:36
usocksd-0.9.3
-rw-r—r– 1 effugas effugas 54049 Jan 14 20:21
usocksd-0.9.3.tar.gzПодобные функциональные возможности необычайно полезны для создания сетевых туннелей. Основная идея туннелей заключается в том, что нечто создает поток данных через обычно непреодолимые границы сетей. В данном случае разделенные границами сети немного напоминают аппаратные средства, поделенные на совершенно не связанные между собой блоки. (Требуется приложить много усилий для эффективного обособления программ и информационных файлов. Если этого удается добиться, то отказ в одной части программного кода почти никак не влияет на работу всего кода в целом и не приводит к отказу еще чего-нибудь благодаря абсолютной защите памяти, планированию работы центрального процессора и т. д. Между тем простое выполнение почтового сервера или Web-сервера читателя на различных системах при условии, что их много и они могут быть распределены по всему земному шару, предоставляет совершенно другой класс разделения процессов.) SSH превращает каналы в коммуникационную подсистему между хостами. В этих условиях становится справедливым следующее правило . Почти всегда можно использовать канал для передачи данных между процессами. При этом протокол SSH позволяет процессам разных хостов оставаться локальными.
Примечание
Не все используемые команды могут быть объединены путем создания канала. Тем из них, которые захватывают терминал и выводят на него данные, как, например, командам lynx, elm, pine или tin, для правильной работы требуется так называемая поддержка функций телетайпа TTY Названные команды в различных режимах рисования и стилях применяют так называемые неиспользуемые символы. По существу эти символы не используют 8 бит байта так, как это необходимо при применении каналов. Протокол SSH по-прежнему поддерживает использующие функции TTY-команды, но для этого требуется определить опцию -t.
Удаленное выполнение объединенных в канал команд может оказаться очень эффективным. В этом случае простейшие команды неожиданно приобретают способность преодолевать границы серверов и могут быть использованы с большой пользой. Например, большинство операций передачи файлов могут быть реализованы с использованием небольшого числа базовых инструментальных средств, которые присутствуют почти во всех дистрибутивах систем UNIX и Cygwin. Некоторые из базовых элементов перечислены в табл. 13.3.
Таблица 13.3.
Полезные для переадресации команд SSH компоненты скриптов командной оболочки
После рассмотрения элементарных основ можно приступать к обзору реализации некоторых базовых элементов систем передачи файлов (см. табл. 13.4).
Таблица 13.4.
Передача файлов с использованием общих компонентов командной оболочки
Одно из самых полезных свойств протокола SSH заключается в том, что когда протокол удаленно выполняет команды, то он делает это в сильно ограниченном контексте. На самом деле пользующиеся доверием пути компилируются в загрузочный код демона протокола SSH, который выполняется без указания абсолютного пути. В это время абсолютный путь хранится в директориях /usr/local/bin, /usr/bin и /bin. (В протоколе SSH также реализована возможность переадресации переменных окружения. Поэтому если командной оболочке нужен какой-либо путь, то на сервер может быть послано имя переменной, в которой он записан. Это небольшая жертва безопасности в угоду довольно приличного скачка функциональных возможностей.)
Читать дальшеИнтервал:
Закладка:
