Безопасность вашего сайта в ваших руках

Тема закреплена

Безопасность вашего сайта в ваших руках

#1 27 июня 2013 в 17:43
1. Правильно выставите права доступа на файлы и папки.

а. Выставите на все папки права 755 (кроме тех, в которые должны быть разрешена запись)
б. Выставите на (/cache, /images,/upload) и вложенные в них папки права 777
в. На все остальные файлы выставите права 644
г. учитывать владельца файлов и директорий
2. Если есть необходимость привлечения стороннего разработчика

1. Создавайте временные аккаунты для доступа по FTP
2. Создавайте временные аккаунты для доступа к административной панели
3. После исполнения обязательно выключите или удалите или смените пароли
(если нет возможности создать таковые, обязательно смените пароли)
3. Всегда перед тем как проводить любые действия над сайтом делайте резервную копию(база+файлы)

Да и вообще делайте это минимум 1 раз в неделю. Если у Вас большая посещаемость, то 1 раз в сутки.
Время для бэка выставите в моменты минимальной нагрузки.
4. Пользуйтесь антивирусной программой

Минимум freeAvast
5. Не используйте ломанные компоненты для instantcms

Большая вероятность наличия шелов, бэкдюров
6. При выборе исполнителя проверьте портфолио.

Наведите справки об исполнителе. Почитайте отзывы.
7. С осторожностью относитесь к разработкам размещенных не на официальном сайте.

При поиске компонентов, плагинов, модулей убедитесь, что вы покупаете именно у автора.
8. Будьте внимательны к бесплатным шаблонам

Пролистайте бесплатный шаблон на наличие ссылок на сторонние сайты, это может стать утечкой трафика
Уважаемые коллеги, если есть что добавить, то напишите в данном посте ниже.
Если вы увидели, что ваш совет добавлен не поленитесь затрите ваше сообщение. Спасибо.
#2 27 июня 2013 в 21:23
Работайте с теми, у кого есть портфолио (или блог тут), у кого есть репутация, карма, так как риск потерять ее гораздо выше мимолетной прибыли от вреда вам.
#3 29 июня 2013 в 15:18
Не упомянута основная причина взлома многих сайтов, которая и на офф. сайте проскакивала много раз )
Не сохраняйте пароли в фтп менеджерах!
Вне зависимости от того, стоит антивирусник на локальном компе или нет.
И второе, так как многие держат свои сайты на дедиках или VPS, то безопасность ваших сайтов в очень большой степени зависит от настроек вашего сервера. Я не спец по безопасности, но вкратце могу сказать следующее:
1.Для каждого сайта нужно заводить отдельного юзера unix, состоящего в отдельной группе; Файлы сайта должны принадлежать этому юзеру и должны лежать в его доамашней директории.
2. Демоны апача, пхп не должны запускаться от пользователя root. Лучше, завести под каждого отдельного юзера и отдельную группу. Чтобы скрипты работали корректно, достаточно добавить владельца демона в группу владельца файлов сайта. И тогда для того, чтобы разрешить запись в нужный файл или папку, достаточно установить права 775. Что конечно же безопаснее 777. Возможно про это говорил stealthdebuger. Если я ошибаюсь, интересно было бы послушать специалиста, как нужно )
3. Настройки chroot для юзера unix. Доступ не выше домашней директории.
4. Директива open_basedir — запирать скрипты в домашней директории.
Ну и наверно еще что-то. Я ведь не спец )))
#4 29 июня 2013 в 15:36
Закрыть дополнительным паролем папку admin
#5 29 июня 2013 в 16:40

а. Выставите на все папки права 755 (кроме тех, в которые должны быть разрешена запись) б. Выставите на (/cache, /images,/upload) и вложенные в них папки права 777 в. На все остальные файлы выставите права 644

Димитриус
Прежде чем это утверждение, принимать это основное решение — надо БУКВАЛЬНО ЗНАТЬ УСЛОВИЯ ПРЕДОСТАВЛЕНИЯ ПРАВ ХОСТЕРА.
Что може явиться неправильным — в этом случае?
Большинство в целях безопастности уже изначально — ПРИНУДИТЕЛЬНО устанавливают права 755 на директории. И 644 на файлы. И изменение одной директории с прав 755 на 777 повлечет полную неработоспособность скрипта.Это также касается любого изменения прав на файл-644 (ПРАВИЛА касаются -ТОЛЬКО ВИРТУАЛЬНЫХ ХОСТИНГОВ).
Надо четко обозначить и принять определенное правило касающееся ПРАВИЛ ПРАВ НА ДИРЕКТОРИИ И ФАЙЛЫ.

Если хостер обозначил права НЕ ИНАЧЕ 755 на директории и 644 на файлы- не надо ничего менять.
Приемлемо как — только исключительные решения, в зависимости о ПРОФЕССИОЛТИЗМА услуг виртуального хостинра.
#6 29 июня 2013 в 16:52


Не упомянута основная причина взлома многих сайтов, которая и на офф. сайте проскакивала много раз )
Не сохраняйте пароли в фтп менеджерах!

Марат

Это далеко не основная причина взлома сайтов на инстанте.
Единственное, с чем могу согласиться — в большей части случаев виноваты сами владельцы сайтов.
#7 29 июня 2013 в 19:06
stealthdebuger, пост поправили — не смогли повторить при правильных правах или всё же смогли и поэтому?
#8 29 июня 2013 в 19:22


stealthdebuger, пост поправили — не смогли повторить при правильных правах или всё же смогли и поэтому?

lokanaft

Хм… Если вы успели увидать мое сообщение, то заметили, видимо, и оговорку, что требуются еще и другие условия для того, чтобы вариант сработал.
Кроме того да, при правильных правах и владельцах (тот же файл .htaccess от рута) сделает всякие попытки тщетными.

P.S. Смысл же редактирования моего поста был в том, чтобы не давать иллюзорных надежд горе-хацкерам, которые сразу побегут проверять информацию.
#9 29 июня 2013 в 19:50

Кроме того да, при правильных правах и владельцах (тот же файл .htaccess от рута) сделает всякие попытки тщетными.

stealthdebuger
stealthdebuger -это ВАШ КАРТ ВЛАНШ.Пожалуйста, разьясните принципиально основную теорию защиты сайтов от определенного фактора уязвимостей.
Я предлагаю ВАМ как профессионалу, создать блог в котором Вы сможете поделиться своими многолетними знаниями в плане безопастности исполняемых скриптов.В Вашем варианте достаточно преподнести тему как Общая.В итоге Вы имеете неоспоримое преимущество и интерес к теме:
1-эта тема ОЧЕНЬ НУЖНА сторонним разработчикам дополнений в виде модулей, плагиной, компонентов.
2-именно малый процент разработчиков являются профессионалами.В ЛЮБИТЕЛЬСКОМ итоге мы имеем ВСЕ взломы по совершенно правильным (классическим) понятиям.Разработчик дополнений в ICMS в большей степени, это саморазвивающийся програмист, и не более.Уровень соотношения качества кода к знаниям, иногда имеет противоречия.
Кто как не ВЫ в данной ситуации сможете обозначить прямые условия правильного кодирования.
Сверх задача? Просто делитесь опытом, если жаба не жмет.Это называеться прогрессом личности- учите! И МЫ — ученики, ВАМ только благое будем вешать.
#10 29 июня 2013 в 20:34
Присоединяюсь к пожеланиям Oll, тоже интересно было бы почитать )
Кроме того, интересно было бы услышать рекомендации аудита безопасности, проведенные для icms. Что-то сами заметили — csrf-токены, модификаторы escape, удаление коннекторов в fck-едиторе… Наверняка же, ещё есть много чего…
Понятно, что не все используют, но кому то же поможет сделать свой код более безопасным.
Согласен с Олей, профессионалов-кодеров(именно программистов по образованию или близких по професии) среди разработчиков расширений очень мало. R2, Максисофт(отошел от icms) — я больше и не знаю smile
Почти все мы самоучки, да и опыт то небольшой — всего то пару лет, и то без отрыва от производства.
В целом, если бы была какая-то тема на форуме или может блог, где можно было бы обсуждать, послушать, учиться — как нужно писать и как не нужно- это было бы очень даже полезно в целом для сообщества, ну и для нас тоже ) Возможно даже обсуждение в закрытом режиме.
Интересно не только про безопасность, но и про произодительность, быстродействие… И вообще качество кода.
Честно, во многом учусь у Fuze, его код легко читается. Что ни говори, хотя он и говорит, что не профессионал, есть талант у человека. Как то, умеет он просто и красиво писать.
Писать то всё равно будем laugh. Сколько раз не пытался переключиться на другое, тянет на php и всё. Засядет в голове какая идея, и пока не реализуешь, тараканы в голове не дают покоя.
Ну и, хотелось бы и красиво кодить.
#11 29 июня 2013 в 20:54
Димитриус,

Честно, во многом учусь у Fuze, его код легко читается. Что ни говори, хотя он и говорит, что не профессионал, есть талант у человека. Как то, умеет он просто и красиво писать.

Марат
Это ТАЛАНТ, и я oll с него беру пример.
#12 29 июня 2013 в 21:30
Марат, oll, спасибо.

учусь у Fuze, его код легко читается

Марат
я учился у R2, именно благодаря ему я изучил php. Частные уроки не даем)

В целом, я уверен, что имея желание, задавая правильные вопросы (а зачастую правильно заданный вопрос несет в себе ответ) и изучая оф документацию можно изучить любой язык программирования. Нужно садиться и разбираться, ну и в случае вопросов искать кому бы их задать)
По мануалам безопасности: дело в том, что подобные публикации имеют обратную сторону. Где вероятность, что человек, читающий разбор безопасности InstantCMS будет использовать данную информацию для своего развития, а не для руководств к действию.
Поэтому в данном случае думаю максимум что возможно — это попросить написать некий пост, охватывающий в целом безопасное написание php кода, не в контексте бывших уязвимостей InstantCMS. Далеко не все исходя из патчей смогут сделать PoC.
#13 30 июня 2013 в 13:53

В целом, если бы была какая-то тема на форуме или может блог, где можно было бы обсуждать

Марат

Одну сторону озвучил Fuze постом выше, вторую сторону я могу продемонстрировать наглядно instantcms.ru/blogs/nash-instantcms/komponent-rasylki-dlja-instantcms-instantmailer-v0-0-7.html#comment_57766
Это весьма неблагодарное дело. Тратится тьма личного времени на анализ кода, тестирование, описание найденной проблемы и рекомендации по устранению, а в ответ чаще всего слышишь ругань, упреки и фразы по-типу "сам дурак". smile

P.S. Если озвученный вопрос будет действительно интересен многим, я могу выложить несколько своих рассуждений, но предпочту это сделать на специализированом форуме, в отведенной для ICMS ветке. joke
#14 30 июня 2013 в 14:32

вторую сторону я могу продемонстрировать наглядно

stealthdebuger

Я почему то уверен, что такая проблема практически у всех разработок. Но вот механизма, для контроля нет.
#15 30 июня 2013 в 14:52

предпочту это сделать на специализированом форуме

stealthdebuger
поделитесь, где этот форум?
Вы не можете отвечать в этой теме.
Войдите или зарегистрируйтесь, чтобы писать на форуме.
Используя этот сайт, вы соглашаетесь с тем, что мы используем файлы cookie.