Настройка сети
Итак, с работой сети в Linux Мефодий немного познакомился, однако то, как эту сеть использовать для личных нужд, понятнее не стало. Предже всего: как приучить имеющийся компьютер пользоваться имеющейся локальной сетью?
Настройка вручную
Первая мысль -- настроить сетевые интерфейсы вручную. Это довольно просто, если знать полагающиеся при настройке данные: IP-адрес самого компьютера, IP-адрес маршрутизатора по умолчанию и адрес сервера доменных имён.
Задать IP-адреса интерфейсам eth0 и lo можно уже известной командой ifconfig:
[root@sakura root]# ifconfig
[root@sakura root]# ifconfig eth0 inet 192.168.102.125 netmask 255.255.255.0\
broadcast 192.168.102.255
[root@sakura root]# ifconfig lo inet 127.0.0.1 netmask 255.0.0.0\
broadcast 127.255.255.255
[root@sakura root]# ifconfig
eth0 Link encap:Ethernet HWaddr 00:0C:29:56:C1:36
inet addr:192.168.102.125 Bcast:192.168.102.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:34 errors:0 dropped:0 overruns:0 frame:0
TX packets:32 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:6765 (6.6 Kb) TX bytes:8753 (8.5 Kb)
Interrupt:17 Base address:0x1080
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
[root@sakura root]# ping -c1 192.168.102.1
PING 192.168.102.1 (192.168.102.1) 56(84) bytes of data.
64 bytes from 192.168.102.1: icmp_seq=1 ttl=64 time=0.613 ms
--- 192.168.102.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.613/0.613/0.613/0.000 msНастройка сетевых интерфейсов |
Заметим, что вместе с IP-адресом необходимо указывать и сетевую маску, и широковещетельный адрес сети. Теперь пакеты доходят до любого абонента локальной сети, но не дальше, поскольку не задан ни один маршрутизатор. Добавить маршрутизатор можно командой route add:
[root@sakura root]# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.102.0 * 255.255.255.0 U 0 0 0 eth0 127.0.0.0 * 255.0.0.0 U 0 0 0 lo [root@sakura root]# ping 209.173.53.26 connect: Network is unreachable [root@sakura root]# route add default gw 192.168.102.1 [root@sakura root]# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.102.0 * 255.255.255.0 U 0 0 0 eth0 127.0.0.0 * 255.0.0.0 U 0 0 0 lo default 192.168.102.1 0.0.0.0 UG 0 0 0 eth0 [root@sakura root]# ping 209.173.53.26 64 bytes from 209.173.53.26: icmp_seq=1 ttl=114 time=166 ms . . .
Добавление маршрутизатора по умолчанию |
Мефодий заметил, что две записи в таблице маршрутизации уже были до выполнения команды route add: относительно локальных сетей 192.168.102.0/24 и 127.0.0.0/8. Эти записи появилась там в результате настройки сетевых интерфейсов: для пополнения таблицы достаточно было адреса и сетевой маски. Не хватало только явного указания маршрутизатора. Ключевое слово default заменило параметр -net 0.0.0.0 (из предыдущей лекции известно, что сети 0.0.0.0/0 в таблице маршрутизации принадлежит любой адрес), а параметр gw означает "gateway", т. е. маршрутизатор.
Тем не менее служба доменных имён пока не работает: необходимо заполнить файл /etc/resolv.conf:
[root@sakura root]# ping www.ru ping: unknown host www.ru [root@sakura root]# cat /etc/resolv.conf [root@sakura root]# cat > /etc/resolv.conf domain nipponman.ru nameserver 192.168.102.1 [root@sakura root]# ping www.ru PING www.ru (194.87.0.50) 56(84) bytes of data. 64 bytes from www.ru (194.87.0.50): icmp_seq=1 ttl=55 time=84.3 ms . . . [root@sakura root]# update_chrooted conf
Определение домена и DNS-сервера |
Последнюю команду присоветовал Гуревич. Дело в том, что подсистему, работающую с DNS, нередко "сажают в песочницу", то есть переносят в отдельный каталог, в котором выполняется chroot. Как сказано в лекции Конфигурационные файлы, в такой "песочнице" должны быть все нужные для работы файлы -- и уж конечно процедурам DNS нужен свой файл-копия /etc/resolv.conf. Информация о том, кому что нужно копировать при изменении профиля системы, обычно хранится централизованно и управляется несложными сценариями. В данном дистрибутиве комнда update_chrooted conf как раз и копирует все изменившиеся конфигурационные файлы по песочницам.
Настройка при установке или загрузке системы
Мефодий очень обрадовался заработавшей сети и немедленно принялся сочинять простейший стартовый сценарий, который выполнял бы все нужные команды автоматически. Выяснилось, что такой сценарий уже есть в любом дистрибутиве Linux, хотя называться он может по-разному, как правило, /etc/init.d/network или networking. Как и полагается стартовому сценарию, с параметром start он настраивает сеть, а с пареметром stop -- "выключает" сетевые настройки.
Безусловно, ни список сетевых интерфейсов, ни параметры их настройки не указаны в самом стартовом сценарии, как то хотел сделать Мефодий. Всевозможные сетевые настройки хранятся в /etc отдельно, как правило, в специальном подкаталоге. В разных дистрибутивах Linux применяются различные схемы размещения настроек. Система, установленная на компьютере Мефодия, использует общий подкаталог /etc/sysconfig для хранения большинства настроек, используемых не службами, а самими стартовыми сценариями, в том числе и network:
[root@sakura root]# ls -F /etc/sysconfig/ acpi framebuffer init network-scripts/ vlan apmd harddisk/ keyboard* nfs xfs autologin* harddisks keyboard.rpmnew pcmcia* xinetd bootsplash hotplug klogd rawdevices xinitrc clock* hwconf kudzu syslogd console/ i18n* mouse* system* consolefont* i18n.rpmnew network* usb
Каталог /etc/sysconfig |
Как видно из примера, в этом каталоге содержатся и конфигурационные файлы, и дополнительные сценарии, и вложенные подкаталоги для отдельных видов настроек.
За сеть непоседствено отвечают файл /etc/sysconfig/network и содержимое подкаталога /etc/sysconfig/network-scripts:
[root@sakura root]# cat /etc/sysconfig/network NETWORKING=yes HOSTNAME=sakura.nipponman.ru DOMAINNAME=nipponman.ru GATEWAY=192.168.102.1
Настройка сети по умолчанию |
Файл network оказался очень простым: в нём в формате shell определяются основные настройки сети: имя компьютера и домена, а также маршрутизатор по умолчанию. По-видимому, этот файл "втягивается" командой "." из самого сценария network.
[root@sakura root]# ls -F /etc/sysconfig/network-scripts/ README@ ifdown-ppp* ifup-ipv6* ifup-sl* ifcfg-eth0* ifdown-pre* ifup-ipx* net_cnx_pg* ifcfg-lo* ifdown-sit* ifup-plip* net_prog.default* ifdown@ ifdown-sl* ifup-plusb* net_resolv.default ifdown-aliases* ifup@ ifup-post* network-functions* ifdown-iptun* ifup-aliases* ifup-ppp* network-functions-ipv6* ifdown-ipv6* ifup-ctc* ifup-routes* ifdown-post* ifup-iptun* ifup-sit*
Каталог network-scripts |
Каталог network-scripts содержит множество сценариев на все случаи сетевой жизни. В файле README описано, для чего какой сценарий нужен и что означают поля в каждом из них (часто этот файл хранится в /usr/share/doc/net-scripts, а не в /etc).
[root@sakura root]# cat /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 BOOTPROTO=static IPADDR=192.168.102.125 NETMASK=255.255.255.0 NETWORK=192.168.102.0 BROADCAST=192.168.102.255 ONBOOT=yes
Настройка интерфейса по умолчанию |
А вот и настройки интерфейса eth0, которые Мефодию приходилось применять вручную. Таким образом, стоит только подать команду service network stop, как все сетевые интерфейсы "пропадут" (деактивизируются), а после service network start -- снова появятся.
Как правило, пользователю вообще не обязательно редактировать эти файлы. С каждым дистрибутивом поставляется программа-конфигуратор, которая позволяет "настроить сеть", не вспоминая, какие данные, в каком формате и куда нужно записывать. Обычно такая программа оформляется в стиле мастера, "кудесника", задающего только вопросы по существу, с её помощью и формируются более или менее подходящие конфигурационные файлы. Результатов работы мастера в большинстве случаев бывает достаточно, а в тех случаях, когда его искусственный интеллект пасует, администратор применяет свой естественный интеллект и редактор Vim. С другой стороны, изменить несколько значений в трёх конфигурационных файлах не так уж сложно. Когда настройщик действительно необходим -- это во время установки системы на компьютер или непосредственно после неё. Настраивать приходится сразу всё в системе, так что любая экономия времени при этом существенна.
В некоторых дистрибутивах используется схема ifupdown, основанная на технологии ". d":
debian!shogun$ ls -F /etc/network if-down.d/ if-pre-up.d/ ifstate.hotplug interfaces if-post-down.d/ ifstate if-up.d/ options
Настройка сети с применением схемы ". d" |
Настройка сетевых интерфейсов и маршрутизатора по умолчанию хранится одном файле (считается, что редактировать его автоматически -- просто). Тонкая настройка сети -- в файле options. Каталоги if-pre-up.d, if-up.d, if-down.d и if-post-down.d предназначены для служб, которые хотят производить какие-то действия, соответственно, перед тем, как сетевой интерфейс будет активизирован ("поднят"), после успешной активизации интерфейса, перед тем как сетевой интерфейс будет деактивизирован ("опущен") и после этого.
Автоматическая настройка
Программа-настройщик регулярно предлагала Мефодию "настроить сеть автоматически". В режиме автоматической настройки практически не запрашивается данных у пользователя. Это значит, что данные система должна брать откуда-то ещё, видимо, со специального сервера в локальной сети.
Запрашивать сетевые настройки с сервера вместо того, чтобы хранить их на каждом компьютере, довольно удобно. В самом деле: один сервер, один администратор, один файл с общими настройками. Более того, можно вообще не хранить персональных настроек для каждого компьютера в сети, а ограничиться настройками групповыми, лишь бы IP-адреса внутри группы различались. Одним из первых был разработан протокол RARP (reverse ARP), который, как следует из названия, занимается преобразованием, обратным ARP: по интерфейсному адресу компьютер узнаёт у сервера сетевой. В ethernet-сетях для этого посылается широковещательный ethernet-фрейм типа "RARP-запрос", который означает "Вот мой MAC-адрес. Кто-нибудь, дайте мне IP!". На что специальная программа-сервер отвечает RARP-ответом "Вот тебе IP!" -- фреймом, содержащим IP-адрес, который сервер нашёл в своей таблице. Если в сети нет ни одного RARP-сервера или ни в одном из них не зарегистрирован интерфейсный адрес компьютера-клиента, тот останется без IP. Похожую схему использует и протокол BOOTP, применяющийся для сетевой загрузки компьютеров. Предполагается, что, получив IP-адрес, клиент заберёт с сервера (по протоколу TFTP, trivial FTP) некий файл, загрузит его в память и передаст управление. Поэтому в BOOTP передаётся не только IP-адрес клиента, но и IP-адреса TFTP-сервера и маршрутизатора по умолчанию и имя файла-загрузчика.
В современных сетях чаще всего используется протокол DHCP (Dynamic Host Configure Protocol, протокол динамической настройки сетевых абонентов). Он имеет очень широкие возможности: с сервера можно получить IP-адрес, сетевую маску и широковещательный адрес, имя домена, адреса маршрутизатора и серверов доменных имён, а также великое множество других параметров, вплоть до не предусмотренных в DHCP явно, так что их тип задаётся обычным числом, а интерпретация значения целиком определяется клиентом. Урезанную часть DHCP поддерживают "умные" сетевые устройства (те, что снабжены BootROM, т. е. ПЗУ с загрузочной программой). Но полностью обрабатывать все поля DHCP умеет специальный демон-клиент. В Linux этот демон называется dhcpcd (DHCP client daemon). В его ведение, как минимум, входит настройка сетевого интерфейса, маршрута по умочанию и resolv.conf.
Так что всё, что Мефодий делал вручную или вписывал в настроечный файл, можно получить "за просто так", если в сети работает DHCP-сервер:
[root@sakura root]# ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
. . .
[root@sakura root]# cat /etc/resolv.conf
[root@sakura root]# /sbin/dhcpcd -h sakura -N eth0
dhcpcd.exe: interface eth0 has been configured with new IP=192.168.102.124
[root@sakura root]# ps gax | grep "dhcpcd"
1011 ? S 0:00 /sbin/dhcpcd -h sakura -N eth0
[root@sakura root]# cat /etc/resolv.conf
nameserver 192.168.102.1
search nipponman.ru
[root@sakura root]# ifconfig
eth0 Link encap:Ethernet HWaddr 00:0C:29:56:C1:36
inet addr:192.168.102.124 Bcast:192.168.102.255 Mask:255.255.255.0
. . .Использование dhcpcd |
Протокол DHCP даже позволяет передавать серверу желаемое имя и адрес компьютера. Впрочем, выдача IP-адреса привязана, как правило, к MAC-адресу. Здесь есть особая хитрость. DHCP может неплохо работать, когда IP-адресов не хватает на всех: компьютеров с разными NAC-адресами в сети больше, чем выделенных IP, но эти компьютеры никогда не включаются все одновременно. Компьютер, определяемый в DHCP по MAC-адресу, не "присваивает" выданный IP навсегда: адрес сдаётся в "аренду" (lease) на некоторое время. Если до истечения срока аренды бывший владелец не подтвердил желание пользоваться адресом и дальше (не послал повторный DHCP-запрос), адрес считается незанятым. Но когда компьютер подключается к сети после долгого перерыва, сервер DHCP сначала просматривает "арендную историю" на предмет того, какой IP этому абоненту уже выдавался. Если этот IP не занят, то будет выдан именно он. И только когда к сети подключится совсем новый абонент, а все адреса уже когда-нибудь кому-то выдавались, среди них будет выбран и отдан в аренду новичку тот, что дольше всех оставался невостребованным.
Наконец, чтобы избавиться и от этой ручной работы, можно перенастроить ifcfg-eth0 на использование DHCPD:
[root@sakura root]# cat /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 BOOTPROTO=dhcp NETMASK=255.255.255.0 ONBOOT=yes
Настройка интерфейса на DHCP по умолчанию |
Настройка соединений "точка--точка"
Если компьютер стоит дома, далеко не всегда есть возможность подключиться к локальной сети, непосредственно граничащей с Internet. Для передачи небольших сообщений чаще всего используется временное подключение посредством телефонной линии. На обеих сторонах линии устанавливается модем -- устройство, преобразующее один формат сигнала в другой. На российских телефонных линиях обычно использутся аналоговые модемы, способные обмениваться данными по довольно низкокачественным линиям с большой долей помех и относительно неискажённой передачей сигнала только в диапазоне слышимых звуковых частот. За низкое качество канала приходится расплачиваться низкой скоростью передачи данных: на таких модемах она до сих пор не превышает (после отбрасывания служебной информации, ошибок и прочего) трёх-четырёх килобайтов в секунду, а в действительности бывает раза в два меньше.
Соединение между двумя устройствами, вообще говоря, не сетевыми, а только способными передавать данные, описывается несколькими протоколами. Самый распространённый из них -- PPP (Point-to-Point Protocol, протокол "точка--точка") -- решает задачи, возникающие в силу особенностей соединений "точка--точка".
Во-первых, само участвующее в соединении устройство почти никогда не представлено в виде сетевого интерфейса, потому что не обладает нужными для организации сети свойствами. Это значит, что какая-то часть системы (скорее всего, демон) будет разговаривать с устройством на понятном ему языке, а с пользовательскими утилитами взаимодействовать посредством специально организованного виртуального сетевого интерфейса.
Во-вторых, нет необходимости поддерживать часть интерфейсного протокола: абонента на среде передачи данных два, никакой идентификации не требуется, потому что каждый может отличить себя от не-себя. Так, виртуальный сетевой интерфейс ppp0, соответствующий устройству, обменивающемуся данными по протоколу PPP, не обладает MAC-адресом.
В-третьих, оттого, что соединение не постоянное, а среда за время, пока абоненты не были связаны, могла измениться до неузнаваемости, обеим сторонам приходится при каждом дозвоне идентифицировать себя. Обычно идентифицируется только сторона, которой предоставляется доступ в сеть, но проверять, до правильного ли места мы дозвонились, тоже не мешает. При установлении соединения "точка--точка" процедуры идентификации проходят после того, как появляется возможность передавать данные, но до всякой сетевой настройки. Мало того, данные по настройке сети (аналогичные тем, что используются в DHCP) также передаются на этом этапе взаимодействия по протоколу PPP.
В силу того, что дозвон нужен пользователям самого разного уровня знаний, для PPP написано множество программ-"звонилок", использующих графическую подсистему, со звуками и прочими не относящимися к делу украшениями. Пример такой программы -- kppp, утилита модемного доступа для рабочего стола KDE. Всё, что требуется от пользователя -- это указать модем, список телефонов, куда звонить и тип идентификации. Впрочем, и здесь пользователь не освобождается от "тяжёлой" мыслительной работы: некоторые провайдеры (организации, предоставляющие выход в Internet) после дозвона требуют идентификацию не по протоколу PPP, а открытым тесктом, на манер "login--password" в Linux. Иногда это и есть самый настоящий login: пользователю предоставляется терминальный доступ, а дальше пускай делает, что хочет. В этом случае приходится писать сценарий-диалог (chat script) в стиле "Дождаться строки "login:" -- ввести входное имя. Дождаться сторки "Password:" -- ввести пароль. Дождаться подсказки командного интерпретатора -- ввести "pppd" с параметрами".
Что совсем уже просто для пользователя, так это утилита wvdial, описанная в лекции Конфигурационные файлы. Она и модем сама определяет, и тип идентификации, и pppd настраивает и запускает тоже сама. В действительности же сетью занимается демон pppd, чьи конфигурационные файлы находятся в каталоге /etc/ppp:
[root@sakura root]# ls /etc/ppp callback-client chap-secrets ip-up options.dialin peers callback-server ip-down ip-up.d options.dialout callback-users ip-down.d options pap-secrets [root@sakura root]# ls -l /etc/ppp/*secrets -rw------- 1 root root 78 Jun 23 1995 /etc/ppp/chap-secrets -rw------- 1 root root 77 Jun 23 1995 /etc/ppp/pap-secrets
Каталог с настройками PPP |
Большинство из этих файлов по умолчанию не используются. Следует помнить, что идетификационная информация, используемая в PPP (в зависимости от особенностей соединения и пристрастий провайдера могут применяться протоколы идентификации PAP или CHAP), хранится в файлах pap-secrets и chap-secrets в текстовом виде. Хранить не пароль, а ключ, как это сделано в /etc/shadow нельзя, так что остаётся либо надеяться на права доступа к этим файлам, либо запускать pppd вручную (или с помощью тех же wvdial и kppp) и каждый раз этот пароль вводить.
Установить PPP-соединение можно поверх любой среды передачи данных, в том числе и поверх локальной сети. В этом случае pppd обменивается данными (посредством псевдотерминальной пары pty -- tty или ptmx -- pts/, описанной в лекции Работа с внешними устройствами) с демоном pppoe, выполняющим роль "модема". При этом передаваемые данные можно сжимать или шифровать, а главное, связь "точка--точка" устанавливается с конкретным пользователем, который ввёл одному ему известный пароль, поэтому часто выход в Internet, требующий стогого учёта трафика, делают именно с помощью пары pppd/pppoe. Наконец, в сети может быть настоящий модем, преобразующий эти данные в формат, пригодный для передачи по цифровым телефонным линиям (DSL). Кстати сказать, такой модем легко собирается из маленького компьютера с низким энергопотреблением, ядра Linux и доработанного стартового виртуального диска. Некоторые современные DSL-модемы устроены именно так, причём ядро и initrd записываются в перепрограммируемое ПЗУ.
Межсетевой экран
В Linux существует мощный механизм анализа сетевых и транспортных пакетов, позволяющий избавляться от нежелательной сетевой активности, манипулировать потоками данных и даже преобразовывать служебную информацию в них. Обычно такие средства носят название "firewall" ("fire wall" -- противопожарная стена, брандмауэр), общепринятый русский термин -- межсетевой экран. В более старых версиях межсетевого экрана Linux использовался вариант межсетевого экрана ipchains, который впоследствии был заменён на более мощный, iptables.
Суть iptables в следующем. Обработка сетевого пакета системой представляется как его конвейерная обработка. Пакет нужно получить из сетевого интерфейса или от системного процесса, затем следует выяснить предполагаемый маршрут этого пакета, затем отослать через сетевой интерфейс либо отдать какому-нибудь процессу, если пакет предназначался нашему компьютеру. Налицо три конвейера обработки пакетов: "получить -- маршрутизировать -- отослать" (действие маршрутизатора), "получить -- маршрутизировать -- отдать" (действие при получении пакета процессом) и "взять -- маршрутизировать -- отослать" (действие при отсылке пакета процессом).
Между каждыми из этих действий системы помещается модуль межсетевого экрана, именуемый цепочкой. Цепочка обрабатывает пакет, исследуя, изменяя и даже, возможно, уничтожая его. Если пакет уцелел, она передаёт его дальше по конвейеру. В этой стройной схеме есть два исключения. Во-первых, ядро Linux даёт доступ к исходящему пакету только после принятия решения о его маршрутизации, поэтому связка "взять -- маршрутизировать" остаётся необработанной, а цепочка, обрабатывющая исходящие пакеты (она называется OUTPUT) вставляется после маршрутизации. Во-вторых, ограничения на "чужие" пакеты, исходящие не от нас и не нам предназначенные, существенно отличаются от ограничений на пакеты "свои", поэтому после маршрутизации транзитные пакеты обрабатываются ещё одной цепочкой (она называется FORWARD). Цепочка, обслуживающая связку "получить -- маршрутизировать", называется PREROUTING, цепочка, обслуживающая свазку "маршрутизировать -- отдать" -- INPUT, а цепочка, стоящая непосредственно перед отсылкой пакета -- POPSTROUTING:
|
Обработка пакетов цепочками iptables |
В варианте ipchains каждая цепочка представляла собой таблицу правил. В правиле задаются свойства пакета и действие, которое нужно выполнять со всеми пакетами, обладающими указанными свойствами. Когда пакет попадает в таблицу, к нему начинают последовательно применяться правила. Если пакет не имеет свойств, требуемых первым правилом, к нему применяется второе, если второе также не подходит -- третье, и так вплоть до последнего, правила по умолчанию, которое применяется к любому пакету. Если свойства пакета удовлетворяют правилу, над ним совершается действие. Действие DROP уничтожает пакет, а действие ACCEPT немедленно выпускает его из таблицы, после чего пакет движется дальше по конвейеру. Некоторые действия, например LOG, никак не влияют на судьбу пакета, после их выполнения он остаётся в таблице: к нему применяется следующее правило, и т. д. до ACCEPT или DROP.
Из сказанного выше следует, что действия ACCEPT или DROP в каждой таблице могут примениться к пакету лишь однократно. Для большей гибкости цепочки iptables состоят из нескольких (двух-трёх) таблиц. Выходя живым из одной таблицы, пакет попадает в следующую, а уж последняя передаёт его, если завершается действием ACCEPT, на конвейер. Хотя таблицы функционально одинаковы, принято использовать их по разному назначению. Таблицу mangle используют для внесения исправлений в служебную информацию пакета, таблицу filter -- для определния того, не стоит ли пакет уничтожить, а таблицу nat -- для подмены сетевых адресов. В приведённой выше диаграмме буквами M, N и F отмечено, какие именно таблицы есть в цепочках и в каком порядке их проходит пакет.
Для просмотра правил во всех таблицах всех цепочек iptables можно воспользоваться командой iptables-save:
[root@sakura root]# iptables-save # Generated by iptables-save v1.2.11 on Fri Dec 24 21:06:12 2004 *nat :PREROUTING ACCEPT [1:261] :POSTROUTING ACCEPT [3:220] :OUTPUT ACCEPT [3:220] COMMIT # Completed on Fri Dec 24 21:06:12 2004 # Generated by iptables-save v1.2.11 on Fri Dec 24 21:06:12 2004 *filter :INPUT ACCEPT [7:1077] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [5:355] COMMIT # Completed on Fri Dec 24 21:06:12 2004 # Generated by iptables-save v1.2.11 on Fri Dec 24 21:06:12 2004 *mangle :PREROUTING ACCEPT [7:1077] :INPUT ACCEPT [7:1077] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [5:355] :POSTROUTING ACCEPT [5:355] COMMIT # Completed on Fri Dec 24 21:06:12 2004
Пустые цепочки iptables |
Команда группирует одинаковые таблицы каждой цепочки. В пустой таблице присутствует только правило по умолчанию (policy), в этом примере все умолчания равны ACCEPT (пропускать пакет).
Фильтрация
Мефодйий озаботился судьбой "календарного сервера", изобретённого им на прошлой лекции. Как уже было замечено, он запустил этот сервис на порту 26000, используемом популярной сетевой компьютерной игрой, что может помешать игрокам. Поэтому Мефодий решил запретить обращение к 26000-му порту отовсюду, кроме самой машины, то есть со всех интерфейсов, кроме lo. С этой задачей справлялась настройка only_from = 127.0.0.1 метадемона, но её пришлось выключить, так как она автоматически запрещала доступ из сети ко всем сервисам компьютера:
[root@sakura root]# iptables --append INPUT --in-interface lo --protocol tcp --destination-port quake --jump ACCEPT [root@sakura root]# iptables --append INPUT --protocol tcp --destination-port quake --jump REJECT [root@sakura root]# iptables-save . . . *filter :INPUT ACCEPT [1030:72984] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [730:69581] -A INPUT -i lo -p tcp -m tcp --dport 26000 -j ACCEPT -A INPUT -p tcp -m tcp --dport 26000 -j REJECT --reject-with icmp-port-unreachable COMMIT . . . [root@sakura root]# service iptables save saving current rules to /etc/sysconfig/iptables: [ DONE ]
Фильтрация TCP-запросов из сети |
Команды iptables получаются довольно длинными: нужно аккуратно описать свойства каждого фильтруемого пакета. В примере Мефодий добавил два правила в таблицу filter цепочки INPUT (таблица filter выбирается по умолчанию, если не оказан ключ "-t таблица"). Первое правило разрешает принимать TCP-пакеты, адресуемые на порт 26000, если они пришли из интерфейса lo. Проверка таких пакетов не дойдёт до второго правила: по действию ACCEPT они немедленно отправятся дольше по конвейеру. Второе правило не просто уничтожает пакет, пришедший на 26000 порт, но и, как то предписывает действие REJECT, посылает отправителю ICMP-пакет, сообщающий о том, что такие запросы не обслуживаются (при обычном действии DROP клиент некоторое время дожидается подтвержения). Из примера видно, что полнословные ключи iptables можно заменять на однобуквенные. Кроме того, пример показывает, что стартовый сценарий iptables (в этом дистрибутиве) обрабатывает параметр save, который делает изменения, внесённые вручную, постоянными (service iptables start, выполняемый при загрузке системы, использует /etc/sysconfig/iptables).
Подмена адресов
Если в некоторой сети используются адреса из описанного стандартом RFC1918 внутреннего диапазона (например, из сети 10.0.0.0/8), без дополнительных действий абоненты этой сети доступа к Internet иметь не будут. Пакеты с такими адресами запрещено передавать в Internet, а даже если они туда просочатся через маршрутизатор, соединяющий "внутреннюю" и "внешнюю" сети, следующий же маршрутизатор откажется их пересылать. Простая, казалось бы, мысль научить межсетевой экран, установленный на маршрутизаторе, подменять IP-адреса в пакетах, приходящих из внутренней сети, своим внешним IP-адресом наталкивается на серьёзное препятствие.
Допустим, абоненты с адресом 10.0.0.3 и 10.0.0.7 устанавливают TCP-соединение с адресом в Internet (скажем, 209.173.53.26). Специально обученный маршрутизатор подменяет 10.0.0.3 и 10.0.0.7 на адрес своего сетевого интерфейса, подключенного к внешней сети (допустим, 194.87.0.50). Пакеты уходят адресату, как если бы и тот, и другой были отправлены самим маршрутизатором. 209.173.53.26 отвечает на два запроса двумя пакетами, оба -- на адрес 194.87.0.50. Что делать дальше? Как отличить пакет, предназначенны для 10.0.0.3 от такового же для 10.0.0.7?
На помощь приходит знание TCP! Как известно, TCP-соединение идентифицируется шестью параметрами: IP-адресами отправителя и получателя, портами на отправителе и получателе и номерами последовательности (SEQN) входящего и исходящего потока данных. В нашей схеме межсетевой экран обязательно заменяет IP-адреса одним, поэтому у двух принятых пакетов они совпадают. А вот с четырьмя оставшимися параметрами он волен поступать, как заблагорассудится: в любом случае каждому из сеансов должны соответствовать разные SEQN и разные номера исходящих портов. Осталось только держать в памяти таблицу соответствия TCP-соединений из внутренней сети TCP-соединениям во внешнюю сеть.
Этот механизм носит название "преобразование сетевых адресов" (Network Adress Translation, NAT). Следует помнить, что чем больше транспортных соединений отслеживается межсетевым экраном, тем больше требуется оперативной памяти ядру Linux и тем медленнее работает процедура сопоставления проходящих пакетов таблице. Впрочем, мощности современных компьютеров позволяют без каких-либо затруднений обслуживать преобразование адресов для сети с пропускной способностью 100Мбит/с и даже выше. В iptables есть специальный модуль для NAT и соответствующие действия в правиле. Такие правила принято помещать в таблиы типа nat:
[root@fuji root]# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 83.237.29.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 192.168.102.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 10.13.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 83.237.29.1 0.0.0.0 UG 0 0 0 ppp0 [root@fuji root]# iptables-save # Generated by iptables-save v1.2.11 on Sat Dec 25 14:02:44 2004 *nat :PREROUTING ACCEPT [216:12356] :POSTROUTING ACCEPT [242:27148] :OUTPUT ACCEPT [1428:91596] -A POSTROUTING -o ppp+ -j MASQUERADE COMMIT . . .
Использование простейшего преобразования адресов |
На том самом маршрутизаторе, где, по словам Гуревича, "всего один настоящий адрес, да и тот -- PPP", как раз и настроено преобразование адресов. Делается это всего одним правилом, добавленным в таблицу nat цепочки POSTROUTING. Действие MASQUERADE отличается от действия SNAT (Source NAT) только тем, что может быть использовано на интерфейсах с изменяемым IP-адресом, таких как ppp или настраиваемый по DHCP eth. Если в процессе работы IP-адрес интерфейса поменяется, правило SNAT продолжит подменять адреса на старый, заданный во время настройки iptables. Зато MASQUERADE вынуждено спрашивать у системы IP-адрес указанного интерфейса для каждого преобразуемого пакета, что может быть неудобно на очень медленных или очень загруженных разнообразными службами компьютерах.
Преобразование адресов работает не только для TCP-соединений, но и для многих других протоколов, где возможно отследить либо настоящего адресата на внутренней сети, либо идентификатор сеанса связи. Например, ICMP-пакет команды ping содержат уникальный идентификатор, который используется в ответе на него, поэтому не составляет труда отследить, на чей именно ping пришёл ICMP-ответ. Таблица отслеживаемых соединений отражается в файле net/ip_conntrack виртуальной файловой системы /proc:
[root@fuji root]# cat /proc/net/ip_conntrack . . . icmp 1 30 src=192.168.102.125 dst=209.173.53.26 type=8 code=0 id=50179 [UNREPLIED] src=209.173.53.26 dst=83.237.29.65 type=0 code=0 id=50179 use=1 tcp 6 431981 ESTABLISHED src=192.168.102.125 dst=194.87.0.50 sport=1027 dport=80 src=194.87.0.50 dst=83.237.29.65 sport=80 dport=1027 [ASSURED] use=1
Просмотр таблицы подменяемых адресов |
Так и есть: во-первых, Мефодий (скорее всего) что-то рассматривает на сайте www.ru (он же 194.87.0.50), а во-вторых, он зачем-то запустил ping www.us: команда cat подана как раз между ICMP-запросом по адресу 209.173.53.26 и ответом на него. Левая часть таблицы описывает соединение до подмены адресов, а правая -- после. Точно так же можно "ловить" и UDP-запросы к службе доменных имён, и многое другое.
Конечно, фильтрацией и маскарадом функции iptables не исчерпываются. Можно, например, задать статическую таблицу подмены адресов, тогда появится возможность принимать из Internet соединения, предназначенные для внутренних серверов. Того же можно добиться, используя подмену адреса только для соединений по определённым портам и т. д.
Сетевые службы
Эта часть лекции -- обзорная. Поскольку, с одной стророны, толковое и последовательное объяснение устройства многочисленных сетевых служб Linux требует, по крайней мере, отдельного курса лекций, а с другой стороны -- хорошей теоретической и практической подготовки слушателя. Так что придётся ограничиться поверхностным описанием наиболее востребованных для личного или домашнего пользования сервисов. Стоит заранее отметить, что описываемые задачи, как правило, могут решаться несколькими путями с помощью различных демонов или утилит, по-разному выполняющих одну и ту же работу. У администратора Linux всегда есть свобода выбора!
HTTP
Мефодий, конечно, знает, что Internet, как глобальная сеть компьютров служит хранилищем глобальной сети документов под общим название WWW (World Wide Web, "Всемирная Паутина"). Связь между документами в Паутине обеспечивается за счёт особого -- гипертекстового -- формата этих документов. Большинство из них написаны на специальном языке гипертекстовой разметки, HTML (HyperText Markup Language) или его диаклектах и расширениях. Гипертекст может содержать ссылки на любые другие документы в Паутине. Формат такой ссылки описывается стандартом URL (Universal Resource Locator, всеобщий указатель ресурсов). Всемирность сети HTML-документов образовалась за счёт удобства доступа к ним: огромное число абонентов Internet предоставляют возможность просмотра этих документов по специальному протоколу HTTP (HyperText Transfer Protocol), и ещё болшее число (фактически, каждый компьютер) запускают клиентские программы-навигаторы (или "броузеры", от англ. "browse", "просматривать"), позволяющие легко "переходить по ссылке", т. е. начинать просмотр документа, на который в выбранном месте ссылался исходный. Сами документы при этом принято называть WWW-страницами, или просто страницами.
Apache -- HTTP-сервер, обладающий самым большим набором возможностей. Учитывая организованный в нём механизм подключаемых модулей (plug-ins), создавать которые может любой грамотный программист, описать умения Apache полностью, видимо, невозможно. Документация по одним только стандартным его возможностям занимает более 50 тысяч строк. Конфигурационные файлы Apache хранятся в /etc/httpd/conf (или, в зависимости от дистрибутива, /etc/apache). Главный конфигурационный файл -- httpd.conf. Этот файл неплохо самодокументирован: вместе с комментариями в нём много больше тысячи строк, что позволяет не изучать руководство, если администратор запамятовал синтаксис той или иной настройки, но, конечно, не позволяет вовсе не изучать руководства.
DirectoryIndex index.html index.htm index.shtml index.cgi
AccessFileName .htaccess
DocumentRoot "/var/www/html"
<Directory "/var/www/html">
Options Indexes Includes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>
ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"
<Directory "/var/www/cgi-bin">
AllowOverride None
Options ExecCGI
Order deny,allow
Deny from all
Allow from 127.0.0.1 localhost
</Directory> Отрывок конфигурационного файла apache |
Пользователь, набравший в броузере "^http://доменное_имя_сервера", увидит содержимое каталога, указанного настройкой DocumentRoot (в примере -- /var/www/html). Каждый каталог, содержащий WWW-страницы, должен быть описан группой настроек <Directory>, включающей права доступа к страницам этого каталога, настройки особенностей просмотра этих страниц и т. п. В частности, настройка DirectoryIndex описывает, какие файлы в каталоге считаются индексными -- если такой файл есть в каталоге, он будет показан вместо содержимого этого каталога. Если в настройке каталога Options не указано значение Indexes, просмотр каталога будет вообще невозможен. Значение Includes этой настройки позволяет WWW-страницам включать в себя текст из других файлов, FollowSymLinks позволяет серверу работать с каталогами и файлами, на которые указывают символьные ссылки (это может вывести точку доступа за пределы DocumentRoot!), а MultiViews позволяеет серверу для разных запросов на одну и ту же страницу выдавать содержимое различных файлов -- сообразно языку, указанному в запросе.
Если настройку каталога AllowOverride установить в All, в любом его подкаталоге можно создать дополнительный конфигурационный файл, изменяющий общие свойства каталога. Имя этого файла задаёт настройка AccessFileName (в примере -- ".htaccess"). Доступом к страницам в каталоге управляют настройки Order, Deny и Allow. Так, доступ к каталогу /var/www/html разрешён отовсюду, а к каталогу /var/www/cgi-bin -- только с самого сервера.
Важное свойство WWW-серверов -- поддержка т. н. динамических WWW-страниц. Динамическая WWW-страница не хранится на диске в том виде, в котором её получает пользователь. Она создаётся -- возможно, на основании какого-то шаблона -- напросредственно после запроса со стороны броузера. Никаких особенных расширений протокола HTTP при этом можно не вводить, просто сервер получает запрос на WWW-страницу, которой не соответствует ни один файл. Зато HTTP-адрес (точнее говоря, URL) этой страницы распознаётся сервером как динамический и передаётся на обработку выделенной для этого программе. Программа генерирует текст в формате HTML, который и передаётся пользователю в качестве запрошенной страницы. В примере для этого используется каталог /var/www/cgi-bin, группа настроек которого имеет единственный параметр Options -- ExecCGI. Для того, чтобы этот каталог, в действительности не входящий в /var/www/html, был доступен броузеру как подкаталог /cgi-bin всего дерева, необходимо прикрепить его к DocumentRoot с помощью ScriptAlias; эта настройка говорит также и о том, что файлы в этом каталоге -- сценарии, и их надо запускать, а не показывать(1).
Как и многие другие прикладные протоколы, HTTP был и остаётся текстовым. При желании можно выучить команды HTTP и получать странички с серверов с помощью telnet вручную. Это означает, что любая система идентификации, основанная на одном только HTTP, будет небезопасна: если передавать учётные данные по HTTP непосредственно, любой абонент сети на протяжении всего маршрута пакета от броузера к серверу сможет подглядеть внутрь этого пакета и увидеть там пароль. Более или менее безопасно можно чувствовать себя, только зашифровав весь канал передачи данных. Для этого неплохо подходит алгоритм шифрования с открытым ключом, описанный в разделе .. Терминальный доступ. Универсальный способ шифрования большинства текстовых прикладных протоколов называется SSL, Secure Socket Layer (уровень надёжных сокетов). Идея этого способа -- в том, что шифрованием данных занимается не само приложение, а специальная библиотека работы с сокетами, то есть шифорвание происходит на стыке прикладного и транспортного уровня. Конечно, и клиент, и сервер должны включать в себя поддержку SSL, поэтому для служб, защищённых таким способом, обычно отводятся другие номера портов (напрмер, 80 -- для HTTP, и 443 -- для HTTPS). В Apache этим занимается специальный модуль -- mod_ssl, его настройки и способ организации защищённой службы можно найти в документации.
Несмотря на то, что Apache решает практически любые задачи, связанные с организацией WWW-страниц, есть, конечно, и области, где его применение нежелательно или невозможно. Если, например, задача WWW-сервера -- отдавать десяток-другой статически оформленных страниц небольшому числу клиентов, запускать для этого Apache -- как стрелять из пушки по воробьям. Лучше воспользоваться сервером thttpd, специально для таких задач предназначенным: он займёт намного меньше ресурсов системы. Особая ситуация возникает, когда самый важный параметр сервера -- его быстродействие. Например сервер, раздающий т. н. "баннеры" (banners, небольшие картинки рекламного характера), приносит тем больше дохода, чем быстрее работает, что означает: может обслуживать больше клиентов. Способ радикально уменьшить время отклика такого сервера на HTTP-запрос -- оформить его не в виде демона, а в виде модуля ядра. Такой сервер существует в виде дополнений к ядру Linux под общим названием tux.
FTP
В Linux существует несколько вариантов службы, предоставляющей доступ к файлам по протоколу FTP (File Transfer Protocol). Как правило, они отличаются друг от друга сложностью настроек, ориентированных на разные категории абонентов, подключающихся к серверу. Если выбор предоставляемых в открытый доступ данных велик, будет велик и наплыв желающих эти данные получить ("скачать"), так что возникает естественное желание этот наплыв ограничить. При этом, допустим, компьютеры из локльной сети могут неограниченно пользоваться файловыми ресурсами сервера, соединений из того же города или в пределах страны должно быть не более двух десятков одновременно, а соединений из-за границы -- не более пяти. Такие ухищрения бывают нужны нечасто, но и они поддерживаются большинством FTP-демонов, вроде vsftpd, proftpd, pure-ftpd или wu-ftpd.
FTP -- по-своему очень удобный протокол: он разделяет поток команд и поток собственно данных. Дело в том, что команды FTP обычно очень короткие, и серверу выгоднее обрабатывать их как можно быстрее, чтобы подолгу не держать ради них (часто -- ради одной команды) открытое TCP-соединение. А вот файлы, передаваемые с помощтю FTP обычно большие, поэтому задержка при передаче в несколько долей секунды, и даже в пару секунд, не так существенна, зато играет роль пропускная способность канала. Было бы удобно, если бы для передачи команд использовался "быстрый, но тонкий" канал (т. е. среда передачи данных с малым временем отклика и небольшой пропускной способностью, например, наземное оптоволокно), а для передачи данных -- "медленный, но толстый" (например, спутниковая магистраль).
Для того, чтобы эти каналы было проще различить, данные в FTP пересылаются по инициативе сервера, что означает, что именно сервер подключается к клиенту, а не наоборот. Делается это так: клиент подключается к 20-му порту сервера (управляющий порт FTP) и передаёт ему команду: "Хочу такой-то файл. Буду ждать твоего ответа на таком-то (временно выделенном) порту". Сервер подключается со своего 21-го порта (порт данных FTP) к порту на клиенте, указанном в команде, и пересылает содержимое запрошенного файла, после чего связь по данным разрывается и клиент перестаёт обрабатывать подключения к порту.
Трудности начинаются, когда FTP-кленит находится за межсетевым экраном. Далеко не каждый администратор согласится открывать доступ из любого места Internet к любому абоненту внутренней сети по любому порту (пускай даже и с порта 21)! Да это и не всегда просто, учитывая подмену адресов. Для того, чтобы FTP работал через межсетевой экран, придумали протокол Passive FTP. В нём оба сеанса связи -- и по командам, и по данным -- устанавливает клиент. При этом происходит такой диалог. Клиент: "Хочу такой-то файл. Но пассивно". Сервер: "А. Тогда забирай его у меня с такого-то порта". Клиент подключается к порту сервера и получает оттуда содержимое файла. Если со стороны сервера тоже находится бдительный администратор, он может не разрешить подключаться любому абоненту Internet к любому порту сервера. Тогда не будет работать как раз Passive FTP. Если и со стороны клиента, и со стороны сервера есть по бдительному системному администратору, никакой вариант FTP не поможет.
Ещё один недостаток протокола FTP: в силу двухканальной природы его трудно "затолкать" в SSL-соединение. Поэтому идентификация пользователя, если таковой имеется, в большинстве случаев идёт открытым текстом. Мефодий тут же вспомнил про своего приятеля, который сначала завёл себе где-то в Сети бесплатную WWW-страницу, файлы на которую надо было передавать по FTP, а потом отказался от этой затеи: с утомительным постоянством кто-то под завязку набивал эту страничку сомнительного вида архивами и программами. Несмотря на то, что для FTP подходит другой механизм шифрования, называемый TLS, далеко не все FTP-клиенты его поддерживают, и он оказывается не востребован на серверах. Поэтому рекомендуется использовать службу FTP только для огранизации архивов публичного доступа.
Терминальный доступ
Текстовый интерфейс позволяет пользователю Linux работать на компьютере удалённо с помощью терминального клиента. Весьма удобно, находясь далеко от компьютера, управлять им самым естественным способом, с помощью командной строки. Препятствий этому немного: объём передаваемых по сети данных крайне невелик, ко времени отклика в полсекунды вполне можно привыкнуть, а если оно меньше десятой доли секунды, то задержка и вовсе не мешает. Что необходимо соблюдать строго, так это шифрование учётных записей при подключении к удалённому компьютеру, а на самом деле, и самого сеанса терминальной связи, так как в ним вполне может "засветиться" пароль: например, пользователь заходит на удалённый компьютер и выполняет команду passwd.
Как уже говорилось в этих лекциях, сначала для терминального доступа использовался протокол TELNET и соответствующая пара клиент-сервер telnet-telnetd. От них пришлось отказаться в силу их вопиющей небезопасности. На смену TELNET пришла служба Secure Shell ("Надёжная Оболочка"), также состоящая из пары клиент-сервер -- ssh и sshd. Шифрование данных в Secure Shell огранизовано по принципу "асимметричных ключей", который позволяет более гибко шифровать или идентифицировать данные, чем более распростанённый и привычный принцип "симметричных ключей". Симметричный ключ -- это пароль, которым данные можно зашифровать, и им же потом расшифровать.
Упрощённо метод "асимметричных ключей" можно описать так. Используется алгоритм, при котором специальным образом выбранный пароль для шифрования данных не совпадает с соответствующим ему паролем для их расшифровки. Более того, зная любой один из этих паролей, никак нельзя предугадать другой. Некто, желая, чтобы передаваемые ему данные нельзя было подсмотреть, раздаёт всем желающим шифрующий пароль со словами: "будете писать мне -- шифруйте этим", т. е. делает этот пароль открытым. Дешифрующий пароль он хранит в строгой тайне, никому не открывая. В результате зашифровать данные его паролем может любой, а расшифровать (что и значит -- подглядеть) -- может только он. Цель достигнута.
Тот же принцип используется для создания т. н. электронной подписи, помогающей иднтифициорвать данные, то есть определить их автора. На этот раз открытым делается дешифрующий ключ (конечно, не тот, о котором только что шла речь, а ещё один). Тогда любой, получив письмо и расшифровав его, может быть уверен, что это письмо написал этот автор -- потому что шифрующим ключом не владеет больше никто.
Здесь уместно сделать два замечания. Во-первых, алгоритмы шифрования с асимметричными ключами весьма ресурсоёмки, поэтому в Secure Shell (и упомянутом ранее SSL) они используются только на начальном этапе установления соединения. Обмен данными шифруется симметричным ключом, но, поскольку сам этот ключ был защищён асимметричным, соединение считается надёжным. Во-вторых этот кажущийся надёжным алгоритм имеет серьёзный изъян, с которым, впрочем, нетрудно справиться. Опасность таится в самом начале: как, получив от товарища открытый ключ, удостовериться, что этот ключ действительно ему принадлежит? А вдруг на пути от товарища ключ был перехвачен злоумышленником, и до нас дошёл уже его, злоумышленника, открытый ключ? Мы легкомысленно шифруем наши данные этим ключом, злоумышленник переватывает их на обратном пути, просматривает их (только он и может это сделать, так как подсунул нам свой шифрующий пароль), и обманывает таким же манером товарища, притворяясь на этот раз нами.
Такая уязвимость называется "man-in-the-middle" (дословно "человек-посередине"), всоего рода "испорченный телефон". Есть два способа борьбы с ней. Первый: не доверять никаким открытым ключам, кроме тех, которые получил лично от товарища. Если с товарищем вы незнакомы, можете попросить у него удостоверение личности: а вдруг он всё-таки злоумышленник? Второй способ: получить от товарища открытый ключ несколькими независимыми путями. В этом случае подойдёт т. н. "отпечаток пальца" (fingerprint) -- получаемая из ключа контрольная сумма такого размера, что подделать её ещё невозможно, но уже нетрудно сравнить с этой же контрольной суммой, размещённой на WWW-странице или присланной по электронной почте.
Пересылка почты
Ещё один немаловажный сервис, отлично поддерживаемый в Linux, -- пересылка электронной почты. Протокол SMTP (Simple Mail Transfer Protocol), задающий порядок пересылки почты, впервые был описан и помещён в RFC в самом начале 80-х годов. С тех пор он неоднократно модифицировался, однако в основе своей остался прежним: SMTP -- это протокол передачи текстовых сообщений, снабжённых вспомогательными заголовками, часть из которых предназначена для почтового сервера, передающего сообщения, а часть -- для почтового клиента, с помощью которого пользователь просматривает эти сообщения.
RCF |
Постоянно пополняемое собрание рабочих материалов (технических отчётов, проектов и описаний стандартов протоколов), используемых разработчиками и пользователями Internet. |
В качестве адреса в электронном письме обычно используется сочетание пользователь@доменное_имя. Изначально поле пользователь совпадало с входным именем пользователя в UNIX-системе, а доменное_имя -- с именем компьютера. Пользователь -- удалённо или через "настоящий" терминал -- подключался к системе и просматривал почту, скажем, утилитой mail. Когда компьютеров в сети стало больше, выяснилось, что, имея учётные записи на многих машинах, почту всё-таки удобнее хранить и читать на одной, только для почты предназначенной, а значит, доменное_имя в почтовом адресе может не совпадать с доменным именем персонального компьютера адресата. Для удобства решили ввести один уровень косвенности: прежде, чем соединяться с компьютером "доменное_имя", почтовый сервер проверяет, нет ли в 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, предназначенный для работы на больших и очень больших серверах, выполняющих, в-основном, работу по пересылке.
Доступ к почтовым ящикам
Электронная почта нужна далеко не только тем, кто имеет терминальный доступ Linux-машине. Доступ к почтовому ящику на сервере не должен зависеть от того, есть ли у данного пользователя право запускать на этом сервере какие-то программы. Для этого необходимо организовать специальную службу, предоставляющую пользователю только возможность манипулировать сообщениями в своём ящике с помощью программы-клиента. Самые популярные протоколы доступа к ящикам -- POP3 (Post Office Protocol версии 3) и IMAP4 (Internet Message Access Protocol версии 4).
POP3 -- довольно простой протокол, в нём определён единственный почтовый ящик пользователя, где тот может посмотреть список заголовков сообщений, прочитать (скачать) некоторые из них и удлалить некоторые из них. Такой протокол удобен, когда пользователь хранит всю переписку на своём компьютере, а удалённый почтовый ящик служит исключительно для приёма входящей почты. Протокол IMAP4 гораздо сложнее: в нём разрешено заводить несколько ящиков на сервере, в том числе и вложенных подобно каталогам. Каждый их этих ящиков может обладать особыми свойствами: может быть входящим (тогда пользователь уведомляется о новых поступлениях в этот ящик), мусорной корзиной (сообщения из которой удаляются после того, как устареют), и даже быть исходящим (в такой ящик пользователь складывает новые письма, а сервер их через некоторое время отсылает, удаляя оттуда). IMAP4 подходит для ситуации, когда пользователь не имеет возможности хранить свою переписку и/или обрабатывать её с одного и того же компьютера, поэтому хранит её в ящиках на сервере. IMAP4 используют и в качестве "движка" т. н. WEB-почты, этого заменителя почтовых клиентов для торопливых.
В большинстве случаев с помощью одного и того же почтового клиента можно и просматривать электронные письма в ящиках, и создавать новые письма, и отсылать их. Это сделано для удобства пользователя, однако стоит понимать, что общее у этих трёх действий -- только формат сообщения. Строго говоря, при доступе к почтовому ящику совершенно неважно, каким путём там оказалось письмо, а при пересылке почты никак не определяет, каким способом пользователь будет её читать. Что касается написания письма -- чьё же это дело, как не текстового редактора?
Как водится, в Linux есть несколько IMAP/POP-серверов. Наиболее мощный из них -- Cyrus (его авторы участвовали в расзработке протокола IMAP4), в нём поддерживается больше всего дополнений и расширений IMAP, которые бывает удобно использовать, наиболее простой -- UW-IMAP, разрабатываемый в университете штата Вашингтон. UW-IMAP вообще не имеет конфигурационного файла: пользователи, пароли, входящие почтовые ящики и домашние каталоги для личных почтовых ящиков берутся системные (при этом вместо командного интерпретатора почтовому пользователью можно выдать /sbin/nologin или /usr/bin/passwd). Сервер Binc можно рекомендовать на системах, использующих QMail, интеграция с которым других IMAP-серверов имеет некоторые шероховатости, а сервер Dovecot -- тем, кто, как и его авторы, в первую очередь озабочен надёжностью работы сервиса(2).
Протоколы POP3 и IMAP4, как и многие другие, -- текстовые. Как и в большинстве других протоколов, это порождает проблему передачи пароля в открытом виде. Решается она так же, как и для других протоколов -- "заворачиванием" всего сеанса в SSL (порту 110--POP3 соответствует порт 995--POP3S, а порту 143--IMAP4 -- 993--IMAPS), либо использование внутрисеансового шифрования с помощью TLS. Кроме того, в протоколе POP3 есть и собственное расширение, APOP, решающее ту же задачу. Здесь Мфодий опять вспомнил своего незадачливого приятеля: чтобы не сильно задумываться, тот всегда испльзовал один и тот же пароль, в том числе и для доступа к почте по протоколу POP3 безо всяких SSL/TLS/APOP... Увы, и эта беззаботность ему даром не прошла: однажды его учётной записью кто-то воспользовался для отсылки почты с помощью SMTPAUTH. Конечно же, это оказался спам, и приятель ещё долго расхлёбывал неприятности.
(1) Конечно, сами файлы при этом должны быть исполняемыми.
(2) Точнее, потенциальной ненадёжностью, так как все перечисленные службы, конечно, тоже работают исправно.