Я сетевой и системный администратор в организации, насчитывающей чуть менее 500 пользователей. У нас есть несколько серверов Windows, и это, безусловно, моя область знаний.
У нас также есть очень небольшое количество серверов Debian.
Мы собираемся прекратить работу системного администратора этих систем Debian.
За исключением отключения систем, я хотел бы знать, как я могу гарантировать, что предыдущий администратор не будет контролировать эти системы в будущем, по крайней мере, до тех пор, пока мы не наймем замену системного администратора linux.
У меня есть физическая / виртуальная консоль доступа к каждой из систем, поэтому я могу перезагружать их в различных пользовательских режимах. Я просто не знаю, что мне делать.
Предположим, что в настоящее время у меня нет root-доступа к все этих систем (оплошность с моей стороны, которую я теперь признаю).
У меня есть некоторый опыт работы с Linux, и я использую его на своем рабочем столе ежедневно, но я должен признать, что я компетентный пользователь Linux, а не системный администратор.
Однако я не боюсь командной строки ....
Есть ли список шагов, которые нужно предпринять, чтобы «обезопасить» систему от кого-то еще?
Еще раз заверяю вас, что это законно, я вновь беру на себя контроль над системами своего работодателя по его просьбе.
Я надеюсь, что мне не придется отключать системы навсегда и по-прежнему быть достаточно уверенным в их безопасности.
Этот ответ в первую очередь предназначен для поддержки преимуществ надлежащего поддержания доступа в вашем ИТ-отделе.
Ваша ситуация демонстрирует преимущества контрольного журнала и надлежащего контроля доступа. Например, для любого доступа без исключения потребуется билет запроса на доступ с утверждением. После расторжения вы проводите аудит тикет-системы.
Для общих ролей в вашей компании доступ может быть стандартизирован и даже проще исключить.
Для ИТ-ролей у нас есть электронная таблица, по которой мы работаем для увольнений. В нем перечислено все, чтобы предотвратить оплошность. Мы также проверяем наши билеты запросов на доступ и нашу систему регистрации работы, поскольку все производственные изменения документируются там.
Администраторы также должны иметь индивидуальные учетные записи пользователей, которые они используют для доступа к административным привилегиям. корневые и административные учетные записи не должны аутентифицироваться напрямую. Хотя это не является технически безошибочным, но позволяет вести контрольный журнал, а также индивидуальную ответственность. При этом блокировка всех его учетных записей будет первым шагом, а затем вы измените все учетные записи администратора.
Если вы еще этого не сделали, я бы посоветовал вам реализовать некоторые из этих решений, если не все. Я считаю их неотъемлемыми, и это снижает риск, когда происходит недобровольное прерывание.
Во-первых, удалите весь доступ к внешней стороне. Любой доступ, которым человек может воспользоваться, не находясь в помещении. Затем смените все пароли. Каждый пароль администратора, каждый системный пароль, каждый пароль приложения, каждый пароль учетной записи поставщика, каждый пароль учетной записи поддержки - все. Если риск возмездия велик, вы можете также истечь пароли всех сотрудников.
Поскольку у вас нет паролей root к серверам Linux, вы можете загрузиться в однопользовательском режиме и изменить его. С участием GRUB и LILO, вы просто добавите single. Методы аналогичны.
Как рекомендовали другие, выполните аудит всех crontab (расположенных в / var / spool / cron), пользователей системы, запущенных демонов, пар ключей ssh и систем в целом.
Хотя восстановление - единственный способ убедиться в этом, в большинстве случаев в этом нет необходимости. Ни один уважаемый профессионал не стал бы рисковать своей карьерой из-за такой гортанной реакции. Это также позволит вашему работодателю требовать возмещения как уголовного, так и гражданского ущерба. В конце концов, я бы посоветовал серьезно обсудить риски с вашим руководителем после проведения комплексной проверки удаления.
Вы можете перезапустить системы Debian в однопользовательском режиме и изменить пароль для учетной записи root, но вам также необходимо убедиться, что нет других пользователей с доступом SSH, к которым имеет доступ системный администратор.
Любые пароли FTP или MySQL также должны быть изменены. Вы также можете начать проверку служб и заданий cron и убедиться, что каждая запущенная программа должна работать.
Самым безопасным и быстрым путем было бы резервное копирование ваших данных и переустановка серверов, хотя это зависит от того, сможете ли вы принять время простоя, которое это создает.
Удалите неизвестные ключи ssh из /root/.ssh/authorized_keys и найдите, есть ли у других пользователей неизвестные пользователи в их файле authorized_keys.
Базовые две недели оставляют плату на корневом пароле!