С какой целью прятать, от брута или что?

Не стандартная пара логин:пароль и бан по кол-во не правильных попыток авторизации. Можно еще капчу повесить, но лучше уж тогда двухфакторку реализовать

Попробуй другую сетку для соединения и тунель конечно же с привязкой по маку. У нас так сделано сервак по тунелю и привязкой по маку. Пока взломов не было.

Вообще не редкость наверное в CMS вход в админку только от конкретного юзера, т.е. в админку попасть

можно либо залогинившись от админа например и тогда появляется раздел админки, либо тоже самое

но с двумя паролями, первый на пользователя, второй на админку. Второй соответсвенно по секурней будет.

Второй момент - это путь до админки, т.е. как скрыть ее. Тут два возможных варианта решения мне видится,

суть в принципе одна, но реализация немного разная:

-- рандомное имя админки + проверка на юзера. /my_super_adminka8909898908.php и если пинг не от админа

редирект на index. Ну и желательно чтобы все редиректило на index, ну или куда хочешь, но на одну страницу.

-- тут тоже самое, только юзаем request_uri. Панель входа в админку появляется только при определенном пути,

например domain.com/admin_super_puper_2020/ - ну имя соответсвенно тож рандом. Можно открыть доступ(панель входа)

только при наличии нескольких определенных параметрах - domain.com/admin/param1/param2/

И в первом и во втором случае никаких ссылок, вкладочек, менюшек и тд на админку не ведет.

Сидеть угадывать admin.php administrator.php и тд можно очень долго.

Путь сохраняешь себе + два пароля. Дешево и сердито

Плюс привязка к ip, железу не спасут от атак типа csrf, csrf via xss.

А используя один из вариантов выше, такое сложнее провернуть.

Дополнительно отсутсвие пути к админке в бд, например прописана только в конфиге,

потенциальная скуля даст пассы(которые еще пробрутить нужно), но не даст пути к админке

если не можем читать через нее, уязвимости типа file read дадут path, но одного его мало ...

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

Вобщем жизнь усложнит нормально я думаю.

Админку то я спрятал с дефолтных путей, первым делом. Я сталкивался на практике когда умельцы нашли какую то дырку некритичную, и если ответить на сообщение на сайте, то крались документ.куки и чел получал в том случае админские куки. Поэтому и ищу какое то изящное решение. Оно точно должно быть.

1) куки в httponly

2) Делаешь админа простым юзером. Даже если произойдет кража сессии, кук

атакующий с этим сможет сделать почти столько же, сколько просто зарегавшись

на сайте, кроме обмана юзеров от имени админа. Путь к админке он не знает, и если

то так и не узнает.

3) Выставляем две куки, первую для юзеров

cms_user=bwhfywugfsnbvhd

Вторую cms_admin=asfdegfrsgrshgrth для доступа в админку

Читай сообщения от юзера, пиши - атакующий получит куки юзера с ником админ.

Зашел в админку, сделал свои дела, вышел.

И этого будет достаточно, просто тут надо обратить внимание не на то, к чему ее привязать,

как спрятать и тд - а на поиск багов. Привяжи к железу, ip, спрячь ее - stored xss в имени пользователя

например работающая из админки - и не важно к чему что привязано и как спрятано.

По моему, если проект серьзный, читай денежный, то проще заказать модуль для многофакторной аутентификации через какой нибудь auth0. И пусть атакер хоть в лепёху расшибётся, ничего путного сделать, даже с пассом на руках, не сможет. Если CMS популярная, то скорее всего уже существуют плагины с таким функционалом.

+ за готовую многофакторную аутентификацию из предыдущей реплики

Если хочется поизвращаться - можно добавить скрытую авторизацию по дополнительному ключ-признаку (например, наличие нестандартного header в запросе на авторизацию, без которой все вводимые данные считаются неправильными)

deleted

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