Mini-HOWTO настройка вашего нового домена.
Пред.След.

Безопасность Вашего домена

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

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

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

Конфигурирование Вашего брендмауэра

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

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

  1. Инициализация карты Ethernet.

  2. Брендмауэр выполняется через ipchains.

  3. Пересылка включена.

  4. Запускаются сетевые демоны.

Так, в качестве примера, возьмем систему Slackware, конфигурирование брендмауэра в ней происходит между rc.inet1 и rc.inet2. Далее, если возникнут любые проблемы во время конфигурации, предупреждение будет выведено на экран и Ethernet-карта отключится до загрузки сетевых демонов.

Одна стандартная проблема с брендмауэерами, это убеждение в том, что Ваши права правильно установлены для пакетов, приходящих от внутренних или внешних машин на брендмауэер. Локальные пакеты могут быть блокированы брендмауэром. Все это можно проверить только в процессе отладки, доведя настройку брендмауэра до такого уровня, чтобы все компоненты системы работали. К сожалению, это иногда приводит к появлению дырок в защите. Ниже приведен типовой скрипт, который позволит Вам избежать многих проблем при настройке брендмауэра. Это пример скрипта, /sbin/firewall.sh: 
#! /bin/sh
#
# Этот скрипт использует цепочки IP. Создает фильтрацию с сетевым маскарадингом.
#

# Определим несколько переменных

IPCHAINS=/sbin/ipchains

LOCALNET="192.168.1.0/24"	# частная сеть
ETHINSIDE="192.168.1.1"		# fred.example.com's внутренний IP #
ETHOUTSIDE="10.1.1.9"		# fred.example.com's внешний IP #
LOOPBACK="127.0.0.1/8"
ANYWHERE="0/0"
OUTSIDEIF=eth1			# fred.example.com's внутренний интерфейс

FORWARD_PROCENTRY=/proc/sys/net/ipv4/ip_forward

#
# Эти две команды возвратят коды ошибок, возникающих в том случае,
# если права уже существуют (эта ситуация возникает, если Вы запустите
# скрипт больше чем один раз). Мы помещаем эти команды до "set -e"
# чтобы, в этом случае, скрипт не прервался.

$IPCHAINS -N outside
$IPCHAINS -N portmap

set -e			# Аварийное прекращение работы при возникновении
			# ошибки, связанной с установкой прав.


#
# Выключить форвардинг и очистить таблицы

echo "0" > ${FORWARD_PROCENTRY}

$IPCHAINS -F forward
$IPCHAINS -F input
$IPCHAINS -F output
$IPCHAINS -F outside
$IPCHAINS -F portmap


#
# Используем маскарадинг для пакетов, выходящих из нашей внутренней сети во внешнюю.
# Не используйте маскарадинг для пакетов, перемещающихся по нашей частной сети.

$IPCHAINS -A forward -s $LOCALNET -d $LOCALNET -j ACCEPT
$IPCHAINS -A forward -s $ETHOUTSIDE -d $ANYWHERE -j ACCEPT
$IPCHAINS -A forward -s $LOCALNET -d $ANYWHERE -j MASQ

#
# Установка флагов приритета. Минимальная задержка соединения для www, telnet,
# ftp, и ssh (только для исходящих пакетов).

$IPCHAINS -A output -p tcp -d $ANYWHERE www -t 0x01 0x10
$IPCHAINS -A output -p tcp -d $ANYWHERE telnet -t 0x01 0x10
$IPCHAINS -A output -p tcp -d $ANYWHERE ftp -t 0x01 0x10
$IPCHAINS -A output -p tcp -d $ANYWHERE ssh -t 0x01 0x10


#
# Что-нибудь из нашего локального класса С должно быть принято как
# loopback-пакеты и внешний IP.

$IPCHAINS -A input -s $LOCALNET -j ACCEPT
$IPCHAINS -A input -s $LOOPBACK -j ACCEPT
$IPCHAINS -A input -s $ETHOUTSIDE -j ACCEPT



# Создадим набор правил для пакетов, приходящих из внешнего мира
# и свяжем все внешние интерфейсы с этими правилами. Эти правила
# будут называться "внешние"
#
# Также создадим "portmap". Сокеты, используемые демонами,
# зарегистрированными с RPC portmapper не установлены и поэтому
# трудно установить правила для них. "Portmap"
# конфигурируется в отдельном скрипте.


#
# Это включает интерфейс $OUTSIDEIF и любые интерфейсы ррр, которые мы
# создадим для исходящих или входящих звонков.

$IPCHAINS -A input -i ${OUTSIDEIF} -j outside
$IPCHAINS -A input -i ppp+ -j outside


##################################################
#
#         Установка "внешних" правил             #
#
##################################################

#
# Никто из внешнего мира не может выдавать себя за внутреннего пользователя
#

$IPCHAINS -A outside -s $LOCALNET -j DENY
$IPCHAINS -A outside -s $LOOPBACK -j DENY

#
# Никакие пакеты, отправленные по внутренней сети не могут выходить
# во внешний мир, т.к. внешняя сторона, как предполагается, не знает
# о наших частных IP адресах.

$IPCHAINS -A outside -d $LOCALNET -j DENY

#
# Блокируем входящие соединения на X порте. Блокируем порты от 6000 до 6010.

$IPCHAINS -l -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 6000:6010 -j DENY

#
# Блокируем NFS порты 111 и 2049

$IPCHAINS -l -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 111 -j DENY
$IPCHAINS -l -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 2049 -j DENY
$IPCHAINS -l -A outside -p UDP -s $ANYWHERE -d $ANYWHERE 111 -j DENY
$IPCHAINS -l -A outside -p UDP -s $ANYWHERE -d $ANYWHERE 2049 -j DENY

#
# Блокируем XDM пакеты из внешнего мира, порт 177 UDP

$IPCHAINS -l -A outside -p UDP -s $ANYWHERE -d $ANYWHERE 177 -j DENY


#
# Блокируем YP/NIS порт 653

$IPCHAINS -l -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 653 -j DENY

#
# Не беспокоить регистрацией при доступе на TCP порт 80, это www порт.

$IPCHAINS -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 80 -j DENY

#
# Принятие данных FTP и контрольных соединений.

$IPCHAINS -A outside -p TCP -s $ANYWHERE 20:21 -d $ANYWHERE 1024: -j ACCEPT

#
# Принять ssh пакеты

$IPCHAINS -A outside -p TCP -s $ANYWHERE -d $ANYWHERE ssh -j ACCEPT

#
# Принять DNS пакеты из внешнего мира

$IPCHAINS -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 53 -j ACCEPT
$IPCHAINS -A outside -p UDP -s $ANYWHERE -d $ANYWHERE 53 -j ACCEPT

#
# Принять SMTP из внешнего мира

$IPCHAINS -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 25 -j ACCEPT

#
# Принять NTP пакеты

$IPCHAINS -A outside -p UDP -s $ANYWHERE -d $ANYWHERE 123 -j ACCEPT

#
# Не принимать никаких идентификационных пакетов, мы их не используем

$IPCHAINS -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 113 -j DENY

#
# Запретите и регистрируйте все другие приходящие пакеты, TCP или UDP, на специальные порты

$IPCHAINS -l -A outside -p TCP -s $ANYWHERE -d $ANYWHERE :1023 -y -j DENY
$IPCHAINS -l -A outside -p UDP -s $ANYWHERE -d $ANYWHERE :1023 -j DENY

#
# Проверьте установки прав относительно portmapper

$IPCHAINS -A outside -j portmap


##############################################
#
#     Конец установки "внешних" правил       #
#
##############################################


#
# Блокировать исходящие rwho пакты

$IPCHAINS -A output -p UDP -i $OUTSIDEIF -s $ANYWHERE 513 -d $ANYWHERE -j DENY

#
# Предотвратите отправку пакетов netbios

$IPCHAINS -A output -p UDP -i $OUTSIDEIF -s $ANYWHERE 137 -d $ANYWHERE -j DENY

#
# Включите пересылку

echo "1" > ${FORWARD_PROCENTRY}
Обратите внимание, что мы блокируем не только входящие пакеты, но и исходящие, которые могли бы содержать сведения о Вашей частной сети, например, пакеты rwho и netbios.

Как замечено выше, права portmapper немного отличаются, т.к. демоны регистрируются непосредственно с portmapperи указывают, с какими портами работать. Порты, используемые частью демонов могут изменяться в зависимости от изменения используемых сервисов RPC, или их порядка загрузки. Следующий скрипт, /sbin/firewall.portmap.sh создает права для portmapped-демонов: 
#! /bin/sh
#
ANYWHERE=0/0

IPCHAINS=/sbin/ipchains

$IPCHAINS -F portmap

# Правила для предотвращения доступа к portmapped сервисам людям из внешней сети
#
/usr/bin/rpcinfo -p | tail +2 | \
	{ while read program vers proto port remainder
	  do
	  	prot=`echo $proto | tr "a-z" "A-Z"`
	  	$IPCHAINS -l -A portmap -p $prot -s $ANYWHERE -d $ANYWHERE $port -j DENY || exit 1
	  done
	}
Мы можем не волноваться, относительно пакетов, приходящих по нашей частной сети, т.к. цепочка portmap предназначена только для проверки пакетов, приходящих из внешней сети.

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

Теперь мы помещаем все вместе. Чтобы быть уверенным, что нет уязвимости во время старта системы, Вы должны сконфигурировать сценарий загрузки следующим образом: 
#! /bin/sh
#
# Запускаем сеть, надежно
#
#
/etc/rc.d/rc.inet1		# Конфигурирование сетевых интерфейсов
				# и установка маршрутизации.
/sbin/firewall.sh || { echo "Ошибка конфигурации брендмауэра"
		       /sbin/ifconfig eth1 down }

/sbin/ipchains -I outside 1 -j DENY	# Запретить все входящие пакеты

/etc/rc.d/rc.inet2		# Запуск сетевых демонов

sleep 5				# Дадим возможность им стабилизироваться

# Безопасные сервисы portmap
/sbin/firewall.portmap.sh || { echo "Ошибка конфигурации portmap брендмауэра"
                               /sbin/ifconfig eth1 down }

/sbin/ipchains -D outside 1       # Разрешаем принимать входящие пакеты
Данный файл предполагает, что интерфейс eth1 находится на видимом из внешней сети (реальном) IP адресе. Если любой из наборов правил приводит к сбою установки, будет выдано сообщение и интерфейс отключится. До старта всех демонов мы блокируем прием любых пакетов из внешнего мира, т.к. в это время права еще не вступили в силу. После того, как объявленые нами права вступают в силу, мы восстанавливаем прием пакетов.

Конфигурирование OpenSSH или SSH1

Во время написания этого раздела OpenSSH, подобно SSH1, дает возможность вставлять scp, ssh, и slogin как бинарные файлы, названные rcp, rsh, и rlogin, с переносом в ssh клиентских программах к исходным rsh, rcp, или rlogin, когда удаленная машина не выполняет sshd. Можно создать обращение rsh, вместо этого, по моему, важно сохранить безопасность при простоте использования для пользователей. Общие скрипты, rdist конфигурации, и т.п. могут работать без внесения каких-либо изменений в них если удаленная машина выполняет sshd, данные будут посылаться зашифрованными с довольно надежной аутентификацией. Если же удаленная сторона не поддерживает sshd, программа rsh выведет на экран предупреждение о том, что соединение незашифровано. Это сообщение останавливает работу rdist и, возможно, некоторых других программ. Его нельзя подавить параметрами при компиляции, или чем-то подобным. Единственное решение этой проблемы для rdist - это запускать программу с -p /usr/lib/rsh/rsh.

Возьмите пакет ssh1 с ssh web site, или OpenSSH c OpenSSH web site, и скомпилируйте его, чтобы заменить незашифрованные r-программы (rsh, rlogin, и rcp). Во-первых, скопируйте эти три файла в /usr/lib/rsh/, затем сконфигурируйте пакет ssh: 
 ./configure --with-rsh=/usr/lib/rsh/rsh --program-transform-name='s/^s/r/' --prefix=/usr
Установите бинарные файлы, и произведите настройку, согласно документации. На машине-шлюзе частной сети убедитесь, что конфигурация sshd имеет следующие значения: 
ListenAddress 192.168.1.1	# внутренний IP шлюза
IgnoreRhosts no
X11Forwarding yes
X11DisplayOffset 10
RhostsAuthentication no
RhostsRSAAuthentication yes
RSAAuthentication yes
PasswordAuthentication yes
Вы должны сконфигурировать и другие параметры, входящие в файл /etc/sshd_config, но не пытайтесь заменить эти поля. Как только Вы пропишите параметры всех полей, скопируйте этот файл в новый файл /etc/sshd_config.ext, для внешней сети. Измените всего два поля для нового файла: параметр поля ``ListenAddress'' измените на внешний адрес шлюза (в нашем случае это 10.1.1.9), и параметр поля ``PasswordAuthentication'' измените на ``no'' в /etc/sshd_config.ext. В вашем скрипте загрузки сетевых сервисов запустите sshd дважды, раз 
/usr/sbin/sshd
и раз 
/usr/sbin/sshd -f /etc/sshd_config.ext
Это создаст такую ситуацию, что будет выполняться два демона sshd. Один, работающий на внутренний интерфейс, будет позволять заходить с паролями, а второй, предназначенный для внешнего интерфейса, будет требовать ключевую проверку RSA прежде, чем кто-то сможет войти.

Затем, запретите внешнее использование telnet и shell в файле конфигурации inetd (обратите внимание, что настройка брендмауэра, перечисленная в разделе Разд. Конфигурирование Вашего брендмауэра, уже обеспечит предотвращение доступа снаружи, но лучше обеспечить полную безопасность, не полагайтесь на то, что все будет работать без сбоев).

Люди, которым необходимо будет входить в Вашу частную сеть из дома или из другого города, будут нуждаться в ключе RSA. Удостоверьтесь, что они знают как им пользоваться и не потратят свою энергию на поиск другого пути, как, например, использование telnetd на закрытом порте Вашего брендмауэра.

Ключ RSA генерируется командой: 
ssh-keygen -b 1024 -f new_rsa_key
Вас спросят фразу прохода. Она не должна быть пустой. Человек с доступом к файлу new_rsa_key, и знающий фразу прохода имеет все для авторизации RSA. Фраза прохода может быть паролем или длинным предложением, но не делайте из нее что-то тривиальное. Файл new_rsa_key может быть скопирован на дискету или ноутбук, и, наряду с фразой прохода, может использоваться для авторизации RSA.

Чтобы дать доступ через ключ RSA, необходимо создать каталог $HOME/.ssh/, для этого пользователя частной сети на шлюзе (т.е. на машине, которая будет принимать пользователя), и скопировать туда файл new_rsa_key.pub, который может быть создан командой "ssh-keygen" в файле $HOME/.ssh/authorized_keys. См. раздел ``ФОРМАТ ФАЙЛА AUTHORIZED_KEYS'' в man странице sshd для получения более подробной информации по другим опциям, которые Вы можете добавлять в ключ, например, запрос пароля при переходе с реального IP, или авторизацию ключом только при выполнении некоторых команд. В качестве примера, RSA ключ используется только при использовании команд резервного копирования, или отсылки сообщения о текущем состоянии за пределы системы.

Осталась только одна вещь, которую необходимо сделать чтобы, предоставить пользователю максимальное удобство при работе с механизмом RSA. Если пользователю приходится за сеанс работы набирать фразу прохода больше, чем один раз, то ему, вероятно, это сильно надоест. Под Linux упорядочите их оболочку входа в систему, чтобы она вызывалась под ssh-agent. Для примера, если ноутбук компании используется в деловых поездках, выполняя xdm, измените строку в файле /var/X11R6/lib/xdm/Xsession_0 с: 
exec "$startup"
на: 
exec ssh-agent "$startup"
В моей установке xdm имеется три таких строки в одном файле, все их надо изменить. Теперь, когда пользователь вошел, он вводит команду 
ssh-add new_rsa_key
при любом приглашении, пользователь вводит фразу прохода, и больше ему не потребуется вводить ее до выхода из Х-сеанса на ноутбуке.

Выполните sshd на всех машинах Вашей частной сети. Для машин, отличных от шлюза Вашей частной сети запись ``ListenAddress'' в /etc/sshd_config может быть выставлена в ``0.0.0.0''. Вы должны установить ключи к хостам командой: 
ssh-keygen -b 1024 -f /etc/ssh_host_key -N ""
затем запустите make-ssh-known-hosts и распределите файл /etc/ssh_known_hosts среди всех машин Вашей частной и внешней сети.

Запретите telnet-вход и незашифрованные r-сервисы. Не удаляйте бинарный файл telnet, он бывает нужен для других вещей, помимо обычных сеансов связи на порте 23. Вы должны разрешить авторизацию по паролю для членов Вашей частной сети, и запретить ее на внешних машинах, требующих RSA-ключ для входа.

Удобно для пользователей, если хосты частной сети упомянуты в файлах /etc/hosts.equiv. Демоны sshd будут позволять запускать rlogin и rsh без пароля и фразы прохода. При каждом соединении машины будут проверять ключи RSA друг друга на своем уровне.

Одна трудность возникает, когда пользователь, зарегистрированный в часной сети, хочет получить внешний IP-адрес. Вы можете использовать /etc/hosts.equiv или $HOME/.shosts, чтобы позволить проверку правильности пароля, т.к. пользователь входит с машины, IP адрес которой не может быть определенным, но ключи хостов не будут соответствовать. Есть два решения этой проблемы. Первое, если Вы хотите использовать методы /etc/hosts.equiv или $HOME/.shosts, пользователь должен будет регистрироваться на машине-шлюзе частной сети (fred.example.com в нашем примере), и затем переходить на требуемую машину оттуда. Другая методика заключается в использовании авторизации при помощи ключа RSA, что обеспечит независимость от игр с IP адресами и поисков имен хостов.

Конфигурирование X

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

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

Установка sshd описана в секции Разд. Конфигурирование OpenSSH или SSH1, с установленным флагом ``X11Forwarding'', является фактически более простой в использовании альтернативной xhost. Как только Вы войдете в терминал, сможете просто выполнить rlogin для удаленной машины и запустить netscape, xv или что-нибудь другое, что Вам нравится, без установки переменной $DISPLAY или позволения явных разрешений. Во время входа в систему, автоматически будет настроен ssh абсолютно незаметно для пользователя, благодаря этому будет даже автоматическая зашифровка всех пакетов, перед их отправлением через сеть.

Если Вы не можете использовать sshd X11 форвардинг по некоторым причинам, то должны использовать xauth когда разрешите доступ других машин к Х серверу. Опишите это пользователям или создайте специальные скрипты чтобы помочь им. Чтобы разрешить вход в систему ``jpublic'', на машине ``barney'', с получением доступа к Х серверу, необходимо ввести: 

/usr/X11/bin/xauth extract - $DISPLAY | rsh -l jpublic barney /usr/X11/bin/xauth merge -
Эту последовательность можно не использовать для Х соединений с машин, которые совместно используют общий подключенный домашний каталог NFS. Xauth ключ будет немедленно доступным для пользователей тех машин, которые будут использовать тот же самый домашний каталог.

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

Обратите внимание, что если rsh не шифруется ssh, xauth ключ передается в виде открытого текста. Любой, кто сможет перехватить ключ, сможет получить доступ к Вашему серверу, так что все усилия, направленные на безопасность системы, сводятся к нулу, если не используется ssh. Кроме того, если домашние каталоги экспортируются через NFS, то любому способному и любопытному человеку будут доступны все передающиеся через NFS пакеты, вне зависимости от того, используете Вы на Вашей системе ssh или нет.

Настройка совместного использования дисков

Работать с почтой, приходящей на центральную машину, и читать/посылать ее с любой машины несомненно удобно, но некоторое внимание необходимо уделить и безопасности. NFS без AUTH_DES несомненно опасен. NFS полагается на клиентскую машину, для авторизации доступа не требуется проверка пароля, пользователю необходимо разрешить доступ к его специфическим файлам. Windows-машины могут быть сконфигурированы читать экспортированные NFS разделы с любым uid, полностью обходя права на файл, установленные UNIX. Следовательно, доступ к NFS можно давать только тем машинам, котороые всегда работают только под Linux (или Unix) и никогда не могут быть загружены под Windows. Чтобы экспортировать домашний каталог в Windows, используйте samba, установив режим аудентификации ``security=USER''. Соединение машин в вашей сети с использованием хаба тоже поможет, т.к. при этом теряется всякий смысл использования снифферов на Windows-машинах. В конечном счете, невозможно гарантировать совместное использование диска в сети.

Зачем беспокоиться, если все равно не получится поностью защитить ваши диски, которые совместно используются? Эту ситуацию можно проиллюстрировать следующим примером. Если Вы оставите лист бумаги с конфиденциальной информацией на столе и кто-то в офисе ее прочитает, он может сказать, что не знал, что это за бумага и посмотрел ее просто из любопытства. Но возникает совсем другая ситуация, если этот лист лежал в картотечном блоке или в столе. Цель установления, хотя бы элементарной сетевой защиты, это гарантия того, что никто ``случайно'' не поставит под угрозу Ваши данные.

Пред.НачалоСлед.
Настройка поддерживаемых вами служб Кто помогал мне при составлении данного документа