Pull to refresh

Comments 30

Не согласен, смена хостера у высоконагруженного проекта, на который льется трафик — тот еще геморрой.
Клиент по факту потом таки и сменил хостера
Собственно и история о том как человек лечил следствие, а не причину до тех пор пока «само не прошло».

Можно было бы рассказать так:
Однажды я простудился и начал чихать.
Вместо того чтобы идти к врачу, я нанял гастербайтера, который зажимал мне рот платком, когда замечал, что я хочу чихнуть.
Было неудобно.
Так же было неприятно и сыро в ботинках, но я не обращал на это внимания.
Через полгода простуда прошла (после небольшого воспаления лёгких, которое я тоже не стал лечить).
А ещё через полгода я купил новые ботинки.
С тех пор живу долго и счастливо, не болею. Но с гастербайтером тем не расстаюсь — он стал моим лучшим другом. Я его пою, кормлю, читаю ему книжки на ночь, а он взамен следит не захочу ли я чихнуть. И если я захочу — он заткнёт мне рот.
Конец.

А откуда вредоносный код то? Если так часто меняется файл, то значит у кого то полный доступ, причем даже после смены пароля.
Полный доступ есть у хостера, очевидно же.
Поламали сервер хостера. Скорей всего контрольную панель. Пока хостер искал кудой его ломали, а клиент искал нового хостера, пришлось придумывать костыли с мониторингом на вредоносный код.
Мне кажется, было бы не лишним озвучить хостера. В группе риска не только вы, но и все его пользователи.

P.S. Забыл, что повествование не от пострадавшего лица, извините. Но, если есть такая информация, то озвучить в любом случае не помешало бы.
Основная проблема тут — ужасающие технологии. shared hosting вообще не даёт возможности понять, что происходит.

Потому что если бы такое произошло у меня, то если бы канонические методы анализа не сработали бы, то я бы просто пустил tcpdump на всё с отсылкой данных на соседний сервер. А потом бы под микроскопом изучал пакеты и момент появления файла.

Но без root-доступа (точнее, без cap networking) это невозможно.

Переползайте на vds'ы.
Если был более-менее полноценный доступ до файлов, то достаточно было поставить immutable флаг на фаил/каталог. Большинство гадостей (вернее, все, которые я видел) не умеют обрабатывать такую ситуацию

или говоря другими словами, chattr +i js/common.js из под root
В линуксе появился флаг read-only?.. Почему же тогда samba до сих пор его виндовым клиентам передавать не умеет?..
Этот флаг отвечает за запрет изменений с объектом. То есть нельзя будет его удалить, сменить ему дату, сменить набор флагов и так далее. Флагу этому почти столько же, сколько и файловой системе.

Про samba не знаю (давно не ставил), но раньше отсутствие флага w говорило виндам, что файлик read-only и они вполне себе были этим фактом довольны.
В линуксе есть флаг «разрешить запись», а отсутствие его = «запретить запись» = «read only». Samba транслирует это в отсутствие права записи у соответствующего пользователя, то есть, получается то же самое.

Флаг 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 каждое_увиденное. Это, когда заняться нечем, полностью убивает всяческую депрессию и скуку :-)
У меня нет столько времени для убийства… :-)
У меня тоже его не 100%. Но за годы, потихоньку, изучаю… Собственно, из-за куда-то почти сразу затерянного учебника по Linux я так и изучал данное семейство ОС, когда только начинал работать с ним. Главное — знать английский, и не так много времени всё занимает.
man --path | tr : "\n" | xargs -I{} find {} -type f

Как-то так:)
Щупайте man, там всё есть. Да и что у вас были за книжки такие, в хороших книгах вроде Linux in a Nutshell всё это написано очень подробно. Да и мне кажется для администратора достаточно только этой книги в 90% случаев.
Он не отображается в выводе ls, он запрещает вам пользоваться chmod (даже если вы root), он поддерживается не во всех файловых системах (из того, что у меня: XFS поддерживает, старая ReiserFS нет, про FAT на флэшках вы, наверное, уже догадались) и о нём знает меньше людей. Кроме того, вы не избавитесь от +i, будь вы хоть трижды владелец файла, тогда как chmod владелец может применить всегда, даже если все атрибуты доступа сброшены.
Виндовые атрибуты точно так же не отображаются в выводе dir.

Вот тот факт, что его не может поставить или снять владелец файла, только root — уже интереснее, это действительно отличие. Заодно это объясняет, почему его не отображает на read-only флаг samba, и почему его нет на флэшках с фатом.
Не только root: в соответствии с документацией это может сделать root или любой процесс, которому предоставлена возможность CAP_LINUX_IMMUTABLE (в 99 % случаях это действительно означает «только root»).
Это борьба с симптомом, но не болезнью. С моей точки зрения, нужно провести проверку всех исполняемых файлов, в особенности обратить внимание на инструкции вроде eval (у знакомого вебмастера злодеи вшили подобное в его файлы). Затем сменить хостера и залить туда проверенные файлы.
Я бы сделал так
— настучать в арбуз хостинга вирусодержателя (куда ведёт iframe)
— порыться в логах ftp, ssh, — если вирусатор доступается извне (просто украл пароли), то настучать в арбуз его провайдера
— изменить common.js так, чтобы он сам дезактивировал этот iframe
— прописать в кронтаб восстановление common.js из бэкапа

У меня была похожая ситуация, только я не стал расследовать, у кого именно воруют пароль (сайт админили несколько человек).
Мгновенные бэкапы просто отвадили вирусаторов, они в какой-то момент оставили тщетные попытки.
Sign up to leave a comment.