Владелец может сохранять/изменять файлы. Так что лучше права www-data выставлять только для каталогов под запись. И это при условии, что вас не беспокоит подобное влияние со стороны одного сайта на другие.
Т.е. программные файлы обычно хранятся, имея принадлежность владельцу сайта, а файлы содержимого в public, upload, etc. (т.е. в корневом каталоге или глубже), логи и т.п. могут иметь принадлежность www-data. Либо просто разрешаете запись в нужные каталоги, не меняя их владельца.
Достаточно того, что есть в маршрутизаторе. Но если маршрутизатор "копеечный", тогда может потребоваться дополнительная защита. В общем нужно смотреть на возможности и скорость работы файрвола.
В смысле только для домашней сети? Или к нему открыт прямой доступ извне?
Обычно извне открыт доступ к домашним Web-ресурсам только через VPN или SSH-туннель.
Это потому что в нормальных системах она не видна извне. Доступная извне PMA - тоже существенный фактор риска.
А инъекциями ломают "детские поделки". Если у вас даже защиты от инъекций нет, то о чем-то более серьезном и говорить нечего.
Сразу бы написали, что у вас вопрос для детсада, я бы не стал тратить время на описание более надежного подхода. Тогда действительно можно использовать измененный адрес "точки доступа".
Нет другой подходящей админки и страшно/неудобно использовать командную строку.
"Аналитики" любят лезть в базу данных, не "обвязывая" все это своим кодом 😉
К серверу баз данных или к PMA? Можно и то, и другое поместить в защищенный канал (SSH-туннель). Либо для подключения к серверу баз данных добавить IP сервера в переменную bind_address, создать соответствующего пользователя и т.п., а также настроить шифрование.
PMA лучше запускать на том же сервере (или по крайней мере в той же локальной сети), где находится сервер баз данных. Не нужно внедрять location (phpmyadmin, pma, etc.) в каждый виртуальный хост. Поставьте PMA в отдельный виртуальный хост локального сетевого интерфейса, т.е. на localhost. Если нет другой админки, можно прямо на localhost:80. Доступ выполнять, повторюсь, через SSH-туннель.
Убирать или нет root, зависит от потребностей. Можно сделать и другого суперпользователя баз данных вместо root.
Яндекс сам настраивает SPF- и DKIM-записи. Если вы используете другой DNS-хостинг, просто скопируйте соответствующие записи из панели Яндекса.
Гугл может конфликтовать с самим Яндексом (какими-то его доменами или IP) из-за политической обстановки. Но я только из-за такого дебилизма ничего не переношу с Яндекса.
Я за WP не слежу. Даже если в ядре этого сейчас нет, то это может делать какой-нибудь SEO-плагин. Переадресация определенных внутренних, помню, была в ядре.
Не может.
Теоретически может.
Для обычных сайтов подобную переадресацию лучше вынести на уровень Web-сервера, чтобы объединить еще и с корректировкой протокола запроса (HTTP/HTTPS). Можно запросы по HTTP обрабатывать и на отдельном виртуальном хосте. Также можно запросы по HTTPS к неглавному зеркалу обрабатывать на отдельном виртуальном хосте. Как это обычно сделано на моих серверах:
Непосредственно с поставщиками трудно взаимодействовать? 😀
Программист посмотрит на формат экспорта и сделает импорт. Потом программа импорта может сама контролировать формат экспорта.
