Сервисы и клиенты (XMPP, Jabber и др.) для мобильных платформ с налетом безопасности

Все началось с того, что для мобильных устройств стал искать программы для защищенного обмена сообщениями, защищенного хотя бы формально, хотя бы попробовать. Для компьютеров Win, Mac и Linux все проще, а вот для мобильных вопрос а) актуальнее, б) более закрытый, что-ли.

Идея-фикс: нужны были или PUSH уведомления о новых сообщениях, или другой вид уведомлений. Иначе проще пользоваться электронной почтой. Любые программы с PUSH можно условно считать менее безопасными (т.к. информация проходит через третьи руки), но если шифрование «от устройства до устройства» с предварительной верификацией получателя и отправителя между собой, то, кроме спецслужб, надавивших на сервис, никто получить доступ к данным не сможет (в теории, естественно). А их бояться (и бороться) глупо, т.к. бесполезно.

Что такое PUSH, я увидел и почувствовал тогда, когда тестировал платную и в общем случае не убогую программу для обмена сообщениями через XMPP / Jabber / etc. серверы BeejiveIM. Я не мог понять, как же она эти пуши присылает, если в настройках указан мой сервер, который никуда ничего не шлет, по идее. Оказалось, что логин и пароль, а также остальные настройки, которые я указал для моей учетной записи, эта замечательная программа "передала" на свой сервер и уже этот сторонний сервер регистрировался на моем сервере от моего лица. Т.е. это самый классический MITM, причем моими руками. Я обнаружил это во время тестирования сервера, когда решил ограничить входящие подключения только своей сетью. Бах, а я оффлайн. Стал смотреть логи и так понял, как работает PUSH ;)

Или, например, iMessage. Заявлена поддержка шифрования, но пользователь лично не верифицирует получателя или отправителя, т.к. все ключи шифрования хранятся в Apple.

После этого несколько дней потратил на краткий обзор того, что есть на рынке с приставкой "secure".

Threema

Сайт: https://threema.ch  (Швейцария)

Предоставляют сервис (а не только мессенджер) обмена зашифрованными сообщениями. На сайте заявлено, что они не имеют возможности читать пересылаемые между пользователями данные.

Платформы: Android, iPhone, Windows Phone

Функционал: сообщения.

Клиент платный, но условно (2 EUR).

Open WhisperSystems

Сайт: https://whispersystems.org  / США (по данным https://ru.wikipedia.org/wiki/Open_WhisperSystems )

OpenSource проект( т.е. теоретически не содержит закладок и алгоритм работы может быть проверен. Например, можно удостовериться, что шифрование идет от устройства к устройству).

Платформы: Android и iOS (в виде Signal private messenger, доступен в Google Play и iTunes).

Функционал: звонки (RedPhone) / сообщения (TextSecure)

Вопросы для размышления (если прояснятся, дополню):

1. Есть TextSecure-Server (https://github.com/WhisperSystems/TextSecure-Server ). Можно запустить самим?
2. Так ли он OpenSource? См. ссылку (https://f-droid.org/posts/security-notice-textsecure/).

WhatsApp

В представлении не нуждается. Шифрует сообщения только «по пути». По приходу на сервер они уже не зашифрованы.
https://threema.ch/en/faq: Transport encryption only: usually only the connection between the mobile device and the server is encrypted, e.g. using SSL. While this means that messages cannot be intercepted while in transit over the network (a common problem in public wireless LAN hotspots), they are in unencrypted form again once they reach the server.

Если вы не наркоторговец, можно и не волноваться. А можно волноваться, это уж кому как.

ChatSecure

https://chatsecure.org/

XMPP-клиент. Работает с обычными XMPP серверами (jabber, prosody и др.).

Есть возможность вести защищенный обмен сообщениями поверх между обычными учетными записями на сервере XMPP. Для этого надо выполнить предварительную верификацию отправителя и получателя - сравнили отпечатки на экранах устройств и подтвердили (или отвергли), что это Алиса, а это Боб. Дальше диалог шифруется, прочтение содержимого не возможно (т.е. на сервер приходит уже зашифрованное сообщение. Отправитель и получатель видны, а содержимое - нет.

Не поддерживает PUSH, что в контексте безопасности скорее плюс. После 1-2 минут неиспользования клиент iPhone уходит в статус «оффлайн» и не получает новые сообщения пока снова не открыть программу на телефоне. Никакие данные при этом не проходят через Apple – только конкретный сервер XMPP. Для получения уведомлений о новых сообщениях можно включить на сервере XMPP уведомления об offline сообщениях.

Программа хранит OTR-отпечатки пользователей, с которыми вы устанавливали secure chat.

Если вы используете подключение к вашему сервему XMPP через TLS, то сертификат этого сервера будет сохранен в программе в Настройки - Сохраненные сертификаты. Тут, кстати, есть еще один интересный момент - в сохраненных сертификатах есть по умолчанию два - chat.facebook.com и talk.google.com. Я пытался их удалять, но они появляются снова - почему? - опять надо копаться... Ох, эта ж моя паранойя...

Имхо, лучшее, что я видел в плане безопасности общения для iOS, но чтобы утверждать совсем уж, надо сильно вникать в её работу.

Платформы: Android, iPhone

SilentCircle

https://silentcircle.com/

Единственный сервис / мессенджер из рассмотренных, требующий платной подписки. Заявлены безопасность от отправителя до получателя. Доверять ли им? Решать вам.

Есть целый пласт систем безопасного обмена сообщениями / почтой с применением PGP и его производными.

Например, iPGMail для iOS.

https://ipgmail.com/

Его я не проверял, сказать ничего не могу пока, но для себя на будущее и для других просто оставлю здесь ))

Настройка почтового сервера Linux

Последнее изменение: 03 апреля 2013 года.

     

Вступление

Это первая статья по настройке почтового сервера на Linux в составе Dovecot 2.0.9, Postfix 2.6.6, базой данных MySQL, интерфейсом администрирования PostfixAdmin, веб-интерфейсом к почте RoundCube и все это на CentOS 6.3.

Вообще, эту и все связанные с ней статьи я пишу для того, чтобы задокументировать всякие тонкости, с которыми я сталкивался при настройке почтового сервера на CentOS. А заодно уж и поделюсь с общественностью приобретенным опытом. Несмотря на то, что все в этой статье прошло проверку не раз и не два, вы должны понимать, что от релиза к релизу что-то чуть-чуть меняется, от того, прописано у вас имя хоста или нет, где-то что-то может сработать не так, как здесь написано. Директория /var/log/ должна стать вашим хорошим знакомым :) В этом нет ничего страшного.

Я уже где только не предлагал - скажу еще раз - есть отличный проект iRedMail.org, с помощью которого вы можете легко и просто установить все, что описано ниже и даже намного больше. Я тестировал этот продукт, мне понравилось. По-крайней мере, вы получаете на своем любимом дистрибутиве работающий почтовый сервер. И не за 2-3 дня, а сразу. А зачем я тогда писал эту  и сопутствующие статьи? Мне не нужны антиспамы и прочее для внутреннего корпоративного сервера. Мне не нужны куча привязок и заморочек, так что обновить что-либо достаточно непросто. Наконец, я хочу понимать, что происходит в моем сервере.

Для кого это руководство? Для начинающих системных администраторов, у которых куча вопросов, нехватка времени и желание получить все и сразу. Совсем сразу не выйдет, но большинство вопросов тут описано. 

Оглавление

1. Установка базы данных MySQL, в которой будем хранить настройки пользователей, список доменов и пр.
2. Установка веб-сервера Apache для доступа к инструментам управления почтовым сервером
3. Установка PostfixAdmin для управления почтовым сервером (пользователи, виртуальные домены и др.).
4. Postfix - МТА, отвечает за доставку почты (SMTP).
5. Dovecot - IMAP, POP3, авторизация, хранение почты.

Итак, поехали!

Предварительная настройка сети в CentOS

На свежеустановленной системе (например, из дистрибутива minimal, без X-Window) перед началом настройки проверьте настройки сети:

> ifconfig

Если сетевой интерфейс не активен (в выводе только lo), то надо подправить файл:

# vi /etc/sysconfig/network-scripts/ifcfg-eth0

a) адрес сети получаем через DHCP (пример):

DEVICE="eth0"
BOOTPROTO="dhcp"
NM_CONTROLLED="yes"
ONBOOT="yes"
TYPE="Ethernet"

б) адрес сети установлен вручную (пример): 

DEVICE="eth0"
BOOTPROTO="static"
NM_CONTROLLED="yes"
ONBOOT="yes"
TYPE="Ethernet"
IPADDR=192.168.1.2
NETMASK=255.255.255.0
BROADCAST=192.168.1.255
NETWORK=192.168.1.0
NOZEROCONF=yes

DNS-сервер: 

# vi /etc/resolv.conf

nameserver 127.0.0.1
nameserver your_provider_dns_ip

Шлюз по-умолчанию:

# vi /etc/sysconfig/network

GATEWAY=192.168.1.1

После этого перезагрузите компьютер и попробуйте пропинговать, например, yandex.ru. Если все ок, идем дальше, непосредственно к программному обеспечению.

1. Установка MySQL

Как вариант, посмотрите здесь.

1.1 Установка и минимальная настройка

# yum install mysql-server mysql-devel
# service mysqld start
# /usr/bin/mysql_secure_installation

На этом шаге:

1) установили пароль на root:

Set root password? [Y/n] y
New password: mySQL_passWord

2) удалили анонимный вход:

Remove anonymous users? [Y/n] y
 ... Success!

3) ограничили вход только localhost:

Disallow root login remotely? [Y/n] y
 ... Success!

4) удалили тестовую базу и безпарольный вход:

Remove test database and access to it? [Y/n] y
 - Dropping test database...
 ... Success!
 - Removing privileges on test database...
 ... Success!

 5) обновили новые настройки:
 Reload privilege tables now? [Y/n] y
 ... Success!

1.2 Создание базы данных для Postfix и Dovecot

[root@localhost ~]# mysql -p
Enter password:

mysql> CREATE DATABASE mail;
mysql> CREATE USER 'postfix'@'localhost' IDENTIFIED BY 'postfixPassword';
mysql> GRANT ALL PRIVILEGES ON `mail`.* TO 'postfix'@'localhost';
mysql> exit

Дальше никакие таблицы создавать НЕ НАДО. Для этого мы установим PostfixAdmin и веб-сервер для управления базой данных почтового сервера.

Следующий шаг: установка веб-сервера.

2. Установка Apache

Собственно, сам веб-сервер:

> yum install httpd

Необходимые библиотеки:

> yum install php
> yum install php-mysql
> yum install php-mbstring
> yum install php-imap

3. Установка PostfixAdmin

Скачиваем архив с сайта (на 03.04.12 это будет версия 2.3.5):

> cd /var/www/html
> wget http://downloads.sourceforge.net/project/postfixadmin/postfixadmin/postfixadmin-2.3.5/postfixadmin-2.3.5.tar.gz
> tar xvfz postfixadmin-2.3.5.tar.gz

Получаем папку /var/www/html/postfixadmin-2.3.5/

Дальше создадим ссылку на эту версию postfixadmin и отредактируем файл начальной конфигурации PostfixAdmin:

> ln -s /var/www/html/postfixadmin-2.3.5/ /var/www/html/postfixadmin/
> nano /var/www/html/postfixadmin/config.inc.php

В файле изменяем:

$CONF['configured'] = true; // По-умолчанию, false
$CONF['database_name'] = 'mail'; // По-умолчанию, postfix
$CONF['database_password'] = 'postfixPassword'; // Пароль от пользователя postfix в базе данных.
$CONF['encrypt'] = 'dovecot:CRAM-MD5';

Закрываем файл, перезапускаем веб-сервер:

> service httpd restart

Открываем в браузере адрес вида: http://почтовый_сервер/postfixadmin/setup.php

Если не открывается страница, то убедитесь, что сервис httpd запущен, попробуйте отключить iptables командой "service iptables stop".

Также вы можете столкнуться с неявными проблемами, которые создаст вам SELinux, который охраняет вашу систему от нестандартного поведения служб, а вы как раз эти службы терзаете почем зря. Поэтому рекомендую отключить SELinux на время настройки. Делается это разными способами:
 

1. Временное отключение (до перезагрузки):
   # setenforce 0
   или
   # echo 0 > /selinux/enforce
2. Выключить насовсем - в файле /etc/selinux/config изменить параметр SELINUX=disabled
   Перезагрузить компьютер.

Запоминаем пароль от настроек PostfixAdmin ("postfixAdminPassword") и жмем "Generate password hash".

Получаем ответ:

If you want to use the password you entered as setup password, edit config.inc.php and set
$CONF['setup_password'] = '785c37b013896e6d19dc57ecec:60965d6fe4d785c37b013a65a9836bf877aceecb';

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

Я введу email "admin@mailserver.local" и пароль "adminPassword".

Здесь надо отметить, что скорее всего Postfixadmin выдаст вам такую ошибку:

Почтовый адрес
Некорректный адрес администратора!

Это может произойти от того, что email может не резолвится, например, если вы ввели название виртуального домена "от балды". Для того, чтобы postfixadmin не проверял доменное имя, надо в файле config.inc.php поменять параметр $CONF['emailcheck_resolve_domain'] с 'YES' на 'NO'. Вот и все.

Пробуем залогиниться со страницы: http://почтовый_сервер/postfixadmin/

По идее, у вас не возникнет проблем, потому что раз уж вы дошли до этого шага, то все у вас в порядке.

Так, кратко резюмируем: у нас есть база данных, в которой сохраняются виртуальные пользователи, домены, пароли и пр.

Если вы забыли логин/пароль суперпользователя postfixadmin (который вы вводите на странице http://бла-бла-бла/postfixadmin/ ), вы можете сделать вот что:

1. Узнать логин (логины) суперпользователя postfixadmin:

# mysql -u root -p
mysql> use mail;
mysql> select * from admin;

Поле username - это логин. Поле password - хеш пароля.

2. Сброс пароля суперпользователя postfixadmin:

В файле postfixadmin/config.inc.php ищем параметр $CONF['encrypt']'.

Его значение - тиш хеширования. В зависимости от него, генерируем пароль с помощью команды.

Например, если $CONF['encrypt'] = 'dovecot:CRAM-MD5' то новый пароль сгенерируем так:
# dovecot pw -s CRAM-MD5 -p testTEST123 | sed 's/{CRAM-MD5}//'

2858fffd54326fff886f30f05357d4d690cf61f6583533a6f5b1f30f7dea1cd2

Полученную строку подставляем в поле password нашего суперюзера postfixadmin (например, это может быть admin@mailserver.local):
mysql> update admin set password='2858fffd54326fff886f30f05357d4d690cf61f6583533a6f5b1f30f7dea1cd2' where username='admin@mailserver.local';

Теперь администратор postfixadmin "admin@mailserver.local" имеет пароль "testTEST123". Логинимся, меняем его на нормальный пароль. Почему сразу не сделать хороший пароль? Потому что мы все команды вводим в консоли и если не стереть всю историю команд, наш пароль будет виден всем, кто может работать в консоли.

Теперь самое время перейти к главному - к установке и настройке собственно почтового сервера.

Начем, пожалуй, с сервера SMTP - Postfix.

 Бонус!!! Лучше всего ставить после установки Postfix и Dovecot.

Ставим Roundcubemail

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

Сразу могу порекомендовать оригинал инструкции по установке Roundcubemail.

Итак, скачиваем архив последней версии, распаковываем его, удаляем файл ахива и ждем указаний:

> mkdir /var/www/html/webmail
> cd /var/www/html/webmail
> wget http://downloads.sourceforge.net/project/roundcubemail/roundcubemail/0.7.2/roundcubemail-0.7.2.tar.gz
> tar xvfz roundcubemail-0.7.2.tar.gz
> mv roundcubemail-0.7.2 roundcubemail
> rm roundcubemail-0.7.2.tar.gz
> cd /var/www/html/webmail/roundcubemail

Ок, у нас есть заготовка по адресу /var/www/html/webmail/roundcubemail/

Копируем оригиналы конфигов (мало ли что?):

> cp config/db.inc.php.dist config/db.inc.php
> cp config/main.inc.php.dist config/main.inc.php

Создаем базу данных Roundcubemail:

> mysql -p
Enter password:

mysql> CREATE DATABASE roundcubemail;
mysql> CREATE USER 'roundcubemail'@'localhost' IDENTIFIED BY 'roundCubePassword';
mysql> GRANT ALL PRIVILEGES ON `roundcubemail`.* TO 'roundcubemail'@'localhost';
mysql> exit

Правим config/main.inc.php:

$rcmail_config['default_host'] = 'localhost';
$rcmail_config['imap_auth_type'] = PLAIN;
$rcmail_config['smtp_server'] = '';
$rcmail_config['enable_installer'] = true; (после установки изменить на false!!!)

Правим config/db.inc.php:

$rcmail_config['db_dsnw'] = 'mysql://roundcubemail:roundCubePassword@localhost/roundcubemail';

Ставим необходимые расширения php:

yum -y install php-dom php-intl

Пользователь, от имени которого запускается веб-сервер, должен иметь возможность записывать в директории temp и logs:

# chown -R apache:apache /var/www/html/webmail/roundcubemail/logs
# chown -R apache:apache /var/www/html/webmail/roundcubemail/temp
# ls -al /var/www/html/webmail/roundcubemail/

Запускаем установщик http://почтовый_сервер/webmail/roundcubemail/installer/

Инициализируем базу данных нажатием кнопки «Initialize Database».
Проверяем отправку и авторизацию стандартными средствами Roundcubemail.

На этом этапе может быть будут всякие мелочи, их лучше решить сразу и не идти дальше. Например, если у вас пароли не PLAIN, а, скажем, MD5 или еще как, у вас могут возникнуть проблемы. В принципе, именно из-за этого я был вынужден отказаться от шифрования паролей. Мы все-таки состыковываем кучу софта (веб-морду, dovecot, postfix, mysql, потом возможно еще что-то), и различия в терминах алгоритмов шифрования и др. делают работу с зашифрованными паролями настолько трудной, что я пока забил на это. Если кто-то знает работающую схему шифрования паролей, в комментариях напишите об этом и опишите как вы это сделали. Мы работаем для себя и для всех, по крайней мере, на этом сайте!

После прохождения тестов Roundcube напишет вам такое:

After completing the installation and the final tests please remove the whole installer folder from the document root of the webserver or make sure that enable_installer option in config/main.inc.php is disabled.

These files may expose sensitive configuration data like server passwords and encryption keys to the public. Make sure you cannot access this installer from your browser.

Запрещаем повторную переустановку приложения в main.inc.php:

$rcmail_config['enable_installer'] = false;

Удаляем установщик:

# rm -f -r /var/www/html/webmail/roundcubemail/installer

Заходим по адресу http://почтовый_сервер/webmail/roundcude/ и наслаждаемся web интерфейсом.

Обратите внимание: доступ через веб-сайт к каталогу config должен быть запрещен!. Для этого надо в конфиге Apache изменить "AllowOverride None" на "AllowOverride All", чтобы файл .htaccess, поставляемый вместе с Roundcube, заработал.

Установка и настройка Samba на CentOS 7

В статье приведен пример установки файлового сервера Samba в рабочей группе (не в домене) на CentOS 7. Доступ к ресурсам как публичный, так и по логину/паролю. Поехали!

Ставим Samba:

# yum install samba samba-client samba-common

Подготовка

# cp /etc/samba/smb.conf /etc/samba/smb.conf.bak

Сначала укажем в конфиге то, что мы планируем сделать, а потом уже создадим нужных пользователей, задаим права доступа на директории и пр. Почти все в этом файле как и в примере ниже, выдумывать или менять мало что нужно:

# nano /etc/samba/smb.conf

[global]
workgroup = WORKGROUP
server string = My Samba Server %v
netbios name = centos

security = user
map to guest = bad user
passdb backend = tdbsam
guest account = samba_guest

dns proxy = no

log file = /var/log/samba/log.%m
max log size = 50

; а вот это мы добавляем в конец конфига:
[Common]
comment = Common share
path = /samba/share
browsable =yes
writable = yes
guest ok = yes
read only = no

WORKGROUP должно совпадать с названием рабочей группы компьютеров у вас дома;

netbios name = centos - имя вашего сервера в сети. У меня это имя прописано в dns на роутере mikrotik, вы же при желании можете прописать centos в файл hosts на рабочих станциях в вашей сети. Главное, чтобы ваш сервер был доступен по имени centos (в этом примере). Если вы еще не заблокировали icmp, выполните команду `ping centos` с рабочей станции. Если разрешение имени не работает, у вас будет вариант использовать такую запись <ip-вашего-сервера> вместо centos.

guest account = samba_guest - определяем имя пользователя (должен быть добавлен в систему), от имени которого будет осуществляться доступ к общим папкам. Этого пользователя мы создадим чуть позже.

map to guest = bad user - означает, что если был указан логин/пароль и такого логина не существует, то будет произведена попытка войти под учеткой гостя.

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

Да, и еще, я сразу удалил в этом файле дефолтные группы [homes], [printers], [netlogon], [Profiles] и [public]. Особенно я не хотел бы расшаривать домашние директории пользователей системы.

Несмотря на то, что файл настройки samba один, сами шары могут быть раскиданы по дискам и директориям, при просмотре сетевые пользователи не смогут понять, что шара upload указывает в /var/www/htdocs/upload, а шара docs - на /samba/common_docs. Т.е. ваша фантазия в этом плане вам на руку. Вы можете настроить все так, что файлы, которые вы загрузили по локальной сети, будут доступны посетителям вашего сайта. Ну или что угодно еще можете придумать. Главное, обращайте внимание на права доступа к файлам и директориям, которые вы создаете!

Проверяем, все ли правильно отредактировали:

# testparm

Public share

Ранее в конфиге smb.conf мы указали имя пользователя (guest account = samba_guest), от имени которого будет производиться доступ к общедоступным шарам. Т.е. если мы в описании соответствующей группы укажем guest ok = yes, то независимо от ваших текущих привилегий доступ к файлам в соотв. шаре будет произведен от имени samba_guest. Давайте подготовим такого пользователя и директорию с соотв. правами.

# mkdir /samba/share

# ls -ldZ /samba/share
# chcon -t samba_share_t /samba/share
# ls -ldZ /samba/share
drwxr-xr-x. root root unconfined_u:object_r:samba_share_t:s0 /samba/share

# groupadd smbgrp
# useradd -c 'Samba member' -G smbgrp -M -s /sbin/nologin samba_guest
# chmod 775 /samba/share
# chown samba_guest:smbgrp /samba/share

опция -M указывает не создавать домашнюю директорию;
группа smbgrp будет объединять создаваемых в системе пользователей для Samba.

Здесь небольшая ремарка: часто в интернете в мануалах права на публичные шары предлагается давать 755 (т.е. запись только для пользователя, для группы и остальных - чтение и выполнение). И все здорово, до тех пор, пока вы не авторизуетесь для входа в другую папку, на которую установлен пароль (см. ниже). При этом вы будете уже не samba_guest:smbgrp, а, скажем, user1:smbgrp и вы сможете войти в свою директорию, но не сможете войти в общедоступную share (или войти сможете, но создать ничего не получиться - прав на запись у вас не будет)! Скажу честно, я не совсем понял, это я не так что-то понимаю или все так и есть. Но в моем случае именно права 775 на паблики выправили ситуацию (и я выше дал этому объяснение. Если я ошибаюсь - прошу прощения, что ввел вас в заблуждение. Но я честно вас предупредил :)

# systemctl enable smb.service && systemctl enable nmb.service
# systemctl restart smb.service && systemctl restart nmb.service

# firewall-cmd —permanent —zone=public —add-service=samba
# firewall-cmd —reload

Пробуем с рабочей станции в сети открыть шару share и создать пробный файл. Создав, проверьте на сервере, с какими правами создан файл:

# ls -al /samba/share

Если все ок и вы можете войти в публичную шару и создать в ней файл, то можно попробовать создать запароленную директорию для отдельного пользователя. Если что-то не так, скорее всего проблема в правах на папки или с SELinux.

Шары с паролем

Общая идея такова: если нам надо создать пользователя user1 для шары Samba, нам надо сначала создать пользователя с таким логином в системе Linux, а потом создать такого же пользователя в Samba. По моему разумению, системный пользователь, создаваемый для Samba, не должен иметь возможность входа в систему, а также иметь домашнюю директорию. Собственно, зачем ему это?

# useradd -c 'Samba member' -G smbgrp -M -s /sbin/nologin user1

Вообще говоря, пока вы не создадите пароль для этого пользователя, зайти им в систему нельзя, но представьте себе, когда через год или три вы забудете, ставили вы пароль или нет, и при просмотре /etc/passwd конкретно так вздрогнете, если оставить шелл по-умолчанию ;) Так что в любом случае проверьте файл /etc/passwd после выполнения команды. Хотя бы один разок.

А это уже внутренний пользователь Samba:

# smbpasswd -a user1

Создаем пользовательскую папку. Для директории user1 права можно ставить уже не 775, а 755:

# mkdir /samba/user1
# chcon -t samba_share_t /samba/user1
# chown user1:smbgrp /samba/user1
# chmod 755 /samba/user1

# ls -al /samba/
total 16
drwxr-xr-x.  4 root         root   4096 Feb 28 15:50 .
dr-xr-xr-x. 21 root         root   4096 Feb 28 14:54 ..
drwxr-xr-x.  2 user1        smbgrp 4096 Feb 28 15:50 user1
drwxrwxr-x.  2 samba_guest  smbgrp 4096 Feb 28 15:12 share

# nano /etc/samba/smb.conf
...
[User1 Share]
comment = User1's files
path = /samba/user1
;valid users = @smbgrp
valid users = user1
guest ok = no
writable = yes
browsable = yes
create mask = 0640
directory mask = 0750

параметр create mask = 0640 указывает, что создаваемые в этой шаре файлы будут для владельца с правами на запись, для группы - на чтение, всем остальным - фиг;
параметр directory mask = 0750 указывает аналогично, только для директорий.

В принципе, в личной шаре никто не мешает вам использовать маски 0600 и 0700 соотв. Хотите, поиграйтесь :) Ноникогда без явно обозначенной цели не делайте маски 0777 ни для чего, даже если после этого все работает.

# systemctl restart smb.service && systemctl restart nmb.service

Проверяйте работу, все должно быть ок. В сетевом окружении должны быть две сетевые папки: share и user1.

Создайте еще пользователя, проверьте, как работают права доступа к пабликам и персональным директориям. Если что-то идет не так, проверяйте права доступа на директории и встроенные механизмы защиты, в данном случае SELinux.

Дополнительно

Ну и напоследок некоторые полезные команды.

Список пользователей Samba:

# pdbedit -L
user1:1001:Samba member

Расширенные данные по пользователям:

# pdbedit -L -v

Смена пароля у существующего пользователя:

# smbpasswd <User_name>

Удаление существующего пользователя:

# smbpasswd -x <User_name>

Приостановление учетной записи без удаления:

# smbpasswd -d <User_name>

Не хотите видеть в сетевой папке всякие временные файлы? В конфиге smb.conf добавьте к группе [User1 Share] что-то вроде:

hide files = /$RECYCLE.BIN/desktop.ini/lost+found/Thumbs.db/~*/

Можно до бесконечности писать про всякие отдельные фишки. Но в целом зада выполнена.

Настройка VPN IPSec/L2TP сервера Mikrotik

Настройка туннелирования (L2TP)

1. IP - Pool / Определям диапазон адресов VPN-пользователей

Name: vpn_pool
Addresses: 192.168.112.1-192.168.112.10
Next pool: none

Лучше для клиентов vpn использовать отдельную адресацию. Так проще отделять одних от других. И вообще, бест практис.

2. PPP - Profiles / Профиль для нашего конкретного туннеля

General:
Name: l2tp_profile
Local address: vpn_pool (а можно указать 192.168.88.1, сами смотрите, как вам больше нравится)
Remote address: vpn_pool
Change TCP MSS: yes

Protocols:
all to default:
Use MPLS: default
Use compression: default
Use Encription: default

Limits:
Only one: default

3. PPP - Secrets / Готовим пользователя VPN

Name: vpn_user1
Password: bla-bla-bla
Service: l2tp
Profile: l2tp_profile

4. PPP - Interface - клик на L2TP Server / Включаем сервер L2TP

Enabled - yes
MTU / MRU - 1450
Keepalive Timeout - 30
Default profile - l2tp_profile
Authentication - mschap2
Use IPSec - yes
IPSec Secret: tumba-yumba-setebryaki (это не пароль пользователя, а предварительный ключ, который надо будет указывать на клиентах в дополнение к логину/паролю)

Настройка шифрования данных в "туннеле" (IPSec)

На предыдущем этапе мы создали туннель для передачи данных и включили IPSec. В этом разделе мы настроим параметры IPSec.

5. IP - IPSec - Groups

Т.к. велика вероятность появления ошибки соединения с сервером из-за дефолтной группы, просто удалим и тут же создадим ее. Например, с именем "policy_group1". Также можно просто удалить эту группу, но через веб-интерфейс будут показываться ошибки.

6. IP - IPSec - Peers

Address: 0.0.0.0/0
Port: 500
Auth method: pre shared key
Passive: yes (set)
Secret: tumba-yumba-setebryaki (это не пароль пользователя!)

Policy template group: policy_group1
Exchange mode: main l2tp
Send Initial Contact: yes (set)
NAT Traversal: yes (set)
My id: auto
Proposal check: obey
Hash algorithm: sha1
Encryption Algorithm: 3des aes-128 aes-256

DH Group: modp 1024
Generate policy: port override
Lifitime: 1d 00:00:00
DPD Interval: 120
DPD Maximum failures: 5

7. IP - IPSec - Proposals / "Предложения".

Что-то вроде "что мы можем вам предложить". Другими словами, задаем опции подключения, которые смогут пытаться использовать удаленные клиенты.

Name: default
Auth algorithms: sha1
Enrc. algorithms: 3des, aes-256 cbc, aes-256 ctr
Life time: 00:30:00
PFS Group: mod 1024

Вы наверняка заметили, что пункты 6 и 7 похожи, а если еще добавить, что один и тот же Secret мы добавляли и пункте 4 и пункте 6, то возникает вопрос: почему одни и те же опции повторно настраиваются? Ответ у меня такой: чисто из практики вышло, что Windows 7 требовал одного, а iPhone - другого. Как так работает, не знаю. Но факт чисто из практики. Например, изменяю в Proposal PFS Group на 2048 - Windows нормально коннектиться, а iPhone перестает. Делаю наоборот (в proposal ставлю 1024, а в ip-ipsec-peers ставлю 2048) - iPhone коннектиться, а Windows - нет :) Т.е. при подключении разных клиентов используются разные части конфигов. Бред? Может быть, это следствие постепенных изменений в конфигурацию VPN сервера, не могу сказать, т.к. может иметь место даже влияние старых прошивок, конфигов и др. Я не исключаю, что что-то здесь избыточно, но что именно, не знаю.

Firewall

Давайте уж к консоли, что-ли для разнообразия:

/ip firewall filter
add chain=input action=accept protocol=udp port=1701,500,4500
add chain=input action=accept protocol=ipsec-esp

Это правило надо поднять выше финальных запрещающих правил, если у вас они есть. У вас же они есть???  Если нет, прошу сюда.

Вот теперь с сервером все.

Подключение удаленного клиента

Пробуем подключить Windows 7:

Панель управленияСеть и ИнтернетЦентр управления сетями и общим доступом:
    Настройка нового подключения или сети
        Подключение к рабочему месту
            Создать новое подключение
                Использовать мое подключение к интернету (VPN)
                    Интернет-адрес: ip или имя роутера в сети
                        Пользователь и пароль из PPP->Secrets. В нашем случае это vpn_user1 и его пароль.
                      
Пытаемся подключиться.

Если не выходит, или просто надо настроить созданное подключение:

Вкладка Безопасность:

Тип VPN: L2TP IPSec VPN

Дополнительные параметры: для проверки подлинности использовать предварительный ключ. В нашем случае это "tumba-yumba-setebryaki" (IP - IPSec - Peers):

Здесь же, в группе "Проверка подлинности", оставляем только CHAP v2: