- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
hvosting, я не называл хостера аникейщиком, а только исключительно того человека кто ответственен был за конкретный сервер.
Не думаю, что у них 1 человек заведует всем хостерским отделом.
hvosting, я не называл хостера аникейщиком, а только исключительно того человека кто ответственен был за конкретный сервер.
Не думаю, что у них 1 человек заведует всем хостерским отделом.
Я думаю что сервера у них не выпиливаются индивидуально напильником, а штампуются по шаблону. И что версии библиотек и ядра на серверах б-м совпадают и время от времени апдейтятся.
Вообще, эта ситуация похожа на то, что когда юзер покупает комп с лицензионным виндусом и первым делом отключает авто апдейты (или наоборот не включает их), а потом вызывает спеца за бабки, который очищает его бедный виндус кишмя кишащий вирусами. Что мешает поставить авто апдейт, который в 90% случаев предотвратит проникновение вируса, мне лично, не очень понятно.
Все равно что установленный антивирус никогда не обновляется после установки. Толку от такого антивируса через 3 месяца - ноль.
Так чем авто апдейт до стабильных версий так плох? Зачем личное участие админа в этом процессе?
Это каким же образом? Допустим, стандартная настройка httpd работает от nobody + suEXEC + suPHP. Все обновлено до последних стабильных версий.
Как можно получить доступ к другому аккаунту хотя бы на чтение?
Не всё так красиво как кажется в таком конфиге. У нас cPanel тоже так работает уже шетсь лет, но как то мы сами начали анализировать и оказалось что такой конфиг взломать ещё проще если уровень взломщика достаточно высокий. То есть, банальный mod_php фактически более безопасный, если пользоатель грамотный, а производительность выше примерно раз пять. Дополнительно если взломали акаунт с suPHP, то самому этому акаунту возможен полный каюк....
А по теме - это очередной раз когда безграмотные пользователи пострадали из за своей неграмотности. Ну на сколько надо быть тупому, чтоб оставить возможность для апача редагировать файлы? Сами виноваты, хостёр тут не причём. Права на файлы которые доступные только на чтение 644, на папки 755, на недоступные на чтение 600 и 700 и ваш акаунт будет жить спокойно.
авто апдейт, который в 90% случаев предотвратит проникновение вируса,
То есть антивирусы придумали слабоумные люди и они никак не нужны? То есть в Вашем случае автоапдейт спасает? Давайте еще брандмауэр включим.. действительно, зачем нам антивирусы..
но как то мы сами начали анализировать и оказалось что такой конфиг взломать ещё проще если уровень взломщика достаточно высокий. То есть, банальный mod_php фактически более безопасный, если пользоатель грамотный, а производительность выше примерно раз пять.
На производительность многие ведутся и приводит это к плачевным результатам.
LineHost, не могли бы вы дать ссылочку описывающую, что suPHP менее безопасен чем mod_php.
К стати, рассчитывать на грамотного юзера не приходится.
Дополнительно если взломали акаунт с suPHP, то самому этому акаунту возможен полный каюк....
Это вполне допустимо, т.к. залезли в него не из-за взлома системы привилегий или suPHP.
То есть антивирусы придумали слабоумные люди и они никак не нужны? То есть в Вашем случае автоапдейт спасает? Давайте еще брандмауэр включим.. действительно, зачем нам антивирусы..
Антивирус вещь полезная, когда он обновляется постоянно. Но он так же многое не ловит. Есть же ситуации, когда антивирус ничего не поймал, а от взлома системы спасло то, что в этой библиотеке нет той дыры, на которую вирус рассчитан.
Ну на сколько надо быть тупому, чтоб оставить возможность для апача редагировать файлы? Сами виноваты, хостёр тут не причём. Права на файлы которые доступные только на чтение 644, на папки 755, на недоступные на чтение 600 и 700 и ваш акаунт будет жить спокойно.
а если движком задумано, что в нем должна быть возможность апачу редактировать файлы?
За безопасностью своего аккаунта должен следить сам юзер, а то что имея юзерский доступ - можно похакать весь сервер, это жесть конечно.
не могли бы вы дать ссылочку описывающую, что suPHP менее безопасен чем mod_php.
Защита (как верно ранее заметили) должна быть комплексная, другое дело, что на базе suPHP (но именно на базе, а не за счёт исключительно разницы в режимах) построить более безопасную среду намного проще (безопасную для всего сервера, но да, к сожалению не для того аккаунта, который был взломан). Как минимум нужно сделать (но именно при использовании suPHP):
1) Отключаем глобально в php.ini ВСЕ ф-ции, кои могут быть использованы для повышения прав (exec, system и т.д.)
2) Ограничиваем путь, по которому апач будет искать php.ini (дабы не было возможности загрузить свой php.ini с разрешёнными ф-циями)
3) Используем CloudLinux + CageFS + Grsecurity (разграничение доступа процессов пользователя к системной среде ОС)
4) Используем mod_security (с правилами соответствующими)
п.с. но сам по себе suPHP ненамного более безопасен, чем любой другой режим (если в системе есть публично известные уязвимости в ядре, той же glibc и т.д. повысят привилегии и вперёд с песней)
а если движком задумано, что в нем должна быть возможность апачу редактировать файлы?
Включаем мозг и думаем, перед тем как писать такой коментарий.... Обычно апачу надо иметь права записи на один - два файла, так зачем разрещить на все? Я не знаю ни одного движка, который требовал бы право записи на index.php. Типично, ламеры заливают на акаунт файлы и чтоб было проще на все махом 777.
За безопасностью своего аккаунта должен следить сам юзер, а то что имея юзерский доступ - можно похакать весь сервер, это жесть конечно.
Не весь сервер, а тех у которых нет ума. Нормального пользователя на том же сервере ни кто не укусит. Дураков и в церкви бьют.... :)
Включаем мозг и думаем, перед тем как писать такой коментарий.... Обычно апачу надо иметь права записи на один - два файла, так зачем разрещить на все? Я не знаю ни одного движка, который требовал бы право записи на index.php. Типично, ламеры заливают на акаунт файлы и чтоб было проще на все махом 777.
ну не в index.php запишут, а файл конфига, файл шаблона и т.п. - часто нужно иметь возможность править в админке. какая разница, куда будет вставлен вредоносный скрипт...