На втором этапе я с удивлением обнаружил, что существуют такие звери, как PHP-shell. В этом мне помог Касперский, когда заблокировал доступ к моему столь любимому сайту. Следующим откровением было то, что вскрыть могут не только вас, но и хостинг. При этом шеллы появляются на вашем сайте с удивительной регулярностью, неизвестно откуда и делают, естественно, что хотят. Например, редактируют файлы .htaccess и закрывают их редактирование для всех, в том числе и для владельца.
Все эти откровения в свое время забрали огромное количество суббот и воскресений и потребовали перехода на рерайтинг урлов, создание развернутой системы анализа входных параметров на подозрительные слова и выражения (здесь я, кстати, потерпел некоторое фиаско), создание лога параметров, передающихся методом пост, системы оповещения о подозрительных событиях, происходящих на сайте, и, наконец, разрешения запуска только скриптов со специфическим префиксом в имени, чтобы никакой другой скрипт типа template.php или wso2.php не запускался.
Что же нужно иметь ввиду и что можно сделать для создания относительно безопасного сайта?
Стоит ли располагать файлы разных типов в отдельных папках?
Современный сайт, созданный на PHP, имеет обычно довольно разветвленную файловую структуру. В ней однозначно есть исполняемые скрипты, модули или классы, подключаемые инструкцией include/require, файлы .css и .js, страничный кэш. Вот этими файлами для простоты и ограничимся.
Я думаю на вопрос, заданный в подзаголовке, я отвечу утвердительно и это очень даже полезно. Так, например, подключаемые файлы PHP не предназначены для того, чтобы запрашивать их для обработки сервером и вывода в браузер. В папках подобного типа мы располагаем особый файл .htaccess, в котором запрещаем доступ кого-либо к чему-либо.
Deny from all
В папках с файлами .css и .js мы себе такого позволить не можем, но зато мы в этих папках можем ограничить доступ по типам, что тоже не плохо. Ниже приведен запрет на доступ к любым файлам кроме файлов с расширением .js
Deny from all
<FilesMatch "\.js$">
Allow from all
</FilesMatch>
Стоит заметить, что по моему опыту такое ограничение практически не влияет на реальную безопасность сайта и является, так сказать, только одной галочкой в общем списке дел. Сам я этими методами не пользуюсь, и об этом будет разговор ниже. Но, с другой стороны, усилий для этого тоже требуется минимум, так что почему бы и нет? Опять же, если против вас будет действовать какой-то сумасшедший робот, то он будет переть как трактор и портить все подряд. Если вы будете знать, что в папке у вас лежат только файлы с определенными расширениями, то легче будет обнаружить вредоносного пришельца.
Лично я пошел немного дальше. У меня файлы .css и .js сжимаются и кешируются, поэтому и папки, где лежат исходники могут быть закрыты от всех подряд. Сами же запрашиваемые кэши лежат в довольно глубоко закопанной папке, куда робот может и не дойти. У меня, кстати говоря, и исполняемый скрипт на весь сайт всего один. Но об этом чуть позже.
Стоит ли называть папки нестандартным образом?
Вот, кстати, хороший метод реально повысить безопасность своего сайта. Дело в том, что вредоносный робот ищет на сайте папки с определенными названиями. Это же относится и к файлам. Поэтому как одна из мер повышения безопасности — это изменение имен папок и файлов на что-то нестандартное. Стоит придумать что-то свое и дать именам хотя бы префиксы. Префиксы однозначно помогут от роботов. Если хотите попробовать затруднить и ручной взлом, то советую пойти дальше и дать папкам и основным файлам имена собственные (Петя, Маша и т.д.). Не многие молодые хакеры будут разбираться, где что у вас лежит. Хотя у хакеров, занимающихся взломом от скуки, не известно, какая каша может быть в голове. Но шанс, определенно есть! Главное самому не запутаться. Тоже шанс немалый.
Файл config.php, в котором лежит пароль доступа к базе данных в открытом виде
Вот это то, чего я никак не могу понять. Есть файл, который все знают, как называется, и в котором в открытом виде лежит именно то, что нужно хакеру. Зачем это делается? Это, на мой взгляд, вредительство какое-то. Крайне рекомендую на всех своих сайтах зашифровать данные для доступа к базе данных и разместить их в совершенно нестандартно названном файле, закрытом от доступа по сети и доступного только для чтения. Конечно, надо поработать над оптимизацией скорости расшифровки, но это тоже вполне решаемо. По крайней мере XOR действует довольно быстро (ссылка на Шифр Вернама в конце статьи). Главное иметь ключ хорошей длины и получше его спрятать. Можно создать действительно запутанный и очень эффективный алгоритм расшифровки и заставить хакера провести на вашем сайте много часов, прежде чем им будет найден и ключ и алгоритм его использования. Вы же вовремя злонамеренную деятельность видите, благодаря вашей собственной системе логирования-оповещения, пресекаете деятельность злоумышленника и меняете ключи, пароли, явки и так далее. Поэтому скачивать ваши скрипты и разбираться с ними до потери сознания для хакера может оказаться непродуктивным.
Безопасность запускаемых скриптов php
Очень важная тема. В первую очередь скажу, что публичный хостинг действительно могут вскрыть и на вашем сайте откуда ни возьмись окажется файл с условным названием template.php. Предположим, что ваша замечательная система логирования и оповещения через какое-то время, например, через 10 минут, определит появление в такой-то папке такого-то нового файла и пришлет вам об этом письмо. Казалось бы замечательно! Но шелл может за 10 минут такого на сайте натворить, что сайт на несколько часов выйдет в аут. Проходили. Знаем, о чем говорим.
И этой крайне существенной уязвимостью безопасности грешат большинство движков. Сделайте для примера файл с любым названием, например my_template.php, разместите в нем
<?php
echo 'hi!';
Далее разместите его в корне своего сайта на WordPress и вызовите его (скрипт). И он скорее всего сработает! Покажет вам ваш привет!
Вот какая эволюция методов борьбы с этим злом происходила у меня. Но я не работаю на бесплатных (и платных) движках и мне легче!
Сначала я сделал такой Урл-рерайтинг, при котором запускаться могли только файлы с определенным префиксом. Работает это следующим образом. На вашем сайте сам собой, без всяких подозрительных вызовов появляется вредоносный файл без префикса. Вы остаетесь в неведении. Далее идет попытка доступа к этому свеже-подсаженному файлу. У него нет префикса, и он не запускается, а вы тут же, без задержки получаете об этом письмо. Заходите на сайт, видите шелл, блокируете IP, с которого он запрашивался, пишете письмо на хостинг и поднимаете всех сотрудников на уши. Все, как бы хорошо кончается. Ссылка на статью, в которой я в «высоко-художественной и одновременно развлекательной» форме описал проблему и пути решения я укажу в подвале.
Бывает подсадка шелла, проходящая по более интеллектуальному, но для нас более безопасному алгоритму. Известно, что логи доступа на хостингах хранятся ограниченное время, чаще всего неделю. Злоумышленник подсаживает вам на сайт постронний файл — скрипт шелла и оставляет его чуть больше чем на неделю. Логи, в которых была видна уязвимость, пропадают и вы не можете определить уязвимость, которая была использована. Но в нашем случае мы, в течение считанных минут, получаем оповещение о появлении чужака в файловой структуре нашего сайта, так что этот, казалось бы, изощренный метод подсадки нам более предпочтителен и желателен.
Описанная система прожила у меня не долго и была успешно заменена. В итоге я пришел к следующей схеме, которую на сегодняшний день считаю близкой к идеальной.
Мы удаляем из .htaccess все правила урл-рерайтинга, которые там были и оставляем только одно правило, которое любой файл отправляет на один разъединственный исполняемый скрипт вашего сайта. Он имеет особое, ни на что не похожее название, как минимум префикс. Этот скрипт по REQUEST_URI разбирается, что же это пришло, делает всякие seo-действия по рерайтингу и решает, на какой скрипт передавать управление. Управление передается не рерайтингом, конечно, а путем подключения файла инструкцией require. В итоге доступ на вашем сайте разрешен всем, но выполняется всего один исполняемый php-скрипт. Все остальные скрипты лежат в отдельной папочке и защищены от запросов по сети и могут быть защищены инструкцией Deny from all. А могут и не быть.
Кстати, такая схема употребляется в некоторых движках. Но там всем управляет мега-скрипт index.php с 10 тысячами строк и более, и реализована эта схема вовсе не ради безопасности, а для того, чтобы было удобнее закрыть код от разворовывания.
Вот такое правило стоит у меня в .htaccess
RewriteCond %{REQUEST_URI} !^/sitemap\.xml$
RewriteCond %{REQUEST_URI} !^/favicon\.ico$
RewriteCond %{REQUEST_URI} !^/apple-touch-icon(?:\-precomposed)?\.png$
RewriteCond %{REQUEST_URI} !^/robots\.txt$
RewriteCond %{REQUEST_URI} !^/pref_dispatch\.php$
RewriteRule ^.*$ /pref_dispatch.php [L]
Обратите внимание, что пропускаем мы совершенно определенные файлы, которые у нас точно существуют, и на диспетчерский скрипт переводятся все запросы без исключения, а не одни только скрипты php. Кстати, можно и robots.txt, и sitemap.xml генерировать в диспетчере и отдавать, как скрипт. А можно и картинки…
Что происходит с урлом, который не проходит проверку в диспетчере?
Он записывается в "лог плохих ури". Этот лог я изредка просматриваю для того, чтобы определить, не запрещен ли у меня какой-либо нужный ури, и не нужно ли сделать переадресацию. Лог плохих ури зарекомендовал себя как один из самых полезных и занимательных инструментов в админке. Сразу видно кто ломится, куда ломится, и что, вообще, на сегодня интересно хакерам. Конечно, на первом месте стоит wp-admin и wp-config. Есть о чем задуматься любителям бесплатных движков.
Как сделать так, чтобы плохие ури собирались со всех папок, а не только с корня сайта?
В лог плохих ури попадают ури вида /very-bad-uri-script.php или /very-bad-uri-folder/. Но если ури имеет вид типа /existent-folder/very-bad-uri-folder/, этот ури в лог может и не попасть. При этом в лучшем случае в логе ошибок мы увидим строку типа File does not exist: /existent-folder/very-bad-uri-folder/
Если мы для папки /existent-folder отключили все для всех, то будет ошибка типа client denied by server configuration.
И то и другое не очень удобно. Дело в том, что вызов, попадающий в лог ошибок, уже не попадает в лог доступа, и мы не увидим никаких подробностей. Самое неприятное, что мы не получим никакого письма в случае подозрительной активности на сайте. Такая неприятность происходит из-за того, что в папке /existent-folder либо вообще отсутствует файл .htaccess, либо в нем не включен урл-рерайтинг. Для того, чтобы этого не происходило нам надо во-первых, разрешить доступ к этой папке всех, то есть стереть нашу строчку Deny From All, а во-вторых, включить урл-рерайтинг.
RewriteEngine on
RewriteBase /
RewriteRule ^.*$ /badurl/ [L]
Любой запрашиваемый файл сразу, прямиком отправляется в лог плохих ури со всеми возможными подробностями. Строчка об этом событии попадает в лог доступа и не попадает в лог ошибок. Мы получаем письмо от системы оповещения, но, конечно, если запрограммировали эту функциональность.
Вышеприведенный .htaccess подходит для замены функциональности "Deny from all". В случае, если нам надо что-то пропустить, например, скрипты js или таблицу стилей, то нужно либо разрешить запрос определенных типов файлов, либо, что лучше, задать скриптам особые имена или префиксы. Ну, или перечислить пропускаемые файлы явно. Но, боюсь, это уже слишком жестко в смысле продуктивности и программиста и сервера.
Атаки и блокирование вредоносных IP
Время от времени, но с удивительной регулярностью, на сайт происходят атаки. Среди этих атак есть такие, когда с определенного IP идут прозвоны страниц логина и регистрации пользователя, отправки писем через форму и приема объявлений. Это работают mail-сервера. Работают они чаще всего в паре с «чистыми» IP, которые не используются для атак, а используются только для прозвонов. Для определения сущности IP, занимающихся спамом, я сам использую и всячески пропагандирую сайт projecthoneypot.org.
Бороться с такими спаммерами оказалось крайне просто. Надо просто реализовать все эти формы аяксом и все. Одного только этого бывает уже вполне достаточно. Для пущей безопасности можно запретить вызов php-бэкенда, если он не идет с сайта.
Очень объемный трафик идет от сомнительных ботов. Почему сомнительных? Потому что я не знаю, полезны ли эти боты для сайта и зачем они ходят по моему сайту и звонят урлы, которые вышли из употребления много лет назад. Вообще, появление давным давно убитых урлов само по себе является компрометирующим действием для бота. Такие боты чаще всего не используют файл robots.txt или используют его в противоположном направлении, то есть для них существование списка запрещенных к просмотру адресов есть повод именно до них и ломиться. Тем не менее, эти боты честно метят себя в пользовательских агентах. Из таких я могу назвать 199.192.207.146 с агентом
Mozilla/5.0 (compatible; MJ12bot/v1.4.5; http://www.majestic12.co.uk/bot.php?+)или 185.53.44.90 с агентом
Mozilla/5.0 (compatible; XoviBot/2.0; +http://www.xovibot.net/)IP в приведенных выше примерах реальные, но понятно, что у этих ботов не один IP адрес, а много.
Есть и боты, маскирующиеся под хорошие, но, похоже, такими не являющиеся. Вот, например, 176.31.182.56 с агентом
Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)По действию этого IP на моем сайте у меня есть очень большие сомнения, что это действительно Googlebot.
Наконец, мне очень не нравится bingbot. Он крайне неаккуратный. Он обожает ломиться к сайту по несуществующим урлам. Все бы ничего, если не задумываться, где и в каких базах он эти урлы берет и почему не удаляет их из базы? Понятно, что этого зверя я не блокирую, несмотря на мое к нему отношение.
Но есть атаки не направленные явно на спам. Запросы могут сыпаться со скоростью несколько штук в секунду и представляют собой полную чушь. Часто испорченные и исковерканные запросы к самому сайту, а часто атаки на движки, из которых лидирует WP. Серия запросов обычно может быть от 100 до 200 штук в одной серии за сутки. Зачем ломиться до движков — понятно, наверное. Зачем пытаться добиться ответа сайта по исковерканным и часто вообще нечитаемым урлам мне не понятно. Но факт в том, что куча запросов с высокой скоростью замедляют и сам сайт и его соседей по хостингу и с ними стоит бороться.
Кстати, что такое «нечитаемый урл»? А вот что!
http://мой-сайт.ru/bulletin_board/ad_add/+++++++++++++++++++++++++++++++++++++Result:+%ED%E5+%ED%E0%F8%EB%EE%F1%FC+%F4%EE%F0%EC%FB+%E4%EB%FF+%F0%E0%E7%EC%E5%F9%E5%ED%E8%FF;+Result:+%ED%E5+%ED%E0%F8%EB%EE%F1%FC+%F4%EE%F0%EC%FB+%E4%EB%FF+%F0%E0%E7%EC%E5%F9%E5%ED%E8_cutted
Пожалуйста, не пытайтесь реально зайти по этому урлу на мой сайт, ибо в этом случае ваш IP будет помечен опасным и он будет поражен в правах.
Во-первых, урл имеет длину боле 255 знаков и его пришлось обрезать. Во-вторых, хоть все, что идет за словом «Result:» и декодируется (windows 1251), но все равно представляет собой чушь. Есть подозрение, что запрашивает этот урл XoviBot/2.0, причем в сравнительно больших количествах и всегда одинаковый.
Но как бороться? И стоит ли блокировать все подряд? Если с этим процессом трудно бороться, может быть его можно возглавить, или как-то по-другому к нему приспособиться?
Я, к сожалению, не знаю, каков круговорот плохих IP в природе, и могут ли плохие стать хорошими, а хорошие плохими. Поэтому я если и блокирую, то делаю это в ручном режиме. Если принадлежность IP из такой страны, где мой русскоязычный сайт скорее всего читать не будут, и деятельность слишком уж жесткая, я эти IP блокирую. Остальные оставляю.
В моей системе безопасности есть не только лог плохих ури, но и лог IP, когда либо вызвавших плохой ури. Спамовские, опасные, заблокированные и разблокированные IP, а также боты, учитываются в этом списке.
При заходе с заблокированного IP клиент попадает на специальную страницу, где ему предлагается нажать на кнопку и разблокировать IP. Кнопка аяксовая. Запись о блокировке автоматически меняется на «разблокированный IP». У меня сейчас порядка 20 заблокированных IP. Был ли хоть один из них разблокирован пользователем? Нет. Не был. Часто происходят заходы с уже заблокированных IP? Нет, исчезающе редко.
Для всех клиентов, приходящих с IP, которые как-либо помечены, никогда не производится дополнительная обработка их запросов. Для них не проверяется наличие обязательного обратного слэша, они не проверяются на список редиректов, для них не работает преобразование SEO адресов. Если запросы не являются полностью хорошими, то им тут же, без задержки, выводится краткое прощанье.
Но в последнее время я думаю о том, что можно усовершенствовать систему блокирования. Возможно, было бы полезно при обнаружении серии потока запросов с некоего IP, блокировать его на час. Боюсь только, что я уже так заоптимизировал схему обработки плохих ури, что блокировка IP и вывод ему стандартного прощанья примерно одинаковы по времени обработки.
Резюме
Выше описаны довольно простые действия, которые могут серьезно повысить степень защищенности любого сайта. У меня остается вопрос — почему же эти простейшие вещи не включены, кажется, ни в один движок? Ни в платный, ни в бесплатный?
Ссылки
Комментарии (89)
garex
03.08.2015 13:19+6Весьма похоже на отчаянную борьбу со следствиями, а не с причинами дырок.
belkin-labs
03.08.2015 13:26Вы правы! Очень точно выразились! Дело в том, что идет разговор о том, как защититься от шелла, подсаживаемого через рутированный хостинг.
garex
03.08.2015 13:40Тогда получается проще можно.
Если у нас какой-нибудь типовой движок, что скорее всего в 99.999% случаев, то заместо директивы «исполняй *.php» надо сделать директиву «исполняй webroot/index.php». Т.е. запретить всё везде и разрешить только в одном месте.
Без возможностей изменения ниже через .htaccess или иные варианты.belkin-labs
03.08.2015 13:52Именно это я, кажется, и предлагаю. Для типовых движков все может быть сложнее. Осложняется дело SEO рерайтингом, который везде реализован по-разному. В cs-cart, например, это делается с помощью аддона. То есть конечно, любой двиг можно преобразовать для безопасности. Но это может быть очень сложно и в каждом случае надо подходить индивидуально.
Если брать любой движок, то первым делом, на мой взгляд, надо зашифровать сведенья для доступа к базе. Так потеряв на некоторое время сайт, можно хотя бы базу данных сохранить и не просить пользователей, чтобы пароли меняли.garex
03.08.2015 15:06belkin-labs
03.08.2015 15:54К сожалению я не понял, что вы хотите сказать приведенной ссылкой.
Как бы там ни было, движки, с которыми мне приходится иметь дело, не кодируют данные для доступа к базам данных. А работать мне приходилось из известных с WP, JOOMLA, CS-CART. Из менее известных — MODX, ShopCms и несколькими другими. Причем, что удивительно, когда я клиентов пугаю перспективами этого открытого хранения, то никто не пугается! Ни один! А один клиент, имея магазин с оборотом 5 миллионов рублей в месяц, все пароли имеет одинаковые. Это имя его кошки. Предположим, «masha». Один раз я его напугал таки рассказом о том, чем это грозит и тогда в самом ответственном месте он изменил пароль на имя второй кошки, условно «dasha». После того, как я ему откровенно сказал, что я об этом думаю, он сжалился и изменил пароль на (опять же условно) «Masha,Dasha». Это меня более или менее устроило.
Скажите, вы считаете, что проблема высосана из пальца, а я «маньяк безопасности»?
XolodIT
03.08.2015 16:16+1Шифровать доступы к бд? Хм, из сотен очищенных шеллов наверное 1 случай привел к порче бд, на моей практики. А вот sql инъекции распространены (привет jooml'ы!) и здесь это не поможет. Короче не вариант.
И есть одно дешевое средство от простых паролей и простых пользователей — бэкап.belkin-labs
03.08.2015 16:35Я совсем не о порче БД говорю. Против порчи — бэкап хороший вариант.
Я говорю о том, что конкретное физическое лицо с преступными целями рутирует хостинг. Подсадят шеллы во все папки хостинга. Утянут пароли, зайдут в базы данных, найдут таблицу tralala_users и скопируют ее к себе на диск. В этой таблице скорее всего есть столбик с хэшами. Эти хэши вынут из столбика и загрузят на вход такому современному зверю с 200-ми или 500-ми процессорами, который работает круглосуточно и только и умеет делать — так это считать хэши.
После прохождения некотого времени какая-то часть паролей (подозреваю, большая часть) окажется расшифрованной. Эти расшифрованные пароли загрузят в другую базу данных и «скормят» серверу, который будет заходить на определенные сайты и опять же в круглосуточном режиме будет пытаться логиниться. Например, скайп, или в Яндекс деньги (там сейчас SMS-ки сделали в виде подтверждения), или еще куда-нибудь. И куда-то они залогинятся! И у какого-то количества пользователей на счету будут деньги, которые пропадут!
Именно поэтому, если у вас бизнес связан с деньгами и вы учитываете их на счетах пользователей, то секундное присутствие шелла уже грозит вам следствием (не была ли утянута база) и потом просьбой ко всем пользователям заменить свои пароли. Это может плохо отразиться на вашем бизнесе.
Очевидно, если вы работаете на известном движке, то задача такому мошеннику, который пароли собирает, облегчается до нельзя, поскольку точно известно, где брать, что брать и даже для каждого движка есть уже готовые скрипты, которые за 1 секунду все сделают.
В этой статье я хотел усложнить задачу мошенникам. Заставить их либо уйти сразу с сайта, поскольку на нем разбираться надо, как все устроено, либо хотя бы замедлить его работу. Тогда можно успеть зайти и заблокировать его IP.
Извините, что слишком подробно все описал. Надеюсь читать было нескучно.
Alexeyslav
03.08.2015 19:13А я бы не убирал стандартные файлы. Просто оставил бы их нефункциональными, или с безобидным содержимым — фейковые пароли и т.д. Если кто попытается влезть куда-то с фейковым логином/паролем — сразу блокировать IP до выяснения обстоятельств. Так же под немедленное подозрение тех кто обращается к стандартным файлам.
Пусть взломщик думает что он что-то получил. Очень сложно ориентироваться в комнате полной зеркал.
XolodIT
04.08.2015 17:06Хочу сказать, что причинно следственная связь, вернее то как вы ей манипулируете, доведет вас до 3-й мировой -).
Ну а хэши паролей хранятся не только в базах данных sql, а при необходимости вас все равно взломают, а пользователей не перевоспитаешь… т.ч. получается неразделенная безнадега параноика -).
garex
03.08.2015 17:23Никак нет. В любом движке есть конфиг. В том же WP это wp-config.php.
В нём вам рекомендуется делать заместо:
// define('DB_PASSWORD', 'masha'); // BAD BAD BAD!!! define('DB_PASSWORD', $_ENV['DB_PASSWORD']); // Good.
Как попадают в ENV значения DB_PASSWORD уже дело десятое. Напр. их можно прохардкодить в конфигах php-fpm'а, которые только руту для чтения доступны, а уже сайты запускаются под www-blabla, который даже хоть всё поламает — не прочитает тот конфиг через шельные вызовы.
Вот только он точно также сможет прочитать $_ENV['DB_PASSWORD'], если будет использоваться маска "*.php" для запуска.
Ps: Вариант хорош, когда у вас есть доступ к способу запуска php под разными правами. Для стандартных shared серверов под cPanel'ями не подходит.belkin-labs
03.08.2015 17:46Понял. Вариант близок к тому, что я предлагаю. Не уверен, правда, что можно хоть что-то прохардкодить на публичном хостинге от имени рута. Если только админов попросить? Но у админов есть супер-отговорка: «Мы такого не делаем. Извините за беспокойство».
grayfolk
03.08.2015 17:51Вот только он точно также сможет прочитать $_ENV['DB_PASSWORD'], если будет использоваться маска "*.php" для запуска.
Это ключевая фраза. Повторюсь, если получен прямой доступ на ftp — обсуждать далее нечего.belkin-labs
03.08.2015 18:02Повторюсь, если получен прямой доступ на ftp — обсуждать далее нечего.
Да! Так и есть!
DarkByte
03.08.2015 19:02Ну окей, в таком случае зашифрованный пароль и алгоритм шифрования находятся все зоны доступа, но теперь банальный вызов phpinfo() покажет всем желающим пароль от БД. Некоторые движки/фреймворки любят показывать вместе со стек трейсами содержимое глобальных массивов, включая _ENV. Была уязвимость раскрытия информации, а стала уязвимость раскрытия реквизитов доступа. По-моему хуже стало :)
belkin-labs
03.08.2015 19:24Для того, чтобы вызвать php-info() надо сделать скрипт с этим вызовом.
- Если будет скрипт — он не вызовется
- Для вставки кода в существующий скрипт, надо зайти на ftp, и это сложно. надо знать пароль. Иначе надо знать, как скрипт называется и переходим к пункту 1
- Если будет утащен весь сайт, то опять нужно либо по ftp заходить, либо см. первый пункт. И в любом случае придется очень долго разбираться в алгоритмах шифрования
- Про ENV — это не моя идея, а создателей WP. Я за свой метод стою.
DarkByte
03.08.2015 19:45В данном случае я именно про использование _ENV в качестве хранилища для чувствительной информации. А вот phpinfo довольно часто приходится видеть на сайтах лежащим в корне под разными именами, а в некоторых движках это даже встроенная фитча, и иногда она даже открыта для всех желающих, а не только для администраторов.
Так же в некоторых случаях зачем то оставляют скрипты для проверки совместимости движка и хостинга, среди функций которых можно найти проверку подключения к БД, которая так же позволяет ввести произвольный адрес mysql сервера, имя пользователя и пароль. При удачном стечении обстоятельств злоумышленник с использованием этого скрипта и фишки «LOAD DATA LOCAL» может прочитать и конфиг с зашифрованным паролем и алгоритм для его декодирования. И без доступа к FTP :)belkin-labs
03.08.2015 20:12Согласен!
Может быть случаи, которые вы приводите — это безалаберность админов? В доках, вроде не советуют такие вещи делать, а доки читаются первыми (хабр за доками идет).
Но хочу еще добавить, что и хостинги содержат много настроек безопасности, о которых узнаешь только когда с ними сталкиваешься. Вот, например, с какого-то момента хостом баз данных стал повально использоваться localhost, и достучаться до базы данных стало возможно только локально, то есть с родного сайта. То есть, заметьте как интересно, все опять упирается в левый скрипт в корневой папке. Я, возможно, скажу крамолу, но есть ощущение, что после повсеместного внедрения урл-рерайтинга, подсадка шелла осталась единственным реальным методом «хорошо взломать». Ну или откровенные поделки, которые действительно, кроме любителей и не нужны никому.
garex
03.08.2015 21:02<?php // auto_prepend_file by php-fpm's php_admin_value $secure = getenv('WTF'); putenv('WTF=***********'); unset($_SERVER['WTF']); unset($_ENV['WTF']); // your file phpinfo();
Это стандартный способ:
* не хранить логин/пароль в исходниках
* не хранить логин/пароль в коде в принципе
В любом случае, имея доступ к куску кода, который откуда-то получает логин/пароль, его можно добыть. Но он точно не на ладони будет. И в случае утечки исходников, он также не улетит вместе с ними.
PS: Опять же для стандартного окружения, на которое расчитаны овер100500 CMS'ок это не вариант в любом случае.
Bibainet
03.08.2015 13:54+1Во-вторых, все, что идет за словом «Result:» не декодируется. Я не могу определить кодировку и это точно не utf8.
Нормально декодируется и там windows-1251: «Result: не нашлось формы для размещения; Result: не нашлось формы для размещени_cutted»belkin-labs
03.08.2015 14:02Либо это мой позорный пролет, либо я неудачный пример подобрал.
belkin-labs
03.08.2015 14:19Да! Пролет! Я, оказывается, пользовался плохим онлайн-декодировщиком. Сейчас поискал другой и да! Вы абсолютно правы! Сейчас я перефразирую этот абзац.
Bibainet
03.08.2015 16:45Похоже что этот запрос от XRumer. Берется строка из результатов его выдачи и копируется в адресную строку как есть вместе с этим текстом.
А декодировал я с помощью PHP urldecode.belkin-labs
03.08.2015 17:04Понял. К своему стыду у меня нет ни одного локального проекта в этой кодировке. А делать специально неохота. Но есть удобные онлайн сервисы. И некоторые даже работают.
redc0de
03.08.2015 15:56Крайне рекомендую на всех своих сайтах зашифровать данные для доступа к базе данных и разместить их в совершенно нестандартно названном файле, закрытом от доступа по сети и доступного только для чтения.
Ужасно неудобно, непродуктивно и я не припомню подобного в популярных фреймворках
andrewiWD
03.08.2015 16:22CMS — зло. Если проект более-менее крупный и ему начинает быть нужна продвинутая безопасность, то стоит обратить внимание на фреймворки.
С точкой входа — все ок. Она должна быть одна (если нет API или чего другого).
Насчёт безопасности конфигов — весь бекенд обычно выносят за пределы корня веб-сервера. Выставляются корректные права. Не забудьте так же обезопасить скрытые директории (от git к примеру, или IDE). Это сделает невозможным добраться до исходников с веба. Если косячит хостинг — убегайте от них!belkin-labs
03.08.2015 16:41Спасибо! Согласен на 100%!
Хотел добавить. Только вчера я просматривал результаты очередной атаки на свой сайт. Знаете что хотели утянуть?
/index.zip
/files.zip
/htdocs.zip
/file.zip
/www.zip
/belkin-labs.zip
Как я и говорил, система логирования и сбора плохих ури дает развеселые результаты!
Будьте осторожны! Некоторые мои регулярно клиенты держат подобные зипы в корневых папках. Причем именно те, кто сидит на выделенных серверах и кому места на этих серверах девать реально некуда!DarkByte
03.08.2015 19:15+1К вашему списку потенциально опасных URL предлагаю добавить коллекцию товарища Bo0oM, которую он презентовал на одной из конференций по ИБ: bo0om.ru/fuzz.txt
belkin-labs
03.08.2015 19:27У меня у самого накопилось этих урлов на 900 страниц уже. Уже сделал сводную таблицу. Но спасибо за наводку. Я, если честно, хочу свой список в общий доступ выложить. Да все не соберусь. Выложу — презентую.
Alexeyslav
03.08.2015 19:20Как вариант, подсовывать в таком случае мусор. бесконечный файл с random. Пусть боты удавятся(если трафика исходящего не жалко)
belkin-labs
03.08.2015 19:28На публичном хостинге у нас есть соседи по серверу. Так что вообще трафика очень жалко!
Alexeyslav
03.08.2015 19:35Ну ладно, тогда мусор покилобайтно. А если совсем-совсем жалко, то просто не отвечать.
belkin-labs
03.08.2015 19:37У меня есть некоторые случаи, когда я вообще посылаю очень далеко. Пишу «Большое спасибо» и все. Без объяснений
Alexeyslav
04.08.2015 10:09Ботам ваш ответ даёт сигнал о том что сайт жив и его надо дожимать. Проще всего ботов игнорировать, пусть стоят в ожидании ответа до таймаута. Потыкаются потыкаются, посчитают сайт мёртвым и уйдут.
belkin-labs
04.08.2015 10:30Вы знаете, я тут использую очень спорный прием. Заходы ботов и подозрительных IP на мой сайт я использую практически. На каждый такой заход у меня стоит полезная нагрузка. Проверка порции папок на новые файлы, отсылка уведомлений пользователям о комментариях на сайте и так далее. Я не использую никаких кронов. Поскольку заходов довольно много (200-300 в день), то все сервисные дела ими покрываются. А то, что львиная часть происходит ночью — даже хорошо. Своеобразный естественный крон получается.
DoctorX
05.08.2015 21:36Но зачем?
belkin-labs
05.08.2015 21:50Как альтернатива крону (cron — демон-планировщик задач в юникс-подобных системах). В настоящее время получается так, что когда спам-робот заходит, антиспам-система определяет его, и перед тем, как он получит ответ, на сайте выполняются некие сервисные действия из очереди этих действий. Например, проверяется целостность файловой системы, отправляются уведомления пользователям о появлении новых коментариев к статьям. Таким образом, робот вынужден какое-то очень малое время ждать. Мне этот факт греет душу.
grayfolk
05.08.2015 23:49отправляются уведомления пользователям о появлении новых коментариев к статьям
А если вдруг боты перестанут заходить — пользователи никогда не получат уведомлений? Зачем изобретать велосипед, тем более, что крон разрешен на подавляющем большинстве шаред-хостингов.
ionicman
06.08.2015 15:52т.е. в случае DOS атаки, Ваш сервер будет залипать по черному — отлично!
grayfolk
06.08.2015 15:58В случае такой атаки любой сервер будет залипать ))
ionicman
06.08.2015 16:02Ну да, только вот степень залипания будет разной :)
Ну и согласитесь, что чем быстрее сервак избавляется от бота — тем меньше он залипает.
DOS разный бывает, бывает кроме него просто флуд.
а к Автору:
А если честно все это — даже не велосипед, это костылестроение.
В случае определения что зашел бот — нужно как можно более быстро и с минимальным количеством ресурсов избавиться от него, а не пытаться использовать. Иначе сервак захлебнется при флуде или досе.
Обычно сообщается IP антифлудеру вместе с датой (чтобы обновить / продлить бан ) и выходится, усе — в следующий раз оно не пройдет. Просто при бане по IP (если он есть) есть риск забанить прокси, через которую сидят кроме бота и невинные пользователи, по этому бан обычно по времени или есть возможность выхода из него при нормальной активности.
Иногда можно репортить IP/хэш от всего, к чему можно привязаться у пользователя (UserAgent, система и т.д.) — это помогает делать бан более избирательным и гибким.
Мой Вам совет разобраться во всем этом, прежде чем «картины писать». Ибо у Вас велосипедостроение + непонимание как что работает и как нужно = костылестроение (ибо свой велосипед далеко не всегда плохо, а вот велосипед без понимания — это костылище).
И не в обиду Вам будет сказано — я бы гнал таких вот любителей натюрмортов из команды поганой метлой.
DarkByte
03.08.2015 16:41+3Вот это то, чего я никак не могу понять. Есть файл, который все знают, как называется, и в котором в открытом виде лежит именно то, что нужно хакеру. Зачем это делается? Это, на мой взгляд, вредительство какое-то.
Просто так файл config.php прочитать не получится, веб сервер же не отдаёт его в открытом виде. Ну а если злоумышленник нашёл уязвимость типа чтение произвольных файлов, то зачем ему угадывать имя конфига, если почти наверняка точка входа index.php (или иная, описанная в .htaccess), и одной из первых строк будет инклуд файла с конфигом?
Крайне рекомендую на всех своих сайтах зашифровать данные для доступа к базе данных и разместить их в совершенно нестандартно названном файле, закрытом от доступа по сети и доступного только для чтения.
Это как? Покажите пример, а то не совсем понятно что вы предлагаете. Если вы делаете вызов mysql_connect(..., decrypt($crypted_password), ...), то что мешает злоумышленнику сделать вызов print(decrypt($crypted_password))? Алгоритм шифрования лежит рядом, шифрование обратимое, не знаю над чем можно зависнуть на пару часов в данном случае.
В целом, когда вы используете shared хостинг, то заведомо не можете защитить себя от взлома хостера. Ведь ничего не мешает злоумышленнику добавить к вашему .htaccess строчку со своим «php_value auto_prepend_file». Такой вариант рассматривали?belkin-labs
03.08.2015 16:46Просто так файл config.php прочитать не получится, веб сервер же не отдаёт его в открытом виде. Ну а если злоумышленник нашёл уязвимость типа чтение произвольных файлов, то зачем ему угадывать имя конфига, если почти наверняка точка входа index.php (или иная, описанная в .htaccess), и одной из первых строк будет инклуд файла с конфигом?
Проблема именно в том, что у вас на хостинге оказывается чужой скрипт. Прямо в корневой папке. И этот скрипт работает у вас на сайте от имени владельца, что есть делает все, что угодно! И бывает так, что это не ваша вина, не уязвимость сайта или кода. Советую ознакомиться со статьей по второй ссылке из подвала (детективная история). Там все описано в красках.
На счет примера я, возможно, сделаю отдельную статью, если у уважаемого сообщества возникнет интерес к теме.DarkByte
03.08.2015 17:02Если злоумышленник порутал машину хостера и может творить на ней что ему вздумается, то в какой то момент он догадается, что auto_prepend_file можно сделать глобально в настройках веб сервера, поэтому ему совершенно не обязательно палиться на изменении файлов вашего и других сайтов. Кстати, при желании, php шелл можно оформить в виде одного .htaccess файла. Историю прочитал.
belkin-labs
03.08.2015 17:12Вы знаете, я свято верю в то, что на любую крутую гайку рано или поздно найдется особый изогнутый винт.
Я не очень знаком с разделом рутирования хостингов. Возможно, администрация как-то все же защищается от настолько явных дыр.
belkin-labs
03.08.2015 16:51В целом, когда вы используете shared хостинг, то заведомо не можете защитить себя от взлома хостера. Ведь ничего не мешает злоумышленнику добавить к вашему .htaccess строчку со своим «php_value auto_prepend_file». Такой вариант рассматривали?
Я продолжаю работать и совершенствовать свои подходы. Для того, чтобы уберечь .htaccess от прямого редактирования, нужно, на мой взгляд, использовать стандартные средства защиты ftp.
- Заходить только по SFTP
- Не хранить пароли в клиенте
- Не разрабатывать сайты на Windows
- Менять пароли к FTP по регламенту
DarkByte
03.08.2015 17:15Выставить права только на чтение при заливке по фтп это конечно хорошее решение от модификации файлов со стороны самого веб-приложения, но ведь в вашем случае был взлом хостера. И наверное логично было бы предположить, что раз хостер не позаботился о безопасности одного своего сервера, то с другими серверами тоже может приключиться подобная беда, не исключая сервер админки хостинга и биллинга. Ну а когда ему удалось слить пароли пользователей (они ведь в открытом виде хранятся), то частота смена паролей и используемая ОС на безопасность сайта не повлияет.
belkin-labs
03.08.2015 17:28Согласен!
Но мне кажется, что не нужно успокаивать себя тем, что если кому-то надо вас взломать — вас взломают. Надо все равно попытаться злоумышленнику помешать. Мы все знаем, что умрем когда-нибудь. Но ведь живем зачем-то… сайты делаем… и все такое…
Кстати, я не предлагал бороться с проблемой выставлением жестких прав. Я всегда думал, что это так или иначе надо делать. Есть много чего в документациях на эту тему. Я эту тему просто не рассматривал.
belkin-labs
03.08.2015 16:59Это как? Покажите пример, а то не совсем понятно что вы предлагаете. Если вы делаете вызов mysql_connect(..., decrypt($crypted_password), ...), то что мешает злоумышленнику сделать вызов print(decrypt($crypted_password))? Алгоритм шифрования лежит рядом, шифрование обратимое, не знаю над чем можно зависнуть на пару часов в данном случае.
Схема следующая.
Есть файл php в котором лежит заранее зашифрованные сведенья. Это строка бинарная, поэтому я ее кодирую base64. Строка зашифрованных сведений оформлена в качестве константы.
Первый же скрипт, которому нужна база расшифровывает эту строку. Ключ лежит в секретном месте. Сам ключ перед использованием меняется. К нему добавляются так называемые отпечатки пальцев (секретные). Добавили отпечатки, взяли md5 какое-то количество раз и вот то, что получилось используем в виде ключа. Для шифрования XOR-ом хорошо бы иметь ключ такой-же длины как и данные. Ну мы не лыком шиты и придумываем что-нибудь, чтобы получить ключ нужной длины. Смысл в том, что нельзя взять просто ключ, который лежит, но который надо найти. Его еще трансформировать надо правильно.
Данные расшифровываются и кладутся в глобальную сферу. Ну и все другие методы, которые лезут в базу данных, используют сведенья из глобалов.
Вот вкраце так.
Да! Поскольку зашифровать вручную практически невозможно (слишком трудно) у меня есть локальный скрипт, который делает это быстро и надежно.
grayfolk
03.08.2015 17:11Первый же скрипт, которому нужна база расшифровывает эту строку.
Что мешает злоумышленнику увидеть расшифрованное? Либо сразу, либо так —Ну и все другие методы, которые лезут в базу данных, используют сведенья из глобалов.
belkin-labs
03.08.2015 17:20А как он увидит? Я не понял. Поясните, пожалуйста.
grayfolk
03.08.2015 17:22print(), echo — есть варианты, разве нет? В чем проблема вывести какие-то данные в браузер, в файл? Выше уже ведь написали.
DarkByte
03.08.2015 17:21Среди «других методов» может оказаться добавленный злоумышленником в .htaccess (или конфиг веб сервера) скрипт вида «if(isset($_COOKIE['iamhacker']))phpinfo();» с использованием auto_append_file. Можно конечно затирать глобалсы перед завершения выполнения веб-приложения, но всё равно, если скрипт умеет декодировать пароль, а злоумышленник видит скрипт, то трудно будет ему усложнить задачу расшифровки пароля.
grayfolk
03.08.2015 17:25Вот именно. Мне вообще непонятен предмет обсуждения. belkin-labs, если злоумышленник получил доступ к вашим файлам — то все, обсуждение можно закрывать, защищаться в таком случае можно только святым духом — и то, вряд ли поможет :)
belkin-labs
03.08.2015 17:35Если злоумышленник зайдет на мой сайт по фтп, скачает весь сайт, то ему потребуется довольно много времени, чтобы получить сведенья по доступу к базе данных. Я успею заменить все пароли к тому времени.
Если он зайдет от моего имени в мою админку на хостинге, тогда да. все пропало и можно уже ничего не обсуждать.grayfolk
03.08.2015 17:37Возможно, я что-то пропустил, но каким образом вы на шаред-хостинге будете отслеживать активность ftp? Сидеть в cpanel и обновлять страничку ежеминутно-секундно?
belkin-labs
03.08.2015 17:51Нет. Я выше предлагал средства для затруднения злоумышленникам доступа на ftp. К сожалению, только это. Больше никаких методов я не знаю.
veam
03.08.2015 17:12После взлома у хакеров будет доступ ко всем вашим скриптам, скопипейстить этот код труда не составит.
belkin-labs
03.08.2015 17:21Я надеюсь, что достаточно затруднил ему взлом, чтобы успеть заблокировать его раньше
veam
03.08.2015 17:23Вообще на моей памяти базами интересовались крайне редко.
В основном ломают ради черного сео либо ради продажи трафика под трояны.belkin-labs
03.08.2015 17:53Странно, а на моей памяти интересовались только базами. Может поэтому я так и озаботился.
grayfolk
03.08.2015 17:26Чем, интересно, доступ затруднен? И, например, если произошел наихудший случай, и взломщик имеет рутовый доступ к серверу хостера — ваши блокировки, увы, не помогут.
belkin-labs
03.08.2015 17:39Я не очень хорошо себе представляю, как вскрываются хостинги. Все мои сведенья почерпнуты из интернетов. Я же не могу спрашивать у админов хостинга о том, как их вскрыли? Правда? С вероятностью 100% я буду послан.
Если в итоге взлома у меня в файловой структуре появляется посторонний файл, я узнаю об этом в течение 10 минут. Если будет попытка запуска подозрительного скрипта, он не запустится, а я узнаю об этом еще быстрее.
Если злоумышленник укачает мой сайт, он очень долго не сможет расшифровать данные по доступу к базе. Я успею их поменять.
Так что я не совсем затрудняю доступ. Скорее я увеличиваю шанс того, что я вовремя его поймаю за хвост.grayfolk
03.08.2015 17:49Если в итоге взлома у меня в файловой структуре появляется посторонний файл
Лично я вижу два пути появления такого файла:
- Плохой хостер (плохо настроенный сервер, плохо настроенные права и т.п.) — и очевидно, от такого хостера надо бежать.
- Плохой код, позволяющий злоумышленнику загрузить файл на сервер. Решение в данной ситуации тоже очевидно.
Если в итоге взлома у меня в файловой структуре появляется посторонний файл, я узнаю об этом в течение 10 минут. Если будет попытка запуска подозрительного скрипта, он не запустится, а я узнаю об этом еще быстрее.
А если будет изменен существующий скрипт? Тот же index.php?belkin-labs
03.08.2015 17:55Обсуждение как-то само свелось к обсуждению пункта 1. Бежать от хостера просто, если вы не участвовали в партнерке и не накопили в ней кучу бабла. И еще если вы уверены, чтоследующий хостер будет на много лучше.
Для того, чтобы изменить существующий скрипт, надо знать его имя. Перечитайте статью, у меня нет index.php.grayfolk
03.08.2015 18:02Перечитайте статью, у меня нет index.php.
Какое это имеет значение, если мы попали на ftp? )))
Бежать от хостера просто, если вы не участвовали в партнерке и не накопили в ней кучу бабла.
Тут ничего сказать не могу — не в курсе, что за партнерка, но, вероятно, не обязательно продолжать покупать хостинг для участия в партнерке и продолжения заработка?
И еще если вы уверены, чтоследующий хостер будет на много лучше.
Лично мне видится такая ситуация:
Все зависит от важности, так скажем, сайта. Персональную страничку Иванова Васи, обновлявшуюся в последний раз более пяти лет назад, тоже могут взломать. Но скорее всего, взлому подвержены более интересные проекты, более посещаемые, хотя бы. Серъезный проект, как уже говорилось выше, располагать на шареде глупо. Разумеется, и на впс, к примеру, есть свои проблемы с безопасностью, как и везде, но это уже тема совершенно другого разговора. Сорри за ИМХО.belkin-labs
03.08.2015 18:21Ваша позиция ясна. Я очень со многими ее положениями не могу согласиться. Углубляться в обсуждение не хочу, ибо они не программистского плана.
grayfolk
03.08.2015 18:36Моя позиция такова, что ваш пост не предполагает никаких решений, ибо ищутся эти решения не под реальные возможные проблемы, а под то, что вы себе сами придумали. При этом, даже банальный вход по ftp все ваши решения сводит к бессмысленной трате времени — толку от них в такой ситуации — ноль.
Как по мне, глупо искать решение тех проблем, которые вы не можете решить (например, безопасность шаред-сервера) и при этом игнорировать простые действия (как то переезд на впс), при которых потребность в ваших решениях отпадет сама собой.XolodIT
04.08.2015 16:52+1, но шаред безопасен, если он на CloudLinux (cagefs), например. Т.ч. шаред это не небезопасно, я бы даже сказал, что где-то безопасней вдс, которую еще надо уметь готовить, если подходить к делу с паранойей.
ionicman
03.08.2015 22:52+4Вы предлагаете ерунду, уж простите.
Если я каким-либо образом залил скрипт к вам на сайт и смог выполнить его — я смогу вытащить весь сайт, включая все переменные окружения, а потом уж разобраться, как вытащить пароль для БД — дело 5 минут. Мало того — я даже разбираться не буду — найду, где выполняется SQL и засуну туда дамп. Причем, для запуска скрипта вообще не надо создавать какие-то доп. файлы — можно исполнить «на лету», либо модифицировать существующее.
Если я смог скомпромитировать хостера, или как-то по другим образом получил доступ до FTP — все получается тоже самое, за исключением переменных среды.
Переименовывать файлы, криптовать пароль БД в случае получения доступа к исполнению или FTP — совершенно бесполезно и господин grayfolk абсолютно прав.
Все это называется security through obscurity и у хаккера вызывает лишь улыбку, при получении контроля FS или исполнения.
vshemarov
04.08.2015 00:30Крайне рекомендую на всех своих сайтах зашифровать данные для доступа к базе данных и разместить их в совершенно нестандартно названном файле...
А ключ для расшифровки ведь тоже где-то надо хранить. И варианта тут два — либо в каком-то аналогичном файле, либо прямо в коде. Для тиражируемых решений второй вариант однозначно не годится. Значит, кроме файла config.php будет, условно говоря, еще и key.php. И если хакер может прочитать config.php, то что мешает ему прочитать key.php?
При этом надо учесть, что раз нет возможности писать пароли непосредственно в config.php (ведь туда пишется уже зашифрованное значение), то должен быть некий интерфейс для ввода пароля, чтоб движок его зашифровал и туда записал.
Назвать конфиг-файл как-нибудь нестандартно и положить по нестандартному пути мало что даст, если речь о типовом известном движке, т.к. хорошо известно, где этот файл должен подключаться. А это значит, что если уж хакер получил доступ к коду, он без труда узнает «секретные» имена и пути.
В общем, сдается мне, что предложенный вариант создаст больше проблем для разработчика и админа сайта, нежели для злоумышленника.Alexeyslav
04.08.2015 10:20На то чтобы разобраться где лежит пароль и вытянуть его нужно будет время. Особенно если реальный пароль при наличии фейковых конфигурационных данных будет зашит в одном из неприметных модулей которые еще ко всему будут обфусцированы и для пущего счастья расшифровывать сохраненный пароль по ключу находящемуся на соседнем хостинге и при работе сайта хранящемся в RAM.
А если подключение к БД еще и подписать… то пароль ничего не даст. При обнаружении взлома меняются ключи и вся имеющаяся у взломщика информация не позволит получить доступ к БД.
Главный критерий — чтобы взломщик не мог получить реальные реквизиты доступа к БД раньше чем будет обнаружено вторжение.
Кстати, фейковые реквизиты вполне могут работать но ссылаться на фейковую базу данных. И пока он будет выкачивать подставную базу(сам факт обращения к базе должен служить сигналом!), можно предпринять нужные действия.vshemarov
04.08.2015 14:20Описанные Вами приемы — это все подразумевает, что сайт либо на фреймворке создается (либо вообще самописный), либо на CMS, очень основательно подработанной напильником. В любом случае — это некий уникальный (а не тиражируемый) проект, и разработчик имеет достаточную квалификацию и постоянно обслуживает сайт. Но в таком случае, как правило, и сисадмин проекта — не студент первого курса, и большинство описанных в статье потенциальных «дыр» — это для него банальности. Поэтому все эти приемы с прятанием паролей — это, скорее, дополнительная подстраховка к мерам, которые предприняты на системном уровне.
А тут, как мне кажется, статья рассчитана, главным образом, на тех, кто создает сайты, используя готовые тиражируемые решения, и для таких случаев описываемые Вами меры мало применимы.
makkintosh
04.08.2015 09:05Для начала с публичных хостингов надо бежать.
Или выбирать более надежные.
Но это отдельная тема.
Защищаться фильтрованием плохих айпишников тема бесполезная, защитит конечно от тех, кто не пользуется проксями/торами и другими хачеными сайтами/серверами.
Если исключить проблемы с дырявым хостингом то поможет защита ВСЕХ файлов и каталогов от записи, а те директории куда должны складываться media данные(загружаемые пользователями картинки и другие файлы) запретить php handler.
Далее храним исходники сайта в git и регулярно делаем git reset --hard && git pull
Если интересно что поменялось с времени последнего reset/pull – git diff > some_log_file.log с текущей датой и отправкой этого документа по почте если что-то нашлось.
Если делать это достаточно часто – можно оперативно узнать о проблеме и что именно «залили».
А все эти извращения с шифрованными паролями и прочим прочим – способ себя занять, не более.
MoonGrate
04.08.2015 09:22Этот скрипт по REQUEST_URI разбирается, что же это пришло, делает всякие seo-действия по рерайтингу и решает, на какой скрипт передавать управление.
Вы изобрели паттерн Front Controller, и он реализован во всех приличных современных PHP фреймворках.belkin-labs
04.08.2015 10:01-1Я думаю все хорошее уже изобретено в нашей сфере. Только очень глубоко закопано. Я бы никогда не взял на себя смелость заявлять, что что-то изобрел. Это слишком опасно для имиджа. Могут действительно указать на первоисточник. Я просто путем долгих экспериментов пришел к выводу, что он почти идеален. Опять же, я не презентовал свой метод именно тогда, когда пришел к нему. Это было года 4 назад. Может Front Controller моложе?
MoonGrate
04.08.2015 10:27Это ирония.
Front Controller, как минимум, описан в книге Catalog of Patterns of Enterprise Application Architecture М. Фаулера в 2003 году.
Реализован в MVC PHP фреймворках. Например — Symfony, еще в 2005 году.
Мораль — если знакомиться с лучшими практиками, можно избежать траты времени на переизобретение велосипеда. Но и бездумно применять их всегда и везде тоже не стоит, конечно, а только где они уместны.belkin-labs
04.08.2015 10:39-1шопотом (интим)Я от программирования тащусь. Моя программа — это всегда картина. Я заканчиваю ее, потом некоторое время любуюсь, потом изредка подхожу и делаю несколько дополнительных мазков. Если в процессе любования своим детищем оно мне не кажется красивым, я его переделываю полностью. Часто с нуля. В свободное время. При таком подходе я не могу (часто) использовать чужие коды. Чисто с эстетической точки зрения. Но кое-что использую. PHPmailer, например. Но я все равно его переопределяю. Учусь же я, в основном на движках, которые делаю для клиентов. На CS-CART, например. Ну и, конечно, иногда меня эстетически заносит. Но я научился себя за это прощать.
akirsanov
04.08.2015 09:31Ерунда. Выше уже всё правильно написали — борьба со следствием, а не с причиной, попытка реализовать свой security through obscurity.
Если произошла компроментация сайта через хостинг, то причин оставаться на этом хостинге больше нет, а попытки ужиться с неожиданно появившимися «соседями», велосипедя с ксором паролей, уж извините, полный п___ц.
Начинать надо с оценки рисков, и если риск простоя, инфицирования, утечки для вашего бизнеса, завязанного на сайте, существенен, то минимизируйте его — используйте VPS, VDS, коло в конце концов, и конечно нанимайте адекватных специалистов по настройке серверов, используя всю мощь политик инфобеза, без велосипедов.belkin-labs
04.08.2015 10:02-1Вы слишком категоричны, а жизнь часто преподносит сюрпризы.
akirsanov
04.08.2015 10:18Я вообще не категоричен, и по мировозрению буддист.
Однако есть методики, которые приводят к правильным решениям, и есть методики, которые приведут к неправильным. В Ваших сообщениях и используемой Вами терминологии наблюдаются огрехи, которые говорят о некоторых пробелах в инфобезе.
Вы можете неверить мне, но другие комментаторы это подтвердят.
Поэтому советую прислушаться и взять из этого треда ценные мысли, это приведет к Вашему развитию не через метод проб и ошибок, который Вы бы получили, применяя неверные методики, а через опыт других.
У вас есть два варианта — вступить в полемику с каждым, или же просто прислушаться. Выбирайте.Alexeyslav
04.08.2015 10:30Судя по всему — все решения неправильные. Ибо в конечном итоге все решения приводят к взлому сайта. Но вот лёгкость взлома, она зависит от принимаемых решений это да.
security through obscurity хороша до тех пор пока ваше решение не изучили или есть возможность более легкого взлома соседа. По крайней мере такие решения спасают от массовых автоматизированных взломов. Один из эшелонов защиты, самый простой.akirsanov
04.08.2015 10:35Если из этого не делать основной способ защиты — то да, в этом нет ничего плохого. Вот только осознать и применять это можно только с опытом, новичкам лучше брать готовые протестированные методики и решения, чем велосипедить.
CWN
04.08.2015 09:58+1Бесполезные советы.
Варианта доступа к БД ровно два, в зависимости от того, что было скомпрометировано.
1. Если Ваш код, то есть есть уязвимость на заливку и изменение файлов — то, как тут уже в комментариях отмечали, модификация существующего скрипта (там где есть обращение к БД) позволяет тупо слить всю базу. И скрытие паролей уже не поможет.
2. Если хостинг, то есть грубо говоря рут — то два варианта событий:
2.1 База на этом же сервере — тут вообще пароли доступа к БД не нужны, ко всем БД можно получить рутовый доступ без пароля.
2.2 База на другом сервере — то по первому варианту, модификация существующего скрипта.
По вопросу защиты:
1. От шаред хостинга помогает переход на Dedicated или VPS хостинг. Там все в ваших руках.
2. По минимизации рисков взлома ПО вариантов много, по вашим вопросам:
2.1 например белые списки URL можно организовать через ModSecurity
2.2 по контролю целостности кода — периодическое сканирование каталога внешним скриптом с подсчетом контрольных сумм, или например можно для этого использовать GIT, он делает тоже самое, плюс можно после каждого скана сформировать отчет с изменениями.
2.3 По хешам паролей — использовать криптостойкие алгоритмы, для php это функция password_hash.
2.4 Максимально внимательно отнестись к коду отвечающему за заливку файлов на сервер, например самому генерировать названия файлов при их сохранении, а пользовательские названия, если нужны, хранить в БД.
3. Внимательно изучить рекомендации OWASP www.owasp.org, для начала список Top-10. А потом можно пройтись по OWASP Cheat Sheet Series
rPman
А не рассматривали вариант размещать весь сайт в readonly файловой системе (тот же контейнер squashfs, там и патчи красиво подсовываются, и скорость работы с файлами поднимается)?
belkin-labs
Нет. Не пробовал. Статья в большой степени написана для тех, кто работает на публичных хостингах и не пользуется https. Возможно, это стоило бы указать особо! Именно там особенно актуальны описанные проблемы безопасности и сложности с производительностью.