Comments 17
А для IIS и ASP.NET будет продолжение?
Если какие-то файлы были изменены, то имена этих файлов запишутся в файл files.txt и отправятся на почту.Только не «были изменены», а «дата модификации была изменена», которую можно и подделать и скрипт уже не сработает.
Сработает, если использовать incrond
В целом тема интересная.
В целом тема интересная.
UFO just landed and posted this here
Для ext4 можно проверять crtime метку (creation time). Если не ошибаюсь, подделать её можно только патчингом ядра, что как бы тот ещё геморрой на наломанной машинке.
Если руками:
Ну и да, это будет полезно только для поиска новых вредоносных файлов.
Если руками:
$ sudo debugfs -R 'stat /var/www/index.php' /dev/sda1 2>/dev/null | grep crtime | cut -d ' ' -f4-9
Tue Feb 13 11:34:47 2018
Ну и да, это будет полезно только для поиска новых вредоносных файлов.
А есть какие-то более «профессиональные» что-ли средства аудита изменения в сайтах, на разных CMS? Чтобы не только файлы шаблонов мониторило, но и в СУБД?
У нас, например, не cron дергается каждую минуту, а ночью контентно сравниваются файлы в архивах бекапов с их предыдущими версиями и все это на стороннем сервере происходит.
Такой подход не плох, но бекапы СУБД таким способом «в лоб» не сравнить, увы. Нужно знать архитектуру БД конкретной CMS.
У нас, например, не cron дергается каждую минуту, а ночью контентно сравниваются файлы в архивах бекапов с их предыдущими версиями и все это на стороннем сервере происходит.
Такой подход не плох, но бекапы СУБД таким способом «в лоб» не сравнить, увы. Нужно знать архитектуру БД конкретной CMS.
Очень странное послевкусие от прочитанного материала.
В первую очередь хочу обратить внимание, что если сервер скомпрометирован, и в сервере заинтересован взломщик, то ни одно средство работающее на скомпрометированной системе нельзя считать доверенным.
Все описанные проблемы давно решаются системами вроде AIDE или аналогичными.
Даже если вынести за скобки подобные системы, любой проект сейчас обязан быть под контролем любой системы контроля версий, которая в свою очередь показала бы все изменения в проекте эффективнее чем все те скрипты что было описаны в материале.
В первую очередь хочу обратить внимание, что если сервер скомпрометирован, и в сервере заинтересован взломщик, то ни одно средство работающее на скомпрометированной системе нельзя считать доверенным.
Все описанные проблемы давно решаются системами вроде AIDE или аналогичными.
Даже если вынести за скобки подобные системы, любой проект сейчас обязан быть под контролем любой системы контроля версий, которая в свою очередь показала бы все изменения в проекте эффективнее чем все те скрипты что было описаны в материале.
Не соглашусь с Вами. Контроль версий штука безусловно полезная и необходимая. Но что с него толку, если у Вас 100 проектов? Вы действительно будете глазками анализировать все изменения? Нужно же знать, куда смотреть.
На мой взгляд триггеры, которые привлекают внимание к возможной проблеме, нужны независимо от контроля версий. Да и вопрос того, какие изменения были внесены, это уже больше к расследованию.
На мой взгляд триггеры, которые привлекают внимание к возможной проблеме, нужны независимо от контроля версий. Да и вопрос того, какие изменения были внесены, это уже больше к расследованию.
Я пытаюсь донести вот какую мысль:
Если у Вас 100 проектов, то Вам как администратору такого сервера нужно смотреть не в сторону таких скриптов, а подымать свой уровень администрирования. Изучать современные средства мониторинга работы подобных серверных систем. Если же у нас «сервер на коленке» для своих «пэт» проектов то применение таких скриптов оправдано в образовательных целях, и проигрывает той же системе контроля версий.
Если у Вас 100 проектов, то Вам как администратору такого сервера нужно смотреть не в сторону таких скриптов, а подымать свой уровень администрирования. Изучать современные средства мониторинга работы подобных серверных систем. Если же у нас «сервер на коленке» для своих «пэт» проектов то применение таких скриптов оправдано в образовательных целях, и проигрывает той же системе контроля версий.
Статья о самых наивных способах узнать, что произошёл дефейс. Может стоит копнуть глубже?
#!/bin/bash
if (find ./ -name '*.php' -mmin -1)
then find ./ -name '*.php' -mmin -1 > ./files.txt
echo "Subject: static files changed!" | sendmail -v user@mail.com < ./files.txt
fiа для чего find выполняется 2 раза, причём 1 раз вхолостую?
и да, атрибуту mtime верить нельзя, ибо даже старый как мир wso2 автоматически подменяет mtime при правке файла, при условии что мы владельцы файла
#!/bin/bash
find ./ -iname '*.php' -cmin -1 > ./files.txt
[ -s ./files.txt ] && echo "Subject: static files changed!" | sendmail -v user@mail.com < ./files.txt
Я делаю надёжнее:
И этот скрипт запускается в cron-е. Все изменения выдаются командой diff и cron их честно присылает на почту.
find "/path/to/files" -type f -exec sha1sum \{\} \; >>/root/sums-new.txt
diff /root/sums.txt /root/sums-new.txt
mv /root/sums-new.txt /root/sums.txt
И этот скрипт запускается в cron-е. Все изменения выдаются командой diff и cron их честно присылает на почту.
Sign up to leave a comment.
Как понять, что ваш сайт взломали?