mount –t fs_type device mount_point,
fs_type – параметр, указывающий тип подключаемой файловой системы (vfat, ntfs, ext 2, ext 3, iso 9660 – при монтировании CD - ROM);
device – устройство, являющееся носителем данных, например, /dev/hda;
mount _ point – точка монтирования.
Например, для монтирования дисковода А:
mount –t vfat /dev/fd0 /mnt/floppy
Для монтирования привода CD - ROM:
mount –t iso9660 /dev/hdd /mnt/cdrom
Команда mount при вызове с аргументами проверяет все аргументы, за исключением устройства, и вызывает специфический модуль монтирования для указанного типа файловой системы. При вызове без аргументов mount выдает список всех смонтированных файловых систем из соответствующей таблицы.
При вызове с неполным списком аргументов (например, только с указанием устройства или точки монтирования, или когда указаны оба эти аргумента, но не задан тип файловой системы), mount будет просматривать таблицу стандартных файловых систем (в файле /etc/fstab или /etc/vfstab, в зависимости от разновидности UNIX) в поисках недостающих аргументов. Затем она вызывает специфический модуль монтирования для соответствующего типа файловой системы.
Опции команды mount:
-а – монтирование всех файловых систем, указанных в файле /etc/fstab, кроме тех, для которых указан параметр noauto;
- r – монтирование в режиме только чтение;
- t тип ФС – задает тип файловой системы;
- o – задает специфические опции для указанного типа физической файловой системы.
Обратная процедура по отношению к монтированию называется демонтированием и выполняется командой umount с указанием точки монтирования.
Любой пользователь может вызывать команду mount для получения списка смонтированных файловых систем и ресурсов.
Таблица стандартных файловых систем (в файле /etc/fstab или /etc/vfstab, в зависимости от разновидности UNIX) описывает стандартные параметры для физических файловых систем, которые могут монтироваться автоматически при запуске системы. Поля в таблице (их 6) разделены пробелами и символами табуляции и представляют, соответственно:
Монтируемое Устройство Точка Монтирования Тип Файловой Системы Опции (через_запятые) Флаг Резервного Копирования Флаг Проверки.
В табл. 7 приведены основные опции, применяемые при монтировании физических файловых систем.
|
Таблица 7
|
Некоторые опции монтирования файловых систем
|
Опции
|
Описание
|
exec
|
Разрешает запуск бинарных (выполняемых) файлов для данной файловой системы. Эта опция установлена по умолчанию
|
noexec
|
Запрещает запуск бинарных (выполняемых) файлов для данной файловой системы
|
noauto
|
Запрещает автоматическое монтирование данной файловой системы при загрузке системы (при выполнении команды mount – a)
|
auto
|
Разрешает автоматическое монтирование данной файловой системы при загрузке системы.
|
ro
|
Монтирование в режиме «только чтение»
|
rw
|
Монтирование в режиме «чтение/запись». Эта опция установлена по умолчанию
|
user
|
Разрешает пользователям монтировать/демонтировать данную файловую систему
|
nouser
|
Запрещает пользователям монтировать/демонтировать данную файловую систему. Эта опция установлена по умолчанию
|
defaults
|
Использование стандартного набора опций, установленных по умолчанию
|
Для перекодирования русскоязычных наименований файлов необходимо установить опции iocharset = cp 1251 (или iocharset = koi 8- r), codepage =866
Пример записей в файле /etc/fstab:
/dev/hda 1/ext 3 defaults 0 1
/dev/hda 5/mnt/diskD ntfs auto, iocharset = cp 1251, codepage =866 0 0
/dev/fd 0/mnt/eloppy vfat noauto, iocharset = cp 1251, codepage =866 0 0
Если флаг резервного копирования установлен 1, то программа dump включит данную файловую систему в архив при создании резервной копии (дампа). Если установлен 0, то резервная копия данной файловой системы создаваться не будет.
Если флаг проверки установлен 1, то при монтировании эта файловая система будет проверяться на наличие ошибок в первую очередь (рекомендуется для корневой файловой системы). Если установлен 0, то проверка на наличие ошибок выполняться не будет (рекомендуется применять для съемных носителей). Для всех остальных файловых систем рекомендуется устанавливать значение 2.
В графическом интерфейсе монтирование сменных носителей выполняется автоматически, но перед их выемкой необходимо выполнить команду Извлечь (при помощи контекстного меню).
4.5. Сетевые средства UNIX
Операционная система UNIX почти с самого рождения интегрировала в себя технологии локальных сетей, на её основе затем была построена сеть Интернет, распространившаяся ныне по всему миру. Все UNIX-системы поддерживают стек протоколов TCP/IP.
На компьютере под управлением UNIX-системы могут устанавливаться как клиентские, так и серверные части всех известных сетевых служб. Наиболее распространенными являются:
WWW-сервер Apache (служба httpd).
FTP-сервер.
Поддержка сети Microsoft – пакет Samba (службы smb и winbind), который эмулирует работу файлового сервера Windows.
DHCP-сервер.
DNS-сервер.
Прокси-сервер.
Сервер баз данных MySQL.
Почтовый сервер, например, Sendmail.
Службы удаленного терминала на основе протоколов telnet и ssh.
Различные межсетевые экраны, например, iptables.
4.5.1. Сетевой интерфейс
Конфигурирование сетевого интерфейса рабочей станции можно выполнить уже на этапе инсталляции операционной системы, указав IP адрес, маску сети, шлюз по умолчанию и сервер DNS, либо разрешив получить эти данные автоматически от сервера DHCP.
Конфигурирование сетевого интерфейса после инсталляции системы можно выполнять как непосредственно в конфигурационных файлах, так и при помощи программ-конфигураторов, к числу которых относится консольный конфигуратор setup, а также различные графические конфигураторы из состава графических сред Gnome и KDE.
Сетевые параметры компьютера хранятся в следующих конфигурационных файлах:
IP адрес компьютера, маска сети, широковещательный адрес сети (BROADCAST) и шлюз по умолчанию (GATEWAY) в файлах /etc/sysconfig/network-scripts/ifcfg-ethN:M,
где N – номер физического сетевого интерфейса (сетевого адаптера); M – номер логического сетевого интерфейса;
например: ifcfg-eth0, ifcfg-eth1, ifcfg-eth0:0, ifcfg-eth0:1, и т. д., < (ifcfg-lo – сеть 127.0.0.0).
IP-адрес сервера DNS хранится в файлах /etc/resolv.conf и /etc/sysconfig/network.
Имя компьютера хранится в файле /etc/hosts.
При запуске системы запускается служба инициализации сети network, которая выполняет программу ifconfig с параметрами, представленными в конфигурационных файлах, размещенных в каталоге /etc/sysconfig/network-scripts/.
Изменения сетевого интерфейса вступают в силу после перезапуска службы network (после выполнения команды service network restart) или перезапуска всей системы (reboot).
Если запустить программу ifconfig (одноименной командой) без параметров, то будет выведена на экран текущая настройка сетевых интерфейсов в системе.
Доступность других компьютеров сети проверяется утилитой ping, трассирование маршрута выполняется утилитой traceroute.
Для просмотра всех существующих в настоящий момент сетевых соединений на транспортном уровне можно воспользоваться командой netstat.
Для проверки работы системы DNS используются утилиты dig и host.
Таблица маршрутизации доступна при помощи команды route. Примеры добавления новых маршрутов:
route add default gw 10.10.10.2 netmask 0.0.0.0 metric 1
route add net 10.10.10.0 netmask 255.255.255.0 eth 0
Следует заметить, что ключа – p, обеспечивающего сохранение постоянных маршрутов в таблице маршрутизации в ОС Windows, в UNIX нет, нужен специальный скрипт – загрузочный сценарий.
4.5.2. WWW-сервер Apache
Огромному числу абонентов сети Интернет предоставляется возможность просмотра WWW-документов по специальному протоколу HTTP (H yper T ext T ransfer P rotocol) при помощи клиентских программ-навигаторов (или браузеров, от англ. "browse", "просматривать").
Apache – это HTTP-сервер, обладающий самым большим набором возможностей. Учитывая организованный в нем механизм подключаемых модулей, создавать которые может любой грамотный программист, описать умения Apache полностью невозможно. Документация по одним только стандартным его возможностям занимает более 50 тысяч строк.
Запускается WWW-сервер Apache путем инициализации службы httpd. Конфигурационные файлы Apache хранятся в каталоге /etc/httpd/conf/ (или, в зависимости от дистрибутива, /etc/apache/). Главный конфигурационный файл – httpd.conf. Этот файл неплохо самодокументирован: вместе с комментариями в нем больше тысячи строк, что позволяет не изучать руководство, если администратор запамятовал синтаксис той или иной настройки, но, конечно, не позволяет вовсе не изучать его.
Например, пользователь, набравший в адресной строке браузера "http://доменное_имя_сервера", увидит содержимое каталога, указанного настройкой строки DocumentRoot в файле httpd.conf.
Конфигурирование сайтов пользователей, обслуживаемых WWW-сервером, выполняется в соответствующих секциях VirtualHost.
Каждый каталог, содержащий WWW-страницы, должен быть описан группой настроек, включающей права доступа к страницам этого каталога, настройки особенностей просмотра этих страниц и т. п.
В частности, настройка DirectoryIndex описывает, какие файлы в каталоге считаются индексными – если такой файл есть в каталоге, он будет показан вместо содержимого этого каталога. Если в настройке каталога Options не указано значение Indexes, просмотр каталога будет вообще невозможен. Значение Includes этой настройки позволяет WWW-страницам включать в себя текст из других файлов, FollowSymLinks позволяет серверу работать с каталогами и файлами, на которые указывают символьные ссылки (это может вывести точку доступа за пределы DocumentRoot), а MultiViews позволяет серверу для разных запросов на одну и ту же страницу выдавать содержимое различных файлов – сообразно языку, указанному в запросе.
Если настройку каталога AllowOverride установить в All, в любом его подкаталоге можно создать дополнительный конфигурационный файл, изменяющий общие свойства каталога. Имя этого файла задает настройка AccessFileName (в примере – ".htaccess"). Доступом к страницам в каталоге управляют настройки Order, Deny и Allow.
Важное свойство WWW-серверов – поддержка так называемых динамических WWW-страниц. Динамическая WWW-страница не хранится на диске в том виде, в котором ее получает пользователь. Она создается – возможно, на основании какого-то шаблона – непосредственно после запроса со стороны браузера. Никаких особенных расширений протокола HTTP при этом можно не вводить – просто сервер получает запрос на WWW-страницу, которой не соответствует ни один файл. Зато HTTP-адрес (точнее говоря, URL) этой страницы распознается сервером как динамический и передается на обработку выделенной для этого программе. Программа генерирует текст в формате HTML, который и передается пользователю в качестве запрошенной страницы. Часто для этого используется каталог /var/www/cgi-bin.
Как и многие другие прикладные протоколы, HTTP был и остается текстовым. При желании можно выучить команды HTTP и получать странички с серверов с помощью telnet вручную. Это означает, что любая система идентификации, основанная на одном только HTTP, будет небезопасна: если передавать учетные данные непосредственно по HTTP, любой абонент сети на протяжении всего маршрута пакета от браузера к серверу сможет заглянуть внутрь этого пакета и узнать пароль.
Более или менее безопасно можно чувствовать себя, только зашифровав весь канал передачи данных. Для этого неплохо подходит алгоритм шифрования с открытым ключом, описанный в параграфе 4.5.4. Универсальный способ шифрования большинства текстовых прикладных протоколов называется SSL (S ecure S ocket L ayer (уровень надежных сокетов)). Идея этого способа в том, что шифрованием данных занимается не само приложение, а специальная библиотека работы с сокетами, т. е. шифрование происходит на стыке прикладного и транспортного уровней. Конечно, и клиент, и сервер должны включать в себя поддержку SSL, поэтому для служб, защищенных таким способом, обычно отводятся другие номера портов (например, 80 – для HTTP, и 443 – для HTTPS). В Apache этим занимается специальный модуль – mod_ssl, его настройки и способ организации защищенной службы можно найти в документации.
Apache работает в системе как демон с именем httpd. Если необходимо, чтобы при загрузке системы этот демон запускался, то его следует включить в число инициализируемых программ, например при помощи консольного конфигуратора setup – System services. После изменений в конфигурационном файле эту службу требуется перезагрузить, например, при помощи команды service httpd restart.
Несмотря на то, что Apache решает практически любые задачи, связанные с организацией WWW-страниц, есть, конечно, и области, где его применение нежелательно или невозможно. Если, например, задача WWW-сервера – отдавать десяток-другой статически оформленных страниц небольшому числу клиентов, запускать для этого Apache – все равно что стрелять из пушки по воробьям. Лучше воспользоваться сервером thttpd, специально для таких задач предназначенным: он займет намного меньше ресурсов системы.
4.5.3. FTP-сервер
В UNIX-системах существует несколько вариантов службы, предоставляющей доступ к файлам по протоколу FTP (File Transfer Protocol). Как правило, они отличаются друг от друга сложностью настроек, ориентированных на разные категории абонентов, подключающихся к серверу. Если выбор предоставляемых в открытый доступ данных велик, будет велик и наплыв желающих эти данные получить ("скачать"), так что возникает естественное желание этот наплыв ограничить. При этом, допустим, компьютеры из локальной сети могут неограниченно пользоваться файловыми ресурсами сервера, тогда соединений из того же города или в пределах страны должно быть не более двух десятков одновременно, а соединений из-за границы – не более пяти. Такие ухищрения бывают нужны нечасто, но и они поддерживаются большинством FTP-демонов, вроде vsftpd, proftpd, pure-ftpd или wu-ftpd.
FTP – по-своему очень удобный протокол: он разделяет поток команд и поток собственно данных. Дело в том, что команды FTP обычно очень короткие, и серверу выгоднее обрабатывать их как можно быстрее, чтобы подолгу не держать ради них (часто – ради одной команды) открытое TCP-соединение. А вот файлы, передаваемые с помощью FTP, обычно большие, поэтому задержка при передаче в несколько долей секунды, и даже в пару секунд, не так существенна, зато играет роль пропускная способность канала.
Для того чтобы эти каналы было проще различить, данные в FTP пересылаются по инициативе сервера, т. е. именно сервер подключается к клиенту, а не наоборот. Делается это так: клиент подключается к 20-му порту сервера (управляющий порт FTP) и передает ему команду: "Хочу такой-то файл. Буду ждать твоего ответа на таком-то (временно выделенном) порту". Сервер подключается со своего 21-го порта (порт данных FTP) к порту на клиенте, указанном в команде, и пересылает содержимое запрошенного файла, после чего связь по данным разрывается, и клиент перестает обрабатывать подключения к порту.
Трудности начинаются, когда FTP-клиент находится за межсетевым экраном. Далеко не каждый администратор согласится открывать доступ из любого места сети Интернет к любому абоненту внутренней сети по любому порту (пускай даже и с порта 21). Да это и не всегда просто, учитывая подмену адресов.
Для того чтобы FTP работал через межсетевой экран, придумали протокол Passive FTP. В нем оба сеанса связи – и по командам, и по данным – устанавливает клиент. При этом происходит такой диалог. Клиент: "Хочу такой-то файл. Но пассивно". Сервер: "А. Тогда забирай его у меня с такого-то порта". Клиент подключается к порту сервера и получает оттуда содержимое файла. Если со стороны сервера тоже находится бдительный администратор, он может не разрешить подключаться любому абоненту Интернет к любому порту сервера. Тогда не будет работать как раз Passive FTP. Если и со стороны клиента, и со стороны сервера имеется по бдительному системному администратору, никакой вариант FTP не поможет.
Еще один недостаток протокола FTP: в силу двухканальной природы его трудно "затолкать" в SSL-соединение. Поэтому идентификация пользователя, если таковой имеется, в большинстве случаев идет открытым текстом. Несмотря на то, что для FTP подходит другой механизм шифрования, называемый TLS, далеко не все FTP-клиенты его поддерживают, и он оказывается не востребован на серверах. Поэтому рекомендуется задействовать службу FTP только для организации архивов публичного доступа.
4.5.4. Терминальный доступ
Текстовый интерфейс позволяет пользователю UNIX-системы работать на компьютере удаленно с помощью терминального клиента. Весьма удобно, находясь далеко от компьютера, управлять им самым естественным способом, с помощью командной строки. Препятствий этому немного: объем передаваемых по сети данных крайне невелик, ко времени отклика, занимающего полсекунды, вполне можно привыкнуть, а если оно меньше десятой доли секунды, то задержка и вовсе не мешает. Что необходимо соблюдать строго, так это шифрование учетных записей при подключении к удаленному компьютеру, а на самом деле – и самого сеанса терминальной связи, т. к. в нем вполне может "засветиться" пароль: например, пользователь заходит на удаленный компьютер и выполняет команду passwd.
Для терминального доступа раньше использовался протокол telnet и соответствующая пара клиент-сервер telnet-telnetd. От них пришлось отказаться в силу их вопиющей небезопасности.
На смену telnet пришла служба Secure Shell ("Надежная оболочка"), также состоящая из пары клиент-сервер – ssh и sshd. Шифрование данных в Secure Shell организовано по принципу "асимметричных ключей", который позволяет более гибко шифровать или идентифицировать данные, чем более распространенный и привычный принцип "симметричных ключей". Симметричный ключ – это пароль, которым данные можно зашифровать, и с помощью него же потом расшифровать.
Упрощенно метод "асимметричных ключей" можно описать так. Используется алгоритм, при котором специальным образом выбранный пароль для шифрования данных не совпадает с соответствующим ему паролем для их расшифровки. Более того, зная любой из этих паролей, никак нельзя предугадать другой. Некто, желая, чтобы передаваемые ему данные нельзя было подсмотреть, раздает всем желающим шифрующий пароль со словами: "будете писать мне – шифруйте этим", т. е. делает этот пароль открытым. Дешифрующий пароль он хранит в строгой тайне, никому не открывая. В результате зашифровать данные его паролем может любой, а расшифровать (что и значит – подглядеть) – может только он. Цель достигнута.
Тот же принцип используется для создания так называемой электронной подписи, помогающей идентифицировать данные, т. е. определить их автора. На этот раз открытым делается дешифрующий ключ (конечно, не тот, о котором только что шла речь, а еще один). Тогда любой, получив письмо и расшифровав его, может быть уверен, что письмо написал этот автор – потому что шифрующим ключом не владеет больше никто.
Здесь уместно сделать два замечания. Во-первых, алгоритмы шифрования с асимметричными ключами весьма ресурсоемки, поэтому в Secure Shell (и упомянутом ранее SSL) они используются только на начальном этапе установления соединения. Обмен данными шифруется симметричным ключом, но, поскольку сам этот ключ был защищен асимметричным, соединение считается надежным. Во-вторых, этот кажущийся надежным алгоритм имеет серьезный изъян, с которым, впрочем, нетрудно справиться. Опасность таится в самом начале: как, получив от товарища открытый ключ, убедиться, что этот ключ действительно ему принадлежит? А вдруг по пути ключ был перехвачен злоумышленником, и до нас дошел уже его, злоумышленника, открытый ключ? Мы легкомысленно шифруем наши данные этим ключом, злоумышленник перехватывает их на обратном пути, просматривает их (только он и может это сделать, т. к. подсунул нам свой шифрующий пароль), и обманывает таким же манером товарища, притворяясь на этот раз нами.
Такая уязвимость называется "man-in-the-middle" (дословно "человек посередине"), своего рода "испорченный телефон". Существует два способа борьбы с ней.
Первый: не доверять никаким открытым ключам, кроме тех, которые получил лично от товарища. Если с товарищем вы незнакомы, можете попросить у него удостоверение личности: а вдруг он все-таки злоумышленник?
Второй способ: получить от товарища открытый ключ несколькими независимыми путями. В этом случае подойдет так называемый отпечаток пальца (fingerprint) – получаемая из ключа контрольная сумма такого размера, что подделать ее еще невозможно, но уже нетрудно сравнить с этой же контрольной суммой, размещенной на WWW-странице или присланной по электронной почте.
4.5.5. Почтовая служба
Еще один немаловажный сервис, отлично поддерживаемый в UNIX-системах, – пересылка электронной почты. Протокол SMTP (Simple Mail Transfer Protocol), задающий порядок пересылки почты, впервые был описан и помещен в RFC в самом начале 80-х гг. (RFC, Request For Comments, рабочее предложение – постоянно пополняемое собрание рабочих материалов (технических отчетов, проектов и описаний стандартов протоколов), используемых разработчиками и пользователями Интернет).
С тех пор он неоднократно модифицировался, однако в основе своей остался прежним: SMTP – это протокол передачи текстовых сообщений, снабженных вспомогательными заголовками, часть из которых предназначена для почтового сервера, передающего сообщения, а часть – для почтового клиента, с помощью которого пользователь просматривает эти сообщения.
В качестве адреса в электронном письме обычно используется сочетание пользователь@доменное_имя. Изначально поле пользователя совпадало с входным именем пользователя в UNIX-системе, а доменное_имя – с именем компьютера. Пользователь – удаленно или через "настоящий" терминал – подключался к системе и просматривал почту, скажем, при помощи утилиты mail. Такой вариант обмена электронными письмами между пользователями UNIX-системы доступен и сейчас.
Когда компьютеров в сети стало больше, выяснилось, что, имея учетные записи на многих машинах, почту все-таки удобнее хранить и читать на одной машине, предназначенной только для почты, а значит, доменное_имя в почтовом адресе может не совпадать с доменным именем персонального компьютера адресата. Для удобства решили ввести один уровень косвенности: прежде чем соединяться с компьютером "доменное_имя", почтовый сервер проверяет, нет ли в DNS записи вида доменное_имя... MX... сервер. Эта запись означает, что почту, адресованную на пользователь@доменное_имя, необходимо посылать компьютеру "сервер" – а уж тот разберется, что делать дальше.
Иногда необходимо, чтобы сервер принимал письма, не предназначенные для зарегистрированных на нем пользователей. Эти письма немедленно помещаются в очередь на отправку, и пересылаются дальше. Такой режим работы сервера называется "relay" (пересыльщик). Когда-то все почтовые серверы работали в режиме "open relay", т. е. соглашались пересылать почту откуда угодно и куда угодно. К сожалению, этим немедленно стали пользоваться желающие подзаработать массовой рассылкой рекламы (т. е. "спамом"). Поэтому открытые пересыльщики сегодня запрещены RFC. Однако как минимум в трех случаях сервер имеет право работать пересыльщиком: если он пересылает почту от абонента обслуживаемой сети, если письмо адресовано в обслуживаемый домен или его поддомен, и если письмо исходит непосредственно от почтового клиента пользователя, который предварительно каким-нибудь способом идентифицировался в системе (например, с помощью разработанного для этого расширения SMTPAUTH). Во всех трех случаях ответственность за возможные злоупотребления почтовым сервисом возлагается на администратора сервера, т. к. он имеет возможность отыскать провинившегося пользователя.
В Linux существует несколько различных почтовых серверов. Во-первых, Sendmail, корифей почтового дела, возникший одновременно с SMTP. Возможности этого сервера весьма велики, однако воспользоваться ими в полной мере можно только после того, как научишься понимать и исправлять содержимое конфигурационного файла sendmail.cf, который уже более двадцати лет служит примером самого непонятного и заумного способа настройки. Впрочем, на сегодня для sendmail.cf на языке препроцессора m4 написано несметное, на все случаи жизни, число макросов, так что sendmail.cf редактировать не приходится. Вместо него из этих макросов составляется файл sendmail.mc, небольшой и вполне читаемый, а он, с помощью утилиты m4, транслируется в sendmail.cf, который не читает никто, кроме самого Sendmail. К сожалению, упростить исходный текст этой программы невозможно, поэтому специалисты по компьютерной безопасности не любят давать относительно нее гарантии: редко, но все же находится в sendmail какое-нибудь уязвимое место.
Другой вариант почтового сервера, Postfix, весьма гибок в настройке, прекрасно подходит для почтовых серверов масштаба предприятия, и, в отличие от Sendmail, более прозрачно спроектирован и написан. Он поддерживает все хитрости, необходимые современной почтовой службе: виртуальных пользователей, виртуальные домены, подключаемые антивирусы, средства борьбы со спамом и т. п. Настройка его хорошо документирована, в том числе с помощью комментариев в конфигурационном файле (как правило, /etc/postfix/main.cf), и с помощью файлов-примеров.
Стоит упомянуть еще как минимум три почтовые службы: QMail – по мнению многих, этот демон наиболее защищен и от атак извне, и от возможных ошибок в собственных исходных текстах; Exim – как наиболее гибкий в настройках (в том числе и пока не реализованных); и ZMailer, предназначенный для работы на больших и очень больших серверах, выполняющих в основном работу по пересылке.
|
