- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году Одноклассники пресекли более 9 млн подозрительных входов в учетные записи
И выявили более 7 млн подозрительных пользователей
Оксана Мамчуева
Как удалить плохие SEO-ссылки и очистить ссылочную массу сайта
Применяем отклонение ссылок
Сервис Rookee
Вопрос был в запрете CGI, а не в запрете Perl. Это понятно, что есть PHP shell_exec, но, опять же, как показывает практика до этого редко кто снизосходит, видимо, найти ломаный акк, где открыт CGI, проще, чем усложнять себе жизнь.
Это понятно, что есть PHP shell_exec, но, опять же, как показывает практика до этого редко кто снизосходит
Если вспомнить все основные проблемы с которым столкнулся, то всё таки CGI это чаще всего для спама, irc и что то подобное применялось. А вот по поводу PHP shell_exec не могу сказать ничего хорошего, на общем хостинге он должен быть закрыт.
WHMCS у меня пытаются ломать 1-2 раза в день, большинство айпи саудовская аравия, некоторые - пакистан, подсети разные, где-то адсл, где-то wimax. Приходят в основном из google.com.sa. Все они пытаются использовать одну и ту же уязвимость WHMCS, которая позволяет запустить php-код, внедряемый в заголовок отправляемого тикета. Уязвимость была ликвидирована патчем ещё в октябре, а атаковать стали не более месяца назад.
Так вот для чего этот патч был :) У нас тоже ломали,ломали и недоламали :p
А вот по поводу PHP shell_exec не могу сказать ничего хорошего, на общем хостинге он должен быть закрыт.
Вопрос к знатокам. Сервер с cPanel, php работает как suphp. shell_exec и другие вкусные функции закрыты, но клиент может создать собственный php.ini, и отменить эти запреты. Насколько это чревато боком, и что можно предпринять для дополнительной защиты? Я знаю, что можно запретить создание собственного php.ini, но иногда клиентам требуются определённые директивы, которые в .htaccess не работают при suphp.
Вопрос к знатокам. Сервер с cPanel, php работает как suphp. shell_exec и другие вкусные функции закрыты, но клиент может создать собственный php.ini, и отменить эти запреты. Насколько это чревато боком, и что можно предпринять для дополнительной защиты? Я знаю, что можно запретить создание собственного php.ini, но иногда клиентам требуются определённые директивы, которые в .htaccess не работают при suphp.
Apache mpm-itk c mod_php
Сервер с cPanel, php работает как suphp. shell_exec и другие вкусные функции закрыты
На сервере с cPanel csf очень желателен, так как cPanel конфиги сама меняет, если что то делать не через WHM. С помощью csf очень быстро оценить реальную ситуацию на сервере.
но клиент может создать собственный php.ini, и отменить эти запреты. Насколько это чревато боком, и что можно предпринять для дополнительной защиты? Я знаю, что можно запретить создание собственного php.ini, но иногда клиентам требуются определённые директивы, которые в .htaccess не работают при suphp.
Лучше в основном php.ini всё решать, но напрягает лишние вопросы к поддержке, значит делаем компромис и бэкапы....
Вопрос к знатокам. Сервер с cPanel, php работает как suphp. shell_exec и другие вкусные функции закрыты, но клиент может создать собственный php.ini, и отменить эти запреты. Насколько это чревато боком, и что можно предпринять для дополнительной защиты? Я знаю, что можно запретить создание собственного php.ini, но иногда клиентам требуются определённые директивы, которые в .htaccess не работают при suphp.
Здравствуйте!
При правильной настройке suphp - не может клиент изменить php.ini Достаточно воспользоваться штатными средствами cPanel и держать php.ini за пределами аккаунта пользователя. Но вам придется настраивать клиентский php.ini в соответствии с запросами от клиентов.
Apache mpm-itk c mod_php
не панацея, даже при отключенном cgi
возможно cloud linux как решение но тоже сомневаюсь что не найдут какую нибудь дыру и не взломают
Всем спасибо за ответы. CSF и CloudLinux уже имеются. С mpm-itk + mod_php буду экспериментировать позже.
rustelekom, спасибо что наставили на путь истинный, это то что и требовалось =)
не панацея, даже при отключенном cgi
Ну почему же?
cgi тут вообще ни как не мешает, т.к. апач с патчем mpm-itk, перед тем как выполнить скрипт, делает форк под пользователя которому принадлежит данный скрипт и только потом передаёт его интерпритатору на выполнение.
Это относится не только к php скриптам, но и любым другим, которые запускаются через веб, т.е. через апач.