Данную книгу можно назвать практической энциклопедией. В ней дан максимальный охват проблематики обеспечения информационной безопасности, начиная с современных подходов, обзора нормативного обеспечения в мире и в России и заканчивая рассмотрением конкретных направлений обеспечения информационной безопасности (обеспечение ИБ периметра, противодействие атакам, мониторинг ИБ, виртуальные частные сети и многие другие), конкретных аппаратно-программных решений в данной области. Книга будет полезна бизнес-руководителям компаний и тем, в чью компетенцию входит решение технических вопросов обеспечения информационной безопасности. Все права защищены. Никакая часть этой книги не может быть воспроизведена в какой бы то ни было форме и какими бы то ни было средствами, включая размещение в сети Интернет и в корпоративных сетях, а также запись в память ЭВМ для частного или публичного использования, без письменного разрешения владельца авторских прав. По вопросу организации доступа к электронной библиотеке издательства обращайтесь по адресу mailto:%[email protected] [email protected] . |
Салонный бизнес развивается, и с каждым месяцем салонов красоты становится больше. Но открыть предприятие индустрии и привлечь клиентов – два разных вопроса. Эта книга поможет собственникам и директорам существующих салонов освоить основы рекламного дела. В книге раскрыты все эффективные варианты рекламы бьюти-предприятия, на что стоит обратить внимание в созданием макета флаера, визитки, сайта; какие подводные камни и грубые ошибки могут нанести ущерб репутации. Вы узнаете, как проводить рекламные акции по привлечению клиентов и сделать это с минимальным бюджетом. А также сможете получить действенные и проверенные на практике инструменты привлечения новых и удержания существующих клиентов. Книга, посвященная рекламе салонов красоты, выходит впервые на территории СНГ. Автор – Владислав Вавилов, бизнес-тренер, ведущий консультант в индустрии красоты и фитнеса, политический и общественный деятель. |
| ||||||||||
CGI-двоичныйВозможные атакиИспользование PHP как двоичного CGI это опция установки, когда, по некоторым соображениям, нет желания интегрировать PHP как модуль в программу-сервер (такую как Apache) или когда PHP будет использоваться с различными видами CGI-оболочек для создания для скриптов безопасной среды chroot и setuid. Такая инсталяция обычно заключается в установке исполняемого файла PHP в директорию cgi-bin web-сервера. CERT advisory CA-96.11 рекомендует не помещать никакие интерпретаторы в директорию cgi-bin. Даже если исполняемый файл PHP используется как самостоятельный интерпретатор, PHP разработан таким образом, чтобы предотвратить атаки при таком варианте установки:
Вариант 1: обслуживаются только public-файлыЕсли на вашем сервере нет содержимого, доступ к которому ограничен паролем
или ip, то нет необходимости в применении этих опций конфигурации. Перенаправление может быть сконфигурировано в Apache через использование директив AddHandler и Action (см. ниже). Вариант 2: использование --enable-force-cgi-redirectЭта опция времени компиляции предотвращает вызов PHP кем бы то ни было прямо в url, например, http://my.host/cgi-bin/php/secretdir/script.php. Вместо этого PHP будет разбирать в этом режиме только в том случае, если пройдено правило перенаправления web-сервера. Обычно перенаправление в конфигурации Apache выполняется следующими директивами:
Эта опция была проверена только на сервере Apache и основывается на установке Apache нестандартной переменной окружения CGI REDIRECT_STATUS для перенаправленных запросов. Если ваш web-сервер не поддерживает способ сообщения того, является ли запрос перенаправляемым или прямым, вы не можете использовать эту опцию и обязаны использовать один из других вариантов запуска CGI-версии из указанных здесь. Вариант 3: установка doc_root или user_dirВключение активного содержимого, такого как скрипты и исполняемые файлы, в директорию документов web-сервера считается небезопасным. Если они, из-за какой-нибудь ошибки конфигурации, не исполняются, а выводятся как обычные HTML-документы, это может привести к потере интеллектуальной собственности или закрытой информации вроде паролей. Поэтому многие sysadmins предпочитают устанавливать другую структуру директорий для скриптов, когда они доступны только для PHP CGI и, следовательно, всегда интерпретируются и не выводятся как текст. Также, если невозможно гарантировать, что запросы не перенаправляются, как указано в предыдущем разделе, необходимо установить doc_root скриптов, которая отличается от web document root. Вы можете установить корневую директорию скриптов PHP директивой конфигурации doc_root в файле конфигурации или можете установить переменную окружения PHP_DOCUMENT_ROOT. Если она установлена, CGI-версия PHP всегда будет конструировать имя открываемого файла с применением doc_root и информации пути к файлу из запроса, поэтому вы можете быть уверены, что никакие скрипты не будут исполняться вне этой директории (за исключением user_dir ниже её). Другая используемая здесь опция - user_dir. Когда user_dir не установлена/unset, единственное, что контролирует имя открываемого файла, это doc_root. Открытие url вроде http://my.host/~user/doc.php приводит к открытию не файла под home-директорией пользователя, а файла, вызываемого ~user/doc.php под doc_root (да, директории с именем, начинающимся с тильды [~]). Если user_dir установлена для, например, public_php, запрос вроде http://my.host/~user/doc.php откроет файл doc.php под директорией public_php ниже home-директории пользователя. Если home пользователя это /home/user, выполняется файл /home/user/public_php/doc.php. Расширение user_dir происходит независимо от установки doc_root, поэтому вы можете контролировать доступ к директории document root и пользовательской директории независимо друг от друга. Вариант 4: разборщик PHP вне дерева webОчень надёжной опцией является помещение исполняемого файла разборщика PHP где-нибудь вне дерева файлов web. В /usr/local/bin, например. Единственным недостатком этой опции является то, что вы теперь должны помещать строку вроде следующей:
как первую строку любого файла, содержащего тэги PHP. Вы также должны сделать файл исполняемым. То есть рассматривать его так же, как любой другой CGI-скрипт, написанный на Perl или sh или любом другом языке скриптинга, который использует механизм замены #! оболочки для запуска самого себя. Чтобы PHP корректно обрабатывал информацию PATH_INFO и PATH_TRANSLATED при такой установке, разборщик РНР должен быть скомпилирован с опцией конфигурации --enable-discard-path. | ||||||||||
|