Итак, с работой сети в 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, нередко "сажают в песочницу", то есть переносят в отдельный каталог, в котором выполняется chroot. Как сказано в лекции 12, в такой "песочнице" должны быть все нужные для работы файлы – и уж конечно процедурам DNS необходим свой файл-копия /etc/resolv.conf. Информация о том, кому и что нужно копировать при изменении профиля системы, обычно хранится централизованно и управляется несложными сценариями. В данном дистрибутиве команда update_chrooted conf как раз и копирует все изменившиеся конфигурационные файлы по "песочницам".
Мефодий очень обрадовался заработавшей сети и немедленно принялся сочинять простейший /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/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 содержит множество сценариев на все случаи сетевой жизни. В файле 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 – снова появятся.
Как правило, пользователю вообще не обязательно редактировать эти файлы. С каждым дистрибутивом поставляется программа-конфигуратор, которая позволяет "настроить сеть", не вспоминая, какие данные, в каком формате и куда их нужно записывать. Обычно такая программа оформляется в стиле
В некоторых дистрибутивах используется схема 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
Настройка сетевых интерфейсов и options. Каталоги if-preup.d, if-up.d, if-down.d и if-post-down.d предназначены для служб, которые хотят производить какие-то действия, соответственно, перед тем, как сетевой интерфейс будет активизирован ("поднят"), после успешной активизации интерфейса, перед тем как сетевой интерфейс будет деактивизирован ("опущен") и после этого.
Программа-настройщик регулярно предлагала Мефодию "настроить сеть автоматически". В режиме автоматической настройки практически не запрашиваются данные у пользователя. Это значит, что данные система должна брать откуда-то еще, видимо, со специального сервера в локальной сети.
Запрашивать сетевые настройки с сервера вместо того, чтобы хранить их на каждом компьютере, довольно удобно. В самом деле: один сервер, один администратор, один файл с общими настройками. Более того, можно вообще не хранить персональных настроек для каждого компьютера в сети, а ограничиться настройками групповыми – лишь бы IP-адреса внутри группы различались. Одним из первых был разработан
В современных сетях чаще всего используется протокол DHCP ( D ynamic H ost C onfiguration P rotocol, протокол динамической настройки сетевых абонентов). Он имеет очень широкие возможности: с сервера можно получить IP-адрес, 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 . . .
Протокол DHCP позволяет передавать серверу желаемое имя и адрес компьютера. Впрочем, выдача IP-адреса привязана, как правило, к MAC-адресу. Здесь есть особая хитрость. DHCP может неплохо работать, когда IP-адресов не хватает на всех: компьютеров с разными MAC-адресами в сети больше, чем выделенных IP, но эти компьютеры никогда не включаются все одновременно. Компьютер, определяемый в DHCP по MAC-адресу, не "присваивает" выданный 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
Если компьютер стоит дома, далеко не всегда есть возможность подключиться к локальной сети, непосредственно граничащей с Internet. Для передачи небольших сообщений чаще всего используется временное подключение посредством телефонной линии. На обеих сторонах линии устанавливается
Соединение между двумя устройствами, вообще говоря, не сетевыми, а только способными передавать данные, описывается несколькими протоколами. Самый распространенный из них – PPP ( P oint-to- P oint P rotocol, протокол "точка–точка") – решает задачи, возникающие в силу особенностей соединений "точка–точка".
Во-первых, само участвующее в соединении устройство почти никогда не бывает представлено в виде сетевого интерфейса, потому что не обладает нужными для организации сети свойствами. Это значит, что какая-то часть системы (скорее всего,
Во-вторых, нет необходимости поддерживать часть интерфейсного протокола: на среде передачи данных два абонента , никакой ppp0, соответствующий устройству, обменивающемуся данными по протоколу PPP, не обладает MAC-адресом.
В-третьих, оттого, что соединение не постоянное, а среда за время, пока абоненты не были связаны, могла измениться до неузнаваемости, обеим сторонам приходится при каждом дозвоне идентифицировать себя. Обычно идентифицируется только сторона, которой предоставляется доступ в сеть, но проверять, до нужного ли места мы дозвонились, тоже не мешает. При установлении соединения "точка–точка" процедуры
В силу того, что дозвон нужен пользователям самого разного уровня знаний, для PPP написано множество программ-"звонилок", использующих графическую подсистему, со звуками и прочими не относящимися к делу украшениями. Пример такой программы – kppp, утилита модемного доступа для рабочего стола KDE. Все, что требуется от пользователя – это указать PPP, а открытым текстом, на манер "login–password" в Linux. Иногда это и есть самый настоящий login: пользователю предоставляется терминальный доступ, а дальше пускай делает, что хочет. В этом случае приходится писать "login:" – ввести "Password:" – ввести пароль. Дождаться подсказки командного интерпретатора – ввести " с параметрами".
Что совсем уже просто для пользователя, так это утилита wvdial, описанная в лекции 12. Она и /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 (в зависимости от особенностей соединения и пристрастий провайдера могут применяться протоколы /etc/shadow, нельзя, так что остается либо надеяться на права доступа к этим файлам, либо запускать wvdial и kppp ) и каждый раз этот пароль вводить.
Установить PPP-соединение можно поверх любой среды передачи данных, в том числе и поверх локальной сети. В этом случае pty – tty или ptmx – pts/, описанной в лекции 11) с initrd записываются в перепрограммируемое ПЗУ.
В Linux существует мощный механизм анализа сетевых и транспортных пакетов, позволяющий избавляться от нежелательной сетевой активности, манипулировать потоками данных и даже преобразовывать служебную информацию в них. Обычно такие средства носят название "firewall" ("fire wall" – противопожарная стена, брандмауэр), общепринятый русский термин – ipchains, который впоследствии был заменен на более мощный, iptables.
Суть iptables в следующем. Обработка сетевого пакета системой представляется как его
Между каждыми из этих действий системы помещается модуль FORWARD ). Цепочка, обслуживающая связку "получить – маршрутизировать", называется PREROUTING, цепочка, обслуживающая связку "маршрутизировать – отдать" – INPUT, а цепочка, стоящая непосредственно перед отсылкой пакета – POSTROUTING:
В варианте (рис 15.1) Обработка пакетов цепочками iptablesЕсли пакет не имеет свойств, требуемых первым правилом, к нему применяется второе, если второе также не подходит – третье, и так вплоть до последнего, правила по умолчанию, которое применяется к любому пакету. Если свойства пакета удовлетворяют правилу, над ним совершается действие. Действие DROP уничтожает пакет, а действие ACCEPT немедленно выпускает его из таблицы, после чего пакет движется дальше по LOG, никак не влияют на судьбу пакета, после их выполнения он остается в таблице: к нему применяется следующее правило, и т. д. до ACCEPT или DROP.
Из сказанного выше следует, что действия ACCEPT или DROP в каждой таблице могут применяться к пакету лишь однократно. Для большей гибкости ACCEPT, на filter – для определения того, не стоит ли пакет уничтожить, а таблицу nat – для подмены сетевых адресов. В приведенной выше диаграмме буквами M, N и F отмечено, какие именно таблицы есть в цепочках и в каком порядке их проходит пакет.
Для просмотра правил во всех таблицах всех 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
Команда группирует одинаковые таблицы каждой цепочки. В пустой таблице присутствует только правило по умолчанию (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 ]
Команды iptables получаются довольно длинными: нужно аккуратно описать свойства каждого фильтруемого пакета. В примере Мефодий добавил два правила в таблицу filter цепочки INPUT (таблица filter выбирается по умолчанию, если не указан ключ "-t таблица "). Первое правило разрешает принимать TCP-пакеты, адресуемые на порт 26000, если они пришли из интерфейса lo. Проверка таких пакетов не дойдет до второго правила: по действию ACCEPT они немедленно отправятся дальше по DROP клиент некоторое время дожидается подтверждения). Из примера видно, что iptables можно заменять однобуквенными. Кроме того, пример показывает, что iptables (в этом дистрибутиве) обрабатывает параметр save, который делает изменения, внесенные вручную, постоянными ( service iptables start, выполняемый при загрузке системы, использует /etc/sysconfig/iptables ).
Если в некоторой сети используются адреса из описанного стандартом RFC1918 внутреннего диапазона (например, из сети 10.0.0.0/8 ), то без дополнительных действий абоненты этой сети доступа к Internet иметь не будут. Пакеты с такими адресами запрещено передавать в Internet, а даже если они туда просочатся через
Допустим, абоненты с адресом 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-адресами отправителя и получателя, портами на отправителе и получателе и
Этот механизм носит название "преобразование сетевых адресов" ( N etwork A dress T ranslation, NAT). Следует помнить, что чем больше транспортных соединений отслеживается 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 . . .
На том самом nat цепочки POSTROUTING. Действие SNAT (Source NAT) только тем, что может быть использовано на интерфейсах с изменяемым IP-адресом, таких как ppp или настраиваемый по DHCP eth. Если в процессе работы IP-адрес интерфейса поменяется, правило SNAT продолжит менять адреса на старый, заданный во время настройки iptables. Зато
Преобразование адресов работает не только для 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 требует, с одной стороны, отдельного курса лекций, а с другой стороны – хорошей теоретической и практической подготовки слушателя. Так что придется ограничиться поверхностным описанием наиболее востребованных для личного или домашнего пользования сервисов. Стоит заранее отметить, что описываемые задачи, как правило, могут решаться несколькими путями с помощью различных
Мефодий, конечно, знает, что Internet как глобальная сеть компьютеров служит хранилищем глобальной сети документов под общим названием WWW ( W orld W ide W eb, "Всемирная Паутина"). Связь между документами в Паутине обеспечивается за счет особого – гипертекстового – формата этих документов. Большинство из них написаны на специальном
Apache – HTTP-сервер, обладающий самым большим набором возможностей. Учитывая организованный в нем механизм /etc/httpd/conf (или, в зависимости от дистрибутива, /etc/apache ). Главный конфигурационный файл –
DirectoryIndex index.html index.htm index.shtml index.cgi AccessFileName .htaccess DocumentRoot "/home/bitrix/www" Options Indexes Includes FollowSymLinks MultiViews AllowOverride None Order allow,deny Allow from all ScriptAlias /cgi-bin/ "/var/www/cgi-bin/" AllowOverride None Options ExecCGI Order deny,allow Deny from all Allow from 127.0.0.1 localhost
Пользователь, набравший в броузере "http://доменное_имя_сервера", увидит содержимое каталога, указанного настройкой DocumentRoot (в примере – /home/bitrix/www ). Каждый каталог, содержащий WWW-страницы, должен быть описан группой настроек, включающей права доступа к страницам этого каталога, настройки особенностей просмотра этих страниц и т. п. В частности, настройка DirectoryIndex описывает, какие файлы в каталоге считаются индексными – если такой файл есть в каталоге, он будет показан вместо содержимого этого каталога. Если в настройке каталога Options не указано значение Indexes, просмотр каталога будет вообще невозможен. Значение Includes этой настройки позволяет WWW-страницам включать в себя текст из других файлов, FollowSymLinks позволяет серверу работать с каталогами и файлами, на которые указывают символьные ссылки (это может вывести точку доступа за пределы DocumentRoot!), а
Если настройку каталога AllowOverride установить в All, в любом его подкаталоге можно создать дополнительный конфигурационный файл, изменяющий общие свойства каталога. Имя этого файла задает настройка AccessFileName (в примере – ".htaccess" ). Доступом к страницам в каталоге управляют настройки Order, Deny и Allow. Так, доступ к каталогу /home/bitrix/www разрешен отовсюду, а к каталогу /var/www/cgi-bin – только с самого сервера.
Важное свойство WWW-серверов – поддержка так называемых динамических WWW-страниц. Динамическая WWW-страница не хранится на диске в том виде, в котором ее получает пользователь. Она создается – возможно, на основании какого-то шаблона – непосредственно после запроса со стороны броузера. Никаких особенных расширений протокола HTTP при этом можно не вводить – просто сервер получает запрос на WWW-страницу, которой не соответствует ни один файл. Зато HTTP-адрес (точнее говоря, URL) этой страницы распознается сервером как динамический и передается на обработку выделенной для этого программе. Программа генерирует текст в формате HTML, который и передается пользователю в качестве запрошенной страницы. В примере для этого используется каталог
Как и многие другие прикладные протоколы, HTTP был и остается текстовым. При желании можно выучить команды HTTP и получать странички с серверов с помощью telnet вручную. Это означает, что любая система mod_ssl, его настройки и способ организации защищенной службы можно найти в документации.
Несмотря на то, что Apache решает практически любые задачи, связанные с организацией WWW-страниц, есть, конечно, и области, где его применение нежелательно или невозможно. Если, например, задача WWW-сервера – отдавать десяток-другой статически оформленных страниц небольшому числу клиентов, запускать для этого Apache – все равно что стрелять из пушки по воробьям. Лучше воспользоваться сервером thttpd, специально для таких задач предназначенным: он займет намного меньше ресурсов системы. Особая ситуация возникает, если самый важный параметр сервера – его быстродействие. Например сервер, раздающий так называемые "баннеры" (banners, небольшие картинки рекламного характера), приносит тем больше дохода, чем быстрее работает, а значит, может обслуживать больше клиентов. Способ радикально уменьшить время отклика такого сервера на HTTP-запрос – оформить его не в виде tux.
В Linux существует несколько вариантов службы, предоставляющей доступ к файлам по протоколу FTP ( F ile T ransfer P rotocol). Как правило, они отличаются друг от друга сложностью настроек, ориентированных на разные категории абонентов, подключающихся к серверу. Если выбор предоставляемых в открытый доступ данных велик, будет велик и наплыв желающих эти данные получить ("скачать"), так что возникает естественное желание этот наплыв ограничить. При этом, допустим, компьютеры из локальной сети могут неограниченно пользоваться файловыми ресурсами сервера, соединений из того же города или в пределах страны должно быть не более двух десятков одновременно, а соединений из-за границы – не более пяти. Такие ухищрения бывают нужны нечасто, но и они поддерживаются большинством FTP-демонов, вроде vsftpd, proftpd, wu-.
FTP – по-своему очень удобный протокол: он разделяет поток команд и поток собственно данных. Дело в том, что команды FTP обычно очень короткие, и серверу выгоднее обрабатывать их как можно быстрее, чтобы подолгу не держать ради них (часто – ради одной команды) открытое TCP-соединение. А вот файлы, передаваемые с помощью FTP, обычно большие, поэтому задержка при передаче в несколько долей секунды, и даже в пару секунд, не так существенна, зато играет роль пропускная способность канала. Было бы удобно, если бы для передачи команд использовался "быстрый, но тонкий" канал (т. е. среда передачи данных с малым временем отклика и небольшой пропускной способностью, например, наземное оптоволокно), а для передачи данных – "медленный, но толстый" (например, спутниковая магистраль).
Для того чтобы эти каналы было проще различить, данные в FTP пересылаются по инициативе сервера, то есть именно сервер подключается к клиенту, а не наоборот. Делается это так: клиент подключается к 21-му порту сервера ( управляющий порт FTP) и передает ему команду: "Хочу такой-то файл. Буду ждать твоего ответа на таком-то (временно выделенном) порту". Сервер подключается со своего 20-го порта (порт данных FTP) к порту на клиенте, указанном в команде, и пересылает содержимое запрошенного файла, после чего связь по данным разрывается и клиент перестает обрабатывать подключения к порту.
Трудности начинаются, когда FTP-клиент находится за файл. Но пассивно". Сервер: "А. Тогда забирай его у меня с такого-то порта ". Клиент подключается к порту сервера и получает оттуда содержимое файла. Если со стороны сервера тоже находится бдительный администратор, он может не разрешить подключаться любому абоненту Internet к любому порту сервера. Тогда не будет работать как раз
Еще один недостаток протокола FTP: в силу двухканальной природы его трудно "затолкать" в SSL-соединение. Поэтому
Текстовый интерфейс позволяет пользователю Linux работать на компьютере удаленно с помощью терминального клиента. Весьма удобно, находясь далеко от компьютера, управлять им самым естественным способом, с помощью командной строки. Препятствий этому немного: объем передаваемых по сети данных крайне невелик, ко времени отклика, занимающего полсекунды, вполне можно привыкнуть, а если оно меньше десятой доли секунды, то задержка и вовсе не мешает. Что необходимо соблюдать строго, так это шифрование учетных записей при подключении к удаленному компьютеру, а на самом деле, и самого сеанса терминальной связи, так как в нем вполне может "засветиться" пароль: например, пользователь заходит на удаленный компьютер и выполняет команду passwd.
Как уже говорилось в предыдущих лекциях, сначала для терминального доступа использовался протокол TELNET и соответствующая пара клиент-сервер telnet-telnetd. От них пришлось отказаться в силу их вопиющей небезопасности. На смену TELNET пришла служба Secure Shell ("Надежная оболочка"), также состоящая из пары клиент-сервер – ssh и sshd. Шифрование данных в Secure Shell организовано по принципу "асимметричных ключей", который позволяет более гибко шифровать или идентифицировать данные, чем более распространенный и привычный принцип "симметричных ключей". Симметричный ключ – это пароль, которым данные можно зашифровать, и с помощью него же потом расшифровать.
Упрощенно метод "асимметричных ключей" можно описать так. Используется алгоритм, при котором специальным образом выбранный пароль для шифрования данных не совпадает с соответствующим ему паролем для их расшифровки. Более того, зная любой из этих паролей, никак нельзя предугадать другой. Некто, желая, чтобы передаваемые ему данные нельзя было подсмотреть, раздает всем желающим шифрующий пароль со словами: "будете писать мне – шифруйте этим", т. е. делает этот пароль открытым. Дешифрующий пароль он хранит в строгой тайне, никому не открывая. В результате зашифровать данные его паролем может любой, а расшифровать (что и значит – подглядеть) – может только он. Цель достигнута.
Тот же принцип используется для создания так называемой
Здесь уместно сделать два замечания. Во-первых, алгоритмы шифрования с асимметричными ключами весьма ресурсоемки, поэтому в Secure Shell (и упомянутом ранее SSL) они используются только на начальном этапе установления соединения. Обмен данными шифруется симметричным ключом, но, поскольку сам этот ключ был защищен асимметричным, соединение считается надежным. Во-вторых этот кажущийся надежным алгоритм имеет серьезный изъян, с которым, впрочем, нетрудно справиться. Опасность таится в самом начале: как, получив от товарища злоумышленником, и до нас дошел уже его, злоумышленника, Мы легкомысленно шифруем наши данные этим ключом, злоумышленник перехватывает их на обратном пути, просматривает их (только он и может это сделать, так как подсунул нам свой шифрующий пароль), и обманывает таким же манером товарища, притворяясь на этот раз нами.
Такая уязвимость называется "man-in-the-middle" (дословно "человек посередине"), своего рода "испорченный телефон". Существует два способа борьбы с ней. Первый: не доверять никаким товарища. Если с товарищем вы незнакомы, можете попросить у него удостоверение личности: а вдруг он все-таки злоумышленник? Второй способ: получить от товарища
Еще один немаловажный сервис, отлично поддерживаемый в Linux, – пересылка электронной почты. Протокол SMTP ( S imple M ail T ransfer P rotocol), задающий порядок пересылки почты, впервые был описан и помещен в
В качестве адреса в электронном письме обычно используется сочетание пользователь@доменное_имя. Изначально поле пользователь совпадало с доменное_имя – с именем компьютера. Пользователь – удаленно или через "настоящий" терминал – подключался к системе и просматривал почту, скажем, утилитой mail. Когда компьютеров в сети стало больше, выяснилось, что, имея учетные записи на многих машинах, почту все-таки удобнее хранить и читать на одной машине, предназначенной только для почты, а значит, доменное_имя в почтовом адресе может не совпадать с доменным именем персонального компьютера адресата. Для удобства решили ввести один уровень косвенности: прежде чем соединяться с компьютером " доменное_имя ", почтовый сервер проверяет, нет ли в DNS записи вида доменное_имя ... MX ... сервер. Эта запись означает, что почту, адресованную на пользователь@доменное_имя, необходимо посылать компьютеру " сервер " – а уж тот разберется, что делать дальше.
Иногда необходимо, чтобы сервер принимал письма, не предназначенные для зарегистрированных на нем пользователей. Эти письма немедленно помещаются в очередь на отправку, и пересылаются дальше. Такой режим работы сервера называется "relay" (пересыльщик). Когда-то все почтовые серверы работали в режиме "open relay", т. е. соглашались пересылать почту откуда угодно и куда угодно. К сожалению, этим немедленно стали пользоваться желающие подзаработать массовой рассылкой рекламы (т. е. "спамом"). Поэтому открытые пересыльщики сегодня запрещены
В Linux существует несколько различных почтовых серверов. Во-первых, Sendmail, корифей почтового дела, возникший одновременно с SMTP. Возможности этого сервера весьма велики, однако воспользоваться ими в полной мере можно только после того, как научишься понимать и исправлять содержимое конфигурационного файла sendmail.cf, который уже более двадцати лет служит примером самого непонятного и заумного способа настройки. Впрочем, на сегодня для sendmail.cf на языке препроцессора m4 написано несметное, на все случаи жизни, число макросов, так что sendmail.cf редактировать не приходится. Вместо него из этих макросов составляется файл sendmail.mc, небольшой и вполне читаемый, а он, с помощью утилиты m4, транслируется в sendmail.cf, который не читает никто, кроме самого Sendmail. К сожалению, упростить исходный текст этой программы невозможно, поэтому специалисты по компьютерной безопасности не любят давать относительно нее гарантии: редко, но все же находится в sendmail какое-нибудь уязвимое место.
Другой вариант почтового сервера, Postfix, весьма гибок в настройке, прекрасно подходит для почтовых серверов масштаба предприятия, и, в отличие от Sendmail, более прозрачно спроектирован и написан. Он поддерживает все хитрости, необходимые современной почтовой службе: виртуальных пользователей, виртуальные домены, подключаемые антивирусы, средства борьбы со спамом и т. п. Настройка его хорошо документирована, в том числе с помощью комментариев в конфигурационном файле (как правило, /etc/postfix/main.cf ), и с помощью файлов-примеров.
Стоит упомянуть еще как минимум три почтовых службы: QMail – по мнению многих, этот
Электронная почта нужна далеко не только тем, кто имеет терминальный доступ к Linux-машине. Доступ к
POP3 – довольно простой протокол, в нем определен единственный
В большинстве случаев с помощью одного и того же почтового клиента можно и просматривать электронные письма в ящиках, и создавать новые письма, и отсылать их. Это сделано для удобства пользователя, однако стоит понимать, что общее у этих трех действий – только формат сообщения. Строго говоря, при доступе к
Как водится, в Linux есть несколько IMAP/POP-серверов. Наиболее мощный из них – Cyrus (его авторы участвовали в разработке протокола IMAP4). В нем поддерживается больше всего дополнений и расширений IMAP, которые бывает удобно использовать, наиболее простой – UWIMAP, разрабатываемый в университете штата Вашингтон. UW-IMAP вообще не имеет конфигурационного файла: пользователи, пароли, входящие
Протоколы POP3 и IMAP4, как и многие другие,являются текстовыми. Как и в большинстве других протоколов, это порождает проблему передачи пароля в открытом виде. Решается она так же, как и для других протоколов – "заворачиванием" всего сеанса в SSL (порту 110–POP3 соответствует порт 995–POP3S, а порту 143–IMAP4 – 993–IMAPS), либо использованием внутрисеансового шифрования с помощью TLS. Кроме того, в протоколе POP3 есть и собственное расширение, APOP, решающее ту же задачу. Здесь Мефодий опять вспомнил своего незадачливого приятеля: чтобы не сильно задумываться, тот всегда использовал один и тот же пароль, в том числе и для доступа к почте по протоколу POP3 без всяких SSL/TLS/APOP... Увы, эта беззаботность ему даром не прошла: однажды его учетной записью кто-то воспользовался для отправки почты с помощью SMTPAUTH – конечно же, это оказался спам.
Итак, с работой сети в 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, нередко "сажают в песочницу", то есть переносят в отдельный каталог, в котором выполняется chroot. Как сказано в лекции 12, в такой "песочнице" должны быть все нужные для работы файлы – и уж конечно процедурам DNS необходим свой файл-копия /etc/resolv.conf. Информация о том, кому и что нужно копировать при изменении профиля системы, обычно хранится централизованно и управляется несложными сценариями. В данном дистрибутиве команда update_chrooted conf как раз и копирует все изменившиеся конфигурационные файлы по "песочницам".
Мефодий очень обрадовался заработавшей сети и немедленно принялся сочинять простейший /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/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 содержит множество сценариев на все случаи сетевой жизни. В файле 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 – снова появятся.
Как правило, пользователю вообще не обязательно редактировать эти файлы. С каждым дистрибутивом поставляется программа-конфигуратор, которая позволяет "настроить сеть", не вспоминая, какие данные, в каком формате и куда их нужно записывать. Обычно такая программа оформляется в стиле
В некоторых дистрибутивах используется схема 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
Настройка сетевых интерфейсов и options. Каталоги if-preup.d, if-up.d, if-down.d и if-post-down.d предназначены для служб, которые хотят производить какие-то действия, соответственно, перед тем, как сетевой интерфейс будет активизирован ("поднят"), после успешной активизации интерфейса, перед тем как сетевой интерфейс будет деактивизирован ("опущен") и после этого.
Программа-настройщик регулярно предлагала Мефодию "настроить сеть автоматически". В режиме автоматической настройки практически не запрашиваются данные у пользователя. Это значит, что данные система должна брать откуда-то еще, видимо, со специального сервера в локальной сети.
Запрашивать сетевые настройки с сервера вместо того, чтобы хранить их на каждом компьютере, довольно удобно. В самом деле: один сервер, один администратор, один файл с общими настройками. Более того, можно вообще не хранить персональных настроек для каждого компьютера в сети, а ограничиться настройками групповыми – лишь бы IP-адреса внутри группы различались. Одним из первых был разработан
В современных сетях чаще всего используется протокол DHCP ( D ynamic H ost C onfiguration P rotocol, протокол динамической настройки сетевых абонентов). Он имеет очень широкие возможности: с сервера можно получить IP-адрес, 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 . . .
Протокол DHCP позволяет передавать серверу желаемое имя и адрес компьютера. Впрочем, выдача IP-адреса привязана, как правило, к MAC-адресу. Здесь есть особая хитрость. DHCP может неплохо работать, когда IP-адресов не хватает на всех: компьютеров с разными MAC-адресами в сети больше, чем выделенных IP, но эти компьютеры никогда не включаются все одновременно. Компьютер, определяемый в DHCP по MAC-адресу, не "присваивает" выданный 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
Если компьютер стоит дома, далеко не всегда есть возможность подключиться к локальной сети, непосредственно граничащей с Internet. Для передачи небольших сообщений чаще всего используется временное подключение посредством телефонной линии. На обеих сторонах линии устанавливается
Соединение между двумя устройствами, вообще говоря, не сетевыми, а только способными передавать данные, описывается несколькими протоколами. Самый распространенный из них – PPP ( P oint-to- P oint P rotocol, протокол "точка–точка") – решает задачи, возникающие в силу особенностей соединений "точка–точка".
Во-первых, само участвующее в соединении устройство почти никогда не бывает представлено в виде сетевого интерфейса, потому что не обладает нужными для организации сети свойствами. Это значит, что какая-то часть системы (скорее всего,
Во-вторых, нет необходимости поддерживать часть интерфейсного протокола: на среде передачи данных два абонента , никакой ppp0, соответствующий устройству, обменивающемуся данными по протоколу PPP, не обладает MAC-адресом.
В-третьих, оттого, что соединение не постоянное, а среда за время, пока абоненты не были связаны, могла измениться до неузнаваемости, обеим сторонам приходится при каждом дозвоне идентифицировать себя. Обычно идентифицируется только сторона, которой предоставляется доступ в сеть, но проверять, до нужного ли места мы дозвонились, тоже не мешает. При установлении соединения "точка–точка" процедуры
В силу того, что дозвон нужен пользователям самого разного уровня знаний, для PPP написано множество программ-"звонилок", использующих графическую подсистему, со звуками и прочими не относящимися к делу украшениями. Пример такой программы – kppp, утилита модемного доступа для рабочего стола KDE. Все, что требуется от пользователя – это указать PPP, а открытым текстом, на манер "login–password" в Linux. Иногда это и есть самый настоящий login: пользователю предоставляется терминальный доступ, а дальше пускай делает, что хочет. В этом случае приходится писать "login:" – ввести "Password:" – ввести пароль. Дождаться подсказки командного интерпретатора – ввести " с параметрами".
Что совсем уже просто для пользователя, так это утилита wvdial, описанная в лекции 12. Она и /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 (в зависимости от особенностей соединения и пристрастий провайдера могут применяться протоколы /etc/shadow, нельзя, так что остается либо надеяться на права доступа к этим файлам, либо запускать wvdial и kppp ) и каждый раз этот пароль вводить.
Установить PPP-соединение можно поверх любой среды передачи данных, в том числе и поверх локальной сети. В этом случае pty – tty или ptmx – pts/, описанной в лекции 11) с initrd записываются в перепрограммируемое ПЗУ.
В Linux существует мощный механизм анализа сетевых и транспортных пакетов, позволяющий избавляться от нежелательной сетевой активности, манипулировать потоками данных и даже преобразовывать служебную информацию в них. Обычно такие средства носят название "firewall" ("fire wall" – противопожарная стена, брандмауэр), общепринятый русский термин – ipchains, который впоследствии был заменен на более мощный, iptables.
Суть iptables в следующем. Обработка сетевого пакета системой представляется как его
Между каждыми из этих действий системы помещается модуль FORWARD ). Цепочка, обслуживающая связку "получить – маршрутизировать", называется PREROUTING, цепочка, обслуживающая связку "маршрутизировать – отдать" – INPUT, а цепочка, стоящая непосредственно перед отсылкой пакета – POSTROUTING:
В варианте (рис 15.1) Обработка пакетов цепочками iptablesЕсли пакет не имеет свойств, требуемых первым правилом, к нему применяется второе, если второе также не подходит – третье, и так вплоть до последнего, правила по умолчанию, которое применяется к любому пакету. Если свойства пакета удовлетворяют правилу, над ним совершается действие. Действие DROP уничтожает пакет, а действие ACCEPT немедленно выпускает его из таблицы, после чего пакет движется дальше по LOG, никак не влияют на судьбу пакета, после их выполнения он остается в таблице: к нему применяется следующее правило, и т. д. до ACCEPT или DROP.
Из сказанного выше следует, что действия ACCEPT или DROP в каждой таблице могут применяться к пакету лишь однократно. Для большей гибкости ACCEPT, на filter – для определения того, не стоит ли пакет уничтожить, а таблицу nat – для подмены сетевых адресов. В приведенной выше диаграмме буквами M, N и F отмечено, какие именно таблицы есть в цепочках и в каком порядке их проходит пакет.
Для просмотра правил во всех таблицах всех 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
Команда группирует одинаковые таблицы каждой цепочки. В пустой таблице присутствует только правило по умолчанию (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 ]
Команды iptables получаются довольно длинными: нужно аккуратно описать свойства каждого фильтруемого пакета. В примере Мефодий добавил два правила в таблицу filter цепочки INPUT (таблица filter выбирается по умолчанию, если не указан ключ "-t таблица "). Первое правило разрешает принимать TCP-пакеты, адресуемые на порт 26000, если они пришли из интерфейса lo. Проверка таких пакетов не дойдет до второго правила: по действию ACCEPT они немедленно отправятся дальше по DROP клиент некоторое время дожидается подтверждения). Из примера видно, что iptables можно заменять однобуквенными. Кроме того, пример показывает, что iptables (в этом дистрибутиве) обрабатывает параметр save, который делает изменения, внесенные вручную, постоянными ( service iptables start, выполняемый при загрузке системы, использует /etc/sysconfig/iptables ).
Если в некоторой сети используются адреса из описанного стандартом RFC1918 внутреннего диапазона (например, из сети 10.0.0.0/8 ), то без дополнительных действий абоненты этой сети доступа к Internet иметь не будут. Пакеты с такими адресами запрещено передавать в Internet, а даже если они туда просочатся через
Допустим, абоненты с адресом 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-адресами отправителя и получателя, портами на отправителе и получателе и
Этот механизм носит название "преобразование сетевых адресов" ( N etwork A dress T ranslation, NAT). Следует помнить, что чем больше транспортных соединений отслеживается 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 . . .
На том самом nat цепочки POSTROUTING. Действие SNAT (Source NAT) только тем, что может быть использовано на интерфейсах с изменяемым IP-адресом, таких как ppp или настраиваемый по DHCP eth. Если в процессе работы IP-адрес интерфейса поменяется, правило SNAT продолжит менять адреса на старый, заданный во время настройки iptables. Зато
Преобразование адресов работает не только для 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 требует, с одной стороны, отдельного курса лекций, а с другой стороны – хорошей теоретической и практической подготовки слушателя. Так что придется ограничиться поверхностным описанием наиболее востребованных для личного или домашнего пользования сервисов. Стоит заранее отметить, что описываемые задачи, как правило, могут решаться несколькими путями с помощью различных
Мефодий, конечно, знает, что Internet как глобальная сеть компьютеров служит хранилищем глобальной сети документов под общим названием WWW ( W orld W ide W eb, "Всемирная Паутина"). Связь между документами в Паутине обеспечивается за счет особого – гипертекстового – формата этих документов. Большинство из них написаны на специальном
Apache – HTTP-сервер, обладающий самым большим набором возможностей. Учитывая организованный в нем механизм /etc/httpd/conf (или, в зависимости от дистрибутива, /etc/apache ). Главный конфигурационный файл –
DirectoryIndex index.html index.htm index.shtml index.cgi AccessFileName .htaccess DocumentRoot "/home/bitrix/www" Options Indexes Includes FollowSymLinks MultiViews AllowOverride None Order allow,deny Allow from all ScriptAlias /cgi-bin/ "/var/www/cgi-bin/" AllowOverride None Options ExecCGI Order deny,allow Deny from all Allow from 127.0.0.1 localhost
Пользователь, набравший в броузере "http://доменное_имя_сервера", увидит содержимое каталога, указанного настройкой DocumentRoot (в примере – /home/bitrix/www ). Каждый каталог, содержащий WWW-страницы, должен быть описан группой настроек, включающей права доступа к страницам этого каталога, настройки особенностей просмотра этих страниц и т. п. В частности, настройка DirectoryIndex описывает, какие файлы в каталоге считаются индексными – если такой файл есть в каталоге, он будет показан вместо содержимого этого каталога. Если в настройке каталога Options не указано значение Indexes, просмотр каталога будет вообще невозможен. Значение Includes этой настройки позволяет WWW-страницам включать в себя текст из других файлов, FollowSymLinks позволяет серверу работать с каталогами и файлами, на которые указывают символьные ссылки (это может вывести точку доступа за пределы DocumentRoot!), а
Если настройку каталога AllowOverride установить в All, в любом его подкаталоге можно создать дополнительный конфигурационный файл, изменяющий общие свойства каталога. Имя этого файла задает настройка AccessFileName (в примере – ".htaccess" ). Доступом к страницам в каталоге управляют настройки Order, Deny и Allow. Так, доступ к каталогу /home/bitrix/www разрешен отовсюду, а к каталогу /var/www/cgi-bin – только с самого сервера.
Важное свойство WWW-серверов – поддержка так называемых динамических WWW-страниц. Динамическая WWW-страница не хранится на диске в том виде, в котором ее получает пользователь. Она создается – возможно, на основании какого-то шаблона – непосредственно после запроса со стороны броузера. Никаких особенных расширений протокола HTTP при этом можно не вводить – просто сервер получает запрос на WWW-страницу, которой не соответствует ни один файл. Зато HTTP-адрес (точнее говоря, URL) этой страницы распознается сервером как динамический и передается на обработку выделенной для этого программе. Программа генерирует текст в формате HTML, который и передается пользователю в качестве запрошенной страницы. В примере для этого используется каталог
Как и многие другие прикладные протоколы, HTTP был и остается текстовым. При желании можно выучить команды HTTP и получать странички с серверов с помощью telnet вручную. Это означает, что любая система mod_ssl, его настройки и способ организации защищенной службы можно найти в документации.
Несмотря на то, что Apache решает практически любые задачи, связанные с организацией WWW-страниц, есть, конечно, и области, где его применение нежелательно или невозможно. Если, например, задача WWW-сервера – отдавать десяток-другой статически оформленных страниц небольшому числу клиентов, запускать для этого Apache – все равно что стрелять из пушки по воробьям. Лучше воспользоваться сервером thttpd, специально для таких задач предназначенным: он займет намного меньше ресурсов системы. Особая ситуация возникает, если самый важный параметр сервера – его быстродействие. Например сервер, раздающий так называемые "баннеры" (banners, небольшие картинки рекламного характера), приносит тем больше дохода, чем быстрее работает, а значит, может обслуживать больше клиентов. Способ радикально уменьшить время отклика такого сервера на HTTP-запрос – оформить его не в виде tux.
В Linux существует несколько вариантов службы, предоставляющей доступ к файлам по протоколу FTP ( F ile T ransfer P rotocol). Как правило, они отличаются друг от друга сложностью настроек, ориентированных на разные категории абонентов, подключающихся к серверу. Если выбор предоставляемых в открытый доступ данных велик, будет велик и наплыв желающих эти данные получить ("скачать"), так что возникает естественное желание этот наплыв ограничить. При этом, допустим, компьютеры из локальной сети могут неограниченно пользоваться файловыми ресурсами сервера, соединений из того же города или в пределах страны должно быть не более двух десятков одновременно, а соединений из-за границы – не более пяти. Такие ухищрения бывают нужны нечасто, но и они поддерживаются большинством FTP-демонов, вроде vsftpd, proftpd, wu-.
FTP – по-своему очень удобный протокол: он разделяет поток команд и поток собственно данных. Дело в том, что команды FTP обычно очень короткие, и серверу выгоднее обрабатывать их как можно быстрее, чтобы подолгу не держать ради них (часто – ради одной команды) открытое TCP-соединение. А вот файлы, передаваемые с помощью FTP, обычно большие, поэтому задержка при передаче в несколько долей секунды, и даже в пару секунд, не так существенна, зато играет роль пропускная способность канала. Было бы удобно, если бы для передачи команд использовался "быстрый, но тонкий" канал (т. е. среда передачи данных с малым временем отклика и небольшой пропускной способностью, например, наземное оптоволокно), а для передачи данных – "медленный, но толстый" (например, спутниковая магистраль).
Для того чтобы эти каналы было проще различить, данные в FTP пересылаются по инициативе сервера, то есть именно сервер подключается к клиенту, а не наоборот. Делается это так: клиент подключается к 21-му порту сервера ( управляющий порт FTP) и передает ему команду: "Хочу такой-то файл. Буду ждать твоего ответа на таком-то (временно выделенном) порту". Сервер подключается со своего 20-го порта (порт данных FTP) к порту на клиенте, указанном в команде, и пересылает содержимое запрошенного файла, после чего связь по данным разрывается и клиент перестает обрабатывать подключения к порту.
Трудности начинаются, когда FTP-клиент находится за файл. Но пассивно". Сервер: "А. Тогда забирай его у меня с такого-то порта ". Клиент подключается к порту сервера и получает оттуда содержимое файла. Если со стороны сервера тоже находится бдительный администратор, он может не разрешить подключаться любому абоненту Internet к любому порту сервера. Тогда не будет работать как раз
Еще один недостаток протокола FTP: в силу двухканальной природы его трудно "затолкать" в SSL-соединение. Поэтому
Текстовый интерфейс позволяет пользователю Linux работать на компьютере удаленно с помощью терминального клиента. Весьма удобно, находясь далеко от компьютера, управлять им самым естественным способом, с помощью командной строки. Препятствий этому немного: объем передаваемых по сети данных крайне невелик, ко времени отклика, занимающего полсекунды, вполне можно привыкнуть, а если оно меньше десятой доли секунды, то задержка и вовсе не мешает. Что необходимо соблюдать строго, так это шифрование учетных записей при подключении к удаленному компьютеру, а на самом деле, и самого сеанса терминальной связи, так как в нем вполне может "засветиться" пароль: например, пользователь заходит на удаленный компьютер и выполняет команду passwd.
Как уже говорилось в предыдущих лекциях, сначала для терминального доступа использовался протокол TELNET и соответствующая пара клиент-сервер telnet-telnetd. От них пришлось отказаться в силу их вопиющей небезопасности. На смену TELNET пришла служба Secure Shell ("Надежная оболочка"), также состоящая из пары клиент-сервер – ssh и sshd. Шифрование данных в Secure Shell организовано по принципу "асимметричных ключей", который позволяет более гибко шифровать или идентифицировать данные, чем более распространенный и привычный принцип "симметричных ключей". Симметричный ключ – это пароль, которым данные можно зашифровать, и с помощью него же потом расшифровать.
Упрощенно метод "асимметричных ключей" можно описать так. Используется алгоритм, при котором специальным образом выбранный пароль для шифрования данных не совпадает с соответствующим ему паролем для их расшифровки. Более того, зная любой из этих паролей, никак нельзя предугадать другой. Некто, желая, чтобы передаваемые ему данные нельзя было подсмотреть, раздает всем желающим шифрующий пароль со словами: "будете писать мне – шифруйте этим", т. е. делает этот пароль открытым. Дешифрующий пароль он хранит в строгой тайне, никому не открывая. В результате зашифровать данные его паролем может любой, а расшифровать (что и значит – подглядеть) – может только он. Цель достигнута.
Тот же принцип используется для создания так называемой
Здесь уместно сделать два замечания. Во-первых, алгоритмы шифрования с асимметричными ключами весьма ресурсоемки, поэтому в Secure Shell (и упомянутом ранее SSL) они используются только на начальном этапе установления соединения. Обмен данными шифруется симметричным ключом, но, поскольку сам этот ключ был защищен асимметричным, соединение считается надежным. Во-вторых этот кажущийся надежным алгоритм имеет серьезный изъян, с которым, впрочем, нетрудно справиться. Опасность таится в самом начале: как, получив от товарища злоумышленником, и до нас дошел уже его, злоумышленника, Мы легкомысленно шифруем наши данные этим ключом, злоумышленник перехватывает их на обратном пути, просматривает их (только он и может это сделать, так как подсунул нам свой шифрующий пароль), и обманывает таким же манером товарища, притворяясь на этот раз нами.
Такая уязвимость называется "man-in-the-middle" (дословно "человек посередине"), своего рода "испорченный телефон". Существует два способа борьбы с ней. Первый: не доверять никаким товарища. Если с товарищем вы незнакомы, можете попросить у него удостоверение личности: а вдруг он все-таки злоумышленник? Второй способ: получить от товарища
Еще один немаловажный сервис, отлично поддерживаемый в Linux, – пересылка электронной почты. Протокол SMTP ( S imple M ail T ransfer P rotocol), задающий порядок пересылки почты, впервые был описан и помещен в
В качестве адреса в электронном письме обычно используется сочетание пользователь@доменное_имя. Изначально поле пользователь совпадало с доменное_имя – с именем компьютера. Пользователь – удаленно или через "настоящий" терминал – подключался к системе и просматривал почту, скажем, утилитой mail. Когда компьютеров в сети стало больше, выяснилось, что, имея учетные записи на многих машинах, почту все-таки удобнее хранить и читать на одной машине, предназначенной только для почты, а значит, доменное_имя в почтовом адресе может не совпадать с доменным именем персонального компьютера адресата. Для удобства решили ввести один уровень косвенности: прежде чем соединяться с компьютером " доменное_имя ", почтовый сервер проверяет, нет ли в DNS записи вида доменное_имя ... MX ... сервер. Эта запись означает, что почту, адресованную на пользователь@доменное_имя, необходимо посылать компьютеру " сервер " – а уж тот разберется, что делать дальше.
Иногда необходимо, чтобы сервер принимал письма, не предназначенные для зарегистрированных на нем пользователей. Эти письма немедленно помещаются в очередь на отправку, и пересылаются дальше. Такой режим работы сервера называется "relay" (пересыльщик). Когда-то все почтовые серверы работали в режиме "open relay", т. е. соглашались пересылать почту откуда угодно и куда угодно. К сожалению, этим немедленно стали пользоваться желающие подзаработать массовой рассылкой рекламы (т. е. "спамом"). Поэтому открытые пересыльщики сегодня запрещены
В Linux существует несколько различных почтовых серверов. Во-первых, Sendmail, корифей почтового дела, возникший одновременно с SMTP. Возможности этого сервера весьма велики, однако воспользоваться ими в полной мере можно только после того, как научишься понимать и исправлять содержимое конфигурационного файла sendmail.cf, который уже более двадцати лет служит примером самого непонятного и заумного способа настройки. Впрочем, на сегодня для sendmail.cf на языке препроцессора m4 написано несметное, на все случаи жизни, число макросов, так что sendmail.cf редактировать не приходится. Вместо него из этих макросов составляется файл sendmail.mc, небольшой и вполне читаемый, а он, с помощью утилиты m4, транслируется в sendmail.cf, который не читает никто, кроме самого Sendmail. К сожалению, упростить исходный текст этой программы невозможно, поэтому специалисты по компьютерной безопасности не любят давать относительно нее гарантии: редко, но все же находится в sendmail какое-нибудь уязвимое место.
Другой вариант почтового сервера, Postfix, весьма гибок в настройке, прекрасно подходит для почтовых серверов масштаба предприятия, и, в отличие от Sendmail, более прозрачно спроектирован и написан. Он поддерживает все хитрости, необходимые современной почтовой службе: виртуальных пользователей, виртуальные домены, подключаемые антивирусы, средства борьбы со спамом и т. п. Настройка его хорошо документирована, в том числе с помощью комментариев в конфигурационном файле (как правило, /etc/postfix/main.cf ), и с помощью файлов-примеров.
Стоит упомянуть еще как минимум три почтовых службы: QMail – по мнению многих, этот
Электронная почта нужна далеко не только тем, кто имеет терминальный доступ к Linux-машине. Доступ к
POP3 – довольно простой протокол, в нем определен единственный
В большинстве случаев с помощью одного и того же почтового клиента можно и просматривать электронные письма в ящиках, и создавать новые письма, и отсылать их. Это сделано для удобства пользователя, однако стоит понимать, что общее у этих трех действий – только формат сообщения. Строго говоря, при доступе к
Как водится, в Linux есть несколько IMAP/POP-серверов. Наиболее мощный из них – Cyrus (его авторы участвовали в разработке протокола IMAP4). В нем поддерживается больше всего дополнений и расширений IMAP, которые бывает удобно использовать, наиболее простой – UWIMAP, разрабатываемый в университете штата Вашингтон. UW-IMAP вообще не имеет конфигурационного файла: пользователи, пароли, входящие
Протоколы POP3 и IMAP4, как и многие другие,являются текстовыми. Как и в большинстве других протоколов, это порождает проблему передачи пароля в открытом виде. Решается она так же, как и для других протоколов – "заворачиванием" всего сеанса в SSL (порту 110–POP3 соответствует порт 995–POP3S, а порту 143–IMAP4 – 993–IMAPS), либо использованием внутрисеансового шифрования с помощью TLS. Кроме того, в протоколе POP3 есть и собственное расширение, APOP, решающее ту же задачу. Здесь Мефодий опять вспомнил своего незадачливого приятеля: чтобы не сильно задумываться, тот всегда использовал один и тот же пароль, в том числе и для доступа к почте по протоколу POP3 без всяких SSL/TLS/APOP... Увы, эта беззаботность ему даром не прошла: однажды его учетной записью кто-то воспользовался для отправки почты с помощью SMTPAUTH – конечно же, это оказался спам.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.