18.08.2005

Автор Artur Maj

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

Это первая статья в цикле статей, посвященных настройке Apache 2.0 с поддержкой SSL/TLS в целях достижения максимальной безопасности и оптимальной производительности SSL-соединений. В первой части этой статьи будут описаны ключевые аспекты SSL/TLS, а затем показано - как настроить Apache 2.0 с поддержкой этих протоколов. Во второй части будет описан процесс настройки mod_ssl, далее – вопросы адресов с аутентификацией веб-сервера. Кроме того, во второй части мы разберемся, как создать SSL-сертификат веб-сервера. Третья и последняя часть этой серии расскажет об аутентификации клиента, а также о некоторых типичных ошибках настройки, которые допускают системные администраторы, что резко снижает уровень безопасности любого SSL-соединения.

Введение в SSL

Secure Sockets Layer (SSL-протокол защищенных сокетов - прим. пер.) самое известное и достаточно надежное средство соединения по модели клиент-сервер с использованием Интернет. SSL сам по себе довольно простой в плане понимания: он устанавливает алгоритмы шифрования и ключи на обоих сторонах и прокидывает шифрованный туннель, по которому могут передаваться другие протоколы (например HTTP). Опционально в SSL имеется возможность аутентификации обоих сторон через использование сертификатов.

SSL - это многоуровневый протокол и состоит из четырех под-протоколов:

• 
  SSL Handshake Protocol


• 
  SSL Change Cipher Spec Protocol


• 
  SSL Alert Protocol


• 
  SSL Record Layer

Места вышеуказанных протоколов, в соответствии с моделью стека протоколов TCP/IP показаны на Рисунке 1.

Figure 1. Подпротоколы SSL в модели TCP/IP

Как видно на диаграмме, SSL находится на уровне приложений модели TCP/IP. Благодаря этому, SSL может быть развернут почти на любой ОС, поддерживающей TCP/IP, без какой либо правки ядра системы или TCP/IP стека. В результате SSL имеет преимущества перед другими протоколами, такими как IPSec (IP Security Protocol), который требует поддержки модифицированного TCP/IP стека ядром системы. Кроме того, SSL легко пропускают брандмауэры, прокси и NAT (Network Address Translation - Преобразование Сетевых Адресов – прим.пер.) без проблем.

Как работает SSL? На блок-схеме на Рисунке 2 показан упрощенный пошаговый процесс установки SSL соединения между клиентом (обычно веб-браузер) и сервером (чаще всего SSL веб-сервер).

Рисунок 2. Установка SSL соединений, шаг за шагом.

Итак, процесс установки соединения каждого нового SSL соединения начинается с обмена параметрами шифрования, а затем (опционально) происходит аутентификация серверов (через SSL Handshake Protocol). Если «рукопожатие» удалось, и обе стороны согласились на один и тот же алгоритм шифрования и ключи шифрования, данные приложения (обычно HTTP, но может быть и другой) могут быть переданы по зашифрованному каналу (используется SSL Record Layer).

Если рассматривать реальную ситуацию, то процесс, описанный выше, выглядит намного сложнее. Чтобы избежать ненужных «рукопожатий» некоторые параметры шифрования кэшируются. При этом могут быть посланы предупреждающие сообщения. Также могут быть изменены блоки шифра. Как бы то ни было, не зависимо от тонкостей спецификации SSL, в общем виде этот процесс работает примерно так, как показано на Рисунке 2.

SSL, PCT, TLS и WTLS (но не SSH)

Хотя SSL - самый известный и популярный, но не единственный протокол, используемый для защиты веб транзакций. Важно знать, что со времени изобретения SSL v1.0 (релиза которого, кстати говоря, не было) появилось, как минимум, пять протоколов, сыгравших более-менее важную роль в защите доступа к World Wide Web:

SSL v2.0

Релиз выпущен фирмой Netscape Communications в 1994. Основной целью этого протокола было повысить безопасность транзакций через World Wide Web. К несчастью, очень быстро нашлось несколько критических брешей в безопасности этой версии, что сделало его ненадежным для коммерческого использования:

• 
  Слабая конструкция MAC


• 
  Возможность принудительных партий для использования слабого алгоритма шифрования


• 
  Отсутствие защиты «рукопожатий»


• 
  Возможность злоумышленника осуществить атаки принудительного завершения

PCT v1.0

Разработан в 1995 году корпорацией Microsoft. В Privacy Communication Technology (PCT - Технология Конфиденциальной Связи – прим.пер.) v1.0 были усилены некоторые слабые места SSL v2.0, корпорация планировала заменить тем самым SSL. Однако, этот протокол так никогда и не получил популярности из-за появления SSL v3.0.

SSL v3.0

Релиз выпущен в 1996 году компанией Netscape Communications. В SSL v3.0 были решены большинство проблем SSL v2.0 и заимствовано множество возможностей нового для того времени протокола PCT, вследствие чего он быстро стал самым популярным протоколом для защиты соединений через WWW.

TLS v1.0 (также известный как SSL v3.1)

Опубликован IETF (Internet Engineering Task Force - Проблемная Группа Проектирования Интернет – прим.пер.) в 1999 году (RFC 2246). Протокол базируется на SSL v3.0 и PCT и согласован как с методами Netscape, так и с корпорацией Microsoft. Стоит заметить, что если TLS базируется на SSL, он не 100% совместим со своим предшественником. IETF сделала некоторые поправки в безопасности, например использование HMAC вместо MAC, использование другого пересчета основного шифра и ключевого материала, добавлены коды предупреждения, отсутствует поддержка алгоритмов шифрования Fortezza и т.д. В конце концов множество противоречивых изменений привели к тому, что эти протоколы толком не могли взаимодействовать. К счастью, появился мод TLS с откатом до SSL v3.0.

WTLS

«Мобильная и беспроводная» версия протокола TLS, которая использует в качестве носителя UDP протокол. Он разработан и оптимизирован под нижнюю полосу частот и меньшую пропускную способность мобильных устройств с поддержкой WAP (Wireless Application Protocol – Протокол Беспроводных Приложений – прим.пер.). WTLS был представлен с протоколом WAP 1.1 и был опубликован на форуме WAР. Однако, после релиза WAP 2.0, WTLS заменили профилированной версией TLS, которая оказалась намного безопаснее – в основном из-за того, что в этой версии нет необходимости расшифровки и перешифровки трафика на WAP шлюзе.

Почему протокол SSH (Secure Shell) не используется для обеспечения безопасного доступа к World Wide Web? Вот несколько причин: во-первых, с самого начала TLS и SSL были разработаны для защиты веб (HTTP) сессий, тогда как SSH задумывался как альтернатива Telnet и FTP. SSL не выполняет ничего, кроме «рукопожатия» и установки зашифрованного туннеля, а в SSH имеется возможность консольной авторизации, защищенной передачи файлов и поддержка сложной схемы аутентификации (включая пароли, публичные ключи, Kerberos и др.). С другой стороны, SSL/TLS базирован на сертификатах X.509v3 и PKI, что делает распространение и управление аутентификационными мандатами намного проще. Следовательно, эти и другие причины делают SSL/TLS более удобным для защиты WWW доступа и подобных форм соединений, включая SMTP, LDAP и другие – тогда как SSH больше удобен для удаленного управления системой.

В итоге, несмотря на существование нескольких «безопасных» протоколов, только два следует использовать для защиты веб-транзакций (по крайней мере сейчас): TLS v1.0 и SSL v3.0. Оба протокола будут дальше рассмотрены в этих статьях как SSL/TLS. Из-за известных слабостей SSL v2.0, и знаменитой «WAP дыры» в случае с WTLS, использования таких протоколов следует избегать или максимально уменьшать.

Установка Apache с поддержкой SSL/TLS

Первым шагом в установке Apache с поддержкой SSL/TLS будет настройка и установка Apache 2 веб-сервера и создание пользователя и группы с именем "apache". Безопасный способ установки Apache 2.0 уже был рассмотрен на Securing Apache 2.0: Step-by-Step. Единственное отличие в том, что нужно включить mod_ssl и mod_setenvif, которые требуются для совместимости с некоторыми версиями MS Internet Explorer, как описано ниже (изменения выделены жирным):

./configure \ 

--prefix=/usr/local/apache2 \ 

--with-mpm=prefork \ 

--enable-ssl \  

--disable-charset-lite \ 

--disable-include \ 

--disable-env \ 

--enable-setenvif \ 

--disable-status \ 

--disable-autoindex \ 

--disable-asis \ 

--disable-cgi \ 

--disable-negotiation \ 

--disable-imap \ 

--disable-actions \ 

--disable-userdir \ 

--disable-alias \ 

--disable-so

После настройки мы можем установить Apache в конечную директорию:

make

su

umask 022

make install

chown -R root:sys /usr/local/apache2

Настройка SSL/TLS

Перед запуском Apache в первый раз, нам нужно подготовить некоторую начальную конфигурацию и образец веб-контента. Как минимум, мы должны сделать следующее (под root):

1. 
   Создание некоторого веб-контента, который будет обслуживаться через TLS/SSL:

umask 022

mkdir /www

echo " \  

Test works." > /www/index.html

chown -R root:sys /www

2. 
   Удаление конфигурационного файла Apache, созданного по умолчанию (обычно находится в /usr/local/apache2/conf/httpd.conf) и замена его новым, с использованием следующего контента (оптимизировано для обеспечения безопасности и производительности).

# =================================================

# Basic settings

# =================================================

User apache

Group apache

ServerAdmin webmaster@www.seccure.lab     

ServerName www.seccure.lab

UseCanonicalName Off

ServerSignature Off

HostnameLookups Off

ServerTokens Prod

ServerRoot "/usr/local/apache2"

DocumentRoot "/www"

PidFile /usr/local/apache2/logs/httpd.pid

ScoreBoardFile /usr/local/apache2/logs/httpd.scoreboard

    DirectoryIndex index.html

# =================================================

# HTTP and performance settings

# =================================================

Timeout 300

KeepAlive On

MaxKeepAliveRequests 100

KeepAliveTimeout 30

    MinSpareServers 5

    MaxSpareServers 10

    StartServers 5

    MaxClients 150

    MaxRequestsPerChild 0

# =================================================

# Access control

# =================================================

    Options None

    AllowOverride None

    Order deny,allow

    Deny from all

www">

    Order allow,deny

    Allow from all

# =================================================

# MIME encoding

# =================================================

    TypesConfig /usr/local/apache2/conf/mime.types

DefaultType text/plain

    AddEncoding x-compress              .Z

    AddEncoding x-gzip                  .gz .tgz

    AddType application/x-compress      .Z

    AddType application/x-gzip          .gz .tgz

    AddType application/x-tar           .tgz

    AddType application/x-x509-ca-cert  .crt

    AddType application/x-pkcs7-crl     .crl

# =================================================

# Logs

# =================================================

LogLevel warn

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined

LogFormat "%h %l %u %t \"%r\" %>s %b" common

LogFormat "%{Referer}i -> %U" referer

LogFormat "%{User-agent}i" agent

ErrorLog /usr/local/apache2/logs/error_log

CustomLog /usr/local/apache2/logs/access_log combined

CustomLog logs/ssl_request_log \  

"%t %h %{HTTPS}x %{SSL_PROTOCOL}x %{SSL_CIPHER}x \  

%{SSL_CIPHER_USEKEYSIZE}x %{SSL_CLIENT_VERIFY}x \"%r\" %b"

# =================================================

# SSL/TLS settings

# =================================================

Listen 0.0.0.0:443

SSLEngine on

SSLOptions +StrictRequire

    SSLRequireSSL

SSLProtocol -all +TLSv1 +SSLv3

SSLCipherSuite HIGH:MEDIUM:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM

SSLMutex file:/usr/local/apache2/logs/ssl_mutex

SSLRandomSeed startup file:/dev/urandom 1024

SSLRandomSeed connect file:/dev/urandom 1024

SSLSessionCache shm:/usr/local/apache2/logs/ssl_cache_shm

SSLSessionCacheTimeout 600

SSLPassPhraseDialog builtin

SSLCertificateFile /usr/local/apache2/conf/ssl.crt/server.crt

SSLCertificateKeyFile /usr/local/apache2/conf/ssl.key/server.key

SSLVerifyClient none

SSLProxyEngine off

    AddType application/x-x509-ca-cert      .crt

    AddType application/x-pkcs7-crl         .crl

SetEnvIf User-Agent ".*MSIE.*" \  

  nokeepalive ssl-unclean-shutdown \  

  downgrade-1.0 force-response-1.0

Заметьте: читатели должны изменить некоторые значения этого конфигурационного файла, таких как имя веб-сервера, e-mail администратора и т.д.

1. 
   Подготовим структуры директории для приватных ключей веб-сервера, сертификатов и списков аннулированных сертификаций (CRLs - certification revocation lists)

umask 022

mkdir /usr/local/apache2/conf/ssl.key

mkdir /usr/local/apache2/conf/ssl.crt

mkdir /usr/local/apache2/conf/ssl.crl

2. 
   Создаем самоподписанный серверный сертификат (следует использовать только для тестов – ваш настоящий сертификат должен быть от достоверного СА – такого как Verisign):

openssl req \ 

-new \ 

-x509 \ 

-days 30 \ 

-keyout /usr/local/apache2/conf/ssl.key/server.key \ 

-out /usr/local/apache2/conf/ssl.crt/server.crt \ 

-subj '/CN=Test-Only Certificate'

Проверяем установку

Теперь можно запустить Apache с поддержкой SSL/TLS:

/usr/local/apache2/bin/apachectl startssl

Apache/2.0.52 mod_ssl/2.0.52 (Pass Phrase Dialog)

Some of your private key files are encrypted for security reasons.

In order to read them you have to provide us with the pass phrases.

Server 127.0.0.1:443 (RSA)

Enter pass phrase:*************

Ok: Pass Phrase Dialog successful.

После запуска сервера мы можем попробовать соединиться к нему, направив веб-браузер на URL: https://имя сервера (в нашем случае, https://www.seccure.lab)

Через некоторое время мы должны увидеть предупреждающее сообщение о том, что в ходе проверки аутентифифкации веб-сервера возникла проблема. На Рисунке 3 показан пример такого сообщения в MS Internet Explorer 6.0.

Рисунок 3. Примерное сообщение о сертификате в IE 6.

Все работает правильно. Следует принять это сообщение из-за двух причин:

• 
  Веб-браузер не знает Certificate Authority, использовавшийся при создании данного сертификата (и не может знать, ведь мы используем самоподписанный сертификат)


• 
  Атрибут CN (Common Name – Общее Имя) сертификата не совпадает с именем веб-сайта – на данный момент «Test-Only Certificate» (Только для Тестирования), а должен быть полностью определенное доменное имя веб сервера (например www.seccure.lab)

После нажатия кнопки «Yes», мы увидим следующее веб содержимое:

Рисунок 4. Пример работы SSL веб страницы.

Внизу окна браузера появился желтый замок, означающий что SSL соединение было успешно установлено. Значение "128-bit" говорит о том, что симметричный ключ, используемый для шифрования равен 128 бит, что довольно таки неплохо (по крайней мере сейчас) для защиты трафика от неавторизованного доступа.

Выполнив двойной щелчок по значку замка, мы увидим свойства сертификата:

Рисунок 5. Подробнее о нашем самоподписанном сертификате.

Диагностика неисправностей

Если по каким-то причинам мы не можем получить доступ к веб-сайту, можно воспользоваться очень полезной утилитой "s_client" от библиотеки OpenSSL. Пример использования этой утилиты:

/usr/bin/openssl s_client -connect localhost:443

CONNECTED(00000003)

depth=0 /CN=Test-Only Certificate

verify error:num=18:self signed certificate

verify return:1

depth=0 /CN=Test-Only Certificate

verify return:1

---

Certificate chain

0 s:/CN=Test-Only Certificate

i:/CN=Test-Only Certificate

---

Server certificate

-----BEGIN CERTIFICATE-----

MIICLzCCAZigAwIBAgIBADANBgkqhkiG9w0BAQQFADAgMR4wHAYDVQQDExVUZXN0

LU9ubHkgQ2VydGlmaWNhdGUwHhcNMDQxMTIyMTg0ODUxWhcNMDQxMjIyMTg0ODUx

WjAgMR4wHAYDVQQDExVUZXN0LU9ubHkgQ2VydGlmaWNhdGUwgZ8wDQYJKoZIhvcN

AQEBBQADgY0AMIGJAoGBAMEttnihJ7JpksdToPi5ZVGcssUbHn/G+4G43OiLhP0i

KvYuqNxBkSqqM1AanR0BFVEtVCSuq8KS9LLRdQLJ/B1UTMOGz1Pb14WGsVJS+38D

LdLEFaCyfkjNKnUgeKMyzsdhZ52pF9febB+d8cLmvXFve28sTIxLCUK7l4rjT3Xl

AgMBAAGjeTB3MB0GA1UdDgQWBBQ50isUEV6uFPZ0L4RbRm41+i1CpTBIBgNVHSME

QTA/gBQ50isUEV6uFPZ0L4RbRm41+i1CpaEkpCIwIDEeMBwGA1UEAxMVVGVzdC1P

bmx5IENlcnRpZmljYXRlggEAMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEEBQAD

gYEAThyofbK3hg8AJXbAUD6w6+mz6dwsBmcTWLvYtLQUh86B0zWnVxzSLDmwgdUB

NxfJ7yfo0PkqNnjHfvnb5W07GcfGgLx5/U3iUROObYlwKlr6tQzMoysNQ/YtN3pp

52sGsqaOOWpYlAGOaM8j57Nv/eXogQnDRT0txXqoVEbunmM=

-----END CERTIFICATE-----

subject=/CN=Test-Only Certificate

issuer=/CN=Test-Only Certificate

---

No client certificate CA names sent

---

SSL handshake has read 1143 bytes and written 362 bytes

---

New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA

Server public key is 1024 bit

SSL-Session:

Protocol : SSLv3

Cipher : DHE-RSA-AES256-SHA

Session-ID: 56EA68A5750511917CC42A1B134A8F218C27C9C0241C35C53977A2A8BBB9986A

Session-ID-ctx:

Master-Key: 303B60D625B020280F5F346AB00F8A61A7C4BEA707DFA0ED8D2F52371F8C4F087FB6EFFC02CE3B48F912D2C8929DB5BE

Key-Arg : None

Start Time: 1101164382

Timeout : 300 (sec)

Verify return code: 18 (self signed certificate)

---

GET / HTTP/1.0

HTTP/1.1 200 OK

Date: Mon, 22 Nov 2004 22:59:56 GMT

Server: Apache

Last-Modified: Mon, 22 Nov 2004 17:24:56 GMT

ETag: "5c911-46-229c0a00"

Accept-Ranges: bytes

Content-Length: 70

Connection: close

Content-Type: text/html

Test works.

closed

Утилита s_client имеет много полезных опций, например включение/выключение отдельного протокола (-ssl2, -ssl3, -tls1), выбор отдельного алгоритма шифрования (-cipher), запуск режима отладки (-debug), просмотр статистик и сообщений SSL/TLS (-state, -msg), и некоторые другие, которые смогут помочь найти причину неполадки.

Если s_client ничем не помог, следует сменить значение LogLevel (в httpd.conf) на "debug" и перезапустить Apache и проверить его логи (/usr/local/apache2/logs/) для дополнительной информации.

Еще можно попробовать Ethereal или ssldump. Благодаря этим утилитам, мы можем пассивно наблюдать SSL сообщения «рукопожатий» и пытаться найти причину неисправности. Вот скриншот использования Ethereal:

Figure 6. Просмотр SSL «рукопожатия» в Ethereal.

Заключение к первой части

Итак, мы имеем безопасный Apache 2 сервер в состоянии онлайн и пример SSL-сертификата, на чем и заканчивается первая часть. В следующей части вы познакомитесь с рекомендуемыми настройками безопасности и функций для mod_ssl и процессом создания нормального сертификата.

We strongly recommend that all users upgrade to Microsoft Internet Information Services (IIS) version 7.0 running on Microsoft Windows Server 2008. IIS 7.0 significantly increases Web infrastructure security. For more information about IIS security-related topics, visit the following Microsoft Web site:

http://www.microsoft.com/technet/security/prodtech/IIS.mspx

For more information about IIS 7.0, visit the following Microsoft Web site:

http://www.iis.net/default.aspx?tabid=1

Summary

---

This article describes the server authentication process during the Secure Sockets Layer (SSL) handshake.

More Information

---

During the SSL handshake, the server sends the client a certificate to authenticate itself. The client uses the certificate to authenticate the identity the certificate claims to represent.


An SSL-enabled client goes through these steps to authenticate a server's identity:

1. Is today's date within the validity period? The client checks the server certificate's validity period. If the current date and time are outside of that range, the authentication process does not go any further. If the current date and time are within the certificate's validity period, the client goes on to step 2.
    
2. Is the issuing Certificate Authority (CA) a trusted CA? Each SSL-enabled client maintains a list of trusted CA certificates. This list determines which server certificates the client will accept. If the distinguished name (DN) of the issuing CA matches the DN of a CA on the client's list of trusted CAs, the answer to this question is yes, and the client goes on to step 3. If the issuing CA is not on the list, the server is not authenticated unless the client can verify a certificate chain ending in a CA that is on the list.
    
3. Does the issuing CA's public key validate the issuer's digital signature? The client uses the public key from the CA's certificate (which it found in its list of trusted CAs in step 2) to validate the CA's digital signature on the server certificate that is being presented. If the information in the server certificate has changed since it was signed by the CA, or if the CA certificate's public key doesn't correspond to the private key that was used by the CA to sign the server certificate, the client does not authenticate the server's identity. If the CA's digital signature can be validated, the client treats the server's certificate as a valid "letter of introduction" from that CA and proceeds. At this point, the client has determined that the server certificate is valid. It is the client's responsibility to take step 4 before it takes step 5.
    
4. Does the domain name in the server's certificate match the domain name of the server itself? This step confirms that the server is actually located at the same network address that is specified by the domain name in the server certificate. Although step 4 is not technically part of the SSL protocol, it provides the only protection against a form of security attack known as a "Man-in-the-Middle Attack." Clients must perform this step and must refuse to authenticate the server or establish a connection if the domain names do not match. If the server's actual domain name matches the domain name in the server certificate, the client goes on to step 5.
    
5. The server is authenticated. The client proceeds with the SSL handshake. If the client does not get to step 5 for any reason, the server that is identified by the certificate cannot be authenticated, and the user is warned of the problem and informed that an encrypted and authenticated connection cannot be established.

Мы хорошо знаем Solarwinds и давно с ним работаем, многим также известны их продукты для сетевого (и не только) мониторинга. Но не так широко известно, что они дают скачивать со своего сайта добрых четыре десятка бесплатных утилит, которые помогут контролировать сетевые устройства, управлять инфраструктурой, базами данных и даже обрабатывать инциденты. Фактически, этот софт — отдельные фрагменты их платных продуктов. Все утилиты 100% бесплатные, не триальные версии. Под катом ссылки на описание и скачивание.

В этом обзоре утилиты для:

• управления сетевой инфраструктурой;
• управления ИТ-инфраструктурой;
• управления ИТ-безопасностью;
• управления базами данных;
• организации службы Help Desk.

Управление сетевой инфраструктурой

ipMonitor Free Edition

Простой инструмент. В интерфейсе задаётся диапазон адресов, он их опрашивает и выдаёт доступные для постановки на удалённый мониторинг узлы. Из возможных инструментов мониторинга: ping, WMI, SSH. На серверах может выполнять стандартные проверки типа CPU, Memory, Disk. Это бесплатная версия старшего брата ipMonitor (без free) и поддерживает до 50 узлов. Для небольшого офиса или тестовых задач вполне себе ничего. Есть короткое видео с описанием.

Flow Tool Bundle

Репликация, тестирование и конфигурирование устройств для отправки flow-трафика. Инструмент состоит из трёх частей: репликатора, генератора и конфигуратора. Репликатор умеет принимать и пересылать netflow трафик на один или несколько приёмников. Генератор — генерирует netflow для тестирования, проверки настроек сетевых экранов и других целей. Конфигуратор в автоматическом режиме настраивает сетевые устройства для отправки netflow на целевое устройство. Есть короткое видео с описанием.

Traceroute NG

Утилита эта — надстройка над системной tracert. Выполняет анализ сетевых маршрутов, умеет запускать пакеты по протоколам TCP и ICMP. Есть короткое видео с описанием.

Port Scanner

Генерирует список открытых, закрытых и зафильтрованных портов каждого сканируемого IP адреса. Умеет сканировать по протоколам TCP и UDP, а после сканирования можно выгрузить все собранные данные в файл. Работает в том числе и через командную строку.
Есть короткое видео с описанием.

Network Device Monitor

Мониторинг сетевых устройств. Утилита имеет в комплекте много разных шаблонов для мониторинга по SNMP, можно настраивать отчёты и оповещения. Но есть ограничение: поддерживается мониторинг только одного устройства. Короткое видео с описанием.

GNS3 Network Emulator

Эмулятор сетевого окружения. Утилита работает на Windows, Mac и Linux. Поддерживаются более 20 вендоров сетевого оборудования. Можно эмулировать различные сетевые топологии и смотреть как это всё будет работать. Есть видео с описанием.

Response Time Viewer for Wireshark

Надстройка над Wireshark для удобства анализа пакетов по времени отклика. Определяет трафик примерно 1200 приложений. Работает как калькулятор для времени ответа приложения. Есть видео с описанием.

Network Analyzer & Bandwidth Monitoring Bundle

Утилита предназначена для мониторинга NetFlow, J-Flow и sFlow трафика. В интерфейсе есть представления в виде различных срезов: по взаимодействию между устройствами, по приложениям, по доменам и конечным устройствам. Кроме этого, есть возможность записи данных до 60 минут.

TFTP Server

TFTP сервер с графическим интерфейсом. Работает на Windows в виде сервиса. Есть видео с описанием.

IP Address Tracker

Сканирование, фиксация изменений, выявление конфликтов IP-адресов. Это младший брат старшего IP Address Manager — может управлять до 254 адресами в отличие от 2 млн. в платном решении.

Real-Time Bandwidth Monitor

Мониторинг пропускной способности сетевых интерфейсов и визуализация метрик. Также младшее решение для Network Performance Monitor (NPM).

Call Detail Record Tracker

Поиск, фильтрация и сортировка логов CCM CDR.

IP SLA Monitor

Сбор данных IP SLA с устройств Cisco и их визуализация.

Advanced Subnet Calculator

IP-калькулятор для проектирования адресного пространства.

Kiwi Syslog Server Free Edition

Анализ, приём и архивация syslog и SNMP. Есть видео с описанием.

FTP Voyager FTP Client for Windows

Продвинутый FTP клиент для Windows. Поддерживает протоколы FTP, FTPS, и SFTP. Через этот клиент можно выполнять передачу файлов по расписанию.

SFTP/SCP Server

Утилита работает в виде Windows-сервиса и поддерживает одновременную передачу файлов на несколько устройств.

Управление ИТ-инфраструктурой

Cost Calculator for Azure

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

Event Log Forwarder for Windows

Упаковывает события из журнала Windows и отправляет их в виде syslog куда захотите. Есть гибкая фильтрация. Какие именно события из журналов Windows нужно контролировать — мы писали в прошлой статье.

Solar-PuTTY

Продвинутый Putty. Имеет многовкладочный интерфейс и удобный поиск по сохранённым сессиям. Есть видео с описанием.

VM Monitor

Мониторинг производительности VMware и Hyper-V. В интерфейсе отображаются основные метрики производительности и статус виртуальных машин.

Server Health Monitor

Предназначен для мониторинга физических серверов. Из коробки умеет работать с Dell PowerEdge, HP ProLiant, серверами IBM eServer xSeries и гипервизорами VMware ESX/ESXi. Поддерживает протоколы взаимодействия SNMP, WMI и CIM.

Storage Performance Monitor

Мониторинг массивов данных Dell EMC, NetApp, IBM, Pure Storage. Есть видео с описанием.

Exchange Monitor

Мониторинг ключевых сервисов Exchange. Есть видео с описанием.

Remote Execution Enabler for PowerShell

Утилита для автоматической настройки локального и удалённого сервиса WinRM.

Admin Bundle for Active Directory

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



Для выявления атаки на самой ранней стадии в ОС Windows есть три полезных событийных источника: журнал событий безопасности, журнал системного мониторинга и журналы Power Shell.

Журнал событий безопасности (Security Log)

Это главное место хранения системных логов безопасности. Сюда складываются события входа/выхода пользователей, доступа к объектам, изменения политик и других активностей, связанных с безопасностью. Разумеется, если настроена соответствующая политика.



Перебор пользователей и групп (события 4798 и 4799). Вредоносное ПО в самом начале атаки часто перебирает локальные учетные записи пользователей и локальные группы на рабочей станции, чтобы найти учетные данные для своих тёмных делишек. Эти события помогут обнаружить вредоносный код раньше, чем он двинется дальше и, используя собранные данные, распространится на другие системы.

Создание локальной учётной записи и изменения в локальных группах (события 4720, 4722–4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 и 5377). Атака может также начинаться, например, с добавления нового пользователя в группу локальных администраторов.

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

Попытка входа с заданной учётной записью (событие 4648). Такое бывает, когда процесс выполняется в режиме “Запуск от имени” (run as). В нормальном режиме работы систем такого не должно быть, поэтому такие события должны находиться под контролем.

Блокировка/разблокировка рабочей станции (события 4800-4803). К категории подозрительных событий можно отнести любые действия, которые происходили на заблокированной рабочей станции.

Изменения конфигурации файрволла (события 4944-4958). Очевидно, что при установке нового ПО настройки конфигурации файрволла могут меняться, что вызовет ложные срабатывания. Контролировать такие изменения в большинстве случаев нет необходимости, но знать о них точно лишним не будет.

Подключение устройств Plug’n’play (событие 6416 и только для WIndows 10). За этим важно следить, если пользователи обычно не подключают новые устройства к рабочей станции, а тут вдруг раз — и подключили.

Windows включает в себя 9 категорий аудита и 50 субкатегорий для тонкой настройки. Минимальный набор субкатегорий, который стоит включить в настройках:

Logon/Logoff

• Logon;
• Logoff;
• Account Lockout;
• Other Logon/Logoff Events.

Account Management

• User Account Management;
• Security Group Management.

Policy Change

• Audit Policy Change;
• Authentication Policy Change;
• Authorization Policy Change.

Системный монитор (Sysmon)

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



Эти же события можно в принципе найти в журнале безопасности (включив нужную политику аудита), но Sysmon даёт больше подробностей. Какие события можно забирать из Sysmon?

Создание процесса (ID события 1). Системный журнал событий безопасности тоже может сказать, когда запустился какой-нибудь *.exe и даже покажет его имя и путь запуска. Но в отличие от Sysmon не сможет показать хэш приложения. Злонамеренное ПО может называться даже безобидным notepad.exe, но именно хэш выведет его на чистую воду.

Сетевые подключения (ID события 3). Очевидно, что сетевых подключений много, и за всеми не уследить. Но важно учитывать, что Sysmon в отличие от того же Security Log умеет привязать сетевое подключение к полям ProcessID и ProcessGUID, показывает порт и IP-адреса источника и приёмника.

Изменения в системном реестре (ID события 12-14). Самый простой способ добавить себя в автозапуск — прописаться в реестре. Security Log это умеет, но Sysmon показывает, кто внёс изменения, когда, откуда, process ID и предыдущее значение ключа.

Создание файла (ID события 11). Sysmon, в отличие от Security Log, покажет не только расположение файла, но и его имя. Понятно, что за всем не уследишь, но можно же проводить аудит определённых директорий.

А теперь то, чего в политиках Security Log нет, но есть в Sysmon:

Изменение времени создания файла (ID события 2). Некоторое вредоносное ПО может подменять дату создания файла для его скрытия из отчётов с недавно созданными файлами.

Загрузка драйверов и динамических библиотек (ID событий 6-7). Отслеживание загрузки в память DLL и драйверов устройств, проверка цифровой подписи и её валидности.

Создание потока в выполняющемся процессе (ID события 8). Один из видов атаки, за которым тоже нужно следить.

События RawAccessRead (ID события 9). Операции чтения с диска при помощи “\\.\”. В абсолютном большинстве случаев такая активность должна считаться ненормальной.

Создание именованного файлового потока (ID события 15). Событие регистрируется, когда создается именованный файловый поток, который генерирует события с хэшем содержимого файла.

Создание named pipe и подключения (ID события 17-18). Отслеживание вредоносного кода, который коммуницирует с другими компонентами через named pipe.

Активность по WMI (ID события 19). Регистрация событий, которые генерируются при обращении к системе по протоколу WMI.

Для защиты самого Sysmon нужно отслеживать события с ID 4 (остановка и запуск Sysmon) и ID 16 (изменение конфигурации Sysmon).

Журналы Power Shell

Power Shell — мощный инструмент управления Windows-инфраструктурой, поэтому велики шансы, что атакующий выберет именно его. Для получения данных о событиях Power Shell можно использовать два источника: Windows PowerShell log и Microsoft-WindowsPowerShell / Operational log.

Windows PowerShell log

Загружен поставщик данных (ID события 600). Поставщики PowerShell — это программы, которые служат источником данных для PowerShell для просмотра и управления ими. Например, встроенными поставщиками могут быть переменные среды Windows или системный реестр. За появлением новых поставщиков нужно следить, чтобы вовремя выявить злонамеренную активность. Например, если видите, что среди поставщиков появился WSMan, значит был начат удаленный сеанс PowerShell.

Microsoft-WindowsPowerShell / Operational log (или MicrosoftWindows-PowerShellCore / Operational в PowerShell 6)

Журналирование модулей (ID события 4103). В событиях хранится информация о каждой выполненной команде и параметрах, с которыми она вызывалась.

Журналирование блокировки скриптов (ID события 4104). Журналирование блокировки скриптов показывает каждый выполненный блок кода PowerShell. Даже если злоумышленник попытается скрыть команду, этот тип события покажет фактически выполненную команду PowerShell. Ещё в этом типе события могут фиксироваться некоторые выполняемые низкоуровневые вызовы API, эти события обычно записывается как Verbose, но если подозрительная команда или сценарий используются в блоке кода, он будет зарегистрирован как c критичностью Warning.

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

Расскажите в комментариях, какие собираете логи для аудита информационной безопасности и какие инструменты для этого используете. Одно из наших направлений — решения для аудита событий информационной безопасности. Для решения задачи сбора и анализа логов можем предложить присмотреться к Quest InTrust, который умеет сжимать хранящиеся данные с коэффициентом 20:1, а один его установленный экземпляр способен обрабатывать до 60000 событий в секунду из 10000 источников.

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


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


На уровне подсознания мы прекрасно понимаем, что любая атака происходит не на пустом месте, она требует подготовки и ряда иных действий для того, чтобы быть успешной. Вот Kill Chain и описывает эти шаги, начинающиеся не с проникновения через периметр корпоративной или ведомственной сети, а с сбора разведывательной информации. По сути Lockheed Martin аккумулировала имеющиеся ранее исследования и модели МинОбороны США, ВВС США и ряда других организаций и предложила 7 стадий, которые проходит злоумышленник для успешной реализации своей деятельности:

1. Разведка. Исследование, идентификация и выбор свой жертвы, часто используя публичные источники данных - соцсети, сайты конференций, списки рассылки и т.п.
2. Вооружение. Оснащение вредоносным содержанием файла (например, PDF или MS Office) или иного контента, который должен быть прочтен/открыт жертвой. 
3. Доставка. Донесение вредоносного контента до жертвы, чаще всего используя для этого e-mail, web-сайты или USB-флешки.
4. Заражение. Запуск вредоносного кода, используя имеющиеся на целевом компьютере уязвимости, с последующим его заражением.
5. Инсталляция. Открытие удаленного доступа для незаметного управления и обновления вредоносного кода. В последнее время для этого чаще всего используется протокол DNS.
6. Получение управления. Получение обновлений с новым функционалом извне, а также управляющих команд для достижения поставленных целей.
7. Выполнение действий. Сбор и кража данных, шифрование файлов, перехват управления, подмена данных и другие задачи, которые могут стоять перед нарушителем.

Понятно, что злоумышленник не обязательно должен соблюдать указанные 7 шагов, но в этом случае эффективность его деятельности снижается. Более того, 7 шагов часто модифицируются в 6 или 8. Например, в картинке ниже (скачана из Интернет) этап утечки данных выделен отдельно. А на последней картинке восьмой этап описывает уничтожение следов после выполнения своей задачи злоумышленником. Но как бы то ни было, первые шаги, описанные несколько лет назад Lockheed Martin, остаются неизменными.


Если подытожить, то Kill Chain представляет собой систематический процесс достижения нарушителем цели для получения желаемого эффекта. С этой же целью (систематизация) это понятие и стоит включить в арсенал служб ИБ (если этого еще не сделано). Использовать это понятие можно при моделировании угроз, а с практической точки зрения нередко когда Kill Chain используется при оценке эффективности Security Operation Center (SOC). Распределение обнаруженных и нейтрализованных атак по их стадии - это одна из метрик SOC. Логично предположить, что чем раьнше мы обнаруживаем направленные против нас действия злоумышленников, тем эффективнее работает наша система защиты.