Вопросы Теги

Есть ли шанс, что некоторые из этих процессов являются злонамеренными?

Править: Вообще-то, если задуматься я понял, что, возможно, неправильно понял вопрос. Если Вы хотите, чтобы каталог только был видим определенному пользователю (т.е. для любого пользователя, тот список даже не обнаруживается в списке каталогов), Вы не можете сделать этого, не мешая другим пользователям перечислить содержание родительского каталога. Таким образом, если каталог /foo/bar затем можно удалить r разрешение на /foo (для всех, но владельца) препятствование тому, чтобы другие пользователи перечислили содержание /foo, но Вы не можете скрыться /foo/bar конкретно (хотя можно, конечно, скрыть его содержание).

Старый ответ:

Сделайте того определенного пользователя владельцем каталога и затем удалите все полномочия на том каталоге для всех, но владельца. В оболочке Вы использовали бы chmod сделать это:

chmod 700 the_directory

Если Вы используете filemanager, просто удаляете все галочки на вкладке полномочий кроме тех в "Пользователе" - столбец (точные детали зависят от filemanager, конечно).

3
09.03.2011, 01:37
3 ответа

Это - длинный список, конечно, Вы не ожидаете, что мы рассмотрим его линию за линией? Нормально иметь много процессов, работающих как корень: системы Unix часто имеют один процесс, чтобы сделать каждое задание, столько системных служб получает свой собственный процесс. На самом деле, некоторые из них (например, весь /0 или / (число определяет ЦП), и большинство из тех начало k) потоки ядра.

Если Вы волнуетесь по поводу кого-то получающего контроль над Вашей машиной, ps не полезный инструмент. Любой промежуточный достойный ¹ руткит содержит код для сокрытия любого злонамеренного процесса от списков процессов. Даже если бы вредоносный код не работал как корень и так не мог бы изменить отчеты о ядре, то он замаскировался бы как что-то безвредное как sh.

¹ Да, “достойный” может не быть правильное слово здесь.

7
27.01.2020, 21:08

Идея оценить, является ли процесс злонамеренным на основе своего имени, является идеей, которая устарела для, по крайней мере... хорошо, очень долго ;)

Ложные операции флага, кто-либо?

  1. заражающий вирус мог добавить/вставить вредоносный код в любой двоичный файл
  2. злонамеренный двоичный файл мог очень хорошо позировать под тем же именем как что-то, что Вы будете обычно считать безопасным, и Ваш список не дает идеи о местоположении двоичных файлов в файловой системе или их битах файла. Например, setuid двоичный файл, принадлежавший корню, соответствующему одному из этих процессов, должен, по крайней мере, быть проверен...
  3. руткит обычно пытается скрыться, таким образом, это даже не появилось бы в списке

И тот список не является исчерпывающим. Кроме того, система, которая выполняет вредоносный код с правами суперпользователя, не имеет никакой (технической) проблемы для лжи о Вас.

По крайней мере офлайновый анализ требовался бы. При использовании диспетчера пакетов Вы могли бы сравнить двоичные файлы в их ожидаемых местоположениях против хешей в пакетах (со знаком). В целом это должно оставить только крошечное подмножество двоичных файлов фактическими двоичными файлами для Вас для осмотра помимо многочисленных сценариев. Но даже для сценариев, у тех, которые существуют пакетов, будет сопроводительный хеш, по которому можно проверить двоичный файл.

4
27.01.2020, 21:08
  • 1
    хм, я не уверен, что это действительно помогает мне, но я не сделал downvote Вы –  ixtmixilix 09.03.2011, 22:44
  • 2
    @ixtmixilix: я боюсь, что нет никакого полезного ответа в том смысле, что Вы узнаете, является ли один из процессов злонамеренным. Наименьшее, которое мы можем сделать, тем не менее, должно объяснить Вам, почему ;) –  0xC0000022L 10.03.2011, 03:41
  • 3
    я просто нашел руткит на своем сервере после наблюдения удачливого именованного процесса на top, таким образом, это определенно иногда работает, это может, по крайней мере, быть первый тест –  pietrovismara 21.02.2018, 17:31

Единственный руткит, с которым я когда-либо встречался в дикой природе (в соответствии с Солярисом 8 давным-давно) действительно выполнял сниффера пароля как процесс "lpsched". Проблема состояла в том, что это выполнило двух из них (ошибка в рутките) и выполнило их из каталога, который "человек lpsched" сказал, не был то, где lpsched жил. Кроме того, "PS" был trojaned для не показа дополнительных странных процессов lpsched, но вершина показала им.

Если Вы действительно заинтересованы, смотрите на весь PIDs в/proc. Посмотрите на то, с чем связывается/proc/$PID/exe, для наблюдения, где исполняемый файл действительно живет. Двойная проверка, что против того, где исполняемый файл должен жить. Попробуйте "ls" на всех каталогах, Вы находите, что способ видеть, показывает ли "ls" им всем. "ls", не показывающий каталог, является мертвой дешевой распродажей, что что-то неправильно.

Если какой-либо определенный процесс кажется подозрительным, получите chkrootkit (http://www.chkrootkit.org/) и охотник за руткитом (http://www.chkrootkit.org/) и судите их, чтобы видеть, находят ли они что-нибудь. Необходимо знать, что некоторое плавание руткитов вокруг в дикой природе, но никогда не становились объединенными в тех охотниках за руткитом.

4
27.01.2020, 21:08

Теги

Похожие вопросы