3 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Как установить пароль на (wp-admin)

Как установить пароль на wp-login.php (wp-admin)

Если вы установите пароль на доступ странице wp-login.php, вы добавите еще один уровень защиты для своего сайта.

Вы можете добавить защиту паролем на всю папку wp-admin, но это может нарушить работу некоторых плагинов, которые используют ajax во фронт-энде.

Обычно достаточно установить пароль только на wp-login.php.

В этой статье вы узнаете, как установить пароль на доступ к странице wp-login.php или к папке wp-admin вручную или при помощи плагина, и как разрешить использовать ajax, если вы установили пароль на папку wp-admin.

Как ищется инклуд…

Давайте сначала разберемся как именно взломщик пытается обнаружить уязвимость.

Выглядит это следующим образом. Злоумышленник модифицирует все входящие параметры по очереди, предполагая что данные этих параметров попадают в функцию инклуда. Ну или если по-простому пытается «приинклудить» файлы. И для того чтобы определить есть ли уязвимость или нет, ему необходимо приинклудить какой нибудь файл на целевой системе (приикнулдилось — уязвимость есть, нет — уязвимости нет).

Естественно если злоумышленник действует извне, то он не знает структуру расположения каталогов и файлов, и не может приинклудить любой файл, так как не будет знать пути к нему. Но бывают такие файлы, которые всегда существуют в системе, и к которым есть всегда права на чтение. Для Linux — это /etc/passwd, а для Windows — пусть будет C:boot.ini. Но впрочем Windows нас мало интересует, поэтому дальше мы будем говорить про passwd

Обнаружение SQL инъекций в ORACLE, часть первая

Данная статья более подробно исследует возможности администратора базы данных (DBA) в обнаружении SQL инъекций в Oracle. В этой статье мы сфокусируем внимание на исследовании некоторых методов трассировки данных и анализе лог файлов. Наша цель — показать читателю доступные решения.

Введение

В прошлом году были написаны две статьи о SQL инъекциях в Oracle. В них были описаны различные методы SQL инъекций, используемые в Oracle, даны простые примеры об их работе и некоторые предложения по защите от нападений злоумышленников, использующих эти методы. Статьи можно найти здесь:

Данная статья более подробно развивает данную тему и исследует возможности администратора базы данных (DBA) в обнаружении SQL инъекций в Oracle. Возможно ли вообще обнаружение SQL инъекции? Если да, то какие средства и методы должны использоваться?

В этой статье мы сфокусируем внимание на исследовании некоторых методов трассировки данных и анализе лог файлов. Наша цель — показать читателю доступные решения. В этой статье не упоминаются коммерческие решения. Так как настоящие инструменты обнаружения SQL инъекций включают в себя написание синтаксических анализаторов или фильтров для анализа SQL выражений, то полный показ таких методов, к сожалению, выходит за рамки короткой статьи.

Читать еще:  Для завершения восстановления системы требуется перезагрузк?

Можно ли обнаружить SQL инъекцию?

Ответ короткий — определенно да. вероятно. То есть да, возможно обнаружить SQL инъекцию, но вероятно, что не всегда и не во всех случаях, и не всегда в реальном времени. Причины этого сложны и их много:

Существует много различных форм атак с помощью SQL инъекций — они ограничены только воображением хакера и предвидением DBA (или его нехваткой) в защите базы данных и обеспечении наименьшего количества необходимых привилегий.

Обнаружение попыток SQL инъекций вообще и конкретно против Oracle возможно. Как возможно этого добиться, и какие данные являются доступным? В данной статье мы попытаемся исследовать эти вопросы.

Сначала необходимо определить граничные условия, или какие действия должны быть обнаружены. Затем нужно выбрать возможные бесплатные решения в рамках Oracle и как можно их использовать для достижения хорошего эффекта.

Некоторые возможные коммерческие решения

Нет никаких коммерческих решений, обнаруживающих попытки SQL инъекций, конкретно в базах данных Oracle. Существует определенное количество программ межсетевой защиты, которые объединяют Oracle proxy и несколько средств IDS, поддерживающих Oracle. В настоящее время множеством компаний серьезно разрабатываются проекты IDS приложений под Oracle, и возможно эти средства смогут обнаруживать SQL инъекции. Для должной работы большинства существующих коммерческих программ, необходимо использование правил и сигнатур, определенных для специфических случаев Oracle.

Некоторые бесплатные решения

Невозможно определить полный список всех типов и сигнатур SQL инъекций, но в качестве отправной точки можно выделить следующее:

Главное, сначала сделать все как можно проще; попытка делать что-то слишком сложное с помощью встроенных средств, в данном случае не принесет никакого эффекта. Важно не “перегнуть палку” с предположениями о том, что действительно является легальным SQL, а что создано хакером. Остерегайтесь ложных плюсов. Делайте это просто и действенно — используйте, если возможно, более одного метода, расширяйтесь и учитесь.

Любое средство или система, используемые для обнаружения SQL инъекций, могут идентифицировать большинство возможностей из вышеупомянутого списка. В попытке определить, откуда приходят данные для анализа SQL, следующие шаги должны быть полезными для одного и нескольких методов:

Фокусирование внимания на захвате SQL, а если возможно, то на получении timestamp и пользовательской информации, также как и возможный дальнейший анализ, приводят нас к следующему списку возможностей:

Из-за некоторых проблем нельзя находиться в полной уверенности. Средства аудита используются исключительно для более явных случаев. Если при шифровании сетевого трафика используются дополнительные параметры Oracle, то будет затруднено выделение SQL из сети. Использование трассировки имеет тенденцию генерировать огромные количества данных и потреблять системные ресурсы. Любой метод, не позволяет обнаружить инструкции Select.

Если невозможно обнаружить SQL инъекцию в реальном времени, то лучше узнать позже, чем вообще не знать, что это произошло.

Примеры с решениями

Теперь мы можем работать с некоторыми простыми примерами попыток SQL инъекций, используя пример из предыдущих статей. Первый шагом мы создаем типовую клиентскую таблицу, добавляем данные и создаем демонстрационную процедуру get_cust.

Ниже приведен пример попытки SQL инъекции, который будет использоваться далее, для того чтобы увидеть обнаружен ли он:

Читать еще:  ТОП-12 Лучших приставок для цифрового ТВ (DVB Т2)

Теперь мы проанализируем, какие из трассировок, пакетов, контрольной и внутренней информации, смогли записать любое из доказательств выполнения этого запроса.

Сборщик логов

Oracle поддерживает две хранимые процедуры базы данных DBMS_LOGMNR и DBMS_LOGMNR_D, позволяющие архивировать и интерактивно восстанавливать лог файлы, которые будут проанализированы. Восстановленные лог файлы содержат всю информацию, для воспроизведения любого действия в базе данных. Они используются для моментального восстановления, для транзакций и совместимости данных. Однако существуют некоторые, перечисленные ниже, проблемы с функциональными возможностями Сборщика логов.

SQL, сгенерированный Сборщиком логов, не такой как SQL, выполненный пользователем. Это происходит, из-за того, что восстановленные лог файлы сохраняют достаточно данных для изменения значений на уровнях строк и столбцов, так что невозможно воспроизвести первоначальные составные выражения.

Некоторые преимущества Сборщика логов:

Для того чтобы сделать практичным использование этого инструмента, база данных должна быть в режиме ARCHIVELOGMODE, а для размещения пользовательской информации значение transaction_auditing в файле инициализации должно быть true.

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

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

Теперь мы можем просмотреть пример и исследовать содержание архивных лог файлов. Сначала проверьте, находится ли база данных в ARCHIVELOGMODE, определите, где записаны архивные лог файлы и, наконец, что включен аудит имен пользователей.

Обнаружение, какой именно пользователь выполнил команду:

Теперь запустите пробную SQL инъекцию, а затем используйте Сборщик логов, для просмотра того, что было зарегистрировано. Для облегчения анализа этого примера, архивный лог файл сохраняется только до, и после выполнения этой команды находящейся в лог файле:

Сначала создайте словарь Сборщика логов:

Найдите правильный архивный лог файл:

Теперь загрузите архивный лог файл в Сборщик логов:

Наконец необходимо найти результаты:

Первое, что можно заметить это то, что Сборщик логов не обрабатывает команды select и отображает вывод в 9i. Модуль Сборщика логов не поддерживает выборки, поскольку они не сохраняются в восстановленных лог файлах. Возможно использование Сборщика логов, для онлайнового чтения восстановленных лог файлов, но я оставляю эти эксперименты читателям. Даже притом, что SQL инъекция может быть обнаружена в insert, delete и update выражениях, Сборщик логов не является подходящим средством для обнаружения SQL инъекций. Это, также как и некоторые другие проблемы, упомянутые выше, является недостатком в способности Сборщика логов обнаруживать команды select.

Анализатор сетевых пакетов

Главная проблема в анализаторе пакетов при подключении к базе данных Oracle это то, что сетевой протокол Oracle является собственным и не открытым. Это имеет ли значение при установлении, были ли попытки SQL инъекций? Вероятно да, поскольку доступ к протоколу был бы более эффективным инструментом для решения этой задачи. При отсутствии доступа к протоколу и желания это воспроизводить, задача ограничена только захватом строк ASCII-текста из шины. Существуют как преимущества, так и недостатки этого метода:

Система может быть реализована на отдельном сервере, позволяющем проводить анализ в реальном масштабе без влияния на исходную базу данных.

Анализ каждого пакета приводит к генерации огромного количества данных. Конвейеризация пакетов через программу-фильтр смягчает эту проблему.

Читать еще:  Как удалить неудаляемый файл: програма Unlocke?

Для демонстрации, мы будем использовать snoop на Solaris, чтобы увидеть то, что видимо внутри сетевых пакетов. Запустите snoop, и SQL из сеанса SQL*PLUS:

С помощью этого метода очевиден немедленный успех, так как SQL захватывается вместе с SQL инъекцией. Как и в других методах описанных в этой статье, должно быть выполнено следующее:

В качестве простого решения, анализ сетевых пакетов, может выступать в роли альтернативного решения, обеспечивающего достаточно простые фильтры/синтаксические анализаторы, написанные в Perl или C. Нашей целью является вывод возможных преступлений, выделяя SQL, timestamp и src и dest IP из пакетного потока.

Анализ внутренних сетевых пакетов Oracle (sqlnet trace)

Извлечение сетевой информации из Oracle возможно, используя средство трассировки SQL*NET, Net*8 или Oracle networking (смотря какое из названий подходит к версии вашей базы данных).

Средства трассировки доступны для большинства сетевых сервисов Oracle, таких как: listener, Oracle names, connection manager, names control utility, и конечно Oracle networking client and server. В этом примере мы сконцентрируем внимание на трассировке сервера.

Существуют некоторые недостатки в использовании сетевых трассировочных файлов, как средства поиска SQL инъекций:

Для включения трассировки необходимо в файле $ORACLE_HOME/network/admin/sqlnet.ora добавить следующие строки:

Параметры определяют, где должен быть записан файл трассировки, как он должен называться, а также его уровень. Существует четыре используемых уровня трассировки: OFF, USER, ADMIN и SUPPORT. Они повышают детализацию трассировки от OFF до SUPPORT; уровень SUPPORT учитывает содержание сетевых пакетов.

Давайте снова запустим наш пример из SQL*PLUS на Windows-клиенте и посмотрим, что было сгенерировано в a файле трассировки. Трассировочный файл, как и ожидалось, называется pf_trace_616.trc. Ничего себе! Этот файл содержит в себе 4005 строк, и это только из-за соединения и запуска следующей команды:

Выполнив поиск дампа пакета, в файле трассировке, мы можем найти попытку SQL инъекции, посланной базе данных:

При использовании файлов трассировки SQL*Net, существует еще ряд проблем, помимо перечисленных выше:

Этот метод не удобен, для выполнения простой утилиты обнаружения SQL инъекций. Ресурсные проблемы только затрудняют управление и работу. Можно использовать это более расчетливо, когда подозреваемый инцидент произошел и где использование трассировки может контролироваться на ограниченном отрезке времени или числе пользователей.

Подписывайтесь на каналы «SecurityLab» в Telegram и Twitter, чтобы первыми узнавать о новостях и эксклюзивных материалах по информационной безопасности.

Сменить стандартный логин администратора

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

Старый (скомпроментированный) логин можно удалить или временно заблокировать с помощью плагина Lock User Account (в списке Действий помимо Удалить еще появится выбор Lock и UnLock).

Еще почитать:

Защита WP

Бан хакеров по IP для WordPress

Варианты основных хакерских атак на Ваш сайт

Двухфакторная аутентификация WordPress

Закрываем папки и файлы WordPress с помощью Apache

Защита базы данных сайта MySql

Защита текста и картинок от копирования

Как сбросить пароль администратора WordPress

Как скрыть логин автора поста

Переводим сайт WordPress на https

Плагины для архивирования и переноса сайта

Вы можете сохранить ссылку на эту страницу себе на компьютер в виде htm файла

Ссылка на основную публикацию
Статьи c упоминанием слов:
Adblock
detector