Есть VPS (Centos 6.0, cPanel/WHM — если важно) — на нам десяток сайтов, хочется настроить информирование при изменении любых файлов в указанном списке директорий.
Я могу это сделать с помощью программерского подхода — загнать все в git и потом вывод git status отправлять по крону, если он не стандартный.
Хочется изменения часто — раз 5-15 минут видеть.
А какой будет верный подход? Потому как git все же не быстрый, на нужных объемах…
Файлов не много — 10к, 250 мегабайт примерно. Будет ну максимум раза в три больше.
Ага, идея понятна — т.е. фактически дергать git не по таймеру, а по событиям на файлов системе :) Ибо как я понимаю — получить блокирующий вызов события ДО изменения файла — не получится (чтобы снять копию, до именения и сравнить после изменения чтобы получить дифф)? Спасибо, через yum установился — попробуем завтра конфиги пописать.
Эм… А git-то зачем дёргать? Письмо отправлять надо по таким событиям. А если посмотреть изменения, то потом либо diff'ом, либо если хотите то вручную git запустить. А самое темное это diff -u на почту отправлять.
В случае incron — я пока не очень понимаю, от чего дифф то брать. Т.е. либо нужно сложную схему — если файл открыли на записать — то скопировать его, когда закрыли — взять дифф от предыдушей копии и текущей и прислать.
Сорвалось. Мне то собственно сгенерировать набор директорий не сложно — но их много будет — много сотен, если не тысяч. Будет нормально работать — не просядут другие файловые операции, в других путях которые не отслеживаются?
Ну тогда можно повозится с достаточно серьёзной тулзой контроля целостности — tripwire. Однако она не даст вам инфы в реальном времени, что может дать механизм inotify. Tripwire бегает по cron.daily по умолчанию. На счёт производительности данной системы не могу сказать.
Замерил — типичный wordpress сайт это порядка 650 файлов, и порядка 130 директорий. Т.е. тысяч не будет, но будет больше тысячи и меньше двух вероятно. Другое дело можно ограничиться директорями с кодом — будет раза в два меньше.
Ну собственно мне добавить здесь нечего. Примеры решений я Вам дал. До кучи ниже предложен auditd и даже скрипт через find (это уже точно не котируется на фоне tripwire).
Выбор и реализация за Вами.
Я думаю для правильного решения задачи нужно понимание о каких изменениях вы хотите узнавать: «юзеры сайта заменили файл в катплог uploads» или «злобные прошаренные хакеры взломали истему и подчистили следы»?
Решения естественно будут разные.
Скорее второе — нашли дыру в сайте и добавили бекдоров, ссылки, айфреймы и прочую гадость. Собственно почему хочется — уже был претендент — когда собственно дырку нашли в январе и тогдаже разместили бекдор, а воспользовались через полгода. Проводить аудит чужого кода полугодовой давности — то еще удовольсвие.
chkrootkit и rkhunter
Один из них даже знает контрольные суммы оригинальных файлов системы (которые в дистрибутиве, полезно, если не собирали из сорцов) и может показать какие были изменены.
Ну и контроль целостности нужно делать. Вроде бы они это тоже могут или придется использоватдополнительное ПО.
Хм — все же это немного не о том. Вот смотрите — типичный взлом с которым я сталкиваюсь такой — через дырку разместить php файлы, который при исполнении проходится по всем файлам — находит index.php и index.html и добавляет туда показ айфрема или просты ссылки. Как я понимаю данные инструменты это не отловят.
Плюс второе — чисто админские какие-то инстурменты. Ну вот запустил я rkhunter — выдал он мне
Warning: The command '/sbin/ifdown' has been replaced by a script: /sbin/ifdown: Bourne-Again shell script text executable
Warning: The command '/usr/bin/GET' has been replaced by a script: /usr/bin/GET: a /usr/bin/perl -w script text executable
или
Warning: No output found from the lsmod command or the /proc/modules file:
или
Warning: Hidden directory found: '/dev/.udev'
И что делать?? Я бы ожидал — подсказки — мол стандратно жидается что то-то, а вот то что у вас скорее означает то-то, и сделать нужно это.
Первоочкредная задача этих инструментов — определить что система скомпроментирована. Что делать дальше — и так понятно. Если руткит или сам взломщик заменил скрипты — значит нужно заменить их обратно на оригинальные. Думаю не нужно объяснять почему.
В задаче по отслеживанию изменения в самописных файлов я вижу два пункта: контроль целосности и запрет на запись файлов даже хозяину (или изменение хозяина на того, с чьими привилегиями не запускается httpd). Вы ведь не часто изменяете index.php, не так ли? И почти никогда не делаете это с помощью веб-сервера. Скорее в консоли или ftp.
«Что делать дальше — и так понятно» — мне вот не очень...:)
Вот на примере моего варнинга — что мол /sbin/ifdown и /sbin/ifup заменены на скрипты. Ну посмотрел я на эти скрипты — вполне себе валидные — есть предположение что так изначально и было при установки системы ( или после установки cPanel/WHM). Опять же «заменить на оригинальные» — для системного администарота это как бы возможно тревиальная задача, а вот мне не очевидно. Или есть простой способ? yum install ifup не подходит :) Или как можно посмотреть какой должен быть ifup для kernel-2.6.32-71.el6.i686?
Но это так, ради беседы…
Контроль целосности — да сижу изучаю Tripwire, incron — в целом что нужно. Запрет на запись — тут сложно, некоторые скрипты все же пишут — но в целом идея понятна, тоже веротяно нужно от веб-сервера запретить писать (хотя как это сделать именно для определенного типа файлов — без проставления прав на нужные файла не понятно пока
«Что делать дальше — и так понятно» — мне вот не очень...:)
Вот на примере моего варнинга — что мол /sbin/ifdown и /sbin/ifup заменены на скрипты. Ну посмотрел я на эти скрипты — вполне себе валидные — есть предположение что так изначально и было при установки системы ( или после установки cPanel/WHM). Опять же «заменить на оригинальные» — для системного администарота это как бы возможно тревиальная задача, а вот мне не очевидно. Или есть простой способ? yum install ifup не подходит :) Или как можно посмотреть какой должен быть ifup для kernel-2.6.32-71.el6.i686?
Но это так, ради беседы…
Контроль целосности — да сижу изучаю Tripwire, incron — в целом что нужно. Запрет на запись — тут сложно, некоторые скрипты все же пишут — но в целом идея понятна, тоже веротяно нужно от веб-сервера запретить писать (хотя как это сделать именно для определенного типа файлов — без проставления прав на нужные файла не понятно пока)
Ну как говорится — люди делятся на тех кто не делает бэкапы и на тех кто уже делает бэкапы. Распаковали бы из прошлого бэкапа и все.
Скрипты должны писать или в базу или в один конфиг. И вот на этот конфиг права на запись быть должны. А на сами скрипты — нет.
Я в случае компроментации сервера предпочел бы все снести, если восстанавливть неоткуда. Ну или хотя бы у хостера попросить оригинальны файл. На других машинках ведь наверняка такой же.
