SSH - (Secure Shell) - сетевой протокол, позволяющий производить удалённое управление компьютером и передачу файлов. Сходен по функциональности с протоколом Telnet и rlogin, однако использует алгоритмы шифрования передаваемой информации.
Недостатки telnet привели к очень быстрому отказу от использования этого протокола в пользу более безопасного и функционального протокола SSH. SSH предоставляет все те функциональные возможности, которые представлялись в telnet, с добавлением эффектного кодирования с целью предотвращения перехвата таких данных, как логины и пароли. Введенная в протоколе SSH система аутентификации с использованием публичного ключа гарантирует, что удаленный компьютер действительно является тем, за кого себя выдает.
Криптографическая защита протокола SSH не фиксирована, возможен выбор различных алгоритмов шифрования. Клиенты и серверы, поддерживающие этот протокол, доступны для различных платформ. Кроме того, протокол позволяет не только использовать безопасный удалённый shell на машине, но и туннелировать графический интерфейс - X Tunnelling (только для Unix-подобных ОС или приложений, использующих графический интерфейс X Window System). Так же SSH способен передавать через безопасный канал (Port Forwarding) любой другой сетевой протокол, обеспечивая (при надлежащем конфигурировании) возможность безопасной пересылки не только X-интерфейса, но и, например, звука.
Однако протокол SSH не решает всех проблем сетевой безопасности. Он лишь фокусирует свое внимание на обеспечении безопасной работы таких приложений, как эмуляторы терминала. Использование реализаций протокола SSH на серверах и в клиентских приложениях помогает защитить данные лишь в процессе передачи. Протокол SSH ни коим образом не является заменой брандмауэров, систем обнаружения вторжений, сетевых сканеров, систем аутентификации и других инструментов, позволяющих защитить информационные системы и сети от атак.
39.Роль и задачи сервера в локальной сети.
В общем понимании сервер – это вычислительная машина, обладающая, как правило, высокой производительностью и другими вычислительными ресурсами, предназначенная для предоставления определённых возможностей для компьютеров локальной или глобальной сети. Эти возможности называют сетевыми сервисами .
Задачи сервера:
1.обеспечения доступа к данным, хранящимся на серверных дисках организации;
2.хранение, обработку и доступ к базам данных компании;
3.программную обработку данных, которые посылает ему пользователь, и выдаёт этому пользователю конечные результаты;
4.выдачу интернет-страницы пользователю, который её запрашивает;
5.отправки, получения, хранения и распределения электронных писем, которые посылают все пользователи локальной сети.
Сетевые службы.
Для конечного пользователя сеть - это не компьютеры, кабели и концентраторы и даже не информационные потоки, для него сеть - это, прежде всего, тот набор сетевых служб, с помощью которых он получает возможность просмотреть список имеющихся в сети компьютеров, прочитать удаленный файл, распечатать документ на «чужом» принтере или послать почтовое сообщение. Именно совокупность предоставляемых возможностей - насколько широк их выбор, насколько они удобны, надежны и безопасны - определяет для пользователя облик той или иной сети.
Кроме собственно обмена данными, сетевые службы должны решать и другие, более специфические задачи, например, задачи, порождаемые распределенной обработкой данных. К таким задачам относится обеспечение непротиворечивости нескольких копий данных, размещенных на разных машинах (служба репликации), или организация выполнения одной задачи параллельно на нескольких машинах сети (служба вызова удаленных процедур). Среди сетевых служб можно выделить административные, то есть такие, которые в основном ориентированы не на простого пользователя, а на администратора и служат для организации правильной работы сети в целом.
Реализация сетевых служб осуществляется программными средствами. Основные службы - файловая служба и служба печати - обычно предоставляются сетевой операционной системой, а вспомогательные, например служба баз данных, факса или передачи голоса, - системными сетевыми приложениями или утилитами, работающими в тесном контакте с сетевой ОС. Вообще говоря, распределение служб между ОС и утилитами достаточно условно и меняется в конкретных реализациях ОС.
При определении степени удобства разделяемого ресурса часто употребляют термин «прозрачность». Прозрачный доступ - это такой доступ, при котором пользователь не замечает, где расположен нужный ему ресурс - на его компьютере или на удаленном. После того как он смонтировал удаленную файловую систему в свое дерево каталогов, доступ к удаленным файлам становится для него совершенно прозрачным. Сама операция монтирования также может иметь разную степень прозрачности - в сетях с меньшей прозрачностью пользователь должен знать и задавать в команде имя компьютера, на котором хранится удаленная файловая система, в сетях с большей степенью прозрачности соответствующий программный компонент сети производит поиск разделяемых томов файлов безотносительно мест их хранения, а затем предоставляет их пользователю в удобном для него виде, например в виде списка или набора пиктограмм.
Для обеспечения прозрачности важен способ адресации (именования) разделяемых сетевых ресурсов. Имена разделяемых сетевых ресурсов не должны зависеть от их физического расположения на том или ином компьютере. В идеале пользователь не должен ничего менять в своей работе, если администратор сети переместил том или каталог с одного компьютера на другой. Сам администратор и сетевая операционная система имеют информацию о расположении файловых систем, но от пользователя она скрыта. Такая степень прозрачности пока редко встречается в сетях, - обычно для получения доступа к ресурсам определенного компьютера сначала приходится устанавливать с ним логическое соединение. Такой подход применяется, например, в сетях Windows NT
Есть несколько способов получить доступ к среде CLI. Наиболее распространенные методы:
-
Telnet или SSH
Консоль
К CLI можно получить доступ через консольный сеанс, также известный как строка CTY. Консоль использует низкоскоростное последовательное соединение, которое происходит через непосредственное подключение компьютера или терминала к консольному порту на маршрутизаторе или коммутаторе.
Консольный порт является портом управления, который обеспечивает внеполосный доступ к маршрутизатору. Консольный порт доступен, даже если никакие сетевые службы не были сконфигурированы на устройстве. Консольный порт часто используется, чтобы получить доступ к устройству, когда сетевые службы не были запущены или перестали работать.
Примеры использования консоли:
Начальная конфигурация сетевого устройства
Процедуры аварийного восстановления и поиск и устранение неисправностей, когда удаленный доступ не возможен
Процедуры восстановления пароля
Когда маршрутизатор впервые начинает использоваться, сетевые параметры еще не сконфигурированы. Поэтому, маршрутизатор не может осуществлять связь через сеть. Чтобы подготовить его к начальному запуску и конфигурации, на компьютере запускают программное обеспечение эмуляции терминала для соединения с консольным портом устройства. Команды конфигурации для настройки маршрутизатора могут быть введены через соединенный компьютер.
Во время работы, если к маршрутизатору нельзя получить доступ удаленно, соединение с консолью через компьютер может позволить определить состояние устройства. По умолчанию консоль выводит информацию о запуске устройства, об отладке и сообщения об ошибках.
Для многих устройств с IOS консольный доступ не требует никакой формы безопасности по умолчанию. Однако, консоль должна быть сконфигурирована с паролями, чтобы предотвратить несанкционированный доступ к устройству. Когда пароль теряется, существует специальный набор процедур для того, чтобы обойти пароль и получить доступ к устройству. Устройство должно быть расположено в заблокированной комнате или стойке для оборудования, чтобы предотвратить физический доступ.
Telnet и SSH
Telnet - метод для получения удаленного доступа к сеансу CLI маршрутизатора. В отличие от консольного соединения, сеансы Telnet требуют активных сетевых служб на устройстве. У сетевого устройства должен быть по крайней мере один активный интерфейс, сконфигурированный с адресом Уровня 3, таким как адрес IPv4. Устройства с Cisco IOS включают процесс сервера Telnet, который запускается при запуске устройства. IOS также содержит клиент Telnet.
Узел с клиентом Telnet может получить доступ к сеансам vty, работающим на устройстве Cisco. Из соображений безопасности IOS требует, чтобы сеанс Telnet использовал пароль в качестве минимальный метода аутентификации. Методы установки учетных записей и паролей будут обсуждаться в последующих статьях данной рубрики.
Протовол Безопасной Оболочки (SSH) является более безопасным методом для удаленного доступа к устройству. Этот протокол обеспечивает удаленный вход в систему, подобный Telnet, за исключением того, что он использует более безопасные сетевые службы.
SSH обеспечивает более сильную аутентификацию по паролю, чем Telnet, и использует шифрование, транспортируя данные сеанса. Сеанс SSH шифрует все передачи данных между клиентом и устройством IOS. Это защищает идентификатор пользователя, пароль и детали сеанса управления. Следуя передовой практике, всегда используйте SSH вместо Telnet, когда только это возможно.
Большинство более новых версий IOS содержат сервер SSH. В некоторых устройствах эта служба включена по умолчанию. Другие устройства требуют, чтобы сервер SSH был включен.
Устройства IOS также включают клиент SSH, который может использоваться, чтобы установить сеансы SSH с другими устройствами. Точно так же можно использовать удаленный компьютер с клиентом SSH, чтобы запустить безопасный сеанс CLI. Клиентское программное обеспечение SSH не поставляется по умолчанию на всех компьютерных операционных системах. Вы, возможно, должны будете получить, установить и сконфигурировать клиентское программное обеспечение SSH для Вашего компьютера.
AUX
Другой способ установить сеанс CLI удаленно - через телефонное коммутируемое соединение, используя модем, соединенный с портом маршрутизатора AUX. Подобно консольному соединению, этот метод не требует конфигурации каких-либо сетевых служб или их доступности на устройстве.
Порт AUX может также использоваться локально в качестве консольного порта при прямом подключении к компьютеру, выполняющему программу эмуляции терминала. Консольный порт требуется для конфигурации маршрутизатора, но не все маршрутизаторы имеют вспомогательный порт. Консольный порт также предпочитается вспомогательному порту для диагностики, потому что он отображает детали запуска маршрутизатора, информацию об отладке и сообщения об ошибках по умолчанию.
Обычно, единственный случай, когда порт AUX используется локально вместо консольного порта - когда есть проблемы с использованием консольного порта, например, если некоторые параметры консоли неизвестны.
Telnet – базовый протокол ОС UNIX, обеспечивающий терминальный доступ пользователей к удалённому компьютеру .
Первоначально терминалом являлось устройство типа пишущей машинки, на котором оператор (пользователь) печатал команды и наблюдал результаты. Позднее терминал разделили на монитор и клавиатуру.
По умолчанию в Telnet используется 23 порт. На удалённом компьютере должна быть запущена серверная часть, а на компьютере пользователя – клиентская. Клиентская программа носит то же название – telnet и допускает ввод параметров из командной строки. К этим параметрам относятся:
Имя (IP адрес) сервера и номер порта
Тип текстового терминала
Имя пользователя
Имя журнала соединения
Определение действий некоторых функциональных клавиш клавиатуры и др.
Синтаксис командной строки зависит от программной реализации telnet и с этой точки зрения telnet можно рассматривать как службу или сервис.
Работа протокола telnet предусматривает передачу серверу (удалённому компьютеру) по протоколу ТСР каждого набранного пользователем знака в отдельном пакете. В случае включённого эха сервер возвращает знак на монитор пользователя. Результаты выполнения запущенных на сервере программ передаются уже блоками. В пределах прав пользователя и возможностей терминала telnet обеспечивает полный доступ к программам и файлам сервера. При установлении соединения в процессе аудентификации символы имени пользователя и пароля передаются в открытом виде, что делает использование telnet крайне опасным.
Наиболее популярный метод повышения безопасности прикладных терминальных протоколов (например, telnet) является протокол SSH (Secure SHell), использующий 22 порт по умолчанию. Так же, как и в telnet, на удалённом компьютере запускается серверная часть SSH, а на пользовательском компьютере – клиентская. После установления соединения все данные передаются в зашифрованном виде и все данные прикладных протоколов туннелируются по этому защищённому соединению как это показано на рисунке 3.5.3.1.
Перед использованием telnet удалённый компьютер и компьютер пользователя устанавливают защищённое соединение по 22 порту (подразумевается, что до использования SSH в клиентской и серверной части уже определены пароли криптографической защиты). При вызове telnet открывается 23 порт, но передаваемые пакеты перехватываются клиентом SSH, шифруются и отправляются по защищённому каналу. Сервер SSH расшифровывает данные и по 23 порту передаёт серверу telnet. Реакция сервера передаётся в обратном порядке. Пользователь не ощущает работы протокола SSH и работает как с обычным клиентом telnet по 23 порту.
Протоколы электронной почты
Электронная почта (E-mail) – один из старейших и наиболее распространённых сетевых сервисов, популярных как в локальных, так и глобальных сетях .
Система электронной почты появилась в 1982 г. как сервис предка Internet сети ARPANET. Эта система значительно отличалась от принятых CCITT рекомендаций серии X.400. Сложность рекомендаций Х.400 и их непродуманность привели к редкому для сетевых технологий случаю, когда инициативная разработка победила международный стандарт. Службы электронной почты, отвечающие Х.400, не нашли широкого применения и представляют скорее научный интерес.
Электронное почтовое сообщение, как и в обычной почте, содержит конверт с необходимой для доставки информацией, заголовка с полезными для автоматизированной обработки адресатом данными и собственно сообщения.
Конверт и заголовок имеют формализованные поля. Наиболее важными из них являются (обязательные для заполнения отправителем поля выделены жирным шрифтом):
То: - адрес (а) получателя (лей) в формате имя_ящика@имя_почтового_сервера
Сс: - (carbon copy) адрес (а) дополнительного (ных) получателя (лей)
Bcc: - (blind carbon copy) слепой (ые) адрес (а) получателя (лей), о которых другим не сообщается
Sender: - адрес отправителя письма
Received: - поле, куда при прохождении каждого узла добавляется имя узла, дата и время приёма
Return-Path: - имена узлов на пути письма
Date: - дата и время отправки письма
Reply-to: - адрес, куда надо ответить
Message-id: - уникальный идентификатор письма (для ссылок)
In-Reply-id: - идентификатор письма, на которое даётся ответ
Subject: - тема письма
Тело сообщения представляет собой набор строк из не более, чем 1000 (рекомендуется до 78) ASCII (American Standard Code for Information Interchange) знаков, т. е. 7-и битных чисел, представляющих буквы латинского алфавита, знаки препинания и цифры (популярным для такого представления является термин «кодировка»). Символы национальных кодировок (например, знаков кириллицы), двоичные файлы (например, с аудио, или видео информацией) и др. отображаются в соответствии с соглашением MIME (Multipurpose Internet Mail Extension – многоцелевые расширения электронной почты в Интернете), которое предусматривают поле с указанием способа кодировки (например, Base64 – см. параграф 3.5.2).
Базовым методом обеспечения конфиденциальности электронной почты является её криптографическая защита. Наиболее популярная система именуется PGP (Pretty Good Privacy - достаточно хорошая конфиденциальность). Эта система предложена Филом Циммерманом (Phil Zimmerman) и предусматривает использование нескольких алгоритмов шифрования (RSA, IDEA, MD5).
Другая система носит название PEM (Privacy Enhanced Mail – почта повышенной секретности) и отличается от PGP необходимостью связи с центрами сертификации ключей, меньшей степенью защиты (для кодирования данных в системе PGP используется ключи длинной 128 бит, а в системе PEM – только 56 бит), но полным соответствием рекомендациям ITU-T (Х.400 и Х.509).
Протоколы электронной почты характеризуются значительным разнообразием от фирменных, пригодных в программных продуктах конкретных фирм-производителей, до общепризнанных. Речь идёт о протоколах именно систем электронной почты, а не о распространённых системах эмуляции почтовых служб на базе протокола НТТР (см., например, www. mail. ru).
Среди почтовых протоколов можно выделить:
SMTP (Simple Mail Transfer Protocol – простой протокол электронной почты) – протокол, используемый для обмена почтой между узлами и отправки писем от клиента к почтовому серверу. По умолчанию протокол использует 25 порт.
РОР3 (Post Office Protocol v.3 –протокол электронной почты версии 3) – протокол для получения почты клиентом. По умолчанию протокол использует 110 порт.
IMAP v4 (Internet Message Access Protocol v.4 –протокол интерактивного доступа к электронной почте версии 4) – протокол, аналогичный РОР3, но позволяющий клиенту хранить и обрабатывать почту на самом почтовом сервере. По умолчанию протокол использует 585 порт
Протокол SMNP
Протокол SNMP (Simple Network Management Protocol – простой протокол сетевого управления) первоначально разрабатывался для управления маршрутизаторов, но затем был расширен на любые сетевые устройства (по умолчанию порты 161/162). В настоящее время актуальна версия 2 протокола (1999 г.) .
Протокол построен по принципу клиент - сервер (на управляемом сетевом устройстве должна быть запущена программа клиента) и включает в себя протокол управления (взаимодействие управляемого и управляющего узлов), язык ASN.1 (Abstract Syntax Notation v.1 - абстрактная синтаксическая нотация версии 1) описания модели управления и собственно модель управления MIB (Management Information Base - база управляющей информации). Распространению протокола мешает его низкая защищённость и ориентация на использование протокола UDP, приводящего к возможной потере сообщенийDNS
Задача разрешения имен подразумевает определение IP адреса узла по его символьному имени и определение символьного имени по заданному IP адресу.
Исторически первый, но до сих пор действующий механизм разрешения имен связан с прямым заданием таблицы соответствия символьных имён и IP адресов в файле hosts/lmhosts (первый файл используют UNIX/Linux и некоторые др. операционные системы (ОС), а второй – ОС фирмы Microsoft). Оба файла текстовые и их форматы и ключи можно найти в MS Windows в одноимённых файлах с расширением. sam (sample – образец). Очевидно, для сколько-нибудь крупной сети решить задачу таким образом полностью не представляется возможным, хотя запись в эти файлы сведений об основных серверах, маршрутизаторах, шлюзах и пр. весьма эффективна для ускорения старта компьютера в сетевом окружении.
Другой, достаточно популярный способ разрешения имён связан с использованием NetBIOS (Network Basic Input/Output System) поверх TCP/IP . Эта система была разработана совместными усилиями Microsoft и IBM в 80-е годы как сетевой сервис ввода/вывода для операционной системы Windows. Позже, для реализации доступа пользователей к ресурсам сети был разработан протокол NetBEUI (NetBIOS Extended User Interface – расширенный пользовательский интерфейс NetBIOS) как основной сетевой протокол в ОС Windows for Workgroups и NT. Наконец, с повсеместным распространением стека TCP/IP компания Microsoft была вынуждена выпустить реализацию NetBIOS, использующую протокол IP для передачи необходимых данных (NetBIOS поверх TCP/IP). До сих пор продолжается поддержка NetBIOS в ОС Windows 2000/NT/XP, правда уже не как основного механизма доступа к ресурсам сети. NetBIOS целесообразно использовать в небольших, одноранговых сетях.
Изначально, каждый узел в сети с NetBIOS имеет символьное имя (до 15 знаков) с идентификатором ресурса (16-ый знак), который указывает на роль узла (файловый сервер, принт-сервер, рабочая станция и пр.). «Чистый» NetBIOS применим только для небольших сетей и считается «немаршрутизируемым», т. к. –
система имён не позволяет идентифицировать сеть
широко используются широковещательные запросы для получения и обновления сведений об узлах сети (большинство маршрутизаторов широковещательные запросы не пропускают)
Для устранения указанных недостатков компания Microsoft предложила службу WINS (Windows Internet Name Service – служба Windows имен Internet) на базе серверов имен NetBIOS. Следует отметить, что несмотря на упоминание сети Internet, WINS не применяется в этой глобальной сети.
Первый недостаток NetBIOS устраняется в WINS тем, что вводится групповое имя для сети, а второй – тем, что запросы при разрешении имён обращены к конкретным серверам WINS. Неустойчивость в работе службы, трудности администрирования и затруднительность использования в глобальной сети Internet, к настоящему моменту заставили компанию Microsoft перейти к полноценной поддержке DNS.
DNS (Domain Name System – доменная система имён) реализуется с помощью одноименного прикладного протокола, использующего по умолчанию 53 порт . Система DNS была разработана в рамках ОС UNIX и соответствующая служба, использующая DNS, имеет ту же аббревиатуру, но расшифровывается как Domain Name Service.
Имена в DNS строятся по иерархическому принципу в виде перевёрнутого дерева. Домены верхнего уровня (корневые) делятся по профессиональному принципу (. com - коммерческие,. gov - государственные,. net - сетевые и пр. узлы) или по национальному (. ru - русские,. fi - финские,. fr - французские и т. д.). ОС UNIX разрабатывалась в США и, само собой считалось, что все узлы находятся там же. Сейчас можно встретить двойные имена доменов, например,. com. tw – коммерческие тайваньские.
В свою очередь, каждый домен содержит поддомен, имя которого добавляется слева и отделяется точкой, и т. д. Заканчивается запись добавлением слева имени узла. Имя каждого домена, поддомена или узла не должно превышать 63 символа, а полное имя – 255 символов. Для обозначения имён традиционно используется латинский алфавит, цифры и тире (знак _ недопустим), но, в принципе, можно зарегистрировать домен с именем на кириллице, но смысл этого проблематичен.
Данные об именах зарегистрированных в любом домене поддоменов/узлов и их IP адресах хранятся в двух таблицах на DNS-серверах, где также имеется имя и адрес вышележащего домена. По первой таблице для заданного символьного имени определяется цифровой адрес (прямое преобразование и, соответственно, т. н. «прямая зона»), а по второй - по заданному адресу находится символьное имя (обратное преобразование и «обратная зона»).
Для повышения надёжности в каждом домене должно быть не менее 2-х серверов (primary - первичного и secondary - резервного), причём физически эти серверы должны находиться в разных сетях и могут располагаться не в тех доменах, имена узлов которых они содержат.
Корневой домен поддерживают свыше 10 DNS серверов, IP адреса и имена которых «зашиты» в сетевые ОС. Регистрацию новых имён и выделение соответствующих IP адресов производит владелец домена. Например, регистрацию в домене. ru производит РосНИИРОС, где регистрация имени и получение IP адреса обойдётся приблизительно в 50$, а годовая поддержка адреса – в 10$.Все изменения в таблице имен производятся на первичном DNS сервере, резервные серверы только обновляют свои записи по записям первичного сервера. Репликация (обновление) зоны производится с помощью надёжного протокола TCP, в то время, как для DNS запросов клиентов, применяется протокол UDP. Для ускорения процесса разрешения имени и уменьшения трафика в сети иногда устанавливают так называемые кэш-серверы DNS, которые записывают часто используемые имена и адреса.Режим работы DNS сервера может быть рекурсивным и не рекурсивным. В случае рекурсивного режима при невозможности разрешить DNS запрос этот запрос транслируется специально заданному другому DNS серверу (форвардеру – forfarders), который затем возвращает полученный ответ. При не рекурсивном режиме - в отсутствии информации о запрашиваемом узле производится обращение к корневым DNS серверам, а от них вниз по цепочке до получения ответа.
NAT (Network Address Translation - трансляция сетевых адресов) реализует преобразование (подмену) IP адресов локальных сетей во внешние IP адреса глобальной сети Internet . Необходимость такого преобразования следует из соглашения об использовании части IP адресов только в локальных сетях (см. п. 3.2), по которому маршрутизаторы глобальной сети уничтожают пакеты с этими адресами.
NAT действует на сетевом и частично на транспортном уровнях, обеспечивая преобразование в IP пакетах адресов узлов локальной сети во внешний адрес. Преобразование производится путём замены адреса внутреннего узла на внешним адрес. Заменяемые адреса запоминаются в таблице, с помощью которой производится обратная замена при получении ответного пакета. Следует отметить, что для устранения возможной неразличимости преобразуется не только IP адрес, но и с помощью PAT (Port Address Translation) номер порта.
Кроме преобразования адресов NAT позволяет уменьшить потребность в IP адресах для глобальных сетей, т. к. все пользователи локальной сети могут получать доступ к ресурсам глобальной сети через один внешний адрес.
NAT - не единственный способ отправки пакетов из локальной сети в глобальную, альтернативой трансляции адресов является использование сервера-посредника.
В книге подробно рассмотрены настройки сетевых сервисов, позволяющих создать сервер требуемой конфигурации и функциональности на основе ОС Linux. Вы сможете настроить сервер любого типа: от сервера локальной сети до Интернет-сервера и сервера удаленного доступа. Детальна описано администрирование Linux.
Изложение материала построено на основе дистрибутивов Red Hat и Mandrake. Много уникальной информации: запуск Windows-игр под Linux и создание Linux-сервера для игрового зала, настройка антивирусов Dr. Web и AVP под Linux, программа учета трафика MRTG, система защиты и обнаружения атак LIDS, а также многое другое. Особое внимание уделено безопасности Linux-серверов. Достаточно подробно описана сама ОС Linux и приведен справочник ее команд. Прочитав книгу, вы станете обладателями знаний по настройке и компилированию ядра, созданию собственных rpm-пакетов, командному интерпретатору bash, использованию массивов RAID. Вы узнаете внутренний мир Linux. Книга подойдет как для профессиональных, так и для начинающих администраторов, поскольку изложение материала начинается с установки ОС Linux, а в первой главе дано описание основных сетевых технологий и протоколов (Курс Молодого Администратора).
Все приведенные в книге листинги проверены на практике и размещены на прилагаемом CD. Помимо этого на нем содержится много справочной информации (HOWTO, RFC), a также статей, посвященных Linux. Размещен богатый набор вспомогательных утилит и программного обеспечения для сервера (Apache, MySQL, MRTG и др.).
Книга:
Разделы на этой странице:
Сервис Telnet обеспечивает базовую эмуляцию терминалов удаленных систем, поддерживающих протокол Telnet над протоколом TCP/IP. Обеспечивается эмуляция терминалов Digital Equipment Corporation VT 100, Digital Equipment Corporation VT 52, TTY. Протокол Telnet описан в документе RFC 854, который вы найдете на прилагаемом компакт-диске.
Любые команды, выполняемые с помощью Telnet, обрабатываются telnet-сервером, а не локальным компьютером. Пользователь лишь видит результат выполнения этих команд.
Для использования Telnet на удаленном компьютере должен быть установлен telnet-демон. На компьютере пользователя нужно установить программу-клиент. Практически в каждой операционной системе существует утилита telnet, которая является клиентом для протокола telnet (см. рис. 8.2).
Сервис Telnet был и остается одним из самых популярных способов удаленной регистрации и работы на удаленной машине. Основным его недостатком является то, что любая информация, в том числе и пароли, передается в открытом виде без какого-либо кодирования.
SSH (Secure Shell) - программа, позволяющая вам зарегистрироваться на удаленных компьютерах и установить зашифрованное соединение. Существует также «безопасная» версия telnet - stelnet.
SSH использует криптографию открытого ключа для шифрования соединения между двумя машинами, а также для опознавания пользователей.
Рис. 8.2.Telnet-клиент для Windows
Оболочку ssh можно использовать для безопасной регистрации на удаленном сервере или копировании данных между двумя машинами, в то же время предотвращая атаки путем присоединения посередине (session hijacking) и обманом сервера имен (DNS spotting).
Оболочка Secure Shell поддерживает следующие алгоритмы шифрования:
BlowFish - это 64-разрядная схема шифрования. Этот алгоритм часто используется для высокоскоростного шифрования данных больших объемов.
Тройной DES (Data Encryption Standard) - стандарт для шифрования данных. Данный алгоритм довольно старый, поэтому не рекомендуется его использовать. Обычно DES используется для шифрования несекретных данных.
IDEA (International Data Encryption Algorithm) - международный алгоритм шифрования информации. Этот алгоритм работает со 128-разрядным ключом и поэтому он более защищен, чем BlowFish и DES.
RSA (Rivest-Shamir-Adelman algorithm) - алгоритм Ривеста-Шамира-Адельмана. Представляет собой схему шифрования с открытым и секретным ключами.
При выборе алгоритма шифрования нужно исходить из конфиденциальности информации, которую вам нужно передать. Если информация секретна, лучше использовать алгоритмы IDEA или RSA. Если же вы просто не хотите передавать данные в открытом виде, используйте алгоритм BlowFish, поскольку он работает значительно быстрее, чем DES.
Оболочка ssh очень эффективна против анализаторов протоколов, так как она не только шифрует, но и сжимает трафик перед его передачей на удаленный компьютер. Программу ssh можно скачать по адресу http://www.cs.hut.fi/ssh/ . Версия ssh для UNIX распространяется бесплатно, а за Windows-версию (имеется в виду клиент для Windows) нужно заплатить.
Оболочка ssh незаменима в тех случаях, когда удаленно нужно администрировать сервер или когда сервер не имеет собственного монитора. При использовании telnet все данные, которые передаются через telnet-соединение, доступны в открытом виде. А значит, имена пользователей и пароли будут доступны всем, кто прослушивает трафик с помощью анализатора. Шифрование ssh выполняет, используя несколько различных алгоритмов, включая DES и 3DES.
Программа состоит из демона sshd, который запускается на Linux/UNIX-машине, и клиента ssh, который распространяется как для Linux, так и для Windows. Чтобы установить ssh, возьмите исходные тексты и поместите их по традиции в каталог /usr/src/. Затем распакуйте архив и установите программу, выполнив следующую последовательность действий:
cd /usr/src/
tar xzf ssh-2.4.0.tar.gz
cd ssh-2.4.0
./configure
make
make install
Чтобы ssh начал работать, необходимо запустить демон sshd на той машине, к которой предполагается подключение. Желательно добавить команду запуска в сценарий загрузки системы для автоматического запуска. Демон sshd работает по 22 порту (см. листинг 8.6). Если не ошибаюсь, ssh невозможно использовать вместе с xinetd/inetd - его нужно запускать подобно httpd– серверу в режиме standalone.
Листинг 8.6. Фрагмент файла /etc/services
ssh 22/tcp # SSH Remote Login Protocol
ssh 22/udp # SSH Remote Login Protocol
Обычно с настройкой sshd не возникает никаких неприятных моментов. Подробно настройка демона будет рассмотрена чуть ниже в этой главе. Теперь попробуйте зарегистрироваться на этой машине через ssh. Для этого нужно установить этот же пакет на другую машину под управлением Linux/UNIX (или установить Windows-клиент ssh) и ввести команду:
$ ssh hostname.domain
ssh запросит вас ввести пароль пользователя. В качестве имени пользователя для установки соединения будет использовано имя текущего пользователя, то есть имя, под которым вы сейчас зарегистрированы в системе. В случае, если аутентификация пройдет успешно, начнется сеанс связи. Прекратить сеанс можно комбинацией клавиш Ctrl+D.
Если вам нужно указать другое имя пользователя, используйте параметр –l программы ssh:
ssh –l user hostname.ru
Так можно указать программе ssh, от имени какого пользователя нужно регистрироваться на удаленной машине (см. рис. 8.3).
При использовании Windows-клиента имя компьютера, имя пользователя и пароль нужно ввести в диалоговом окне программы. Если соединение не устанавливается, попробуйте выбрать метод кодирования blowfish. Если и это не поможет, выберите 3DES.
Работа в ssh аналогична работе в telnet. Вы можете администрировать удаленную машину также легко, как и локальную. Опции программы ssh указаны в табл. 8.5.
Рис.8.З. Регистрация на удаленной машине
Опции программы ssh Таблица 8.5
| Опция | Описание |
|---|---|
| -а | Отключает перенаправление аутентификации агента соединения |
| -А | Включает перенаправление аутентификации агента соединения |
| -с blowfish|3des | Позволяет выбрать алгоритм шифрования при использовании первой версии протокола SSH. Можно указать или blowfish, или 3des |
| -с шифр | Задает список шифров, разделенных запятыми в порядке предпочтения. Только для второй версии протокола SSH. Допускаются значения blowfish, twofish, arcfour, cast, des и 3des |
| -f | Данная опция переводит ssh в фоновый режим после аутентификации пользователя. Рекомендуется использовать для запуска программы Х11 . Например, ssh –f hostxterm |
| -i | идент_файл Задает нестандартный идентификационный файл (для нестандартной RSA/DSA-аутентификации) |
| -l имя_пользоват | Указывает от имени какого пользователя будет осуществляться регистрация на удаленной машине |
| -р порт | Определяет порт, к которому подключится программа ssh (по умолчанию используется порт 22) |
| -q | «Тихий режим». Будут отображаться только сообщения о фатальных ошибках. Все прочие предупреждающие сообщения в стандартный выходной поток выводиться не будут |
| -x | Отключить перенаправление Х11 |
| -X | Включить перенаправление Х11 |
| -1 | Использовать только первую версию протокола SSH |
| -2 | Использовать только вторую версию протокола SSH |
| -4 | |
| -6 |
Оболочка ssh использует два файла конфигурации ssh_conf и sshd_conf. Думаю, что нет смысла говорить о том, что они находятся в директории /etc/ssh. Рекомендую в файле sshd_conf прописать следующую строчку:
allowedadress 10.1.1.1 10.1.2.1 10.1.3.1
Это означает, что доступ по ssh может быть выполнен только с машин с адресами 10.1.1.1, 10.1.2.1, 10.1.3.1. Это оградит ваш компьютер от нежелательных вторжений извне.
Программа stelnet во всем полностью аналогична программе telnet, но она выполняет шифрование трафика, который передается во время telnet-соединения.
Демон sshd - это программа-демон для оболочки ssh. Обычно sshd запускается на машине, к которой подключаются клиенты ssh. Последние версии демона sshd поддерживают две версии протокола ssh - ssh версия 1, и ssh версия 2.
Протокол SSH версия 1
У каждого узла есть свой RSA-ключ (обычно 1024 бит), который используется для идентификации узла. Этот ключ еще называется открытым. Дополнительно, при запуске демона, генерируется еще один RSA-ключ - ключ сервера (обычно 768 бит). Этот ключ создается заново каждый час и никогда не сохраняется на диске.
Каждый раз при установке соединения с клиентом демон отправляет ему в ответ свой открытый ключ и ключ сервера. Клиент сравнивает полученный открытый ключ со своей базой данных, чтобы проверить, не изменился ли он. Затем клиент случайным образом генерирует 256-разрядное число и кодирует его, используя одновременно два ключа - открытый ключ и ключ сервера. Обе стороны используют этот случайный номер как ключ сессии, который используется для кодирования всех передаваемых во время сессии данных.
Затем клиент пытается аутентифицировать себя, используя.rhosts-аутентифи-кацию, аутентификацию RSA или же аутентификацию с использованием пароля.
Обычно.rhosts-аутентификация небезопасна и поэтому она отключена.
Протокол SSH версия 2
Версия 2 работает аналогично: каждый узел имеет определенный DSA-ключ, который используется для идентификации узла. Однако, при запуске демона ключ сервера не генерируется. Безопасность соединения обеспечивается благодаря соглашению Диффи-Хелмана (Diffie-Hellman key agreement).
Сессия может кодироваться следующими методами: 128-разрядный AES, Blowfish, 3DES, CAST128, Arcfour, 192-разрядный AES или 256-разрядный AES.
Опции демона sshd указаны в табл. 8.6.
Опции демона sshd Таблица 8.6
| Опция | Описание |
|---|---|
| -b биты | Определяет число битов для ключа сервера (по умолчанию 768). Данную опцию можно использовать, только если вы используете протокол SSH версии 1 |
| -d | Режим отладки (DEBUG). В этом режиме сервер не переходит в фоновый режим и подробно протоколирует свои действия в системном журнале. Использование данной опции особенно полезно при изучении работы сервера |
| -е | Если указана это опция, демон sshd отправляет отладочные сообщения не в системный журнал, а на стандартный поток ошибок |
| -f конфиг_файл | Задает альтернативный файл конфигурации. По умолчанию используется /etc/ssh/sshd_config |
| -g время | Предоставляет клиенту, не прошедшему аутентификацию, дополнительное время, чтобы аутентифицировать себя. По умолчанию время равно 600 секундам. Если за это время клиент не смог аутентифицировать себя, соединение будет прекращено. Значение 0 интерпретируется как бесконечное ожидание |
| -h | файл_ключа Задает альтернативный файл открытого ключа (ключ узла). По умолчанию используется файл /etc/ssh/ssh_host_key. Эта опция может понадобиться, чтобы sshd мог выполняться не только от имени суперпользователя root. Кроме этого, частым использованием этой опции является запуск sshd из сценариев, задающих различные настройки в зависимости от времени суток. Например, в дневное (рабочее) время устанавливаются одни опции, а в вечернее(иерабочее) время - другие |
| -i | Используется, если нужно запускать sshd через суперсервер xinetd (inetd). Обычно демон sshd не запускается суперсервером xinetd (inetd), а запускается при загрузке системы, потому что демону sshd требуется некоторое время (10 секунд) для генерирования ключа сервера, прежде чем он сможет ответить на запросы клиентов |
| -k время | Задает время, спустя которое ключ сервера будет создан заново. По умолчанию время составляет 3600 секунд (1 час). Данную опцию можно использовать, только если вы используете протокол SSH версии 1 |
| -р порт | Указывает альтернативный порт, который демон sshd будет прослушивать. По умолчанию используется порт 22 |
| -q «Тихий режим». | В данном режиме протоколирование сессии производиться не будет. Обычно протоколируется начало аутентификации, результат аутентификации и время окончания сессии |
| -t | Тестовый режим. Данный режим применяется для проверки корректности файла конфигурации |
| -D | При использовании этой опции демон не будет переходить в фоновый режим |
| -4 | Разрешается использовать IP-адреса только в формате IPv4 |
| -6 | Разрешается использовать IP-адреса только в формате IPv6 |
Файл конфигурации демона /etc/ssh/sshd_config выглядит примерно так, как это показано в листинге 8.7
Листинг 8.7 Файл конфигурации /etc/ssh/sshd_config
# $OpenBSD: sshd_config,v 1.38 2001/04/15 21:41:29 deraadt Exp $
# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin
# This is the sshd server system-wide configuration file. See sshd(8)
# for more information.
Port 22
# Protocol 2,1
# ListenAddress 0.0.0.0
# ListenAddress::
HostKey /etc/ssh/ssh_host_key
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
ServerKeyBits 768
LoginGraceTime 600
KeyRegenerationInterval 3600
PermitRootLogin yes
#
# Don"t read ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# Uncomment if you don"t trust ~/.ssh/known_hosts for
RhostsRSAAuthentication
# IgnoreUserKnownHosts yes
StrictModes yes
X11Forwarding yes
X11DisplayOffset 10
PrintMotd yes
# PrintLastLog no
KeepAlive yes
# Logging
SyslogFacility AUTHPRIV
LogLevel INFO
# obsoletes QuietMode and FascistLogging
RhostsAuthentication no
#
# For this to work you will also need host keys in /etc/ssh/
ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
#
RSAAuthentication yes
# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication yes
PermitEmptyPasswords no
# Uncomment to disable s/key passwords
# ChallengeResponseAuthentication no
# Uncomment to enable РАМ keyboard-interactive authentication
# Warning: enabling this may bypass the setting of "PasswordAuthentication"
# PAMAuthenticationViaKbdInt yes
# To change Kerberos options
# KerberosAuthentication no
# KerberosOrLocalPasswd yes
# AFSTokenPassing no
# KerberosTicketCleanup no
# Kerberos TGT Passing does only work with the AFS kaserver
# KerberosTgtPassing yes
# CheckMail yes
# UseLogin no
# MaxStartups 10:30:60
# Banner /etc/issue.net
# ReverseMappingCheck yes
Subsystem sftp/usr/libexec/openssh/sftp-server
SSH (Secure Shell) - это сетевой протокол удаленного доступа, использующий шифрование и сжатие для передаваемых данных. Проще говоря - это весьма полезный и мощный инструмент, позволяющий аутентифицироваться в системе и полноценно работать от имени локального пользователя, находясь за много километров от работающей машины. Также, в отличие от telnet и rsh - SSH шифрует весь трафик, так что вся переданная информация остается конфиденциальной.
Итак, ssh у нас уже установлен и ssh-daemon добавлен в автозагрузку при старте системы. Управлять им можно по команде:
service ssh stop|start|restart
В Ubuntu, или:
/etc/init.d/ssh {start|stop|reload|force-reload|restart|status}
В Debian, или:
systemctl start|stop|restart sshd.service
В ArchLinux (после каждой правки конфига нужно делать рестарт). В комплект входит клиент и сервер.
Опробуем в деле! Для начала создайте папку ~/.ssh
mkdir ~/.ssh
Сгенерируйте ключи для данного пользователя сервера командой:
ssh-keygen (от имени обычного пользователя).
При генерации, вы можете задать парольную фразу для ключа (желательно задать, и длинную - тогда даже заполучив ключ но не зная пароль от ключа, злоумышленник не сможет залогинится), а можете пропустить, просто нажав "Enter" - в таком случае, пароль никогда не спросится. В папке ~/.ssh появились те самые публичный и закрытый ключ.
Найдите ещё одну машину (даже смартфон подойдет - на Android есть несколько замечательных SSH-клиентов, вроде ConnectBot или JuiceSSH), установите на ней ssh и подключитесь к серверу командой:
ssh user@server
Если всё сделано правильно, будет запрошен пароль пользователя, и после ввода вы окажетесь в своей системе с видом из командной строки.
Для Windows, к слову, также есть сервера и клиенты ssh.
Насладившись результатом трудов своих, приступим к ещё более скучной части - настройке клиента/сервера.
Конфиг клиентской части лежит в /etc/ssh/ssh_config , а серверной - /etc/ssh/sshd_config . Наиболее полным руководством по настройке является, пожалуй, страница в man - man ssh и man sshd_config, так что рекомендуем прочититать её. А в данной статье рассмотрим наиболее необходимые вещи.
Настройка
Стандартный порт ssh - 22. Его можно сменить на любой нестандартный (усложняя возможный взлом благодаря безопасности через неясность, или же для привлечения внимания потенциальных взломщиков:) - для этого расскомментируйте строчку:
#Port 22
И добавьте любой желаемый до 65535 (убедившись, что порт не конфликтует с другими сервисами командой #netstat -tupln | grep LISTEN ).
Теперь при подключении к серверу, клиенту потребуется писать с ключом:
ssh -p [порт] :
По умолчанию доступ от имени root разрешен. Крайне желательно ограничить его (и вместо этого правильно разграничить права локального пользователя с помощью sudo). Для этого найдите строчку "PermitRootLogin" и смените значение на "no". Можно также сменить на "without-password" - в таком случае, логин под рутом будет разрешен только из под машин с доверенным ключом.
Можно отключить аутентификацию по паролю и работать только с ключами - найдите строчку: "PasswordAuthentication" и смените значение на "no". Зачем? Если кто-то очень захочет получить доступ к вашей системе, то он сможет либо перебрать пароль при попытках авторизации, либо прослушать и расшифровать ваше соединение. Если отключить аутентификацию по паролю и добавить в ~/.ssh/authorized_keys на сервере публичный ключ своего, например, рабочего ноутбука, то, как мы помним, нас пустит на сервер сразу. Но как быть, если вы работаете на чужой машине и срочно нужно получить доступ на ssh-сервер, а он нас ожидаемо не пускает? Тогда можно не отключать парольную аутентификацию, а воспользоваться утилитой fail2ban. Просто установите её из вашего репозитория, после чего она применит настройки по умолчанию и, как минимум, защитит ваш ssh-канал от взлома методом перебора. Подробнее о fail2ban - http://putty.org.ru/articles/fail2ban-ssh.html.
На тот случай, если на вашем сервере хранятся ключи запуска ядерных ракет, то можно сделать как-то так:
PermitRootLogin no - запрещен логин под рутом.
PasswordAuthentication no - вход без пароля
Сгенерируем на удаленной машине длинный ключ (-t тип_шифрования, -b битовая длина):
ssh-keygen -t rsa -b 4096
С не менее сложной парольной фразой (восстановить забытый пароль, к слову, нельзя. Можно сменить его командой "ssh-keygen -p", но с вас в любом случае спросят старый). Перенесем публичный ключ удаленной локальной машины в ~/.ssh/authorized_keys сервера, и вуаля - теперь доступ можно получить с единственной машины, с помощью парольной фразы зыкрытого ключа. SSH позволяет настроить множество конфигураций безопасности и имеет для этого множество специфичных настроек - о них читайте в man.
Этим же целям служат два параметра sshd_config:
LoginGraceTime - задает время, по истечении которого будет разорвано соединение, если не произойдет аутентификация.
MaxAuthTries - задает количество неверных попыток ввода логина, по достижении которого соединение будет разорвано.
MaxSessions - количество одновременных сессий (если сервер - ваш домашний компьютер, к которому вы собираетесь подключаться из универа или с работы, то разумно будет ограничить число сессий до одной - отклоненный логин, в таком случае, станет поводом для повышения паранойи, генерации новых ключей и смены пароля). Впрочем, если вы внимательны, то могли заметить, что при каждом логине на сервер высвечивается строчка "Last Login". Помимо неё, можно добавить собственное приветственное сообщение - найдите строчку "Banner" и вместо none задайте путь к файлу с текстом, который будет прочитан и выведен при логине.
Помимо прочего, можно разрешить вход в систему только определенным пользователям, или разрешить всем, помимо определенных пользователей:
AllowUsers user1 - разрешить вход только user1.
DenyUsers user1 - разрешить всем, кроме user1.
И аналогичные параметры для доступа определенных групп - AllowGroups и DenyGroups.
Также по SSH можно передавать сеанс X11. Для этого найдите строчку "ForwardX11" и измените значение на "yes".
Аналогичную строку найдите в конфиге клиента - /etc/ssh/ssh_config, и также смените на "yes".
Теперь присоединяться к серверу по ssh нужно с аргументом -X:
ssh -X user@server>
Можно сразу запуcтить приложение при коннекте:
ssh -X user@server "приложение"
Вот так выглядит работающий GIMP в ssh-сессии:
Или можно получить вывод с веб-камеры ноутбука ничего не подозревающего пользователя:)
Вычисления производятся непосредственно на сервере, а вывод передается на клиентскую машину (то есть, даже если на самом сервере не стоят X11, графические приложения можно отрисовывать на вашей удаленной машине). Работает такая схема довольно медленно (не забываем, что весь трафик динамически шифруется) - но функция эта весьма полезна.
По SSH-сессии можно также копировать файлы - для этого есть простенькая утилита "scp". Передавать файлы можно прямо в сессии как с сервера на клиент:
scp user@server:/путь/к/файлу/на/сервере /куда/сохранить/на/локальной/машине
Так и с клиента на сервер:
scp путь/к/файлу/клиента user@server:/путь/на/сервере
Это достаточно удобно, если нужно скопировать текстовик или фотографию, но как быть, когда предстоит работа с многими файлами? Для этого существует удобнейшая вещь - sshfs (доступна для установки в репозиториях большинства *nix-систем).
Просто задайте путь аналогично scp:
sshfs user@server:/home/user /mnt/
И папка /home/user сервера появится в точке монтирования /mnt локальной машины!
Отмонтирование производится через umount.
И, напоследок, расскажем об одной малоизвестной фиче. Если создать файл /.ssh/config и заполнить его подобным образом:
Host [имя]
Hostname
User [имя пользователя сервера]
желаемые опции
вроде
ForwardX11 yes
Port 30000
То можно будем логиниться по:
ssh [имя]
ssh -X -p 30000 user@server
И все опции подхватятся автоматически. Таким образом, при частой аутентификации на определенном сервере, вы упростите этот процесс к делу пары мгновений.
Что ж, мы рассмотрели всё (и даже больше) что нужно знать об SSH, для его бытового использования - научились пользоваться аутентификацией по ключу, защитили сервер от взлома перебором и в целом, наложили заплатки на большинство потенциальных дыр. На самом деле, SSH может ещё много разных штук - например, туннелирование и проброс портов через ssh-сессию, но вряд ли вы, как самый обычный пользователь, когда-либо этим воспользуетесь. Дополнительные ресурсы
Загрузка...
