почему имя пользователя не имеет UID?
Если вы действительно хотите сделать это "с bash", то
find . -name '*.wcr' -execdir bash -c '
shopt -s extglob; for f; do echo mv -- "$f" "${f/_+([0-9-])_/_}"; done
' bash {} +
Это зависит от расширенного glob +([ 0-9-]), который соответствует одному или нескольким вхождениям символов в наборе [0-9-]
Вы можете сделать замену более конкретной, например ${f/_2017+([0-9-])_/_}, если простое сопоставление цифр и тире слишком распространено.
Примечание: удалите эхо , как только вы убедитесь, что он делает то, что вам нужно.
там написано, что у пользователя нет UID
Я конечно с этим согласен. Пользователь, определяемый как «злонамеренный пользователь, запускающий что-то на сервере», не имеет UID, но это потому, что этот пользователь — это человек, который может (возможно) запускать что-то под разными UID на вашем компьютере (с этого момента я буду придерживаться к термину «агрессор»).
Таким образом, правильный путь — попытаться выяснить, какой путь выбрал злоумышленник, чтобы получить контроль над процессом на вашей машине, который может выполнять fork() и exec(). Это довольно хорошая отправная точка, потому что, в конце концов, успешная атака начинается с получения контроля (возможно, очень запутанным способом) над процессом, который может это сделать. То, как злоумышленнику удается добраться до этой точки, зависит от атаки.
Тем не менее, канонический ответ о том, что делать со скомпрометированным сервером, состоит в том, чтобы уничтожить его с орбиты. Это больше не ваш компьютер, и вы не можете быть уверены, какой доступ получил злоумышленник. Если злоумышленник получил привилегии root, то вы можете также подключиться к виртуальной машине, работающей на том, что когда-то было вашим сервером. Или вы даже можете иметь дело с руткитом.
(Примечание: "nuke from orbit" означает "новая установка" для большинства людей)
Вернемся к основному вопросу:
почему имя пользователя не имеет UID?
Или лучше подразумеваемый текстом вопроса:
(как процесс работает без UID?)
Идея, что процесс работает без UID, абсурдна.Структура ядра, которая поддерживает существование процесса (фактически KSE), содержит поле UID, которое необходимо заполнить (даже если оно заполнено хламом в случае, скажем, ошибки ядра). Поэтому каждый процесс всегда имеет UID.
Скорее всего, вы имеете дело с тем, что UID не указан в /etc/passwd, что, хотя и странно для процесса, ничем не отличается от выполнения touch leet; chown 1337 leet (при условии, что у вас нет пользовательского leet с таким UID). Практически все стандартные инструменты *nix работают с UID так же, как и с именами пользователей. т.е.
lsof -u username
эквивалентно
lsof -u `id -u username`
И
find . -user username
также эквивалентно
find . -user `id -u username`
. Поэтому вернемся к первой цитате (выделено мной):
говорится , что у пользователя нет UID
. ] Что бы там ни было it, это не стандартный инструмент *nix. Или вы действительно более облажались, чем думаете, и работаете внутри какой-то довольно странной среды, созданной злоумышленником.
Чтобы найти файлы без владельца в вашей системе, вы можете запустить find / -nouser
Вы также можете запустить find /sbin -mtime 1, чтобы найти любые файлы, которые были изменены в течение дня в каталог /sbin.
Проще говоря, пользователь и бинарный файл могли быть удалены из системы или root мог запустить процесс и изменить uid; будьте готовы, что вы тоже можете не найти двоичные файлы.
На данный момент я бы не загружался со скомпрометированной системой, а загружался бы с работающим дистрибутивом для анализа файловой системы. Как говорит grochmal, у вас могли быть установлены скомпрометированные инструменты/двоичные файлы, если была компрометация root. Тот факт, что у вас есть двоичный файл, о котором вы не знаете пользователя, сильно указывает на это.
Тем не менее, я видел пару компрометаций системы, либо с укрупнением root, либо с простой компрометацией пароля пользователя, где, по-видимому, было распространенной тенденцией оставлять двоичные файлы работающими, а затем удалять их, чтобы усложнить криминалистические операции.
Если у вас есть запущенные процессы и вы знаете их PID, вы можете узнать, какие файловые дескрипторы открыты, с помощью «ls -l /proc/PID/fd», где PID — это процесс. дис процесса.
Проблема в том, что процесс может открыть файл, прочитать или записать его, а затем закрыть файл fd. В этом случае вам ничего не скажет, но идея @damansk использовать find поможет.
Вы также можете отслеживать процесс и смотреть, какие вызовы open() он делает.
Я также видел это при использовании docker, так как UID внутри контейнеров могут не сопоставляться с пользователями в хост-ОС.