Comments 89
А не рассматривали вариант размещать весь сайт в readonly файловой системе (тот же контейнер squashfs, там и патчи красиво подсовываются, и скорость работы с файлами поднимается)?
Весьма похоже на отчаянную борьбу со следствиями, а не с причинами дырок.
Вы правы! Очень точно выразились! Дело в том, что идет разговор о том, как защититься от шелла, подсаживаемого через рутированный хостинг.
Тогда получается проще можно.
Если у нас какой-нибудь типовой движок, что скорее всего в 99.999% случаев, то заместо директивы «исполняй *.php» надо сделать директиву «исполняй webroot/index.php». Т.е. запретить всё везде и разрешить только в одном месте.
Без возможностей изменения ниже через .htaccess или иные варианты.
Если у нас какой-нибудь типовой движок, что скорее всего в 99.999% случаев, то заместо директивы «исполняй *.php» надо сделать директиву «исполняй webroot/index.php». Т.е. запретить всё везде и разрешить только в одном месте.
Без возможностей изменения ниже через .htaccess или иные варианты.
Именно это я, кажется, и предлагаю. Для типовых движков все может быть сложнее. Осложняется дело SEO рерайтингом, который везде реализован по-разному. В cs-cart, например, это делается с помощью аддона. То есть конечно, любой двиг можно преобразовать для безопасности. Но это может быть очень сложно и в каждом случае надо подходить индивидуально.
Если брать любой движок, то первым делом, на мой взгляд, надо зашифровать сведенья для доступа к базе. Так потеряв на некоторое время сайт, можно хотя бы базу данных сохранить и не просить пользователей, чтобы пароли меняли.
Если брать любой движок, то первым делом, на мой взгляд, надо зашифровать сведенья для доступа к базе. Так потеряв на некоторое время сайт, можно хотя бы базу данных сохранить и не просить пользователей, чтобы пароли меняли.
К сожалению я не понял, что вы хотите сказать приведенной ссылкой.
Как бы там ни было, движки, с которыми мне приходится иметь дело, не кодируют данные для доступа к базам данных. А работать мне приходилось из известных с WP, JOOMLA, CS-CART. Из менее известных — MODX, ShopCms и несколькими другими. Причем, что удивительно, когда я клиентов пугаю перспективами этого открытого хранения, то никто не пугается! Ни один! А один клиент, имея магазин с оборотом 5 миллионов рублей в месяц, все пароли имеет одинаковые. Это имя его кошки. Предположим, «masha». Один раз я его напугал таки рассказом о том, чем это грозит и тогда в самом ответственном месте он изменил пароль на имя второй кошки, условно «dasha». После того, как я ему откровенно сказал, что я об этом думаю, он сжалился и изменил пароль на (опять же условно) «Masha,Dasha». Это меня более или менее устроило.
Скажите, вы считаете, что проблема высосана из пальца, а я «маньяк безопасности»?
Как бы там ни было, движки, с которыми мне приходится иметь дело, не кодируют данные для доступа к базам данных. А работать мне приходилось из известных с WP, JOOMLA, CS-CART. Из менее известных — MODX, ShopCms и несколькими другими. Причем, что удивительно, когда я клиентов пугаю перспективами этого открытого хранения, то никто не пугается! Ни один! А один клиент, имея магазин с оборотом 5 миллионов рублей в месяц, все пароли имеет одинаковые. Это имя его кошки. Предположим, «masha». Один раз я его напугал таки рассказом о том, чем это грозит и тогда в самом ответственном месте он изменил пароль на имя второй кошки, условно «dasha». После того, как я ему откровенно сказал, что я об этом думаю, он сжалился и изменил пароль на (опять же условно) «Masha,Dasha». Это меня более или менее устроило.
Скажите, вы считаете, что проблема высосана из пальца, а я «маньяк безопасности»?
UFO just landed and posted this here
Я совсем не о порче БД говорю. Против порчи — бэкап хороший вариант.
Я говорю о том, что конкретное физическое лицо с преступными целями рутирует хостинг. Подсадят шеллы во все папки хостинга. Утянут пароли, зайдут в базы данных, найдут таблицу tralala_users и скопируют ее к себе на диск. В этой таблице скорее всего есть столбик с хэшами. Эти хэши вынут из столбика и загрузят на вход такому современному зверю с 200-ми или 500-ми процессорами, который работает круглосуточно и только и умеет делать — так это считать хэши.
После прохождения некотого времени какая-то часть паролей (подозреваю, большая часть) окажется расшифрованной. Эти расшифрованные пароли загрузят в другую базу данных и «скормят» серверу, который будет заходить на определенные сайты и опять же в круглосуточном режиме будет пытаться логиниться. Например, скайп, или в Яндекс деньги (там сейчас SMS-ки сделали в виде подтверждения), или еще куда-нибудь. И куда-то они залогинятся! И у какого-то количества пользователей на счету будут деньги, которые пропадут!
Именно поэтому, если у вас бизнес связан с деньгами и вы учитываете их на счетах пользователей, то секундное присутствие шелла уже грозит вам следствием (не была ли утянута база) и потом просьбой ко всем пользователям заменить свои пароли. Это может плохо отразиться на вашем бизнесе.
Очевидно, если вы работаете на известном движке, то задача такому мошеннику, который пароли собирает, облегчается до нельзя, поскольку точно известно, где брать, что брать и даже для каждого движка есть уже готовые скрипты, которые за 1 секунду все сделают.
В этой статье я хотел усложнить задачу мошенникам. Заставить их либо уйти сразу с сайта, поскольку на нем разбираться надо, как все устроено, либо хотя бы замедлить его работу. Тогда можно успеть зайти и заблокировать его IP.
Извините, что слишком подробно все описал. Надеюсь читать было нескучно.
Я говорю о том, что конкретное физическое лицо с преступными целями рутирует хостинг. Подсадят шеллы во все папки хостинга. Утянут пароли, зайдут в базы данных, найдут таблицу tralala_users и скопируют ее к себе на диск. В этой таблице скорее всего есть столбик с хэшами. Эти хэши вынут из столбика и загрузят на вход такому современному зверю с 200-ми или 500-ми процессорами, который работает круглосуточно и только и умеет делать — так это считать хэши.
После прохождения некотого времени какая-то часть паролей (подозреваю, большая часть) окажется расшифрованной. Эти расшифрованные пароли загрузят в другую базу данных и «скормят» серверу, который будет заходить на определенные сайты и опять же в круглосуточном режиме будет пытаться логиниться. Например, скайп, или в Яндекс деньги (там сейчас SMS-ки сделали в виде подтверждения), или еще куда-нибудь. И куда-то они залогинятся! И у какого-то количества пользователей на счету будут деньги, которые пропадут!
Именно поэтому, если у вас бизнес связан с деньгами и вы учитываете их на счетах пользователей, то секундное присутствие шелла уже грозит вам следствием (не была ли утянута база) и потом просьбой ко всем пользователям заменить свои пароли. Это может плохо отразиться на вашем бизнесе.
Очевидно, если вы работаете на известном движке, то задача такому мошеннику, который пароли собирает, облегчается до нельзя, поскольку точно известно, где брать, что брать и даже для каждого движка есть уже готовые скрипты, которые за 1 секунду все сделают.
В этой статье я хотел усложнить задачу мошенникам. Заставить их либо уйти сразу с сайта, поскольку на нем разбираться надо, как все устроено, либо хотя бы замедлить его работу. Тогда можно успеть зайти и заблокировать его IP.
Извините, что слишком подробно все описал. Надеюсь читать было нескучно.
А я бы не убирал стандартные файлы. Просто оставил бы их нефункциональными, или с безобидным содержимым — фейковые пароли и т.д. Если кто попытается влезть куда-то с фейковым логином/паролем — сразу блокировать IP до выяснения обстоятельств. Так же под немедленное подозрение тех кто обращается к стандартным файлам.
Пусть взломщик думает что он что-то получил. Очень сложно ориентироваться в комнате полной зеркал.
Пусть взломщик думает что он что-то получил. Очень сложно ориентироваться в комнате полной зеркал.
UFO just landed and posted this here
Никак нет. В любом движке есть конфиг. В том же WP это wp-config.php.
В нём вам рекомендуется делать заместо:
Как попадают в ENV значения DB_PASSWORD уже дело десятое. Напр. их можно прохардкодить в конфигах php-fpm'а, которые только руту для чтения доступны, а уже сайты запускаются под www-blabla, который даже хоть всё поламает — не прочитает тот конфиг через шельные вызовы.
Вот только он точно также сможет прочитать $_ENV['DB_PASSWORD'], если будет использоваться маска "*.php" для запуска.
Ps: Вариант хорош, когда у вас есть доступ к способу запуска php под разными правами. Для стандартных shared серверов под cPanel'ями не подходит.
В нём вам рекомендуется делать заместо:
// 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'ями не подходит.
Понял. Вариант близок к тому, что я предлагаю. Не уверен, правда, что можно хоть что-то прохардкодить на публичном хостинге от имени рута. Если только админов попросить? Но у админов есть супер-отговорка: «Мы такого не делаем. Извините за беспокойство».
Вот только он точно также сможет прочитать $_ENV['DB_PASSWORD'], если будет использоваться маска "*.php" для запуска.
Это ключевая фраза. Повторюсь, если получен прямой доступ на ftp — обсуждать далее нечего.
Ну окей, в таком случае зашифрованный пароль и алгоритм шифрования находятся все зоны доступа, но теперь банальный вызов phpinfo() покажет всем желающим пароль от БД. Некоторые движки/фреймворки любят показывать вместе со стек трейсами содержимое глобальных массивов, включая _ENV. Была уязвимость раскрытия информации, а стала уязвимость раскрытия реквизитов доступа. По-моему хуже стало :)
Для того, чтобы вызвать php-info() надо сделать скрипт с этим вызовом.
- Если будет скрипт — он не вызовется
- Для вставки кода в существующий скрипт, надо зайти на ftp, и это сложно. надо знать пароль. Иначе надо знать, как скрипт называется и переходим к пункту 1
- Если будет утащен весь сайт, то опять нужно либо по ftp заходить, либо см. первый пункт. И в любом случае придется очень долго разбираться в алгоритмах шифрования
- Про ENV — это не моя идея, а создателей WP. Я за свой метод стою.
В данном случае я именно про использование _ENV в качестве хранилища для чувствительной информации. А вот phpinfo довольно часто приходится видеть на сайтах лежащим в корне под разными именами, а в некоторых движках это даже встроенная фитча, и иногда она даже открыта для всех желающих, а не только для администраторов.
Так же в некоторых случаях зачем то оставляют скрипты для проверки совместимости движка и хостинга, среди функций которых можно найти проверку подключения к БД, которая так же позволяет ввести произвольный адрес mysql сервера, имя пользователя и пароль. При удачном стечении обстоятельств злоумышленник с использованием этого скрипта и фишки «LOAD DATA LOCAL» может прочитать и конфиг с зашифрованным паролем и алгоритм для его декодирования. И без доступа к FTP :)
Так же в некоторых случаях зачем то оставляют скрипты для проверки совместимости движка и хостинга, среди функций которых можно найти проверку подключения к БД, которая так же позволяет ввести произвольный адрес mysql сервера, имя пользователя и пароль. При удачном стечении обстоятельств злоумышленник с использованием этого скрипта и фишки «LOAD DATA LOCAL» может прочитать и конфиг с зашифрованным паролем и алгоритм для его декодирования. И без доступа к FTP :)
Согласен!
Может быть случаи, которые вы приводите — это безалаберность админов? В доках, вроде не советуют такие вещи делать, а доки читаются первыми (хабр за доками идет).
Но хочу еще добавить, что и хостинги содержат много настроек безопасности, о которых узнаешь только когда с ними сталкиваешься. Вот, например, с какого-то момента хостом баз данных стал повально использоваться localhost, и достучаться до базы данных стало возможно только локально, то есть с родного сайта. То есть, заметьте как интересно, все опять упирается в левый скрипт в корневой папке. Я, возможно, скажу крамолу, но есть ощущение, что после повсеместного внедрения урл-рерайтинга, подсадка шелла осталась единственным реальным методом «хорошо взломать». Ну или откровенные поделки, которые действительно, кроме любителей и не нужны никому.
Может быть случаи, которые вы приводите — это безалаберность админов? В доках, вроде не советуют такие вещи делать, а доки читаются первыми (хабр за доками идет).
Но хочу еще добавить, что и хостинги содержат много настроек безопасности, о которых узнаешь только когда с ними сталкиваешься. Вот, например, с какого-то момента хостом баз данных стал повально использоваться localhost, и достучаться до базы данных стало возможно только локально, то есть с родного сайта. То есть, заметьте как интересно, все опять упирается в левый скрипт в корневой папке. Я, возможно, скажу крамолу, но есть ощущение, что после повсеместного внедрения урл-рерайтинга, подсадка шелла осталась единственным реальным методом «хорошо взломать». Ну или откровенные поделки, которые действительно, кроме любителей и не нужны никому.
<?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'ок это не вариант в любом случае.
Во-вторых, все, что идет за словом «Result:» не декодируется. Я не могу определить кодировку и это точно не utf8.
Нормально декодируется и там windows-1251: «Result: не нашлось формы для размещения; Result: не нашлось формы для размещени_cutted»
Либо это мой позорный пролет, либо я неудачный пример подобрал.
Да! Пролет! Я, оказывается, пользовался плохим онлайн-декодировщиком. Сейчас поискал другой и да! Вы абсолютно правы! Сейчас я перефразирую этот абзац.
Похоже что этот запрос от XRumer. Берется строка из результатов его выдачи и копируется в адресную строку как есть вместе с этим текстом.
А декодировал я с помощью PHP urldecode.
А декодировал я с помощью PHP urldecode.
Крайне рекомендую на всех своих сайтах зашифровать данные для доступа к базе данных и разместить их в совершенно нестандартно названном файле, закрытом от доступа по сети и доступного только для чтения.
Ужасно неудобно, непродуктивно и я не припомню подобного в популярных фреймворках
CMS — зло. Если проект более-менее крупный и ему начинает быть нужна продвинутая безопасность, то стоит обратить внимание на фреймворки.
С точкой входа — все ок. Она должна быть одна (если нет API или чего другого).
Насчёт безопасности конфигов — весь бекенд обычно выносят за пределы корня веб-сервера. Выставляются корректные права. Не забудьте так же обезопасить скрытые директории (от git к примеру, или IDE). Это сделает невозможным добраться до исходников с веба. Если косячит хостинг — убегайте от них!
С точкой входа — все ок. Она должна быть одна (если нет API или чего другого).
Насчёт безопасности конфигов — весь бекенд обычно выносят за пределы корня веб-сервера. Выставляются корректные права. Не забудьте так же обезопасить скрытые директории (от git к примеру, или IDE). Это сделает невозможным добраться до исходников с веба. Если косячит хостинг — убегайте от них!
Спасибо! Согласен на 100%!
Хотел добавить. Только вчера я просматривал результаты очередной атаки на свой сайт. Знаете что хотели утянуть?
/index.zip
/files.zip
/htdocs.zip
/file.zip
/www.zip
/belkin-labs.zip
Как я и говорил, система логирования и сбора плохих ури дает развеселые результаты!
Будьте осторожны! Некоторые мои регулярно клиенты держат подобные зипы в корневых папках. Причем именно те, кто сидит на выделенных серверах и кому места на этих серверах девать реально некуда!
Хотел добавить. Только вчера я просматривал результаты очередной атаки на свой сайт. Знаете что хотели утянуть?
/index.zip
/files.zip
/htdocs.zip
/file.zip
/www.zip
/belkin-labs.zip
Как я и говорил, система логирования и сбора плохих ури дает развеселые результаты!
Будьте осторожны! Некоторые мои регулярно клиенты держат подобные зипы в корневых папках. Причем именно те, кто сидит на выделенных серверах и кому места на этих серверах девать реально некуда!
К вашему списку потенциально опасных URL предлагаю добавить коллекцию товарища Bo0oM, которую он презентовал на одной из конференций по ИБ: bo0om.ru/fuzz.txt
Как вариант, подсовывать в таком случае мусор. бесконечный файл с random. Пусть боты удавятся(если трафика исходящего не жалко)
На публичном хостинге у нас есть соседи по серверу. Так что вообще трафика очень жалко!
Ну ладно, тогда мусор покилобайтно. А если совсем-совсем жалко, то просто не отвечать.
У меня есть некоторые случаи, когда я вообще посылаю очень далеко. Пишу «Большое спасибо» и все. Без объяснений
Ботам ваш ответ даёт сигнал о том что сайт жив и его надо дожимать. Проще всего ботов игнорировать, пусть стоят в ожидании ответа до таймаута. Потыкаются потыкаются, посчитают сайт мёртвым и уйдут.
Вы знаете, я тут использую очень спорный прием. Заходы ботов и подозрительных IP на мой сайт я использую практически. На каждый такой заход у меня стоит полезная нагрузка. Проверка порции папок на новые файлы, отсылка уведомлений пользователям о комментариях на сайте и так далее. Я не использую никаких кронов. Поскольку заходов довольно много (200-300 в день), то все сервисные дела ими покрываются. А то, что львиная часть происходит ночью — даже хорошо. Своеобразный естественный крон получается.
Но зачем?
Как альтернатива крону (cron — демон-планировщик задач в юникс-подобных системах). В настоящее время получается так, что когда спам-робот заходит, антиспам-система определяет его, и перед тем, как он получит ответ, на сайте выполняются некие сервисные действия из очереди этих действий. Например, проверяется целостность файловой системы, отправляются уведомления пользователям о появлении новых коментариев к статьям. Таким образом, робот вынужден какое-то очень малое время ждать. Мне этот факт греет душу.
отправляются уведомления пользователям о появлении новых коментариев к статьям
А если вдруг боты перестанут заходить — пользователи никогда не получат уведомлений? Зачем изобретать велосипед, тем более, что крон разрешен на подавляющем большинстве шаред-хостингов.
т.е. в случае DOS атаки, Ваш сервер будет залипать по черному — отлично!
В случае такой атаки любой сервер будет залипать ))
Ну да, только вот степень залипания будет разной :)
Ну и согласитесь, что чем быстрее сервак избавляется от бота — тем меньше он залипает.
DOS разный бывает, бывает кроме него просто флуд.
а к Автору:
А если честно все это — даже не велосипед, это костылестроение.
В случае определения что зашел бот — нужно как можно более быстро и с минимальным количеством ресурсов избавиться от него, а не пытаться использовать. Иначе сервак захлебнется при флуде или досе.
Обычно сообщается IP антифлудеру вместе с датой (чтобы обновить / продлить бан ) и выходится, усе — в следующий раз оно не пройдет. Просто при бане по IP (если он есть) есть риск забанить прокси, через которую сидят кроме бота и невинные пользователи, по этому бан обычно по времени или есть возможность выхода из него при нормальной активности.
Иногда можно репортить IP/хэш от всего, к чему можно привязаться у пользователя (UserAgent, система и т.д.) — это помогает делать бан более избирательным и гибким.
Мой Вам совет разобраться во всем этом, прежде чем «картины писать». Ибо у Вас велосипедостроение + непонимание как что работает и как нужно = костылестроение (ибо свой велосипед далеко не всегда плохо, а вот велосипед без понимания — это костылище).
И не в обиду Вам будет сказано — я бы гнал таких вот любителей натюрмортов из команды поганой метлой.
Ну и согласитесь, что чем быстрее сервак избавляется от бота — тем меньше он залипает.
DOS разный бывает, бывает кроме него просто флуд.
а к Автору:
А если честно все это — даже не велосипед, это костылестроение.
В случае определения что зашел бот — нужно как можно более быстро и с минимальным количеством ресурсов избавиться от него, а не пытаться использовать. Иначе сервак захлебнется при флуде или досе.
Обычно сообщается IP антифлудеру вместе с датой (чтобы обновить / продлить бан ) и выходится, усе — в следующий раз оно не пройдет. Просто при бане по IP (если он есть) есть риск забанить прокси, через которую сидят кроме бота и невинные пользователи, по этому бан обычно по времени или есть возможность выхода из него при нормальной активности.
Иногда можно репортить IP/хэш от всего, к чему можно привязаться у пользователя (UserAgent, система и т.д.) — это помогает делать бан более избирательным и гибким.
Мой Вам совет разобраться во всем этом, прежде чем «картины писать». Ибо у Вас велосипедостроение + непонимание как что работает и как нужно = костылестроение (ибо свой велосипед далеко не всегда плохо, а вот велосипед без понимания — это костылище).
И не в обиду Вам будет сказано — я бы гнал таких вот любителей натюрмортов из команды поганой метлой.
Вообще, трафика жалко. Тем более на ботов.
Вот это то, чего я никак не могу понять. Есть файл, который все знают, как называется, и в котором в открытом виде лежит именно то, что нужно хакеру. Зачем это делается? Это, на мой взгляд, вредительство какое-то.
Просто так файл config.php прочитать не получится, веб сервер же не отдаёт его в открытом виде. Ну а если злоумышленник нашёл уязвимость типа чтение произвольных файлов, то зачем ему угадывать имя конфига, если почти наверняка точка входа index.php (или иная, описанная в .htaccess), и одной из первых строк будет инклуд файла с конфигом?
Крайне рекомендую на всех своих сайтах зашифровать данные для доступа к базе данных и разместить их в совершенно нестандартно названном файле, закрытом от доступа по сети и доступного только для чтения.
Это как? Покажите пример, а то не совсем понятно что вы предлагаете. Если вы делаете вызов mysql_connect(..., decrypt($crypted_password), ...), то что мешает злоумышленнику сделать вызов print(decrypt($crypted_password))? Алгоритм шифрования лежит рядом, шифрование обратимое, не знаю над чем можно зависнуть на пару часов в данном случае.
В целом, когда вы используете shared хостинг, то заведомо не можете защитить себя от взлома хостера. Ведь ничего не мешает злоумышленнику добавить к вашему .htaccess строчку со своим «php_value auto_prepend_file». Такой вариант рассматривали?
Просто так файл config.php прочитать не получится, веб сервер же не отдаёт его в открытом виде. Ну а если злоумышленник нашёл уязвимость типа чтение произвольных файлов, то зачем ему угадывать имя конфига, если почти наверняка точка входа index.php (или иная, описанная в .htaccess), и одной из первых строк будет инклуд файла с конфигом?
Проблема именно в том, что у вас на хостинге оказывается чужой скрипт. Прямо в корневой папке. И этот скрипт работает у вас на сайте от имени владельца, что есть делает все, что угодно! И бывает так, что это не ваша вина, не уязвимость сайта или кода. Советую ознакомиться со статьей по второй ссылке из подвала (детективная история). Там все описано в красках.
На счет примера я, возможно, сделаю отдельную статью, если у уважаемого сообщества возникнет интерес к теме.
Если злоумышленник порутал машину хостера и может творить на ней что ему вздумается, то в какой то момент он догадается, что auto_prepend_file можно сделать глобально в настройках веб сервера, поэтому ему совершенно не обязательно палиться на изменении файлов вашего и других сайтов. Кстати, при желании, php шелл можно оформить в виде одного .htaccess файла. Историю прочитал.
В целом, когда вы используете shared хостинг, то заведомо не можете защитить себя от взлома хостера. Ведь ничего не мешает злоумышленнику добавить к вашему .htaccess строчку со своим «php_value auto_prepend_file». Такой вариант рассматривали?
Я продолжаю работать и совершенствовать свои подходы. Для того, чтобы уберечь .htaccess от прямого редактирования, нужно, на мой взгляд, использовать стандартные средства защиты ftp.
- Заходить только по SFTP
- Не хранить пароли в клиенте
- Не разрабатывать сайты на Windows
- Менять пароли к FTP по регламенту
Выставить права только на чтение при заливке по фтп это конечно хорошее решение от модификации файлов со стороны самого веб-приложения, но ведь в вашем случае был взлом хостера. И наверное логично было бы предположить, что раз хостер не позаботился о безопасности одного своего сервера, то с другими серверами тоже может приключиться подобная беда, не исключая сервер админки хостинга и биллинга. Ну а когда ему удалось слить пароли пользователей (они ведь в открытом виде хранятся), то частота смена паролей и используемая ОС на безопасность сайта не повлияет.
Согласен!
Но мне кажется, что не нужно успокаивать себя тем, что если кому-то надо вас взломать — вас взломают. Надо все равно попытаться злоумышленнику помешать. Мы все знаем, что умрем когда-нибудь. Но ведь живем зачем-то… сайты делаем… и все такое…
Кстати, я не предлагал бороться с проблемой выставлением жестких прав. Я всегда думал, что это так или иначе надо делать. Есть много чего в документациях на эту тему. Я эту тему просто не рассматривал.
Но мне кажется, что не нужно успокаивать себя тем, что если кому-то надо вас взломать — вас взломают. Надо все равно попытаться злоумышленнику помешать. Мы все знаем, что умрем когда-нибудь. Но ведь живем зачем-то… сайты делаем… и все такое…
Кстати, я не предлагал бороться с проблемой выставлением жестких прав. Я всегда думал, что это так или иначе надо делать. Есть много чего в документациях на эту тему. Я эту тему просто не рассматривал.
Это как? Покажите пример, а то не совсем понятно что вы предлагаете. Если вы делаете вызов mysql_connect(..., decrypt($crypted_password), ...), то что мешает злоумышленнику сделать вызов print(decrypt($crypted_password))? Алгоритм шифрования лежит рядом, шифрование обратимое, не знаю над чем можно зависнуть на пару часов в данном случае.
Схема следующая.
Есть файл php в котором лежит заранее зашифрованные сведенья. Это строка бинарная, поэтому я ее кодирую base64. Строка зашифрованных сведений оформлена в качестве константы.
Первый же скрипт, которому нужна база расшифровывает эту строку. Ключ лежит в секретном месте. Сам ключ перед использованием меняется. К нему добавляются так называемые отпечатки пальцев (секретные). Добавили отпечатки, взяли md5 какое-то количество раз и вот то, что получилось используем в виде ключа. Для шифрования XOR-ом хорошо бы иметь ключ такой-же длины как и данные. Ну мы не лыком шиты и придумываем что-нибудь, чтобы получить ключ нужной длины. Смысл в том, что нельзя взять просто ключ, который лежит, но который надо найти. Его еще трансформировать надо правильно.
Данные расшифровываются и кладутся в глобальную сферу. Ну и все другие методы, которые лезут в базу данных, используют сведенья из глобалов.
Вот вкраце так.
Да! Поскольку зашифровать вручную практически невозможно (слишком трудно) у меня есть локальный скрипт, который делает это быстро и надежно.
Первый же скрипт, которому нужна база расшифровывает эту строку.
Что мешает злоумышленнику увидеть расшифрованное? Либо сразу, либо так —
Ну и все другие методы, которые лезут в базу данных, используют сведенья из глобалов.
А как он увидит? Я не понял. Поясните, пожалуйста.
print(), echo — есть варианты, разве нет? В чем проблема вывести какие-то данные в браузер, в файл? Выше уже ведь написали.
Среди «других методов» может оказаться добавленный злоумышленником в .htaccess (или конфиг веб сервера) скрипт вида «if(isset($_COOKIE['iamhacker']))phpinfo();» с использованием auto_append_file. Можно конечно затирать глобалсы перед завершения выполнения веб-приложения, но всё равно, если скрипт умеет декодировать пароль, а злоумышленник видит скрипт, то трудно будет ему усложнить задачу расшифровки пароля.
Вот именно. Мне вообще непонятен предмет обсуждения. belkin-labs, если злоумышленник получил доступ к вашим файлам — то все, обсуждение можно закрывать, защищаться в таком случае можно только святым духом — и то, вряд ли поможет :)
Если злоумышленник зайдет на мой сайт по фтп, скачает весь сайт, то ему потребуется довольно много времени, чтобы получить сведенья по доступу к базе данных. Я успею заменить все пароли к тому времени.
Если он зайдет от моего имени в мою админку на хостинге, тогда да. все пропало и можно уже ничего не обсуждать.
Если он зайдет от моего имени в мою админку на хостинге, тогда да. все пропало и можно уже ничего не обсуждать.
Возможно, я что-то пропустил, но каким образом вы на шаред-хостинге будете отслеживать активность ftp? Сидеть в cpanel и обновлять страничку ежеминутно-секундно?
Нет. Я выше предлагал средства для затруднения злоумышленникам доступа на ftp. К сожалению, только это. Больше никаких методов я не знаю.
После взлома у хакеров будет доступ ко всем вашим скриптам, скопипейстить этот код труда не составит.
Я надеюсь, что достаточно затруднил ему взлом, чтобы успеть заблокировать его раньше
Вообще на моей памяти базами интересовались крайне редко.
В основном ломают ради черного сео либо ради продажи трафика под трояны.
В основном ломают ради черного сео либо ради продажи трафика под трояны.
Чем, интересно, доступ затруднен? И, например, если произошел наихудший случай, и взломщик имеет рутовый доступ к серверу хостера — ваши блокировки, увы, не помогут.
Я не очень хорошо себе представляю, как вскрываются хостинги. Все мои сведенья почерпнуты из интернетов. Я же не могу спрашивать у админов хостинга о том, как их вскрыли? Правда? С вероятностью 100% я буду послан.
Если в итоге взлома у меня в файловой структуре появляется посторонний файл, я узнаю об этом в течение 10 минут. Если будет попытка запуска подозрительного скрипта, он не запустится, а я узнаю об этом еще быстрее.
Если злоумышленник укачает мой сайт, он очень долго не сможет расшифровать данные по доступу к базе. Я успею их поменять.
Так что я не совсем затрудняю доступ. Скорее я увеличиваю шанс того, что я вовремя его поймаю за хвост.
Если в итоге взлома у меня в файловой структуре появляется посторонний файл, я узнаю об этом в течение 10 минут. Если будет попытка запуска подозрительного скрипта, он не запустится, а я узнаю об этом еще быстрее.
Если злоумышленник укачает мой сайт, он очень долго не сможет расшифровать данные по доступу к базе. Я успею их поменять.
Так что я не совсем затрудняю доступ. Скорее я увеличиваю шанс того, что я вовремя его поймаю за хвост.
Если в итоге взлома у меня в файловой структуре появляется посторонний файл
Лично я вижу два пути появления такого файла:
- Плохой хостер (плохо настроенный сервер, плохо настроенные права и т.п.) — и очевидно, от такого хостера надо бежать.
- Плохой код, позволяющий злоумышленнику загрузить файл на сервер. Решение в данной ситуации тоже очевидно.
Если в итоге взлома у меня в файловой структуре появляется посторонний файл, я узнаю об этом в течение 10 минут. Если будет попытка запуска подозрительного скрипта, он не запустится, а я узнаю об этом еще быстрее.
А если будет изменен существующий скрипт? Тот же index.php?
Обсуждение как-то само свелось к обсуждению пункта 1. Бежать от хостера просто, если вы не участвовали в партнерке и не накопили в ней кучу бабла. И еще если вы уверены, чтоследующий хостер будет на много лучше.
Для того, чтобы изменить существующий скрипт, надо знать его имя. Перечитайте статью, у меня нет index.php.
Для того, чтобы изменить существующий скрипт, надо знать его имя. Перечитайте статью, у меня нет index.php.
Перечитайте статью, у меня нет index.php.
Какое это имеет значение, если мы попали на ftp? )))
Бежать от хостера просто, если вы не участвовали в партнерке и не накопили в ней кучу бабла.
Тут ничего сказать не могу — не в курсе, что за партнерка, но, вероятно, не обязательно продолжать покупать хостинг для участия в партнерке и продолжения заработка?
И еще если вы уверены, чтоследующий хостер будет на много лучше.
Лично мне видится такая ситуация:
Все зависит от важности, так скажем, сайта. Персональную страничку Иванова Васи, обновлявшуюся в последний раз более пяти лет назад, тоже могут взломать. Но скорее всего, взлому подвержены более интересные проекты, более посещаемые, хотя бы. Серъезный проект, как уже говорилось выше, располагать на шареде глупо. Разумеется, и на впс, к примеру, есть свои проблемы с безопасностью, как и везде, но это уже тема совершенно другого разговора. Сорри за ИМХО.
Ваша позиция ясна. Я очень со многими ее положениями не могу согласиться. Углубляться в обсуждение не хочу, ибо они не программистского плана.
Моя позиция такова, что ваш пост не предполагает никаких решений, ибо ищутся эти решения не под реальные возможные проблемы, а под то, что вы себе сами придумали. При этом, даже банальный вход по ftp все ваши решения сводит к бессмысленной трате времени — толку от них в такой ситуации — ноль.
Как по мне, глупо искать решение тех проблем, которые вы не можете решить (например, безопасность шаред-сервера) и при этом игнорировать простые действия (как то переезд на впс), при которых потребность в ваших решениях отпадет сама собой.
Как по мне, глупо искать решение тех проблем, которые вы не можете решить (например, безопасность шаред-сервера) и при этом игнорировать простые действия (как то переезд на впс), при которых потребность в ваших решениях отпадет сама собой.
Вы предлагаете ерунду, уж простите.
Если я каким-либо образом залил скрипт к вам на сайт и смог выполнить его — я смогу вытащить весь сайт, включая все переменные окружения, а потом уж разобраться, как вытащить пароль для БД — дело 5 минут. Мало того — я даже разбираться не буду — найду, где выполняется SQL и засуну туда дамп. Причем, для запуска скрипта вообще не надо создавать какие-то доп. файлы — можно исполнить «на лету», либо модифицировать существующее.
Если я смог скомпромитировать хостера, или как-то по другим образом получил доступ до FTP — все получается тоже самое, за исключением переменных среды.
Переименовывать файлы, криптовать пароль БД в случае получения доступа к исполнению или FTP — совершенно бесполезно и господин grayfolk абсолютно прав.
Все это называется security through obscurity и у хаккера вызывает лишь улыбку, при получении контроля FS или исполнения.
Если я каким-либо образом залил скрипт к вам на сайт и смог выполнить его — я смогу вытащить весь сайт, включая все переменные окружения, а потом уж разобраться, как вытащить пароль для БД — дело 5 минут. Мало того — я даже разбираться не буду — найду, где выполняется SQL и засуну туда дамп. Причем, для запуска скрипта вообще не надо создавать какие-то доп. файлы — можно исполнить «на лету», либо модифицировать существующее.
Если я смог скомпромитировать хостера, или как-то по другим образом получил доступ до FTP — все получается тоже самое, за исключением переменных среды.
Переименовывать файлы, криптовать пароль БД в случае получения доступа к исполнению или FTP — совершенно бесполезно и господин grayfolk абсолютно прав.
Все это называется security through obscurity и у хаккера вызывает лишь улыбку, при получении контроля FS или исполнения.
Крайне рекомендую на всех своих сайтах зашифровать данные для доступа к базе данных и разместить их в совершенно нестандартно названном файле...
А ключ для расшифровки ведь тоже где-то надо хранить. И варианта тут два — либо в каком-то аналогичном файле, либо прямо в коде. Для тиражируемых решений второй вариант однозначно не годится. Значит, кроме файла config.php будет, условно говоря, еще и key.php. И если хакер может прочитать config.php, то что мешает ему прочитать key.php?
При этом надо учесть, что раз нет возможности писать пароли непосредственно в config.php (ведь туда пишется уже зашифрованное значение), то должен быть некий интерфейс для ввода пароля, чтоб движок его зашифровал и туда записал.
Назвать конфиг-файл как-нибудь нестандартно и положить по нестандартному пути мало что даст, если речь о типовом известном движке, т.к. хорошо известно, где этот файл должен подключаться. А это значит, что если уж хакер получил доступ к коду, он без труда узнает «секретные» имена и пути.
В общем, сдается мне, что предложенный вариант создаст больше проблем для разработчика и админа сайта, нежели для злоумышленника.
На то чтобы разобраться где лежит пароль и вытянуть его нужно будет время. Особенно если реальный пароль при наличии фейковых конфигурационных данных будет зашит в одном из неприметных модулей которые еще ко всему будут обфусцированы и для пущего счастья расшифровывать сохраненный пароль по ключу находящемуся на соседнем хостинге и при работе сайта хранящемся в RAM.
А если подключение к БД еще и подписать… то пароль ничего не даст. При обнаружении взлома меняются ключи и вся имеющаяся у взломщика информация не позволит получить доступ к БД.
Главный критерий — чтобы взломщик не мог получить реальные реквизиты доступа к БД раньше чем будет обнаружено вторжение.
Кстати, фейковые реквизиты вполне могут работать но ссылаться на фейковую базу данных. И пока он будет выкачивать подставную базу(сам факт обращения к базе должен служить сигналом!), можно предпринять нужные действия.
А если подключение к БД еще и подписать… то пароль ничего не даст. При обнаружении взлома меняются ключи и вся имеющаяся у взломщика информация не позволит получить доступ к БД.
Главный критерий — чтобы взломщик не мог получить реальные реквизиты доступа к БД раньше чем будет обнаружено вторжение.
Кстати, фейковые реквизиты вполне могут работать но ссылаться на фейковую базу данных. И пока он будет выкачивать подставную базу(сам факт обращения к базе должен служить сигналом!), можно предпринять нужные действия.
Описанные Вами приемы — это все подразумевает, что сайт либо на фреймворке создается (либо вообще самописный), либо на CMS, очень основательно подработанной напильником. В любом случае — это некий уникальный (а не тиражируемый) проект, и разработчик имеет достаточную квалификацию и постоянно обслуживает сайт. Но в таком случае, как правило, и сисадмин проекта — не студент первого курса, и большинство описанных в статье потенциальных «дыр» — это для него банальности. Поэтому все эти приемы с прятанием паролей — это, скорее, дополнительная подстраховка к мерам, которые предприняты на системном уровне.
А тут, как мне кажется, статья рассчитана, главным образом, на тех, кто создает сайты, используя готовые тиражируемые решения, и для таких случаев описываемые Вами меры мало применимы.
А тут, как мне кажется, статья рассчитана, главным образом, на тех, кто создает сайты, используя готовые тиражируемые решения, и для таких случаев описываемые Вами меры мало применимы.
UFO just landed and posted this here
Этот скрипт по REQUEST_URI разбирается, что же это пришло, делает всякие seo-действия по рерайтингу и решает, на какой скрипт передавать управление.
Вы изобрели паттерн Front Controller, и он реализован во всех приличных современных PHP фреймворках.
Я думаю все хорошее уже изобретено в нашей сфере. Только очень глубоко закопано. Я бы никогда не взял на себя смелость заявлять, что что-то изобрел. Это слишком опасно для имиджа. Могут действительно указать на первоисточник. Я просто путем долгих экспериментов пришел к выводу, что он почти идеален. Опять же, я не презентовал свой метод именно тогда, когда пришел к нему. Это было года 4 назад. Может Front Controller моложе?
Это ирония.
Front Controller, как минимум, описан в книге Catalog of Patterns of Enterprise Application Architecture М. Фаулера в 2003 году.
Реализован в MVC PHP фреймворках. Например — Symfony, еще в 2005 году.
Мораль — если знакомиться с лучшими практиками, можно избежать траты времени на переизобретение велосипеда. Но и бездумно применять их всегда и везде тоже не стоит, конечно, а только где они уместны.
Front Controller, как минимум, описан в книге Catalog of Patterns of Enterprise Application Architecture М. Фаулера в 2003 году.
Реализован в MVC PHP фреймворках. Например — Symfony, еще в 2005 году.
Мораль — если знакомиться с лучшими практиками, можно избежать траты времени на переизобретение велосипеда. Но и бездумно применять их всегда и везде тоже не стоит, конечно, а только где они уместны.
шопотом (интим)
Я от программирования тащусь. Моя программа — это всегда картина. Я заканчиваю ее, потом некоторое время любуюсь, потом изредка подхожу и делаю несколько дополнительных мазков. Если в процессе любования своим детищем оно мне не кажется красивым, я его переделываю полностью. Часто с нуля. В свободное время. При таком подходе я не могу (часто) использовать чужие коды. Чисто с эстетической точки зрения. Но кое-что использую. PHPmailer, например. Но я все равно его переопределяю. Учусь же я, в основном на движках, которые делаю для клиентов. На CS-CART, например. Ну и, конечно, иногда меня эстетически заносит. Но я научился себя за это прощать.
Ерунда. Выше уже всё правильно написали — борьба со следствием, а не с причиной, попытка реализовать свой security through obscurity.
Если произошла компроментация сайта через хостинг, то причин оставаться на этом хостинге больше нет, а попытки ужиться с неожиданно появившимися «соседями», велосипедя с ксором паролей, уж извините, полный п___ц.
Начинать надо с оценки рисков, и если риск простоя, инфицирования, утечки для вашего бизнеса, завязанного на сайте, существенен, то минимизируйте его — используйте VPS, VDS, коло в конце концов, и конечно нанимайте адекватных специалистов по настройке серверов, используя всю мощь политик инфобеза, без велосипедов.
Если произошла компроментация сайта через хостинг, то причин оставаться на этом хостинге больше нет, а попытки ужиться с неожиданно появившимися «соседями», велосипедя с ксором паролей, уж извините, полный п___ц.
Начинать надо с оценки рисков, и если риск простоя, инфицирования, утечки для вашего бизнеса, завязанного на сайте, существенен, то минимизируйте его — используйте VPS, VDS, коло в конце концов, и конечно нанимайте адекватных специалистов по настройке серверов, используя всю мощь политик инфобеза, без велосипедов.
Вы слишком категоричны, а жизнь часто преподносит сюрпризы.
Я вообще не категоричен, и по мировозрению буддист.
Однако есть методики, которые приводят к правильным решениям, и есть методики, которые приведут к неправильным. В Ваших сообщениях и используемой Вами терминологии наблюдаются огрехи, которые говорят о некоторых пробелах в инфобезе.
Вы можете неверить мне, но другие комментаторы это подтвердят.
Поэтому советую прислушаться и взять из этого треда ценные мысли, это приведет к Вашему развитию не через метод проб и ошибок, который Вы бы получили, применяя неверные методики, а через опыт других.
У вас есть два варианта — вступить в полемику с каждым, или же просто прислушаться. Выбирайте.
Однако есть методики, которые приводят к правильным решениям, и есть методики, которые приведут к неправильным. В Ваших сообщениях и используемой Вами терминологии наблюдаются огрехи, которые говорят о некоторых пробелах в инфобезе.
Вы можете неверить мне, но другие комментаторы это подтвердят.
Поэтому советую прислушаться и взять из этого треда ценные мысли, это приведет к Вашему развитию не через метод проб и ошибок, который Вы бы получили, применяя неверные методики, а через опыт других.
У вас есть два варианта — вступить в полемику с каждым, или же просто прислушаться. Выбирайте.
Судя по всему — все решения неправильные. Ибо в конечном итоге все решения приводят к взлому сайта. Но вот лёгкость взлома, она зависит от принимаемых решений это да.
security through obscurity хороша до тех пор пока ваше решение не изучили или есть возможность более легкого взлома соседа. По крайней мере такие решения спасают от массовых автоматизированных взломов. Один из эшелонов защиты, самый простой.
security through obscurity хороша до тех пор пока ваше решение не изучили или есть возможность более легкого взлома соседа. По крайней мере такие решения спасают от массовых автоматизированных взломов. Один из эшелонов защиты, самый простой.
Бесполезные советы.
Варианта доступа к БД ровно два, в зависимости от того, что было скомпрометировано.
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
Варианта доступа к БД ровно два, в зависимости от того, что было скомпрометировано.
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
Sign up to leave a comment.
Борьба с «плохими» URI, спамерами и php-шеллами — личный опыт