TwitterВопрос специалистам по Unix – контроль доступа
Posted on August 3rd, 2010 by Max Kraynov
Вопрос к специалистам по Unix и вообще по секьюрити:
много лет назад, когда я ещё батрачил в Ситибанке, у нас была следующая система контроля доступа (крутилась на Solaris):
- сотруднику даются админский логин и пароль;
- сотрудник входит в терминальную сессию, вводит логин и пароль, и ему система выдаёт кодовое число, которое надо продиктовать по телефону сотруднику безопасности;
- сотрудник безопасности даёт “отзыв” на это кодовое число, который (отзыв) надо ввести для входа в систему;
- все действия сотрудника протоколируются.
Вопросы:
- с использованием каких систем это можно реализовать?
- есть ли более вменяемые альтернативы для контроля доступа и отслеживания пользовательских действий?
Спасибо 🙂
Filed under: Бизнес
Подписаться по Email
Число-отзыв – это OTP (one-time password), pam-otp.
Протоколирование действий какого уровня? Можно реализовать на уровне syslog протоколирование запуска любой команды.
Могу ответить касательно Linux- и BSD-систем.
1. Действия сотрудника протоколируются “из-коробки” путем записи всех вводимых команд в оболочке в файл истории для этого пользователя. Т.е. для этого ничего особо делать не нужно – это уже присутствует практически в любой Unix-системе. Другое дело, что нужно как-то ограничивать (при необходимости) пользователя в части допустимых действий (запуск программ, окружение шелла и т.д.), но это уже всецело зависит от решаемых пользователем задач. Можно урезать доступ вплоть до одной единственной команды, а можно разрешить все. Тут надо смотреть, что требуется в специфике.
2. Чтобы сгенерировать какое-либо число и показать его пользователю при входе (например, с текстом инструкции, что с ним делать дальше) – тоже решить легко. При входе пользователя будет выполняться скрипт, логику которого ограничивает только фантазия. Т.е. можно реализовать произвольной глубины интерактивный сеанс с произвольным уровнем автоматизации (например, чтобы число автоматически пересылалось по внутренней почте сотруднику безопасности и т.д.) после прохождения которого давать или не давать пользователю уже непосредственно шелл в системе. Опять же это зависит от того, что за систему контроля в конечном счете требуется реализовать.
Все вышеописанное абсолютно необязтельно делать, используя права администратора. Более того, использовать права администратора для решения таких задач крайне не рекомендуется. Строго говоря, “администратором” должен быть очень ограниченный круг лиц (минимально допустимый, исходя из соображений “эффекта грузовика”). 99% обслуживающих и пользовательских действий можно и нужно делать в грамотно настроенной системе, используя пользовательский уровень.
В целом, Unix-системы предоставляют очень широкий спектр решений по контролю доступа, начиная от самого просто матричного доступа, присутствующего “из коробки” и заканчивая сложным мандатным доступом с кучей разнообразных взаимодействующих политик. Этот спектр также в комплексе охватытвает различные уровни сертификации по НСД. Т.е, опять же, все зависит от того какие задачи и на каком уровне нужно реализовать.
Исходя из начального очень приближенного описания задачи, могу сказать, что это можно легко сделать на практически любом обычном Linux-дистрибутиве или BSD-системе без привлечения посторонних решений.
можно прикрутить подобное http://www.aladdin.ru/catalog/etoken/models/etoken_ng_otp/
Не совсем уверен, что полнял вопрос, но, возможно, вам стоит посмотреть в сторону AppArmor или SELinux
Есть такая штука – называется conserver. Может применяться для логирования действий в консоли. Если не давать других вариантов доступа на серверы, то все будет логироваться. Доступ к консерверу можно сделать как угодно, но я пока не вижу за чем конкретно это может быть нужно.
Как угодно – в смысле, с one time password, или просто по паролям, или по ключам ssh (что мне нравится больше), и так далее.
1. Пользователь заходит в систему под собственным логином
2. Если нуждается в админских правах – вводит sudo su –
3. Пользователь в консоли рута, система логирует все его действия от имени пользователя
Для реализации такого надо в /etc/sudoers разрешить пользователю или группе пользователей выполнять команду su без пароля
Огромным плюсом данной схемы является то, что пользователи не знают административный пароль
Это все голая философия. Пункт 3 невозможен даже теоретически.
по пункту 3: есть sudo -i. sudo su – вообще запретить, иначе теряется контроль и смысл sudo
То что под руку попалось по аутентификации.
Хотя, возможно это не совсем то, что хотелось.
http://habrahabr.ru/blogs/infosecurity/99377/
По поводу протоколирования не приходилось. Но гугл результаты выдает.
Тестить надо на пригодность.
Верно скзали. OTP.
Большинство юниксов поддерживают из коробки.
после ввода логина выдается номер (внутрисистемный) функции и последовательность. на основании этих данных и зная свой секретный пароль можно сгенерировать валидный пароль для входа в систему.
Есть внешние брелки-токены, хранящие список паролей и ключей. Можно использовать программные генераторы. Я такой запускаю на своем android-device, когда нужно попасть в защищенный сенмент из интернет-кафе или другого публичного места.
Делается для того, чтобы обезопаситься от возможных кейлоггеров.
Каждому пользователю назначается свой логин и пароль (otp)
Протоколирование делается средствами системы. Для операций, требующих привилегированного доступа настраивается sudo или аналог, который тоже может требовать одноразового пароля.
В точности описанная вами схема нигде в открытых системах не реализовна, это явно была собственная разработка.
По похожей схеме но без подтверждения кода работает система One Time Password (OTP) она широко распространена в банк-клиентах и реализуется обычно либо с помощь карточки одноразовых кодов либо с помощью электроного брелка-генератора.
Насчет альтернатив никакой профессионал не даст вам консультации, потому что Вы не предостатавили достаточно данных. Для чего это нужно, технические требования, какие риски. Напишите мне на email, если не желательно публиковать подробности, обсудим более детально.
Игорь, спасибо, пока можно обойтись без деталей; главное – что уже понятно направление, куда копать.
Протоколирование консоли довольно непросто сделать, и затем еще сложнее читать.
А вот секьюрные OTP сделать можно. В PAM это либо уже есть, либо можно написать. Причем писать там особо нечего, работы на день-два, включая систему генерации OTP.
У моего банка это реализовано через СМС. Логин – номер телефона. Вход осуществляется по номеру телефону и указанному при регистрации паролю. После этого приходит СМС с одноразовым паролем, после ввода которого уже и осуществляется вход в систему.
Ну а полное протоколирование – вопрос легко решаемый технически.
Патн на ядро линукса Grsecurity умеет логировать действия пользователя.
Цитата:
Kernel Auditing (Аудит ядра)
Опции данного меню позволяют протоколировать определенные системные вызовы (например, execve () и fork ()).
Single Group for Auditing
Grsecurity может протоколировать действия пользователя (в частности, exec, chdir, mount/ unmount и IPC). Будут протоколироваться действия не всех пользователей, а только тех, которые входят в группу, GID которой указан в опции GID for Auditing (CONFIG _ GRKERNSEC _ AUDIT _ GID). Чтобы протоколировать действия конкретного пользователя, его нужно добавить в эту группу.
Exec Logging
Протоколирует все системные вызовы execve (), сделанные пользовательским процессом. Вы сможете отслеживать все программы, которые запускаются пользователем.
Resource Logging
Протоколирует попытки пользователя превысить лимит ресурса (например, максимальное число процессов).
Log execs Within chroot
Протоколирует вызовы execve () в пределах chroot -окружения.
Chdir Logging
Протоколирует вызовы chdir()
(Un)Mount Logging
Протоколирует монтирование и размонтирование файловых систем
Это не поможет, т.к. “что такое действие пользователя” – это философский вопрос, не имеющий конкретного ответа.
Например, mysql -uroot db. И там я что-то делаю. Внимание – это действия какого пользователя: меня или mysql? И таких вариантов – миллион.
Это уже крайности. Тогда уж если вы через ssh зашли на другую машину из консоли то это тоже не получится мониторить. Как вариант можно использовать IDS с логирование трафика методом man in the middle. Но это уже совсем перебор имхо.
Прошу прощения. Запостил дважды случаной.
Кстати, восстановить действия в mysql можно будет так же по логам, но это будет не централизовано.
Можно прилепится к сессии через утилиту screen – она отображает все, что пользователь видит на экране. И писать полученный текст. Но это уже натуральный Оруэлловский “большой брат” будет.
Однако если пользователь запустит file.sh > /dev/null 2>&1 ,то мы ничего не увидим
2smail – увидим, что он запустил скрипт. Но если он скрипт удалил, то что делает скрипт, мы узнать не сможем, тут поможет только аудит уровня ядра (auditd во FreeBSD, например)
Да, если он удалит скрипт, то мы ничего не увидим. А в случае логирования системных вызовов мы можем понять что делал тот скрипт когда он его запустил.
Только у нас потом никаких мозгов и скриптов не хватит анализировать этот лог. Это уже очень далеко от реальных действий пользователя.
Ну почему же? Что такое sh фаил? Это набор комманд. Т.е. они будет запущены через exec(). B мы сможем видеть всего строки этого скрипта. А вот если это будет бинарник, тогда да 🙂 Придётся поломать мозг что бы понять что делал этот бинарник. Я ещё раз поторяю – в принципе это можно сделать, вопрос в том стоит ли это того 🙂 И как часто это надо делать.
Запустите strace на простой ls. А теперь представьте себе все то же самое, но в масштабах живой системы. Это будет невозможно анализировать традиционными методами, прикладная полезность сводится к 0.
Я чувствую из это беседы мы с вами разработаем свою систему контроля прав и отслеживания действия пользователя 🙂 Прибыль 50/50.
Значит надо ограничить действия пользователя только запуском установленных и доверенных приложений 🙂 Если конечно в возможности пользователя не должен входить запуск каких-то своих приложений.
yubikey.com
smail01, по логам чего?
по логам mysql. В нём можно включить логировани всех sql запросов.
И теперь – внимание – главный вопрос: а какая связь между записями в general query log и действиями пользователя?
Правильно, ее нет. Записи в логе – это действия MySQL, а не пользователя.
Записи в логе – это SQL запросы. А кто выполняет их? правильно – пользователь.
Это – не формальная связь. Ее может проследить только специалист, читая логи, да и то, не всегда. Более того, даже найдя запросы в логе, которые явно выполнил человек, еще следует найти того, кто эти запросы в MySQL скормил (миллионов способов).
Иными словами, искать эту связь или рассчитывать на протоколирование действий пользователя – бессмысленно.
Оговорюсь: mysql в данной задаче не фигурирует. Shell – да, вполне себе.
Добрый вечер, Макс.
Взгляни на THC-vlogger. Я думаю он именно то, что Вам нужно.
Недописал “ВзгляниТЕ”.
А вообще 80, если не 90 процентов покроет патч на ядро от grsecurity.
Да, но ведь аттакер будет достаточно серьезно готовиться, чтобы без труда попасть в эти самые 10%. А это уже означает, что в нашей защите есть известная, открытая уязвимость с понятным механизмом использования. Все, defeats the purpose. 🙂
Оставшиеся 10% должны протоколироваться отдельно каждым приложением, которое он будет использовать. К примеру mysql.
И эти 10% в частности могут быть покрыти THC-vlogger. К сожалению руки не дошлли его опробывать. Но насколько я понял из описание – это что-то вроде килогера для удалённого термила. А все команды в ssh передаются прямым набором текста руками. В частности он перехватит все ваши запросы в mysql при наборе их руками.
Log keystrokes of all user sessions
Console, serial console
Telnet/SSH remote sessions
патч на ядро – это может быть и хорошо. однако, мы гарантированно привязываемся к linux, который совсем не обязательно является лучшим решением для данной конкретной компании или данных конкретных условий.
В исходных данных, которые дал Макс, не сказано какая именно ОС. Если будет названа ОС – тогда уже и надо искать решение именно под неё. Я уверено что можно найти альтернативу патча grsecurity и под bsd системы и любые другие. Смысл моего поста – это логирование действий на уровне ядра, конкретная реализация под linux – это патч.
вообще-то, я говорил про Solaris 🙂
Значит я не так вас понял 🙂 Я просто подумал что его вы приводили как пример. Вам в итоге под какую ОС надо? 🙂
мир не вращается вокруг патча ядра grsecurity.
более того, сторонний патч на ядро – это само по себе совсем не лучшее решение. скорее от безысходности.
либо такие возможности должны быть в штатной поставке ОС (я не знаю, есть ли такое в Солярке – в наших краях это редкость), либо надо использовать приложения не требующие патчить ядро. ибо накладывать сторонние патчи – обычно выходит дороже.
не могу предложить конкретного опробованного решения. но если стоит выбор между патчем ядра – то я бы таки поискал другую ОС, другой софт и т.п.
ок, не умеете компилировать ядра – так и скажите.
Не хотите патч – используйте lkm. Решение в нашем универе было сделанно на нём.
Макс, обойти протоколирование шелла – не сложнее. Запустить другой шелл или перл или черта в ступе или даже внутри шелла замаскировать свои действия не составит ни малейшего труда.
Это если админ специально колдовал над сервером для протоколирования действий в шеллах. Если нет, то unset HISTFILE и досвидания:)
А причём здесь шелл? Это на уровне ядра. Вы понимаете принци перехвата системных вызовов ядра?
А вы понимаете, что мой вредоносный exec() может приехать не от моего UID’а? А вы понимаете, что я могу исполнить код вообще без использования системных вызовов?
grsecurity логирует (естественно) uid пользователя от которого произошёл вызов exec. Очень интересно как же вы исполните код без использования системых вызовов ядра :)))) не смешите. Это тоже самое что утверждать что я могу программировать под виндовс без win api.
Макс, если Вы желаете – можем обсудить с Вами этот вопрос в скайпе или другом мессанджере. Мой имэил должен быть виден вам.
Я, если это так можно сказать, whitehat.
Моя параноя в моё админство на универском сервере завела меня очень далеко. Студенты очень беспокойный народ, который дня прожить не может не попытавшить взломать сервер своего же университета. И я могу похвастать тем что в моё админство взлома сервера не было, за исключением дырявых веб приложений, за которыми я не следил. До меня (не без моего участия) и после (уже без моего) были 🙂
Я сам лично писал LKM (модуль ядра) для перехвата действия пользователя. Но потом понял что изобрёл велосипед когда увидел тоже самое в grsecurity.
“не было взлома сервера за исключением дырявых приложений” – смех. в чем смысл админа, который следит за таинственным сервером, но не следит за ПО на нем, которое не он писал поэтому он за ним не следит?
сам по себе сервер без приложений “сломать” грубо говоря вообще невозможно. если за приложениями на сервере не следить – тогда вообще нет никакого смысла за чем-то следить.
Вы читать умеете? И будьте добры цитируйте правильно, ок? “за исключением дырявых веб приложений”. ВЕБ приложений! В мои обязанности это тогда не входило. Вы может отличить ВЕБ приложение от системных приложений линукса?
и что это меняет? вы, весь такой hat в белом, охраняете сервер – но если его вдуют в “дырявое веб-приложение” – то вы тут не при чем типа. афигеть. в чем ваша заслуга – спрашивается. учитывая то, что подавляющее большинство “взломов” основаны как раз на “дырявых веб-приложениях” – а не на “системных приложениях линукса”. если речь идет о “системных приложениях линукса” – то и охраны никакой не надо.
Вы только прикидываетесь идиотом или на самом деле не видите разницы между системным администратором и вебмастером? На сервере крутился нагавнокоденный на перле студентами сайт. Через него было совершено проникновение которое было сразу же обнаружено мной и последствия были ликвидированы. Такой пример: хостинг. Администратор хостинга отвечает за то, что у кого-то из клиентов дырявый сайт? Администратор отвечает за то, что бы после взлома этого дырявого сайта злоумышленник не смог взломать ничего сделать дальше, в том числе навредить другим пользователям или захватить сам сервер.
Я доступно объяснил?
ну не что бы бессмыссленно. Это тяжело 😉 Очень тяжело. Но в крайнем случае можно. И это тяжело именно потому что это нецентрализованно. Т.е. вам придётся перерыть логи mysql отдельно отыскивая эти самые следы деятельности пользователя.
Ну хорошо, перерыли логи MySQL. Нашли вредоносный запрос (при условии что он как-то отличается от тех, что генерятся софтом). Смотрим на время – в этот момент на сервере было пять пользователей (при условии что аттакер не прибил wtmp). Ну, че дальше?:)
Забыл очеь старую и добрую вещь от уважаемой команды THC. Называется сие чудо THC-vlogger.
Описание:
THC-vlogger, an advanced linux kernel based keylogger, enables the capability to log keystrokes of all administrator/user’s sessions via console, serial and remote sessions (telnet, ssh), switching logging mode by using magic password, stealthily sending logged data to centralized remote server. Its smart mode can automatically detect password prompts to log only sensitive user and password information.
smail, а я их не буду набирать руками. Я их вызову как удаленную подсистему over ssh.
Понятно, что можно аттакеру сильно усложнить жизнь. Но особенность подобных систем в том, что до тех пор пока в ней остается хоть одна понятная дырка – они бесполезны полностью. Полностью, а не на 10%.
Все что не требует ring0, можно сделать самостоятельно. Впрочем, я неудачно выразился – я имел в виду что запустить на исполнение код можно без exec()’а. Код, разумеется, будет дергать системные вызовы, потому что без них трудно. 🙂
> Ну хорошо, перерыли логи MySQL. Нашли вредоносный запрос (при условии что он как-то отличается от тех, что генерятся софтом). Смотрим на время – в этот момент на сервере было пять пользователей (при условии что аттакер не прибил wtmp). Ну, че дальше?:)
Мы говорим об отслеживании пользовательских действий, а не о предотващении вторжения. Этого в поставленном Максом вопрос не было.
Действия пользователя в логах mysql можно найти по времен. И я точно не уверено пишет ли mysql имя пользователя от которого был вызов. Вообщем найти его действия в mysql можно.
> smail, а я их не буду набирать руками. Я их вызову как удаленную подсистему over ssh.
Не совсем понял что вы имели ввиду под этим.
> Все что не требует ring0, можно сделать самостоятельно. Впрочем, я неудачно выразился – я имел в виду что запустить на исполнение код можно без exec()’а. Код, разумеется, будет дергать системные вызовы, потому что без них трудно. 🙂
Ring0 и есть ядро. Ядро = рабор системных вызовов.
Без системных вызовов не что бы трудно – без них невозможно. А мы как раз и перехватываем все системые вызовы.
Ну будет в MySQL запрос от имени пользователя, которым коннектится вордпресс с его полутора миллионами посещений в день, и че? 🙂
Я не буду набирать команды в ssh. Я их выполню over ssh, но без шелла. И кей логгеры всех мастей пролетают.
Без системных вызовов можно прожить, только почти ничего полезного не сделать. Но код на выполнение можно запустить и без exec(), и это настолько очевидно, что мне странно, как так что вы этого не понимаете, одновременно зная, что такое системный вызов.
вы любите всё драмматизирова. При желании можно найти комманды которые он выполнял. Другой вопрос о стоимости этого.
over ssh и без терминала pts терминала ? 🙂 на котором мы всё снифаем через thc-vlogger.
Будьте добры объясните как мы запустите ваше откомпилированное приложение без вызова exec
Да, по ssh без pts. Е-мое, это же пользовательский функционал
Как запустить код без exec()’a? Я так понял, вы не шутите и не знакомы с принципом работы самого популярного в мире источника уязвимостей в приложениях? 🙁
Если вы имеет виду переполнение буффера и шелкод, то вынужден вас огорчить. Шелкод используем те же самые вызовы ядра.
Хотите я вам расскажу как это делает на ассемблере? Который и используется для составления shellcode’а.
Мы по реестрас процессора раскидываем номер системного вызова, параметры к нему и делаем int $0x80. А знаете что это? Я вам скажу – это вызов прерывания ядра. Именно поэтой причинине в конце всех шелкодов стоит “\x80”.
Давайте вы не будете учить системного программиста, хорошо?
Повторюсь. Я первоначально неудачно выразился: не код без системных вызовов, а _вызвать_ код без exec()’а. И вы, похоже, невнимательно читали: действительно, избегая системных вызовов мало что полезного можно сделать.
Как системный программист системного программиста вы меня удивили, так долго догадываясь о том, что код можно просто разместить в памяти и jmp’нуть на него.
И есть еще миллион способов.
кстати как вариант – для логирования действий через ssh можно потроянить sshd. Что бы он логировал все команды. Это было тоже сделано на моём сервере.
Я тоже повторюсь – ну вызвали вы ваш код “без exec()”. А дальше что? Всё равно дальше он будет использовать системные вызовы, которые мы перехватываем и логируем.
Признаюсь, что вы правы насчёт шелкода – думал долго 🙂 Просто не видел смысла в этом. Всё равно мы упираемся в системные вызовы.
ха, ну и залогируете вы поток сознания от какого-нибудь там nutd с его uid’ом. А как догадаться, что туда подложили свой код? Это ж как логи вычитывать надо, как анализировать 🙂
sshd не всегда аллоцирует терминал и запускает шелл. Пример подсистемы – scp, sftp. Я вызову свой код мимо шелла. 🙂
А даже если и с шеллом, ну допустим. ssh server “cat > lopata.sh”; а в конце lopata.sh идет rm $0. пойди разбери что там было.
>ха, ну и залогируете вы поток сознания от какого-нибудь там nutd с его uid’ом. А как догадаться, что туда подложили свой код?
Это опять же уже предовращение вторжения, а не отслеживание пользовательских дествий. Следите что бы ваш nutd не был дырявый. Это к отслеживанию пользовательских дествий не имеет отношения.
> Пример подсистемы – scp, sftp. Я вызову свой код мимо шелла.
насчёт ssh я не совсем точно сказал. Там логируются не вызовы команд, а логируется вся информация, которая приходит из защифрованного канала со стороны пользователя. Т.е. если вы сделаете cat > lala.sh а потом будет набирать tra-la-la, то ваше tra-la-la тоже будет записано, так же как и предшетвующее этому cat > lala.sh
Хм, даже так. И че, даже scp протоколируется?
Значит, lala.sh будет shar’ом с зашифрованным zip’ом, а расшифровка только по ключу, который тут же будет моментально скачан wget’ом с сайта на googlepages.com.
Господи, Егор, вы меня добить решили сегодня? Московское время 2:36 am. ну закачали вы zip архив зашифрованный, ну (не без помощи вызова команды unzip) зарархивировали его. Ну даже если вы запустите приложение, которое лежало в этом архиве, что даьше? Оно запуститься от вашего имени и будет использовать выховы ядра для своего функционирования.
Вообщем было очень интересно с вами пообщаться. Но я ложусь спать. Если у вас будут какие-то идеи (а они будут, т.к. ваша настойчивость меня просто изумляет), то я отвечу завтра.
Доброй вам ночи.
Oh, мне просто не лень кнопки жмякать. Общение с вами не занимает много времени в течении моего бесконечноего рабочего дня и никак меня не утомляет. Спокойной ночи 🙂
Все верно, слюниксы поддерживают логирование из коробки. Точнее, не слюниксы, а shell – под которым работает пользователь (csh,bash,zsh etc.). Другое дело, что пользователь имееть полный доступ к этим логам – т.е. ему ничего не стоит подредактировать этот лог или вообще его стереть, т.е. никто никогда не узнает что же он там делал на самом деле.
А еще пользователь может запустить midnight commander – и делать все в нем, тогда команды в лог шела писаться не будут – они буду писаться в лог командера, который юзер тоже может редактировать.
В общем, решения “из коробки” imho не существует. Есть некоторые базовые возможности – на которых строить полноценную серьезную систему безопасности (которую Макс описал) наверное все же не стоит.
Мне неизвестны готовые решения подобного рода (не было как-то нужды в таком). Однако, наверняка они существуют.
Хотя, вполне возможно, что в каждой компании есть что-то самодельное для таких задач – это в общем-то тоже вполне нормально.
Задача несколько специфическая (вряд ли под нее есть большой рынок, да и поддерживать такое ПО для всех разновидностей слюникса – задача едва ли посильная), поэтому не думаю что есть большой ассортимент таких решений. Скорее всего, в банке был тоже какой-то набор самописного софта.
Можно покопать в сторону продуктов типа Cyber-Ark. Но это скорее для удаленного доступа администраторов (хотя и для локального схема работает). Суть в том, что загоняются все административные учетки от серверов, рабочих станций, сетевого оборудования, БД и т.п. в систему. Далее админ под личной учеткой заходит на портал, откуда получает доступ (получает пароль, который может автоматически потом меняться или прямой доступ).
Аналог приведенной схемы с кодами подтверждения реализуется с помощью wrkflow, то есть админ оставляет заявку к какому серверу ему нужен доступ, на какое время, и уполномоченный сотрудник утверждает заявку, после чего – как описано выше…
+ пишется журнал действий админа. И понятно кто именно получал доступ, если админов много, что случается в крупных компаниях…