Comments 30
Не лучше ли сменить хостера было?..
Не согласен, смена хостера у высоконагруженного проекта, на который льется трафик — тот еще геморрой.
Клиент по факту потом таки и сменил хостера
Собственно и история о том как человек лечил следствие, а не причину до тех пор пока «само не прошло».
Можно было бы рассказать так:
Однажды я простудился и начал чихать.
Вместо того чтобы идти к врачу, я нанял гастербайтера, который зажимал мне рот платком, когда замечал, что я хочу чихнуть.
Было неудобно.
Так же было неприятно и сыро в ботинках, но я не обращал на это внимания.
Через полгода простуда прошла (после небольшого воспаления лёгких, которое я тоже не стал лечить).
А ещё через полгода я купил новые ботинки.
С тех пор живу долго и счастливо, не болею. Но с гастербайтером тем не расстаюсь — он стал моим лучшим другом. Я его пою, кормлю, читаю ему книжки на ночь, а он взамен следит не захочу ли я чихнуть. И если я захочу — он заткнёт мне рот.
Конец.
Можно было бы рассказать так:
Однажды я простудился и начал чихать.
Вместо того чтобы идти к врачу, я нанял гастербайтера, который зажимал мне рот платком, когда замечал, что я хочу чихнуть.
Было неудобно.
Так же было неприятно и сыро в ботинках, но я не обращал на это внимания.
Через полгода простуда прошла (после небольшого воспаления лёгких, которое я тоже не стал лечить).
А ещё через полгода я купил новые ботинки.
С тех пор живу долго и счастливо, не болею. Но с гастербайтером тем не расстаюсь — он стал моим лучшим другом. Я его пою, кормлю, читаю ему книжки на ночь, а он взамен следит не захочу ли я чихнуть. И если я захочу — он заткнёт мне рот.
Конец.
А откуда вредоносный код то? Если так часто меняется файл, то значит у кого то полный доступ, причем даже после смены пароля.
Мне кажется, было бы не лишним озвучить хостера. В группе риска не только вы, но и все его пользователи.
P.S. Забыл, что повествование не от пострадавшего лица, извините. Но, если есть такая информация, то озвучить в любом случае не помешало бы.
P.S. Забыл, что повествование не от пострадавшего лица, извините. Но, если есть такая информация, то озвучить в любом случае не помешало бы.
Основная проблема тут — ужасающие технологии. shared hosting вообще не даёт возможности понять, что происходит.
Потому что если бы такое произошло у меня, то если бы канонические методы анализа не сработали бы, то я бы просто пустил tcpdump на всё с отсылкой данных на соседний сервер. А потом бы под микроскопом изучал пакеты и момент появления файла.
Но без root-доступа (точнее, без cap networking) это невозможно.
Переползайте на vds'ы.
Потому что если бы такое произошло у меня, то если бы канонические методы анализа не сработали бы, то я бы просто пустил tcpdump на всё с отсылкой данных на соседний сервер. А потом бы под микроскопом изучал пакеты и момент появления файла.
Но без root-доступа (точнее, без cap networking) это невозможно.
Переползайте на vds'ы.
Если был более-менее полноценный доступ до файлов, то достаточно было поставить immutable флаг на фаил/каталог. Большинство гадостей (вернее, все, которые я видел) не умеют обрабатывать такую ситуацию
или говоря другими словами, chattr +i js/common.js из под root
или говоря другими словами, chattr +i js/common.js из под root
В линуксе появился флаг read-only?.. Почему же тогда samba до сих пор его виндовым клиентам передавать не умеет?..
Этот флаг отвечает за запрет изменений с объектом. То есть нельзя будет его удалить, сменить ему дату, сменить набор флагов и так далее. Флагу этому почти столько же, сколько и файловой системе.
Про samba не знаю (давно не ставил), но раньше отсутствие флага w говорило виндам, что файлик read-only и они вполне себе были этим фактом довольны.
Про samba не знаю (давно не ставил), но раньше отсутствие флага w говорило виндам, что файлик read-only и они вполне себе были этим фактом довольны.
В линуксе есть флаг «разрешить запись», а отсутствие его = «запретить запись» = «read only». Samba транслирует это в отсутствие права записи у соответствующего пользователя, то есть, получается то же самое.
Флаг read only как отдельный, не в рамках acl — отсутствует, но он вообще бесполезен при наличии acl, которые позволяют делать то же самое, но гибче.
Флаг read only как отдельный, не в рамках acl — отсутствует, но он вообще бесполезен при наличии acl, которые позволяют делать то же самое, но гибче.
Чем по поведению И почему команда
chattr +i отличается от виндового attrib +r? chattr держится в секрете и я про нее первый раз слышу?..
chattr +i более навороченная вещь — после этого даже root не сможет удалить или что-то сделать с файлом. Это уже расширения классической системы безопасности UNIX. Есть ACL, обычные «классические» атрибуты, расширенные атрибуты и вдобавок SELinux — можно вообще закрыться наглухо. По понятным причинам хостеры не заморачиваются с безопасностью.
Естественно, рут может и снять этот атрибут.
Естественно, рут может и снять этот атрибут.
Повторяю вопрос: чем это отличается от поведения на винде? Там точно так же ридонли файлы нельзя трогать, не сняв сначала этот атрибут.
Никто не гарантирует вам наличие расширенных атрибутов в линуксе. Может, ФС не поддерживает их; может, ядро, или просто ФС смотнирована без «acl,user_xattr».
А вот почему вам неизвестна эта команда — это вопрос не к нам, согласитесь.
А вот почему вам неизвестна эта команда — это вопрос не к нам, согласитесь.
Конечно. Это вопрос к авторам книжек, которые я читал…
Начитаться книжек — не значит быть уверенным в собственной образованности. Надо ещё руками щупать всё, с чем работаете, залезать в неположенные места… хм, о чём это я… Флаг
immutable — штатная в Linux, давно известная вещь (по крайней мере мною), но стрёмная, т.к. в будущем может вводить в заблуждение ошибками стороннего ПО типа «нет доступа» — и гадай, что «держит».Чтобы щупать руками разные места, надо знать хотя бы про существование этих самых мест.
ls /sbin; ls /usr/bin + man каждое_увиденное. Это, когда заняться нечем, полностью убивает всяческую депрессию и скуку :-)
Щупайте man, там всё есть. Да и что у вас были за книжки такие, в хороших книгах вроде Linux in a Nutshell всё это написано очень подробно. Да и мне кажется для администратора достаточно только этой книги в 90% случаев.
Он не отображается в выводе ls, он запрещает вам пользоваться chmod (даже если вы root), он поддерживается не во всех файловых системах (из того, что у меня: XFS поддерживает, старая ReiserFS нет, про FAT на флэшках вы, наверное, уже догадались) и о нём знает меньше людей. Кроме того, вы не избавитесь от +i, будь вы хоть трижды владелец файла, тогда как chmod владелец может применить всегда, даже если все атрибуты доступа сброшены.
Это борьба с симптомом, но не болезнью. С моей точки зрения, нужно провести проверку всех исполняемых файлов, в особенности обратить внимание на инструкции вроде eval (у знакомого вебмастера злодеи вшили подобное в его файлы). Затем сменить хостера и залить туда проверенные файлы.
Я бы сделал так
— настучать в арбуз хостинга вирусодержателя (куда ведёт iframe)
— порыться в логах ftp, ssh, — если вирусатор доступается извне (просто украл пароли), то настучать в арбуз его провайдера
— изменить common.js так, чтобы он сам дезактивировал этот iframe
— прописать в кронтаб восстановление common.js из бэкапа
У меня была похожая ситуация, только я не стал расследовать, у кого именно воруют пароль (сайт админили несколько человек).
Мгновенные бэкапы просто отвадили вирусаторов, они в какой-то момент оставили тщетные попытки.
— настучать в арбуз хостинга вирусодержателя (куда ведёт iframe)
— порыться в логах ftp, ssh, — если вирусатор доступается извне (просто украл пароли), то настучать в арбуз его провайдера
— изменить common.js так, чтобы он сам дезактивировал этот iframe
— прописать в кронтаб восстановление common.js из бэкапа
У меня была похожая ситуация, только я не стал расследовать, у кого именно воруют пароль (сайт админили несколько человек).
Мгновенные бэкапы просто отвадили вирусаторов, они в какой-то момент оставили тщетные попытки.
Sign up to leave a comment.
Как Host-tracker помог оперативно обнаруживать вредоносный код