Мониторинг событий информационной безопасности с помощью ZABBIX

    image

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

    Что же позволяет Zabbix для решения нашей задачи? Примерно следующее:
    • Максимальная автоматизация процессов инвентаризации ресурсов, управления уязвимостями, контроля соответствия политикам безопасности и изменений.
    • Постоянная защита корпоративных ресурсов с помощью автоматического мониторинга информационной безопасности.
    • Возможность получать максимально достоверную картину защищенности сети.
    • Анализ широкого спектра сложных систем: сетевое оборудование, такое как Cisco, Juniper, платформы Windows, Linux, Unix, СУБД MSQL, Oracle, MySQL и т.д., сетевые приложения и веб-службы.
    • Минимизация затрат на аудит и контроль защищенности.

    В статье я не буду рассматривать всё выше перечисленное, затронем только наиболее распространённые и простые вопросы.

    Подготовка


    Итак, для начала я установил сервер мониторинга Zabbix. В качестве платформы мы будем использовать ОС FreeBSD. Думаю, что рассказывать в деталях о процессе установки и настройки нет необходимости, довольно подробная документация на русском языке есть на сайте разработчика, начиная от процесса установки до описания всех возможностей системы.
    Мы будем считать что сервер установлен, настроен, а так же настроен web-frontend для работы с ним. На момент написания статьи система работает под управлением ОС FreeBSD 9.1, Zabbix 2.2.1.

    Мониторинг событий безопасности MS Windows Server


    С помощью системы мониторинга Zabbix можно собирать любую имеющуюся информацию из системных журналов Windows с произвольной степенью детализации. Это означает, что если Windows записывает какое-либо событие в журнал, Zabbix «видит» его, например по Event ID, текстовой, либо бинарной маске. Кроме того, используя Zabbix, мы можем видеть и собирать колоссальное количество интересных для мониторинга безопасности событий, например: запущенные процессы, открытые соединения, загруженные в ядро драйверы, используемые dll, залогиненных через консоль или удалённый доступ пользователей и многое другое.

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

    Устанавливая решение по мониторингу событий ИБ в ИТ инфраструктуре следует учитывать необходимость выбора баланса между желанием отслеживать всё подряд, и возможностями по обработке огромного количества информации по событиям ИБ. Здесь Zabbix открывает большие возможности для выбора. Ключевые модули Zabbix написаны на C/C++, скорость записи из сети и обработки отслеживаемых событий составляет 10 тысяч новых значений в секунду на более менее обычном сервере с правильно настроенной СУБД.

    Всё это даёт нам возможность отслеживать наиболее важные события безопасности на наблюдаемом узле сети под управлением ОС Windows.

    Итак, для начала рассмотрим таблицу с Event ID, которые, на мой взгляд, очевидно, можно использовать для мониторинга событий ИБ:

    События ИБ MS Windows Server Security Log

    Описание EventID 2008 Server 2003 Server
    Очистка журнала аудита 1102 517
    Вход с учётной записью выполнен успешно 4624 528, 540
    Учётной записи не удалось выполнить вход в систему 4625 529-535, 539
    Создана учётная запись пользователя 4720 624
    Попытка сбросить пароль учётной записи 4724 628
    Отключена учётная запись пользователя 4725 629
    Удалена учётная запись пользователя 4726 630
    Создана защищённая локальная группа безопасности 4731 635
    Добавлен участник в защищённую локальную группу 4732 636
    Удален участник из защищённой локальной группы 4733 637
    Удалена защищённая локальная группа безопасности 4734 638
    Изменена защищённая локальная группа безопасности 4735 639
    Изменена учётная запись пользователя 4738 642
    Заблокирована учётная запись пользователя 4740 644
    Имя учётной записи было изменено 4781 685

    Я уделяю внимание локальным группам безопасности, но в более сложных схемах AD необходимо учитывать так же общие и глобальные группы.
    Дабы не дублировать информацию, подробнее о критически важных событиях можно почитать в статье:
    http://habrahabr.ru/company/netwrix/blog/148501/

    Способы мониторинга событий ИБ MS Windows Server

    Рассмотрим практическое применение данной задачи.
    Для сбора данных необходимо создать новый элемент данных:

    Ключ: eventlog[Security,,,,1102|4624|4625|4720|4724|4725|4726|4731|4732|4733|4734|4735|4738|4781]
    Тип элемента данных: Zabbix агент (активный)
    Тип информации: Журнал (лог)
    

    image


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

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

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

    Вот одно из выражений триггера:

    {Template Windows - Eventlog 2008:eventlog[Security,,,,1102|4624|4625|4720|4724|4725|4726|4731|4732|4733|4734|4735|4738|4781].logeventid(4624)}=1&{Template Windows - Eventlog 2008:eventlog[Security,,,,1102|4624|4625|4720|4724|4725|4726|4731|4732|4733|4734|4735|4738|4781].nodata(5m)}=0
    

    image


    Данное выражение позволит отображать на Dashboard информацию о том что «Вход с учётной записью выполнен успешно», что соответствует Event ID 4624 для MS Windows Server 2008. Событие исчезнет спустя 5 минут, если в течение этого времени не был произведен повторный вход.

    Если же необходимо отслеживать определенного пользователя, например “Администратор”, можно добавить к выражению триггера проверку по regexp:

    &{Template Windows - Eventlog 2008:eventlog[Security,,,,1102|4624|4625|4720|4724|4725|4726|4731|4732|4733|4734|4735|4738|4781,,skip].regexp(Администратор)}=1
    

    Тогда триггер сработает только в том случае если будет осуществлён вход в систему именно под учетной записью с именем “Администратор”.

    P.S.

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

    Таким образом тонны сообщений, генерируемых системами Windows будет проверять Zabbix, а не наши глаза. Нам остаётся только смотреть на панель Zabbix Dashboard.
    Дополнительно, у меня настроена отправка уведомлений на e-mail. Это позволяет оперативно реагировать на события, и не пропустить события произошедшие например в нерабочее время.

    Мониторинг событий безопасности Unix систем


    Система мониторинга Zabbix так же позволяет собирать информацию из лог-файлов ОС семейства Unix.

    События ИБ в Unix системах, подходящие для всех

    Такими проблемами безопасности систем семейства Unix являются всё те же попытки подбора паролей к учётным записям, а так же поиск уязвимостей в средствах аутентификации, например, таких как SSH, FTP и прочих.

    Некоторые критически важные события в Unix системах

    Исходя из вышеуказанного следует, что нам необходимо отслеживать действия, связанные с добавлением, изменением и удалением учётных записей пользователей в системе.
    Так же немаловажным фактом будет отслеживание попыток входа в систему. Изменения ключевых файлов типа sudoers, passwd, etc/rc.conf, содержимое каталогов /usr/local/etc/rc.d наличие запущенных процессов и т.п.

    Способы мониторинга ИБ в Unix системах

    Рассмотрим следующий пример. Нужно отслеживать входы в систему, неудачные попытки входа, попытки подбора паролей в системе FreeBSD по протоколу SSH.

    Вся информация об этом, содержится в лог-файле /var/log/auth.log.
    По умолчанию права на данный файл — 600, и его можно просматривать только с привилегиями root. Придется немного пожертвовать локальной политикой безопасности, и разрешить читать данный файл группе пользователей zabbix:
    Меняем права на файл:

    chgrp zabbix /var/log/auth.log
    chmod 640 /var/log/auth.log
    

    Нам понадобится новый элемент данных со следующим ключом:
    log[/var/log/auth.log,sshd,,,skip]
    

    image


    Все строки в файле /var/log/auth.log содержащие слово ”sshd” будут переданы агентом на сервер мониторинга.

    Далее можно настроить триггер со следующим выражением:

    {Template FreeBSD - SSH:log[/var/log/auth.log,sshd,,,skip].regexp(error:)}|{Template FreeBSD - SSH:log[/var/log/auth.log,sshd,,,skip].regexp(Wrong passwordr:)}&{Template FreeBSD - SSH:log[/var/log/auth.log,sshd,,,skip].nodata(3m)}=0
    

    image


    Это выражение определяется как проблема, когда в лог-файле появляются записи, отобранные по регулярному выражению “error:”. Открыв историю полученных данных, мы увидим ошибки, которые возникали при авторизации по протоколу SSH.

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

    image


    Рассмотрим ещё один пример мониторинга безопасности в ОС FreeBSD:
    С помощью агента Zabbix мы можем осуществлять проверку контрольной суммы файла /etc/passwd.
    Ключ в данном случае будет следующий:

    vfs.file.cksum[/etc/passwd]
    

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

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

    UserParameter=system.users.list, /bin/cat /etc/passwd | grep -v "#" | awk -F\: '{print $$1}'
    

    И, например, настроить триггер на изменение в получаемом списке.

    Или же можно использовать такой простой параметр:

    UserParameter=system.users.online, /usr/bin/users
    

    Так мы увидим на Dashboard, кто на данный момент находится в системе:

    image


    Мониторинг событий ИБ на сетевых устройствах


    С помощью Zabbix можно так же очень эффективно отслеживать события ИБ на сетевых устройствах Cisco и Juniper, используя протокол SNMP. Передача данных с устройств осуществляется с помощью так называемых трапов (SNMP Trap).

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

    Способы мониторинга

    Рассмотрим опять же пример с авторизацией:
    В качестве стенда я буду использовать эмулятор GNS3 с маршрутизатором Cisco 3745. Думаю многим знакома данная схема.

    Для начала нам необходимо настроить отправку SNMP трапов с маршрутизатора на сервер мониторинга. В моём случае это будет выглядеть так:

    login block-for 30 attempts 3 within 60
    login on-failure log
    login on-success log
    login delay 5
    
    logging history 5
    
    snmp-server enable traps syslog
    snmp-server enable traps snmp authentication
    snmp-server host 192.168.1.1 public
    

    Будем отправлять события из Syslog и трапы аутентификации. Замечу, что удачные и неудачные попытки авторизации пишутся именно в Syslog.

    Далее необходимо настроить прием нужных нам SNMP трапов на сервере мониторинга.
    Добавляем следующие строки в snmptt.conf:

    EVENT clogMessageGenerated .1.3.6.1.4.1.9.9.41.2.0.1 "Status Events" Normal
    FORMAT ZBXTRAP $ar $N $*
    SDESC
    EDESC
    

    В нашем примере будем ловить трапы Syslog.

    Теперь необходимо настроить элемент данных для сбора статистики со следующим ключом:

    snmptrap[“Status”]
    

    image


    Если трап не настроен на сервере мониторинга, то в логе сервера будут примерно такие записи:

    unmatched trap received from [192.168.1.14]:...
    

    В результате в полученном логе будет отражаться информация о попытках входа с детализированной информацией (user, source, localport и reason в случае неудачи):

    image


    Ну и можно настроить триггер для отображения события на Dashboard:

    {192.168.1.14:snmptrap["Status"].regexp(LOGIN_FAILED)}&{192.168.1.14:snmptrap["Status"].nodata(3m)}=0
    

    В сочетании с предыдущим пунктом у нас на Dashboard будет информация вот такого плана:

    image


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

    Хочу заметить что приведённый пример не будет работать на продуктах Cisco ASA и PIX, так как там несколько иначе организована работа с логированием авторизации.

    Juniper и Syslog

    Ещё одним примером мы разберем мониторинг авторизации в JunOS 12.1 для устройств Juniper.
    Тут мы не сможем воспользоваться трапами SNMP, потому как нет поддержки отправки трапов из Syslog сообщений. Нам понадобится Syslog сервер на базе Unix, в нашем случае им будет тот же сервер мониторинга.

    На маршрутизаторе нам необходимо настроить отправку Syslog на сервер хранения:

    system syslog host 192.168.1.1 authorization info
    

    Теперь все сообщения об авторизации будут отправляться на Syslog сервер, можно конечно отправлять все сообщения (any any), но переизбыток информации нам не нужен, отправляем только необходимое.

    Далее переходим к Syslog серверу
    Смотрим tcpdump, приходят ли сообщения:

    tcpdump -n -i em0 host 192.168.1.112 and port 514
    12:22:27.437735 IP 192.168.1.112.514 > 192.168.1.1.514: SYSLOG auth.info, length: 106
    

    По умолчанию в настройках syslog.conf все что приходит с auth.info должно записываться в /var/log/auth.log. Далее делаем все аналогично примеру с мониторингом входов в Unix.

    Вот пример строки из лога:

    image


    Остается только настроить триггер на данное событие так же как это было рассмотрено в примере с авторизацией на Unix сервере.

    P.S.

    Таким способом можно отслеживать множество событий, среди которых такие как: сохранение конфигурации устройства (commit), вход и выход из режима редактирования конфигурации (edit).
    Так же хочу заметить, что аналогичным способом можно осуществлять мониторинг и на устройствах Cisco, но способ с SNMP трапами мне кажется более быстрым и удобным, и исключается необходимость в промежуточном Syslog сервере.

    Заключение


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

    Подробнее
    Реклама
    Комментарии 28
    • +3
      Добавьте в ваш пост тег habracut, ну пожалуйста!
      • +2
        Извиняюсь, забыл ;)
        • +9
          В zabbix (и не только) много чего «можно». Гораздо интересней было бы если бы поделились готовыми шаблонами для мониторинга типовых событий информационной безопасности.
          • –7
            Пишу совершенно не туда, чтобы меня «услышало» Хабрасообщество. Кто-нибудь, напишите, пожалуйста, статью про всю эту историб с Лентачом.
            • +1
              да, zabbix очень гибок в плане добавления кастомных вещей, я как-то года два назад запилил простецкий мониторинг дырявых пакетов для redhat систем (на гитхабе).
              • 0
                Спасибо за статью!

                Два момента:
                1. Файлы вроде /etc/passwd проще всего мониторить на изменения через vfs.file.cksum, не нужны будут костыли в zabbix_agentd.conf
                2. Логи сетевых устройств мониторить аналогично юниксовым, пересылая их на сислог сервер в иерархию вроде /var/log/cisco/$IP/log и уже оттуда читая заббиксом.
                • +2
                  Спасибо за ответ. Замечу, что оба момента в статье мной описаны. ;)
                  • 0
                    Каюсь, как-то умудрился пропустить :)
                • +1
                  Но зачем? Есть же специальные, мощные, удобные и красивые инструменты, как коммерческие, так и open-source, например OSSIM или LOGalyze.
                  • +1
                    Меня например Zabbix прежде всего подкупает своей гибкостью и возможностью приспособиться под любые капризы как отдела безопасности так и отдела технической поддержки, ну и конечно же понятно написанной документацией.
                    • 0
                      Заббикс — великолепный продукт, его достоинств никто не умаляет.
                      Речь о том, что нет смысла проделывать вагон ручной работы только для того, чтобы получить 10-20% от того, что предлагают другие (в том числе и открытые) продукты сразу из коробки. Инструменты призваны сократить объем ручного труда, а не увеличить его.
                      • +3
                        В моем случае статья о том как использовать Zabbix как систему мониторинга ИБ в дополнение к его основным задачам. Я не утверждаю что это лучший способ. Он скорее для тех кто хочет иметь единую систему. Думаю что у всех продуктов есть свои плюсы и минусы. Тут уже выбирать конечному пользователю.
                        Но все же хочу заметить что Zabbix можно превратить в очень мощный инструмент мониторинга ИБ. 10-20% от того что предлагают другие из коробки далеко не показатель, да и ручного труда как такогого в процессе настройки нет, один раз настроить шаблоны сильно не сказывается на трудозатратах. ;)
                        • 0
                          Да благие намерения очевидны, только вот на выходе получается еще одно «кое-как», нестандартное, немасштабируемое и не развиваемое производителем в этом направлении. Обычно в профессиональных кругах такое называют словом «костыль». Костыль может быть хорошим, удобным и любимым, но не перестает от этого быть собой.
                          Ну вот например коды событий в логе windows меняются периодически (менялись при переходе от 2003 на 2008, потом еще менялись 2008->2012). Кто будет следить за этим в заббиксе? Правильно, никто, только тот, кто это и реализовал, если не забудет или не забьет на это через полгода. Тоже самое и с остальными источниками событий, с изменением версий ПО меняется и формат лога, меняются способы логирования и передачи логов во вне и все в таком духе. Производители специализированных решений следят за этим, коммьюнити пользователей следит за этим (если не успевает производитель), в итоге систему гораздо проще подерживать в актуальном состоянии, гораздо проще подключать новые источники событий, проще масштабировать систему, как результат — задача решается качественее с на порядки меньшими усилиями.
                          А вот преимуществ сабжа я не вижу вообще никаких, кроме уже озвученного «ну я так привык к заббиксу, что хочу там и мониторинг очереди в столовую сделать и корпоративный документооборот». Через некоторое время такая система либо превращается в засохшую тыкву, либо при попытках развития упирается в архитектурные ограничения. Ну и начинаем делать все заново, уже на подходящих решениях. Итог — потраченное время и усилия, но зато набиты некоторые шишки, которых, впрочем, можно и нужно было избежать.
                          Впрочем, это всего лишь скромное мнение человека, который последние несколько лет профессионально занимается системами сбора, анализа и корреляции событий ИБ, к этому мнению вовсе необязательно прислушиваться.
                          • +2
                            Я бы с радостью почитал статью от Вас на тему мониторинга событий ИБ, в предложенных Вами продуктах. ;)
                            • +2
                              Я бы с радостью написал. Но есть дилемма. Статья, на которую у меня хватит времени, получится очень обзорно-поверхностной и может даже быть сочтена за рекламную, да и пользы от нее не будет. Более-менее раскрыть тему можно только циклом довольно обширных статей, но на это у меня времени катастрофически не хватает. Периодически я пишу фокусные статьи в специализированные издания, но для Хабра, опять же, это не подойдет.
                              • +1
                                Косвенно мои слова подтверждаются тем, что даже смежная ИТ-ИБ статья с заббиксом вызвала лишь жалкий отлик, да и то, только среди ИТ-шников. Ни одного ИБ-шника, с которым можно построить диалог, в этой теме нет до сих пор — мой подробный комментарий с аргументами просто получил молчаливые минусы (от фанатов заббикса, видимо?) и никаких возражений или аргументов. Это также подтверждает мою мысль о том, что местная аудитория не нуждается в материале такого рода, да и не готова к нему.
                  • 0
                    Не хочу Вас разочаровывать, но на данный момент 233 человека добавили статью к себе в избранное. Соответственно посчитав данный материал полезным. Опять же замечу что статья писалась как альтернатива а не как незаменимый инструмент. Ваше мнение — это Ваше мнение, просто старайтесь его не навязывать другим. Считаю дальнейший диалог бесполезной тратой времени. Благодарю за критику.
                    • 0
                      Вопрос к автору статьи. А можно ли увеличить время жизни триггера на дашборде? А то он живет от последней неудачной попытки + 30с на обновление итема. Увеличение времени обновления итема не вариант.

                      Для bondbig. Да, заббикс не создан для мониторинга ИБ, но есть люди, которым гораздо приятнее когда все в кучке на 1 ресурсе, в одной программе. А не когда у тебя открыто 10 программ, каждая из которых специализируется на своей области. Для таких людей те самые костыли уместны и дискомфорта не вызывают. имхо.
                      • 0
                        Ну так о том и речь, что подобные «решения» отвечают интересам конкретного человека (в краткосрочной перспективе), но вредят интересам бизнеса (в средне и долгосрочной). Если это для кого-то не является очевидным, то я попытался объяснить. Я пытаю.сь намекнуть, что неплохо бы развивать стратегическое мышление и стараться видеть чуть дальше, чем «вот прямо сейчас».
                        В качестве интересной задачки для развлечения и получения некого опыта — да, можно и нужно делать такие вещи. Но интегрировать в бизнес-процессы — нет. Потом будет много боли и слез, когда придется сносить заботливо построенный руками шалашик, чтобы расчистить место для строительства здания.
                        • 0
                          Одно могу сказать, для госструктур не повредят =)
                          У нас не все так быстро развивается. И скупать каждый год вновь вышедшую винду мы не можем. Хотя в целом Вы и правы.
                          • 0
                            О каких госструктурах идет речь? Я делал множество проектов для разных (крупных) госструктур, баловством там обычно не занимаются. Если речь про какую-нибудь администрацию какого-нибудь города, то наверное. Если же про федеральные структуры — то нет.
                            • +1
                              Мало Вы знаете про госструктуры. Они разные бывают. В кого то вбухивают деньги, кто-то вынужден жить на самообеспечении и ожидать центральных закупок.
                              Хотя Вы скорее всего имели ввиду построение централизованных ИС. Тут да, и деньги большие и исполнение более менее на уровне (за исключением некоторых случаев, почитайте про тот же Росреестр). Но это бывает редко. Так что каждый регион сам себе король и городит что хочет.
                              • 0
                                Ну, знаю только про крупные федеральные или столичные. Про мелкие региональные не знаю ничего, да.
                        • 0
                          Забыл уточнить для какого триггера — для авторизации по SSH.
                          • Интересный вопрос, спасибо. Честно говоря с этим не эксперементировал, но думаю теоретически возможно. Попробовать в выражении триггера использовать diff и например условие совпадения предыдущего и последнего значения. Вообщем мне этот вопрос тоже стал интересен. :) Попробую реализовать. Можете более подробно описать в чем сложность? Я так понимаю что при следующем обновлении элемента данных триггер переходит в OK, так? Можете привести пример последнего и предыдущего значения? У меня триггер без проблем живет 5 минут на дашборде как и указано в выражении.
                            • 0
                              Всё верно. После неудачной аутентификации проходит 30 секунд, которые выставлены в настройках итема.
                              Сам триггер такой же, только выражение разное, т.к. у меня другая система:
                              {proxyd:log[/var/log/auth.log,sshd,,,skip].regexp(failure)}|{proxyd:log[/var/log/auth.log,sshd,,,skip].regexp(Failed password)}&{proxyd.:log[/var/log/auth.log,sshd,,,skip].nodata(3m)}=0
                              Что соответствует строкам:
                              Mar 18 15:56:12 proxyd sshd[13954]: Failed password for root from 10.8.36.105 port 24550 ssh2
                              и
                              Mar 18 10:14:57 proxyd sshd[12551]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.8.36.105

                              Что имеется ввиду под примером? Выложу скрин.
                        • 0
                          не туда ответил =(
                          • 0
                            Любопытно, но — 2014 год, актуальнее было бы не 2003 и 2008 сервер рассматривать, а 2008 и 2012.

                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.