- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Ну кто спорит, ага. Но случае PHP, программистов все еще хуже (phpmyadmin, wordpress и проч.), писал "аудит безопасности" сквозь слезы :)
Pavel.Odintsov добавил 04.12.2010 в 13:35
Вообще, из административно-программистских мер могу посоветовать сходу:
1) Ежедневный / ежечасный бэкап или репликация на удаленную машину. Так как возможно, что уничтожат / испортят базу.
2) Частые бэкапы файлов сайта
3) Перевод системы авторизации с паролей в чистом (если, конечно, в 21м веке такое еще живет) виде на хеши (обязательно с salt), чтобы красть / подбирать к ним пароля было бессмысленнно + ужесточение политики использумых пользователями паролей.
Ну и в целом, лучше такой проект выселить на VPS в гордое одиночество, ибо от чрута.... толку чуть менее чем нету совсем, если fastcgi процессы / апач работают вне чрута.
А нанятые прогеры не могут выполнить аудит безопасности? Если это не шоп / партнерка, то, подозреваю, что это простой сайт с не шибко сложным движком, которому аудит безопасности можно провести за несколько дней. Но с таким подходом к найму, что прошлый программер "кинул", лучше и новым двум особенно не доверять, а отдать независимой конторе, которая выполнит аудит.
шефу я уже это предложил. он выбирал проггеров.
думает пока что.
с админской точки зреня я как админ вроде навертел что мог, анализ логов тоже поставил.
pupseg добавил 04.12.2010 в 15:28
про впс - тоже хорошая идея... уже думаю над этим. сайту хватит 2000мгц и 4гб рам и 20гб места.
прялка хостовая - мощная.
Ваши меры спасут от заливания какого-нибудь шелла, но не спасут от sql-injection с DROP DATABASE ...
От инъекции спасут пряморукие программеры :)
От инъекции спасут пряморукие программеры :)
пряморукие программеры - это миф
Ваши меры спасут от заливания какого-нибудь шелла, но не спасут от sql-injection с DROP DATABASE ...
я это понимаю. вот сидят размышляют два проггера.
я вообще подумал - что нах паниковать.
просто грамотно собирать логи и айпи адреса.
потом собрав все это, если произойдет беда - просто заявление в милицию, да и все.
я это понимаю. вот сидят размышляют два проггера.
я вообще подумал - что нах паниковать.
просто грамотно собирать логи и айпи адреса.
потом собрав все это, если произойдет беда - просто заявление в милицию, да и все.
ага... и наша доблестная милиция с радостью кинется писать письма владельцам уругвайского прокси :D
;8121109']ага... и наша доблестная милиция с радостью кинется писать письма владельцам уругвайского прокси :D
ну это тоже верно.
на данный момент - со стороны "виновника" было только "грозное письмо" шефу. что мол так и так, не заплатите - я все обвалю.
вот принимаем меры.
pupseg, вопрос... скорее к телепатам
от куда тут знают то, что там сделал тот программист?
"дырка" - может быть разная...
например, можно скрыть часть исходников или все (разными способами), и там поставить API которое будет принимать что угодно...
почему программист имет доступ на Ваш оригинальный сервер? надо было поставить тестовый сервер?!
почему бы не откатить бэкап (бэкап исходников) до того как ваш программист имел доступ на сервер? и проблемы не будет!!
ЗЫ: кстати, mod_security может скрыть множество дыр
ЗЫЫ: вообще, можно посмотреть внимательно код, и проанализировать возможность SQL-инъекции... если там ORM стоит, SQL-инъекции не будет...