Танцующий Медведь

2009-05-06

При всём своём интересе к естествознанию вообще и биологии, в частности, в данном случае речь всё-таки не об этологии медведей, а об использовании SFTP, HTTP и SMB-серверов с файрволами SmoothWall Express 3.0. Этот скромный (по размерам и требованиям к ресурсам) файрвол достаточно хорош в своём качестве, о чём я уже писал раньше здесь и здесь. И — популярен. В узких кругах, по меньшей мере. У меня, например, он работает у двух третей корпоративных клиентов, а это под двадцать машин.

И клиенты, и машины, на которых работает SmoothWall, бывают разные. В офисе с десятком станций и P-III/350/128/1.2G в качестве файрвола, от SmoothWall, обычно, ничего, кроме "заградительных" функций и не требуется. Но рано или поздно рачительный хозяин задумывается: а не может ли машинка (пусть даже лишённая монитора, клавиатуры и мыши, и со стоимостью, стремящейся к нулю) пригодиться для чего-нибудь ещё? Прямо скажем: может.

SFTP

Во-первых, вместе с файрволом в составе SmoothWall вы имеете SFTP-сервер. Заводим специального пользователя:

 $ useradd -m -d /httpd/html/sftp sftp-client
 $ passwd sftp-client

Комментарий: в данном случае сразу создаётся и домашний каталог пользователя (-m -d /httpd/html/sftp).

Открываем в Networking -> external access 222-й порт (если это не было сделано раньше) и сообщаем заинтересованным лицам, что они могут выкладывать/забирать нужные файлы по протоколу SFTP, порт 222, адрес — в зависимости от того, из локальной сети они обращаются к серверу, или из Интернет, login/password — прилагаются. Благо стараниями FileZilla даже под windows протокол SFTP — доступен.

Есть неудобство: подключающийся к SmoothWall SFTP-клиент будет "видеть" файловую систему файрвола настолько, насколько это позволяют его права доступа. А права у него хоть и не администраторские (так уж существенно навредить файрволу ему вряд ли удастся), но достаточные, чтобы видеть почти всё. Непорядок...

Решений имеется три:

про-upgrade-ить OpenSSH в составе SmoothWall. Начиная от версии 4.3-stable OpenSSH обеспечивает chrooted environment (изолированное окружение). Это — правильно, но... не всем под силу. Не Ubuntu, чай. Список репозиториев не прилагается;
"расставить" правильные права доступа. Можно, но — утомительно;
и, наконец, отказаться от SFTP-доступа снаружи. Это вполне возможно, поскольку на SFTP-сервере "свет клином не сошёлся". Последнее — проще всего.

Если хочется защититься также от любопытства пользователей локальной сети, то можно использовать File Upload MOD V1.0 KrisTof-а. С моими изменениями, если угодно. При наличии трудностей с редактированием текстового файла, можно сразу загрузить вариант fileupload.cgi. Только если ваш разделяемый каталог не /httpd/html/sftp/, то, по крайней мере, его имя отредактировать придётся.

HTTP/HTTPS

Альтернативой SFTP-доступу к каталогу разделяемых файлов файрвола может быть доступ по протоколам HTTP/HTTPS. Разумеется, http-сервер в составе SmoothWall уже есть (через него, собственно, вы с файрволом и общаетесь) и это, конечно, apache.

Интересующим предлагается почитать документацию к apache, а ниже будут перечислены только возможности, которые уже предоставляются http-сервером SmoothWall или требуют минимального изменения конфигурации. Итак...

Как обращаться к web-интерфейсу файрвола из Интернет и локальной сети вы, очевидно, уже знаете. Поскольку DocumentRoot сервера определён в /etc/httpd/conf/httpd.conf как "/httpd/html", то любой его подкаталог может быть доступен по http-запросу. Так, создав каталог /httpd/html/download/ вы можете получить доступ к нему посредством браузера из локальной сети по протоколу http, порт 81 (http://адрес_сервера_в_лок_сети:81/download/) или https, порт 441 (https://адрес_сервера_в_лок_сети:441/download/). Из Интернет же — только по https, порт 441 (https://адрес_сервера_в_инет:441/download/. Разумеется, доступ этот только на чтение.

Возможно, вскоре вы придёте к выводу, что доступ к этому каталогу без пароля — излишество. Доступ к файлам в apache, как известно, задаётся файлами .htaccess. Для начала можно просто скопировать файл /httpd/html/.htacces в каталог, доступ к которому вы собираетесь регламентировать. Простейшее редактирование этого файла сводится к замене в нём имени applet.conf на "звёздочку" (*). Таким образом, файлы мы защищаем "все", а за паролями отправляем к общему для SmoothWall-а файлу паролей (/var/smoothwall/auth/users). Строка 'require user admin', как нетрудно догадаться, предоставляет доступ только admin-у. Заменив её на 'require valid-user', обеспечиваем доступ ещё и пользователю dial (изначально у http-сервера SmoothWall описано только два пользователя: admin и dial).

Этим, однако, необходимые операции не исчерпываются. Чтобы ваш .htaccess "заработал", он должен иметь на это разрешение в форме директивы AllowOverride. А как раз для этой директивы в соответствии с /etc/httpd/conf/httpd.conf для всех, не описанных явно подкаталогов, будем иметь значение None. Поступаем просто: в вышеназванном файле создаём секцию примерно такого вида:

<Directory "/httpd/html/download">
  Options Indexes
  AllowOverride AuthConfig
</Directory>

Хотите иметь больше аутентифицированных пользователей apache? Расширяете соответствующий файл паролей командой htpasswd passwordfile username. Трудности с командной строкой? Отправляемся на страничку Maintance -> passwords и вводим новый пароль для пользователя dial. После чего в файле /var/smoothwall/auth/users, в последней строке, меняем dial на желаемое имя (всё, что до двоеточия — имя). И так столько раз, сколько пользователей хочется иметь: каждый новый ввод пароля для отсутствующего dial — новая строка с паролем.

Этим, разумеется, возможности apache не исчерпываются. Можно организовать на том же сервере несколько виртуальных хостов: сервер обновлений антивирусной программы, CRM-сервер и т.д. и т.п. Только для этого нужно познакомиться с apache уже поближе. Здесь, например.

SMB

Третий из потенциальных партнёров в "танцах" полярного медведя с другими хостами — SMB/CIFS сервер для *-nix систем, известный "в миру" как SAMBA. SMB-протокол, совершенно бесперспективный для Интернет, усилиями MicroSoft таки является наиболее распространённым в локальных сетях. Ну, SAMBA, так SAMBA...

В отличие от двух названных выше, SMB-сервер в состав SmoothWall не входит. Ничто и ранее не мешало загрузить исходники SAMBA с одного из многочисленных зеркал, транслировать их и использовать под SmoothWall. По этому поводу даже существовала подробная инструкция. Но в последнее время проще воспользоваться mod-ой, представленной сообществу Паскалем (Pascal aka nanouk). Искать, как и все прочие mod-ы, нужно среди Express 3.0 HomeBrew Customizations, подробнее — здесь, загружать — отсюда.

За исключением своего беспрецедентного для mod-ы размера (свыше 27 MiB), никаких неожиданностей mod-а не сулит: инсталлируется стандартно, вопросов лишних не задаёт, к использованию готова сразу после инсталляции. Скрипт инсталляции заканчивается предложением создать пользователей и разделяемые ресурсы.

Создание пользователей сводится к добавлению unix-пользователей (с паролями, но без доступа к системе (--shell /sbin/nologin)) и объявлению их же легальными пользователями SAMBA. В принципе, эти два этапа разделяемы. Использование их порознь может потребоваться, если вы, например, захотите объявить легальными пользователями SAMBA уже существующего unix-пользователя. При наличии минимальных познаний в *-nix разобраться в этом не сложно, для неофитов же я посоветовал бы всегда заводить для работы с SMB-сервером новых пользователей и делать это с помощью скрипта /var/smoothwall/mods/samba/phase2.pl. Только так вы будете избавлены от необходимости знакомиться с назначением и структурой файлов, описывающих пользователей хоста и SMB-сервера.

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

При настройке сервера посредством web-интерфейса SmoothWall, не лишним будет хотя бы в общих чертах представлять себе его работу. Так, кнопка save секции Samba global options, лишь приводит промежуточные конфигурационные файлы в соответствие с введёнными данными. Кнопка add share создаёт конфигурационный файл ресурса (но не сам ресурс, а, тем более, соответствующий каталог). Кнопка update каждой секции отдельного ресурса, изменяет конфигурационный файл ресурса в соответствии с введёнными данными. И лишь кнопка save config and restart server формирует окончательные файлы конфигурации, после чего перезапускает SMB-сервер. Таким образом, только нажатие этой кнопки действительно сохраняет новые конфигурационные файлы и делает доступным результат изменения конфигурации.

И всё бы хорошо... Да только SAMBA имеет много больше возможностей конфигурирования, чем предоставляет web-интерфейс Паскаля. Достаточно сказать, что стандартный SWAT (SAMBA Web Administration Tool), имеет раз в пять больше редактируемых позиций. Сам по себе протокол SMB/CIFS не так уж прост (не его вина, что абсолютное большинство пользователей windows не имеют об этом представления), и в исполнении создателей SAMBA проще он не стал. На основании одного и того же протокола MS Windows по умолчанию предлагает настройки сети, устраивающие некомпетентного пользователя, а SAMBA — нет. Собственно, ни о каких настройках SAMBA "по умолчанию" речь вообще не идёт. Настройки "по умолчанию" — этот просто тот вариант smb.conf, который авторы дистрибутива или пакета посчитали наиболее приемлемым.

Вот, и мои представления о том, каким должен быть smb.conf, несколько разошлись с представлениями Паскаля. Казалось бы: ничего страшного. Web-интерфейс предоставляет возможность непосредственного редактирования smb.conf... Если бы упомянутые выше кнопки save и save config and restart server не переписывали smb.conf "начисто", прчём: исключительно в соответствии с замыслом Паскаля. Столкнувшись пару раз с таким "несанкционированным" сохранением конфигурации (выполненным моими же коллегами), я был вынужден написать update mod-ы. Доработки сводятся к двум моментам:

кнопки save и save config and restart server изменяют только параметры smb.conf, вынесенные в web-интерфейс;
вводится кнопка sync config files, выполняющая операцию, обратную сохранению: значения параметров smb.conf и файлов описания разделяемых ресурсов присваиваются соответствующим полям формы web-интерфейса. Последнее мне потребовалось в связи с тем, что переписать конфигурационные файлы бывает подчас много проще, чем исправить несколько десятков полей формы.

Изменённая mod-а сюрпризов больше не преподносила: ключевые параметры конфигурации оставались неизменными, а местный администратор получил возможность менять Workgroup, Netbios name и Server string хоть каждый час. Описание изменений было приведено здесь, а загрузить предлагаемый update можно отсюда.

smb.conf

Выслушав мнение Паскаля о том, каким должен быть smb.conf, я согласился, что для большинства "домашних" пользователей SmoothWall, его вариант является вполне приемлемым. Меня же больше заботили пользователи преимущественно небольших офисов. Их потребности обычно сводятся к трём типам разделяемых ресурсов:

общий ресурс, открытый для записи/чтения. Так называемый "файлообменник";
общий ресурс, открытый только для чтения. Обычно "Install";
индивидуальные ресурсы пользователей, открытые только их хозяевам, администратору или ограниченному списку пользователей.

Поскольку для первых двух желателен доступ без пароля, то необходимыми параметрами smb.conf становятся следующие:

map to guest = bad user
guest account = nobody
guest ok = yes

В переводе на "человеческий" это означает, что всякий пользователь, не прошедший аутентификацию, будет рассматриваться как guest. В системе ему будет соответствовать учётная запись nobody (учётной записи guest в Linux, обычно, не существует), и, по умолчанию, доступ к разделяемым ресурсам для этого самого guest — разрешён.

Ещё два параметра обеспечивают "читабельность" в консоли Lunux имён файлов и каталогов, набранных в windows в кириллице:

unix charset = koi8-r
dos charset = 866

При этом предполагается, что консоль Linux (у меня в 100% случаев это удалённая консоль) работает в кодировке koi8-r. Не забудьте позаботиться о том, чтобы ваши xterm, rxvt или putty так и были настроены.

Не трудно заметить, что ни один из перечисленных параметров в smb.conf Паскаля не фигурировал.

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

[global]
load printers = no
dns proxy = yes
wins support = no
time server = no
encrypt passwords = yes
server string = SAMBA
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
workgroup = OFFICE
netbios name = SmoothWall
unix charset = koi8-r
dos charset = 866
security = user
guest ok = yes
guest account = nobody
map to guest = bad user
max log size = 5000
lock directory = /var/lock/samba
domain master = auto
local master = yes
preferred master = yes
os level = 20
interfaces = 127.0.0., 192.168.0.1/24

include = /var/smoothwall/mods/samba/etc/smb.conf.admin
include = /var/smoothwall/mods/samba/etc/smb.conf.commonrw
include = /var/smoothwall/mods/samba/etc/smb.conf.commonro
include = /var/smoothwall/mods/samba/etc/smb.conf.user1

Как видим, для описания настроек ресурсов в данном случае используются директивы include, появившиеся в SAMBA 3.X. Это значит, что каждый из ресурсов конфигурируется отдельным файлом. Файл smb.conf.admin, например, выглядит следующим образом:

[admin]
path = /home
comment = Admin Share
available = yes
max connections = 0
valid users = smb-admin
browseable = yes
read list = smb-admin
write list = smb-admin
read only = no

Назначение параметров path и comment — очевидно. Наличие параметра 'valid users' делает ресурс недоступным для guest (доступным только для smb-admin в данном случае). Параметры 'read list', 'write list' и 'read only' определяют способ доступа.

Для ресурса "запись/чтение всем" (файл smb.conf.commonrw) излишними будут параметры 'valid users', 'read list', 'write list', но рекомендуется параметр 'force user', т.к. учётная запись nobody, под которой действует наш guest — не лучшая для выполнения операций записи. Общий вид файла следующий:

[Пересылка]
path = /home/FileExchange
comment = Read Write dir
available = yes
max connections = 0
browseable = yes
read only = no
force user = smb-admin

Файл smb.conf.commonro, конфигурирующий ресурс "только чтение всем" — самый маленький. От предыдущего он отличается тем, что параметр 'force user' не требуется (nobody с чтением справляется вполне успешно), а параметр'read only' имеет значение yes.

Файл smb.conf.user1, конфигурирующий индивидуальный ресурс пользователя user1, отличается от файла smb.conf.admin только тем, что path указывает на каталог /home/user1, а в параметрах 'read list' и 'write list' указан не smb-admin, а user1.

Всё, сказанное выше в связи с smb.conf, вполне соответствует только SAMBA 3.X. Вообще, описывать конфигурацию SAMBA — неблагодарное занятие. Большая часть материалов в Сети написаны для версий 2.X. Они ещё не вытеснены материалами, учитывающими особенности версий 3.Х, а на подходе уже 4.0. Так что, "ты — проверяй, какого полу твой сосед", как справедливо отметил Владимир Высоцкий.

Всё, собственно.

Экспериментируя с подключением к разным ресурсам одного сервера с одной win-станции, не забывайте, что после первого подключения, имя пользователя, прошедшего аутентификацию, будет использоваться при всех последующих попытках. Прежде чем подключаться к какому-либо ресурсу под другим именем пользователя, сначала разорвите соединение с предыдущим ресурсом. Например, с помощью команды net use * /delete. Добро пожаловать в мир windows: мир ничем не обоснованных ограничений.