Офис НП AMWAY в Ярославле
→ На карте Купить AMWAY в ЯрославлеПриобрести высококачественную продукцию Амвей в Ярославле, получить консультации по бизнесу, заказать продукцию или получить заказ:
●Адрес: улица Валентины Терешковой, дом 1 (Вход со двора)
●Телефон: +7 (920) 112-00-91
●Email: matyxho@mail.ru
●Сайт: https://www.amway.ru/user/lebedem
●Визитка: http://yar.meweb.ru
Иерархия статей
Статьи » Безопасность » Способы и методы защиты: взгляд непрофессионала
Сниппет
Попробуем рассмотреть основные методы и способы защиты от взлома и его предотвращение. Я не являюсь профессионалом в данной области, все приведенные рекомендации ты можешь использовать, а можешь положить на них "с пробором"
Способы и методы защиты: взгляд непрофессионала
Что ж, для начала- превентивные меры по предотвращению взлома сайта, самые азы, так сказать.
— Всегда старайся обращать внимание на даты изменения файлов/ каталогов. Это не убережет тебя от профи, который выбрал именно твой сайт, так как, как уже писалось в предыдущей статье, дату последнего редактирования можно подделать, либо изменить файл следом за тобой, дабы ты не заметил подвоха. Но от автоматического взлома это спасет: боты- программы еще, к счастью, не обладают интеллектом и не могут предусмотреть всего. Особенно старайся обращать внимание на дату последнего изменения файла .htaccess.
— CHMOD ( права на папки и файлы) - следите, чтобы данный параметр был настроен правильно. Рекомендуемые права на папки и файлы, в которые не идет запись- 755 и 644 соответственно. На папки и файлы, в которые идет запись- 777 и 666 соответственно. Почему я это упомянул? Потому что это, в принципе, важно: иногда мы сами помогаем хакеру, забывая о важности чмод, сами того не ведая... На важные конфигурационные файлы можно ставить права 600.
— Старайся как можно чаще проверять сервер на наличие посторонних файлов, а так же сами файлы на наличие постороннего кода. И будет вообще прекрасно, если ты время от времени, ручками и глазками, будешь просматривать БД на наличие однозначно ненужных вкраплений: как показывает практика, именно в БД может сидеть троян, и это, в общем, весьма логично.
— Возьми себе за правило просматривать логи. Да-да, это те самые текстовые файлы, которые хранятся в папке logs ( у тебя может называться по-другому). Ищи непонятные запросы, вызов левых файлов, попытки входа в админку: последнее сопоставляй со своими посещениями и делай выводы... Обращай внимание на GET- запросы: их частоту, рефереры и т.п..
— Если у тебя пабличная CMS- регулярно посещай форум официального разработчика, следи за новостями и делай обновления. Для чего нужны обновления? Чаще всего, разработчиками в обновлениях закрываются найденные уязвимости, именно поэтому так важно быть всегда в курсе.
— Обращай внимание на количество входящего/ исходящего трафика. Если эта цифра вдруг, ни с того, ни с сего, резко увеличилась- думаю, есть повод задуматься.
— Если позволяют знания- напиши сам, если нет- обратись к кодеру для написания простого скрипта/ программы оповещения о редактировании файлов. Принцип простой: произошло несанкционированное изменение файла- ушло сообщение тебе на мыло или по смс. Можно банально проверять файлы на размер: увеличился на пару байт- пошел "стук".
Вот тебе один из таких скриптов- Fchecker v2.1, он, конечно, не спасет тебя от профессионального взлома, но вовремя выявить шелл вполне способен.
— Старайтся как можно чаще посещать ЯндексВебмастер и ВебмастерГугл, в которых ты тоже найдешь инструменты для мониторинга своего проекта: следи за резкими перепадами в посещаемости, сканируй страницы на предмет вредоносного кода.
— Обязательно загляни в файл .htaccess- в нем могут быть добавлены перенаправления на другие сайты, распространяющие вирус. При этом файл .htaccess может быть размещен как в корне сайта, так и выше, поэтому не поленись посмотреть все директории аккаунта. Также в нем может быть не только перенаправление на сайт, но и команда для обработки произвольного расширения файла как php скрипта, что даёт нам в каталоге с изменённым .htaccess шелл с расширением изображения.
— Может быть, прозвучит смешно, но довольно большая часть взломов происходит путем простого подбора пароля от админки или FTP. Поэтому, всегда ставь серьезные пароли на любой вход в защищенную зону. Пароль вида vasya1234- изначально потенциально угрожает безопасности, достаточно будет воспользоваться банальным брут'ом. Используй комбинированные пароли: чередующиеся заглавные и маленькие буквы, цифры. Время от времени меняй логины и пароли.
— Ну и самый тривиальный способ- обратиться к специалистам. Правда, это может обойтись тебе в солидную сумму и, опять же, никто не даст 100% гарантии, что сайт абсолютно безопасен.
Здесь я могу дать лишь общие рекомендации о защите после взлома. Итак, основные наши действия:
— Тебе не повезло и ты, к своему горю, все-таки обнаружил шелл на своем детище. Только не спеши его удалять! Это ты всегда успеешь, ведь уязвимость уже существует. Сделай листинг, проще говоря- скопируй исходный код файла и сохрани у себя на компьютере- не бойся, если это .php- файл, твоей железке ничего не грозит, для исполнения файла нужна среда, в данном случае- интерпретатор php. Для чего это нужно? Ну хотя бы погуглишь потом, возможно, твоя проблема уже давно решена. Далее- можно будет обратиться с заявлением в правоохранительные органы, но по этому вопросу- на сайт юристов, я далек от этой темы.
— По логам ищешь уязвимость: когда был загружен шелл, где был загружен( само уязвимое место), с какого IP к нему были обращения. Понимаю, что все это сложно и долго- но такова селяви, как говорят у них...
— Что ж, предположим, тебе повезло и ты нашел уязвимое место и благополучно закрыл его. Далее- устанавливаешь бекап с закрытой уязвимостью, а в идеале- чистый дистрибутив! Важный момент: если бекап лежал на пораженном сервере, есть вероятность, что хакер сделал в нем еще парочку дыр- на будущее, так сказать. Поэтому настоятельно рекомендую хранить бекапы на локальной машине! Едем далее.
— Устаналиваешь бекап базы данных. Внимание! Бекап БД должен быть датирован ДО ДАТЫ ВЗЛОМА, потому что, как показывает последняя практика, вполне вероятно, что троян может находиться в самой БД ! Если же восстановить базу данных до даты проникновения не представляется возможным, тогда надеваешь очки, наливаешь пару литров кофе- и поехал искать вредоносный код в базе вручную... Бекдор ( backdoor) в БД- это, к сожалению, уже не фантастика, а реалии жизни...
— Не забудь проверить свою локальную машину антивирусом: возможно, твои данные были банальным образом стянуты через FTP- клиент.
— Обязательно сменить ВСЕ пароли! Не забывай, что хакер имел доступ ко всем твоим файлам, сомневаюсь, что старый твой пароль в md5 будет для него преградой...
— Ну и маленький совет на будущее от меня лично: фильтруй данные не только при записи в базу данных, но и при их извлечении!
Пока на этом все, май френд. Осознаю, что раскрыл далеко не все аспекты, что осталась еще гора вопросов технического плана. Я постараюсь продолжить подобные публикации, и, возможно, освещу основные моменты в ближайшее время. Ну а пока- всего доброго, удачи тебе и спокойного крепкого сна, без боязни проснуться с надписью HACKED BY MEGACOOLHACKERS, иже ей подобной.
Если тебя еще не похакали
— Всегда старайся обращать внимание на даты изменения файлов/ каталогов. Это не убережет тебя от профи, который выбрал именно твой сайт, так как, как уже писалось в предыдущей статье, дату последнего редактирования можно подделать, либо изменить файл следом за тобой, дабы ты не заметил подвоха. Но от автоматического взлома это спасет: боты- программы еще, к счастью, не обладают интеллектом и не могут предусмотреть всего. Особенно старайся обращать внимание на дату последнего изменения файла .htaccess.
— CHMOD ( права на папки и файлы) - следите, чтобы данный параметр был настроен правильно. Рекомендуемые права на папки и файлы, в которые не идет запись- 755 и 644 соответственно. На папки и файлы, в которые идет запись- 777 и 666 соответственно. Почему я это упомянул? Потому что это, в принципе, важно: иногда мы сами помогаем хакеру, забывая о важности чмод, сами того не ведая... На важные конфигурационные файлы можно ставить права 600.
— Старайся как можно чаще проверять сервер на наличие посторонних файлов, а так же сами файлы на наличие постороннего кода. И будет вообще прекрасно, если ты время от времени, ручками и глазками, будешь просматривать БД на наличие однозначно ненужных вкраплений: как показывает практика, именно в БД может сидеть троян, и это, в общем, весьма логично.
— Возьми себе за правило просматривать логи. Да-да, это те самые текстовые файлы, которые хранятся в папке logs ( у тебя может называться по-другому). Ищи непонятные запросы, вызов левых файлов, попытки входа в админку: последнее сопоставляй со своими посещениями и делай выводы... Обращай внимание на GET- запросы: их частоту, рефереры и т.п..
— Если у тебя пабличная CMS- регулярно посещай форум официального разработчика, следи за новостями и делай обновления. Для чего нужны обновления? Чаще всего, разработчиками в обновлениях закрываются найденные уязвимости, именно поэтому так важно быть всегда в курсе.
— Обращай внимание на количество входящего/ исходящего трафика. Если эта цифра вдруг, ни с того, ни с сего, резко увеличилась- думаю, есть повод задуматься.
— Если позволяют знания- напиши сам, если нет- обратись к кодеру для написания простого скрипта/ программы оповещения о редактировании файлов. Принцип простой: произошло несанкционированное изменение файла- ушло сообщение тебе на мыло или по смс. Можно банально проверять файлы на размер: увеличился на пару байт- пошел "стук".
Вот тебе один из таких скриптов- Fchecker v2.1, он, конечно, не спасет тебя от профессионального взлома, но вовремя выявить шелл вполне способен.
— Старайтся как можно чаще посещать ЯндексВебмастер и ВебмастерГугл, в которых ты тоже найдешь инструменты для мониторинга своего проекта: следи за резкими перепадами в посещаемости, сканируй страницы на предмет вредоносного кода.
— Обязательно загляни в файл .htaccess- в нем могут быть добавлены перенаправления на другие сайты, распространяющие вирус. При этом файл .htaccess может быть размещен как в корне сайта, так и выше, поэтому не поленись посмотреть все директории аккаунта. Также в нем может быть не только перенаправление на сайт, но и команда для обработки произвольного расширения файла как php скрипта, что даёт нам в каталоге с изменённым .htaccess шелл с расширением изображения.
— Может быть, прозвучит смешно, но довольно большая часть взломов происходит путем простого подбора пароля от админки или FTP. Поэтому, всегда ставь серьезные пароли на любой вход в защищенную зону. Пароль вида vasya1234- изначально потенциально угрожает безопасности, достаточно будет воспользоваться банальным брут'ом. Используй комбинированные пароли: чередующиеся заглавные и маленькие буквы, цифры. Время от времени меняй логины и пароли.
— Ну и самый тривиальный способ- обратиться к специалистам. Правда, это может обойтись тебе в солидную сумму и, опять же, никто не даст 100% гарантии, что сайт абсолютно безопасен.
Если сайт уже взломан
Здесь я могу дать лишь общие рекомендации о защите после взлома. Итак, основные наши действия:
— Тебе не повезло и ты, к своему горю, все-таки обнаружил шелл на своем детище. Только не спеши его удалять! Это ты всегда успеешь, ведь уязвимость уже существует. Сделай листинг, проще говоря- скопируй исходный код файла и сохрани у себя на компьютере- не бойся, если это .php- файл, твоей железке ничего не грозит, для исполнения файла нужна среда, в данном случае- интерпретатор php. Для чего это нужно? Ну хотя бы погуглишь потом, возможно, твоя проблема уже давно решена. Далее- можно будет обратиться с заявлением в правоохранительные органы, но по этому вопросу- на сайт юристов, я далек от этой темы.
— По логам ищешь уязвимость: когда был загружен шелл, где был загружен( само уязвимое место), с какого IP к нему были обращения. Понимаю, что все это сложно и долго- но такова селяви, как говорят у них...
— Что ж, предположим, тебе повезло и ты нашел уязвимое место и благополучно закрыл его. Далее- устанавливаешь бекап с закрытой уязвимостью, а в идеале- чистый дистрибутив! Важный момент: если бекап лежал на пораженном сервере, есть вероятность, что хакер сделал в нем еще парочку дыр- на будущее, так сказать. Поэтому настоятельно рекомендую хранить бекапы на локальной машине! Едем далее.
— Устаналиваешь бекап базы данных. Внимание! Бекап БД должен быть датирован ДО ДАТЫ ВЗЛОМА, потому что, как показывает последняя практика, вполне вероятно, что троян может находиться в самой БД ! Если же восстановить базу данных до даты проникновения не представляется возможным, тогда надеваешь очки, наливаешь пару литров кофе- и поехал искать вредоносный код в базе вручную... Бекдор ( backdoor) в БД- это, к сожалению, уже не фантастика, а реалии жизни...
— Не забудь проверить свою локальную машину антивирусом: возможно, твои данные были банальным образом стянуты через FTP- клиент.
— Обязательно сменить ВСЕ пароли! Не забывай, что хакер имел доступ ко всем твоим файлам, сомневаюсь, что старый твой пароль в md5 будет для него преградой...
— Ну и маленький совет на будущее от меня лично: фильтруй данные не только при записи в базу данных, но и при их извлечении!
Пока на этом все, май френд. Осознаю, что раскрыл далеко не все аспекты, что осталась еще гора вопросов технического плана. Я постараюсь продолжить подобные публикации, и, возможно, освещу основные моменты в ближайшее время. Ну а пока- всего доброго, удачи тебе и спокойного крепкого сна, без боязни проснуться с надписью HACKED BY MEGACOOLHACKERS, иже ей подобной.
Понравилась статья?
Метки для данной статьи
Похожие статьи
Заголовок
Категория
Просмотров
Поделиться:
Последние активные темы форума
Темы | Просмотров | Ответов | Последние сообщения | |
Вопрос по переделке bb-кода PHP, MySQL |
21880 | 5 | Pisatel 26. мая 2017 |
|
Вопросы по Ajax форме обратной связи CMS PHP Fusion |
66527 | 48 | Ditrin 19. февраля 2017 |
|
BBCode YouTube Video Colorbox mod CMS PHP Fusion |
15146 | 2 | Pisatel 10. декабря 2016 |
|
Как лучше создать собственную страницу? CMS PHP Fusion |
17591 | 17 | Pisatel 11. мая 2016 |
|
Небольшие вопросы по скриптам магазина и катало... PHP, MySQL |
140967 | 80 | Pisatel 11. января 2016 |
|
BBCode Code mod CMS PHP Fusion |
14093 | 0 | Pisatel 31. августа 2015 |
|
Ajax Like Dislike Article Panel CMS PHP Fusion |
22112 | 16 | Pisatel 07. июля 2015 |
|
Хлебные крошки / BreadCrumbs SEO Panel CMS PHP Fusion |
25747 | 17 | Pisatel 04. июля 2015 |
|
Abbr Description BBCode CMS PHP Fusion |
7546 | 0 | Pisatel 15. июня 2015 |
|
Плагин Email рассылки Mail To All by Pisatel CMS PHP Fusion |
36134 | 32 | Pisatel 26. апреля 2015 |
|
Подозрительный трафик и прочие страшилки Всякая хрень |
11614 | 2 | Ditrin 23. апреля 2015 |
|
Мод Newsletter - рассылка писем пользователям с... CMS PHP Fusion |
30804 | 13 | Pisatel 10. апреля 2015 |
|
Мод отправки писем PHPMailer для PHP-Fusion CMS PHP Fusion |
124640 | 113 | Ditrin 06. апреля 2015 |
|
Появление неизвестного файла subscriptions.php CMS PHP Fusion |
8756 | 2 | Pisatel 06. апреля 2015 |
|
Autoban on IP CMS PHP Fusion |
22980 | 13 | Pisatel 03. апреля 2015 |