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

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

Устанавливаем команду mail.

CentOS/RedHat:

# yum install mailx

Ubuntu/Debian:

$ sudo apt-get install mailutils

SSH (Secure Shell) чаще всего используется для удаленного управления серверами Linux, хотя также может успешно применяться для создания SOCKS, для организации тоннеля при копировании файлов с помощью rsync. По-умолчанию, при создании сервера Linux настроен доступ по SSH по логину/паролю (как правило изначально вы получаете доступ пользователя root по паролю). Пароль можно подобрать. Но если настроить доступ по ключам, то тогда попытки подбора пароля в принципе будут невозможны.

В Ubuntu, Debian, Astralinux и им подобным сохранить текущие правила iptables так, чтобы они не пропали при перезапуске, можно следующим образом:

Сохранить (выгрузить) текущие правила Iptables в файл:

# iptables-save > /etc/iptables/iptables.rules

Рассмотрим перенаправление (forward) на двух примерах:

1. с внешнего IP на внутренний сервер (без masquerade, IP-адрес источника сохраняется);

2. forward с использованием masquerade, с подменой IP-адреса источника (в локалку, и просто с сервера на сервер).

fail2ban мониторит лог файлы (например, /var/log/secure и др. по вашему желанию) и при появлении в логах заранее настроенных событий (например, неверный пароль по ssh) блокирует удаленный компьютер, внося в цепочку iptables fail2ban-SSH IP этого удаленного компьютера. Время блокирования (вплоть до навсегда), количество неудачных попыток ввода пароля и другие параметры настраиваются вами на основании уже готовых шаблонов. Почти никаких шаманств.

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

Если у вас CentOS, вы устанавливали все не "make... make hardcor...", а примерно так, то скорее всего, postfixadmin у вас скачан в качестве архива, распакован в /var/www/html/postfixadmin-2.3.7 и сделана символьная ссылка ln -s /var/www/html/postfixadmin-2.3.7/ /var/www/html/postfixadmin/, заходите вы в postfixadmin примерно так "http://your_ip/postfixadmin/".

Так вот, чтобы обновить версию postfixadmin на новую, вы должны сделать так:

Имея уже настроенный сервер OpenVPN (см. инструкцию по настройке) рано или поздно придется разрешать подключения для новых пользователей. И сделать это очень просто. Для этого надо выпустить новый клиентский приватный ключ (key) и сертификат (csr).

Вообще это не рекомендуется, но раз уж необходимо, то все делается очень просто:

/etc/squid/squid.conf:

# запретить access.log
cache_access_log /dev/null
# запретить store.log
cache_store_log none
# запретить cache.log
cache_log /dev/null

Также рекомендуется здесь же установить:

logfile_rotate 0

т.к. если будет выполнено squid -k rotate при использовании /dev/null, то есть риск сделать его plain log файлом.

После этого перезапустить Squid:

service squid restart