php shell php скрипты
Собираем свой веб-шелл
Здесь ничего объяснять не буду, т.к. все как всегда понятно.
6. Итог
Статейка получилось приличной по объему, поэтому многие доп. функции в статью не вошли, но могу лишь подать идейки:
[1] Сделать ajax обновление
[2] Кодирование в md5,base64,url encode/decode и т.д.
[3] Замутить mysql-менеджер, но это уже вообще отдельная статья
[4] Добавить различие в цветовой гамме папок и файлов, скрытых файлов и т.п.
Кодирование/Декодирование мы будем делать за счет пользовательских функций в PHP: base64_encode и base64_decode.
FORM method = ‘POST’ >
label > b > URL encode : b > label >
input type = ‘text’ name = ‘url’ >
input type = ‘submit’ name = ‘submit’ value = ‘Encode’ >
label > b > URL decode : b > label >
input type = ‘text’ name = ‘url2’ >
input type = ‘submit’ name = ‘submit2’ value = ‘Decode’ >
FORM >
да ты гуру расковырял всо и давай плодить статьи
404 Not Found
Абсолютно неэффективно. Ну то есть да, для начала неплохо, но 100% защиты не даёт. Бот других поисковиков найдёт запросто.
ИМХО, надо резать по IP сетей поисковиков (знающие люди имеют их в бооооольшом количестве). Это хоть как то убережёт ваш шелл от чужих глаз.
Была ещё идея юзать определённый User-Agent и только по нему авторизовывать, но геморно это как то.
BigBear, а в чем сложность твоей идеи? Отписал свою реализацию в соответствующем посте, если я её правильно понял конечно.
Другое дело, если создать портэйбл версию Opera или Mozilla (первое уже встречал) и заходить по шеллам только с портативного браузера с заранее прописанным юзер-агентом. Но тогда придётся везде таскать с собой такой портативный браузер на флэшке или хранить в каком то репозитории.
По этой фразе грех не найти все твои шеллы, тем более пишешь с грамматической ошибкой.
Лучше убрать её совсем.
Другое дело, если создать портэйбл версию Opera или Mozilla (первое уже встречал) и заходить по шеллам только с портативного браузера с заранее прописанным юзер-агентом. Но тогда придётся везде таскать с собой такой портативный браузер на флэшке или хранить в каком то репозитории.
По этой фразе грех не найти все твои шеллы, тем более пишешь с грамматической ошибкой.
shell_exec
(PHP 4, PHP 5, PHP 7, PHP 8)
shell_exec — Выполнить команду через оболочку и вернуть вывод в виде строки
Описание
Эта функция идентична оператору с обратным апострофом.
Список параметров
Команда, которая будет выполнена.
Возвращаемые значения
Ошибки
Примеры
Пример #1 Пример использования shell_exec()
Смотрите также
User Contributed Notes 33 notes
In the above example, a line break at the beginning of the gunzip output seemed to prevent shell_exec printing anything else. Hope this saves someone else an hour or two.
To run a command in background, the output must be redirected to /dev/null. This is written in exec() manual page. There are cases where you need the output to be logged somewhere else though. Redirecting the output to a file like this didn’t work for me:
# this doesn’t work!
shell_exec ( «my_script.sh 2>&1 >> /tmp/mylog &» );
?>
Using the above command still hangs web browser request.
Seems like you have to add exactly «/dev/null» to the command line. For instance, this worked:
# works, but output is lost
shell_exec ( «my_script.sh 2>/dev/null >/dev/null &» );
?>
But I wanted the output, so I used this:
proc_open is probably a better solution for most use cases as of PHP 7.4. There is better control and platform independence. If you still want to use shell_exec(), I like to wrap it with a function that allows better control.
Something like below solves some problems with background process issues on apache/php. It also
A simple way to handle the problem of capturing stderr output when using shell-exec under windows is to call ob_start() before the command and ob_end_clean() afterwards, like this:
‘The system cannot find the path specified’.
I’m not sure what shell you are going to get with this function, but you can find out like this:
= ‘set’ ;
echo «» ;
?>
On my FreeBSD 6.1 box I get this:
USER=root
LD_LIBRARY_PATH=/usr/local/lib/apache2:
HOME=/root
PS1=’$ ‘
OPTIND=1
PS2=’> ‘
LOGNAME=root
PPID=88057
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin
SHELL=/bin/sh
IFS=’
‘
Very interesting. Note that the PATH may not be as complete as you need. I wanted to run Ghostscript via ImageMagik’s «convert» and ended up having to add my path before running the command:
I had trouble with accented caracters and shell_exec.
Executing this command from shell :
Vidéos D 0 Tue Jun 12 14:41:21 2007
Desktop DH 0 Mon Jun 18 17:41:36 2007
Using php like that :
Vid Desktop DH 0 Mon Jun 18 17:41:36 2007
The two lines were concatenated from the place where the accent was.
I found the solution : php execute by default the command with LOCALE=C.
I just added the following lines before shell_exec and the problem was solved :
Just adapt it to your language locale.
Here is a easy way to grab STDERR and discard STDOUT:
add ‘2>&1 1> /dev/null’ to the end of your shell command
For example:
= shell_exec ( ‘ls file_not_exist 2>&1 1> /dev/null’ );
?>
Here is my gist to all:
On Windows, if shell_exec does NOT return the result you expected and the PC is on an enterprise network, set the Apache service (or wampapache) to run under your account instead of the ‘Local system account’. Your account must have admin privileges.
To change the account go to console services, right click on the Apache service, choose properties, and select the connection tab.
How to get the volume label of a drive on Windows
print GetVolumeLabel ( «c» );
?>
Note: The regular expression assumes a english version of Windows is in use. modify it accordingly for a different localized copy of Windows.
I have PHP (CGI) and Apache. I also shell_exec() shell scripts which use PHP CLI. This combination destroys the string value returned from the call. I get binary garbage. Shell scripts that start with #!/usr/bin/bash return their output properly.
A solution is to force a clean environment. PHP CLI no longer had the CGI environment variables to choke on.
// Binary garbage.
$ExhibitA = shell_exec ( ‘/home/www/myscript’ );
?>
— start /home/www/myscript
#!/usr/local/bin/phpcli
echo( «Output.\n» );
Be careful as to how you elevate privileges to your php script. It’s a good idea to use caution and planing. It is easy to open up huge security holes. Here are a couple of helpful hints I’ve gathered from experimentation and Unix documentation.
Things to think about:
1. If you are running php as an Apache module in Unix then every system command you run is run as user apache. This just makes sense.. Unix won’t allow privileges to be elevated in this manner. If you need to run a system command with elevated privileges think through the problem carefully!
2. You are absolutely insane if you decide to run apache as root. You may as well kick yourself in the face. There is always a better way to do it.
3. If you decide to use a SUID it is best not to SUID a script. SUID is disabled for scripts on many flavors of Unix. SUID scripts open up security holes, so you don’t always want to go this route even if it is an option. Write a simple binary and elevate the privileges of the binary as a SUID. In my own opinion it is a horrible idea to pass a system command through a SUID— ie have the SUID accept the name of a command as a parameter. You may as well run Apache as root!
As others have noted, shell_exec and the backtick operator (`) both return NULL if the executed command doesn’t output anything.
This can be worked around by doing anything like the following:
it took me a heck of a lot of head banging to finally solve this problem so I thought that I would mention it here.
If you are using Eclipse and you try to do something like
shell_exec is extremely useful as a substitute for the virtual() function where unavailable (Microsoft IIS for example). All you have to do is remove the content type string sent in the header:
This works fine for me as a substitute for SSI or the virtual() func.
Shell script с root правами из PHP?
с помощью приложения на PHP порождать некие процессы, работающие от конкретного (отличного от пользователя, от которого работает web-сервер) пользователя.
Сейчас, как вы можете догадаться, от apache отпочковываются процессы, работающие под его же пользователем, что естественно не есть гуд по нескольким причинам: 1) если понадобилось ребутнуть apache (или он не дай бог крэшнется сам), то упадут все процессы, порожденные от него 2) кривые права доступа для учетки www-data в связи с тем, что ей тоже нужны права на запуск экземпляров приложения, лежащего вне директории web-сервера. Хватит это терпеть, подумал я…
Был написан shell script, который умеет запускать приложение от конкретного пользователя. Он был протестирован от root-а через консольку — работет. Через PHP выполняем shell_exec(), который запускает наш скрипт с некоторыми параметрами (условно, для простоты понимания, с сетевым портом, который будет слушать экземпляр приложения). Осталось разобраться с правами www-data на запуск скрипта от root-а. Ну так же ж есть sudo, подумал я… Вот тут-то и возникли сложности.
Положим, что бинарник приложения лежит (условно) тут /home/app/bin. Пользователь username, от которого мы собираемся запускать экземпляры, имеет полный доступ (rwx) как к директории так и к бинарнику.
Файлы web-сервера как и положено валяются где-то в /var/www. Apache работает от пользователя www-data.
Shell script лежит (условно) в /var/www/script.sh. Полные права доступа (rwx) к нему имеет только root, все остальные делать с ним ни чего не могут. Он тщательно проверяет входные параметры (существование пути, существование бинарника и другие проверки) и запускает экземпляр приложения следующей командой:
или условно
Остается позволить www-data запускать script.sh от root-а. Ставим sudo,
идем в /etc/sudoers и добавляем:
www-data ALL=(root) NOPASSWD: /var/www/script.sh
По ощущениям этого достаточно и по тем же ощущениям подозрения — слишком просто.
Теперь из PHP вызываем наш скрипт:
Пробуем по другому (через консоль):
Появляется мало ожидаемое приглашение ввести пароль пользователя www-data:
[sudo] password for www-data:
А NOPASSWD на что? Да и вообще какого хрена пароль у www-data? 🙁
Собственно, что я делаю не так?
Понятное дело, что православность решения мягко говоря под сомнением, но пока хочется «добить» хотя бы его (силы-то и время уже потрачены). Другие решения придут (надеюсь) позднее с новым опытом.
19 полезных shell-скриптов на все случаи жизни
Содержание статьи
Командная строка и те невообразимые вещи, которые с ее помощью можно творить, — визитная карточка UNIX и всех ее наследников. А где есть командная строка, там есть скрипты. И сегодня. нет, мы не будем учиться писать скрипты, мы рассмотрим наиболее полезные из них, те, что ты сможешь применять ежедневно для решения самого разного круга задач, начиная от сводки погоды и веб-сервера в одну строку и заканчивая ботом для твиттера в десять строк и скриптом для автоматического запуска любого торрент-клиента.
Сразу оговорюсь, что я вовсе не приверженец шаманизма и ни в коем случае не призываю тебя сидеть в зелено-черной консоли и набирать кучу букв, чтобы выполнить действия, для которых в графическом интерфейсе достаточно навести мышку на нужный элемент. Однако я убежден, что для решения многих задач консоль и скрипты годятся гораздо лучше графического интерфейса и поэтому пренебрегать ими никак нельзя. Тем более что любая DE позволяет создать для скрипта иконку, так что для его запуска даже не надо будет открывать консоль.
Простые примеры
Итак, не разглагольствуя понапрасну, сразу перейдем к примерам:
Эта простая команда покажет тебе внешний IP — идеальный вариант, если в Сеть ты ходишь через роутер. Все, что она делает, — просто обращается к серверу ifconfig.co, который возвращает обратно IP-шник одной строкой вместо полноценной веб-страницы.
И да, это вовсе не скрипт, это просто команда, но, чтобы превратить команду в скрипт, достаточно поместить ее в текстовый файл и первой строкой добавить так называемый шебанг, то есть символы #!, за которыми следует имя командного интерпретатора:
Далее скрипт сохраняем в каталог
/bin и назначаем права на исполнение:
Теперь его можно вызывать из командной строки командой myip.sh.
Этот скрипт позволяет получить сводку погоды на четыре дня. Принцип тут такой же, как в случае с ifconfig.co.
Сводка погоды в консоли
Xakep #212. Секреты даркнета
А так можно получить краткое описание чего-либо в Википедии, причем с помощью DNS-запроса вместо обращения к веб-серверу. Кстати, веб-сервер через командную строку тоже очень легко создать:
Данный скрипт основан на утилите netcat (nc), которую называют швейцарским армейским ножом для сетевых операций. Скрипт запускает цикл, выполняющий команду nc, которая слушает 80-й порт и в ответ на запрос отдает file.html, отправляя переданный запрос в никуда (символ означает noop, то есть пустую операцию).
С помощью простых скриптов и команд можно запросто слушать интернет-радио:
Естественно, плей-лист в формате M3U необходимо заранее скачать с сайта радиостанции. Кстати, если запустить MPlayer с аргументом —input-ipc-server=/tmp/mpvsocket, им можно будет управлять, записывая команды в файл. Например, настроить громкость:
Создай два скрипта: один для запуска, другой для остановки радио (со строкой killall mpv), повесь их на рабочий стол и настрой горячие клавиши DE на управление воспроизведением. Вуаля, у тебя готов плеер для интернет-радио, запустить который можно, просто кликнув по иконке на рабочем столе. И он почти не будет расходовать память или занимать трей.
Но отвлечемся от сетевых операций и вернемся к локальным делам.
А это уже скрипт, который запускает команду в ответ на изменение файлов в каталоге. Ее можно использовать для множества разных целей, например для автоматического включения плеера при сохранении MP3-файла. Или просто выводить уведомление на десктоп, используя в качестве команды notify-send:
Десктоп
Раз уж мы заговорили о десктопе, то продолжим. Как и консоль, его тоже можно заскриптовать. Вот, например, скрипт, загружающий случайные обои, опубликованные на reddit-канале wallpaper:
Здесь все просто. С помощью wget скрипт загружает страницу www.reddit.com/r/wallpaper, передает ее grep, который ищет на ней ссылки на imgur, выбирает случайную ссылку с помощью shuf, загружает ее опять же с помощью wget и устанавливает в качестве обоев, используя команду feh (это такой миниатюрный просмотрщик изображений, его нужно предварительно установить). Скрипт можно добавить на рабочий стол, и тогда по клику у тебя будут меняться обои.
А это скрипт для включения/выключения тачпада ноутбука: включает, если отключен, и наоборот. В своей работе использует утилиту synclient, позволяющую управлять тачпадами производства Synaptics (90% тачпадов делают они). При запуске без аргументов утилита выводит различную информацию о тачпаде, в том числе строку TouchpadOff = 1, если он активирован, и TouchpadOff = 2, если отключен. Скрипт находит это значение и в зависимости от состояния тачпада включает или отключает его.
Ту же самую команду можно использовать для создания полноценной камеры слежения, которая делает снимки в моменты, когда юзер прикасается к мыши:
Для записи полноценного видео с веб-камеры можно использовать такой скрипт:
В результате ты получишь video.avi в формате MPEG4 с битрейтом 1800 и аудиодорожкой в формате MP3 с битрейтом 128.
А так ты можешь записать скринкаст. 1366×768 — разрешение рабочего стола. Просто сделать скриншот отдельного окна всегда можно с помощью команды import:
После ее запуска значок мыши изменится на «прицел», с помощью которого можно выбрать окно. Повесив эту команду на клавиатурную комбинацию, ты получишь практически идеальную систему снятия скриншотов, абсолютно не жрущую память, как это делают специализированные приложения, постоянно висящие в трее.
Подключить и настроить внешний монитор тоже можно из командной строки:
Данный скрипт предполагает, что основной монитор носит имя LVDS, а внешний — VGA-0. Это стандартная ситуация для ноутбуков; если ты не уверен, можешь проверить вывод команды xrandr: при передаче скрипту аргумента off он отключает внешний монитор, аргумент on, в свою очередь, включает его, располагая по левую сторону от основного (аргумент —left-of LVDS в первой команде). Далее скрипт добавляет новую конфигурацию для монитора с разрешением 1920 x 1080 и активирует его. В самом конце скрипт устанавливает дефолтное значение DPI — как показывает практика, при подключении монитора с другим разрешением оно часто слетает.
Он же поможет сгенерировать нестандартное разрешение, «не поддерживаемое» монитором по умолчанию.
Google, Twitter, Dropbox и торренты
Отвлечемся от десктопных дел и поговорим о сетевых сервисах. Начнем, разумеется, с Google. Вот так будет выглядеть скрипт для получения первых десяти результатов поиска:
Скрипт делает запрос к Google с помощью уже знакомого нам curl, заменяя пробелы в поисковой строке на плюсы. Далее выискивает в ответном HTML ссылки и выводит их на экран. Все просто, хоть и кажется сложным.
Ищем в Google из командной строки
Второй популярный сервис — YouTube:
Здесь все совсем просто. Скрипт всего лишь проигрывает видео с указанным в аргументе ID с помощью плеера mpv. Естественно, youtube-dl придется установить заранее.
Как насчет твиттера? Нет проблем, вот полноценный бот, который на входе принимает команду, выполняет ее с помощью командного интерпретатора и отправляет результат указанному юзеру.
Скрипт использует консольный клиент ttytter, читая в цикле последнее direct message, далее он проверяет, не была ли такая команда уже выполнена, и, если нет, выполняет ее и отправляет указанному в переменной USER пользователю, попутно обрезая до 140 символов.
Чтобы все заработало как надо, тебе придется установить ttytter, запустить его, ввести приведенную им ссылку в адресную строку браузера, скопировать показанный браузером ключ аутентификации и ввести его в ttytter. Естественно, перед тем как это сделать, следует завести для бота отдельного юзера и залогиниться под его учеткой.
Ttytter запрашивает ключ
Твиттер можно использовать не только для выполнения команд, но и для мониторинга машины. Следующий скрипт отправляет в ленту сообщение с информацией о состоянии машины (имя хоста, uptime, нагрузка, свободная память и нагрузка на CPU):
Мониторинг машины с помощью Twitter
Ну и под конец приведу скрипт, не связанный с сетевыми сервисами, но имеющий прямое отношение к сетям и к тому, зачем мы обычно их используем. Это скрипт для запуска и остановки торрент-клиента во время простоя машины:
Скрипт уходит в бесконечный цикл, каждую минуту проверяя, сколько миллисекунд прошло с момента, когда юзер что-либо делал (для этого используется команда xprintidle). Если прошло уже 600 000 мс (десять минут), скрипт выполняет команду, указанную в переменной STARTCMD. В противном случае он выполнит команду STOPCMD, но только тогда, когда до нее была выполнена команда STARTCMD. Если кратко: ничего не делаешь за компом десять минут — запускается STARTCMD, в данном случае это команда запуска всех закачек с помощью Transmission, если нет — приостановка всех закачек. Не любишь Transmission? Нет проблем, вот команды для Deluge:
Вместо выводов
Не удивлюсь, если все описанное в статье покажется тебе очередным велосипедостроением, и даже соглашусь с таким мнением. Все-таки современный Linux — это не та система для сумасшедших экспериментаторов, какой она была пятнадцать лет назад. Сегодня для каждой задачи можно найти отдельный, отлаженный и хорошо работающий инструмент, в том числе графический. Другое дело, что не совсем понятно, стоит ли захламлять систему тяжеловесными написанными на Python приложениями с кучей зависимостей, когда ту же задачу легко решить с помощью простенького скрипта.
Каким путем пойти — выбирать тебе. Встанешь ли ты на темную сторону или выберешь путь джедая?
Евгений Зобнин
Редактор рубрики X-Mobile. По совместительству сисадмин. Большой фанат Linux, Plan 9, гаджетов и древних видеоигр.
Борьба с «плохими» URI, спамерами и php-шеллами — личный опыт
Полагаю, все веб-программисты проходят в той или иной степени одинаковый путь. Я основываюсь на своем личном опыте. Для меня в начале постижения этой науки создание сайта было на первом месте. Только по прошествии значительного времени я осознал, что сайты еще и вскрывают. Прочитав, как это делается, я удивился, на сколько просто по неопытности превратить свой сайт в «проходной двор» и стал уделять безопасности определенное внимание. По крайней мере я стал фильтровать входные параметры страниц.
Все эти откровения в свое время забрали огромное количество суббот и воскресений и потребовали перехода на рерайтинг урлов, создание развернутой системы анализа входных параметров на подозрительные слова и выражения (здесь я, кстати, потерпел некоторое фиаско), создание лога параметров, передающихся методом пост, системы оповещения о подозрительных событиях, происходящих на сайте, и, наконец, разрешения запуска только скриптов со специфическим префиксом в имени, чтобы никакой другой скрипт типа template.php или wso2.php не запускался.
Что же нужно иметь ввиду и что можно сделать для создания относительно безопасного сайта?
Стоит ли располагать файлы разных типов в отдельных папках?
Современный сайт, созданный на PHP, имеет обычно довольно разветвленную файловую структуру. В ней однозначно есть исполняемые скрипты, модули или классы, подключаемые инструкцией include/require, файлы .css и .js, страничный кэш. Вот этими файлами для простоты и ограничимся.
Я думаю на вопрос, заданный в подзаголовке, я отвечу утвердительно и это очень даже полезно. Так, например, подключаемые файлы PHP не предназначены для того, чтобы запрашивать их для обработки сервером и вывода в браузер. В папках подобного типа мы располагаем особый файл .htaccess, в котором запрещаем доступ кого-либо к чему-либо.
В папках с файлами .css и .js мы себе такого позволить не можем, но зато мы в этих папках можем ограничить доступ по типам, что тоже не плохо. Ниже приведен запрет на доступ к любым файлам кроме файлов с расширением .js
Стоит заметить, что по моему опыту такое ограничение практически не влияет на реальную безопасность сайта и является, так сказать, только одной галочкой в общем списке дел. Сам я этими методами не пользуюсь, и об этом будет разговор ниже. Но, с другой стороны, усилий для этого тоже требуется минимум, так что почему бы и нет? Опять же, если против вас будет действовать какой-то сумасшедший робот, то он будет переть как трактор и портить все подряд. Если вы будете знать, что в папке у вас лежат только файлы с определенными расширениями, то легче будет обнаружить вредоносного пришельца.
Лично я пошел немного дальше. У меня файлы .css и .js сжимаются и кешируются, поэтому и папки, где лежат исходники могут быть закрыты от всех подряд. Сами же запрашиваемые кэши лежат в довольно глубоко закопанной папке, куда робот может и не дойти. У меня, кстати говоря, и исполняемый скрипт на весь сайт всего один. Но об этом чуть позже.
Стоит ли называть папки нестандартным образом?
Вот, кстати, хороший метод реально повысить безопасность своего сайта. Дело в том, что вредоносный робот ищет на сайте папки с определенными названиями. Это же относится и к файлам. Поэтому как одна из мер повышения безопасности — это изменение имен папок и файлов на что-то нестандартное. Стоит придумать что-то свое и дать именам хотя бы префиксы. Префиксы однозначно помогут от роботов. Если хотите попробовать затруднить и ручной взлом, то советую пойти дальше и дать папкам и основным файлам имена собственные (Петя, Маша и т.д.). Не многие молодые хакеры будут разбираться, где что у вас лежит. Хотя у хакеров, занимающихся взломом от скуки, не известно, какая каша может быть в голове. Но шанс, определенно есть! Главное самому не запутаться. Тоже шанс немалый.
Файл config.php, в котором лежит пароль доступа к базе данных в открытом виде
Вот это то, чего я никак не могу понять. Есть файл, который все знают, как называется, и в котором в открытом виде лежит именно то, что нужно хакеру. Зачем это делается? Это, на мой взгляд, вредительство какое-то. Крайне рекомендую на всех своих сайтах зашифровать данные для доступа к базе данных и разместить их в совершенно нестандартно названном файле, закрытом от доступа по сети и доступного только для чтения. Конечно, надо поработать над оптимизацией скорости расшифровки, но это тоже вполне решаемо. По крайней мере XOR действует довольно быстро (ссылка на Шифр Вернама в конце статьи). Главное иметь ключ хорошей длины и получше его спрятать. Можно создать действительно запутанный и очень эффективный алгоритм расшифровки и заставить хакера провести на вашем сайте много часов, прежде чем им будет найден и ключ и алгоритм его использования. Вы же вовремя злонамеренную деятельность видите, благодаря вашей собственной системе логирования-оповещения, пресекаете деятельность злоумышленника и меняете ключи, пароли, явки и так далее. Поэтому скачивать ваши скрипты и разбираться с ними до потери сознания для хакера может оказаться непродуктивным.
Безопасность запускаемых скриптов php
И этой крайне существенной уязвимостью безопасности грешат большинство движков. Сделайте для примера файл с любым названием, например my_template.php, разместите в нем
Далее разместите его в корне своего сайта на WordPress и вызовите его (скрипт). И он скорее всего сработает! Покажет вам ваш привет!
Вот какая эволюция методов борьбы с этим злом происходила у меня. Но я не работаю на бесплатных (и платных) движках и мне легче!
Сначала я сделал такой Урл-рерайтинг, при котором запускаться могли только файлы с определенным префиксом. Работает это следующим образом. На вашем сайте сам собой, без всяких подозрительных вызовов появляется вредоносный файл без префикса. Вы остаетесь в неведении. Далее идет попытка доступа к этому свеже-подсаженному файлу. У него нет префикса, и он не запускается, а вы тут же, без задержки получаете об этом письмо. Заходите на сайт, видите шелл, блокируете IP, с которого он запрашивался, пишете письмо на хостинг и поднимаете всех сотрудников на уши. Все, как бы хорошо кончается. Ссылка на статью, в которой я в «высоко-художественной и одновременно развлекательной» форме описал проблему и пути решения я укажу в подвале.
Бывает подсадка шелла, проходящая по более интеллектуальному, но для нас более безопасному алгоритму. Известно, что логи доступа на хостингах хранятся ограниченное время, чаще всего неделю. Злоумышленник подсаживает вам на сайт постронний файл — скрипт шелла и оставляет его чуть больше чем на неделю. Логи, в которых была видна уязвимость, пропадают и вы не можете определить уязвимость, которая была использована. Но в нашем случае мы, в течение считанных минут, получаем оповещение о появлении чужака в файловой структуре нашего сайта, так что этот, казалось бы, изощренный метод подсадки нам более предпочтителен и желателен.
Описанная система прожила у меня не долго и была успешно заменена. В итоге я пришел к следующей схеме, которую на сегодняшний день считаю близкой к идеальной.
Мы удаляем из .htaccess все правила урл-рерайтинга, которые там были и оставляем только одно правило, которое любой файл отправляет на один разъединственный исполняемый скрипт вашего сайта. Он имеет особое, ни на что не похожее название, как минимум префикс. Этот скрипт по REQUEST_URI разбирается, что же это пришло, делает всякие seo-действия по рерайтингу и решает, на какой скрипт передавать управление. Управление передается не рерайтингом, конечно, а путем подключения файла инструкцией require. В итоге доступ на вашем сайте разрешен всем, но выполняется всего один исполняемый php-скрипт. Все остальные скрипты лежат в отдельной папочке и защищены от запросов по сети и могут быть защищены инструкцией Deny from all. А могут и не быть.
Кстати, такая схема употребляется в некоторых движках. Но там всем управляет мега-скрипт index.php с 10 тысячами строк и более, и реализована эта схема вовсе не ради безопасности, а для того, чтобы было удобнее закрыть код от разворовывания.
Вот такое правило стоит у меня в .htaccess
Обратите внимание, что пропускаем мы совершенно определенные файлы, которые у нас точно существуют, и на диспетчерский скрипт переводятся все запросы без исключения, а не одни только скрипты 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, а во-вторых, включить урл-рерайтинг.
Любой запрашиваемый файл сразу, прямиком отправляется в лог плохих ури со всеми возможными подробностями. Строчка об этом событии попадает в лог доступа и не попадает в лог ошибок. Мы получаем письмо от системы оповещения, но, конечно, если запрограммировали эту функциональность.
Вышеприведенный .htaccess подходит для замены функциональности «Deny from all«. В случае, если нам надо что-то пропустить, например, скрипты js или таблицу стилей, то нужно либо разрешить запрос определенных типов файлов, либо, что лучше, задать скриптам особые имена или префиксы. Ну, или перечислить пропускаемые файлы явно. Но, боюсь, это уже слишком жестко в смысле продуктивности и программиста и сервера.
Атаки и блокирование вредоносных IP
Время от времени, но с удивительной регулярностью, на сайт происходят атаки. Среди этих атак есть такие, когда с определенного IP идут прозвоны страниц логина и регистрации пользователя, отправки писем через форму и приема объявлений. Это работают mail-сервера. Работают они чаще всего в паре с «чистыми» IP, которые не используются для атак, а используются только для прозвонов. Для определения сущности IP, занимающихся спамом, я сам использую и всячески пропагандирую сайт projecthoneypot.org.
Бороться с такими спаммерами оказалось крайне просто. Надо просто реализовать все эти формы аяксом и все. Одного только этого бывает уже вполне достаточно. Для пущей безопасности можно запретить вызов php-бэкенда, если он не идет с сайта.
Очень объемный трафик идет от сомнительных ботов. Почему сомнительных? Потому что я не знаю, полезны ли эти боты для сайта и зачем они ходят по моему сайту и звонят урлы, которые вышли из употребления много лет назад. Вообще, появление давным давно убитых урлов само по себе является компрометирующим действием для бота. Такие боты чаще всего не используют файл robots.txt или используют его в противоположном направлении, то есть для них существование списка запрещенных к просмотру адресов есть повод именно до них и ломиться. Тем не менее, эти боты честно метят себя в пользовательских агентах. Из таких я могу назвать 199.192.207.146 с агентом или 185.53.44.90 с агентом
IP в приведенных выше примерах реальные, но понятно, что у этих ботов не один IP адрес, а много.
Есть и боты, маскирующиеся под хорошие, но, похоже, такими не являющиеся. Вот, например, 176.31.182.56 с агентом По действию этого IP на моем сайте у меня есть очень большие сомнения, что это действительно Googlebot.
Наконец, мне очень не нравится bingbot. Он крайне неаккуратный. Он обожает ломиться к сайту по несуществующим урлам. Все бы ничего, если не задумываться, где и в каких базах он эти урлы берет и почему не удаляет их из базы? Понятно, что этого зверя я не блокирую, несмотря на мое к нему отношение.
Но есть атаки не направленные явно на спам. Запросы могут сыпаться со скоростью несколько штук в секунду и представляют собой полную чушь. Часто испорченные и исковерканные запросы к самому сайту, а часто атаки на движки, из которых лидирует WP. Серия запросов обычно может быть от 100 до 200 штук в одной серии за сутки. Зачем ломиться до движков — понятно, наверное. Зачем пытаться добиться ответа сайта по исковерканным и часто вообще нечитаемым урлам мне не понятно. Но факт в том, что куча запросов с высокой скоростью замедляют и сам сайт и его соседей по хостингу и с ними стоит бороться.
Кстати, что такое «нечитаемый урл»? А вот что!
Пожалуйста, не пытайтесь реально зайти по этому урлу на мой сайт, ибо в этом случае ваш IP будет помечен опасным и он будет поражен в правах.
Во-первых, урл имеет длину боле 255 знаков и его пришлось обрезать. Во-вторых, хоть все, что идет за словом «Result:» и декодируется (windows 1251), но все равно представляет собой чушь. Есть подозрение, что запрашивает этот урл XoviBot/2.0, причем в сравнительно больших количествах и всегда одинаковый.
Но как бороться? И стоит ли блокировать все подряд? Если с этим процессом трудно бороться, может быть его можно возглавить, или как-то по-другому к нему приспособиться?
Я, к сожалению, не знаю, каков круговорот плохих IP в природе, и могут ли плохие стать хорошими, а хорошие плохими. Поэтому я если и блокирую, то делаю это в ручном режиме. Если принадлежность IP из такой страны, где мой русскоязычный сайт скорее всего читать не будут, и деятельность слишком уж жесткая, я эти IP блокирую. Остальные оставляю.
В моей системе безопасности есть не только лог плохих ури, но и лог IP, когда либо вызвавших плохой ури. Спамовские, опасные, заблокированные и разблокированные IP, а также боты, учитываются в этом списке.
При заходе с заблокированного IP клиент попадает на специальную страницу, где ему предлагается нажать на кнопку и разблокировать IP. Кнопка аяксовая. Запись о блокировке автоматически меняется на «разблокированный IP». У меня сейчас порядка 20 заблокированных IP. Был ли хоть один из них разблокирован пользователем? Нет. Не был. Часто происходят заходы с уже заблокированных IP? Нет, исчезающе редко.
Для всех клиентов, приходящих с IP, которые как-либо помечены, никогда не производится дополнительная обработка их запросов. Для них не проверяется наличие обязательного обратного слэша, они не проверяются на список редиректов, для них не работает преобразование SEO адресов. Если запросы не являются полностью хорошими, то им тут же, без задержки, выводится краткое прощанье.
Но в последнее время я думаю о том, что можно усовершенствовать систему блокирования. Возможно, было бы полезно при обнаружении серии потока запросов с некоего IP, блокировать его на час. Боюсь только, что я уже так заоптимизировал схему обработки плохих ури, что блокировка IP и вывод ему стандартного прощанья примерно одинаковы по времени обработки.
Резюме
Выше описаны довольно простые действия, которые могут серьезно повысить степень защищенности любого сайта. У меня остается вопрос — почему же эти простейшие вещи не включены, кажется, ни в один движок? Ни в платный, ни в бесплатный?