Безопасность

http://sonikelf.ru/17-shagov-chtoby-zashhitit-vash-sajt-na-wordpress-ot-xakerov/

Если бы 13й был первым — я бы сразу читать не стал.
Более унылого бреда сложно и придумать : 🙂

Защитите файл .htaccessВыглядит немного странным, что кто-то будет менять этот файл, но это самое сердце вашей защиты, поэтому, лучше о нём позаботиться заранее. Заприте каждую дверь, какую сможете. Поместите туда код:

<files .htaccess>
order allow, deny
deny from all
</files>

с 1 по 8й, и 12й — норм. Только..
1й давно на уровнен ВП решён — логин админа (вернее первого юзера. И вот над этим уже стоит подумать) задаётся при установке.
2й Не «необычный», а «безопасный». И данный там пример на 10 символов — не самый удачный.
4й и 5й заголовки отстой, но по тексту — всё верно (я только не согласен насчёт своих велосипедов. Нубам оно ни чему).

11й. Здание префикса, отличного от wp_ (сразу при установке ВП) — не столько безопасность, сколько удобство и снижение рисков случайно поломать. А то, что и как написано в этих фантазия — вероятность 99% поломать сайт.

14й в такой редакции только навредит неопытным (а опытней и без этого знают)
16й ну просто рассмешил…
17й 100лет кочующий копипаст. 🙂

• Ответ изменён 8 лет, 4 месяца назад пользователем SeVlad.

Так уж лучше как там написано в конце коментов накатить плагин

Это тоже спорный вопрос. Зависит и от сервера и от задач сайта и от многого другого.
И кроме «накатить» — нужно знать как его настроить. А если это знаешь — значит знаешь и как сделать без плага. Тем более что это как раз тот случай, когда не каждый плагин одинаково полезен.

А тут хорошее описание

Продолжаете читать всякое, вместо изучения матчасти. 🙁 Вы же сисадмин. Безопасность серверов и сетей — это Ваша прямая обязанность. А Вы… в поисках зелёнки, вместо изучения причин болей в животе. 🙁
ЗЫ Я не знаю что там написано — дальше заголовка не читал. Может и хорошая статья по настройке плагина для конкретного сайта.

ЗЫ2. Безопасность — это не волшебная таблетка. Это процесс. Постоянный и разный, зависящий от местных условий. Но базовые мероприятия конечно во многом сходные везде. Но их не достаточно.

• Ответ изменён 8 лет, 4 месяца назад пользователем SeVlad. Причина: ЗЫ2

iThemes Seccurity aka better wordpress security

Решил я глянуть что это за плагин, многими неоднократно восхваляемый. Когда-то давно, наверно. я его уже видел (как и многие другие), но то уже не считается. 😉
И первое же что меня с ходу.. напугало.. да-да именно напугало — это АПИ-ключ. Безопасность сайта (по сути локальной системы) и какой-то ключ, запрашиваемый/проверяемый извне?! Мож и параноик, но «безопасность» и «слив данных куда бы то ни было» — для меня эти вещи несовместимые.

Ну всё же бегло глянул на функционал. Как я предполагал — плагин на 99% решает то, что должен решать сервер и пользователь (в конфиге/хтацессе и др). Правда, я не думал что настолько всё… плохо. Честно-честно.

Мой личный вердикт: плагин хорош для неграмотных, тк простыми движениям позволяет повысить уровень безопасности сайта по нек параметрам. Но при этом по большому счёту является вредным, так как создаёт ненужную нагрузку и имеются немалые потенциальные риски по др. параметрам (особенно для тех же неграмотных).

а ожидалось что-то иное?

Да особо и нет — я ж так и сказал, что почти всё как и ожидалось. Только не думал что настолько.

А жутьпак — это… боль. 😉
Я бы лично не допустил в репо много плагинов, которые вообще не работают локально и пересылают данные на сайты разрабов (а то и тупо в ифрейме «работают»). Но жутьпак от разработчиков же делает тоже самое..
ЗЫ, разные виджеты СЦ и коды счётчиков не в счёт 😉

У Jetpack есть и локальный режим: https://jetpack.com/support/development-mode/

Ну это конечно хорошо, но всё же в целом в репо множество плагинов, которые гоняют данные к себе. Ещё как-то можно понять бекапы и картинки на CDN — это осознанное решения пользователя где что хранить, но галереи [не]работающие через сайт разработчика. Или опросники или.. не помню уже что, но тоже аналогично работающие. При этом это незаметно, если не углубятся или не разрабатывать локально/с ограничениями (на несуществующих доменах, на закрытых сайтах) — они просто в ифрейме показывают. В админке в тч, эмулируя нормальную работу.

Да и те же бекапы.. Множество бекапных плагинов, как оказалось, просто не работают локально. При том, что локальные бекапы — основной их функционал. Т.е. они требуют соединения с внешними сайтами (разработчиков). Вот зачем.. заставляет задуматься. О безопасности.

на случай глобальной паранойи… даже чистое ядро WP рапортует статистику версий wp,php,mysql

Да это не страшно 🙂 Как и плагины СЦ и тп (тут проблема другого плана — тормоза и траффик прежде всего)

Я не о том же.
Я говорю, что в репо множество плагинов по сути не рабочих (локально) и потенциально опасных. Галереи, бекаппы, ФАКи и пр, для чего абсолютно не нужны внешние сайты. Тем более на слив инфы и нередко, доступа к серверу. Вот это бы хотелось если не ограничивать, то хоть как-то выделять их.

ЗЫ. WP_HTTP_BLOCK_EXTERNAL не поможет (если ифрейм) или как раз приведёт к неработоспособности многих плагинов.

• Ответ изменён 8 лет, 4 месяца назад пользователем SeVlad.