4 заметки с тегом

настройка

Добавляем mail.ru в Openfire

«Переклинило» меня на очередном эксперименте — подключаться к icq и mail.ru через транспорты своего jabber-сервера. Разницы для меня никакой, в то же время нужно заводить только одну учетную запись в клиенте. Плюс к этому вся история переписки будет храниться опять же на моем сервере.
Все оказалось и просто и сложно одновременно. Сложность заключалась в том, чтобы найти компонент для использования транспорта. Ссылка на компонент в популярной статье о подключении транспорта оказалась не рабочей, но нашлась на другом ресурсе. Благо, что человек выложил архив с нужными файлами на своем сайте. Настройка заняла буквально несколько минут.
Для начала распаковал архив в домашний каталог. Изменил конфигурацию под свой сервер:

[main]
name = xmpp.kini24.ru
password = пароль_для_регистрации_компонента_на_сервере
# -- optional --
admins = admin@kini24.ru
# -- defaults --
server = 127.0.0.1
disconame = Mail.ru IM
port = 5275
reconnect = on
probe = on
show_version = on
show_os = on
psyco = off
# -- http proxy for avatars (default is none) --
# http_proxy = http://localhost:3128
# -- PID file (default is none) --
# pidfile = /var/run/mrim.pid

[profile]
type = xml
dir = /var/spool/mrim

[logger]
logfile = /var/log/openfire/mrim.log
loglevel = info
# --- logger defaults ---
# timestamp = %%d/%%m/%%y-%%H:%%M:%%S
# xml_formatting = off

Затем открыл веб-интерфейс Openfire и в разделе Настройки сервера — Внешние устройства — Разрешено подключаться (да, вот такой дурацкий перевод) добавил поддомен и пароль для подключения компонента. Без этого при попытке запуска компонента я получал только кучу сообщений типа

31/10/17-10:30:21 Connecting to XMPP server
31/10/17-10:30:22 Connection to server lost

Затем запустил транспорт:

/usr/bin/python mrim.py -c mrim.conf

Вернулся в Openfire, открыл Сеансы — Компонент сеансов, где и увидел что транспорт подключился к серверу. Затем прошел регистрацию в своем клиенте Miranda NG и попробовал написать своему другу. Полученный от него ответ оказал, что все работает нормально. Перед этим пришлось, правда, ответить на кучу запросов авторизации.
Осталось только добавить запуск транспорта в автозагрузку и настройка полностью завершена.

31 октября   jabber   mail.ru   openfire   настройка   подключение   сервер   транспорт

Убираем название сервера Apache

Не совсем, конечно, правильный заголовок, но какой уж есть...
Собственно, сегодня я не планировал этим заниматься, просто так вышло. На сервере установлен Apache версии 2.4. При помощи двух параметров (ServerTokens Prod и ServerSignature Off) можно сократить название сервера до банального Apache. Но убрать само название сервера «нельзя». Для того, чтобы это сделать понадобится установить или включить дополнительный модуль mod_security. У меня он установлен не был, но был в репозитории. Раньше, кстати, когда был установлен Apache версии 2.2, его там не было, поэтому приходилось довольствоваться тем, что получилось. Итак, установил модуль, включил его и... поймал ошибку при запуске сервера. Что за ошибка было поначалу не совсем понятно, поскольку ее текст уходил за пределы экрана. Пришлось вывод команды перенаправить в файл, из которого уже стало понятно, что сервер не может найти файлы конфигурации в подкаталоге модуля. Посмотрев в папке, вообще не нашел таковых. Видимо, не очень-то они и нужны. Поэтому просто закомментировал эти строчки и еще раз перезапустил сервер. На этот раз все прошло штатно, он заработал. «Хорошо», подумал я и добавил в файл конфигурации модуля строку

SecServerSignature " "

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

2017   apache   безопасность   имя   настройка   сервер

Настройка VPN на OpenWrt

Доступ в домашнюю сеть

На фоне запретов на VPN и анонимайзеров, взбрело в голову прокинуть туннель в свою домашнюю сеть. Так сказать, пока это не стало противоправным действием :-) Все делал вот по этой статье. С первого раза ничего не заработало. После небольшого расследования оказалось, что клиентский сертификат неверно сгенерировался и получился файл нулевого размера. Пришлось переделывать все заново. После этого я смог подключиться к домашней сети, но у меня не было доступа ни к одному компьютеру в ней. Для доступа к ней пришлось выполнить еще одно действие из этой же статьи, из англоязычной ее части:

# uci add_list openvpn.myvpn.push='route 192.168.1.0 255.255.255.0'

Так как подсеть у меня такая же, то не пришлось править адрес и маску. После перезапуска OpnVPN на роутере все заработало: доступ в сеть есть, к компьютерам — тоже. Все работает, отлично!
Но, как обычно, показалось этого мало. Настроил OpenVPN и на смартфоне. Применение такого доступа нашлось сразу же: быстрый просмотр записей с камеры. VLC, конечно, на такой скорости плохо кэширует (надеюсь, это лечится), но снимки, которые создает motion из записанного видеофайла просмотреть можно. Уже, как говорится, хлеб.
Затем, ради интереса, заглянул на собранную метеостанцию, посмотрел как там дела обстоят. Затем зашел на роутер, проглядел папку с торрентами.
Из «минусов» подключения по VPN вижу только то, что работать приходится не с именами машин, а с их IP-адресами. Но это уже мелочи.

2017   android   openvpn   openwrt   vpn   доступ   настройка   сеть

Внедрение HTTP Strict Transport Security (HSTS) на свой сайт

Сначала небольшая выдержка из википедии:

«HSTS (сокр. от англ. HTTP Strict Transport Security) — механизм, активирующий форсированное защищённое соединение через протокол HTTPS. Данная политика безопасности позволяет сразу же устанавливать безопасное соединение, вместо использования HTTP-протокола. Механизм использует особый заголовок Strict-Transport-Security для принудительного использования браузером протокола HTTPS даже в случае перехода по ссылкам с явным указанием протокола HTTP. Механизм специфицирован в RFC6797 в ноябре 2012 года.

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

Дополнительную защиту https-соединений предоставляют методы Certificate pinning (хранение списка разрешенных для домена сертификатов или CA в исходных текстах браузера) и HTTP Public Key Pinning (англ.). Они предотвращают множество возможностей подмены tls-сертификатов https-сервера.»

Для внедрения этой технологии нам понадобится несколько вещей:

  1. Наличие валидного сертификата (можно бесплатно получить на сайте Let’s Encrypt)
  2. Уверенность в том, что будет использоваться только https протокол, включая все ваши субдомены.
  3. Полное перенаправление с http-версий сайтов на https.

Если что-то из этого по каким-то причинам вам не подходит, то эта технология вам не нужна.

Так как у меня используется «старенький» Apache версии 2.2, то и настраивать, соответственно, мы будет его. Для включения HSTS нам нужно добавить в файл /etc/httpd2/conf/sites-available/default_https.conf следующие строки:

<IfModule ssl_module>
    <VirtualHost *:443>
        Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
   </VirtualHost>
</IfModule>

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

Инструкция Header set позволяет вставить заголовок в ответ сервера. В данном случае заголовок «Strict-Transport-Security». В скобках за ним расположены параметры этого заголовка:

  • max-age — время в секундах, которое будет действовать этот заголовок. Если быть точнее, то это время, в течение которого сайт будет доступен по протоколу HTTPS. Не рекомендуется устанавливать его менее 18 недель;
  • includeSubDomains — указывается, если действие заголовка распространяется также на поддомены. Не является обязательным;
  • preload — параметр, позволяющий указывать, что ваш сайт никогда не будет доступен по незащищенному протоколу. Не является обязательным. Про него будет чуть ниже.

Итак, данные мы добавили, теперь нужно перезагрузить файлы конфигурации:

# service httpd2 condreload

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

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Идем на сайт ssllabs, вводим адрес своего сайта с указанием https и тестируем, что у нас получилось. Тест занимает некоторое время, его вполне хватит на то, чтобы, например, налить себе чашечку кофе.

По итогу мы должны увидеть такие строчки:

Эту вы увидите в шапке отчета
Эту строчку вы увидите в шапке отчета
Эта будет находиться ближе к концу отчета
Эта будет находиться ближе к концу отчета

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

И, наконец, про параметр preload. Существует так называемый «preload list», в котором перечислены все домены, использующие технологию HSTS. Своего рода список «избранных» :-) При желании вы можете подать заявку на включение вашего домена в этот список, но на скорый ответ не рассчитывайте. Список обновляется с выпуском каждой версии браузера Chrome, поэтому может пройти несколько месяцев, прежде, чем вы увидите, что ваш домен добавлен в него. Для подачи заявки нужно выполнить несколько требований, указанных на главной странице сайта, поэтому рекомендую прочитать ее внимательно. Значение имеет даже регистр параметров заголовка. В случае критической ошибки после нажатия на кнопку «Check status and eligibility» фон страницы станет красным, в случае некритической — желтым, если же все верно — зеленым. На этой же странице указано, что нужно делать, чтобы удалить свой домен из этого списка.

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