Подскажите компонент защиты админки - страница 2 - Поиск компонентов, модулей, плагинов

да не гоните:
просто запретить или указать доступ по ИП админке.

Код

 Order deny,allow
 Deny from all
 Allow from 0.0.0.0

могу скрипт выложить.

Сам не гони.
Айпи у многих - динамика, плюс способ выше скрывает сам факт скрытия!

Я об этом тоже не знал, пока не прочитал документацию

+1 Сергею в репу:и я такое не читал ранее.

чем больше читаю тему-тем больше начинает мне мой скрипт нравится!

vipiusss

Практически профи

Беда!

http://www.webpress.uz/Alexandr/htaccess/Avtorizatsiya-s-pomoshchyu-htaccess

Еще вопрос, наверное не совсем в тему. Не могу добраться до корня в cmd. Через команду cd.. максимум вышел на C:\>
Как только не набирал, выдает либо "отказано в доступе", либо "Не удается найти указанный файл". В примере вашей ссылки у пользователя есть возможность сразу писать от начала строки (без C:\>).

Я об этом тоже не знал, пока не прочитал документацию

То есть htpasswd вовсе не обязателен?

очень остроумно(я Филиппу).

То есть htpasswd вовсе не обязателен?

Как хотите. Вариантов много, я лишь предложил один из них.

Как хотите. Вариантов много, я лишь предложил один из них.

Так-то суперский вариант. Спасибо. Но хотелось бы уточнить, получается ваш вариант, ни чем не хуже остальных например того где используют htpasswd?

Так-то суперский вариант. Спасибо. Но хотелось бы уточнить, получается ваш вариант, ни чем не хуже остальных например того где используют htpasswd?

Всё относительно. Если на ваш сайт хакеры поставят прослушку, то будет бессилен даже htpasswd. В идеале вы должны использовать htdigest аутентификацию, хотя её тоже можно хакнуть, но значительно сложнее. Для полного комплекта, помимо htdigest вам необходимо также установить SSL сертификат (хотя некоторые считают, что достаточно и базовой аутентификации, если используешь SSL).

Мой способ хорош против хакеров-любителей и против тупых ботов, которые не додумаются украсть у вас сессионную куку. Но против профессионального подхода этот метод не самый эффективный. Если вы политик или же представляете интерес для спецслужб, то должны шифроваться надёжнее, если же нет — то сойдёт и так

Мой способ хорош против хакеров-любителей и против тупых ботов, которые не додумаются украсть у вас сессионную куку. Но против профессионального подхода этот метод не самый эффективный. Если вы политик или же представляете интерес для спецслужб, то должны шифроваться надёжнее, если же нет — то сойдёт и так

Что, серьезно?
99,999% взломов идёт на автомате, для монетизации сети хакеров.
Ну а защищаться от спецслужб - не взломают, так на мосту найдут.

Что, серьезно?
99,999% взломов идёт на автомате, для монетизации сети хакеров.
Ну а защищаться от спецслужб - не взломают, так на мосту найдут.

Знаю реальный пример, когда в бизнесе заказывали взлом конкурентов "вручную".

Ну а защищаться от спецслужб - не взломают, так на мосту найдут.

))) и монастырка не спасёт!

Всё относительно. Если на ваш сайт хакеры поставят прослушку, то будет бессилен даже .htpasswd. В идеале вы должны использовать .htdigest аутентификацию, хотя её тоже можно хакнуть, но значительно сложнее.

То есть пальма первенства у htdigest, второе место - htpasswd, а третье ваш вариант? Я правильно понял?

Если вы политик или же представляете интерес для спецслужб, то должны шифроваться надёжнее, если же нет — то сойдёт и так

)
А если просто сайт серьезный, рассчитанный на не малую аудиторию?

То есть пальма первенства у htdigest, второе место - htpasswd, а третье ваш вариант? Я правильно понял?

Нет, второе и третье поменяйте.

Нет, второе и третье поменяйте.

Тогда меняю и с более легкой душой оставляю вариант с .htaccess, предложенный Филиппом. Во всяком случае пока до htdigest не доберусь

Тогда меняю и с более легкой душой оставляю вариант с .htaccess, предложенный Филиппом. Во всяком случае пока до htdigest не доберусь

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

А про намеренную прослушку я уже говорил — тут нужно принимать меры посерьёзнее.

Тогда меняю и с более легкой душой оставляю вариант с .htaccess, предложенный Филиппом. Во всяком случае пока до htdigest не доберусь

Кстати, ещё один важный момент. Если не использовать SSL шифрование, то риск быть хахнутым все равно остаётся достаточно высоким, независимо от того, какой тип аутентификации вы используете. Да и против тупого перебора паролей не подействует ни один алгоритм. А ещё есть двухфакторная авторизация, которая, правда, не закрывает доступ к каталогу, но тоже является определенным барьером. То есть методы защиты от взлома можно комбинировать и использовать вместе, в зависимости от личного уровня параноидальности.

независимо от того, какой тип аутентификации вы используете.

Кстати по поводу аутентификации. У метода htpasswd, наверняка большая степень защиты, нежели у простого htaccess, ведь там предлагается вариант аутентификации Digest, при котором, как я понимаю данные хранятся в зашифрованном виде. Или я ошибаюсь.

А ещё есть двухфакторная авторизация

Это когда пользователь проходит сперва первое окно... затем второе...?

Кстати по поводу аутентификации. У метода htpasswd, наверняка большая степень защиты, нежели у простого htaccess, ведь там предлагается вариант аутентификации Digest, при котором, как я понимаю данные хранятся в зашифрованном виде. Или я ошибаюсь.Это когда пользователь проходит сперва первое окно... затем второе...?

Вы немного напутали: htaccess - это файл дополнительной конфигурации, а htpasswd - файл, содержащий пароли для доступа к ресурсу веб-сервера. Всё это относится к серверу Apache. Digest аутентификация эффективна при отсутствии сертификата SSL. То есть, если вы используете протокол http и пытаетесь защититься с помощью базовой аутентификации (htpasswd), то толку от этого совершенно никакого, защита нулевая, потому что данные передаются от клиента к серверу как есть без шифрования и хеширования и могут быть перехвачены. Digest аутентификация (htdigest) использует алгоритм хеширования данных md5, но без SSL такую защиту так же можно хакнуть, хоть и сложнее.

А может быть полезна при автоматическом подборе пароля, хотя она не помогает против кражи сессионных кук и SQL инъекций, что очень хорошо подтвердилось на практике буквально недавно, когда нашли огромную дырищу уязвимость в версиях J! 3.0 - 3.4.4.

Вывод из этого такой: если вы не используете SSL (протокол https), устанавливайте digest аутентификацию, если используете SSL, то всё равно какую аутентификацию вы будете использовать — степень защиты будет высокой (но не стопроцентной). А страницу админки, даже если она будет прикрыта SSL и/или аутентификацией, всё равно лучше убрать из поля зрения посторонних.

... А страницу админки, даже если она будет прикрыта SSL и/или аутентификацией, всё равно лучше убрать из поля зрения посторонних.

Мне напоминает первое десятилетие этого века эта паранойя. Ни чего не надо убирать и тем более тратить на это время.

AuthType Basic вполне хватит для защиты от дурака и ботов, ни кто не подберет пароль 22 и более знака разного регистра который периодически меняется, и пусть стучат об стену головой. А разницы что бот получит 401 или 403 ответ ни какой совершенно нету, он придет снова и снова, ответы ошибок его не остановят. Папка закрывается не только от брутфорса, еще и от того что в ней куча файлов не только самого движка, там также файлы сторонних разработчиков расширений.

Ну а смену адреса админки раз уж не делают разработчики как в других cms это в коробке имеется, то и самим её менять нет смысла разве что через htaccess как вы же в теме написали.

mod_authz_host.c даже папки с правами 777 закрывает.

В данное время очень много, что можно использовать для защиты.

Если есть паранойя то можно по IP закрывать, если он динамический то постоянно его менять при входе.

COOKIE используются в любом случае при настройках через apache

В некоторых CMS реализовано через COOKIE авторизация на сайте и там через htaccess вообще настройки неимоверно какие извращенные.

Паранойя то же излечима, просто не иметь сайт и хост/сервер.

AuthType Basic вполне хватит для защиты от дурака и ботов, ни кто не подберет пароль 22 и более знака разного регистра который периодически меняется, и пусть стучат об стену головой. А разницы что бот получит 401 или 403 ответ ни какой совершенно нету, он придет снова и снова, ответы ошибок его не остановят. Папка закрывается не только от брутфорса, еще и от того что в ней куча файлов не только самого движка, там также файлы сторонних разработчиков расширений.

Ну эт ясен пень. Но против man-in-the-middle вы хоть трактат из 100 символов напишите вместо пароля — всё равно с помощью инструментов перехвата трафика ваш пароль будет сворован, а ваш сайт будет взломан, потому что AuthType Basic не шифрует данные, даже не хеширует — передаёт как есть.

Мне напоминает первое десятилетие этого века эта паранойя. Ни чего не надо убирать и тем более тратить на это время.

Не надо тратить время. Страницей ранее я написал вполне действенный рецепт -- просто админка будет доступна по другому URL.

Вывод из этого такой: если вы не используете SSL (протокол https), устанавливайте digest аутентификацию,

Я понял. Главный тезис поста - Лучшая защита SSL + digest аутентификация.

А у базовой htpasswd или вашего примера с htaccess - шифрования нет и они полностью идентичны.

Я понял. Главный тезис поста - Лучшая защита SSL + digest аутентификация.

Теоретически — да: SSL/TLS шифрование + md5 хеширование. А практически — сами разработчики Apache говорят, что при использовании SSL/TLS базовой аутентификации (htpasswd) будет достаточно. Но базовая аутентификация — это ноль без палочки при отсутствии шифрования, поэтому digest аутентификацию целесообразно использовать в том случае, если ваш сайт использует небезопасный протокол http. В случае с безопасным протоколом https — без разницы.

А у базовой htpasswd или вашего примера с htaccess - шифрования нет и они полностью идентичны.

Опять путаете. htaccess — это конфигурационный файл, который к типу аутентификации отношения не имеет. Есть базовая аутентификация (htpasswd), а есть digest аутентификация (htdigest). Отличаются они тем, что последняя хеширует данные алгоритмом md5.

Опять путаете. htaccess — это конфигурационный файл, который к типу аутентификации отношения не имеет. Есть базовая аутентификация (htpasswd), а есть digest аутентификация (htdigest). Отличаются они тем, что последняя хеширует данные алгоритмом md5.

Теперь понятно. Но я имел ввиду общую идентичность в плане результата, который оба способа несут.

И еще один момент. Многие разработчики предлагают некоторые плагины, которые якобы защищают сайт.
Например наткнулся на такой как jHackGuard.

Как вы относитесь к подобной защите? Нужна ли она или лишнее?

Например наткнулся на такой как jHackGuard... Как вы относитесь к подобной защите? Нужна ли она или лишнее?

Интересная игрушка: можно устанавливать различные блокирующие фильтры прямо в админ панели и блокировать юзера по IP, однако то же самое можно сделать и при помощи самописного скрипта, что гораздо проще. Учитывая то, что расширение было создано для специалистов (неспециалист не разберётся во всех этих фильтрах), данное расширение мне представляется лишним. Но функционал там интересный, хотя он ни в коем случае не заменяет защиту каталога "/administrator" от несанкционированного доступа. Если же каталог "/administrator" будет доступен, то можно произвести, например, SQL инъекцию, подобную той, от которой сейчас летят сайты на J! ниже версии 3.4.5.

хотя он ни в коем случае не заменяет защиту каталога "/administrator" от несанкционированного доступа. Если же каталог "/administrator" будет доступен, то можно произвести, например, SQL инъекцию, подобную той, от которой сейчас летят сайты на J! ниже версии 3.4.5.

То есть получается при должной защите админки (а именно с помощью SSL-сертификата) мощь плагина теряется и необходимость его установки отпадает аз ненадобностью?
И эти фильтры нужны только при условии отсутствия других форм защиты? Или все таки в комплекте с защитой SSL, плагин имеет вес?

То есть получается при должной защите админки (а именно с помощью SSL-сертификата) мощь плагина теряется и необходимость его установки отпадает аз ненадобностью?

SSL сертификат не спасёт от SQL инъекций и несанкционированного доступа к скриптам, в которых могут быть уязвимости, поэтому путь к папке "/administrator" надо по-любому закрывать либо моим способом, либо при помощи базовой/digest аутентификации. SSL/TLS шифрование сохранит вас от прослушивания хакером логина и пароля в момент передачи их на сервер и от чтения хакером ответных заголовков вашего сервера, в которых содержатся сессионные куки.

И эти фильтры нужны только при условии отсутствия других форм защиты? Или все таки в комплекте с защитой SSL, плагин имеет вес?

Фильтры нужны при определённых условиях, когда вы сами устанавливаете эти фильтры. Единственный плюс для неспециалиста от этого расширения — возможность заблокировать, например, бота по IP прямо в админ. панели.

rsfirewall, cdloginconfirmation, JSecure - советую всем, эти плагины и компоненты стоят у меня на сайте http://www.amen.in.ua/

Расширьте список и советуйте, что так мало.
@Igoritaly
Старайтесь обходится без дополнительных расширений, это мусор, Вам правильно сказали выше

Единственный плюс для неспециалиста от этого расширения — возможность заблокировать, например, бота по IP прямо в админ. панели.

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

Единственный плюс для неспециалиста от этого расширения — возможность заблокировать, например, бота по IP прямо в админ. панели.

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

В общем лучшая защита - это хорошие знания структуры CMS и работы с сервером.

В общем лучшая защита - это хорошие знания структуры CMS и работы с сервером.

Однозначно! Что ещё раз подтверждает концепцию, что пользователь != вебмастер. После недавнего эпического холивара на свалке сообщество разделилось на тех, кто считает, что пользователь ничего не должен, и вообще все должны считаться с отсутствием у него элементарной квалификации, и на тех, кто считает, что для мало-мальски серьезного проекта пользователь должен быть не пользователем вовсе, а квалифицированным вебмастером, как минимум :]