Сообщение Finished

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

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

struct { opaque verify_data[12];} Finished;

verify_data	PRF(master_secret, finished_label, MD5(handshake_messages) + SHA1(handshake_messages)) [0..11];
finished_label	Для сообщений Finished, посланных клиентом, это строка "client finished". Для сообщений Finished, посланных сервером, это строка "server finished".
handshake_messages	Все данные от сообщений диалога до этого сообщение (но не включительно). Это единственные данные, видимые на уровне диалога, они не включают заголовки уровня записей. Это соединение всех структур диалога, определенных в 7.4.

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

Хэши, содержащиеся в сообщениях finished, посланных серверам, включает в себя Sender.server; а посланные клиентом содержат Sender.client. Значение handshake_messages включает все сообщения диалога, начиная с hello клиента и вплоть до (но не включая) это сообщение finished. Здесь могут быть отличия от handshake_messages из раздела 7.4.8, так как сюда может входить сообщение верификации сертификата. Следует также иметь в виду, что, handshake_messages для сообщения finished, посланного клиентом, будет отличаться от посланного сервером, так как второе, включает первое.

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

Сообщение ключевого обмена сервера

Это сообщение будет послано немедленно после сообщения сертификата сервера (или сообщения server hello, если это анонимное согласование параметров).

Сообщение ключевого обмена сервера посылается сервером только когда сообщение сертификата сервера (если послано) не содержит достаточно данных, чтобы позволить клиенту осуществлять обмен предмастерными секретными кодами (premaster secret). Это верно для следующих методов обмена ключами:

RSA_EXPORT (если открытый ключ в сертификате длиннее, чем 512 бит)
DHE_DSS
DHE_DSS_EXPORT
DHE_RSA
DHE_RSA_EXPORT
DH_anon

Нелегально посылать сообщение ключевого обмена сервера для следующих методов пересылки ключей:

RSA
RSA_EXPORT (когда открытый ключ в сертификате сервера короче чем или равен 512 бит)
DH_DSS
DH_RSA

Это сообщение передает криптографическую информацию, чтобы позволить клиенту оперировать с premaster секретным кодом: либо общедоступный ключ RSA, чтобы зашифровать предмастерный секретный код, либо общедоступный ключ Diffie-Hellman, с помощью которого клиент может завершить обмен ключами.

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

Согласно настоящему закону США об экспорте, модули RSA больше 512 бит не могут использоваться для ключевого обмена в программах, экспортируемых из США. Более длинные ключи RSA, зашифрованные в сертификатах, могут быть использованы для подписи более коротких ключей RSA в случае метода ключевого обмена RSA_EXPORT.

Структура этого сообщения:
enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
struct { opaque rsa_modulus<1..2^16-1>; opaque rsa_exponent<1..2^16-1>;} ServerRSAParams;

rsa_modulus	Модуль временного RSA-ключа сервера.
rsa_exponent	Общедоступный показатель временного RSA-ключа сервера.

struct { opaque dh_p<1..2^16-1>;

opaque dh_g<1..2^16	1>;
opaque dh_Ys<1..2^16	1>;} ServerDHParams; /* Временные DH параметры */

dh_p	Простой модуль, используемый для операции Diffie-Hellman.
dh_g	Генератор, используемый для операции Diffie-Hellman.
dh_Ys	Общедоступное значение (gX mod p) метода Diffie-Hellman для сервера.

struct { select (KeyExchangeAlgorithm) {

	case diffie_hellman:
	ServerDHParams params;
	Signature signed_params;
	case rsa:
	ServerRSAParams params;
	Signature signed_params; };
	} ServerKeyExchange;

Params	Параметры ключевого обмена сервера.
signed_params	Для не анонимных ключевых обменов, хэш соответствующих значений параметров с подписью, согласованной с примененным хэшем.
md5_hash	MD5(ClientHello.random + ServerHello.random + ServerParams);
sha_hash	SHA(ClientHello.random + ServerHello.random + ServerParams);

enum { anonymous, rsa, dsa } SignatureAlgorithm;

select (SignatureAlgorithm)

	{ case anonymous: struct { };
	case rsa:
	digitally-signed struct
	{
	opaque md5_hash[16];
	opaque sha_hash[20];
	};
	case dsa:
	digitally-signed struct {
	opaque sha_hash[20];
	};
	} Signature;

Сообщение обмена ключами клиента

Это сообщение посылается клиентом всегда. За ним непосредственно следует сообщение сертификата клиента, если оно посылается. В противном случае оно будет первым сообщением, посылаемым клиентом после получения сообщения сервера hello done.

С помощью этого сообщения устанавливается предмастерный секретный код, либо путем прямой передачи его, зашифровав с применением RSA, либо с помощью передачи параметров Diffie-Hellman, которые позволят каждой из сторон согласовать применение одного и того же предмастерного секретного кода. Когда в качестве метода передачи ключей использован DH_RSA или DH_DSS, запрашивается сертификация клиента, и клиент может откликаться посылкой сертификата, который содержит общедоступный ключ Diffie-Hellman, чьи параметры (группа и генератор) соответствуют, специфицированным в сертификате сервера. Это сообщение не содержит никаких других данных.

Структура этого сообщения:

Выбор сообщений зависит от выбранного метода ключевого обмена. Смотри раздел 7.4.3, где дано определение KeyExchangeAlgorithm.

struct { select (KeyExchangeAlgorithm) { case rsa: EncryptedPreMasterSecret;
case diffie_hellman: ClientDiffieHellmanPublic; } exchange_keys;
} ClientKeyExchange;

Сообщение зашифрованного RSA предмастерного секретного кода

Если для согласования ключей и аутентификации применен алгоритм RSA, клиент генерирует 48-байтовый предмастерный секретный код, шифрует его с помощью общедоступного ключа из сертификата сервера или временного RSA-ключа, переданного в сообщении ключевого обмена сервера, и посылает результат в сообщении зашифрованного предмастерного секретного кода (encrypted premaster secret). Эта структура является вариантом сообщения ключевого обмена клиента.

Структура этого сообщения:
struct { ProtocolVersion client_version; opaque random[46];} PreMasterSecret;

client_version	Последняя (новейшая) версия, поддерживаемая клиентом. Она используется для детектирования атак связанных с понижением номера версии. По получении предмастерного секретного кода сервер должен проверить, что данное значение согласуется с величиной, переданной клиентом в сообщении hello.
random	46 байт псевдослучайного кода.

struct { public-key-encrypted PreMasterSecret pre_master_secret;} EncryptedPreMasterSecret;

Атака, рассмотренная Даниэлем Блайбенбахером (Daniel Bleichenbacher) [BLEI], может быть предпринята против TLS-сервера, который использует PKCS#1, закодированный с помощью RSA.

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

pre_master_secret

Это случайное число генерируется клиентом и используется для формирования мастерного секретного кода, как это специфицировано в разделе 8.1.

Сообщения Hello

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

Сообщения протокола диалога SSL

Сообщения протокола диалога SSL инкапсулируются в рекорды протокола SSL и состоят из двух частей: однобайтового кода типа сообщения, и некоторых данных. Клиент и сервер обмениваются сообщениями, пока обе стороны не пошлют сообщения finished, указывающие, что они удовлетворены диалогом SSL (Handshake Protocol).

После того как каждый из партеров определил пару ключей сессии, тела сообщений кодируются с помощью этих ключей. Для клиента это происходит, после того как он верифицировал идентификатор сессии, сформировал новый ключ сессии и послал его серверу. Для сервера это происходит, после того как идентификатор сессии признан корректным, или сервер получил сообщение клиента с ключом сессии. Для сообщений SSLHP (SSL Handshake Protocol) используется следующая нотация:

char MSG-EXAMPLE
char FIELD1
char FIELD2
char THING-MSB
char THING-LSB
char THING-DATA[(MSB<<8)|LSB];
...

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

Для записи "THING-DATA", значения MSB и LSB в действительности равны THING-MSB и THING-LSB (соответственно) и определяют число байт данных, имеющихся в сообщении. Например, если THING-MSB был равен нулю, а THING-LSB был равен 8, тогда массив THING-DATA будет иметь 8 байт.

Длина кодов характеризуется целым числом без знака, и когда MSB и LSB объединяются, результат также является целым числом без знака. Если не указано обратного, длины полей измеряются в байтах.

Состояние дел

Упрощенная диаграмма атаки типа “TCP SYN шторм” изображена ниже:

                                                204.69.207.0/24

ЭВМ <----- router <--- Internet <----- router <-- Атакер

         TCP/SYN

     <---------------------------------------------

           Отправитель: 192.168.0.4/32

SYN/ACK

Маршрута нет

         TCP/SYN

     <---------------------------------------------

           Отправитель: 10.0.0.13/32

SYN/ACK

Маршрута нет

         TCP/SYN

     <---------------------------------------------

           Отправитель: 172.16.0.2/32

SYN/ACK

Маршрута нет

[и т.д.]

Предположим, что:

"ЭВМ" является атакуемой машиной.

Атакер находится в пределах префикса, 204.69.207.0/24.

Атакер осуществляет атаку, используя каждый раз случайное значение IP-адреса отправителя; в данном примере, адреса отправителя обозначаются также как в [4], отсутствуют в глобальных таблицах маршрутизации, и, следовательно, не достижим. Однако для реализации данного метода атаки могут использоваться любые недостижимые префиксы.

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

Дальнейшим осложнением ситуации является то, что атаки типа шторма TCP SYN приводят к тому, что пакеты SYN-ACK посылаются одной или многим ЭВМ, которые не имеют никакого отношения к атаке, но которые становятся вторичными жертвами. Это позволяет атакеру использовать в своих целях две или более системы одновременно.

Аналогичные атаки реализовывались с использованием UDP и ICMP лавин. Первая атака (UDP лавина) использует фальсифицированные пакеты, чтобы попытаться подключиться к допустимой UDP услуге и вызвать отклик, адресованный другому сайту. Системные администраторы не должны никогда допускать внешним UDP-дейтограммам попадать в диагностические порты их системы. Последний вид атак (ICMP шторм), использует хитрую особенность откликов на широковещательные IP вызовы. Эта атака базируется на маршрутном обслуживании больших широковещательных сетей с множественным доступом, где IP-адреса места назначения такие как 10.255.255.255 преобразуются в широковещательные кадры уровня 2 (для Ethernet, FF:FF:FF:FF:FF:FF). Оборудование Ethernet NIC (в частности, оборудование MAC-уровня) в нормальных условиях прослушивает только определенное число адресов. Единственным MAC-адресом, используемым всеми устройствами, является широковещательный адрес FF:FF:FF:FF:FF:FF. В этом случае, устройство воспринимает кадр и посылает прерывание процессору. Таким образом, шторм таких широковещательных кадров может исчерпать все доступные ресурсы оконечной системы [9]. Возможно, благоразумно потребовать, чтобы конфигурация пограничных шлюзов (GW) не допускала прямого прохождения широковещательных через эти устройства.

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

            В противном случае, если атакер использует чей-то еще корректный адрес ЭВМ в качестве адреса отправителя, атакуемая система пошлет большое число пакетов SYN/ACK предполагаемому инициатору установления соединения. Таким образом, атакер оказывает разрушительное воздействие на две системы.

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

Состояния соединений

Состояние соединения TLS является операционной средой протокола записей TLS. Оно специфицирует алгоритмы сжатия, шифрования и MAC. Кроме того, известны параметры этих алгоритмов: секретный код MAC, а также ключи шифрования и IV соединения для направлений чтения и записи. Логически существует четыре состояния соединения: текущие состояния чтения и записи, и отложенные состояния чтения и записи. Все записи обрабатываются в текущих состояниях чтения или записи. Параметры безопасности для отложенных состояний могут быть установлены протоколом диалога TLS. Протокол диалога может селективно переводить любое отложенное состояние в текущее, при этом соответствующее текущее состояние становится отложенным. Не допускается формировать состояние, которое не инициализировано с учетом параметров безопасности текущего состояния. Исходное текущее состояние всегда специфицировано без компрессии, шифрования или MAC. Параметры безопасности для состояния чтения и записи соединения TLS задаются путем определения следующих величин:

Конец соединения	Клиент или сервер участник соединения.
Алгоритм массового шифрования	Алгоритм, используемый для массового шифрования. Эта спецификация включает размер ключа алгоритма, степень секретности ключа, является ли этот шифр блочным или поточным, размер блока и является ли шифр экспортным.
Алгоритм MAC	Алгоритм аутентификации сообщений. Эта спецификация включает размер хэша, который возвращается алгоритмом MAC.
Алгоритм сжатия	Алгоритм сжатия данных. Эта спецификация должна включать всю информацию, необходимую для выполнения компрессии.
Секретный код сервера (master secret)	48 байтовый секретный код, общий для обоих партеров в соединении.
Случайный код клиента	32 байтный код, предоставляемый клиентом.
Случайный код сервера	32 байтный код, предоставляемый сервером.

Эти параметры определены в языке представления в виде:

enum { server, client } ConnectionEnd;
enum { null, rc4, rc2, des, 3des, des40 } BulkCipherAlgorithm;
enum { stream, block } CipherType;


enum { true, false } IsExportable;
enum { null, md5, sha } MACAlgorithm;
enum { null(0), (255) } CompressionMethod;

/* Алгоритмы, специфицированные в CompressionMethod, BulkCipherAlgorithm и MACAlgorithm могут быть добавлены. */

struct {	ConnectionEnd	entity;
	BulkCipherAlgorithm	bulk_cipher_algorithm;
	CipherType	cipher_type;
	uint8	key_size;
	uint8	key_material_length;
	IsExportable	is_exportable;
	MACAlgorithm	mac_algorithm;
	uint8	hash_size;
	CompressionMethod	compression_algorithm;
	Opaque	master_secret[48];
	opaque	client_random[32];
	opaque	server_random[32];} SecurityParameters;

Уровень записей будет использовать параметры безопасности для формирования следующих шести объектов:

Секретный код MAC записи клиента
Секретный код MAC записи сервера
Ключ записи клиента
Ключ записи сервера
IV записи клиента (только для блочного шифра)
IV записи сервера (только для блочного шифра)

Параметры записи клиента используются сервером при получении и обработке записей и наоборот. Алгоритм, использованный для генерирования этих объектов с помощью параметров безопасности, описан в разделе 6.3. Раз параметры безопасности определены и ключи сформированы, состояния соединения могут быть в любой момент реализованы путем перевода их в текущее состояние. Эти текущие состояния должны актуализоваться после обработки каждой записи. Каждое состояние соединения включает в себя следующие элементы:

Состояние сжатия	Текущее состояние алгоритма сжатия.
Состояние шифра	Текущее состояние алгоритма шифрования. Оно состоит из текущего ключа для данного соединения. Кроме того, для блочного шифра, работающего в режиме CBC (единственный режим, специфицированный в TLS), оно в исходный момент содержит IV для данного состояния соединения и должно актуализоваться, чтобы содержать текст последнего шифрованного или дешифрованного блока. Для поточных шифров, оно содержит всю необходимую информацию для продолжения шифрования или дешифрования данных.
Секретный код MAC	Секретный код MAC для данного соединения.
Номер по порядку	Каждое состояние соединения содержит номер по порядку, который поддерживается независимо для состояний чтения и записи. Номер по порядку должен быть установлен равным нулю, как только соединение переведено в активное состояние. Номера по порядку имеют тип uint64 и не может превышать 264-1. Номер по порядку инкрементируется после прихода каждой записи: в частности, первая запись, передаваемая через некоторое соединение, имеет порядковый номер 0.

Спецификация протокола диалога SSL Протокол диалога SSL

Протокол диалога SSL имеет две основные фазы. Первая фаза используется для установления конфиденциального канала коммуникаций. Вторая - служит для аутентификации клиента.

Фаза 1

Первая фаза является фазой инициализации соединения, когда оба партнера посылают сообщения "hello". Клиент инициирует диалог посылкой сообщения CLIENT-HELLO. Сервер получает сообщение CLIENT-HELLO, обрабатывает его и откликается сообщением SERVER-HELLO.

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

Когда нужен новый мастерный ключ, сообщение SERVER-HELLO будет содержать достаточно данных, чтобы клиент мог сформировать такой ключ. Сюда входит подписанный сертификат сервера, список базовых шифров (см. ниже), и идентификатор соединения (последний представляет собой случайное число, сформированное сервером и используемое на протяжении сессии). Клиент генерирует мастерный ключ и посылает сообщение CLIENT-MASTER-KEY (или сообщение ERROR, если информация сервера указывает, что клиент и сервер не могут согласовать базовый шифр).

Здесь следует заметить, что каждая оконечная точка SSL использует пару шифров для каждого соединения (т.е. всего 4 шифра). На каждой конечной точке, один шифр используется для исходящих коммуникаций и один - для входящих. Когда клиент или сервер генерирует ключ сессии, они в действительности формируют два ключа, SERVER-READ-KEY (известный также как CLIENT-WRITE-KEY) и SERVER-WRITE-KEY (известный также как CLIENT-READ-KEY). Мастерный ключ используется клиентом и сервером для генерации различных ключей сессий.

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

Фаза 2

Вторая фаза является фазой аутентификации. Сервер уже аутентифицирован клиентом на первой фазе, по этой причине здесь осуществляется аутентификация клиента.
При типичном сценарии, серверу необходимо получить что-то от клиента, и он посылает запрос. Клиент пришлет позитивный отклик, если располагает необходимой информацией, или пришлет сообщение об ошибке, если нет. Эта спецификация протокола не определяет семантику сообщения ERROR, посылаемого в ответ на запрос сервера (например, конкретная реализация может игнорировать ошибку, закрыть соединение, и т.д. и, тем не менее, соответствовать данной спецификации). Когда один партнер выполнил аутентификацию другого партнера, он посылает сообщение finished. В случае клиента сообщение CLIENT-FINISHED содержит зашифрованную форму идентификатора CONNECTION-ID, которую должен верифицировать сервер. Если верификация терпит неудачу, сервер посылает сообщение ERROR.

Раз партнер послал сообщение finished он должен продолжить воспринимать сообщения до тех пор, пока не получит сообщение finished от партнера. Как только оба партнера послали и получили сообщения finished, протокол диалога SSL закончил свою работу. С этого момента начинает работать прикладной протокол.

Спецификация протокола записей SSL Формат заголовка записи SSL

В SSL все данные пересылаются в виде рекордов (записей), объектов, которые состоят из заголовка и некоторого количества данных. Каждый заголовок рекорда содержит два или три байта кода длины. Если старший бит в первом байте кода длины рекорда равен 1, тогда рекорд не имеет заполнителя и полная длина заголовка равна 2 байтам, в противном случае рекорд содержит заполнитель и полная длина заголовка равна 3 байтам. Передача всегда начинается с заголовка.

Заметим, что в случае длинного заголовка (3 байта), второй по старшинству бит первого байта имеет специальное значение. Когда он равен нулю, посылаемый рекорд является информационным. При равенстве 1, посылаемый рекорд является security escape (в настоящее время не определено ни одного значения security escapes; это зарезервировано для будущих версий протокола).

Код длины рекорда не включает в себя число байт заголовка (2 или 3). Для 2-байтового заголовка его длина вычисляется следующим образом (используется Си-подобная нотация):

RECORLENGTH = ((byte[0] & 0x7F << 8)) | byte[1];

Где byte[0] представляет собой первый полученный байт, а byte[1] - второй полученный байт. Когда используется 3-байтовый заголовок, длина рекорда вычисляется следующим образом:

RECORD-LENGTH = ((byte[0] & 0x3F) << 8)) | byte[1];
IS-ESCAPE = (byte[0] & 0x40) != 0;
PADDING = byte[2];

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

Отправитель "заполненного" рекорда добавляет заполнитель после имеющихся данных, а затем шифрует все это, благо длина этого массива кратна размеру блока используемого шифра. Содержимое заполнителя не играет роли. Так как объем передаваемых данных известен, заголовок сообщения может быть корректно сформирован с учетом объема субполя PADDING.

Получатель этого рекорда дешифрует все поле данных и получает исходную информацию. После этого производится вычисление истинного значения RECORD-LENGTH (с учетом наличия опционного PADDING), при этом заполнитель из поля данные удаляется.

Средства и их размещение

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

Большинство программных средств и приложений, описанных ниже можно найти в одном из ниже указанных депозитариев:

(1)	Координационный центр CERT ftp://info.cert.org:/pub/tools
(2)	DFN-CERT   ftp://ftp.cert.dfn.de/pub/tools/
(3)	Компьютерные средства безопасности и проверки COAST (Computer Operations, Audit, and Security Tools) coast.cs.purdue.edu:/pub/tools

Важно заметить, что многие узлы, включая CERT и COAST, имеют зеркальные копии, разбросанные по Интернет. Будьте осторожны при использовании "хорошо известных" зеркальных узлов для копирования программ, а для проверки программ используйте средства верификации (контрольные суммы md5 и т.д.). Умный атакер может рекламировать программы безопасности, которые были намеренно сконструированы, так, чтобы обеспечить доступ к данным или системам.

Программные средства

 COPS

 DES

 Drawbridge

 identd (не является на самом деле средством безопасности)

 ISS

 Kerberos

 logdaemon

 lsof

 MD5

 PEM

 PGP

 rpcbind/portmapper замещение

 SATAN

 sfingerd

 S/KEY

 smrsh

 ssh

 swatch

 TCP-Wrapper

 tiger

 Tripwire*

 TROJAN.PL

Ссылки

[Appelman, et. al., 1995]	Appelman, Heller, Ehrman, White, and McAuliffe, "The Law and The Internet", USENIX 1995 Technical Conference on UNIX and Advanced Computing, New Orleans, LA, January 16-20, 1995.
[ABA, 1989]	American Bar Association, Section of Science and Technology, "Guide to the Prosecution of Telecommunication Fraud by the Use of Computer Crime Statutes", American Bar Association, 1989.
[Aucoin, 1989]	R. Aucoin, "Computer Viruses: Checklist for Recovery", Computers in Libraries, Vol. 9, No. 2, Pg. 4, February 1989.
[Barrett, 1996]	D. Barrett, "Bandits on the Information Superhighway", O'Reilly & Associates, Sebastopol, CA, 1996.
[Bates, 1992]	R. Bates, "Disaster Recovery Planning: Networks, Telecommunications and Data Communications", McGraw-Hill, 1992.
[Bellovin, 1989]	S. Bellovin, "Security Problems in the TCP/IP Protocol Suite", Computer Communication Review, Vol 19, 2, pp. 32-48, April 1989.
[Bellovin, 1990]	S. Bellovin, and M. Merritt, "Limitations of the Kerberos Authentication System", Computer Communications Review, October 1990.
[Bellovin, 1992]	S. Bellovin, "There Be Dragon", USENIX: Proceedings of the Third Usenix Security Symposium, Baltimore, MD. September, 1992.
[Bender, 1894]	D. Bender, "Computer Law: Evidence and Procedure", M. Bender, New York, NY, 1978-present.
[Bloombecker, 1990]	B. Bloombecker, "Spectacular Computer Crimes", Dow Jones- Irwin, Homewood, IL. 1990.
[Brand, 1990]	R. Brand, "Coping with the Threat of Computer Security Incidents: A Primer from Prevention through Recovery", R. Brand, 8 June 1990.
[Brock, 1989]	J. Brock, "November 1988 Internet Computer Virus and the Vulnerability of National Telecommunications Networks to Computer Viruses", GAO/T-IMTEC-89-10, Washington, DC, 20 July 1989.
[BS 7799]	British Standard, BS Tech Cttee BSFD/12, Info. Sec. Mgmt, "BS 7799 : 1995 Code of Practice for Information Security Management", British Standards Institution, London, 54, Effective 15 February 1995.
[Caelli, 1988]	W. Caelli, Editor, "Computer Security in the Age of Information", Proceedings of the Fifth IFIP International Conference on Computer Security, IFIP/Sec '88.
[Carroll, 1987]	J. Carroll, "Computer Security", 2nd Edition, Butterworth Publishers, Stoneham, MA, 1987.
[Cavazos, 1995]	E. Cavazos and G. Morin, "Cyber-Space and The Law", MIT Press, Cambridge, MA, 1995.
[CCH, 1989]	Commerce Clearing House, "Guide to Computer Law", (Topical Law Reports), Chicago, IL., 1989.
[Chapman, 1992]	B. Chapman, "Network(In) Security Through IP Packet Filtering", USENIX: Proceedings of the Third UNIX Security Symposium, Baltimore, MD, September 1992.
[Chapman, 1995]	B. Chapman and E. Zwicky, "Building Internet Firewalls", O'Reilly and Associates, Sebastopol, CA, 1995.
[Cheswick, 1990]	B. Cheswick, "The Design of a Secure Internet Gateway", Proceedings of the Summer Usenix Conference, Anaheim, CA, June 1990.
[Cheswick1]	W. Cheswick, "An Evening with Berferd In Which a Cracker is Lured, Endured, and Studied", AT&T Bell Laboratories.
[Cheswick, 1994]	W. Cheswick and S. Bellovin, "Firewalls and Internet Security: Repelling the Wily Hacker", Addison-Wesley, Reading, MA, 1994.
[Conly, 1989]	C. Conly, "Organizing for Computer Crime Investigation and Prosecution", U.S. Dept. of Justice, Office of Justice Programs, Under Contract  Number OJP-86-C-002, National Institute of Justice, Washington, DC, July 1989.
[Cooper, 1989]	J. Cooper, "Computer and Communications Security: Strategies for the 1990s", McGraw-Hill, 1989.
[CPSR, 1989]	Computer Professionals for Social Responsibility, "CPSR Statement on the Computer Virus", CPSR, Communications of the ACM, Vol. 32, No. 6, Pg. 699, June 1989.
[CSC-STD-002-85, 1985]	Department of Defense, "Password Management Guideline", CSC-STD-002-85, 12 April 1985, 31 pages.
[Curry, 1990]	D. Curry, "Improving the Security of Your UNIX System", SRI International Report ITSTD-721-FR-90-21, April 1990.
[Curry, 1992]	D. Curry, "UNIX System Security: A Guide for Users and Systems Administrators", Addision-Wesley, Reading, MA, 1992.
[DDN88]	Defense Data Network, "BSD 4.2 and 4.3 Software Problem Resolution", DDN MGT Bulletin #43, DDN Network Information Center, 3 November 1988.
[DDN89]	DCA DDN Defense Communications System, "DDN Security Bulletin 03", DDN Security Coordination Center, 17 October 1989.
[Denning, 1990]	P. Denning, Editor, "Computers Under Attack: Intruders, Worms, and Viruses", ACM Press, 1990.
[Eichin, 1989]	M. Eichin, and J. Rochlis, "With Microscope and Tweezers: An Analysis of the Internet Virus of November 1988", Massachusetts Institute of Technology, February 1989.
[Eisenberg, et. al., 89]	T. Eisenberg, D. Gries, J. Hartmanis, D. Holcomb, M. Lynn, and T. Santoro, "The Computer Worm", Cornell University, 6 February 1989.
[Ermann, 1990]	D. Ermann, M. Williams, and C. Gutierrez, Editors, "Computers, Ethics, and Society", Oxford University Press, NY, 1990.  (376 pages, includes bibliographical references).
[Farmer, 1990]	D. Farmer and E. Spafford, "The COPS Security Checker System", Proceedings of the Summer 1990 USENIX Conference, Anaheim, CA, Pgs. 165-170, June 1990.
[Farrow, 1991]	Rik Farrow, "UNIX Systems Security", Addison-Wesley, Reading, MA, 1991.
[Fenwick, 1985]	W. Fenwick, Chair, "Computer Litigation, 1985: Trial Tactics and Techniques", Litigation Course Handbook Series No. 280, Prepared for distribution at the Computer Litigation, 1985: Trial Tactics and Techniques Program, February-March 1985.
[Fites 1989]	M. Fites, P. Kratz, and A. Brebner, "Control and Security of Computer Information Systems", Computer Science Press, 1989.
[Fites, 1992]	Fites, Johnson, and Kratz, "The Computer Virus Crisis", Van Hostrand Reinhold, 2nd edition, 1992.
[Forester, 1990]	T. Forester, and P. Morrison, "Computer Ethics: Tales and Ethical Dilemmas in Computing", MIT Press, Cambridge, MA, 1990.
[Foster, 1990]	T. Forester, and P. Morrison, "Computer Ethics: Tales and Ethical Dilemmas in Computing", MIT Press, Cambridge, MA, 1990.  (192 pages including index.)
[GAO/IMTEX-89-57, 1989]	U.S. General Accounting Office, "Computer Security - Virus Highlights Need for Improved Internet Management", United States General Accounting Office, Washington, DC, 1989.
[Garfinkel, 1991]	S. Garfinkel, and E. Spafford, "Practical Unix Security", O'Reilly & Associates, ISBN 0-937175-72-2, May 1991.
[Garfinkel, 1995]	S. Garfinkel, "PGP:Pretty Good Privacy", O'Reilly & Associates, Sebastopol, CA, 1996.
[Garfinkel, 1996]	S. Garfinkel and E. Spafford, "Practical UNIX and Internet Security", O'Reilly & Associates, Sebastopol, CA, 1996.
[Gemignani, 1989]	M. Gemignani, "Viruses and Criminal Law", Communications of the ACM, Vol. 32, No. 6, Pgs. 669-671, June 1989.
[Goodell, 1996]	J. Goodell, "The Cyberthief and the Samurai: The True Story of Kevin Mitnick-And The Man Who Hunted Him Down", Dell Publishing, 1996.
[Gould, 1989]	C. Gould, Editor, "The Information Web: Ethical and Social Implications of Computer Networking", Westview Press, Boulder, CO, 1989.
[Greenia, 1989]	M. Greenia, "Computer Security Information Sourcebook", Lexikon Services, Sacramento, CA, 1989.
[Hafner, 1991]	K. Hafner and J. Markoff, "Cyberpunk: Outlaws and Hackers on the Computer Frontier", Touchstone, Simon & Schuster, 1991.
[Hess]	D. Hess, D. Safford, and U. Pooch, "A Unix Network Protocol Security Study: Network Information Service", Texas A&M University.
[Hoffman, 1990]	L. Hoffman, "Rogue Programs: Viruses, Worms, and Trojan Horses", Van Nostrand Reinhold, NY, 1990.  (384 pages, includes bibliographical references and index.)
[Howard, 1995]	G. Howard, "Introduction to Internet Security: From Basics to Beyond", Prima Publishing, Rocklin, CA, 1995.
[Huband, 1986]	F. Huband, and R. Shelton, Editors, "Protection of Computer Systems and Software: New Approaches for Combating Theft of Software and Unauthorized Intrusion", Papers presented at a workshop sponsored by the National Science Foundation, 1986.
[Hughes, 1995]	L. Hughes Jr., "Actually Useful Internet Security Techniques", New Riders Publishing, Indianapolis, IN, 1995.
[IAB-RFC1087, 1989]	Internet Activities Board, "Ethics and the Internet", RFC 1087, IAB, January 1989.  Also appears in the Communications of the ACM, Vol. 32, No. 6, Pg. 710, June 1989.
[Icove, 1995]	D. Icove, K. Seger, and W. VonStorch, "Computer Crime: A Crimefighter's Handbook", O'Reilly & Associates, Sebastopol, CA, 1995.
[IVPC, 1996]	IVPC, "International Virus Prevention Conference '96 Proceedings", NCSA, 1996.
[Johnson]	D. Johnson, and J. Podesta, "Formulating A Company Policy on Access to and Use and Disclosure of Electronic Mail on Company Computer Systems".
[Kane, 1994]	P. Kane, "PC Security and Virus Protection Handbook: The Ongoing War Against Information Sabotage", M&T Books, 1994.
[Kaufman, 1995]	C. Kaufman, R. Perlman, and M. Speciner, "Network Security: PRIVATE Communication in a PUBLIC World", Prentice Hall, Englewood Cliffs, NJ, 1995.
[Kent, 1990]	S. Kent, "E-Mail Privacy for the Internet: New Software and Strict Registration Procedures will be Implemented this Year", Business Communications Review, Vol. 20, No. 1, Pg. 55, 1 January 1990.
[Levy, 1984]	S. Levy, "Hacker: Heroes of the Computer Revolution", Delta, 1984.
[Lewis, 1996]	S. Lewis, "Disaster Recovery Yellow Pages", The Systems Audit Group, 1996.
[Littleman, 1996]	J. Littleman, "The Fugitive Game: Online with Kevin Mitnick", Little, Brown, Boston, MA., 1996.
[Lu, 1989]	W. Lu and M. Sundareshan, "Secure Communication in Internet Environments: A Hierarchical Key Management Scheme for End-to-End Encryption", IEEE Transactions on Communications, Vol. 37, No. 10, Pg. 1014, 1 October 1989.
[Lu, 1990]	W. Lu and M. Sundareshan, "A Model for Multilevel Security in Computer Networks", IEEE Transactions on Software Engineering, Vol. 16, No. 6, Page 647, 1 June 1990.
[Martin, 1989]	M. Martin, and R. Schinzinger, "Ethics in Engineering", McGraw Hill, 2nd Edition, 1989.
[Merkle]	R. Merkle, "A Fast Software One Way Hash Function", Journal of Cryptology, Vol. 3, No. 1.
[McEwen, 1989]	J. McEwen, "Dedicated Computer Crime Units", Report Contributors: D. Fester and H. Nugent, Prepared for the National Institute of Justice, U.S. Department of Justice, by Institute for Law and Justice, Inc., under contract number OJP-85-C-006, Washington, DC, 1989.
[MIT, 1989]	Massachusetts Institute of Technology, "Teaching Students About Responsible Use of Computers", MIT, 1985-1986.  Also reprinted in the Communications of the ACM, Vol. 32, No. 6, Pg. 704, Athena Project, MIT, June 1989.
[Mogel, 1989]	Mogul, J., "Simple and Flexible Datagram Access Controls for UNIX-based Gateways", Digital Western Research Laboratory Research Report 89/4, March 1989.
[Muffett, 1992]	A. Muffett, "Crack Version 4.1: A Sensible Password Checker for Unix"
[NCSA1, 1995]	NCSA, "NCSA Firewall Policy Guide", 1995.
[NCSA2, 1995]	NCSA, "NCSA's Corporate Computer Virus Prevention Policy Model", NCSA, 1995.
[NCSA, 1996]	NCSA, "Firewalls & Internet Security Conference '96 Proceedings", 1996.
[NCSC-89-660-P, 1990]	National Computer Security Center, "Guidelines for Formal Verification Systems", Shipping list no.: 89-660-P, The Center, Fort George G. Meade, MD, 1 April 1990.
[NCSC-89-254-P, 1988]	National Computer Security Center, "Glossary of Computer Security Terms", Shipping list no.: 89-254-P, The Center, Fort George G. Meade, MD, 21 October 1988.
[NCSC-C1-001-89, 1989]	Tinto, M., "Computer Viruses: Prevention, Detection, and Treatment", National Computer Security Center C1 Technical Report C1-001-89, June 1989.
[NCSC Conference, 1989]	National Computer Security Conference, "12th National Computer Security Conference: Baltimore Convention Center, Baltimore, MD, 10-13 October, 1989: Information Systems Security, Solutions for Today - Concepts for Tomorrow", National Institute of Standards and National Computer Security Center, 1989.
[NCSC-CSC-STD-003-85, 1985]	Нational Computer Security Center, "Guidance for Applying the Department of Defense Trusted Computer System Evaluation Criteria in Specific Environments", CSC-STD-003-85, NCSC, 25 June 1985
[NCSC-STD-004-85, 1985]	National Computer Security Center, "Technical Rationale Behind CSC-STD-003-85: Computer Security Requirements", CSC-STD-004-85, NCSC, 25 June 1985
[NCSC-STD-005-85, 1985]	National Computer Security Center, "Magnetic Remanence Security Guideline", CSC-STD-005-85, NCSC, 15 November 1985
[NCSC-TCSEC, 1985]	National Computer Security Center, "Trusted Computer System Evaluation Criteria", DoD 5200.28-STD, CSC-STD-001-83, NCSC, December 1985.
[NCSC-TG-003, 1987]	NCSC, "A Guide to Understanding DISCRETIONARY ACCESS CONTROL in Trusted Systems", NCSC-TG-003, Version-1, 30 September 1987, 29 pages.
[NCSC-TG-001, 1988]	NCSC, "A Guide to Understanding AUDIT in Trusted Systems", NCSC-TG-001, Version-2, 1 June 1988, 25 pages.
NCSC-TG-004, 1988]	National Computer Security Center, "Glossary of Computer Security Terms", NCSC-TG-004, NCSC, 21 October 1988.
[NCSC-TG-005, 1987]	National Computer Security Center, "Trusted Network Interpretation", NCSC-TG-005, NCSC, 31 July 1987.
[NCSC-TG-006, 1988]	NCSC, "A Guide to Understanding CONFIGURATION MANAGEMENT in Trusted Systems", NCSC-TG-006, Version-1, 28 March 1988, 31 pages.
[NCSC-TRUSIX, 1990]	National Computer Security Center, "Trusted UNIX Working Group (TRUSIX) rationale for selecting access control list features for the UNIX system", Shipping list no.: 90-076-P, The Center, Fort George G. Meade, MD, 1990
[NRC, 1991]	National Research Council, "Computers at Risk: Safe Computing in the Information Age", National Academy Press, 1991.
[Nemeth, 1995]	E. Nemeth, G. Snyder, S. Seebass, and T. Hein, "UNIX Systems Administration Handbook", Prentice Hall PTR, Englewood Cliffs, NJ, 2nd ed. 1995.
[NIST, 1989]	National Institute of Standards and Technology, "Computer Viruses and Related Threats: A Management Guide", NIST Special Publication 500-166, August 1989.
[NSA]	National Security Agency, "Information Systems Security Products and Services Catalog", NSA, Quarterly Publication.
[NSF, 1988]	National Science Foundation, "NSF Poses Code of Networking Ethics", Communications of the ACM, Vol. 32, No. 6, Pg. 688, June 1989.  Also appears in the minutes of the regular meeting of the Division Advisory Panel for Networking and Communications Research and Infrastructure, Dave Farber, Chair, November 29-30, 1988.
[NTISSAM, 1987]	NTISS, "Advisory Memorandum on Office Automation Security Guideline", NTISSAM COMPUSEC/1-87, 16 January 1987, 58 pages.
[OTA-CIT-310, 1987]	United States Congress, Office of Technology Assessment, "Defending Secrets, Sharing Data: New Locks and Keys for Electronic Information", OTA-CIT-310, October 1987.
[OTA-TCT-606]	Congress of the United States, Office of Technology Assessment, "Information Security and Privacy in Network Environments", OTA-TCT-606, September 1994.
[Palmer, 1989]	I. Palmer, and G. Potter, "Computer Security Risk Management", Van Nostrand Reinhold, NY, 1989.
[Parker, 1989]	D. Parker, "Computer Crime: Criminal Justice Resource Manual", U.S. Dept. of Justice, National Institute of Justice, Office of Justice Programs, Under Contract Number OJP-86-C-002, Washington, D.C., August 1989.
[Parker, 1990]	D. Parker, S. Swope, and B. Baker, "Ethical Conflicts: Information and Computer Science, Technology and Business", QED Information Sciences, Inc., Wellesley, MA. (245 pages).
[Pfleeger, 1989]	C. Pfleeger, "Security in Computing", Prentice-Hall, Englewood Cliffs, NJ, 1989.
[Quarterman, 1990]	J. Quarterman, J., "The Matrix: Computer Networks and Conferencing Systems Worldwide", Digital Press, Bedford, MA, 1990.
[Ranum1, 1992]	M. Ranum, "An Internet Firewall", Proceedings of World Conference on Systems Management and Security, 1992.
[Ranum2, 1992]	M. Ranum, "A Network Firewall", Digital Equipment Corporation Washington Open Systems Resource Center , June 12, 1992.
[Ranum, 1993]	M. Ranum, "Thinking About Firewalls", 1993.
[Ranum, 1994]	M. Ranum and F. Avolio, "A Toolkit and Methods for Internet Firewalls", Trustest Information Systems, 1994.
[Reinhardt, 1992]	R. Reinhardt, "An Architectural Overview of UNIX Network Security"
[Reinhardt, 1993]	R. Reinhardt, "An Architectural Overview of UNIX Network Security", ARINC Research Corporation, February 18, 1993.
[Reynolds-RFC1135, 1989]	The Helminthiasis of the Internet, RFC 1135, USC/Information Sciences Institute, Marina del Rey, CA, December 1989
[Russell, 1991]	D. Russell and G. Gangemi, "Computer Security Basics" O'Reilly & Associates, Sebastopol, CA, 1991.
[Schneier 1996]	B. Schneier, "Applied Cryptography: Protocols, Algorithms, and Source Code in C", John Wiley & Sons, New York, second edition, 1996.
[Seeley, 1989]	D. Seeley, "A Tour of the Worm", Proceedings of 1989 Winter USENIX Conference, Usenix Association, San Diego, CA, February 1989.
[Shaw, 1986]	E. Shaw Jr., "Computer Fraud and Abuse Act of 1986", Congressional Record (3 June 1986), Washington, D.C., 3 June 1986.
[Shimomura, 1996]	T. Shimomura with J. Markoff, "Takedown:The Pursuit and Capture of Kevin Mitnick, America's Most Wanted Computer Outlaw-by the Man Who Did It", Hyperion, 1996.
[Shirey, 1990]	R. Shirey, "Defense Data Network Security Architecture", Computer Communication Review, Vol. 20, No. 2, Page 66, 1 April 1990.
[Slatalla, 1995]	M. Slatalla and J. Quittner, "Masters of Deception: The Gang that Ruled Cyberspace", Harper Collins Publishers, 1995.
[Smith, 1989]	M. Smith, "Commonsense Computer Security: Your Practical Guide to Preventing Accidental and Deliberate Electronic Data Loss", McGraw-Hill, New York, NY, 1989.
[Smith, 1995]	D. Smith, "Forming an Incident Response Team", Sixth Annual Computer Security Incident Handling Workshop, Boston, MA, July 25-29, 1995.
[Spafford, 1988]	E. Spafford, "The Internet Worm Program: An Analysis", Computer Communication Review, Vol. 19, No. 1, ACM SIGCOM, January 1989.  Also issued as Purdue CS Technical Report CSD-TR-823, 28 November 1988
[Spafford, 1989]	G. Spafford, "An Analysis of the Internet Worm", Proceedings of the European Software Engineering Conference 1989, Warwick England, September 1989. Proceedings published by Springer-Verlag as: Lecture Notes in Computer Science #387.  Also issued as Purdue Technical Report #CSD-TR-933
[Spafford, 1989]	E. Spafford, K. Heaphy, and D. Ferbrache, "Computer Viruses: Dealing with Electronic Vandalism and Programmed Threats", ADAPSO, 1989. (109 pages.)
[Stallings1, 1995]	W. Stallings, "Internet Security Handbook", IDG Books, Foster City CA, 1995.
[Stallings2, 1995]	W. Stallings, "Network and Internetwork Security", Prentice Hall, , 1995.
[Stallings3, 1995]	W. Stallings, "Protect Your Privacy: A Guide for PGP Users"  PTR Prentice Hall, 1995.
[Stoll, 1988]	C. Stoll, "Stalking the Wily Hacker", Communications of the ACM, Vol. 31, No. 5, Pgs. 484-497, ACM, New York, NY, May 1988.
[Stoll, 1989]	C. Stoll, "The Cuckoo's Egg", ISBN 00385-24946-2, Doubleday, 1989.
[Treese, 1993]	G. Treese and A. Wolman, "X Through the Firewall, and Other Applications Relays", Digital Equipment Corporation, Cambridge Research Laboratory, CRL 93/10, May 3, 1993.
[Trible, 1986]	P. Trible, "The Computer Fraud and Abuse Act of 1986", U.S. Senate Committee on the Judiciary, 1986.
[Venema]	W. Venema, "TCP WRAPPER: Network monitoring, access control, and booby traps", Mathematics and Computing Science, Eindhoven University of Technology, The Netherlands.
USENIX, 1988]	USENIX, "USENIX Proceedings: UNIX Security Workshop", Portland, OR, August 29-30, 1988.
[USENIX, 1990]	USENIX, "USENIX Proceedings: UNIX Security II Workshop", Portland, OR, August 27-28, 1990.
[USENIX, 1992]	USENIX, "USENIX Symposium Proceedings: UNIX Security III", Baltimore, MD, September 14-16, 1992.
[USENIX, 1993]	USENIX, "USENIX Symposium Proceedings: UNIX Security IV", Santa Clara, CA, October 4-6, 1993.
[USENIX, 1995]	USENIX, "The Fifth USENIX UNIX Security Symposium", Salt Lake City, UT, June 5-7, 1995.
[Wood, 1987]	C. Wood, W. Banks, S. Guarro, A. Garcia, V. Hampel, and H. Sartorio, "Computer Security: A Comprehensive Controls Checklist", John Wiley and Sons, Interscience Publication, 1987.
[Wrobel, 1993]	L. Wrobel, "Writing Disaster Recovery Plans for Telecommunications Networks and LANS", Artech House, 1993.
[Vallabhaneni, 1989]	S. Vallabhaneni, "Auditing Computer Security: A Manual with Case Studies", Wiley, New York, NY, 1989.

[1]  CERT Advisory CA-96.21; TCP SYN Flooding and IP Spoofing Attacks; September 24, 1996.

[2]  B. Ziegler, "Hacker Tangles Panix Web Site", Wall Street Journal, 12 September 1996.

[3]  "Firewalls and Internet Security: Repelling the Wily Hacker"; William R. Cheswick and Steven M. Bellovin, Addison-Wesley Publishing Company, 1994; ISBN 0-201-63357-4.

[4]  Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", RFC 1918, February 1996.

[5]  The North American Network Operators Group; http://www.nanog.org.

[6]  Perkins, C., "IP Mobility Support", RFC 2002, October 1996.

[7]  Montenegro, G., "Reverse Tunneling for Mobile IP", RFC 2344, May 1998.

[8]  Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.

[9]  Thanks to: Craig Huegen; See: http://www.quadrunner.com/~chuegen/smurf.txt.

Сжатие и восстановление записи

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

Должно использоваться сжатие без потерь, а длина содержимого не может стать больше чем 1024 байт. Если функция восстановления встречает фрагмент TLSCompressed.fragment, длина которого окажется больше 214 байт, она должна выдать уведомление о фатальной ошибке преобразования.

Struct	{ ContentType type;	/* то же самое, что и TLSPlaintext.type */
	ProtocolVersion version;	/* то же самое, что и TLSPlaintext.version */
	uint16 length;
	opaque fragment[TLSCompressed.length];
	} TLSCompressed;

length	Длина (в байтах) следующего TLSCompressed.fragment. Длина не должна превосходить 214 + 1024.
Fragment	Сжатая форма TLSPlaintext.fragment.

Операция CompressionMethod.null является идентификационной; ни одно из полей не изменено.

Функции декомпрессии (восстановления) отвечают за то, что внутренний буфер не будет переполнен при обработке сообщения.

Table_shtml

Tableshtml

Скорость [кбит/с]	64	1544	6312	32064	44736	2048	8448	34368	139264	155520
Тип кода	AMI	AMI B8ZS	B6ZS	AMI	B3ZS	HDB3	HDB3	HDB3	CMI	CMI
Амплитуда, В	1,0	3,0	1,0	1,0	1,0	2,37 3,0	2,37	1,0	±0,55	±0,55
Ширина импульса, нс	15000	323,5	79	15,6	11,2	244	59,0	14,55	3,59	3,2

Dear Valued Customer, SmithBarney Citigroup, is committed to maintaining a safe environment for our customers. To protect the security of your account, SmithBarney Citigroup, employs some of the most advanced security systems in the world and our anti-fraud teams regularly screen the Citibank system for unusual activity. We are contacting you to remind you that on Nov. 28, 2004 our Account Review Team identified some unusual activity in your account. In accordance with SmithBarney's User Agreement and to ensure that your account has not been compromised, access to your account was limited. Your account access will remain limited until this issue has been resolved. We encourage you to log in and perform the steps necessary to restore your account access as soon as possible. Allowing your account access to remain limited for an extended period of time may result in further limitations on the use of your account and possible account closure.Visit now log on page and sign to account verification process:
https://www.smithbarney.com/login/login.cgi?redir=s
Thank you for your prompt attention to this matter. Please understand that this is a security measure meant to help protect you and your account. We apologize for any inconvenience. Sincerely, SmithBarney Citigroup, Account Review Department.

Пример подмены web-страницы при Phishing-атаке

Краткий обзор типов атак

Код атаки	Описание атаки
2000001	Land attack. Атакер пытается замедлить работу вашей машины, послав пакет с идентичными адресами получателя и отправителя. Для стека протоколов Интернет такая ситуация не нормальна. ЭВМ пытается выйти из бесконечной петли обращений к самой себе. Имеются пэтчи для большинства операционных систем.
2000002	Unknown IP protocol. Традиционными транспортными протоколами являются UDP, TCP и ICMP, которые работают поверх протокола IP. Код протокола определяется полем тип протокола заголовка IP-дейтограммы. Существует большое число протоколов, которые идентифицируются с помощью номеров портов, например, HTTP, использующий в качестве транспорта TCP. Появление незнакомого протокола должно всегда настораживать, так как может нарушить нормальную работу программ.
2000003	Teardrop attack. Опасное перекрытие IP-фрагментов, сформированное программой teardrop. Ваша операционная система может стать нестабильной или разрушиться. Имеются пэтчи для большинства операционных систем. Адрес отправителя вероятнее всего не является истинным. Это означает, что отправитель использует фальшивый IP-адрес, и прикидывается кем-то еще. К сожалению, не существует простых способов определить, кто в действительности посылает кадры с искаженным адресом отправителя.
2000004	NewTear attack. Опасное перекрытие IP-фрагментов, сформированное программой newtear. Ваша операционная система может стать нестабильной или разрушиться. Имеются пэтчи для большинства операционных систем. Адрес отправителя вероятнее всего не является истинным.
2000005	SynDrop attack. Опасное перекрытие IP-фрагментов, сформированное программой syndrop. Ваша операционная система может стать нестабильной или разрушиться. Имеются пэтчи для большинства операционных систем.
2000006	TearDrop2 attack. Тоже что и, например, SynDrop, но для программы teardrop2
2000007	Bonk DoS..
2000008	Boink DoS. Тоже что и, например, SynDrop, но для программы boink
2000009	IP Fragment overlap. Смотри, например 2000005

2000010	IP last fragment length changed..
2000011	Too much IP fragmentation..
2000012	Ping of death. Предпринимается попытка послать пакет, длина которого больше теоретического предела 65536 байтов. Системы до 1997 года были уязвимы для такой атаки. Это делалось, например с помощью ping -l 65550.
2000013	IP source route. Попытка вторжения с использованием IP-опции "маршрут отправителя". В настоящее время эта опция заблокирована большинством маршрутизаторов.
2000014	Zero length IP option. Некоторые системы при этом повисают
2000015	Nestea attack. Опасное перекрытие IP-фрагментов, сформированное программой nestea. Ваша операционная система может стать нестабильной или разрушиться. Имеются пэтчи для большинства операционных систем. Адрес отправителя вероятнее всего не является истинным. Это означает, что отправитель использует фальшивый IP-адрес, и прикидывается кем-то еще. К сожалению, не существует простых способов определить, кто в действительности посылает кадры с искаженным адресом отправителя.
2000016	Empty fragment. Когда пакеты слишком длины, они могут быть фрагментированы. Система контроля фиксирует фрагмент с нулевой длиной. Например, IP-заголовок имеет 20-байт, а данных вообще нет. Это может указывать, что: Атакер пытается обойти систему контроля вторжения. Некоторое сетевое оборудование (маршрутизаторы/переключатели) работают некорректно, генерируя такие фрагменты. Имеется ошибка в стеке TCP/IP машины, посылающей пакет. Атакер пытается предпринять DoS-атаку против вашей системы. Ядра Linux для версий между 2.1.89 и 2.2.3 были уязвимы для атак DoS с привлечением этой методики. Каждый такой фрагмент вызывает некоторую потерю памяти. Повторно посылая такие фрагменты, можно вызвать кризис из-за отсутствия свободной памяти. Ceotcndetn cкрипт с именем sesquipedalian, который был написан для использования этой ошибки.
2000017	IP unaligned timestamp.
2000018	Jolt2.
2000019	Jolt.
2000020

IP microfragment. Некоторые программы рушатся при получении временной метки, не выровненной по границе, кратной 32 бит.

2000021	SSping attack. Попытка атаки с помощью некорректного формата фрагментов.
2000022	Flushot attack.
2000023	IP source route end.
2000024	Oshare attack.
2000025	IP fragment data changed.
2000101	Traceroute. Кто- то пытается отследить путь от своей машины к вашей. Утилита traceroute широко используется в Интернет для поиска пути между машинами. Программа traceroute выполняет эту работу и определяет виртуальный путь через Internet. Программа traceroute не является опасной. Не существует способа проникнуть в вашу ЭВМ, используя ее. Однако она помогает хакеру отследить ваши соединения через Интернет. Эта информация может использоваться для компрометации некоторых других участников ваших связей. Например, в прошлом этот вид информации использовался хакерами для того, чтобы отключить свою жертву от Интернет, заставив ближайший маршрутизатор повесить телефонную линию.
2000102	Echo storm. Необычно большое число ping пакетов пришло за ограниченный период времени. Pings Довольно частой атакой домашних пользователей, играющих в сетевые игры или общающихся через сеть, является блокировка их канала с помощью большого числа пакетов Ping. Сейчас ведутся работы, для того чтобы позволить пользователю конфигурировать configuration file, чтобы было можно игнорировать такое вторжение. Смотри статью q000050.
2000103	Possible Smurf attack initiated..
2000104	ICMP unreachable storm..
2000105	ICMP subnet mask request. Поступил извне ICMP-запрос маски. В норме этого не должно быть. Атакер исследует структуру сети.
2000106	Ping sweep.
2000107	Suspicious Router advertisement. Подозрительное анонсирование новых маршрутов. Атакер возможно пытается перенаправить трафик на себя. Для этого может использоваться, в том числе, и ICMP-протокол. Соответствующие опции должны всегда вызывать подозрение.
2000108

Corrupt IP options. Опции IP на практике почти не используются. По этой причине в их обработке имеется достаточно много ошибок. Ими часто пытаются воспользоваться хакеры.

Появление в пакете IP-опций должно вызывать подозрения.

2000109	Echo reply without request. Это может быть результатом взаимодействия хакера с засланным троянским конем. Может быть это и результатом дублирования вашего IP-адреса. В любом случае такие пакеты достойны внимания.
2000110	ICMP flood..
2000111	Twinge attack. То же, что и ICMP-flood
2000112	Loki. Атака, использующая "заднюю дверь" приложения или ОС. Это может быть сделано для сокрытия трафика, например под видом ICMP-эхо или UDP-запросов к DNS и т.д. Воспользуйтесь командой netstat, чтобы выяснить, какие raw SOCKET открыты.
2000201	UDP port scan..
2000202	UDP port loopback. Пакет UDP путешествует между двумя эхо-портами. Такие пакеты могут делать это бесконечное число раз, используя всю имеющуюся полосу сети и производительность ЦПУ. Имеется несколько стандартных услуг такого рода, которые могут работать в системе. Среди них: echo (порт 7) дневная квота (порт 17) chargen (порт 19) Атакер может создать проблемы, фальсифицируя адрес отправителя и вынуждая две машины бесконечно обмениваться откликами друг с другом. Таким образом, может быть парализована вся сеть (ведь хакер может послать много таких пакетов). Например, хакер может имитировать посылку пакета от ЭВМ-A (порт chargen) к ЭВМ-B (порт echo). Эхо-служба ЭВМ-B пошлет отклик ЭВМ-A и т.д.
2000203	Snork attack. Регистрируются UDP-дейтограммы с портом назначения 135 (Microsoft Location Service), и отправитель с портом 7 (Echo), 19 (Chargen) или 135. Это попытка замкнуть две службы (если они разрешены/активированы) и заставить их бесконечно обмениваться пакетами друг с другом. Существует пэтч для блокировки таких атак (смотри сайт Microsoft).
2000204	Ascend Attack. Атака маршрутизаторов Ascend путем посылки UDP-пакета в порт 9.
2000205

Possible Fraggle attack initiated.Это не атака вашей ЭВМ. Это скорее попытка перегрузить систему третьей стороны. Это может быть также попытка выявить всех сетевых соседей. Internet поддерживает широковещательную адресацию.


Это позволяет послать один "пакет" сотням ЭВМ " субсети". Эта техника позволяет ЭВМ оповестить окружение о своем присутствии. Атакер, используя технику, называемую "spoofing", атакует третью сторону. Атакер притворяется жертвой и посылает эхо-пакеты в субсеть. Каждая включенная ЭВМ откликнется "отправителю". Этот вид атаки был использован югославскими хакерами против сайтов в США и НАТО. Системы Firewall блокируют такие пакеты по умолчанию. Разные пакеты могут быть посланы ЭВМ, чтобы вызвать эхо-отклик. Сюда входят:

ICMP Echo	Используются стандартной командой 'ping' Применяется также в smurf-атаке, которая подобна fraggle.
UDP Echo	Эхо-порт UDP, который перенаправляет трафик отправителю. Это первичный пакет, используемый для запуска атаки fraggle.
chargen	Перенаправляет произвольный трафик отправителю
daytime	Присылает значение текущего времени отправителю.
quotd	Присылает отправителю "quote of the day" или "fortune cookie".

2000207 UDP short header. Заголовок UDP-дейтограммы содержит менее 8 байт (в надежде сломать программу-обработчик) 2000208 Saihyousen attack. Атака против ConSeal PC Firewall 2000209 W2K domain controller attack. Атакер посылает error-пакет вашей ЭВМ на UDP порт 464, а ваша система отвечает, возможно получение бесконечного цикла. 2000210 Echo_Denial_of_Service. Посылается UDP-пакет с номером порта отправителя и получателя равным 7. 2000211 Chargen_Denial_of_Service. Посылается UDP-пакет с номером порта отправителя и получателя равным 19. 2000301 TCP port scan. 2000302 TCP SYN flood. 2000303 WinNuke attack. 2000304 TCP sequence out-of-range. 2000305 TCP FIN scan. Разновидность TCP-сканирования. Однако хакер здесь пытается осуществить так называемое "FIN-сканирование". Он пытается закрыть несуществующее соединение сервера. Это ошибка, но системы иногда выдают разные результаты в зависимости от того, является ли данная услуга доступной. В результате атакер может получить доступ к системе.

2000306	TCP header fragmentation.
2000307	TCP short header.
2000308	TCP XMAS scan. Посылается TCP-сегмент с ISN=0 и битами FIN, URG и PUSH равными 1.
2000309	TCP null scan. Посылается TCP-сегмент с ISN=0 и битами флагов равными нулю.
2000310	TCP ACK ping.
2000311	TCP post connection SYN.
2000312	TCP FIN or RST seq out-of-range..
2000313	TCP OS fingerprint.Посылается необычная комбинация TCP-флагов с тем, чтобы посмотреть реакцию. А по реакции определить вид ОС.
2000314	NMAP OS fingerprint.
2000315	Zero length TCP option.
2000316	TCP small segment size..
2000317	TCP SYN with URG flag.
2000318	TCP Invalid Urgent offset.
2000319	RFProwl exploit.
2000320	TCP data changed.
2000321	Queso Scan.Попытка определения версии ОС или прикладной программы
2000401	DNS zone transfer.
2000402	DNS cache poison. Атакер послал запрос DNS-серверу, который содержит также и отклик. Это может быть попыткой компрометировать DNS-серверов. Это может быть также результатом работы ISP, который перенаправляет своих клиентов на прокси-сервер. Это вероятнее всего вторжение в систему Для того чтобы улучшить рабочие параметры, DNS-серверы пытаются "кэшировать" имена локально. Серверы просматривают секции откликов всех пакетов, приходящих в систему. Они запоминают эти отклики на короткое время на случай, если кто-то еще нуждается в этой информации. Очевидной проблемой является случай, когда такой пакет содержит ложную информацию. В частности, кто-то может послать запрос в DNS, содержащий, кроме того, дополнительную информацию в секции отклика. Старые серверы воспринимают эту информацию, кэшируют ее, и выдают в ответ на запрос, если таковой поступит. (Новые DNS-серверы лишены этой дырки, но существует еще достаточно много старых серверов). Если ваш DNS-сервер обновлен, атака такого рода невозможна.
2000403	DNS name overflow.
2000404	DNS non-Internet lookup. DNS-запрос послан не DNS-серверу или запрос имеет некорректный формат.
2000405	DNS malformed.

2000406	DNS Internet not 4 bytes.
2000407	DNS HINFO query.
2000408	DNS spoof successful.
2000409	DNS IQUERY.
2000410	DNS I-Query exploit.
2000411	DNS Chaos lookup.
2000413	NetBIOS names query.
2000414	DNS spoof attempt.
2000415	DNS NXT record overflow.
2000416	DNS null. DNS- запрос не содержит ни поля запросов, ни поля ответов ни поля дополнительной информации.
2000417	DNS BIND version request. Сервер BIND DNS содержит в своей базе данных запись CHAOS/TXT с именем "VERSION.BIND". Если кому-то нужна эта запись, присылается версия программы BIND soft. Такой запрос сам по себе не является атакой, но может являться разведывательным рейдом. Однако, если возвращается версия типа "4.9.6-REL" или "8.2.1", это указывает, что у вас установлена версия с хорошо известной дыркой, связанной с переполнением буфера.
2000418	AntiSniff DNS exploit. Программа AntiSniff может быть использована путем посылки специального DNS-кадра. В случае успеха, атакер может использовать программу, работающую в системе, где работает AntiSniff. AntiSniff представляет собой программу, которая разработана L0pht Heavy Industries в июле 1999. Атакер может использовать L0pht AntiSniff для получения информации о сети, которая может оказаться для него полезной при последующих атаках. Атакер может также использовать L0pht AntiSniff для определения положения компрометированных ЭВМ, переведенных в режим 6 (sniffing), которые могут им позднее использоваться.
2000419	Excessive DNS requests.
2000420	DNS ZXFR. Предпринята попытка осуществить зонный обмен DNS с транспортным сжатием, что само по себе нормально (популярный алгоритм "gzip"). Подобно всем зонным обменам, это позволяет удаленному атакеру сформировать карту вашей сети. Такой обмен может быть частью атаки, если поступает извне.
2000421	DNS TSIG name overflow.
2000422	DNS name overflow contains %.
2000423	DNS name overflow very long.
2000501	SMB malformed. Существует ошибка в старой версии SMB (система Microsoft для совместного использования файлов и принтеров в сети).

Эта ошибка может быть использована при авторизации, путем посылки специально сформированных пакетов. При реализации этого трюка машина крэшится. Данная атака может быть предпринята успешно для систем Windows NT 4.0 SP4 и Windows 95 (все версии). Заметим, что имеются пэтчи для всех систем. Для того чтобы дырка работала, "File and Print Sharing" должно быть разрешено.

2000502	SMB empty password.
2000503	SMB I/O using printer share.
2000504	SMB password overflow.
2000505	SMB file name overflow.
2000506	SMB Unicode file name overflow.
2000507	SMB unencrypted password.
2000508	RFParalyze exploit.
2000600	HTTP Attack.
2000601	HTTP URL overflow.
2000602	HTTP cgi starting with php. Специально сконструированный URL может позволить нежелательный доступ к CGI на сервере
2000603	HTTP URL directory traversal/climbing. Ситуация выглядит так, как будто атакер пытается прочесть посторонние файлы вашей системы. Обычная ошибка web-броузера заключается в том, что хакер может специфицировать URL, который выглядит как /../../../foo/bar.txt. Эта атака удается, так как программист не осуществляет двойной проверки URL, чтобы убедиться, корректен ли файл web-сайта. Сигнатурой такой атаки может быть наличие в URL последовательности ../... Иногда такого рода атака может быть имитирована некорректными связями, размещенными на странице. Это говорит о некорректной конфигурации. Во-первых, проверьте параметры URL, чтобы выяснить к какому файлу намерен получить доступ атакер. Затем проверьте, получил ли атакер доступ к файлу. Если это действительно критичный файл, и атакер был успешен, необходимо предпринять срочные действия. Например, если атакер получил доступ к файлу паролей, необходимо заменить все пароли. Следует также проверить является ли версия сервера новейшей и использованы ли все существующие пэтчи безопасности. Большинство таких атак предпринимается против "встроенных" web-серверов (т.e. web-серверов, добавленных в качестве части другого программного продукта), а не против реальных web-серверов типа Apache и IIS.

2000604	HTTP asp with . appended.
2000605	HTTP cgi with ~ appended.
2000606	HTTP URL has many slashes.
2000607	HTTP URL with ::$DATA appended. Предпринята попытка доступа к файлу с завершающей последовательностью ::$DATA. Некоторые серверы в этом случае возвращают исходный файл asp, вместо того, чтобы его (asp) исполнить, таким образом атакер получает критическую информацию о сервере. Исходные тексты программы сервера часто содержат пароли, имена скрытых файлов и т.д.
2000608	HTTP GET data overflow.
2000609	Данные HTTP CGI содержат ../../../... Данные, переданные в URL, имеют подозрительный проход, содержащий ../../../..; Этот проход может быть использован для доступа к привилегированным файлам. Атакер пытается добраться по дереву каталогов до нужных ему файлов. Некоторые приложения Web используют проходы, содержащие ../../../.. . Вам следует рассмотреть URL и аргумент GET с целью проверки их корректности. Если проход в аргументе GET, указывает на попытку доступа к привилегированным данным, возможно ваш сервер скомпрометирован.
2000610	HTTP URL with blank appended.
2000611	HTTP GET data with repeated char.
2000612	IIS Double-Byte Code attempt. Специально сформированный URL, который может позволить нежелательный доступ . Выполняется попытка доступа к URL с завершающими %81 - %FE. Некоторые серверы возвращают в этом случае исходный файл, а не выполняют его, таким образом предоставляется атакеру критическая информация о сервере. Исходный текст программы сервера часто содержит скрытые пароли, имена файлов или данные об ошибках в программе.
2000613	HTTP HOST: repeated many times.
2000614	HTTP URL contains old DOS filename.
2000615	HTTP ACCEPT: field overflow.
2000616	HTTP URL contains /./.
2000617	HTTP URL contains /....
2000618	HTTP GET data contains /....
2000619	HTTP URL scan.
2000620	Whisker URL fingerprint.
2000621	Web site copying.
2000622	HTTP Authentication overflow.
2000623

HTTP POST data contains ../../../... Некоторые Web-серверы используют "скрытое" поле формы, содержащее имя файла, чтобы управлять работой программы сервера.

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

2000624	HTTP POST data contains /....
2000625	HTTP URL with repeated char.
2000626	HTTP POST data with repeated char.
2000627	HTTP URL bad hex code.
2000628	HTTP URL contains %20.
2000629	HTTP User-Agent overflow.
2000630	HTTP asp with \ appended. Произошла попытка доступа к файлу asp с завершающим символом \. В некоторых ситуациях, вместо исполнения программы asp будет возвращен исходный asp-файл. Это раскроет атакеру критическую информацию о сервере. Исходный текст программы сервера часто содержит пароли, скрытые имена файлов или ошибки, которые в такой ситуации относительно легко найти. Хакер может затем использовать эту скрытую (hidden) информацию для вскрытия сервера.
2000631	URL with repeated ..
2000632	HTTP JavaServer URL in Caps.
2000633	HTTP URL with +.htr appended.
2000634	HTTP path contains *.jhtml or *.jsp.
2000635	HTTP POST data contains script.
2000636	HTTP HOST: field overflow.
2000638	HTTP Cookie overflow.
2000639	HTTP UTF8 backtrack.
2000640	HTTP GET data contains script.
2000641	HTTP login name well known.
2000642	HTTP DAV PROPFIND overflow.
2000643	SubSeven CGI.
2000644	Repeated access to same Web service.
2000645	HTTP URL with double-encoded ../.
2000646	HTTP field with binary.
2000647	HTTP several fields with binary.
2000648	HTTP CONNECTION: field overflow.
2000700	POP3 Attack.
2000701	POP3 USER overflow.
2000702	POP3 password overflow.
2000703	POP3 MIME filename overflow.
2000704	POP3 command overflow.
2000705	POP3 AUTH overflow.
2000706	POP3 RETR overflow.
2000707	POP3 MIME filename repeated chars.
2000708	POP3 MIME filename repeated blanks.
2000709	POP3 Date overflow.
2000710	POP3 APOP name overflow.

2000711	POP3 false attachment.
2000800	IMAP4 Attack.
2000801	IMAP4 user name overflow.
2000802	IMAP4 password overflow.
2000803	IMAP4 authentication overflow.
2000804	IMAP4 command overflow.
2000805	IMAP4 Parm Overflow.
2000901	Telnet abuse.
2000902	Telnet login name overflow.
2000903	Telnet password overflow.
2000904	Telnet terminal type overflow.
2000905	Telnet NTLM tickle.
2000906	Telnet Bad Environment.
2000907	Telnet Bad IFS. В UNIX, переменная "IFS" специфицирует символ, разделяющий команды. Если значение этой переменной изменено, тогда система детектирования вторжения не будет способна корректно интерпретировать команды. Более того, кто-либо может изменить эту переменную для того, чтобы модифицировать работу некоторых скриптов ядра. В частности плохой IFS станет разграничителем, используемым при разборе любых вводов, таких как имена файлов или DNS-имена. В этом случае, нужно установить IFS соответствующим символу '/' или '.'. Вообще, если вы хотите жить немного спокойнее, лучше заблокировать применение telnet, предложив пользователям перейти на SSH.
2000908	Telnet Environment Format String Attack. В районе августа 2000, выявлено большое число атак типа "format string". Эти атаки связаны с попыткой проникнуть в Telnet-машины путем посылки некорректных переменных окружения (environmental variables with format commands).
2000909	Telnet RESOLV_HOST_CONF. Переменная окружения RESOLV_HOST_CONF посылается с привлечением поля опций Telnet. Это поле не должно никогда изменяться таким способом. Это может означать попытку получения доступа к критическим файлам типа паролей и т.д.
2000910	Telnet bad TERM. Совершена попытка исказить "TERM" Telnet. Клиент Telnet может эмулировать многие виды терминалов текстового типа. Клиент передает эту информацию серверу с помощью переменной "TERM" или команды "term-type". Если обнаружено необычное значение этой переменной, возможно предпринята атака против вашей системы.

2000911 Telnet bad TERMCAP. 2000912 Telnet XDISPLOC. 2000913 Telnet AUTH USER overflow. 2000914 Telnet ENV overflow. 2000915 Telnet login name well known. 2000916 Telnet Backdoor. Атакер пытается воспользоваться известным именем/паролем "задней" двери telnet Trigger. Протокольный анализатор извлекает login name и пароль из входной строки Telnet и сравнивает их со списком известных параметров доступа для задней двери telnet. Некоторые из них приведены ниже:

wh00t!	Пароль задней двери предоставляемый rootkit для Linux, разработанного в 1994 .
lrkr0x	Пароль задней двери предоставляемый Rootkit I для Linux, разработанного в 1996
satori	Rootkit IV для Linux.
rewt	Задняя дверь пользовательского аккоунта, которая предоставляет root-привилегии.
h0tb0x	Пароль задней двери для FreeBSD rootkit 1.2 (1/27/97).

2001000

SMTP Attack. 2001001 SMTP pipe in mail address. кто-то пытается компрометировать e-mail сервер путем посылки исполняемого кода shell внутри e-mail адреса. Это имеет целью компрометировать e-mail сервер, а также субсистему, обрабатывающую заголовки почтового сообщения. Ниже приводится пример SMTP-сессии с попыткой реализации такой атаки:

HELO

MAIL FROM: |/usr/ucb/tail|/usr/bin/sh

RCPT TO: root

DATA

From: attacker@example.com

To: victim@example.com

Return-Receipt-To: |foobar

Subject: Sample Exploit 2001002

SMTP DEBUG command. Кто-то сканирует вашу систему с целью выявления ее уязвимости. В 1988, червь Morris уложил Интернет Internet. Одним из путей распространения червя являлась программа sendmail. Sendmail поддерживала нестандартную команду "DEBUG", которая позволяет любому получить контроль над сервером. Червь Morris автоматизировал этот процесс для распространения через системы sendmail Internet. Сейчас маловероятно, что вы найдете такую старую почтовую систему. Следовательно, такая атака будет означать, что кто-то использует универсальный сканер уязвимости. Иногда система может выйти из синхронизма (сбой в ISN), что вызывает большие потери пакетов. В таких условиях по ошибке может быть запущена команда DEBUG. Например, если вы работаете с версией сервера для системы 486, который обрабатывает большое количество e-mail, такая десинхронизация может произойти. Уязвимой системой является Sendmail/5.5.8. 2001003 SMTP login name overflow. 2001004 SMTP EXPN command. 2001005 SMTP VRFY command. 2001006 SMTP WIZ command. 2001007 SMTP Too many recipients. 2001008 SMTP corrupted MAIL command. 2001009 SMTP email name overflow. 2001010 SMTP corrupted RCPT command. 2001011 SMTP relay attempt. Предпринята попытка использования SMTP в качестве ретранслятора сообщений - это может случиться, когда спамер некорректно использует SMTP-сервер. Это одна из наиболее успешных атак на Internet. Спамер регулярно ищет в Интернет ретранслирующие e-mail сервера. Примерно половина всех e-mail серверов поддерживают ретрансляцию в той или иной форме. 2001012 SMTP command overflow. 2001013 SMTP mail to decode alias. Обнаружено сообщение, адресованное пользователю с именем decode. Это может быть попыткой взломать почтовый сервер, или это может быть частью сканирования системы. Это достаточно старый трюк, выявленный в 1990. Системы UNIX позволяют посылать почту клиенту с именем decode, чтобы передать сообщение не клиенту, а программе uudecode. Атакер может попытаться таким образом переписать файлы таким образом, чтобы проникнуть в систему. Эта дырка связана с файлом /etc/aliases, содержащим строку типа:

decode: |/usr/bin/uudecode

Сейчас, такой тип вторжения может проявиться лишь в случае универсального сканирования с целью выявления уязвимости вашей системы. Например, атакер пытается передать по каналу uuencoded-файл после команды DATA. HELO

MAIL FROM: test@example.com

RCPT TO: decode

DATA

begin 644 /usr/bin/.rhosts

$*R`K"@``

`

end

.

QUIT

Этот пример пытается атаковать систему путем записи строки "+ +" в файл ".rhosts". Это будет указывать системе, что следует доверять любому, кто вошел в нее через программу типа 'rlogin'. Этот вид атаки существенен только для почтовых серверов, работающих под UNIX. Просмотрите файл "aliases", размещенный в /etc/aliases. Проверьте, нет ли строк типа:

decode: |/usr/bin/uudecode

uudecode: |/usr/bin/uuencode -d

Удалите эти строки. Заметим, что новые системы не допускают такой возможности. 2001014 SMTP mail to uudecode alias. 2001015 SMTP too many errors. 2001016 SMTP MIME file name overflow. 2001017 SMTP uucp-style recipient. 2001018 SMTP encapsulated relay. 2001019 STMP encapsulated Exchange relay. Spam-атака. Выявляется инкапсулируемый почтовый адрес вида . Некоторые версии Microsoft Exchange не способны проверять эти типы адресов, таким образом, они могут использоваться спамерами для посылки неавторизованной почты. 2001020 SMTP mail to rpmmail alias. 2001021 SMTP MIME name overflow. 2001022 SMTP MIME filename repeated chars. 2001023 SMTP MIME filename repeated blanks. 2001024 SMTP ETRN overflow. 2001025 SMTP Date overflow. 2001026 SMTP Recipient with trailing dot. 2001027 SMTP FROM: field overflow. 2001028 SMTP MIME null charset.Обнаружено незнакомое почтовое сообщение, вероятно сконструированное, чтобы разрушить почтовый сервер. В заголовки "Reply-To:" сообщения встраиваются исполняемые Shell и PERL коды. Когда система откликается, эти коду будут исполнены. Например, старые версии list-сервера MAJORDOMO исполняют любой PERL-скрипт, который вставлен в это поле. 2001030 SMTP ENVID overflow. 2001031 SMTP false attachment. 2001032 SMTP Expn Overflow. 2001033 SMTP Vrfy Overflow. 2001034 SMTP Listserv Overflow. 2001036 SMTP Auth Overflow. 2001040 SMTP Xchg Auth. 2001041 SMTP Turn. 2001101 Finger. 2001102 Finger forwarding. Предпринята попытка использования программы finger для переадресации запроса другой системе. Это часто делается атакерами, чтобы замаскировать свою идентификацию. Finger поддерживает рекурсивные запросы. Запрос типа "rob@foo@bar" просит "bar" сообщить информацию о "rob@foo", заставляя "bar" послать запрос "foo". Эта техника может использоваться для сокрытия истинного источника запроса. Finger является опасным источником информации и по этой причине должен быть заблокирован в /etc/inetd.conf. 2001103 Finger forwarding overflow. 2001104 Finger command. 2001105 Finger list. 2001106 Finger filename. 2001107 Finger overflow. 2001108 Finger search. Демон "cfinger" позволяет осуществлять поиск любых или всех имен пользователей, при вводе "search.*". Эта возможность поиска предоставляет атакеру легкий способ пронумеровать всех пользователей системы. Широкополосные сканеры (напр. CyberCop Scanner, ISS Scanner) осуществляют сканирование этого типа. Сигнатурой для этого вида атаки является наличие строки "search.*" в качестве имени пользователя. 2001109

Finger Backdoor. Кто-то пытается повторно войти в систему через известную заднюю дверь в finger. Раз система была компрометирована, атакеры могу оставит для себя открытую "потайную" дверь, через которую они смогут войти, когда захотят. Например, одна потайная дверь допускает посылку finger команды "cmd_rootsh", которая открывает shell с привилегиями суперпользователя. Заметим, что если потайная дверь действительно имеется, ваша система уже была скомпрометирована. В настоящее время, все известные потайные двери finger существуют только в системах UNIX. Если вы столкнулись с такой проблемой то, во-первых, просмотрите информацию откликов, которая может быть в наличии. Если вы обнаружили какие-то уведомления об ошибках, то вероятно попытка вторжения не была успешной (но не обольщайтесь). Во-вторых, если вы озабочены возможностью наличия потайной двери в системе, исполните команду finger сами. Чтобы устранить уязвимость данного вида, следует, во-первых, рассмотреть возможность удаления услуги finger вообще. Это опасная услуга, которая предоставляет полезную информацию атакерам. Во-вторых, если вы чувствуете, что система компрометирована, следует заново инсталлировать операционную систему. Поищите потайную дверь в списке пользователей. Трудно представить, что какой-то пользователь в вашей системе имеет имя "cmd_shell". Многие широкодиапазонные сканеры ищут такие потайные двери. 2001110 Finger Scan. Производится сканирование известных из Finger имен пользователей с целью получения персональной информации. Например, если вы направляете запрос finger "jsmith", вы вероятно ищите данные о "Jane Smith". В безопасных сетях, любое использование finger подозрительно, так как оно может раскрыть важную информацию о пользователе. Однако, существует в системе большое число не пользовательских аккоунтов, таких как "adm", "bin" или "demo". Попытки Finger обратиться к этим аккоунтам указывают, что кто-то использует протокол finger для того, чтобы сканировать сервер с целью получения более существенной информации. В настоящее время, finger работает на UNIX-системах. Чтобы забыть об этих проблемах, заблокируйте finger. Если он работает, атакеры могут получить нужные им данные, а за помощь им вам не платят. 2001111 Finger Enumeration. Зафиксированы подозрительные команды finger. Finger используется для поиска информации о пользователях. Некоторые системы допускают множественный поиск пользователей. Здесь возможны некорректности. Например, запрос finger о пользователе с именем "e" выдаст список всех пользователей в системе, содержащими "e" в своем имени. Некоторые системы finger допускают также спецификацию множественных имен. Это означает, что finger для "a b c d e f...x y z" перечисляет всех пользователей в системе. В настоящее время, finger работает в основном на системах UNIX. Чтобы забыть об этих проблемах, заблокируйте finger. Если он работает, атакеры могут получить нужные им данные. 2001201 TFTP file not found. 2001202 TFTP file name overflow. 2001203 TFTP Traversal. 2001204 TFTP Exe Transfer. 2001205 TFTP Web Transfer. 2001206 TFTP Echo Bounce. 2001301 FTP invalid PORT command. Если вы такое обнаружили, это означает, что совершается попытка вторжения в вашу FTP-систему. Немногие ЭВМ допускают такую атаку. Команда "PORT" является частью протокола FTP но обычно незаметна для пользователя, хотя он часто и получает статусные сообщения "PORT command successful". Это уведомляет противоположную сторону о том, кода следует направлять данные. Эта команда форматируется в виде списка из 6 чисел, разделенных запятыми. Например:

PORT 192,0,2,63,4,01

Данная команда сообщает противоположной стороне, что данные следует отправлять по адресу 192.0.2.63, порт 1025. Если эта команда искажена, то вероятно атакер пытается компрометировать FTP-сервис. Однако, так как большинство FTP-сервисов противостоит этому типу атаки, шансов у хакера в этом варианте немного. 2001302 FTP PORT bounce to other system. 2001303 FTP PORT restricted. 2001304 FTP CWD ~root command. 2001305 FTP SITE EXEC command. Старые версии FTP-серверов поддерживают эту команду, которая разрешает нежелательный доступ к серверу. В версиях wu-ftpd ниже 2.2, имеется возможность исполнения программы (об этом хакер может только мечтать) . Ниже показана сессия, где "robert" имеет легальный аккоунт в системе и пытается реализовать режим строчно-командного доступа к shell.

220 example.com FTP server (Version wu-2.1(1) ready.

Name (example.com:robert): robert

331 Password required for robert.

Password: foobar

230 User robert logged in.

Remote system type is UNIX.

Using binary mode to transfer files.

ftp> quote "site exec cp /bin/sh /tmp/.runme"

200-cp /bin/sh /tmp/runme

ftp> quote "site exec chmod 6755 /tmp/.runme"

200-chmod 6755 /tmp/runme

ftp> quit

221 Goodbye.

Теперь пользователь авторизован и может работать с shell на уровне привилегий root в каталоге /tmp. 2001306 FTP USER name overflow. 2001307 FTP password overflow. 2001308 FTP CWD directory overflow. 2001309 FTP file name overflow. 2001310 FTP command line overflow. 2001311 FTP pipe in filename. Совершена попытка исполнить программу на FTP-сервере. Допускающее это ошибка имеется во многих FTP-демонах около 1997, таких что, если перед именем файла присутствует символ PIPE (|), сервер пытается исполнить программу имя которой следует за ним. Так как FTP-сервер обычно работает с привилегией root, может произойти его компрометация. Проверьте, что у вас работает новейшая версия сервера. 2001312 FTP MKD directory overflow. 2001313 ProFTPD snprintf exploit. 2001314 FTP SITE PSWD exploit. 2001315 FTP compress exec exploit. 2001316 FTP file exec exploit. 2001317 FTP command too long. 2001318 FTP data too long. 2001319 FTP NLST directory overflow. 2001320 FTP SITE ZIPCHK metacharacters. 2001321 FTP SITE ZIPCHK buffer overflow. 2001322 FTP SITE EXEC exploit. 2001323 FTP PrivilegedBounce.Кто-то пытается нарушить безопасность FTP-сервиса, чтобы сканировать другие ЭВМ. Если атака FTP используется при одновременной спецификации привилегированного порта, можете не сомневаться - это сетевая атака. Возможно, что FTP-переадресация на непривилегированный порт является результатом FTP-прокси. По этой причине комбинированная атака рассматривается как отдельная сигнатура. Это позволяет атакеру маскировать свою сетевую идентичность. Возможно также, что атакер, используя эту технику, может обойти некоторые плохо конфигурированные фильтры пакетов или firewalls. Например, если ваш mail-сервер допускает соединения посредством telnet с вашим внутренним FTP-сервером, а с внешними ЭВМ из Internet не допускает, атакер сможет соединиться с вашим telnet-портом на вашем SMTP методом переадресации через ваш FTP-сервер. К системам допускающим такую атаку относятся SunOS 4.1.x, Solaris 5.x, большинство систем, работающих со старыми FTP-серверами. Чтобы покончить с такого рода угрозой раз и навсегда. Просмотрите, какие ЭВМ и порты вовлечены в этот процесс. Если это ваши ЭВМ, проконтролируйте, как это реализовано. Если же это не ваша ЭВМ, убедитесь, что администратор этой машины, видит, что в соединении участвует ваш FTP-сервер, и если атака осуществлена, ваша машина будет выглядеть, как источник этой атаки. Вы можете провзаимодействовать с этим администратором или по крайней мере записать logs оригинального источника атаки. После этих дипломатических шагов вам следует установить новую версию FTP-сервера, где данная ошибка исправлена, например, wu-ftpd 2.4.2 beta 15 или более новую. 2001324 FTP Site Exec DotDot. Попытка неавторизованного доступа. Некоторые версии wu-ftpd позволяют использовать команду site exec для удаленных машин. Путем предоставления прохода с определенными параметрами, удаленный пользователь может исполнить произвольные команды на FTP-сервере. Эта атака позволяет атакующему выполнять команды на атакуемой машине. Это может привести к получению им доступа root-уровня. Такой дефект имеют системы wu-ftpd 2.4.1 и ранее. Чтобы защитить себя от таких атак, просмотрите команды, которые атакер использовал. Если они представляют угрозу для атакуемой ЭВМ, можете считать машину скомпрометированной. Обновите программное обеспечение FTP-сервера или замените его вообще. 2001325 FTP Site Exec Format Attack. 2001326 FTP Site Exec Tar. 2001327 FTP Site Chown Overflow. 2001328 FTP AIX Overflow. 2001329 FTP HELP Overflow. 2001330 FTP Glob Overflow. 2001331 FTP Pasv DoS. 2001332 FTP Mget DotDot. 2001401 RWHO host name overflow. 2001501 Back Orifice scan. Кто-то сканирует вашу систему на предмет троянского коня "Back Orifice". Back Orifice сканы наиболее частые атаки, встречающиеся в Internet. Ваша машина просканирована, но еще не выбрана для атаки. Это означает, что хакер сканирует тысячи ЭВМ в Interent, надеясь найти одну, которая была скомпрометирована посредством Back Orifice. Хакер не обязательно охотится именно на вашу ЭВМ. Большинство взломов происходит путем установки хакером инфицированных программ или документов в Internet в надежде, что какой-то неосторожный клиент скопирует и запустит их у себя. Хакер сканирует затем Internet и ищет эти скомпрометированные ЭВМ. Но даже, если ваша машина была скомпрометирована программой Back Orifice, ваша субсистема firewall может заблокировать доступ к ней. 2001502 Netbus response. 2001503 Quake backdoor. 2001504 HP Remote watch. 2001505 Back Orifice response. 2001506 Back Orifice ping. 2001507

PCAnywhere ping. Кто-то пингует систему для того чтобы проверить, работает ли PCAnywhere. Это может быть атака, но может быть и случайный инцидент. PCAnywhere является продуктом Symantec, который позволяет осуществить удаленное управление ЭВМ. Она является очень популярной в Internet для этих легальных целей, позволяя администраторам удаленно контролировать серверы. Хакеры часто сканируют Internet с целью поиска машин, поддерживающих этот продукт. Многие пользователи используют пустые пароли или пароли, которые легко угадать (например слово "password"). Это предоставит легкий доступ хакеру. Если хакер захватил контроль над машиной, он не только могут украсть информацию, но и использовать эту машину для атаки других ЭВМ в Интернет. Случайные сканирования клиентами PCAnywhere обычно видны со стороны соседей. Программа инсталлирует иконку, названную "NETWORK", которая сканирует локальную область. Хотя эти сканы не содержат враждебных намерений, они могут создавать дискомфорт. Чтобы проверить, что на самом деле имеет место, следует рассмотреть IP-адрес атакер. Если IP-адрес относится к локальному сегменту (т.e. подобен вашему IP-адресу), тогда ничего страшного. В противном случае (адрес внешний) - имеет место атака вашей системы. PCanywhere сканирует то, что называется диапазоном "класса C", например, 192.0.2.0 - 192.0.2.255. Если вы не работаете с PCAnywhere, тогда проблем нет. В противном случае, читайте советы по обеспечению безопасности сервера PCAnywhere. 2001508 ISS Ping Scan. 2001509 ISS UDP scan. 2001510 Cybercop FTP scan. 2001511 WhatsUp scan. 2001512 Back Orifice 2000 ping. 2001513 Back Orifice 2000 auth. 2001514 Back Orifice 2000 command. 2001515 Back Orifice 2000 response. 2001517 Scan by sscan program. 2001518 phAse Zero trojan horse activity. Возможная попытка вторжения. Программа phAse Zero обладает всеми стандартными особенностями троянского коня, включая возможность выгружать и загружать файлы в ЭВМ с помощью FTP, исполнять программы, стирать и копировать файлы, а также читать и записывать в конфигурационную базу данных (registry). Здесь имеется функция 'Trash Server', которая удалит все файлы из каталога вашей системы Windows. phAse Zero работает под Windows 95, 98 и Windows NT. 2001519 SubSeven trojan horse activity. 2001520 GateCrasher trojan horse activity. 2001521 GirlFriend trojan horse activity. 2001522 EvilFTP trojan horse activity. Неавторизованная попытка вторжения. Троянский конь EvilFTP является одним из многих программ подобного рода, который может использовать атакер для доступа к вашей компьютерной системы без вашего ведома. Когда программа, содержащая троянского коня работает, EvilFTP инсталлирует FTP-сервер на порт12346 с login "yo" паролем "connect." Этот троянский конь при инсталляции в удаленной системе позволяет атакеру выгружать и загружать файлы для системы, где он инсталлирован. 2001523 NetSphere trojan horse activity. 2001524 Trinoo Master activity. 2001525 Trinoo Daemon activity. 2001526 NMAP ping. Для проверки вашей системы на уязвимость используется программа NMAP. NMAP -очень популярная программа, используемая хакерами для сканирования Internet. Она работает под Unix, и имеет много конфигурационных опций и использует несколько трюков, чтобы избежать детектирования системами, детектирующими вторжение. NMAP не позволяет хакеру вторгнуться в систему, но допускает получение им полезной информации о конфигурации системы и доступных услугах. Программа часто используется как прелюдия более серьезной атаки. 2001527 NetSphere Client. Активность клиента NetSphere. Это указывает, имеется пользователь в вашей сети, который применил NetSphere для хакерства. Это не должно быть заметно клиентам, если только они сами не работают с NetSpheres. 2001528 Mstream agent activity. 2001529 Mstream handler activity. 2001530 SubSeven password-protected activity. 2001531 Qaz trojan horse activity. 2001532 LeakTest trojan horse activity. 2001533 Hack-a-tack trojan horse activity. 2001534 Hack-a-tack trojan horse ping. 2001535 Bionet trojan horse activity. 2001536 Y3K trojan horse ping. 2001537 Y3K trojan horse activity. 2001601 FTP login failed. 2001602 HTTP login failed. 2001603 IMAP4 login failed. 2001604 POP3 login failed. 2001605 rlogin login failed. 2001606 SMB login failed. 2001607 SQL login failed. 2001608 Telnet login failed. 2001609 SMTP login failed. 2001610 PCAnywhere login failed. 2001611 SOCKS login failed. 2001612 VNC login failed. 2001701 rpc.automountd overflow. 2001702 rpc.statd overflow. 2001703 rpc.tooltalkd overflow. 2001704 rpc.admind auth. 2001705 rpc.portmap dump. 2001706 rpc.mountd overflow. 2001707 RPC nfs/lockd attack. 2001708 rpc.portmap.set. 2001709 rpc.portmap.unset. 2001710 rpc.pcnfs backdoor. 2001711 rpc.statd dotdot file create. 2001712 rpc.ypupdated command. 2001713 rpc.nfs uid is zero. 2001714 rpc.nfs mknod. 2001715 rpc.nisd long name. 2001716 rpc.statd with automount. 2001717 rpc.cmsd overflow. 2001718 rpc.amd overflow. 2001719 RPC bad credentials. 2001720 RPC suspicious credentials. 2001721 RPC getport probe. 2001722 rpc.sadmind overflow. 2001723 rpc.SGI FAM access. 2001724 RPC CALLIT unknown. 2001725 RPC CALLIT attack. 2001726 RPC CALLIT mount. 2001727 rpc.bootparam whoami mismatch. 2001728 RPC prog grind. 2001729 RPC high-port portmap. 2001730 RPC ypbind directory climb. 2001731 RPC showmount exports. 2001732 RPC selection_svc hold file. 2001733 RPC suspicious lookup. 2001734 RPC SNMPXDMID overflow. 2001735 RPC CALLIT ping. 2001736 RPC yppasswdd overflow. 2001737 rpc.statd Format Attack. 2001738 RPC Sadmind Ping. 2001739 RPC Amd Version. 2001801 IRC buffer overflow. 2001802 SubSeven IRC notification. 2001803 IRC Trinity agent. 2001804 Y3K IRC notification. 2001901 IDENT invalid response. Чужой сервер пытается использовать identd клиента. Многие программы осуществляют реверсивные lookups IDENT. Эти программы уязвимы к атакам, когда сервер присылает некорректный отклик. 2001902 IDENT scan. 2001903 IDENT suspicious ID. 2001904 IDENT version. 2001905 IDENT newline. 2002001 SNMP Corrupt. 2002002 SNMP Crack. Обнаружено большое число строк community (паролей), которые индицируют попытку вскрыть систему контроля паролей. Большое число сообщений SNMP с различными строками community за ограниченный период времени должны рассматриваться как подозрительная активность, и как попытка подобрать корректное значение поля community. SNMP(Simple Network Management Protocol) используется для мониторирования параметров оборудования. Однако, это крайне небезопасный протокол, и ничто не препятствует простому подбору пароля путем простого перебора. Следует конфигурировать систему так, чтобы она была доступна со стороны ограниченного числа машин. Рекомендуется также использовать максимально возможно длинные строки community, что позволит зарегистрировать подбор до того, как он успешно завершится. 2002003 SNMP backdoor. Атакер пытается использовать известную "потайную дверь" сетевого оборудования. Однако, многие приборы имеют пароли для "потайной двери", которые могут использоваться для обхода нормальных проверок, предусмотренных нормальной системой обеспечения безопасности. Скрытые и недокументированные строки community имеются во многих субагентах SNMP, которые могут позволить атакерам поменять важные системные параметры. Удаленные атакеры могут убить любой процесс, модифицировать маршруты, или заблокировать сетевые интерфейсы. Важно то, что атакер может выполнить апосредовано произвольные команды, требующие привилегий суперюзера. 2002004 SNMP discovery broadcast. Атакер посылает команду SNMP GET по широковещательному адресу. Это может быть попыткой определить, какие системы поддерживают различные возможности SNMP. Это часто дает полную информацию об управляемом приборе, и иногда может предоставить полный контроль над прибором. В то же время, SNMP крайне небезопасный протокол, с легко угадываемым паролем. В результате, он является популярным протоколом для хакеров. 2002005 SNMP sysName overflow. 2002006 SNMP WINS deletion. Совершена попытка стереть записи WINS через интерфейс SNMP сервера. Это может быть попытка реализовать Denial-of-Service (DoS) или просканировать систему безопасности. Клиенты Windows контактируют с системой WINS для того, чтобы найти серверы. Многие системы уязвимы для атак при помощи SNMP-команд, посланных серверу для того, чтобы стереть записи. Это не взламывает сервер, но после стирания записи в базе данных, клиенты и серверые смогут более найти друг друга. Однако этот отказ обслуживания (DoS) может предварять другие атаки. Это может быть частью широко диапазонного сканирования с целью поиска слабых точек в сети. Эта атака может быть против систем, где нет работающих SNMP или WINS. 2002007 SNMP SET sysContact. Совершена попытка удаленно установить поле sysContact через SNMP. Это вероятно сканирование уязвимых мест вашей системы. Группа SNMP "system" используется всеми MIB. Она часто сканируется хакерами при предварительной разведке. Одним из способов сканирования является выполнение команд SET для поля "sysContact" для того, чтобы просмотреть, реагирует ли какая-либо система. Такие SET часто используют для взлома хорошо известные пароли/communities. 2002008 SNMP lanmanger enumeration. 2002009 SNMP TFTP retrieval. 2002010 SNMP hangup. Совершена попытка подвесить пользователя коммутируемой телефонной сети с помощью протокола SNMP. Некоторые типы сетевого оборудования (Ascend, Livingston, Cisco, etc.) могут допускать такое подвешивание пользователей. Это может быть обычным отказом обслуживания (DoS) в chat-комнатах и при играх в реальном времени. Один участник в chat-комнате может не любить другого. Он может взять IP-адрес жертвы, затем осуществлять поиск, пока не найдут прибор доступа, через который подключен клиент телефонной сети. 2002011 SNMP disable authen-traps. Совершена попытка заблокировать трэпы неудач SNMP-аутентификации, возможно с целью замаскировать активность хакера. Если строка community некорректна, прибор может послать на консоль управления трэп "authentication-failure". Эти строки community не управляют доступом всего SNMP-агента MIB. Вместо этого, они управляют "видами" MIB: различные строки community могут позволять управление различными частями MIB. Предположим сценарий, где атакер желает взломать строку community, отвечающую за секцию MIB поставщика. Это включает множество (возможно миллионы) попыток выяснить правильный пароль. Следовательно, чтобы избежать оповещений об атаке, нападающий должен заблокировать трэпы, которые могут поступить на консоль. 2002012 SNMP snmpdx attack. Совершена попытка заменить Sun Solstice Extension Agent, используя SNMP. Это может быть попытка вскрыть систему. Sun Solaris 2.6 поставляется со встроенной SNMP. В этот пакет входит возможность "extension agents": агенты, которые подключены к первичному SNMP-агенту для управления другими частями системы. Следует просмотреть log-book b jndtnbnm на вопросы:

Имеется ли платформа управления, которая может выполнять подобные операции? Является ли строка "community" одной из "печально" известных для Solaris (в особенности "all private")? Параметр "val" содержит имя программы, которая будет исполнена. Выглядит ли это как демон или выглядит ли она как программа, предназначенная для компрометации системы? Типичными вариантами компрометации является создание xterm или скрипта, который изменяет /etc/passwd. 2002013 SNMP 3Com communities. Совершена попытка прочесть строку community/пароля устройства 3Com с помощью SNMP. Это может быть попыткой проникновения в систему. Многие старые версии оборудования 3Com содержат дефекты, которые делают строку community/пароля общедоступной. Атакер, чтобы получить пароли, может прочесть специфические таблицы, используя строку community+"public". После этого атакер получает полный контроль над прибором. Такого рода атаки возможны для хабов 3Com SuperStack II версий ранее 2.12, карт HiPer Arc, с кодами выпуска ранее 4.1.59. 2002014

SNMP dialup username. 2002015 SNMP dialup phone number. 2002016 SNMP scanner. 2002017 SNMP passwd. 2002018 SNMP community long. 2002019

SNMP echo bounce. Обнаружен пакет UDP путешествующий между портами SNMP и ECHO. Техника, которая иногда используется, заключается в том, что пакеты SNMP посылаются службе ECHO промежуточной системы. IP-адрес отправителя фальсифицируется так, чтобы ECHO посылалось службе SNMP атакуемой системы. Атакуемый объект доверяет промежуточной системе и поэтому принимает пакет. 2002020 SNMP HP Route Metachar. 2002101 rlogin -froot backdoor. 2002102 rlogin login name overflow. 2002103 rlogin password overflow. 2002104 rlogin TERM overflow. 2002105 Rlogin login name well known. 2002201 Melissa virus. 2002202 Papa virus. 2002203 PICTURE.EXE virus. 2002204 W97M.Marker.a virus. 2002205 ExploreZip worm. 2002206 Keystrokes monitored. 2002207 PrettyPark worm. 2002208 ILOVEYOU worm. 2002209 Worm extensions. 2002210 Worm address. 2002301 Duplicate IP address. 2002401 NNTP name overflow. 2002402 NNTP pipe seen. 2002403 NNTP Message-ID too long. 2002500 Suspicious URL. 2002501 bat URL type. 2002502 cmd URL type. 2002503

CGI aglimpse. Совершена попытка исполнить программу aglimpse, которая имеет известные уязвимости. Атакер сканирует web-сервер системы и ищет потенциальные уязвимости в секции web-сервера "dynamic content generation" (динамическая генерация содержимого). Эта утилита web-сервера исполняет отдельную программу для генерации web-страниц, когда пользователи осуществляют доступ к сайту. Существует сотни таких программ, которые содержат ошибки в сфере безопасности. В данном примере, хакер просматривает web-сервер и ищет одну из таких программ. Большая часть того, что вы читали в новостях о хакерских "штучках", является описанием слабостей таких программ и повреждений web-сайта. Особенно много информации можно найти о слабостях cgi-bin. Если скрипт виден внешнему миру, вам следует удалить его из данного каталога. Следует также удалить все динамическое содержимое, которое не является абсолютно необходимым для работы web-сайта. Выполните двойную проверку скриптов, которые вы действительно используете, на предмет наличия в них брешей уязвимости. Данная атака является стандартной, использующей метасимвольный CGI на PERL. Программа PERL передает "поврежденный" ввод пользователя непосредственно в интерпретатору shell. 2002504 CGI AnyForm2. Совершена попытка исполнить программу anyform2, которая имеет известную уязвимость. Программа AnyForm cgi-bin содержит уязвимость, которая позволяет удаленному атакеру исполнять программы Web-сервера. Атакер сканирует web-сервер системы и ищет потенциальные уязвимости в секции web-сервера "dynamic content generation" (динамическая генерация содержимого). Эта утилита web-сервера исполняет отдельную программу для генерации web-страниц, когда пользователи осуществляют доступ к сайту. Существует сотни таких программ, которые содержат ошибки в сфере безопасности. В данном примере, хакер просматривает web-сервер и ищет одну из таких программ. 2002505 CGI bash. Совершена попытка исполнить скрипт bash, который в случае успеха, позволит хакеру получить доступ к серверу. Это программа shell, которая может исполнять произвольные операции на сервере. Если она была случайно помещена в удаленно доступный каталог, и, если вы обнаружили, что какие-то параметры системы стали доступны хакеру, считайте свою систему скомпрометированной. Вы должны немедленно удалить эту программу из данного каталога, проверить систему на наличие троянских коней и проконтролировать, не изменялась ли ее конфигурация. 2002506 CGI campas. Совершена попытка исполнить campas, которая имеет известную уязвимость. Это известный скрипт, поставляемый с оригинальными web-серверами NCSA. Он оказался весьма популярным среди хакеров (вместе с phf), но в настоящее время его важность незначительна. Эта точка уязвимости позволяет удаленному атакеру исполнять команды на ЭВМ Web-сервера, как если бы он работал на самой машине, где размещен httpd. Эта уязвимость разрешает доступ хакеру к файлам web-сервера. При определенных конфигурациях web-сервера возможно получение хакером административного доступа к ЭВМ. 2002507 CGI convert.bas. 2002508 CGI csh. 2002509 CGI faxsurvey. 2002510 CGI finger. Произведена попытка исполнить программу finger, который может позволить хакеру неавторизованный доступ к серверу. Атакер сканирует web-сервер системы и ищет потенциальные точки уязвимости в секции "dynamic content generation". Эта утилита web-сервера исполняет отдельную программу для генерации web-страниц, когда пользователь получает доступ к сайту. Существуют сотни таких программ, которые имею окна уязвимости. в данном примере, хакер просматривает web-сервер и ищет одну из таких уязвимых программ. Дополнительную информацию можно найти в cgi-bin exploits. Если этот скрипт виден внешнему миру, его следует удалить из данного каталога. Следует удалить также все динамические данные, которые совершенно необходимы для работы web-сайта. 2002511 CGI formmail. 2002512 CGI formmail.pl. 2002513 CGI glimpse. Попытка исполнения программы glimpse, которая известна своими уязвимостями. Эти уязвимости позволяют атакеру исполнять команды на ЭВМ Web-сервера во время работы процесса пользователя в httpd. В зависимости от конфигурации web-сервер, это может позволить атакеру получит root или административный доступ к ЭВМ. В любом случае, атакер сможет изменить содержимое web-сайта. 2002514 CGI guestbook.cgi. 2002515 CGI guestbook.pl. 2002516 CGI handler. Попытка исполнения CGI-хандлера, который обладает известными слабостями Эта CGI-программа является частью "Outbox Environment" в системах SGI IRIX. Программа может использоваться для выполнения любой команды на web-сервере. Для того, чтобы реализовать это, используйте программу Telnet следующим образом:

telnet www.example.com 80

GET /cgi-bin/handler/useless_shit;cat /etc/passwd|?data=Download HTTP/1.0

Используйте символ TAB, чтобы ввести пробел в пределах команды. 2002517

CGI htmlscript. 2002518 CGI info2www. 2002519 CGI machineinfo. 2002520 CGI nph-test-cgi. 2002521 CGI perl. Произведена попытка исполнить perl-скрипт, который позволит хакеру неавторизованный доступ к серверу. Это программа shell, которая может выполнить произвольные операции на сервере. Если эта программа случайно помещена в удаленно доступный каталог, и, если выявлена модификация некоторого системного параметра, можете считать свою систему скомпрометированной. Вам следует немедленно удалить программу из ее каталога и поместить в более подходящее место, проверьте вашу систему на наличие троянских коней, а также проконтролируйте конфигурацию на предмет возможных модификаций. 2002522 CGI perl.exe. Произведена попытка исполнить perl.exe, которая позволит хакеру неавторизованный доступ к серверу. Это программа shell, которая может выполнить произвольные операции на сервере. Если эта программа случайно помещена в удаленно доступный каталог, и, если выявлена модификация некоторого системного параметра, можете считать свою систему скомпрометированной. Вам следует немедленно удалить программу из ее каталога и поместить в более подходящее место, проверьте вашу систему на наличие троянских коней, а также проконтролируйте конфигурацию на предмет возможных модификаций. 2002523 CGI pfdispaly.cgi. 2002524 CGI phf. 2002525 CGI rguest.exe. 2002526 CGI wguest.exe. 2002527 CGI rksh. 2002528 CGI sh. 2002529 CGI tcsh. 2002530 CGI test-cgi.tcl. 2002531 CGI test-cgi. 2002532 CGI view-source. 2002533 CGI webdist.cgi. 2002534 CGI webgais. 2002535 CGI websendmail. 2002536 CGI win-c-sample.exe. 2002537 CGI wwwboard.pl. 2002538 CGI uploader.exe. 2002539 CGI mlog.html. 2002540 CGI mylog.html. 2002541 CGI snork.bat. 2002542 CGI newdsn.exe. 2002543 FrontPage service.pwd. 2002544 .bash_history URL. 2002545 .url URL type. 2002546 .lnk URL type. 2002547 WebStore admin URL. 2002548 Shopping cart order URL. 2002549 Order Form V1.2 data URL. 2002550 Order Form data URL. 2002551 EZMall data URL. 2002552 QuikStore configuration URL. 2002553 SoftCart password URL. 2002554 Cold Fusion Sample URL. 2002555 favicon.ico bad format. 2002556 Site Server sample URL. 2002557 IIS sample URL. 2002558 IIS password change. 2002559 IIS malformed .HTR request. 2002560 IIS data service query. 2002561 .htaccess URL. 2002562 passwd.txt URL. 2002563 NT system backup URL. 2002564 CGI imagemap.exe. 2002565 adpassword.txt URL. 2002566 CGI whois suspicious field. 2002567 Cold Fusion cache URL. 2002568 IIS malformed HTW request. 2002569 CGI finger.cgi. 2002570 WebSpeed admin URL. 2002571 UBB suspicious posting. 2002572 SubSeven ICQ pager URL. 2002573 Oracle batch file URL. 2002574 sojourn.cgi argument contains %20. 2002575 Index Server null.htw exploit. 2002576 FrontPage extension backdoor URL. Прислан "подозрительный" URL. Библиотека dvwssr.dll, встроенная в расширения FrontPage 98 для IIS, включает в себя ключ шифрования "Netscape engineers are weenies!". Этот ключ может быть использован для маскирования имени запрошенного файла, который затем передается в качестве аргумента в dvwssr.dll URL. Любой, кто имеет привилегии доступа к web-серверу ЭВМ мишени может загрузить любую Web-страницу, включая файлы текстов программ ASP. Используя файл dvwsrr.dll можно также переполнить буфер. Успешная атака может позволить исполнение на сервере удаленной программы. 2002577 FrontPage htimage.exe URL. 2002578 InfoSearch CGI exploit. 2002579 Cart32 Clientlist URL. 2002580 Cart32 ChangeAdminPassword URL. 2002581 Listserv CGI exploit. 2002582 Calendar CGI exploit. Подозрительный URL. Конфигурационный параметр содержит мета-символы, которые вероятно означают, что атакер пытается использовать слабости в некоторых версиях CGI-скрипта. В случае успеха, он сможет выполнить произвольную команду на сервере. 2002583 Rockliffe CGI exploit. 2002584 RealServer Denial-of-service URL. 2002585 Java Admin Servlet backdoor URL. Административный модуль Java Web Server допускает компиляцию и исполнение программы Java server с помощью специального URL. Если атакеру удалось загрузить свой собственный Java-код на сервере, он может тогда скомпилировать и исполнить этот код и получить контроль над серверной системой. 2002586 DOS DoS URL. 2002587 Auction Weaver CGI exploit. 2002589 CGI jj exploit. 2002590 classifieds.cgi. 2002591 BNBSurvey survey.cgi. 2002592 YaBB exploit. 2002593 Webplus CGI exploit. 2002594 Squid cachemgr.cgi. 2002595 IIS system32 command. 2002596 Webevent admin. 2002597 Unify UploadServlet. 2002598 Thinking Arts directory traversal. 2002599 Lotus Domino directory traversal. 2002600 Commerce.cgi directory traversal. 2002601 CGI mailnews suspicious field. 2002602 FrontPage Publishing DoS. 2002603

way-board cgi file access. 2002604

roads cgi file access. 2002605

Hack-a-tack ICQ pager URL. 2002606

Bionet ICQ pager URL. 2002607

IIS .printer overflow. 2002608

ISAPI index extension overflow. 2002609

Y3K ICQ pager URL. 2002610 HTTP Pfdisplay Execute. 2002611 HTTP Pfdisplay Read. 2002701 SMB passwd file. 2002702 SMB sam file. 2002703 SMB winreg file. 2002704 SMB pwl file type. 2002705 SMB win.ini file. 2002706 Startup file access. 2002707 SMB autoexec.bat file access. 2002710 SMB RICHED20.DLL access. 2002801 MS rpc dump. Атакер пытается сканировать вашу систему для услуг RPC/DCOM. Возможно он ищет слабости в системе доступа. Была попытка загрузки списка всех услуг RCP/DCOM. Это специальная команда, которая может быть послана к "RPC End-Point Mapper" работающему с port 135. Эта атака не направлена непосредственно на вторжение. Она является частью (разведывательного этапа) reconnaissance атаки. Команда 'epdump' попросит ЭВМ Windows перечислить все работающие сервисы. Хакер, получив эти данные, сможет эффективнее искать слабые места в вашей обороне. Если хакер найдет какие-то их этих услуг, он вероятно попытается воспользоваться ими. Например, существуют пути, посредством которых спамер может направить e-mail через Microsoft Exchange Servers. Путем выполнения 'epdump', спамер может выяснить, работает ли машина в качестве сервера. Если это так, спамер может затем заставить систему переадресовать SPAM своим "клиентам". Зафильтруйте порт 135 в firewall, как для UDP так и TCP. 2002802 MS share dump. 2002803 MS domain dump. 2002804 MS name lookup. 2002805 MS security ID lookup. 2002806 Malformed LSA request. 2002807 RFPoison attack. 2002808 LsaLookup Denial of Service. 2002901 PPTP malformed. 2002902 IGMP fragments. 2002903 SNTP malformed. 2002904 XDMCP gdm exploit. 2002905 VNC no authentication. 2002906 VCF attachment overflow. 2002907 SNTP overflow. 2002908 Quake Exploit. 2002911 RADIUS User Overflow. 2002912 RADIUS Pass Overflow. 2003001 HTTP port probe. 2003002 POP3 port probe. 2003003 SMTP port probe. 2003004 FTP port probe. 2003005 IMAP4 port probe. 2003006 TELNET port probe. 2003007 FINGER port probe. 2003008 RLOGIN port probe. 2003009 NetBIOS port probe. 2003010 NNTP port probe. 2003011 DNS TCP port robe. 2003012 PCANYWHERE port probe. 2003013 SQL port probe. 2003014 MSRPC TCP port probe. 2003015 XWINDOW port probe. Возможно хакер просканировал вашу систему, чтобы проверить, доступно ли XWINDOWS. Иногда это делается в ходе подготовки будущей атаки, или иногда это делается с целью выяснения, уязвима ли ваша система. 2003016 RPC TCP port probe. 2003017 SOCKS port probe. Кто-то сканирует вашу систему, чтобы проверить, не работает ли там SOCKS. Это означает, что хакер хочет устроить переадресацию трафика через вашу систему на какой-то другой сетевой объект. Это может быть также chat-сервер, который пытается определить, не пробует ли кто-то использовать вашу систему для переадресации. SOCKS представляет собой систему, которая позволяет нескольким машинам работать через общее Интернет соединение. Многие приложения поддерживают SOCKS. Типичным продуктом является WinGate. WinGate инсталлируется на ЭВМ, которая имеет реальное Интернет соединение. Все другие машины в пределах данной области подключаются к Интернет через эту ЭВМ. Проблема с SOCKS и продуктами типа WinGate заключается в том, что они не делают различия между отправителем и получателем, что облегчает удаленным машинам из Интернет получить доступ к внутренним ЭВМ. Что важно, это может позволить хакеру получить доступ к другим машинам через вашу систему. При этом хакер маскирует свое истинное положение в сети. Атака против жертвы выглядит так, как если бы она была предпринята со стороны вашей машины. Этот вид атаки на первом этапе выглядит как сканирование. При использовании SOCKs систему следует конфигурировать так, чтобы заблокировать посторонний доступ. Хакер рассчитывает на вашу ошибку при конфигурации. 2003018 PPTP port probe. 2003019 IRC port probe. 2003020 IDENT port probe. 2003021 Linux conf port probe. 2003022 LPR port probe. 2003101 TCP trojan horse probe. 2003102 TCP port probe. Кто-то пытался получить доступ к вашей машине, но не смог. Это довольно распространенный вид атаки. Типовой хакер сканирует миллионы ЭВМ, не обольщайтесь вы не являетесь главным объектом интересов хакеров, но и расслабляться пожалуй не следует. 2003103 Netbus probe. Кто-то попрововал получить доступ к вашей ЭВМ с помощью "NetBus Trojan Horse" и потерпел неудачу. Хакер ищет ЭВМ, скомпрометированную посредством этой программы. Раз вы не скомпрометированы, хакер потерпел неудачу. Программа Trojan рассылается клиентам в надежде, что какой-то легкомысленный человек ее запустит. Задача такой программы похитить пароль, установить вирус, или переформатировать ваш диск. Специальную популярную группу образуют троянские кони, обеспечивающие удаленный доступ к вашей машине. Такие программы хакер пытается прислать по почте, через chat или новости, при этом хакер может не знать, где в Интернет находится ваша ЭВМ (он не знает, кто читает новости, да и по почте он рассылает эту гадость по тысячам адресов). Хакер знает только, кто является вашим провайдером, и вынужден сканировать всех клиентов данного ISP. При таком сканировании хакера устроит ситуация, когда вы получили данного троянского коня от другого атакера. 2003104 Proxy port probe. Атакер сканирует вашу систему с целью обнаружения прокси-сервера. Затем атакер может воспользоваться вашим прокси-сервером для анонимного просмотра Internet. В настоящее время сканирование TCP-портов 3128,8000 или 8080 рассматривается как обращение к прокси. 2003105 SubSeven port probe. 2003106 T0rn port probe. 2003201 SECURITY/SAM reg hack. Была предпринята попытка доступа к ключу registry под HKLM/SECURITY/SAM. Под этим ключом зарегистрированы имена и пароли пользователей. Хотя пароли зашифрованы, они могут быть проанализированы off-line и выяснены путем грубого перебора. 2003202 RUN reg hack. Была предпринята попытка записи в ключи registry, которые управляют программой при загрузке системы или когда в систему входит новый пользователь. Такими ключами являются

HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/Run

HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/RunOnce

HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/RunOnceEx

HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/RunServices

HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/RunServicesOnce

HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/RunServicesEx

Если имела места попытка записи в один из этих ключей, это может быть попыткой продвинуть Trojan Horse. 2003203 RDS reg hack. Была предпринята серьезная попытка скомпрометировать систему или легальная сетевая платформа осуществляет удаленное конфигурирование системы. Осуществлена попытка удаленной записи ключей registry

HKLM\SOFTWARE\Microsoft\DataFactory\HandlerInfo или

HKLM\SOFTWARE\Microsoft\Jet\3.5\Engines\SandboxMode.

Эти ключи ограничивают удаленный доступ к определенным базам данных в системе Windows. Атакер может попытаться установить свои значения для этих объектов registry, так что неавторизованный удаленный доступ может быть осуществлен позднее через точку уязвимости RDO exploit. По умолчанию, эти ключи могут быть переписаны кем угодно. Разрешения должны быть изменены так, что только администратор мог их менять. 2003204 Index Server reg hack. Была предпринята попытка удаленного доступа к записям Index Server's registry. Сделана попытка доступа к ключу registry Remove remote access в HKLM\SYSTEM\CurrentControlSet\Control\SecurePipeServers\Winreg\AllowedPaths 2003205 NT RASMAN Privilege Escalation attempt. Была предпринята попытка удаленного доступа к троянскому коню RAS manager. Сделана попытка доступа к ключу registry HKLM\SYSTEM\CurrentControlSet\Services\RASMan, который удаленно изменяет программу путем изменения сервера, при следующем запуске ЭВМ, будет исполнена специфицированная программа. 2003206 LSA Secrets attempt. Была предпринята попытка удаленного доступа к "Local System Authority" через вызов registry. Атакер получает удаленный доступ к информации о секретных пароля хremotely. Эти пароли хранятся в зашифрованном виде в registry. 2003207 AeDebug reg hack. 2003208 IMail privilege escalation attempt. 2003209 SQL Exec Passwd. Была предпринята попытка сканирования записей SQLExecutive registry. Происходит подозрительное чтение записей registry из SQL-сервера. Иногда пароли записываются в registry, что делает систему уязвимой. 2003301 AOL Instant Messenger overflow. 2003302 AOL w00w00 attack. 2003401 SNMP port probe. 2003402 RPC UDP port probe. 2003403 NFS port probe. 2003404 TFTP port probe. 2003405 MSRPC UDP port probe. 2003406 UDP ECHO port probe. 2003407 CHARGEN port probe. 2003408 QOTD port probe. 2003409 DNS UDP port probe. 2003410 MSDNS port probe. 2003411 NFS-LOCKD port probe. 2003412 Norton Antivirus port probe. 2003501 UDP Trojan Horse probe. 2003502 UDP port probe. 2003601 FTP passwd file. 2003602 FTP sam file. 2003604 FTP pwl file type. 2003605 FTP win.ini file. 2003606 FTP Host File. 2003701

TFTP passwd file. 2003702

TFTP sam file. 2003704

TFTP pwl file type. 2003705

TFTP win.ini file. 2003706 TFTP Host File. 2003707 TFTP Alcatel files. 2003801 HTTP GET passwd file. Была предпринята подозрительная попытка доступа к файлу. Сделана попытка доступа к файлу passwd, который содержит зашифрованные Unix-пароли. Атакер может после этого использовать общедоступные программные средства для вскрытия паролей, содержащихся в этом файле. 2003802 HTTP GET sam file. 2003804 HTTP GET pwl file type. 2003806 HTTP GET AltaVista password. 2003901 HTTP POST passwd file. 2003902 HTTP POST sam file. 2003904 HTTP POST pwl file type. 2003905 HTTP POST win.ini file. Была предпринята попытка удаленного доступа к системному файлу WIN.INI посредством Web-формы. Эта попытка может быть сопряжена с намерением реконфигурировать систему, чтобы реконфигурированная система при последующем запуске загрузила троянского коня. 2004001 SOCKS connect. Кто-то подключился через вашу систему, используя протокол SOCKS. Это может быть хакер, который хочет переадресовать трафик через вашу систему на другие ЭВМ, а также сервер chat, пытающийся определить, не пробует ли кто-то проскочить через вашу систему чтобы работать анонимно на "халяву". SOCKS представляет собой систему, которая позволяет нескольким машинам работать через общее Интернет соединение. Многие приложения поддерживают SOCKS. Типичным продуктом является WinGate. WinGate инсталлируется на ЭВМ, которая имеет реальное Интернет соединение. Все другие машины в пределах данной области подключаются к Интернет через эту ЭВМ. Проблема с SOCKS и продуктами типа WinGate заключается в том, что они не делают различия между отправителем и получателем, что облегчает удаленным машинам из Интернет получить доступ ко внутренним ЭВМ. Что важно, это может позволить хакеру получить доступ к другим машинам через вашу систему. При этом хакер маскирует свое истинное положение в сети. Атака против жертвы выглядит так, как если бы она была предпринята со стороны вашей машины. Этот вид атаки на первом этапе выглядит как сканирование. При использовании SOCKs систему следует конфигурировать так, чтобы заблокировать посторонний доступ. Хакер рассчитывает на вашу ошибку при конфигурации. Ваша внутренняя сеть должна использовать IP-адреса, которые никогда не появляются в Internet. Такими адресами обычно являются "192.168.x.x", "172.16.x.x" или "10.x.x.x". 2004002 SOCKS over SOCKS. Кто-то подключился через вашу систему, используя протокол SOCKS. то может быть хакер, который хочет переадресовать трафик через вашу систему на другие ЭВМ. В этом случае, трафик оказывается инкапсулированным в SOCKS, это означает, что атакер вероятно намерен использовать вашу систему для переадресации к другой системе SOCKS. SOCKS представляет собой систему, которая позволяет нескольким машинам работать через общее Интернет соединение. Многие приложения поддерживают SOCKS. Типичным продуктом является WinGate. WinGate инсталлируется на ЭВМ, которая имеет реальное Интернет соединение. Все другие машины в пределах данной области подключаются к Интернет через эту ЭВМ. Проблема с SOCKS и продуктами типа WinGate заключается в том, что они не делают различия между отправителем и получателем, что облегчает удаленным машинам из Интернет получить доступ ко внутренним ЭВМ. Что важно, это может позволить хакеру получить доступ к другим машинам через вашу систему. При этом хакер маскирует свое истинное положение в сети. Атака против жертвы выглядит так, как если бы она была предпринята со стороны вашей машины. 2004101 Java contains Brown Orifice attack. 2004201 HTTP Cross site scripting. 2004301 DHCP Domain Metachar. 2004302 BOOTP File Overflow. 2004303 UPNP NOTIFY overflow. 2004401 SubSeven email. 2004402 Bionet email. Программа троянского коня Bionet имеет возможность посылать оповещения через e-mail, когда система, содержащая троянского коня, загружается. Это позволяет хакеру знать, что Bionet работает, и ваша система может быть компрометирована хакером. Судя по всему ваша система скомпрометирована. Вам следует использовать антивирусную программу, чтобы немедленно удалить троянского коня Bionet из вашей системы. 2004403 Y3K email. 2004501 HTTP GET contains xp_cmdshell. В качестве аргумента URL обнаружена строка xp_cmdshell; это обычно указывает, что предпринята попытка исполнить команду shell для атакера исполнять на сервере команды shell. 2004502 HTTP POST contains xp_cmdshell. В данных, передаваемых Web-сайту, обнаружена строка xp_cmdshell. Это обычно указывает, что предпринята попытка выполнить команду shell на SQL-сервере. Если SQL-сервер некорректно сконфигурирован, имеется возможность для атакера выполнять на сервере команды shell. 2004601 Code Red I. 2004602 Code Red II. 2004603 Code Red II+. 2009100 DNS crack successful. 2009201 ISS Scan. 2009202 CyberCop Scan. 2009203 Nessus Scan. 2009204 Satan Scan. 2009205 Saint Scan. 2009206 Cerebus Scan. 2009207 Retina Scan. 2010000-2010999 User-specified filename. 2011000-2011999 User-specified URL. 2012000-2012999 User-specified email recipient. 2013000-2013999 User-specified email pattern. 2014000-2014999 User-specified MIME-attached filename. 2015000-2015999 User-specified TCP probe port. 2016000-2016999 User-specified UDP probe port. 2017000-2017999 User-specified registry key. 2018000-2018999 User-specified TCP trojan response. 2019000-2019999 User-specified IRC channel name. 2020000-2020999 User-specified Java pattern. 2900001 Application Terminated. 2900002 Application Added. 2900003 Application Communication Blocked. Config Configuration parameters.

Технические средства сетевой безопасности

Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru

Основу стабильности сети составляют надежность ЭВМ и сетевого оборудования, а также устойчивость каналов связи. Каналы связи, особенно если речь идет о проводных, достались нам от проклятого царизма, их создатели давно умерли и спросить не с кого. Начинать надо с того, что в вашей власти, а это прежде всего правильная конфигурация узла, разумное распределение ответственности и качество сетевого питания (стабильность напряжения и частоты, амплитуда помех). Для решения последней проблемы используют специальные фильтры, мотор-генераторы и UPS (Uninterruptable Power Supply). Выбор того или иного решения зависит от конкретных условий, но для серверов использование UPS крайне желательно (ведь вы не хотите восстанавливать дисковую систему, которая разрушилась из-за отключения питания в момент записи в FAT или dir). При снижении напряжения сети переменного тока ниже определенного уровня UPS (около 208v) отключает потребителя от сети и осуществляет питание ЭВМ от ~220v, получаемого от аккумулятора самого UPS. Учитывая нестабильность напряжения сети в России, можно считать полезным применение активных стабилизаторов на входе UPS.

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

Рис. 6.1.1. Схема подключения UPS.

При исчезновении первичного напряжения ~220V спустя некоторое время UPS выдает сигнал shutdown вычислительной машине. Современный UPS может мониторировать не только напряжение питание, но температуру окружающей среды, своевременно осуществляя спасение жизненно важных файлов до наступления чрезмерного перегрева системы.
При этом значение напряжения питания и температуры можно считывать с использованием протокола SNMP. Некоторые продвинутые системы автономного питания допускают подключение агентов SNMP непосредственно к локальной сети, что открывает дополнительные возможности дистанционного управления и мониторинга.

Указанный интерфейс обеспечит блокировку начала новых операций обмена или выполнит shutdown, если напряжение в сети упало ниже допустимого уровня. К UPS не следует подключать дисплеи (эти приборы не столь критичны к питанию, как диски и оперативная память) и принтеры (лазерные принтеры запрещено подключать к UPS из-за мощных печек, входящих в состав этих приборов). Сетевые фильтры являются желательными при работе с любыми ЭВМ, так как сеть в России сильно засорена высокочастотными помехами.

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

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


Для ввода подписи служат специальные планшеты , а также изощренные методы сравнения и установления идентичности.

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

Поскольку абсолютная надежность недостижима, одним из средств сохранения информации является дублирование носителей (напр. дисков), копирование и сохранение копий в надежном месте. Если раньше для этой цели годились гибкие диски или магнитные ленты, сегодня их пригодность может быть подвергнута сомнению. Конечно, ленты типа Exabyte емкостью 2.5-10Гбайт еще достаточно широко используются, высокая стоимость таких накопителей ограничивает их применимость (да и скорость записи на них оставляет желать лучшего). Альтернативой им могут стать накопители с перезаписываемыми CD, где стоимость устройства несколько ниже, за то емкость одного диска для дешевых моделей пока не превосходит 1 Гбайт. Не исключено, что в скором времени основным средством сохранения информации станет ее дублирование на независимом жестком диске. Это может произойти при широком внедрении компактных жестких дисков емкостью 10 Гбайт и более .

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

Типовой протокол обмена сообщениями

В несколько упрощенном варианте диалог SSL представлен на рис. 6.5.1.

Рис. 6.5.1. Алгоритм работы SSL

Ниже представлено несколько вариантов обмена сообщениями в рамках протокола диалога SSL. В этих примерах представлены два участника диалога: клиент (С) и сервер (S). Если что-то помещено в фигурные скобки, например, "{нечто}key", это означает, что "нечто" зашифровано с помощью ключа "key".

Типы инцидентов

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

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

(1)	Охватывает ли данный инцидент несколько узлов?
(2)	Инцидент затронул много ЭВМ вашего узла?
(3)	Вовлечена ли важная (чувствительная) информация?
(4)	Что является входной точкой атаки (сеть, телефонная линия, локальный терминал и т.д.)?
(5)	Вовлечена ли пресса?
(6)	Каков потенциальный ущерб инцидента?
(7)	Каково ожидаемое время улаживания инцидента?
(8)	Какие ресурсы нужны на ликвидацию инцидента?
(9)	Подразумевается ли привлечение юридической поддержки?

Типы уведомлений и обмен информацией

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

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

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

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

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

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

(1)	Временная зона журнальных записей, в формате GMT или местное время
(2)	Информация об удаленной системе, включая имена ЭВМ, IP-адреса и (может быть) ID пользователей
(3)	Все журнальные записи, связанные с удаленным узлом
(4)	Тип инцидента (что случилось, почему вы должны принять меры)

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

Тщательно выбирайте открывающую метку

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

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

Для высоко секретных приложений, рассмотрите использование "слепого" пароля (т.e., не давайте никакого отклика на ввод пользователем пароля). Это эффективно эмулирует поведение неисправного модема.

Уровень записей

Уровень записей TLS получает не интерпретированные данные от верхних уровней в непустых блоках произвольного размера.

Узлы, вовлеченные в инцидент

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

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

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

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

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

Варианты

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

struct {

	T1 f1;
	T2 f2;
	....
	Tn fn;
	select (E) {
	case e1: Te1;
	case e2: Te2;
	....
	case en: Ten;
	} [[fv]];} [[Tv]];

Например:

enum { apple, orange } VariantTag;
struct {

	uint16 number;
	opaque string<0..10>; /* переменная длина */
	} V1;

struct {

	uint32 number;
	opaque string[10]; /* фиксированная длина */
	} V2;

struct {

	select (VariantTag) {		/* value of selector is implicit */
	case apple: V1;		/* VariantBody, tag = apple */
	case orange: V2;		/* VariantBody, tag = orange */
		} variant_body;		/* optional label on variant */
	} VariantRecord;

Структуры варианта могут быть подготовлены (сужены) путем спецификации значения селектора до спецификации типа. Например: orange VariantRecord является суженным типом для VariantRecord, содержащего variant_body типа V2.

Векторы

Вектор (одномерный массив) является потоком однородных информационных элементов. Размер вектора может быть специфицирован во время документирования или оставаться не специфицированным вплоть до начала работы. В любом случае длина определяет число байтов, а не число элементов в векторе. Синтаксис спецификации нового типа T', который является вектором фиксированной длины типа T, имеет вид T T'[n];

Здесь T' занимает в информационном потоке n байт, где <n кратно размеру T. Длина вектора не включается в кодированный поток.

В следующем примере Datum определен, как три последовательные байта, которые не интерпретируются протоколом, в то время как Data представляет собой три вектора Datum, состоящие из девяти байт.

opaque Datum[3];	/* три не интерпретируемые байта */
Datum Data[9];	/* 3 последовательных 3-байтовых вектора */

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

T T';

В следующем примере, обязательным является вектор, который должен содержать от 300 до 400 байт непрозрачного типа. Он не должен быть пустым. Поле действительной длины занимает два байта, uint16, достаточных, чтобы представить значение 400 (смотри раздел 4.4). С другой стороны, longer может представить до 800 байт данных, или 400 uint16 элементов, и может быть пустым. Его кодовое представление будет включать два байта поля реальной длины, за которым будет следовать вектор. Длина закодированного вектора должна быть четной, кратной длине одиночного элемента (например: 17-байтовый вектор uint16 будет нелегальным).

opaque mandatory<300..400>;	/* поле длины имеет 2 байта, не может быть пустым */
uint16 longer<0..800>;	/* 0 - 400 16-битовое целое число без знака */

Верификация сертификата

Это сообщение используется для осуществления в явной форме верификации сертификата клиента. Оно посылается вслед за сертификатом клиента, который имеет возможность подписи (т.e. все сертификаты кроме тех, которые содержат фиксированные параметры Diffie-Hellman). При посылке это сообщение следует немедленно за сообщением ключевого обмена клиента.

Структура этого сообщения имеет вид:
struct { Signature signature; } CertificateVerify;

Тип подписи определен в 7.4.3.

CertificateVerify.signature.md5_hash MD5(handshake_messages);
Certificate.signature.sha_hash SHA(handshake_messages);

Здесь handshake_messages относятся ко всем сообщениям диалога, посланным или полученным, начиная с hello клиента, и вплоть до (но исключая) данное сообщение, содержащее поля типа и длины сообщений диалога. Это представляет собой соединение всех структур диалога, как это определено в 7.4.

Виртуальные локальные сети VLAN, Интранет

Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru

Широкое внедрение ИНТРАНЕТ, где группы разбросанных по сети пользователей локальных сетей объединяются друг с другом с помощью виртуальных каналов VLAN (Virtual Local Area Network; ), потребовало разработки новых протоколов. Архитектура VLAN позволяет эффективно разделять трафик, лучше использовать полосу канала, гарантировать успешную совместную работу сетевого оборудования различных производителей и обеспечить высокую степень безопасности. При этом пакеты следуют между портами в пределах локальной сети. В последнее время для задач построения VLAN разработан стандартный протокол IEEE 802.10 (3-ий сетевой уровень). Этот протокол предполагает, что пакеты VLAN имеют свои идентификаторы, которые и используются для их переключения. Протокол может поддерживать работу 500 пользователей и более. Полное название стандарта - IEEE 802.10 Interoperable LAN/MAN Security (MAN - Metropolitan Area Network - региональная или муниципальная сеть). Стандарт принят в конце 1992 года. Количество VLAN в пределах одной сети практически не ограничено. Протокол позволяет шифровать часть заголовка и информационное поле пакетов.

Стандарт ieee 802.10 определяет один протокольный блок данных (PDU), который носит название SDE (Secure Data Exchange) PDU. Заголовок пакета ieee 802.10 имеет внутреннюю и внешнюю секции и показан на рис. 6.2.1.

Рис. 6.2.1 Формат пакета IEEE 802.10

Поле чистый заголовок включает в себя три субполя. MDF (Management Defined Field) является опционным и содержит информацию о способе обработки PDU. Четырехбайтовое субполе said (Security Association Identifier) - идентификатор сетевого объекта (VLAN ID). Субполе 802.10 LSAP (Link Service Access Point) представляет собой код, указывающий принадлежность пакета к протоколу vlan. Предусматривается режим, когда используется только этот заголовок.

Защищенный заголовок копирует себе адрес отправителя из mac-заголовка (MAC - Media Access Control), что повышает надежность.

Поле ICV (Integrity Check Value) - служит для защиты пакета от несанкционированной модификации.
Для управления VLAN используется защищенная управляющая база данных SMIB(security management information base).

Наличие VLAN ID (said) в пакете выделяет его из общего потока и переправляет на опорную магистраль, через которую и осуществляется доставка конечному адресату. Размер поля data определяется физической сетевой средой. Благодаря наличию mac-заголовка VLAN-пакеты обрабатываются как обычные сетевые кадры. По этой причине VLAN может работать в сетях TCP/IP (Appletalk или Decnet менее удобны). В среде типа Netbios работа практически невозможна. Сети ATM прозрачны для VLAN. Протокол VLAN поддерживается корпорацией cisco, 3com и др.. Хотя VLAN ориентирован на локальные сети, он может работать и в WAN, но заметно менее эффективно. В последнее время разработано большое число специальных программных средств сетевой безопасности. Среди них Firewall занимает лидирующее положение.

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

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

Рис. 6.2.2. Схема переключателя (или концентратора) с поддержкой VLAN.

Для формирования VLAN необходимо устройство, где возможно осуществлять управление тем, какие порты могут соединяться. Например, пусть запрограммирована возможность пересылки пакетов между портами 1, 3 и 6, 2 и 5, а также между портами 4, 7 и 8. Тогда пакет из порта 1 никогда не попадет в порт 2, а из порта 8 в порт 6 и т.д. Таким образом, переключатель как бы разделяется на три независимых переключателя, принадлежащих различным виртуальным сетям.Управление матрицей переключения возможно через подключаемый из вне терминал или удаленным образом с использованием протокола SNMP. Если система переключателей, концентраторов (и возможно маршрутизаторов) запрограммирована корректно, возникнет три независимые виртуальные сети.

Данная технология может быть реализована не только в рамках локальной сети. Возможно выделение виртуальной сети в масштабах Интернет. В сущности, идея создания корпоративных сетей в Интернет (ИНТРАНЕТ) является обобщением идей виртуальных сетей на региональные сети.

Такая корпоративная сеть должна иметь один шлюз для входа в Интернет. Такой шлюз может выполнять функции Firewall, решая проблемы безопасности корпоративной сети.

Внутренние коммуникации

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

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

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

Восстановление

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

Возможность обратного дозвона

Некоторые серверы подключения через модем к коммутируемой сети предлагают возможность обратного дозвона (т.e., пользователь звонит серверу и аутентифицируется, затем система рвет соединение и звонит назад пользователю по специфицированному номеру). Обратный дозвон полезен, так как, если кто-то пытается подобрать имя пользователя и пароль, система его отсоединит и свяжется с настоящим пользователем, чей пароль вскрыт; случайные звонки серверу как минимум подозрительны. Это в действительности означает, что пользователь может войти в систему только с одного места (которое прописано в сервере при конфигурации).

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

Все входы в систему должны регистрироваться

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

Если доступна идентификация Calling Line (определитель номера), используйте ее преимущество путем записи номера вызова для каждой попытки авторизации. Знайте, что идентификации Calling Line не стоит слишком доверять (так как атакеры, проникая в коммутатор, переадресуют номера телефонов или осуществляют другие изменения); используйте данные только для информационных целей, а не для аутентификации.

Всемирная паутина (WWW)

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

Многие узлы хотят совмещать FTP-услуги с WWW-сервисом. Но это допустимо только для анонимных ftp-серверов, которые лишь предоставляют информацию (ftp-get). Анонимные ftp put в комбинации с WWW могут быть опасны (например, они могут привести к модификациям информации, предоставляемой вашим узлом). Соображения безопасности для каждого из видов сервиса должны быть разными.

Выбор и защита секретных ключей и PIN

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

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

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

Вычисление ключа

Протокол записей требует алгоритма для генерации ключей, IV и секретных кодов MAC из параметров безопасности, поставляемых протоколом диалога.

Мастерный секретный код (master secret) хэшируется в последовательность байтов, которая присваивается секретным кодам MAC, ключам и IV, требуемых текущим состоянием соединения (смотри приложение A.6). CipherSpecs требует чтобы клиент записал секретный код MAC, чтобы сервер записал секретный код MAC, клиент и сервер записали ключ и IV, которые сформированы из мастерного секретного кода в указанном порядке. Не использованные значения остаются пустыми.

Для генерации ключей вычисляется

key_block = PRF(SecurityParameters.master_secret, "key expansion",
SecurityParameters.server_random + SecurityParameters.client_random);

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

client_write_MAC_secret[SecurityParameters.hash_size]
server_write_MAC_secret[SecurityParameters.hash_size]
client_write_key[SecurityParameters.key_material_length]
>server_write_key[SecurityParameters.key_material_length]
client_write_IV[SecurityParameters.IV_size]
server_write_IV[SecurityParameters.IV_size]

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

Спецификация шифра, которая определена в данном документе, требует 2 x 24 байтовых ключей, 2 x 20 байтовых секретных кодов MAC, и 2 x 8 байтов IV, для 104 байтов материала ключей.

Алгоритмы экспортируемого шифрования (для которого CipherSpec.is_exportable равно 'истинно') требуют дополнительной обработки для получения ключей записи, как это показано ниже:

final_client_write_key =
PRF(SecurityParameters.client_write_key,

	"client write key",
	SecurityParameters.client_random +
	SecurityParameters.server_random);

final_server_write_key =
PRF(SecurityParameters.server_write_key,

	"server write key",
	SecurityParameters.client_random +
	SecurityParameters.server_random);

Алгоритмы экспортируемого шифрования получают свои IV исключительно из случайных кодов сообщений hello:

iv_block = PRF("", "IV block", SecurityParameters.client_random +

SecurityParameters.server_random);

Блок iv_block делится на два инициализационных векторов, как это делалось выше для key_block:

client_write_IV[SecurityParameters.IV_size]
server_write_IV[SecurityParameters.IV_size]

Заметим, что PRF используется в этом случае без секретного кода: это означает, что секретный код имеет длину нуль байт и не вносит ничего в хэширование PRF.

Вычисление мастерного секретного кода

Для всех методов ключевого обмена используется один и тот же алгоритм преобразования pre_master_secret в master_secret. Значение pre_master_secret следует стереть из памяти, как только завершится вычисление master_secret.

master_secret = PRF(pre_master_secret, "master secret",
ClientHello.random + ServerHello.random) [0..47];

Мастерный секретный код всегда имеет длину 48 байт. Длина предмастерного секретного кода варьируется в зависимости от метода ключевого обмена.

Взаимодействие с обществом – пресс-релизы

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

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

(1)	Сохраняйте на низком уровне технические детали инцидента. Детальная информация об инциденте может предоставить достаточно данных для других лиц, которые могут предпринять аналогичные атаки на другие узлы, или даже помешать узлу преследование виновных по завершению инцидента.
(2)	В заявлениях для прессы не допускайте предположений. Предположения о том, кто является виновником инцидента или о мотивах действий весьма вероятно окажутся неверными и могут вызвать неверную интерпретацию событий.
(3)	Сотрудничайте с силами правопорядка, чтобы гарантировать сохранение улик. Если предполагается преследование виновника, следите, чтобы собранные улики не просочились в прессу.
(4)	Старайтесь не давать интервью, до тех пор пока вы не будете к нему готовы.
(5)	Не допускайте, чтобы внимание прессы отвлекало от ликвидации последствий инцидента. Всегда помните, что успешное сокрытие инцидента имеет первостепенное значение.

Walk-up точки подключения к сети

"Walk-up" соединениями, мы называем точки, где пользователи могут удобно подключать свои портативные ЭВМ к вашей сети.

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

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

Если вы предоставляете доступ подключения портативных ЭВМ для посетителей, чтобы они устанавливали соединение с их “домашними” сетями (например, чтобы читать почту и т.д.), рассмотрите использование отдельной субсети, которая имеет соединение с внутренней сетью.

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

Запретить все / разрешить все

Существует две диаметрально противоположные базовые философии, которые могут быть приняты, когда определяется план безопасности. Обе альтернативы являются приемлемыми моделями, и выбор между ними зависит от узла и его требований безопасности.

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

Другая модель, которая называется здесь моделью "разрешить все", реализуется много проще, но менее безопасна, чем модель "запрет всего". Просто включаются все сервисы, обычно на уровне по умолчанию (ЭВМ), и на границе сети допускаются все протоколы на уровне маршрутизатора. Так как уязвимости безопасности оказываются открыты, они перекрываются на уровне ЭВМ или сети.

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

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

Запрос Hello

Сообщение-запрос hello может быть послано сервером в любое время.

Значение этого сообщения:

Запрос Hello является простым уведомлением о том, что клиент должен начать согласование путем посылки сообщения client hello. Это сообщение будет проигнорировано клиентом, если он участвует в сессии согласования. Это сообщение может игнорироваться клиентом, если он не хочет заново согласовывать параметры сессии, или клиент может, если хочет, реагировать уведомлением no_renegotiation. Так как сообщения диалога предназначены для осуществления определенных действий над прикладными данными, ожидается, что согласование начнется до того, как будут получены новые записи от клиента. Если сервер посылает запрос hello, но не получает отклика client hello, он может разорвать соединение с фатальным уведомлением.

После посылки запроса hello, серверы не должны повторять запрос до тех пор, пока диалог согласования не завершится.

Структура этого сообщения:
struct { } HelloRequest;

Это сообщение не должно никогда включаться в хэши сообщений и использоваться в завершающих сообщениях (finished), а также в сообщении верификации сертификатов.

Запрос сертификата

Не анонимный сервер может опционно запросить сертификат от клиента, если это возможно для выбранного шифрового набора. За этим сообщением, если оно послано, непосредственно следует сообщение ключевого обмена сервера (Server Key Exchange) (в противном случае, сообщение сертификата сервера).

Структура этого сообщения:
enum { rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
(255)} ClientCertificateType;
opaque DistinguishedName<1..216-1>;
struct { ClientCertificateType certificate_types<1..28-1>;
DistinguishedName certificate_authorities<3..216-1>;
} CertificateRequest;

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

DistinguishedName получается из [X509]. Считается фатальной ошибкой (оповещение handshake_failure), если анонимный сервер запрашивает идентификацию клиента.

Защищая защиту

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

Защита инфраструктуры

Многие сетевые администраторы готовы идти на большие издержки, чтобы защитить ЭВМ их сети. Немногие администраторы делают что-либо, чтобы защитить сами сети. К этому есть определенные предпосылки. Например, ЭВМ защитить много легче чем сеть. Кроме того, атакеров скорее интересуют конкретные машины, а нанесение ущерба сети в их планы не входит. Тем не менее, существуют причины защиты сетей. Например, атакер может перенаправить сетевой трафик через ЭВМ вне сети, чтобы просмотреть интересующие его данные (например, перехватить пароли). Инфраструктура включает в себя сетевое управление (например, SNMP), услуги (например, DNS, NFS, NTP, WWW) и безопасность (т.e., аутентификация пользователей и ограничения доступа).

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

Защита от активных атак является крайне желательной

В обозримом будущем потребуются достаточно мощные системы, способные противостоять активным атакам. Многие корпоративные сети, базирующиеся на широковещательной технологии, такой как Ethernet, вероятно нуждаются в такой методике. Чтобы защититься от активных атак, или обеспечить конфиденциальность, необходимо использовать протокол с шифрованием сессии, например, Kerberos, возможно использование аутентификационного механизма, который защищает от атаки воспроизведения. В системе Kerberos, пользователи получают коды доступа от сервера Kerberos и используют их для аутентификации, чтобы осуществить доступ к услугам других ЭВМ сети. Вычислительная мощность локальной рабочей станции может быть использована для дешифрования кодов доступа (используя ключ, извлеченный из пароля, введенного пользователем) и запоминания на время пока это требуется. Если протокол безопасности базируется на синхронизации часов, тогда может быть полезен протокол NTPv3, так как он распространяет временные метки для большого числа ЭВМ и является одним из немногих протоколов Интернет, которые содержат механизмы аутентификации [Bishop, Mills92].

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

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

Защита периметра

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

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

Частой формой защиты периметра является передача приложений. Так как эти передачи являются протокольно зависимыми, IP-коннективность ЭВМ в пределах периметра с внешним миром оказывается нарушенной и часть преимуществ Интернет пропадает.

Административное преимущество защиты периметра заключается в том, что число ЭВМ, которые могут быть подвергнуты атаке, достаточно мало. Эти машины могут быть тщательно проверены с точки зрения угроз безопасности. Но достаточно трудно или даже невозможно создать достаточно "герметичную" систему. Безопасность системы защиты периметра достаточно сложна, так как шлюз должен пропускать некоторые типы трафика, например, электронную почту. Другие сетевые услуги, такие как NTP (Network Time Protocol) и FTP могут также оказаться желательными [Mills92, PR85, Bishop]. Более того, шлюзовая система периметра должна быть способна пропускать весь трафик всего домен, заключенного в данный периметр.

Защита поля данных записи

Функции шифрования и MAC преобразуют структуру TLSCompressed в TLSCiphertext. Функции дешифрования выполняют обратную процедуру. MAC записи включает также номер по порядку, чтобы было можно детектировать лишние или повторные сообщения.

Struct	{ ContentType type;
	ProtocolVersion version;
	uint16 length;
	select (CipherSpec.cipher_type) {
	case stream: GenericStreamCipher;
	case block: GenericBlockCipher; } fragment;
	} TLSCiphertext;

type	Поле тип идентично TLSCompressed.type.
Version	Поле версия идентично TLSCompressed.version.
length	Длина (в байтах) последующего TLSCiphertext.fragment. Длина не может превосходить 214 + 2048.
Fragment	Зашифрованная форма TLSCompressed.fragment, с MAC.

Защита против пассивной атаки является необходимой

Отсутствие, по крайней мере, не раскрывающей парольной системы, означает предоставление неограниченного доступа любому, кто имеет физический доступ к сети. Например, всякий кто имеет доступ к кабелю Ethernet<, может имитировать работу любого пользователя данного сегмента сети. Таким образом, когда кто-то имеет пароль, передаваемый по Ethernet открытым текстом, реализуется первичная система безопасности. Когда размер локальной системы невелик (а это справедливо не только для Ethernet, но и для FDDI или Token-Ring LAN), данная система может еще рассматриваться как приемлемая, но это совершенно не так для сетей Интернет [CERT94].

Минимальной защитой против пассивных атак, таких как прослушивание сети, является применение не раскрывающей системы паролей. Такая система может функционировать на пассивном терминале или в качестве коммуникационной программы (напр., Crosstalk или PROCOMM), которая эмулирует пассивный терминал на персональной ЭВМ. Использование более строгой аутентификационной системы защитит против пассивных атак со стороны удаленных систем за счет ограничения использования простых терминалов. Разумно ожидать, что производители коммуникационных программ и не программируемых пользователем терминалов (таких как Х-терминалы) встроят систему не раскрываемых паролей или более строгие аутентификационные системы. Одним из преимуществ Kerberos является то, что при правильном использовании пароль пользователя никогда не покидает пределов рабочей станции. Вместо этого они используются для расшифровки билетов пользователя Kerberos.

Защита сети

Существует несколько проблем, которые актуальны для сетей. Классической проблемой является атака "denial of service" (отказ в обслуживании). В этом случае, сеть попадает в состояние, при котором она не может более передавать данные пользователя. Существует два способа реализации такого состояния: путем атаки маршрутизаторов и с помощью перегрузки сети избыточным трафиком. Заметим, что термин маршрутизатор в этом разделе используется как активное сетевое устройство самого широкого класса, сюда могут относиться сетевые экраны (firewall), прокси-серверы, и т.д.

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

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

Решением большинства этих проблем является предотвращение посылки пакетов модификации маршрутов протоколами маршрутизации (например, RIP-2, OSPF).


Существует три уровня защиты: пароль с открытым текстом, криптографическая контрольная сумма и шифрование. Пароли предоставляют минимальную защиту от атакеров, которые не имеют непосредственного физического доступа к сети. Пароли также предлагают некоторую защиту от некорректного конфигурирования маршрутизаторов. Преимуществом паролей является малая избыточность в отношении полосы и ресурсов CPU. Контрольные суммы защищают от присылки ложных пакетов, даже в случае, когда атакер имеет физический доступ к сети. В сочетании с номером по порядку или другим уникальным идентификатором контрольная сумма может защитить также от атак "откликов", когда атакером или “сошедшим с ума” маршрутизатором повторно присылается старое (но корректное) обновление маршрута. Большая безопасность достигается пересылкой закодированной маршрутной информации. Это мешает атакеру определить топологию сети. Недостатком шифрования является избыточность, связанная с обработкой зашифрованных сообщений.

RIP-2 (RFC 1723) и OSPF (RFC 1583) оба поддерживают пароли с открытым текстом в своей основной спецификации. Кроме того, существует расширения этих базовых протоколов, поддерживающие MD5-шифрование.

К сожалению, не существует приемлемой защиты от атак перегрузки (flooding), или некорректного поведения ЭВМ или маршрутизатора, перегружающих сеть. К счастью, этот тип атак является очевидным и по этой причине хорошо диагностируемым и устраняемым.

Защита улик и журнальные записи активности

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

(1)	Все системные события (audit records)
(2)	Все ваши действия (снабженные временными метками)
(3)	Все внешние переговоры (включая имена лиц, с которыми вы говорите, дата, время и содержание разговора)

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

(1)	Регулярно (например, каждый день) включайте копирование подписанных копий вашего журнала событий (а также среды, которую вы используете для записи системных событий).
(2)	Хранитель (custodian) должен хранить копии этих страниц в безопасном месте (например, в сейфе).
(3)	Когда вы предоставляете информацию для записи, вы должны получить подписанный, датированный доклад от хранителя документов.

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

Защита услуг

Существует много типов услуг и каждая из них имеет свой уровень требований безопасности. Эти требования будут варьироваться в зависимости от назначения услуги. Например, услуга, которая предназначена для применения исключительно внутри узла (например, NFS) может требовать механизмов защиты, отличных от используемых в случае внешних приложений. Может быть достаточно защитить внутренний сервер от внешнего. Однако, WWW-сервер, который должен быть доступен из любой точки Интернет, требует встроенной защиты. То есть, сервис/протокол/сервер должны обеспечивать любую безопасность, необходимую для предотвращения неавторизованного доступа и модификации базы данных Web.

Внутренние услуги (т.e., услуги, используемые в пределах узла) и внешние услуги (т.e., услуги, преднамеренно сделанные доступными для пользователей за пределами узла) будут, вообще говоря, иметь требования безопасности, которые существенно отличаются. Следовательно, разумно ограничить внутренние услуги набором ЭВМ, подключенных к серверу, а внешние услуги должны быть доступны на других серверах. То есть, внутренние и внешние серверы не должны размещаться на одном и том же компьютере. Фактически, многие узлы имеют один набор субсетей (или даже сетей), которые доступны извне, и другой набор, который доступен изнутри. Эти две области соединяются через firewall. Должно уделяться большое внимание для обеспечения корректной работы такого firewall.

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

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

Теперь мы рассмотрим некоторые наиболее популярные услуги: службу имен, службу паролей/ключей, службу аутентификации, электронную почту, WWW, пересылку файлов и NFS. Так как эти услуги наиболее часто используются, они являются объектами атак. Успешная атака на одну из услуг может привести к катастрофе всей системы в целом.

---

---