Комментарии к записи Шифрованный SOCKS5-прокси на своем сервере отключены
Я уже писал как поднять шифрованный прокси средствами ssh, и до сих пор я сам использовал именно этот метод. Однако при всех его плюсах, таких как проверенность протоколов и механизмов, и «изкоробочность» (при условии, конечно, наличия под рукой своего сервера), есть и довольно большой минус: задача проксирования для ssh не первоочередная и справляется он с ней не лучшим образом.
Поэтому я в очередной раз загуглил и нашел более адаптированное решение предназначенное именно для проксирования с шифрованием — https://shadowsocks.org/.
Это клиент-серверная штука, изначально написанная на питоне, но существующая и в переписанном, если память не изменяет, на C варианте.
Установка сервера (debian/ubuntu)
Ставим софт
apt install shadowsocks-libev rng-tools
Настраиваем
/etc/default/rng-tools
HRNGDEVICE=/dev/urandom
/etc/shadowsocks-libev/config.json
{
"server":"SERVER_IP",
"server_port":PORT,
"local_port":1080,
"password":"PA$$W0RD",
"timeout":60,
"method":"aes-128-gcm"
}
Установка клиента
Клиенты для всяческих платформ указаны на официальном сайте. Лично я для винды использовал shadowsocks-windows (портативная версия), а для линукса — shadowsocks-qt5, доступный в штатном репозитории дебиана.
Настраиваются клиенты максимально похоже — все что нужно указать: ip и порт сервера, алгоритм шифрования и пароль, указанные при настройке сервера; а также локальный порт на клиенте, к которому будут подключаться наши приложения (браузер и т.д.)
В самом приложении указываем настройки прокси:
SOCKS5
IP: 127.0.0.1
PORT: 3128 (ну или какой вы укажите при настройке клиента)
Например в файрфоксе это будет выглядеть так:
Ну и все, должно работать.
Безопасность сервера (настройка fail2ban)
Само собой мы защитили подключение паролем, но банить по айпи всяких пытающихся пролезть — лишним не будет. Докидываем 2 файла в конфиг fail2ban (если он у вас установлен)
/etc/fail2ban/filter.d/shadowsocks-libev.conf
[INCLUDES]
before = common.conf
[Definition]
_daemon = ss-server
failregex = ^\w+\s+\d+ \d+:\d+:\d+\s+%(__prefix_line)sERROR:\s+failed to handshake with <HOST>: authentication error$
ignoreregex =
datepattern = %%Y-%%m-%%d %%H:%%M:%%S
и
/etc/fail2ban/jail.d/shadowsocks-libev.conf
[shadowsocks-libev]
enabled = true
filter = shadowsocks-libev
port = PORT
logpath = /var/log/syslog
maxretry = 3
findtime = 3600
bantime = 3600
(PORT — порт подключения к серверу, указанный нами в конфиге сервера)
Таким образом буквально минут за 5-10 можно сделать для себя адекватный прокси с шифрованным каналом.
Комментарии к записи Фикс нового дизайна ютуба (придал компактность) отключены
Так как ютуб решил полностью отказаться от поддержки своего старого дизайна, пришлось пилить свой собственный юзерстиль под дизайн новый. Не могу смотреть на эти жирные кнопки, этот «воздух» между элементами — все это занимает слишком много места. Конечно? вернуть все как было уже не получится, но чутка скомпактить — вполне. На данный момент стиль не на 100% готов, но, скажем так, доведен до состояния, когда я его уже не правлю каждый день. Выглядит это примерно так:
Также уменьшены размеры элементов на странице видео — комментарии, описание, кнопки (подписка на канал, лайки и т.д.), расширены строки чата на почти всю ширину чата. Ну и еще какие-то мелочи, которые нет смысла перечислять. Вероятно что-то еще буду допиливать, но, как уже сказал, не каждый день =)
Комментарии к записи Перенастройка DFS для использования DNS-резолвинга отключены
По умолчанию сервис DFS использует короткие NetBIOS-имена для публикации своих неймспейсов (Namespace). Это может привести к недоступности неймспейса \\dfs.mycompany.local\dfsroot\, если вы хотите предоставить доступ кому-то за пределами вашей организации. При попытке захода в dfsroot, даже если пользователь попытается открыть его по полному имени (\\dfs.mycompany.local\dfsroot\), запрос переформулируется в \\dfs\dfsroot\ и возникнет проблема разрешения имени. При этом у вас может быть корректно настроена служба DNS между вашими сетями, и даже все шары внутри этого корня, добавленные с указанием полных имен серверов, могли бы быть доступны. Убедиться в том, что неймспейс резолвится по короткому имени, можно, выбрав его в списке Namespace в оснастке управления DFS на вкладке Namespace Servers: в графе Path будет указано \\dfs\dfsroot. Что делать в этой ситуации?
У DFS нет возможности переключить режим работы на DNS-резолвинг на лету, более того — потребуется удаление всех ранее созданных неймспейсов со всем содержимым. К счастью, текущие настройки неймспейсов можно экспортировать в xml-файл и использовать его для восстановления списка шар после пересоздания неймспейса.
Итак, представим что у нас есть сервер «dfs.mycompany.local», с корнем «dfsroot» и каким-то набором шар внутри него. Шаги для перевода сервера на лыжи DNS будут такими:
(В оснастке управления неймспейс может отображаться как \\dfs\dfsroot или как \\dfs.mycompany.local\dfsroot — это не влияет на резолвинг, но это важно при выполнении нижеприведенных команд. Я привожу их для варианта \\dfs\dfsroot, в случае если у вас имя прописано полностью — в командах с dfsutil используйте его)
Заново создаем корень dfsroot, указывая в мастере полное имя сервера: dfs.mycompany.local
Перезапускаем консоль управления DFS (это важно!), выбираем созданный неймспейс, и на вкладке Namespace Servers убеждаемся, что в графе Path прописан полный путь
Редактируем файл бэкапа:
Меняем, если надо
Root Name="\\dfs\dfsroot"
на
Root Name="\\dfs.mycompany.local\dfsroot"
Меняем
Target Server="dfs"
на
Target Server="dfs.mycompany.local"
Меняем, если надо, параметры «Target Server» для шар, если сервера прописаны короткими NetBIOS-именами (как в примере из п.2 для шары «Temp» указан сервер «fileserver» вместо «fileserver.mycompany.local»)
Восстанавливаем из бэкапа корень (обратите внимание, что теперь в команде мы используем Namespace, содержащий полное имя — dfs.mycompany.local, так как при его создании в п.6 мы прописали имя сервера полностью. Важно чтобы в файле бэкапа на текущий момент было указано оно же.)
Проверяем в оснастке управления, что неймспейс заполнился нашими шарами.
После указанных процедур ваш сервер начать использовать DNS для резолвинга неймспейсов, вам же остается только при подключении новых шар не забывать указывать полные имена серверов их содержащих.
Комментарии к записи Гибридный сон/гибернация в Linux: два варианта отключены
Гибридный режим сна/гибернации заключается в том, что если в режиме сна содержимое оперативки «замораживается» и подпитывается от сети, а при гибернации оно записывается на хард и подпитки от сети не требует, то в гибридном режиме оба процесса происходят одновременно. Таким образом гибридный режим обеспечивает моментальное восстановление работы при выходе из сна, но также страхует от сброса состояния при неожиданном отключении электроэнергии.
В линуксе есть как минимум два варианта использовать сон и гибернацию, скажем так, в смешанном режиме. Я решал эту задачу на ноутбуке c Debian (без какого-либо окружения рабочего стола, так что готовых кнопочек не нашлось).
Начну с простого
Гибридный режим
Сам по себе вызывается командой
systemctl hybrid-sleep
На ноутбуке как правило хочется вызывать этот режим при закрытии крышки, для этого нужно отредактировать файл «/etc/systemd/logind.conf», изменив в секции «Login» параметр «HandleLidSwitch» с дефолтного «suspend» на «hybrid-sleep»
/etc/systemd/logind.conf
[Login]
#HandleLidSwitch=suspend
HandleLidSwitch=hybrid-sleep
после этого нужно перезагрузить систему, или сервис systemd-logind (это перезапустит текущий сеанс пользователя, так что не забудьте сохранить все важное). Теперь при закрытии крышки будет активироваться гибридный режим.
Далее более сложный, но небезынтересный вариант.
Сон с отложенным переходом в гибернацию
Второй вариант смешанного режима заключается в том, что сначала система уходит в простой сон, но если сон подзатянулся, то происходит кратковременное пробуждение и переход в полноценную гибернацию. Это может иметь смысл для ноутбука, если есть потребность экономить энергию батареи во время продолжительной неактивности.
Для этого создаем файл /etc/systemd/system/suspend-sedation.service
ExecStart=/usr/sbin/rtcwake --seconds $ALARM_SEC --auto --mode no
ExecStop=/bin/sh -c '\
ALARM=$(cat $WAKEALARM); \
NOW=$(date +%%s); \
if [ -z "$ALARM" ] || [ "$NOW" -ge "$ALARM" ]; then \
echo "suspend-sedation: Woke up - no alarm set. Hibernating..."; \
sleep 10; \
systemctl hibernate; \
else \
echo "suspend-sedation: Woke up before alarm - normal wakeup."; \
/usr/sbin/rtcwake --auto --mode disable; \
fi \
'
[Install]
WantedBy=sleep.target
и включаем его
systemctl enable suspend-sedation
Теперь, через 10800 секунд (3 часа) после перехода в сон, комп сам проснется и переведет себя в режим гибернации.
Решение подсмотрено в интернете и отличается дополнительной строкой с командой «sleep 10;». Добавлена она потому, что установленный у меня syncthing крашился при моментальном переходе от сна к гибернации (лично я это связываю с работой сети, которая кратковременно нарушается и восстанавливается при выходе из спячки, но это не точно).
Комментарии к записи Как автоматически скачивать сериалы и субтитры к ним отключены
Довольно долгое время искал какие-то решения, позволяющие «подписаться» на торренты с интересными сериалами, но так как для меня важно наличие русский сабов (а их буржуи не раздают, как это ни странно), то часто реально оказывалось проще дождаться раздачи на наших сайтах, где все уже подбито. Но наконец, закинув в очередной раз невод в море, я выудил нечто похожее на золотую рыбку. Состоит рыбка из трех компонентов…
Торрент-клиент
В основе сервера будет transmission-daemon — идеальный для этого случая клиент. Примерный конфиг для него будет такой:
Этот конфиг подразумевает что у нас есть каталог /share/torrents, в который будут падать торренты, а также два подкаталога — inc и watch. Первый для размещения файлов в процессе скачивания, второй для скачивания торрентов, вручную кинутых в этот каталог.
Вебморда: http://IP:9091/transmission/web/, логин admin без пароля
Граббилка торрентов
Шикарный проект torrentwatch-xa, который мониторит RSS-фиды различных трекеров (есть набор дефолтных и возможность добавить свои), выцепляет названия, интересующие нас. и добавляет их на скачивание. Как правило сериалы выкладываются по сериям, так что свежие всегда будут появляться у нас как только так сразу.
Установка описана на гитхабе, так что сразу к настройкам. Прописываем настройки подключения к торрент-клиенту — он может быть как локальным, так и удаленным. Указываем корневую папку в которую будут скачиваться сериалы.
Указываем чтобы сериалы качались каждый в свою папку по названию сериала, и выставляем лимит раздачи (в данном случае 20 к 1, то есть гиг скачали — 20 раздали и остановились)
Вкладка Favorites отвечает за настройки мониторинга тех сериалов, которые мы захотим скачать. Использовать регулярные выражения для вычленения имени сериала, искать во всех фидах, качать только торренты с номерами сезона и эпизода в названии, скачивать только новые эпизоды (об этом ниже)
Теперь о том как выглядит наше избранное и как добавить сериал. Ну, примерно так
Разберем на примере доктора кто, имя торрента с его серией будет примерно таким: doctor.who.2005.s12e07.720p.hdtv.x264-mtb[eztv]
Имя — это просто имя, может быть произвольным; фильтр — как правило совпадает с именем указанным в имени торрента, но игнорирует точки; quality — качество, которое кодируется или как разрешение (720p), или как тип рипа (webrip/hdtv и т.д.), можно указывать или так или эдак; Last Downloaded — последний добавленный в скачивание эпизод (это поле обновляется автоматически, но его можно поменять и вручную, если часть эпизодов у нас уже есть и мы хотим качать только новое), при добавлении нового сериала это поле заполняется в формате SSxEE (SS — номер сезона, EE — номер эпизода, напр. 02×08)
Скачиватель субтитров
Как правило, для большинства сериалов субтитры рано или поздно находятся на opensubtitles.org, и было бы логично искать их там. Но хотелось бы делать это автоматически. И есть такой скрипт: https://github.com/emericg/OpenSubtitlesDownload
/opt/OpenSubtitlesDownload.py
#!/usr/bin/env python
# -*- coding: utf-8 -*-
# OpenSubtitlesDownload.py / Version 4.1
# This software is designed to help you find and download subtitles for your favorite videos!
parser.add_argument('-g','--gui',help="Select the GUI you want from: auto, kde, gnome, cli (default: auto)")
parser.add_argument('-l','--lang',help="Specify the language in which the subtitles should be downloaded (default: eng).\nSyntax:\n-l eng,fre: search in both language\n-l eng -l fre: download both language", nargs='?', action='append')
parser.add_argument('-i','--skip',help="Skip search if an existing subtitles file is detected", action='store_true')
superPrint("error","Connection error!","Unable to reach opensubtitles.org servers!\n\nPlease check:\n- Your Internet connection status\n- www.opensubtitles.org availability\n- Your downloads limit (200 subtitles per 24h)\n\nThe subtitles search and download service is powered by opensubtitles.org. Be sure to donate if you appreciate the service provided!")
sys.exit(2)
# Connection refused?
if session['status']!='200 OK':
superPrint("error","Connection error!","Opensubtitles.org servers refused the connection: " + session['status'] + ".\n\nPlease check:\n- Your Internet connection status\n- www.opensubtitles.org availability\n- Your downloads limit (200 subtitles per 24h)\n\nThe subtitles search and download service is powered by opensubtitles.org. Be sure to donate if you appreciate the service provided!")
sys.exit(2)
# Count languages marked for this search
searchLanguage =0
searchLanguageResult =0
for SubLanguageID in opt_languages:
searchLanguage +=len(SubLanguageID.split(','))
searchResultPerLanguage =[searchLanguage]
# ==== Get file hash, size and name
videoTitle =''
videoHash = hashFile(videoPath)
videoSize =os.path.getsize(videoPath)
videoFileName =os.path.basename(videoPath)
# ==== Search for available subtitles on OpenSubtitlesDownload
for SubLanguageID in opt_languages:
searchList =[]
subtitlesList ={}
if opt_search_mode in('hash','hash_then_filename','hash_and_filename'):
"Just to be safe, please check:\n- www.opensubtitles.org availability\n- Your downloads limit (200 subtitles per 24h)\n- Your Internet connection status\n- That are using the latest version of this software ;-)")
exceptException:
# Catch unhandled exceptions but do not spawn an error window
# Disconnect from opensubtitles.org server, then exit
if session and session['token']:
osd_server.LogOut(session['token'])
sys.exit(ExitCode)
Все что ему нужно — указать файл для которого мы хотим найти сабы, и пару параметров отвечающих за сами сабы (язык, обновлять не обновлять и т.д.). Так как мы исходим из того, что торрент-файлы у нас качаются автоматически, то и этот скрипт применять к файлам лучше скриптом, добавленным в крон. Скрипт простецкий:
/etc/cron.daily/download-subtitle
#!/bin/bash
path="/share/torrents/xa/"
download_sub="/opt/OpenSubtitlesDownload.py --cli --lang eng --lang rus --skip --auto "
rmd="rm -rf "
find"${path}"-size 50M -type f -exec${download_sub}{} \;
find"${path}"-empty-type d -exec${rmd}{} \;
Этот скрипт проверяет все файлы в нашем каталоге /share/torrents/xa/, находит файлы больше 50 мегабайт (потому что иногда в торрентах содержится не только видеофайл, но и какой-нибудь сопровождающий файл с описанием релиза, да и сами субтитры, которые скачались в прошлый раз, нас не интересуют) и натравливает на каждый их них скрипт поиска субтитров. Если субтитры указанных языков (русский английский) найдены — они скачиваются. Также скрипт удаляет пустые каталоги, которые иногда образуются лично у меня после переноса новых серий на постоянное место жительства.
В итоге
Мы получаем уютный сервачок, который сам по себе живет и поставляет к нашему столу свежие серии. Работает исправно на все 95%, осечки случаются, но как правило это связано с некорректным названием торрентов (рукожопы случаются) или отсутствием субтитров на opensubtitles (если я нахожу сабы на стороне, стараюсь их добавить и туда).
Невероятно странно, но попытки нагуглить хоть какой-нибудь веб-интерфейс для сислога приводят в основном в дебри топов коммерческих интерфейсов, среди которых, может, и есть бесплатные версии, но будьте любезны сами ковыряться и разбираться насколько оно убого или нет, и какой функционал там порезан.
Мне же от вебморды много не надо — мне надо чтобы она лог показывала, фильтры имела, и было бы неплохо чтобы составляла с сервером полностью FOSS-решение. И сам я давно уже использую под это дело LogAnalyzer, который с поставленной задачей — презентовать лог сислог-сервера, собирающего в базу данных логи с различного оборудования — справляется весьма неплохо.
И так как в целом задача развертывания сислог-сервера с веб-мордой не решается автоматически установкой какого-нибудь пакета в этом нашем дебиане, я решил во-первых написать скрипт, который сделает все за вас, ну а попутно еще расписать как в целом все это инсталлируется и настраивается руками.
Итак, скрипт писался и проверялся на Debian 10 «Buster», его актуальная версия находится на гитхабе, а текущую я оставлю здесь:
loganalyzer_install.sh
#!/bin/bash
# Syslog server with web interface for Debian 10
# LAMP + phpmyadmin + rsyslog + Log Analyzer
PHPMYADMINUSER="pma"
PHPMYADMINPASS="321"
SYSLOGDBPASSWORD="Qwerty"
PMAVER="4.9.2"
LAVERSION="4.1.7"
exportLANG="en_US.UTF-8"
function check_packages {
notinstalled=""
if[$#-eq0]; thenecho"Package name(s) required"; fi
if[$#-gt0]; then
for packagename in $@; do
if[["" == $(dpkg-query -W--showformat='${Status}\n'${packagename}2>&1|grep"install ok")]]; then
notinstalled=${notinstalled}${packagename}" "
fi
done
fi
if[["" == ${notinstalled}]]; then
echo"true"
else
echo"${notinstalled}"
fi
}
######## MARIA DB
function check_sql {
if[["true"!= $( check_packages mariadb-server )&&"true"!= $( check_packages mysql-server)]]; then
echo"false"
fi
if[["true" == $( check_packages mariadb-server )]]; thenecho"mariadb"; fi
if[["true" == $( check_packages mysql-server )]]; thenecho"mysql"; fi
}
function install_sql {
apt -yinstall mariadb-server
# mysql -uroot -e "UPDATE mysql.user SET Password=PASSWORD('${MYSQLROOTPASS}') WHERE User='root';\
# DELETE FROM mysql.user WHERE User='';\
# DELETE FROM mysql.user WHERE User='root' AND Host NOT IN ('localhost', '127.0.0.1', '::1');\
# DROP DATABASE test;\
# DELETE FROM mysql.db WHERE Db='test' OR Db='test\_%';\
mysql -uroot-e"use mysql; CREATE USER ${PHPMYADMINUSER}@localhost IDENTIFIED BY '${PHPMYADMINPASS}'; GRANT ALL ON *.* TO ${PHPMYADMINUSER}@localhost WITH GRANT OPTION;"
Лучше всего использовать его на свежеустановленном дебиане в минимальной конфигурации. Перед запуском нужно его отредактировать, изменив пароль для создаваемого в процессе пользователя (базы данных) rsyslog, а также логин и пароль дополнительного администратора БД, который будет создан в случае установки (опциональной) PhpMyAdmin. Всего скрипт установит:
mariadb в качестве сервера баз данных,
rsyslog с коннектором rsyslog-mysql в качестве сислог сервера, и создаст конфиг для приема логов по сети
веб-сервер apache
опционально phpmyadmin для управления базой данных
LogAnalyzer.
После завершения работы скрипта останется пройти мастера настройки LogAnalyzer, перейдя в браузере по адресу вашего сервера. Так что если вы решите его использовать, то можете листать к разделу «Настройка LogAnalyzer», а также посмотреть наглядное видео:
Настройка сервера syslog с веб-интерфейсом и хранением логов в базе данных (на Debian 10 «buster»)
Установка debian
Для наших целей подойдет установленный в минимальной конфигурации дебиан. Идеально сразу при установке поставить LAMP-набор, отметив опцию web server
Но можно обойтись пунктом standard system utilities, а все остальное установить самостоятельно. Я буду исходить из этого варианта.
В процессе установки соглашаемся сконфигурировать базу данных
Придумываем и подтверждаем пароль для пользователя «rsyslog» БД
После того как сислог будет установлен, его нужно сконфигурировать так, чтобы он мог принимать события с сетевого оборудования. Создаем файл /etc/rsyslog.d/enable-remote.conf с таким содержанием:
/etc/rsyslog.d/enable-remote.conf
module(load="imudp")
input(type="imudp" port="514")
module(load="imtcp")
input(type="imtcp" port="514")
И перезагружаем сервис
service rsyslog restart
Установка веб-интерфейса (LogAnalyzer)
Скачиваем и распаковываем файлы в директорию веб-сервера:
Перед тем как перейти мастеру настройки, создадим еще одну одну базу, в которой лог аналайзер будет хранить свои настройки, и дадим пользователю rsyslog полные права на нее
mysql -uroot -e "create database loganalyzer; grant all privileges on loganalyzer.* to rsyslog@localhost"
Настройка LogAnalyzer
Теперь к мастеру. Перейдя в браузере по адресу сервера мы должны увидеть его приглашение создать конфиг
Первые два шага пропускаем, интересное начинается с третьего. Здесь нужно выбрать Enable User Database и ввести имя пользователя (rsyslog) и пароль с которыми будет производиться подключение к созданной нами базе «loganalyzer». Остальные настройки можно оставить по умолчанию.
На шестом шаге создаем внутреннего администратора лог аналайзера
На следующем шаге выбираем источник данных — базу rsyslog\’а. Важные пункты, которые будет нужно здесь изменить:
Source Type — MYSQL Native
Database Name — Syslog (была создана при установке rsyslog-mysql)
Database Tablename — SystemEvents (именно так — с большими буквами, а не как по дефолту)
Database User — rsyslog
Database Password — пароль юзера rsyslog
Enable Row Counting — No (при объеме логов в несколько гигабайт этот подсчет приводит к более чем минутным запросам к БД)
Next, Finish и перед нами интерфейс лог аналайзера
Тюнинг
Теперь остается сделать две довольно важные вещи.
Во-первых, при попытке логина в админку, лог аналайзер пытается проверить свое собственное обновление, и это приводит к длительному ожиданию, если сервер не имеет выхода в интернет. Чтобы этого не происходило — нужно отредактировать файл /var/www/html/include/functions_common.php, изменив строку
Второе, и не менее важное. Со временем база сислога будет опухать, поэтому ее стоит периодически очищать от старых записей. Для этого нужно создать файлик /etc/cron.d/rsyslog_mysql с содержимым
232 * * * root mysql -uroot -e 'use Syslog; DELETE FROM SystemEvents WHERE ReceivedAt < DATE_SUB(CURRENT_TIMESTAMP, INTERVAL 365 DAY);'
С ним каждый день из базы будут удаляться записи старше 365 дней (разумеется это количество можно поправить на необходимое)
Комментарии к записи vSphere Launch Remote Console — сменить Workstation на Player в Linux отключены
После переустановки VMware Workstation возникла проблема — ссылка «Launch Remote Console» в web-интерфейсе vSphere стала открываться при помощи основного Workstation вместо более легкого и не требующего аутентификации Player-приложения. Чинится в линуксе очень просто:
Не проверял, но по идее аналогично можно переключить на непосредственно VMware Remote Console, поставив название его ярлыка вместо «vmware-player.desktop» (ярлыки искать в /usr/local/share/applications/)
Комментарии к записи Скрипт для поднятия SOCKS-прокси посредством ssh с проверкой его работоспособности отключены
Небольшой скрипт, которым я пользуюсь для поднятия прокси-через-ssh. Висит в автозагрузке, постоянно проверяет при помощи курла доступность гугла, в случае недоступности — прибивает нужное ssh-соединение и открывает его снова.
ЗЫ: свой собственный прокси с шифрованием трафика средствами ssh — рекомендации лучших собаководов )
proxy.sh
#!/bin/sh
# establishes an SSH Socks proxy and reconnects if it fails.
Комментарии к записи Централизованное хранилище VMware Tools и тулзы для Windows 2003 на vSphere 6.7 отключены
Обновив сферу, столкнулся с ошибкой:
Unable to install VMware Tools. An error occurred while trying to access image file «/usr/lib/vmware/isoimages/winPreVista.iso» needed to install VMware Tools: 2 (No such file or directory). Please refer the product documentation or KB article 2129825 for details about how to get VMware Tools package for this guest operating system
Также ошибка может звучать более лаконично:
The required VMware Tools ISO image does not exist or is inaccessible.
Оказывается, в составе новых ESXI нет исошника с тулзами под старые системы, хотя некоторая обратная совместимость, в виде «знания» какой исошник нужно монтировать — осталась.
Решение этой проблемы — скачать legacy-tools и добавить нужные исошники. Но так как это придется делать для каждого хоста, то проще на общедоступном сторадже выделить папку, свалить туда все исошники и поправить на каждом из серверов параметр, указывающий на папку с тулзами.
Оба архива содержат папки «floppies» и «vmtools» — совмещаем их содержимое (для легаси и новых тулзов содержимое не пересекается) и аплоадим эти две папки в отдельную папку в хранилище. Допустим, в папку vmwaretools на сторадже myStorage (таким образом у нас две папки: «myStorage/vmwaretools/floppies» и «myStorage/vmwaretools/vmtools»)
Теперь заходим в «Advanced System Settings» одного из серверов:
Ищем в них параметр «UserVars.ProductLockerLocation«, по дефолту его значение — «/locker/packages/vmtoolsRepo/», меняем его на «/vmfs/volumes/myStorage/vmwaretools/«.
Теперь сервер придется перезагрузить (по крайней мере у меня он не подхватил новое значение без ребута). После перезагрузки тулзы будут корректно ставиться уже из хранилища.
Технически можно повторить процедуру вручную на каждом из серверов, или включить этот параметр в host profile:
Комментарии к записи Защита wordpress с помощью fail2ban отключены
Совершенно не моё изобретение, да и гуглится несложно, но тем не менее не грех будет упомянуть о средствах контрацепции для этого нашего вордпресса, чтобы на просторах интернетика было ему безопасно.
Вообще говоря, защита учеток вордпресса — это совсем отдельная тема, в которую можно погружаться и погружаться. Ботнеты ищут инсталляции ВП и стараются атаковать, как правило, с двух сторон: разумеется это wp-login.php — страница аутентификации с логином и паролем; и xmlrpc.php — кусок механизма для удаленного подключения и управления сайтом. Причем большинство атак приходится на вторую сторону, и в интернете куча инфы (копия) о том, как эту лавочку прикрыть, отрубив весь механизм. На самом деле это вполне дельная мысль, так как велика вероятность что удаленный доступ к сайту вовсе не используется, но если есть желание, например, постить через мобильный клиент вордпресса — он понадобится.
Но вне зависимости от отключения xmlrpc, придется защищать и основную форму логона. Опять же тут можно (и нужно) возвести многоступенчатую защиту. Негрешно воткнуть капчу при помощи WordPress ReCaptcha Integration, хорошей мыслью будет вообще запретить или ограничить регистрацию с логином и паролем, включив авторизацию через социальные сети (с этим поможет Social Login). Однако все неплохо, пока на сайт пытаются ломиться люди, но вышеупомянутые ботнеты любят атаковать с пачек IP-адресов, посылая частые запросы на аутентификацию, и тут я подбираюсь к сабжу…
Хотя на самом деле скажу еще одно: для блокировки пользователей, активно брутящих пароли, можно с помощью неплохого плагина для самого вордпресса — Limit Login Attempts Reloaded. Он вполне шикарен — ведет список IP, банит на установленный срок при превышении лимита попыток, умеет писать об этом в почту админа. Но в какой-то момент мне захотелось, чтобы такие айпишники не просто банились на уровне ВП, а выпиливались на файрволле — это более концептуальное решение, которое ко всему прочему разгружает сервер от левых запросов. Ну и конечно для такого типа задач есть готовое решение — демон fail2ban.
Оказывается прикрутить его к вордпрессу — проще простого.
Для начала нужно в папку «wp-content/mu-plugins» (если ее нет — нужно ее создать) положить файлик:
Этот файлик, положенный в эту папку, будет постоянно работающим плагином, который нельзя отключить (папка mu-plugins — именно для таких). Суть его работы в том, чтобы при неудачной попытке залогиниться, в лог вебсервера сообщение о доступе к файлам wp-login.php и xmlrpc.php падало с 403й ошибкой. Это нужно чтобы отличать такие фейлы от простого запроса страниц. Выглядеть это будет примерно так:
Простая регулярка, которая выхватит IP из строки с 403ей ошибкой и нужными именами файлов.
Теперь настроим тюрьму:
/etc/fail2ban/jail.d/wordpress.conf
[wp-mysite]
enabled = true
port = http,https
filter = wp-login
logpath = /var/log/nginx/mysite_access.log
findtime = 600
maxretry = 2
bantime = 86400
Тут нужно обратить внимание на параметр logpath — он должен вести к аксес-логу вебсервера (apache или nginx, если он стоит перед апачем). Параметры findtime и bantime принимают значение в секундах, первый отвечает за интервал в который с одного айпишника должны упасть фейлы для срабатывания блокировки, второй — время бана. Так данный пример конфига отправит айпишник в бан на сутки, если с него за 10 минут прилетит больше двух неудачных попыток аутентификации.
Собственно и всё. Рестартим fail2ban, смотрим в /var/log/fail2ban.log — в нем должно быть написано что тюрьма запустилась, а спустя какое-то время, если на сайт полезли боты, и сообщения о банах должны появиться:
2019-04-30 00:42:10,120 fail2ban.jail : INFO Jail 'wp-mysite' started
2019-04-30 00:42:37,452 fail2ban.actions: WARNING [wp-mysite] Ban 119.160.136.138
2019-04-30 00:42:37,483 fail2ban.actions: WARNING [wp-mysite] Ban 143.255.155.57