Протокол SSH, основное применение и отличие от Telnet. Безопасный сетевой протокол SSH, основное

SSH (Secure Shell - Защищенная оболочка ) -- это сетевой протокол, обеспечивающий защищенную аутентификацию, соединение и безопасную передачу данных между хостами сети, путем шифрования, проходящего через него трафика, с возможной компрессией данных. Еще одной важной функциональной особенностью, является возможность создания защищенных, шифрованных туннелей, для безопасной передачи через небезопасную среду (например интернет), других сетевых протоколов, так-же с возможность сжатия трафика. Кроме того протокол SSH отлично работает с форвардингом (переадресация, перенаправление) портов одной машины на порты другой в том числе и форвардинг удаленных клиентов XWindow . Сейчас протокол SSH , является стандартом, и широко используется, например, для серверных систем, то есть выполнения различных команд и манипуляций в оболочке сервера через безопасное соединение, копирования файлов через сеть, вроде резервных копий данных.

Протокол SSH , существует в двух вариантах, коммерческая версия, разрабатываемая SSH inc, и бесплатная, с открытым исходным кодом, OpenSSH , которая в основном и используется на большинстве серверных платформ. Реализация OpenSSH , есть в любой операционной системе семейства Unix, и в большинстве из них, SSH сервер и SSH клиент, являются стандартными утилитами. Все ниже написанное будет касаться OpenSSH и операционной системы FreeBSD. Существуют две версии протокола SSH , не совместимые между собой. Первая реализация протокола SSH , SSH - 1 , была разработана в 1995 году. Вторая версия, SSH - 2 , выпущена в 1996 году. В 2006 году, протокол SSH был принят ассоциацией IETF в качестве интернет стандарта. Сейчас повсеместно используется именно вторая версия протокола SSH , поскольку во-первых, протокол SSH версии 1, страдал серьезными уязвимостями, во вторых в версия 2 использует более мощные алгоритмы шифрования, кроме того поддерживает возможность обнаружения умышленного искажения данных. Алгоритмы шифрования:

Протокол SSH, версии 1 DES, 3DES, blowfish
Протокол SSH, версии 2 AES-128, AES-192, AES-256, blowfish, CAST-128, ArcFour

Функция дайджеста:

Протокол SSH, версии 1 нет
Протокол SSH, версии 2 HMAC-MD5, HMAC-SHA-1, HMAC-RIPEMD

Как видите, разница очень велика, так что, протокол SSH версии 1 , сейчас вообще, строго не рекомендуется к применению где-либо.

Способы аутентификации по протоколу SSH, состав программного пакета OpenSSH

Безопасность протокола SSH обеспечивается следующими программными решениями:

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

Протокол SSH поддерживает довольно разнообразные методы аутентификации и авторизации удаленных клиентов на SSH сервере, вот некоторые из них:

GSSAPI-based аутентификация
Host-based аутентификация;
Аутентификация пользователя с помощью публичного ключа;
Аутентификация "вызов-ответ" (challenge-response );
Ну и наконец обычная аутентификация пользователя, по паролю;

Методы аутентификации, используются именно в этом порядке, однако у протокола версии 2 есть опция, PreferredAuthentications , позволяющая изменить порядок, установленный по-умолчанию. В добавок SSH поддерживает дополнительные методы аутентификации пользователя, в зависимости от конкретной операционной системы (например bsd_auth или PAM) В общем случае, аутентификация пользователя происходит на основе открытых ключей. Клиент, пытающийся установить удаленное SSH соединение, шифрует данные, известным ему открытым серверным ключом, который он получает при первом подключении к серверу, и передает их на SSH сервер. Сервер в свою очередь расшифровывает данные, только ему известным, секретным ключом, и отсылает их клиенту. В такой схеме, клиент может быть уверен, что сервер является именно тем, за кого себя выдает. Таким образом, можно не полагаться на DNS и маршрутизацию, даже если злоумышленнику удалось подделать запись DNS или перенаправить пакеты на свой хост, аутентификация не будет пройдена, так как посторонние хосты не обладают необходимыми для этого ключами. Так как SSH это полноценный сетевой протокол, естественно это и определенный набор программ, необходимых для его работы, как базовой функциональности, так и различных дополнительных возможностей. Поскольку речь у нас идет об операционной системе FreeBSD (в других версиях Unix, набор может несколько отличаться), то основными компонентами SSH , являются:

sshd - это собственно SSH сервер, программа-демон;
ssh - программа-клиент, ставшая заменой для rlogin и telnet ;
scp - программа для удаленного копирования через протокол SSH , замена для rcp ;
sftp - безопасный ftp-клиент;
sftp-server - подсистема обеспечивающая передачу файлов через протоколу SSH ;
ssh-keygen - генератор ключей
ssh-keyscan - "сборщик" публичных ключей хостов;
ssh-agent - агент аутентификации, для удержания приватных ключей;
ssh-add - небольшая программа для добавления ключей в ssh-agent ;

Как было сказано выше, sshd , это программа, отвечающая за серверную функциональность SSH , запускается она при загрузке операционной системы. Что-бы использовать протокол SSH сразу после установки FreeBSD, нужно разрешить запуск демона sshd в программе инсталляции Sysinstall . Хотя это можно сделать и позже, при условии что у вас есть доступ к терминалу сервера. Разрешить запуск демона sshd , можно через стартовый скрипт /etc/rc.conf, прописав следующую строку: Естественно этого можно и не делать, а просто запустить демон с консоли /usr/sbin/sshd , но при следующей перезагрузке, он сам по себе не запустится, соответственно доступа к серверу по протоколу SSH у вас не будет, ну а если сервер стоит в дата-центре хостинг провайдера, то и удаленно администрировать его, вы не сможете. По этой причине, если предполагается удаленное администрирование сервера, sshd включается на этапе установки.

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

SSH
Название	Secure Shell
Уровень (по модели OSI)	Прикладной
Семейство	TCP/IP
Порт/ID	22/TCP
Назначение протокола	Удалённый доступ
Спецификация	RFC 4251
Основные реализации (клиенты)	Аутентификация по паролю наиболее распространена. При каждом подключении подобно https вырабатывается общий секретный ключ для шифрования трафика. При аутентификации по ключевой паре предварительно генерируется пара открытого и закрытого ключей для определённого пользователя. На машине, с которой требуется произвести подключение, хранится закрытый ключ, а на удалённой машине - открытый. Эти файлы не передаются при аутентификации, система лишь проверяет, что владелец открытого ключа также владеет и закрытым. При данном подходе, как правило, настраивается автоматический вход от имени конкретного пользователя в ОС . Аутентификация по ip-адресу небезопасна, эту возможность чаще всего отключают. Для создания общего секрета (сеансового ключа) используется алгоритм Диффи - Хеллмана (DH). Для шифрования передаваемых данных используется симметричное шифрование , алгоритмы AES , Blowfish или 3DES . Целостность передачи данных проверяется с помощью CRC32 в SSH1 или HMAC -SHA1 /HMAC -MD5 в SSH2. Для сжатия шифруемых данных может использоваться алгоритм LempelZiv (LZ77), который обеспечивает такой же уровень сжатия, что и архиватор ZIP . Сжатие SSH включается лишь по запросу клиента, и на практике используется редко. Стандарты и программные реализации Первая версия протокола, SSH-1, была разработана в 1995 году исследователем Тату Улёненом из Технологического университета Хельсинки (Финляндия). SSH-1 был написан для обеспечения большей конфиденциальности, чем протоколы rlogin, telnet и rsh. В 1996 году была разработана более безопасная версия протокола, SSH-2, несовместимая с SSH-1. Протокол приобрел ещё большую популярность, и к 2000 году у него было около двух миллионов пользователей. В настоящее время под термином «SSH» обычно подразумевается именно SSH-2, так как первая версия протокола ввиду существенных недостатков сейчас практически не применяется. Для использования SSH в Python существуют такие модули, как python-paramiko и python-twisted-conch. SSH-туннелирование SSH-туннель - это туннель, создаваемый посредством SSH-соединения и используемый для шифрования туннелированных данных. Используется для того, чтобы обезопасить передачу данных в Интернете (аналогичное назначение имеет IPsec). При пересылке через SSH-туннель незашифрованный трафик любого протокола шифруется на одном конце SSH-соединения и расшифровывается на другом. Практическая реализация может выполняться несколькими способами: Созданием Socks-прокси для приложений, которые не умеют работать через SSH-туннель, но могут работать через Socks-прокси Использованием приложений, умеющих работать через SSH-туннель. Созданием VPN -туннеля, подходит практически для любых приложений. Если приложение работает с одним определённым сервером, можно настроить SSH-клиент таким образом, чтобы он пропускал через SSH-туннель TCP -соединения, приходящие на определённый TCP-порт машины, на которой запущен SSH-клиент. Например, клиенты Jabber подключаются по умолчанию на порт 443. Тогда, чтобы настроить подключение к серверу Jabber через SSH-туннель, SSH-клиент настраивается на перенаправление подключений с любого порта локальной машины (например, с порта 4430) на удалённый сервер (например, jabber.example.com и порт 443): $ ssh -L 4430 :jabber.example.com:443 somehost В данном случае Jabber-клиент настраивается на подключение к порту 4430 сервера localhost (если ssh-клиент запущен на той же машине что и Jabber-клиент). Для создания ssh-туннеля необходима машина с запущенным ssh-сервером и доступом к jabber.example.com. Такая конфигурация может использоваться в случае, если с локальной машины доступ к jabber.example.com закрыт файерволом, но есть доступ к некоторому ssh-серверу, у которого ограничения доступа в Интернет отсутствуют.

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-сессию, но вряд ли вы, как самый обычный пользователь, когда-либо этим воспользуетесь. Дополнительные ресурсы

Введение

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

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

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

Всякий, кто знаком с UNIX понимает, что почти любая сетевая программа может быть использована и как клиент и как сервер. В первом случае вы услугами пользуетесь, во втором - предоставляете их. Ясно, что в сетевом сервисе необходимы обе части. Вопрос в том, какие серверные программы нужны на сервере вашей сети. Устанавливая Linux, вы можете конечно выбрать хоть все, так как установка на диск еще не подразумевает запуска. Но какие из них потом активировать? Есть простой рецепт, которого я сам всегда придерживаюсь в работе с серверами, - чем меньше активированных серверов, тем лучше (если говорить в более общем плане: чем сложнее вещь, тем проще ее сломать). Сколько бы не твердили о надежности UNIX, здесь регулярно обнаруживаются и заделываются дыры. Поэтому чем меньше программ вы запустите, тем меньше за ними нужно будет следить. В реальной жизни это, разумеется, не должно сводиться к тому, что вы запрещаете пользователям буквально все. Это, конечно, безопасно, но зачем тогда вообще администратор? Однако ненужные вещи, типа wais, уж точно ставить не следует.

Telnet и ssh

А теперь более конкретно рассмотрим, что реально нужно и внутренним и внешним пользователям. Нужны telnet и ssh (secure shell). Может, это и не очень удобный доступ, но он необходим, по крайней мере администраторам. Это программа, обеспечивающая доступ в терминальном режиме, когда у вас на компьютере появляется окно 80x25 символов, полностью отражающее вызываемый сервер. Вы можете выполнять любые команды и запускать программы, не использующие графику, - в общем, это обычный удаленный терминал. Отличие telnet от ssh следует из названий, но все же поясним: telnet передает информацию незащищенной, даже пароль передается по сети открытым текстом, а ssh шифрует всю передаваемую информацию. Если вы хотите быть более-менее уверены в защите, то запретите использование telnet или вообще не запускайте его. Ну а если вы все же хотите использовать его, то, конечно, нужно применять firewall. Стандартные команды могут быть такие:

для ipfwadm -

Ipfwadm -I -a accept -P tcp -S 10.0.0.0/8 -D 0.0.0.0/0 23 ipfwadm -I -a accept -P tcp -S some.trusted.host -D 0.0.0.0/0 23 ipfwadm -I -a deny -P tcp -S 0.0.0.0/0 -D 0.0.0.0/0 23

для ipchains -

ipchains -A input -p all -j ACCEPT -s 10.0.0.0/8 -d 0.0.0.0/0 23

Ipchains -A input -p all -j ACCEPT -s some.trusted.host -d 0.0.0.0/0 23 ipchains -A input -p all -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 23

Можно также использовать файлы /etc/hosts.allow и /etc/hosts.deny, для чего следует прописать, соответственно:

в первом файле -

In.telnetd: 10.0.0.0/255.0.0.0, some.trusted.host

во втором файле -

In.telnetd: ALL

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

Еще два важных файла, информация которых связана с безопасностью системы, - /etc/securetty и /etc/shells. Первый задает терминалы, с которых может входить пользователь root. В большинстве систем по умолчанию пользователь root может входить только с консоли. Второй файл задает список допустимых программ-оболочек, которые могут запускаться при входе пользователя. Красивый пример, который я почерпнул из руководства по Linux, - использование passwd в качестве shell. Это обеспечивает пользователям легкую смену пароля, а также гарантирует, что они больше ничего не будут делать в терминальном режиме. Для этого в файл /etc/shells нужно занести саму программу passwd, то есть вписать строчку:

/usr/bin/passwd

а в файл /etc/passwd вписать про пользователя:

Username:x:1000:1000::/home/username:/usr/bin/passwd

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

Trying 1.2.3.4… Connected to localhost. Escape character is "^]". Red Hat Linux release 5.2 (Apollo) Kernel 2.2.5 on an i586 login: tester Password: Changing password for tester (current) UNIX password: New UNIX password: Retype new UNIX password: passwd: all authentication tokens updated successfully Connection closed by foreign host.

Даже если попытка поменять пароль была неудачной, произойдет отключение от системы. Следует обратить внимание и на стартовый вывод при подключении: telnet честно пишет имя системы и версию. Вообще, это удобно, но в таком случае вы даете потенциальному хакеру информацию, которую он может использовать в своих целях. Как этого избежать? При входе пользователя telnet отображает файл /etc/issue.net, создаваемый при старте системы. Он создается командами, стоящими в файле rc.local:

# This will overwrite /etc/issue at every boot. So, make any changes you # want to make to /etc/issue here or you will lose them when you reboot. echo "" > /etc/issue echo "$R" >> /etc/issue echo "Kernel $(uname -r) on $a $(uname -m)" >> /etc/issue cp -f /etc/issue /etc/issue.net echo >> /etc/issue

Поэтому, если вы не перегружаете систему, можно просто отредактировать файл /etc/issue.net, иначе - отредактировать сам rc.local. В любом случае, использовать telnet рекомендуется только тогда, когда это действительно необходимо и он не может быть заменен ssh.

Программа ssh с точки зрения пользователя аналогична telnet. В отличие от telnet, использующего 23-й порт, она использует 22-й, но основное внутреннее отличие состоит в том, что весь трафик кодирован. Во всем же остальном они схожи. Для ssh можно использовать те же самые правила firewall (с заменой номера порта) и установки в файлах /etc/hosts.allow, /etc/hosts.deny. Приятной особенностью является наличие собственного конфигурационного файла /etc/sshd/sshd_config, содержащего следующие конфигурационные строки:

Port 22 # номер порта, который может быть не только 22 ListenAddress 0.0.0.0 # какие адреса обслуживает демон HostKey /etc/ssh/ssh_host_key # файл кодов клиентов RandomSeed /etc/ssh/ssh_random_seed # файл случайных чисел, используемых при генерации кодов ServerKeyBits 768 # длина кода в битах LoginGraceTime 300 # время ввода имени и пароля KeyRegenerationInterval 3600 # частота регенерации кодов PermitRootLogin no # может или нет пользователь root входить через ssh IgnoreRhosts yes # игнорировать или нет информацию из файла пользователя.rhosts StrictModes yes # строгий режим, блокирующий пользовательские огрехи, например ввод пароля 5 раз # или случайное нажатие enter QuietMode no # yes - чтобы не писать log-файл вообще и no - в противном случае X11Forwarding no # передавать информацию X-сервера по ssh-каналу FascistLogging no # степень полноты log-файлов PrintMotd yes # выдавать на экран некоторую фразу дня KeepAlive yes # поддерживать связь, обеспечивая стандартное разъединение SyslogFacility DAEMON # кто отвечает за создание log-файлов RhostsAuthentication no # допускать проверку пользователя через rhosts RhostsRSAAuthentication no # достаточна или нет проверка через rhosts или /etc/hosts.equiv # по умолчанию это установлено в yes RSAAuthentication yes # использовать только проверку RSA PasswordAuthentication yes # использовать пользователям свои обычные пароли или нет PermitEmptyPasswords no # допускать пользователей без пароля или нет

Также есть некоторые полезные установки, в частности:

AllowGroups, DenyGroups, AllowUsers, DenyUsers, AllowHosts, DenyHosts, IdleTimeout time (время, по истечении которого связь будет прервана в случае неактивности).

Как следует из вышесказанного, в целом у ssh такое количество настроек, что вы можете точно прописать, кто и как может входить в систему. Но это касается сервера, а пользователи сети должны запускать ssh-клиенты. В отличие от telnet, который есть в Windows, ssh в стандартной поставке отсутствует. В Linux этой проблемы нет - клиент там тоже есть. Важно отметить, что ssh-демон имеется и в первой и во второй версиях. Неприятно, конечно, что нет обратной совместимости, но я уверен, что вы как администратор будете снабжать пользователей теми клиентами, которые смогут общаться с сервером. Вот некоторые ssh-клиенты для Windows:

Fresh Free FiSSH. http://www.massconfusion.com/ssh/
Tera Term. http://hp.vector.co.jp/authors/VA002416/teraterm.html telnet-клиент. http://www.zip.com.au/~roca/ttssh.html - дополнительная dll для поддержки ssh
Putty. http://www.chiark.greenend.org.uk/~sgtatham/putty.html - всего около 200K
Mindterm http://www.mindbright.se/mindterm/ - Java ssh-клиент
The Java Telnet Application. http://www.mud.de/se/jta/ - есть поддержка ssh
Secure CRT. http://www.vandyke.com/ - коммерческий клиент

О терминальном доступе необходимо упомянуть и в связи с программами типа rlogin, rexec, rsh. Их использование лишено всякой защиты и иногда даже позволяет пользователям попадать с машины на машину без ввода пароля. Это хотя и удобно, однако с точки зрения безопасности - просто никуда не годится. Такие сервисы обычно запускаются по умолчанию. Чтобы отменить их, нужно отредактировать файл /etc/inetd.conf и перезапустить демон inetd. В целом telnet и ssh исчерпывают возможности терминального доступа к системе. Поэтому перейдем к другим серверным приложениям, полезным для пользователей.

Почта, или e-mail

Что нужно, чтобы у людей была почта, без которой общение людей зачастую уже и не мыслится? Довольно распространенный способ - поставить почтовый сервер, завести там ящик на каждого пользователя и настроить pop-демон, чтобы люди могли эту почту забирать. Но для того чтобы сервер мог принимать и отправлять письма, на нем необходимо установить почтовую программу типа sendmail, postfix или qmail, обрабатывающую почту на UNIX-машине. Традиционно с этой целью использовался sendmail. Сейчас он тоже применяется на большинстве машин, но две другие упомянутые программы являются его хорошими и даже усовершенствованными заменителями. Как обычно, основные проблемы связаны с защитой, однако последние версии sendmail (8.9.x) являются вполне устойчивыми.

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

Теперь о конфигурации. Основным является файл sendmail.cf, который может иметь (а может и не иметь) ссылки на другие файлы. Также анализируется файл access, где можно поместить такие адреса, с которых (или на которые) письма отправляться не будут. Например, записи:

10.0.0 RELAY spam.com REJECT

означают, что письма с адресов.spam.com не будут приниматься, а письма из внутренней сети могут приниматься и отправляться.

Другой полезный и используемый файл - aliases. В нем задается, какие имена будут интерпретироваться как имя заданного ящика. Например, если задать

Petrov: star

письма, приходящие Петрову по адресу petrov@host, будут направляться в ящик star@host, даже если кто-то не знает реального адреса. Это целесообразно, в частности, если вы хотите, чтобы письма приходили менеджеру, который хочет иметь почтовый ящик не с именем manager, а со своим собственным. Это означает, что менеджер будет давать свой адрес только тем, кому посчитает нужным, а на Web-странице будет висеть manager. Очевидно, что максимум удобства это принесет в случае смены менеджера. На один и тот же ящик можно перенаправить сколько угодно имен.

В файле virtusertable задается отображение одного адреса на другой, к примеру:

Star@host manager

Используя эти два файла (aliases и virtusertable), можно осуществить дублирование почты, что позволит сохранять всю поступающую почту. Весь фокус в том, что вначале просматривается файл virtusertable, а затем aliases. Если с последней записью в virtusertable в файл aliases вписать:

Manager: star, «/var/spool/mail2/star»

то почта, приходящая и на адрес manager, и на адрес star, будет записываться в нормальную директорию /var/spool/mail и в /var/spool/mail2.

Одно из основных отличий программы postfix от sendmail - модульность (которая присуща и qmail). В отличие от sendmail только маленькая часть кода, всего один модуль, запускается как root, а все остальные части запускаются по мере необходимости и имеют свои настройки. Вообще, конфигурационные файлы postfix обычно лежат в /etc/postfix. Файл manager.cf управляет работой различных модулей, задавая пользователей, под которыми они запускаются, и количество процессов. Файл main.cf является основным файлом конфигурации и задает основные параметры работы самой почты. Вот его примерный вид с пояснениями (точнее, те компоненты, которые скорее всего придется отредактировать):

# имя машины myhostname = mail.example.org # домен mydomain = example.org # от имени какого адреса вы отправляете письма myorigin = $mydomain # на каких интерфейсах работать программе inet_interfaces = all # файл виртуальных имен virtual_maps = hash:/etc/postfix/virtual # файл замен имен alias_maps = hash:/etc/postfix/aliases # директория, в которую нужно складывать почту, когда ее получает пользователь home_mailbox = Maildir/ # где хранить почту mail_spool_directory = /var/spool/mail # команда изъятия почты mailbox_command = /usr/sbin/scanmails # файл с указанием адресов, почта с которых и на которые должна проходить # беспрепятственно relay_domains = /etc/postfix/relaydomains # локальные машины mynetworks = 10.0.0.0/24, 127.0.0.0/8 # что выводить, если пользователи подсоединяются к 25-му порту smtpd_banner = $myhostname ESMTP $mail_name

Программу postfix можно получить по адресу http://www.postfix.org .

Теперь поговорим о протоколах POP и IMAP. Первый работает на 110-м порту, второй - на 143-м. В принципе, оба преследуют одну и ту же цель, но реализованы они по-разному. POP (post office protocol) - довольно старый и бедный протокол. Все, что он позволяет, это соединяться с сервером, получать почту и удалять ее из ящика на сервере. Протокол IMAP более продвинутый. Он позволяет управлять почтой прямо на сервере. Можно не скачивать всю почту, а забирать только заголовки писем, создавать каталоги на сервере и распределять почту по ним. С точки же зрения безопасности эти протоколы одинаковы, поэтому во избежание неприятностей желательно использовать firewall. Можно также поместить трафик этих протоколов внутрь ssh. Очень важно проверять почту на вирусы. Хотя в UNIX вирусы не страшны, но поскольку многие пользователи используют Windows, то разумно прогнать письма через программу-сканер, например AMAVIS. Проще всего это сделать (естественно, подразумевается, что программа AMAVIS уже установлена), если в postfix в строке конфигурации

Mailbox_command = /usr/bin/procmail

Mailbox_command = /usr/sbin/scanmails

Коротко о том, как пользователь получает и отправляет почту на рабочем месте. К счастью, все популярные программы являются POP- или IMAP-клиентами (я имею в виду, по крайней мере, Netscape и Outlook). Плюс к этому, если администратор дал возможность доступа к серверу по telnet или ssh, вы можете просматривать почту и работать с ней в терминальном режиме (забрать ее в этом случае труднее). Для этого нужно соединиться с сервером и запустить в терминале какую-нибудь почтовую программу, типа mail или pine. Последняя гораздо более удобная и представляет собой полноэкранную программу с меню, только в текстовом режиме.

Доступ к файлам и сетевая печать

В UNIX-системе имеются два стандартных средства - NFS и LPD. Первое позволяет создавать сетевые файловые системы, второе - печатать на принтере. Что же касается использования ресурсов UNIX-машины из Windows, то для этого более всего, как мне кажется, подходит Samba (SMB). Эта программа позволяет получать доступ к файлам, а также предоставляет возможность сетевой печати с Windows-машины через UNIX-сервер. Поскольку эта статья в основном посвящена безопасности серверов, необходимо отметить, что разделение ресурсов внутри сети не является опасным, разумеется, при нормальной настройке внешних правил firewall. Здесь могут возникать проблемы иного плана, связанные с тем, что не все должны иметь доступ к той или иной информации, но это целиком регулируется настройками атрибутов файлов и каталогов. Каким бы проницательным администратором вы бы ни были, вы не сможете предотвратить ситуацию, когда, например, кто-то забудет закрыть сеанс работы с ssh и отойдет от компьютера. Другое дело, если вы дадите доступ на чтение каких-то файлов, но это слишком очевидные вещи, чтобы на них специально останавливаться. Поэтому теперь мы перейдем к рассмотрению серверных приложений, которые полезны не только внутренним пользователям, но и внешним. Я имею в виду в первую очередь Web-сервер и, быть может, ftp. Без первого сейчас трудно представить самую маленькую компанию или даже просто сеть, а наличие второго зависит от того, есть ли у вас реальная потребность отдельно выложить некоторые данные на ftp-сервер.

Web- и ftp-серверы

Среди ныне существующих нескольких Web-серверов по популярности и работоспособности бесспорным лидером является Apache. Этот сервер сочетает в себе скорость, стабильность, высокую защищенность, и при этом он бесплатный. Не всегда удается для своих целей найти такую программу, но здесь она есть. И нужно признать, что авторы программы прилагают очень много усилий, чтобы добиться максимальной эффективности и надежности. Прежде всего отметим, что если вы используете Web-сервер только для внутренних целей, таких как администрирование системы или разделение файлов, то его обязательно следует оградить от внешнего мира правилами firewall. Если же это сервер для всех, то необходимо понимать, что он открыт всем. Именно поэтому необходимо должным образом следить за ним, а именно: внимательно и правильно его настроить и контролировать log-файлы, чтобы определить возможную атаку заранее. Что же касается безопасности, то сам сервер имеет весьма малый доступ к системе, поскольку запускается как root только его первая копия, а остальные обычно запускаются от имени nobody. Кроме того, в настройках сервера, то есть в файлах httpd.conf, smr.conf, access.conf, четко указывается, к каким директориям сервер доступ имеет, а к каким нет. Если в файле httpd.conf прописать, например:

Options None AllowOverride None Options Indexes FollowSymLinks Includes AllowOverride None

то вы явно укажете, что сервер имеет доступ только к директории /WWW, куда и нужно поместить весь материал сайта (или сайтов), чью работу обеспечивает сервер. Если вы хотите быть уверенным, что никто не изменит прав доступа, включив, например, в какую-либо директорию файл.htaccess, то в srm.conf следует вписать:

order allow,deny deny from all

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

Следует отдельно остановиться на использовании протокола https (secure http). Этот протокол обычно работает на 443-м порту (в отличие от стандартного http, работающего на 80-м). Существует по крайней мере два способа обогатить Apache такой возможностью, как secure http. Первый - воспользоваться дополнением от open-ssl, второй - использовать модуль mod_ssl. Оба варианта приводят к почти одинаковым результатам. В общем и целом - появляется возможность устанавливать соединения, используя https по 443-м порту. При этом для сервера создается сертификат, который будет проверяться клиентами при подключении. Это позволит исключить (разумеется, не с абсолютной гарантией) прослушивание трафика. Для создания сертификата при использовании openssl нужно дать команды:

Openssl genrsa -des3 > httpsd.key openssl req -new -key httpsd.key > httpsd.csr

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

# прослушивание 443-го порта (по умолчанию сервер слушает только 80-й) Listen 443 # запрещение глобального использования ssl SSLDisable # место, куда сервер будет складывать временную информацию при ssl-соединении. Без # этой установки сервер не будет работать SSLCacheServerPath /usr/bin/gcache # порт, через который сервер общается с CashServer SSLCacheServerPort 12345 # время ожидания CashServer SSLSessionCacheTimeout 300

После этих настроек ваш сервер в принципе готов к работе с https, но пока этот протокол запрещен. Целесообразно создать виртуальный хост, имеющий такое же имя, что и ваш стандартный, но с явным указанием 443-го порта, другими словами, сейчас у вас запущен Web-сервер. Он работает на 80-м порту и использует протокол http. Добавив apache-ssl и описанные выше настройки, вы дали пользователям возможность общаться с вашим сервером через протокол https. Вряд ли вся информация вашего сервера настолько засекречена, что вы хотите всю ее выдавать только в режиме защищенного соединения. Сервер Apache позволяет создавать виртуальные машины, то есть вы можете объявить какую-то поддиректорию корневой для некоторого хоста, дать ему имя, прописать набор конфигурационных файлов и все остальное, что необходимо, но физически он будет находиться на вашем компьютере и управляться будет вашем же сервером. В нашем случае даже не нужно давать другое имя, так как оно то же самое, только другой порт. Вот как могла бы выглядеть такая настройка:

DocumentRoot /www/secure/ ServerName www.example.com ServerAdmin [email protected] ErrorLog logs/https_error.log TransferLog logs/https_access.log # Разрешение ssl для этого виртуального хоста SSLEnable # Требование использовать только ssl SSLRequireSSL SSLCertificateFile /usr/conf/httpsd.crt SSLCertificateKeyFile /usr/conf/httpsd.key SSLVerifyClient none

Помимо http существует и ftp - полезный и удобный сервис, особенно если у вас много файлов, которые пользователи должны скачивать (к примеру, вы предоставляете данные каких-то исследований). Преимущество ftp перед http - это скорость. Протокол ftp имеет минимум служебной информации. Однако с ним и много проблем. Основная - его «возраст»: ftp так же стар, как и telnet. Отсюда сразу возникают сложности, связанные с безопасностью: имя пользователя и пароль передаются в открытом виде, а трафик передаваемой информации ничем не защищен. К тому же ftp умеет только передавать файлы. Поэтому если вы имеете некоторую информацию, которая доступна всем, то разумно создать одного пользователя, под чьим именем будут входить все. Часто в таких ftp-архивах этого пользователя зовут anonymous, а в качестве пароля он передает свой e-mail-адрес. В этом случае проблем с безопасностью уже гораздо меньше. Тем более в случае, когда нужно предоставить ftp-доступ нескольким пользователям, сделать chroot, чтобы они могли класть файлы только в свои директории. Что касается серверов, то, конечно, они имеются в стандартных поставках, но, быть может, вы захотите поставить не стандартный ftpd, а какой-либо иной.

Одним из популярных ftp-серверов является proftpd. Его конфигурационные файлы похожи на файлы Apache, что позволяет легче к ним адаптироваться, поскольку скорее всего ваш Web-сервер именно Apache. Основной файл конфигурации - /etc/proftpd.conf. Его примерный вид может быть таким:

ServerName "ProFTPD Default Installation" ServerType inetd DefaultServer on Port 21 Umask 022 MaxInstances 30 User nobody Group nobody AllowOverwrite on

В вышеприведенном листинге указано, что сервер запускается через inetd, на стандартном 21-м порту, максимальное число копий 30, а запускается он от имени группы и пользователя nobody. 022 - маска атрибутов файла при создании, которая будет стандартно накладываться изначально. Такая конфигурация не дает доступа пользователю anonymous. Чтобы сделать это, необходимо написать примерно следующие конфигурационные настройки:

User ftp Group ftp RequireValidShell off UserAlias anonymous ftp MaxClients 10 DisplayLogin welcome.msg DisplayFirstChdir .message DenyAll

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

AllowAll DenyAll

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

На этом я закончу тему серверных приложений. Безусловно, следует отметить, что серверных приложений гораздо больше: существует еще DNS, серверы новостей, серверы NIS, X-сервер и множество других интересных и полезных приложений. Однако я постарался сделать упор на том, что реально может понадобиться при работе сети, которая не претендует на роль глобального киберполиса или провайдера. Теперь перейдем к рассмотрению второго вопроса, означенного в начале статьи, - к сетевым атакам и взломам.

Сетевые атаки и взломы

Прежде всего - несколько общих слов. В UNIX, в отличие от Windows, нет проблемы с вирусами. Внутренняя структура распределения памяти и прав доступа к файлам в состоянии сама справиться с тем, что обычно творят вирусы в старом DOS или Windows. Основным барьером для вирусов (в стандартном их понимании) является отсутствие доступа к физическим устройствам для программ, запущенных от имени обычного пользователя, а также то, что атрибуты файлов ставятся не вообще, а для пользователя, группы и всех пользователей. Такого в Windows нет (отчасти это реализовано в Windows 2000). Хотя неприятности, вызываемые традиционными вирусами, почти исключены, UNIX-системы все равно взламывают и рушат. Это связано с наличием совсем других технологий, которые можно условно разделить на две категории. Первая - это так называемые троянские кони, которые представляют собой программы, с виду, а может и на самом деле, выполняющие вполне разумные и легальные действия. Однако параллельно они ведут другую «работу»: прослушивают сеть или собирают информацию о паролях и посылают ее в сеть и т.п. Сами эти программы вряд ли могут принести непосредственный вред - скорее они будут посредниками между вашей системой и внешним взломщиком. Вторая категория - сетевые взломы. Эти акции изначально не апеллируют к внутреннему содержанию машины, а стараются разрушить систему или получить доступ к ней, посылая ей некоторую информацию, наподобие заведомо неправильных сетевых пакетов, либо путем специально сформированных запросов пытаются «выманить» какие-то скрытые данные. Зачем вообще нужно взламывать системы? Это вопрос скорее психологический, чем практический. Дело в том, что реально довольно большая часть взломов машин происходит не из корыстных целей, а просто из интереса к самому процессу. Среди людей, которых принято называть хакерами, не только те, кто совершает взломы для какой-то реальной выгоды, но и «энтузиасты», совершающие взлом сети ради самого взлома. Это кажется неожиданным, но это так, и об этом свидетельствует статистика. Кроме того, человека зачастую довольно сложно обвинить в содеянном, так как порой бывает невозможно доказать, что именно он и именно с этого компьютера производил те или иные незаконные действия. Однако в данной статье мы обсуждаем сами взломы, а не их психологические и юридические аспекты, и потому перейдем к конкретным вещам.

Взлом сети, как бы аккуратно он ни проводился и какие бы способы ни применялись, неизбежно приводит к некоторым изменениям в системе. Это может быть появление нового списка прослушиваемых портов, появление незнакомых программ, изменение размеров существующих программ, особенно типа ps или netstat, или даже новых пользователей. Так или иначе, суть в том, что что-то должно поменяться, и это неизбежно. Поэтому первое разумное действие, которое я советую осуществить сразу после установки и конфигурации системы, - это создание файла с информацией о системе. Что-то типа фотографии на тот момент, когда вы считаете все происходящее правильным. Если же говорить еще конкретнее, я имею в виду информацию, которую выдают программы netstat, vmstat, free, du, df. Второй совет - создавать резервные копии конфигурационных файлов системы и изначальных настроек. Их сравнение между собой тоже может дать некоторую информацию о том, что произошло в системе за последнее время.

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

AIDE - программа, позволяющая создавать контрольные суммы для файлов, проверяя таким образом их целостность; позволяет использовать несколько алгоритмов. http://www.cs.tut.fi/~rammer/aide.html . (Остальные программы выполняют аналогичные функции, все они являются бесплатными.)
Gog&Magog - создает список атрибутов и владельцев файлов, позволяет автоматически делать сравнение. http://www.multimania.com/cparisel/gog/
Sentinel - создает контрольные суммы, используя алгоритм RIPEMD-160bit MAC, имеет графический интерфейс. http://zurk.netpedia.net/zfile.html
SuSEauditdisk - программа, помещаемая на дискету, что дает возможность производить проверку системы полностью автономно, загружаясь непосредственно с дискеты. Стандартно поставляется с SuSELinux. http://www.suse.de/~marc
ViperDB - проверяет владельцев файлов и атрибуты, создавая log-файлы, в которых записывает произошедшие изменения. У программы есть три параметра: -init - создает базы данных по файлам, -check - проверяет файлы по базе и вносит изменения в базу, если они произошли на диске, -checkstrict - проверяет файлы по базе и возвращает старые параметры, если произошли изменения. http://www.resentment.org/projects/viperdb
Sxid - создает контрольные суммы файлов и проверяет атрибуты и владельцев. ftp://marcus.seva.net/pub/sxid/
nannie - запоминает время создания файла. ftp://tools.tradeservices.com/pub/nannie/
confcollect - запоминает системную информацию, например установленного программного обеспечения, таблицы маршрутизатора и т.п. http://www.skagelund.com/confcollect/
Pikt - средство, содержащее внутренний язык скриптов для создания программ, выполняющих стандартные, но не реализованные в виде конкретных команд функции (наблюдение за почасовым использованием системы, ликвидация долгоживущих процессов, установка размера почтового ящика и т.д.). Существует для разных платформ: Solaris, Linux и FreeBSD. http://pikt.uchicago.edu/pikt/

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

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

DTK - эмулирует стандартные сервисы и программы, и в случае нестандартных запросов, направляемых этим программам, происходит выдача заведомо ложной информации с целью запутать взломщика. http://all.net/dtk/
Psionic PortSentry - отслеживает сканирование портов. Основная задача - проверять порты на сканирование и отображать все в log-файле. http://www.psionic.com/abacus/portsentry/
Psionic HostSentry - создает базу информации об использовании машины пользователями, выдавая сообщение при нестандартном использовании ресурсов. http://www.psionic.com/abacus/hostsentry/
Scanlogd - сканирует сетевые пакеты, создавая log-файлы в зависимости от настроек. http://www.openwall.com/scanlogd/
Firewalls - это собирательное название программ, выполняющих функции firewall.
TCP-WRAPPERS - программы, ограничивающие доступ к тем или иным ресурсам по имени либо номеру компьютера. Некоторые такие программы доступны по адресу. ftp://ftp.porcupine.org/pub/security/
NFR - программа, по построению аналогичная снифферу (sniffer - программа прослушивания сетевого трафика). Производит запись log-файлов и в режиме реального времени осуществляет детектирование атак и сканирования портов. http://www.nfr.com/
Подробный и полезный FAQ по сетевым атакам и их детектированию находится по адресу http://www.robertgraham.com/pubs/network-intrusion-detection.html .

Трудно однозначно ответить на вопрос, что и как следует делать при сетевых атаках. Здесь очень многое зависит от специфики как конкретной сети, так и той организации, в которой она находится. Даже при атаке одного и того же вида в одном случае вы захотите вначале спасти данные, а во втором - заблокировать источник атаки, то есть все зависит от приоритетов. Весьма сложную проблему атаки представляют в тех организациях, где остановка работы сети недопустима. Там вам придется проводить все операции online, по возможности сохраняя связь с внешним миром. Довольно много зависит и от характера атаки. Одно дело взлом ради взлома, а другое - целенаправленное похищение секретных данных. Может быть, правда, и более изощренный вариант, когда атака проводится с целью отвлечения администратора от более изощренного и продуманного взлома, проводимого параллельно. Но не думайте, что атака может прийти только снаружи. Она вполне может начаться изнутри. Вполне возможный сценарий - запуск троянского коня на Windows-компьютере внутренней сети. Очевидно, что такое можно сделать, просто послав письмо по почте. Теперь давайте чуть подробнее остановимся на программах-снифферах (sniffer).

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

Tcpdump - наиболее старая программа, поставляемая со всеми UNIX.
Sniffit - имеет возможности фильтрации пакетов и перевода информации в текстовый формат; снабжена графическим интерфейсом. http://sniffit.rug.ac.be/~coder/sniffit/sniffit.html
Ethereal - анализатор сетевых протоколов.
Snort - предназначена для слежения за сетью, может определять сканирование портов. http://www.clark.net/~roesch/security.html
SPY - сниффер, но не бесплатный. Существует бесплатная однопользовательская лицензия на сеть, состоящую не более чем из пяти машин. http://pweb.uunet.de/trillian.of/Spy/

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

AntiSniff - программа, сканирующая сеть на наличие снифферов. Принцип ее действия очень прост: она посылает запрос и по ответу и по времени ответа определяет, обрабатывается он какой-нибудь еще программой или нет. http://www.l0pht.com/antisniff/

Подробный и полезный FAQ по снифферам можно найти по адресу. http://www.robertgraham.com/pubs/sniffing-faq.html .

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

Программы, которые сканирует систему саму по себе изнутри:

Tiger - программа, до сих пор находящаяся в разработке. ftp://net.tamu.edu/pub/security/TAMU/
check.pl - Perl скрипт, проверяющий дерево каталогов и файлы в нем и указывающий на различные сомнительные атрибуты и имена владельцев. http://opop.nols.com/proggie.html

Программы сетевого сканирования, указывающие на легкодоступные сервисы на другой системе (неплохая проверка настроек firewall, например):

Strobe - старый, но быстрый и все еще эффективный сетевой сканер. Иногда включается в комплект поставки UNIX. ftp://suburbia.net/pub/
Nmap - программа, использующая новые методы сканирования портов и имеющая много настроек. Позволяет получать параметры операционной системы (название, версию). http://www.insecure.org/nmap/index.html
Portscanner - небольшой сканер портов, имеющий множество форматов выдачи обработанной информации. http://www.ameth.org/~veilleux/portscan.html
Queso - не совсем сканер; это программа, предназначенная для определения типа операционной системы на удаленном компьютере. http://www.apostols.org/projectz/queso/

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

Nessus - программа для отслеживания атак, основанная на принципе «клиент-сервер». Серверы есть для Linux, FreeBSD, NetBSD и Solaris, а клиенты для Linux и Windows. Помимо сканирования портов и отслеживания атак программа может производить поиск по DNS с целью нахождения компьютеров, связанных со взламываемой машиной. http://www.nessus.org/
Saint - потомок программы Satan, которая прежде была одной из самых популярных для сбора информации о машинах. Saint использует архитектуру «клиент-сервер», заменяя, правда, клиента Web-программой. Основная цель - сбор информации об уязвимых местах в защите системы. http://www.wwdsi.com/saint/
Cheops - программа, составляющая карту сетевого IP-окружения с указанием запущенной на компьютерах операционной системы. http://www.marko.net/cheops/
SARA (Security Auditor’s Research Assistant) - программа, аналогичная Saint. Может сканировать одновременно несколько машин, кроме того выдает результат работы в HTML-формате. http://home.arc.com/sara/
BASS (Bulk Auditing Security Scanner) - программа, идеология которой основана на том, что Интернет не защищен. Главная задача - сканирование систем на наличие в них «дыр» защиты. http://www.securityfocus.com/data/tools/network/bass-1.0.7.tar.gz

Программой сканирования firewall и проверки правильности его настройки, является Firewalk. С помощью посылки различных пакетов программа стремится вычислить правила, в соответствии с которыми работает firewall. http://www.packetfactory.net/firewalk/

В архиве по адресу http://www.rootshell.com/ собраны известные данные о погрешностях в защите систем и ссылки на дополнения от производителей операционных систем, которые эти погрешности устраняют. Правда, иногда вместо такой ссылки можно увидеть сообщение «Upgrade to the next version», что обидно, особенно если система коммерческая. Такое, например, часто бывает с IBM AIX.

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

КомпьютерПресс 3"2001

Административное принуждение и его отличие от других видов государственного принуждения система мер административного принуждения.

Адрес заведения, которое заполнило протокол ___________________________________________________

Акты, протоколы. Состав реквизитов акта и протокола. Расположение реквизитов на бланке А4. Требования к оформлению акта и протокола. Придание документу юридической силы.

Амнистия: понятие и признаки. Помилование: понятие, правовые последствия, отличие от амнистии.

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

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