Коллектив авторов - Защита от хакеров корпоративных сетей
- Название:Защита от хакеров корпоративных сетей
- Автор:
- Жанр:
- Издательство:неизвестно
- Год:неизвестен
- ISBN:нет данных
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Коллектив авторов - Защита от хакеров корпоративных сетей краткое содержание
В книге рассматривается современный взгляд на хакерство, реинжиниринг и защиту информации. Авторы предлагают читателям список законов, которые определяют работу систем компьютерной безопасности, рассказывают, как можно применять эти законы в хакерских технологиях. Описываются типы атак и возможный ущерб, который они могут нанести компьютерным системам. В книге широко представлены различные методы хакинга, такие, как поиск различий, методы распознавания шифров, основы их вскрытия и схемы кодирования. Освещаются проблемы безопасности, возникающие в результате непредсказуемого ввода данных пользователем, методы использования машинно-ориентированного языка, возможности применения мониторинга сетевых коммуникаций, механизмы туннелирования для перехвата сетевого трафика. В книге представлены основные сведения о хакерстве аппаратных средств, вирусах, троянских конях и червях. В этой книге читатель узнает о методах, которые в случае неправильного их применения приведут к нарушению законодательства и связанным с этим последствиям.
Лучшая защита – это нападение. Другими словами, единственный способ остановить хакера заключается в том, чтобы думать, как он. Эти фразы олицетворяют подход, который, по мнению авторов, позволит наилучшим образом обеспечить безопасность информационной системы.
Перевод: Александр Петренко
Защита от хакеров корпоративных сетей - читать онлайн бесплатно ознакомительный отрывок
Интервал:
Закладка:
effugas@OTHERSHOE ~
$ ssh-keygen
Generating public/private rsa1 key pair.
Enter file in which to save the key (/home/effugas/.ssh/
identity):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/effugas/.ssh/
identity.
Your public key has been saved in /home/effugas/.ssh/
identity.pub.
The key fingerprint is:
c7:d9:12:f8:b4:7b:f2:94:2c:87:43:14:5a:cf:11:1d
effugas@OTHERSHOE
effugas@OTHERSHOE ~
$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/effugas/.ssh/
id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/effugas/.ssh/
id_dsa.
Your public key has been saved in /home/effugas/.ssh/
id_dsa.pub.
The key fingerprint is:
e0:e2:a7:1b:02:ad:5b:0a:7f:f8:9c:d1:f8:3b:97:bd
effugas@OTHERSHOEЗатем наступает время второго шага: следует проинформировать сервер о необходимости проверить подключенных клиентов на предмет обладания ими личного ключа (.ssh/identity для SSH1, ssh/id_dsa для SSH2). Такая проверка заключается в посылке серверу его общедоступного элемента, который затем добавляется в файл домашней директории пользователя. Домашняя директория пользователя задается самим пользователем:.ssh/authorized_keys для SSH1 и. ssh/authorized_keys2 для SSH2. На самом деле не существует элегантного способа реализовать в протоколе SSH то, что было сказано. Это самая слабая сторона комплекса инструментальных средств, а вполне возможно, что и самого протокола непосредственно. Для преодоления данного недостатка Уильям Стеарнс (William Stearns) проделал в этом направлении очень большую работу. Его скрипт, посвященный этой проблеме, находится по адресу www.stearns.org/ssh-keyinstall/ssh-keyinstall-0.1.3.tar.gz. Реализованные в нем вещи аморальны, и он даже не пытается скрывать это. Приведенный ниже пример, используя недавно загруженные ключи пользователя, устраняет необходимость в идентификации пароля. Попутно появляется дополнительное преимущество, которое заключается в отсутствии необходимости использовать какие-либо дополнительные приложения (отметим, что от читателя потребуется ввести пароль):
effugas@OTHERSHOE ~
$ ssh –1 effugas@10.0.1.10
effugas@10.0.1.10”s password:
Last login: Mon Jan 14 05:38:05 2002 from 10.0.1.56
[effugas@localhost effugas]$А сейчас дышите глубже. Теперь читатель с помощью ssh-keygen должен прочитать сгенерированный ключ и передать его по каналу дальше, используя ssh с адресом 10.0.1.10 и имя пользователя effugas. После этого ему следует удостовериться в том, что он находится в домашней директории, и установить режимы работы с файлом таким образом, чтобы никто другой не смог прочитать то, что он собирается записать. При необходимости читатель может создать директорию (опция -p позволяет по желанию создавать директории), а затем он получит переданные по каналу данные и добавит их к файлу ~/.ssh/authorized_keys, которые демон будет использовать для аутентификации удаленного личного ключа. Почему сказанное не включено в число стандартных функциональных возможностей и является большой загадкой? Возможно, потому, что оно реализуется расширенной командой, состоящей из нескольких частей, которая, тем не менее, хорошо работает:
effugas@OTHERSHOE ~
$ cat ~/.ssh/identity.pub | ssh -1 effugas@10.0.1.10 “cd ~
&& umask 077&& mkdir -p .ssh && cat >> ~/.ssh/
authorized_keys”
effugas@10.0.1.10’s password:
Мама моя родная, никакого пароля не требуется:
effugas@OTHERSHOE ~
$ ssh -1 effugas@10.0.1.10
Last login: Mon Jan 14 05:44:22 2002 from 10.0.1.56
[effugas@localhost effugas]$Эквивалентным процессом для SSH2, который для пакета OpenSSH является протоколом по умолчанию, является следующий:
effugas@OTHERSHOE ~
$ cat ~/.ssh/id_dsa.pub | ssh effugas@10.0.1.10 “cd ~ &&
umask 077 &&mkdir -p .ssh && cat >> ~/.ssh/
authorized_keys2”
effugas@10.0.1.10’s password:
effugas@OTHERSHOE ~
$ ssh effugas@10.0.1.10
Last login: Mon Jan 14 05:47:30 2002 from 10.0.1.56
[effugas@localhost effugas]$Инструментарий и ловушки
Много пользователей, одна учетная запись: предотвращение утечки сведений о пароле
При реализации следует учитывать одну важную вещь: содержимое каждого пользовательского файла учетных записей может состоять из многих компонент, к каждой из которых предусмотрен независимый доступ путем предоставления ей своего указателя входа в файл. Если у пользователя много учетных записей, то часто он может воспользоваться этим для подтверждения серверу своей подлинности. К счастью, многие описываемые в этой главе сквозные методы ограничивают использование такой небезопасной методики. (Чем больше хостов могут подключиться к системе, тем больший ущерб может нанести ей компрометация подключившихся хостов.)
Однако до сих пор успешно используется тот факт, что пользовательские файлы учетных записей authorized_keys и authorized_keys2 состоят из нескольких компонент. Благодаря этому группе пользователей может быть предоставлен коллективный доступ к учетной записи без знания ее долгосрочного пароля. Новые члены группы добавляют к учетной записи свои общедоступные компоненты с необходимыми им разрешениями. После этого их личные ключи учитывают добавленные компоненты. При исключении пользователей из группы их общедоступные компоненты удаляются из списка авторизованных ключей. Никто из исключенных пользователей не должен помнить новый пароль!
Необходимо сделать следующее пояснение: постепенно от файлов known_hosts2 и authorized_keys2 отказываются, преобразуя их в файлы known_hosts и authorized_keys. Сервера, которым не нужны специфические файлы протокола SSH2, обращаются к новым файлам, отбрасывая 2 в конце имени файла.
Из-за недоверия к серверам остерегаются использовать пароли, но кто говорит, что клиент намного лучше? Хорошая криптография – это прекрасно, но по существу берется нечто, что запоминается в памяти пользователя и помещается на жесткий диск клиента. А ведь это нечто может быть перехвачено. Помните, что нет безопасного способа запомнить пароль клиента без использования другого пароля, защищающего запомненный пароль. Решений этой проблемы не так много. В одной из реализаций протокола SSH для ее решения используются идентификационные фразы (passwords). Они позволяют расшифровать личный ключ, с помощью которого удаленный сервер проверяет знание клиентом секрета. Идентификационная фраза состоит из анализируемых клиентом паролей. Читатель может добавить идентификационные фразы к обоим ключам протокола SSH2:
# add passphrase to SSH1 key
effugas@OTHERSHOE ~
$ ssh-keygen.exe -p
Enter file in which the key is (/home/effugas/.ssh/
identity):
Key has comment “effugas@OTHERSHOE”
Enter new passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved with the new passphrase.
# add passphrase to SSH2 key
effugas@OTHERSHOE ~
$ ssh-keygen.exe -t dsa -p
Enter file in which the key is (/home/effugas/.ssh/id_dsa):
Key has comment “/home/effugas/.ssh/id_dsa”
Enter new passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved with the new passphrase.
# Note the new request for passphrases
effugas@OTHERSHOE ~
$ ssh effugas@10.0.1.11
Enter passphrase for key “/home/effugas/.ssh/id_dsa”:
FreeBSD 4.3-RELEASE (CURRENT-12-2-01) #1: Mon Dec 3
13:44:59 GMT 2001
$Конечно, это возврат туда, откуда все начиналось. Читатель должен будет вводить пароль каждый раз, когда он захочет подключиться к удаленному хосту! Что теперь?
Читать дальшеИнтервал:
Закладка:
