Vamp

Необходимо установить расширение mongodb для самого PHP и дополнительную библиотеку alcaeus/mongo-php-adapter.

1. Проверьте синтаксическую корректность номера телефона. Все мобильные номера в РФ начинаются на +79 и имеют длину ровно 11 цифр. Проверку можно даже добавить в веб форму на уровне js. Это нельзя назвать защитой от хулиганов, но она отсеет реальные ошибки и опечатки, облегчив жизнь обычным пользователям.

2. Пробейте номер по базе россвязи (файл DEF-9xx). Так вы определите номера, на которые 100% не будет доставки. В отличии от проверки синтаксиса, не выдавайте пользователю ответ о некорректном номере. На все номера отвечайте "Одноразовый код отправлен, введите его сюда", но на невалидные номера не отправляйте сообщение.

3. Добавьте ограничение на количество отправляемых форм в минуту с одного IP и количество отправляемых сообщений на один и тот же номер (независимо от IP).

4. Оцените сколько может быть отправок форм в день и поставьте общий лимит на все отправки смс за день. Это единственный реальный способ контролировать атаку на сливание бюджета. Да, реальные пользователи пострадают при достижении лимита, но вы не должны доводить до него - настройте мониторинг количества отправляемых смс и алертинг при достижении порога в 90% от лимита, чтобы у вас было время среагировать на атаку и отбить её до полного исчерпания лимита. Либо если это всплеск реальных пользователей (например, неожиданно удачная реакция на рекламу), то у вас будет время скорректировать лимит. Можно рассчитывать лимит как 2 * среднее количество отправок смс за последние Х дней, чтобы не приходилось править его вручную по мере естественного роста посещаемости. Формулу и процент для алертинга, разумеется, подберёте под свои требования. Но можете взять и мои за основу.

Отдельно хочу рассказать про так называемые прямые мобильные номера. Они выглядят как городские (например, +7495), но в реальности являются мобильными и могут принимать смски. Проверка в пункте 1 не пропускает такие номера и нет никакого способа проверить без отправки смс является ли отдельно взятый городской номер прямым мобильным. Прямых номеров мало по сравнению с настоящими мобильными или настоящими городскими. К тому же у каждого прямого номера есть мобильный аналог, начинающийся на +79, которым пользователь может воспользоваться для регистрации. Поэтому предлагаю просто забить на прямые номера, а в случае жалоб на невозможность регистрации с прямым номером, рассказывать про существование мобильного аналога, который может быть прописан где-то в договоре с оператором на оказание услуг связи или узнать в техподдержке оператора и с которым можно спокойно зарегистрироваться.

Обязательное требование email'а не усилит схему защиты, так как не проблема наштамповать реальных адресов со скриптом, автоматически прокликивающим подтверждающие ссылки во входящих письмах.

Альтернативным вариантом является аренда входящего номера. В этом случае не вы отправляете сообщения пользователям, а они вам. Обычно за входящий номер берут фиксированную плату в месяц независимо от количества смс, так что не придётся в принципе волноваться за бюджет. Но тогда у вас будут в пролёте пользователи с отключенной услугой отправки смс. А таких немало, могу сказать. Благодаря интернет-мессенджерам.

Вам нужно явным образом вызвать интерпретатор php и передавать ему путь к скрипту:

cd /var/www/no-name/data/www/oushd.ru/core/channels/channels/ && php /var/www/no-name/data/www/oushd.ru/core/channels/channels/test.php

cd /var/www/no-name/data/www/oushd.ru/core/channels/channels/ && php /var/www/no-name/data/www/oushd.ru/core/channels/channels/channels.php

Архитектурно правильнее возвращать как в примере с Yii2. Использование исключений для управления потоком выполнения программы считается серьёзным антипаттерном.

Например:
1. Исключения в данном случае - просто более хитрая замена оператору GOTO. Надеюсь, не нужно объяснять почему GOTO тоже считается антипаттерном?
2. Программы, написанные в таком стиле, становится сложно читать и понимать.
3. Меньшая эффективность в рантайме, так как большинство современных компиляторов не оптимизированы для случаев использования исключений в качестве управляющей логики.

Более подробно по ссылке.

Потому что нужно устанавливать пакет php7.3-bcmath. На вашем же скриншоте видно, что установилась версия модуля для PHP 7.4: php-bcmath is already the newest version (2:7.4+73+ubuntu18.04.1+deb.sury.org+1)

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

Если хотите точно знать как сильно влияет на производительность то или иное ваше решение в проекте, берите apache bench, siege, yandex.tank и тестируйте. Сразу скажу, разницы между 11 и 5 файлами вы точно не увидите. Впрочем, как между 5 и 555. Но не во всех случаях ответ будет сразу очевиден, поэтому обязательно освойте какую-нибудь тулзу для нагрузочного тестирования и не гадайте на кофейной гуще.

__setSoapHeaders устанавливает заголовки soap запроса, а не http. Они размещаются в элементе Header. По вашему примеру кода получится что-то типа такого:

<SOAP-ENV:Envelope
    xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:ns1="yourns"
    xmlns:ns2="http://soapinterop.org/echoheader/">
    <SOAP-ENV:Header>
        <ns2:token>token</ns2:token>
        <ns2:user-token>user_id</ns2:user-token>
    </SOAP-ENV:Header>
    <SOAP-ENV:Body>
        <!-- тело запроса -->
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Для добавления именно http заголовков нужно создать stream context:

$aOptions['stream_context'] = stream_context_create([
    'http' => [
        'header' => "token: abc\r\nuser-token: 123"
    ]
]);

$oSoapClient = new SoapClient( $url, $aOptions );
$result = $oSoapClient->__doRequest( $sXml, $url, null, SOAP_1_1 );

Время последнего доступа кого угодно к файлу, на который вызываете stat(). Открытие файла и чтение данных из него обновляет метку atime. Причём последнее зарегистрированное время открытия/чтения необязательно могло быть сделано PHP скриптом.

Храните и отображайте в обычной строке. Влезет столько знаков, сколько нужно.

Сразу после вызова функции.

for ($i=0; $i < 3; $i++) { 
  echo curlNew();
  sleep($sleepTime);
}

1. Надо смотреть какое именно API предоставляет сервер. Если JSON REST, то gRPC не подойдёт. gRPC - отдельный протокол, который должны поддерживать и клиент, и сервер, чтобы можно было по нему взаимодействовать.

2. Если хотите взаимодействовать с удалённым сервером, то нужен только клиент. Если хотите сами быть для кого-то сервером, предоставляющим gRPC API, то нужен сервер. На PHP нельзя сделать gRPC сервер, видимо поэтому и предлагают node.js. Попробуйте поднять сервер на линуксе, вместо openserver. Тогда появятся команды, описанные в доке, и вообще разработка станет гораздо проще.

3. Простых доков по gRPC не видел.

Помимо самого gRPC вам придётся разобраться ещё и с protobuf, так как gRPC основан на нём. Его тоже необходимо установить либо как модуль к PHP, либо как composer зависимость. Помимо этого, удалённый сервер должен предоставить proto файл, на основе которого вы будете делать gRPC клиента. Этот файл необходимо скомпилировать при помощи protoc (компилятора protobuf) с использованием специального плагина к нему - grpc_php_plugin. В результате получится набор PHP скриптов, реализующих gRPC клиента для доступа к API удалённого сервера. Вот эти скрипты вы и будете использовать в своих скриптах для общения с сервером.

Вам придется вручную составить XML. Встроенных средств для работы с атрибутами у SoapClient нет.

$xw = new XMLWriter();
$xw->openMemory();
$xw->startElementNS('ns1', 'GetTariffRequest', null);
    $xw->startElement('NeedList');
        $xw->text('1');
    $xw->endElement();

    $xw->startElement('Subject');
        $xw->writeAttribute('SbjKey', '1');
    $xw->endElement();
$xw->endElement();

$s = new SoapClient(...);
$s->GetTariff(new SoapVar($xw->outputMemory(), XSD_ANYXML));

XMLWriter здесь только как пример. Составлять строку с XML вы можете любым другим способом.

upload_tmp_dir нужно указывать в пределах open_basedir, иначе скрипты сайта не смогут получить доступ к загружаемым файлам. Аналогично нужно настроить ещё session.save_path и sys_temp_dir, иначе не будут работать сессии и функции для работы с временными файлами.

Смысл появляется когда у вас больше одного сайта на сервере. В этом случае open_basedir используется для изоляции сайтов друг от друга - чтобы взлом одного сайта не привёл ко взлому всех остальных сайтов на сервере.

Пару лет назад я описывал рабочую схему для усиления безопасности в другом вопросе на тостере. Взгляните.

Сложно сказать в чём у вас ошибка, так как вы не предоставили код. Вероятно, криво составили QR, раз уж ошибка возникает при его сканировании. Более подробно о том как нужно составлять урл для QR-кода можно прочитать в вики.

Я внедрил Google Authenticator в свой проект без каких-либо проблем. Использую пакет sonata-project/google-authenticator.

Генерация кода:

$g = new \Google\Authenticator\GoogleAuthenticator();
$secret = $g->generateSecret();
echo '<img src="https://chart.googleapis.com/chart?'
  .'cht=qr&chl=otpauth://totp/mysite%3Fsecret%3D'
  .$secret.'&chs=200x200&chld=L|0" />';

Значение $secret сохраняется в БД и привязано к конкретному юзеру.

Проверка OTP:

$g = new \Google\Authenticator\GoogleAuthenticator();
if ($g->checkCode($secret, $code)) {
  echo 'Welcome!'
} else {
  echo 'Wrong code';
}

Примеры кода приведены для библиотеки версии 1.0.2.

Важный момент - время на сервере и на телефонах должно совпадать, чтобы генерируемые OTP совпадали. Поэтому сервер синхронизируется по протоколу NTP. С телефонами сложнее. Можно в настройках системы установить синхронизацию часов телефона с временем из GSM сети (для любых платформ), либо в настройках приложения Google Authenticator (в android версии есть, в iOS версии нет, про другие платформы не в курсе).

Метод exec() - это функция SSH2. Так как сервер, к которому вы подключаетесь, не предоставляет вам полноценный SSH доступ, а только лишь SFTP, то и методы вы должны вызывать из класса SFTP:
$ssh->chdir()/nlist()/stat()/get()/put()/delete() и так далее.

В статье рассматривается производительность какой-то абстрактной "обычной CMS" на дешманском VPS хостинге и влияние трех разных видов кеша на общую производительность сайта.

В разделе "SERVER CACHE TYPES EXPLAINED", в принципе, довольно точно и доходчиво расписано про рассматриваемые типы кеширования.

OpCache кеширует результат парсинга php скриптов интерпретатором. Возможно вы не знали, но php скрипты не исполняются интерпретатором напрямую - они сначала проходят через этап парсинга исходного скрипта и его преобразования в так называемые опкоды, которые уже исполняются php интерпретатором. Полученные на этапе прасинга опкоды можно закешировать, так как они не меняются от вызова к вызову (разумеется, если сам скрипт не меняется). Эта операция одинаковая для всех скриптов, поэтому OpCache должен быть включен всегда и везде.

APCu позволяет закешировать произвольную информацию. Например, результат SQL запроса, чтобы в следующий раз не делать запрос к базе и достать результат сразу из кеша. Необходимость APCu для сайта очень сильно зависит от самого сайта. Обычно об этом написано в документации к движку, на котором написан сайт. Так же возможна ситуация, когда сайт затачивался под другой кеширующий модуль, например, memcache, xcache или даже кеширует свои данные в простые файлы - в этом случае наличие/отсутствие APCu ни на что влиять не будет.

There is one peculiarity regarding APCu caching, when it is used alone without OpCache enabled. APCu will internally reduce number of MySQL queries between PHP and MySQL, however, to really shine and show it’s full potential, OpCache must be enabled.

Вот этот замечательный абзац вообще полный бред. APCu не сможет магическим образом уменьшить количество запросов к mysql. Об этом должен позаботиться программист явно - положить результат запроса в кеш и проверить в кеше его наличие перед отправкой запроса. И APCu не станет сиять, если включить OpCache. Эти два модуля никак друг на друга не влияют. Вообще. Совсем.

Static HTML - кеширование всей страницы целиком. То есть весь сгенерированный HTML код страницы будет сохранён где-то. Может быть даже в APCu, хотя из статьи не очень ясно где именно сохраняется результат. Скорее всего в файловой системе. Последующие запросы к этой странице будут обслужены полностью из этого кеша. Непонятно зачем это было выделено в отдельный тип кеширования.

На таблицу результатов можно не смотреть. Эти цифры не имеют никакого смысла, если не представлен сайт, который был протестирован, так как влияние APCu и static HTML cache очень сильно от этого зависит. Результаты могут быть диаметрально противоположны для тех же самых условий, но для другого сайта.

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

Отвечая на ваш вопрос - ставить APCu нужно только для сайтов, которые явно его поддерживают. OpCache нужно ставить всегда.

Все заголовки относятся исключительно к своему ответу. После получения редиректа барузер сгенерирует новый отдельный запрос к ресурсу /my/file.svg и сервер вместе с ним вернёт свои заголовки, относящиеся только к этому ресурсу и в этих заголовках кеширующей директивы не будет.

Так что в вашем случае будет закеширован редирект. То есть браузер запомнит что урл "file.php?path=/my/file.svg" редиректится на "/my/file.svg" (в принципе, он это запомнит и без дополнительного Cache-Control) и если встретит где-то на странице первый урл, то отправит запрос сразу на второй урл, минуя запрос на первый.

Вам нужно отдавать контент картинки непосредственно самим скриптом:

header('Content-Type: image/svg+xml');
// public явным образом разрешает кешировать контент не только на
// устройстве пользователя, но и на любом промежуточном кеширующем http сервере,
// если такой будет стоять между вами и пользователем
// например, провайдерский или в офисах
header('Cache-Control: public, max-age=604800');

// ОСТОРОЖНО!!! Сначала произведите валидацию
// параметра path перед передачей его в readfile()!
readfile($_GET['path']);

Это не должно быть напряжно по ресурсам. Всё-таки кешируется на неделю.

Для начала необходимо разделить сайты друг от друга физически. Сами скрипты сайта, временные файлы и файлы сессий.

Например, структура может быть такая:

/var/www
  + toster.ru
  |  + site
  |  + sessions
  |  + temp
  + example.com
  |  + site
  |  + sessions
  |  + temp
  + остальные сайты

В папке site расположены скрипты сайта. Обычно эта папка (или одна из вложенных) является document root сайта.

В sessions находятся файлы сессий посетителей сайта. Если их не разделять, то взлом одного сайта автоматически дискредитирует сессии всех пользователей остальных сайтов. То есть, взломав example.com, можно стырить сессию администратора toster.ru. Путь к этой папке настраивается директивой session.save_path.

А в temp находятся временные файлы, загружаемые пользователями через html формы (директива upload_tmp_dir). Туда же неплохо направить и остальные временные файлы, генерируемые функциями tmpfile(), tempnam(), самостоятельным образом (используя результат функции sys_get_temp_dir() для построения пути) или любой другой функцией, которая использует системную временную директорию. К сожалению, директива sys_temp_dir, ответственная за это, появилась только в php 5.5.0. Если у вас более ранняя версия, тогда нужно учитывать момент, что сайты могут ходить в /tmp и нельзя блокировать доступ к этой папке.

---

Далее необходимо настроить нормальные права доступа. Часто в интернете можно видеть советы "делайте chmod 777 на всё". Так делать нельзя. Подобные права доступа как раз наихудшим образом сказываются на безопасности, потому что дают возможность отредактировать любой скрипт на сайте и встроить маленький бэкдор в самый незаметный скрипт, принадлежащий CMS. Надежно избавиться от такого довеска можно будет только полной переустановкой CMS. Или можно загнать весь сайт в систему контроля версий, как предложил Максим Гречушников, и одной командой узнать какие скрпиты были заражены. Тем не менее, одно другое не исключает. Система контроля версий позволит выявить заражение постфактум, а нормальные права не дадут возможности заразить файл в принципе.

Я рекомендую на папки устанавливать права 755, а на файлы 644. При этом, владельцем всех папок и файлов должен быть кто угодно, но не пользователь, из-под которого запущен веб-сервер или php (например, пользователь, под которым вы сами заходите на сервер по ssh). Но такие права на всё устанавливать тоже нельзя. Сайт в процессе своей работы может генерировать свои временные файлы (например, кешировать что-то в файл, компилировать шаблоны, хранить какие-нибудь настройки), поэтому для папок, в которые сайт может что-то записать, права должны быть другие. Вот здесь уже можно ставить 777 для папок и 666 для файлов. Это довольно кропотливая работа, потому что у каждого сайта (особенно если они на разных CMS) свои папки и часто определение таких папок нетрвиально.

И права доступа не решают всех проблем. Злоумышленник может встроить вредоносный код в скомпилированный шаблон или отравить кеш. Тогда не помогут ни права (так как для нормальной работы сайту нужно иметь права на запись в такие файлы), ни система контроля версий (так как подобные файлы слишком часто меняются и, как правило, не хранятся в репозитории). Хотя надо сказать, этот способ внедрения сложнее и недолговечнее, чем встраивание в нормальный скрипт.

И ещё автоматическое обновление сайта перестанет работать. Если CMS позволяет обновить себя через кнопку в веб-интерфейсе админки, то такое обновление не будет работать, так как права доступа не разрешают веб-серверу модифицировать скрипты. Обновлять скрипты теперь можно только вручную от имени пользователя, которому принадлежат все файлы. Безопасность и удобство - разные концы одной палки.

Даже с учётом всех недостатков - нормально настроенные права доступа на файлы и папки значительно сокращают вектор возможных атак. Так что обязательно разберитесь с этим вопросом.

---

После раскидывания сайтов по своим папкам и настройки прав, необходимо ограничить доступ сайтов друг к другу. Проще всего это сделать настройкой php директивы open_basedir. Эта директива определяет список директорий, внутри которых (а так же во всех вложенных папках) скрипты могут читать и писать. Доступ за пределы этих директорий будет пресекаться. То есть нужно каждому сайту прописать в open_basedir путь к своей папке и к /tmp (если версия php < 5.5.0 и нельзя установить sys_temp_dir).

Для Apache с mod_php конфигурация прописывается в httpd.conf:

<VirtualHost *:80>
  ServerName example.com
  php_admin_value open_basedir /var/www/example.com/:/tmp/
  php_admin_value upload_tmp_dir /var/www/example.com/temp/
  php_admin_value sys_temp_dir /var/www/example.com/temp/
  php_value session.save_path /var/www/example.com/sessions/
</VirtualHost>

Для php-fpm в конец php.ini файла вписывается специальная секция, определяющая индивидуальную конфигурацию для каждого сайта:

[HOST=example.com]
open_basedir /var/www/example.com/:/tmp/
upload_tmp_dir /var/www/example.com/temp/
sys_temp_dir /var/www/example.com/temp/
session.save_path /var/www/example.com/sessions/

[HOST=toster.ru]
; конфиг для toster.ru и т.д.

У open_basedir есть недостатки:

1. Замедление файловых операций, так как необходимо проверить вхождение каждого открываемого файла в список open_basedir. Если проекты не highload, то некритично.
2. Есть варианты обхода. Но их далеко не всегда удаётся эксплуатировать. Тем более они закрываются со временем в новых версиях php.
3. Realpath cache не работает вместе с включенной open_basedir.

---

Есть вариант запускать каждый сайт от своего пользователя. В apache это делается опцией AssignUserId. В php-fpm - отдельной конфигурацией pool. Но в любом случае нужно для каждого сайта создавать не только отдельного юзера, но и группу. При этом права на основную папку сайта (/var/www/example.com) должны быть 750, а группа должна соответствовать той, от которой будет запускаться процесс apache (или пул php-fpm), ответственный за обслуживание сайта.

Проще показать на примере. После имени файла я буду указывать права, владельца и группу в формате (права, владелец:группа)

/var/www         (755, root:root)
  + toster.ru    (750, my_user:toster)
  |  + site      (755, my_user:toster)
  |  + sessions  (777, my_user:toster)
  |  + temp      (777, my_user:toster)
  + example.com  (750, my_user:example)
  |  + site      (755, my_user:example)
  |  + sessions  (777, my_user:example)
  |  + temp      (777, my_user:example)
  + остальные сайты - всё аналогично

my_user - это пользователь, под которым ни в коем случае нельзя запускать веб-сервер и php. Это может быть ваш собственный пользователь, под которым вы заходите на сервер по ssh. В этом случае у вас будут все права на сайт, а у сайта только необходимый минимум.

<VirtualHost *:80>
  ServerName example.com
  AssignUserId exapmle example
</VirtualHost>
<VirtualHost *:80>
  ServerName toster.ru
  AssignUserId toster toster
</VirtualHost>

Разумеется, в системе должны быть заранее созданы пользователи с именами toster, example и с одноимёнными основными группами.

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

---

Более сложным и предпочтительным вариантом является упаковка каждого сайта в свой отдельный виртуальный контейнер lxc/docker. Я не смогу в двух словах описать как это добро настраивать, но эффект будет такой, как будто каждый сайт работает на своём собственном VPS сервере.

---

Ещё немного про базу. Для доступа к базе у каждого сайта должен быть свой собственный логин с паролем. Причем, доступ должен ограничиваться исключительно той базой, в которой находятся данные сайта. И права должны быть не все подряд, а только SELECT, INSERT, UPDATE, DELETE. В редких случаях CMS может самостоятельно создавать таблицы для своих нужд в процессе своей работы (не в процессе первичной установки). В этом случае можно добавить права CREATE, ALTER, INDEX юзеру этого сайта. Иногда бывает в базе есть какие-то процедуры/функции. Для их вызова требуются права EXECUTE.

---

Безопасность - дело большое и очень разнообразное. И уж точно не простое. Всё что я здесь написал - это далеко не полный список. Есть ещё настройки уровня операционной системы (особенно фаервол) и прочего установленного в системе софта. Так же отдельным пунктом идёт система мониторинга и оповещения, которые почему-то никто не делает - не считают нужным разбираться ещё и в этом. Так что если у вас нет хорошего админа в запасе, то проще будет заказать услугу администрирования прямо у того же хостера, у которого вы арендуете VPS. Или найти админа-фрилансера. Или же перевезти сайты на shared хостинг, где администрирование уже включено в ценник, да и сам переезд хостеры часто предлагают сделать бесплатно силами своих админов.