Что такое шеллы в скриптах

Что такое командная оболочка (shell) в Linux?

Обновл. 27 Июл 2021 |

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

Что такое shell?

Shell (или «шелл», «командная оболочка») — это не только командный интерпретатор, который обеспечивает интерфейс взаимодействия между пользователем и ядром операционной системы, но и своеобразный язык программирования, в котором присутствуют такие конструкции, как операторы условного ветвления, циклы, переменные и многое другое.

Окно терминала привилегированного (root) пользователя (виден символ #)

Примечание: Знак тильды (

) указывает на то, что мы находимся в домашнем каталоге текущего пользователя.

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

Внутренние и внешние команды оболочки

Вводимые пользователем команды делятся на два типа:

Внутренние — это команды, изначально встроенные в оболочку.

Внешние — это команды, которые не встроены в оболочку. По своей сути они являются скорее небольшими отдельными программами, расположенными где-то в файловой системе (обычно, в каталогах /bin или /usr/bin).

Чтобы определить тип команды, достаточно в окне терминала ввести type :

Ознакомиться с полным списком внутренних команд оболочки можно при помощи команды help :

Как узнать какая оболочка у меня установлена?

Если вы только начинаете свое знакомство с Linux и не меняли оболочку, то наиболее вероятно, что в вашей системе используется bash. Самый простой способ узнать, какая оболочка используется в данный момент — это обратиться к переменной окружения SHELL :

Не трудно заметить, что в настоящее время используется оболочка bash. Для просмотра всех доступных оболочек в вашей системе, необходимо обратиться к содержимому файла /etc/shells:

Типы командных оболочек

В *nix-системах существует два основных типа оболочек: оболочки на основе Bourne shell и оболочки на основе C shell.

Типичными представителями оболочек типа Bourne shell являются:

bash (Bourne Again shell)

К оболочкам типа C Shell относятся:

tcsh (TENEX/TOPS C shell)

Ниже представлены некоторые из самых распространенных шеллов, используемых в *nix-системах:

Примечание: Термин «*nix-системы» обозначает Unix-подобные операционные системы.

sh (Bourne shell)

sh (сокр. от «Bourne shell») — это самая старая (среди рассматриваемых) оболочка, написанная Стивеном Борном из AT&T Bell Labs для ОС UNIX v7. Оболочка доступна практически в любом *nix-дистрибутиве. Многие другие шеллы уходят своими корнями именно к sh. Благодаря своей скорости работы и компактности, данная оболочка является предпочтительным средством для написания shell-скриптов. К её недостаткам можно отнести отсутствие функций для использования оболочки в интерактивном режиме, а также отсутствие встроенной обработки арифметических и логических выражений.

Примечание: Стоит отметить, что из-за общего морального устаревания оболочки, в современных системах ссылка на шелл sh (/bin/sh), обычно, является псевдонимом для запуска текущей, более новой оболочки.

Характерные черты sh:

Полные пути к интерпретатору: /bin/sh и /sbin/sh.

bash (Bourne-Again shell)

bash (сокр. от «Bourne–Again shell») — это усовершенствованный и дополненный вариант шелла sh, является одной из самых популярных современных командных оболочек *nix-систем.

Объединяет в себе полезные фишки оболочек ksh и csh.

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

Характерные черты bash:

Полный путь к интерпретатору: /bin/bash.

Приглашение для обычного пользователя: имя_пользователя@имя_хоста:

— это домашний каталог текущего пользователя, например, mrsmith@mypc:

Приглашение для суперпользователя (root): root@имя_хоста:

ksh (Korn shell)

ksh (сокр. от «Korn shell») — это командная оболочка, разработанная Дэвидом Корном из AT&T Bell Labs в 1980-x годах.

Является расширением sh.

Имеет обратную совместимость с sh.

Имеет интерактивный функционал, сравнимый с csh.

Включает в себя удобные для программирования функции, такие как: встроенную поддержку арифметических выражений/функций, Си-подобный синтаксис скриптов и средства для работы со строками.

Работает быстрее, чем csh.

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

Характерные черты ksh:

Полный путь к интерпретатору: /bin/ksh.

csh (C shell)

csh (сокр. от «C shell») — это командная оболочка, созданная Биллом Джоем (автором редактора vi) с целью усовершенствования стандартного шелла Unix (sh).

Имеет встроенные функции для интерактивного использования, например, псевдонимы (aliases) и историю команд.

Включает в себя удобные для программирования функции, такие как: встроенную поддержку арифметических выражений и Cи-подобный синтаксис скриптов.

Характерные черты csh:

Полный путь к интерпретатору: /bin/csh.

tcsh (TENEX C Shell)

tcsh (сокр. от «TENEX C shell») — это командная оболочка, созданная Кэном Гриром, которая позиционируется как улучшенная версия шелла csh.

Имеет полную совместимость csh.

Именно в данном шелле впервые появилась функция автодополнения команд и путей.

Удобна для интерактивной работы.

Поддерживает редактор командной строки в стиле vi или emacs.

Является стандартным шеллом во FreeBSD.

Характерные черты tcsh:

Полный путь к интерпретатору: /bin/tcsh.

Приглашение для обычного пользователя: имя_хоста:

zsh (Z Shell)

zsh (сокр. от «Z shell») — это командная оболочка, созданная Паулем Фалстадом во время его учебы в Принстонском университете, позиционируется как свободная современная sh-совместимая командная оболочка.

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

Встроенная поддержка программируемого автодополнения команд, имен файлов и пр.

Поддержка проверки орфографии и опечаток.

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

Характерные черты zsh:

Полный путь к интерпретатору: /bin/zsh.

Приглашение для суперпользователя (root): root@имя_хоста:

Резюмируем

Краткая сводная таблица для 6 вышерассмотренных командных оболочек:

$имя_пользователя@имя_хоста:

#ksh (Korn Shell)/bin/ksh$#csh (C Shell)/bin/csh%#tcsh (TENEX C Shell)/bin/tcshимя_хоста:

>#zsh (Z Shell)/bin/zsh%#

Примечание: Помимо представленных выше оболочек, есть еще и такие оболочки, как:

mksh — оболочка, основной упор в которой сделан на написание скриптов;

dash — более легковесная в сравнении с bash оболочка, но из-за этого обладающая ограниченной функциональностью;

fish — «новая» оболочка, написанная в 2005 году, отличительной чертой которой является упор на комфорт использования и упрощение командного языка;

Поделиться в социальных сетях:

Источник

Борьба с «плохими» 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 и вывод ему стандартного прощанья примерно одинаковы по времени обработки.

Резюме

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

Источник